tmeissner

tmeissner

FPGA-Engineer doing design and verification using VHDL, SystemVerilog, SVA and PSL.

Member Since 10 years ago

Dresden, Germany

Experience Points
74
follower
Lessons Completed
50
follow
Lessons Completed
299
stars
Best Reply Awards
28
repos

101 contributions in the last year

Pinned
⚡ Examples of using PSL for functional and formal verification of VHDL with GHDL (and SymbiYosys)
⚡ Library of reusable VHDL components
⚡ Trying to verify Verilog/VHDL designs with formal methods and tools
⚡ Examples and design pattern for VHDL verification
⚡ cryptography ip-cores in vhdl / verilog
⚡ VHDL 2008/93/87 simulator
Activity
Jan
12
2 weeks ago
Activity icon
issue

tmeissner issue comment YosysHQ/sby

tmeissner
tmeissner

pono only checks first property in a design

When using the pono solver, it only checks one property. It will mention this at the beginning, e.g. Solving property: both_ex.v:19.25-20.30.

We don't have a testcase that exposes this problem yet.

tmeissner
tmeissner

I also have stumbled over this behavior some time ago, but was not sure, if that is by intention. pono has an option to set the index of the property to check, but I didn't found any option to solve all properties.

Jan
5
3 weeks ago
Activity icon
issue

tmeissner issue comment ghdl/ghdl

tmeissner
tmeissner

Two process DFF with case statement is synthesized incorrectly

Description I'm trying to use two-process design method (https://www.gaisler.com/doc/vhdl2proc.pdf) with ghdl but I'm getting incorrect synthesis results if I use case statements in combinational process. Simple design that should result in a single DFF is contains latches when synthesized by yosys and reportedly Vivado (https://github.com/YosysHQ/yosys/issues/3141#issuecomment-1003728117).

Expected behaviour In the following example both architectures should result in a single DFF being synthesized.

How to reproduce?

library IEEE;
use IEEE.std_logic_1164.all;

entity dff is
    port (clk : in std_logic; d, load : in std_logic; q : out std_logic);
end entity dff;

architecture with_case of dff is
    signal r, rin : std_logic;
begin
    comb : process (r, d, load) is
        variable v : std_logic;
    begin
        v := r;
        case load is
            when '1' => v := d;
            when others => null;
        end case;
        rin <= v;

        q <= r;
    end process comb;

    regs : process (clk) is
    begin
        if rising_edge(clk) then
            r <= rin;
        end if;
    end process regs;
end architecture with_case;

architecture with_if of dff is
    signal r, rin : std_logic;
begin
    comb : process (r, d, load) is
        variable v : std_logic;
    begin
        v := r;
        if load = '1' then
            v := d;
        end if;
        rin <= v;

        q <= r;
    end process comb;

    regs : process (clk) is
    begin
        if rising_edge(clk) then
            r <= rin;
        end if;
    end process regs;
end architecture with_if;
ghdl -a --std=08 ent.vhd
ghdl synth --std=08 --out=verilog dff with_case > dff_with_case.v
ghdl synth --std=08 --out=verilog dff with_if > dff_with_if.v
yosys -p "read_verilog dff_with_case.v; synth; show;"
yosys -p "read_verilog dff_with_if.v; synth; show;"

Context

  • OS: macOS
  • Origin:
    • Package manager: 2.0.0-dev (1.0.0.r950.g8d512a44) [Dunoon edition]

Additional context

with_if architecture results in an expected one DFF: image

Incorrect synthesis result for with_case architecture: image

tmeissner
tmeissner

Such sensitivity lists are usually ignored by synthesis tools. Their incompleteness is more a problem during simulation, as the behavior of simulation could differ from the intended (and synthesized) behavior.

Dec
22
1 month ago
pull request

tmeissner pull request stnolting/neorv32

tmeissner
tmeissner

Fix compile error with questa, for issue #242

This PR fixes #242 by using a deferred constant. It shouldn't change anything except allowing to compile the package with Questa, which failed before (#242).

Activity icon
created branch

tmeissner in tmeissner/neorv32 create branch fix_neorv32_pkg

createdAt 1 month ago
Activity icon
issue

tmeissner issue stnolting/neorv32

tmeissner
tmeissner

neorv32_package: compile error with Questa

It seems that following line of neorv32_package.vhd isn't compliant to the IEE 1076-2008 standard:

constant def_rst_val_c : std_ulogic := cond_sel_stdulogic_f(dedicated_reset_c, '0', '-');

The cond_sel_stdulogic_f() function is used after declaring its signature before, but before defining it's body in the package body after.

$ vcom -2008 neorv32_package.vhd 
QuestaSim-64 vcom 2021.3 Compiler 2021.07 Jul 13 2021
Start time: 15:04:36 on Dec 22,2021
vcom -2008 neorv32_package.vhd 
-- Loading package STANDARD
-- Loading package TEXTIO
-- Loading package std_logic_1164
-- Loading package NUMERIC_STD
-- Compiling package neorv32_package
** Error (suppressible): neorv32_package.vhd(106): (vcom-1594) Cannot call subprogram "cond_sel_stdulogic_f" before it is elaborated. 
** Note: neorv32_package.vhd(2103): VHDL Compiler exiting
End time: 15:04:36 on Dec 22,2021, Elapsed time: 0:00:00
Errors: 1, Warnings: 0

The IEEE 1076-2008 standard in section 14.4.2.1:

14.4.2 Elaboration of a declaration 14.4.2.1 General Elaboration of a declaration has the effect of creating the declared item.

For each declaration, the language rules (in particular scope and visibility rules) are such that it is either impossible or illegal to use a given item before the elaboration of its corresponding declaration. For example, it is not possible to use the name of a type for an object declaration before the corresponding type declaration is elaborated. Similarly, it is illegal to call a subprogram before its corresponding body is elaborated.

Also see https://stackoverflow.com/questions/29764083/why-cant-i-call-a-function-in-a-constant-declaration-that-is-defined-in-the-sa

A simple fix would be only declaring the constant first and set it after definition of the functions body in the package body. I', preparing a PR which implements that to fix the problem.

push

tmeissner push tmeissner/neorv32

tmeissner
tmeissner

[sw/lib] added non-blocking SPI access functions

tmeissner
tmeissner

[docs/datasheet] minor additions

tmeissner
tmeissner

[sw/example/hex_viewer] added byte/half/word modes #169

tmeissner
tmeissner

[rtl/core/SPI] hardware optimization / code clean-up

tmeissner
tmeissner

[sw/lib} RTE: removed terminal whitespaces

tmeissner
tmeissner

[rtl/core] minor VHDL code fixes / clean-ups

tmeissner
tmeissner

[rtl/core] comment fixes / clean-ups

tmeissner
tmeissner

[docs/datasheet] minor edits

tmeissner
tmeissner
tmeissner
tmeissner

[rtl/core] UART: improved start-bit detection

-> more "spike"-resistant

tmeissner
tmeissner

:bug: [rtl/core] fixed bug (introduced in v1.6.2.4)

tmeissner
tmeissner

[rtl/core] minor control unit fixes

When loading two half-words of an unaligned 32-bit instruction, the instruction issue unit now also checks that both of the fetched half-words did not cause any bus exceptions.

tmeissner
tmeissner

[rtl/core] minor ALU logic optimization

tmeissner
tmeissner

[sw/lib] UART: faster execution of UART setup function

let gcc handle division operations if M instruction is not available; except for compiling bootloader: here we need MINIMAL code size

tmeissner
tmeissner

[rtl/core] UART: minor edits

The updated logic seems to require less logic (tested on Quartus and Radiant)

tmeissner
tmeissner

[sw/bootloader] stall if unexpected exception

tmeissner
tmeissner

[sw/common] improved crt0 for bootloader case

If compiling the bootloader, the stack pointer initialization is made based on the actual physical memory configuration. Hence, the bootloader is now even more independent of the platform-configuration.

tmeissner
tmeissner

[rtl/core] updated pre-build memory images

due to updates in sw libraries and crt0.S

tmeissner
tmeissner

commit sha: 6491bff2a824f2176b8e623845cae65022edd732

push time in 1 month ago
Dec
17
1 month ago
Activity icon
issue

tmeissner issue comment ghdl/ghdl

tmeissner
tmeissner

Bug with signal spy

Hello, I tumbled upon this message while running a testbench including the following line : assert priorities = << signal .arbiter_test.my_arbiter.devicePriorities : priorities_t >> report "Error on priorities input";

Here is the bug report : ******************** GHDL Bug occurred *************************** Please report this bug on https://github.com/ghdl/ghdl/issues GHDL release: 2.0.0-dev (tarball) [Dunoon edition] Compiled with GNAT Version: 9.3.0 Target: x86_64-linux-gnu /home/Data/Supaéro/Substit/Cours/СБИС/ЛР/lr2/ Command line: ghdl -e --std=08 arbiter_test Exception TYPES.INTERNAL_ERROR raised Exception information: raised TYPES.INTERNAL_ERROR : vhdl-errors.adb:30 Call stack traceback locations: 0x55db560f5ae8 0x55db562d987b 0x55db562d1786 0x55db562d91e0 0x55db562947a1 0x55db562a45b4 0x55db562a4763 0x55db562a7b7f 0x55db562acd72 0x55db5631ca6c 0x55db562824e9 0x55db5627f63c 0x55db5628d7f8 0x55db563213db 0x55db562604a4 0x55db56195cbb 0x55db56324d2c 0x55db55f26b93 0x7f87131e00b1 0x55db55f251fc 0xfffffffffffffffe


Have a nice day with it ;)

tmeissner
tmeissner

Yes, that's a possible solution.

Activity icon
issue

tmeissner issue comment ghdl/ghdl

tmeissner
tmeissner

Bug with signal spy

Hello, I tumbled upon this message while running a testbench including the following line : assert priorities = << signal .arbiter_test.my_arbiter.devicePriorities : priorities_t >> report "Error on priorities input";

Here is the bug report : ******************** GHDL Bug occurred *************************** Please report this bug on https://github.com/ghdl/ghdl/issues GHDL release: 2.0.0-dev (tarball) [Dunoon edition] Compiled with GNAT Version: 9.3.0 Target: x86_64-linux-gnu /home/Data/Supaéro/Substit/Cours/СБИС/ЛР/lr2/ Command line: ghdl -e --std=08 arbiter_test Exception TYPES.INTERNAL_ERROR raised Exception information: raised TYPES.INTERNAL_ERROR : vhdl-errors.adb:30 Call stack traceback locations: 0x55db560f5ae8 0x55db562d987b 0x55db562d1786 0x55db562d91e0 0x55db562947a1 0x55db562a45b4 0x55db562a4763 0x55db562a7b7f 0x55db562acd72 0x55db5631ca6c 0x55db562824e9 0x55db5627f63c 0x55db5628d7f8 0x55db563213db 0x55db562604a4 0x55db56195cbb 0x55db56324d2c 0x55db55f26b93 0x7f87131e00b1 0x55db55f251fc 0xfffffffffffffffe


Have a nice day with it ;)

tmeissner
tmeissner

GHDL doesn't support external names yet. See #548 for example.

Dec
15
1 month ago
Activity icon
fork

tmeissner forked nobodywasishere/VHDLproc

⚡ VHDLproc is a VHDL preprocessor
tmeissner GNU General Public License v3.0 Updated
fork time in 1 month ago
started
started time in 1 month ago
Dec
13
1 month ago
Activity icon
issue

tmeissner issue comment ghdl/ghdl

tmeissner
tmeissner

Crash on type generic

The following code crashes ghdl:

entity test is
        generic(
                type g_t_test
        );
        port(
                if_in  : in  g_t_test
        );
end entity;

Error output:

******************** GHDL Bug occured ****************************
Please report this bug on https://github.com/tgingold/ghdl/issues
GHDL release: GHDL 0.34 () [Dunoon edition]
Compiled with GNAT Version: 4.9.3
Target: x86_64-linux-gnu
In directory: /src/
Command line:
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.4/ghdl1 --std=08 -P/usr/local/lib/ghdl/v08/std/ -P/usr/local/lib/ghdl/v08/ieee/ -quiet -o test.s test.vhdl
Exception CONSTRAINT_ERROR raised
Exception information:
Exception name: CONSTRAINT_ERROR
Message: trans.adb:1426 access check failed
Call stack traceback locations:
0x62b52a 0x64aaa0 0x64abe9 0x64fc15 0x664ff0 0x62eb09 0x66735a 0x5ae387 0x58675e 0x97660f 0x978306 0x5ae3d9 0x583c55 0x7fa4fea4182e 0x584157 0xfffffffffffffffe
******************************************************************

Execution terminated by unhandled exception
Exception name: CONSTRAINT_ERROR
Message: trans.adb:1426 access check failed
Call stack traceback locations:
0x62b52a 0x64aaa0 0x64abe9 0x64fc15 0x664ff0 0x62eb09 0x66735a 0x5ae387 0x58675e 0x97660f 0x978306 0x5ae3d9 0x583c55 0x7fa4fea4182e 0x584157 0xfffffffffffffffe
ghdl: compilation error

ghdl is 1cf3b7f8 (master) gcc is 2c66a7aca70 (gcc-7-branch a week ago)

I guess type interfaces are not supported as of now. What is the status, are you working on that? Is there a way to contribute?

tmeissner
tmeissner

Yeah, we also had a similar case in a module which includes some pipelining functionality with various different (complex) types. We can't get it through GHDL synthesis during formal verification. In the end, separate components were written, with entity ports as the only difference between them.

Dec
7
1 month ago
started
started time in 1 month ago
Dec
6
1 month ago
Nov
29
1 month ago
started
started time in 1 month ago
started
started time in 1 month ago
Nov
8
2 months ago
started
started time in 2 months ago
push

tmeissner push tmeissner/psl_with_ghdl

tmeissner
tmeissner

Add PSL vunit inherit example as ghdl/ghdl#1899 was fixed

  • New example of PSL inherit usage
  • Add example to formal tests
  • Add issue_1899 to issues tests
  • Add inherit to README

commit sha: ed269c05edba2112cdc65c1ceb04eb3c2c384a9c

push time in 2 months ago
Activity icon
issue

tmeissner issue comment ghdl/ghdl

tmeissner
tmeissner

synth: Support PSL vunit inhiterance

Description It would be nice if GHDL can support inheriting of PSL vunits. That would allow more flexible & reusable code with the possibility of defining named sequences & properties and using them in separate vunits with asserts or cover directives.

Currently, I get a parse error when inherit is used:

library ieee;
  use ieee.std_logic_1164.all;

entity sequencer is
  generic (
    seq : string
  );
  port (
    clk  : in  std_logic;
    data : out std_logic
  );
end entity sequencer;

architecture rtl of sequencer is

  signal index : natural := seq'low;

  function to_bit (a : in character) return std_logic is
    variable ret : std_logic;
  begin
    case a is
      when '0' | '_' => ret := '0';
      when '1' | '-' => ret := '1';
      when others    => ret := 'X';
    end case;
    return ret;
  end function to_bit;

begin

  process (clk) is
  begin
    if rising_edge(clk) then
      if (index < seq'high) then
        index <= index + 1;
      end if;
    end if;
  end process;

  data <= to_bit(seq(index));

end architecture rtl;


library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;

entity issue is
  port (
    clk : in std_logic
  );
end entity issue;

architecture psl of issue is

  signal a, b : std_logic;

begin

  --                              012345
  SEQ_A : entity work.sequencer generic map ("--____") port map (clk, a);
  SEQ_B : entity work.sequencer generic map ("_-____") port map (clk, b);

end architecture psl;

vunit issue_1899_vu0 {
  
  -- Using named sequences
  sequence s_a (boolean a) is {a; a};
  sequence s_b (boolean b) is {b};

}

vunit issue_1899_vu1 (issue(psl)) {

  inherit issue_1899_vu0;

  -- All is sensitive to rising edge of clk
  default clock is rising_edge(clk);

  SERE_0_a : assert always s_a(a) |-> s_b(b);

}
$ ghdl --synth --std=08 issue_1899.vhd -e issue > issue_1899._synth.vhd
issue_1899.vhd:78:11:error: '<=' is expected instead of "issue_1899_vu0"
  inherit issue_1899_vu0;

Expected behaviour inherit should work as defined IEEE PSL 1850-2010 section 7.2.4: in PSL LRM 1.1 section 7.2.2 or IEEE PSL 1850-2010 section 7.2.3. I don't think that we need support of vprop and the other restricted subsets of vunit as they don't add any functionality. Also the override mechanisms defined in the IEEE PSL 1850-2010 section 7.2.4 isn't that useful or needed.

AFAIK inherit works like include, while paying attention to scope rules.

How to reproduce? Get this file: https://github.com/tmeissner/psl_with_ghdl/blob/master/issues/issue_1899.vhd

ghdl --synth --std=08 issue_1899.vhd -e issue > issue_1899._synth.vhd
  • OS: Debian Buster
  • Origin:
    • Docker (Image:ghdl/ghdl:bullseye-llvm-9)
tmeissner
tmeissner

My test case works now, so I assume this issue can be closed. Or is there any work left to do? @tgingold

Nov
5
2 months ago
started
started time in 2 months ago
Nov
2
2 months ago
started
started time in 2 months ago
Activity icon
issue

tmeissner issue comment ghdl/ghdl

tmeissner
tmeissner

synth: Support alias declarations in vunit

This PR is intended to add support of alias definitions in PSL vunits.

I'm not sure if the handling of non-object aliases is correct, I assume such are aliases to procedures or entities? So I also added a simple testcase for that:

function incr (a : integer) return integer is
begin
  return a + 1;
end function incr;
vunit verif5 (assert2(behav)) {
 -- Alias to non-object
alias incr_a is incr[integer return integer];
...
assert always cnti_a = incr_a(prev(cnti_a));
}
tmeissner
tmeissner

@tgingold Are the changes in this PR reasonable? If not I could save work and not bump this PR to the current HEAD of master 😉

Oct
28
2 months ago
push

tmeissner push tmeissner/verification_ip

tmeissner
tmeissner

Add more checks, coverage & tests

  • Add functional coverage for block & rmw cycles
  • Add some more checks for WB rules
  • Add tests of block cycles

commit sha: dbfe16af5919679741be4f162a4840cb7a27b70d

push time in 2 months ago
push

tmeissner push tmeissner/verification_ip

tmeissner
tmeissner

README:clarify project focus & intention

commit sha: 90bd0911d3581ded0e62d79cc457da908c0929a8

push time in 2 months ago
Oct
27
3 months ago
Activity icon
created branch
createdAt 2 months ago
Activity icon
created repository
createdAt 2 months ago
Activity icon
issue

tmeissner issue comment ghdl/ghdl

tmeissner
tmeissner

Component binding issue in GHDL, Vivado succeeds.

I first ran into this issue with VUnit, and then traced it back to being a GHDL issue.

In essence, it would appear that having the component interface for an entity (wrapped in a package) in a library separate to the entity definitions leads to component instantiations being unbound.

Expected behaviour In Vivado 2020.1 this is not an issue and the testbench does not assert any error. It may be that Vivado is not adhering to some strict vhdl rules I'm unaware... but I still thought to report this.

How to reproduce? If you download the attached zip folder there are 3 files therein. Place the dut.vhd file in the library dut_lib: ghdl -a --work=dut_lib ./dut.vhd

And place the components_pkg.vhd and tb_top.vhd in the working library: ghdl -a ./components_pkg.vhd ./tb_top.vhd

Then elaborate the testbench: ghdl -e tb_top and you will see the following output: ./tb_top.vhd:27:9:warning: instance "u1" of component "dut_1" is not bound [-Wbinding] ./tb_top.vhd:9:14:warning: (in default configuration of tb_top(tb)) ./tb_top.vhd:36:9:warning: instance "u2" of component "dut_2" is not bound [-Wbinding] ./tb_top.vhd:9:14:warning: (in default configuration of tb_top(tb))

Then run the testbench: ghdl -r tb_top and you'll see the testbench fails as shown below: ./tb_top ./tb_top.vhd:47:13:@5ns:(assertion failure): ISSUE ./tb_top:error: assertion failed in process .tb_top(tb).p_verify ./tb_top:error: simulation failed

Here is the simulation window from Vivado: image Vivado wave output of tb_top

  • OS: Windows 10 WSL
  • Origin: GHDL 1.0.0 (tarball) [Dunoon edition] Compiled with GNAT Version: 9.3.0 llvm code generator

GHDLDebugging.zip

tmeissner
tmeissner

@umarcor I never really used configurations, so maybe you're right.

Activity icon
issue

tmeissner issue comment ghdl/ghdl

tmeissner
tmeissner

Component binding issue in GHDL, Vivado succeeds.

I first ran into this issue with VUnit, and then traced it back to being a GHDL issue.

In essence, it would appear that having the component interface for an entity (wrapped in a package) in a library separate to the entity definitions leads to component instantiations being unbound.

Expected behaviour In Vivado 2020.1 this is not an issue and the testbench does not assert any error. It may be that Vivado is not adhering to some strict vhdl rules I'm unaware... but I still thought to report this.

How to reproduce? If you download the attached zip folder there are 3 files therein. Place the dut.vhd file in the library dut_lib: ghdl -a --work=dut_lib ./dut.vhd

And place the components_pkg.vhd and tb_top.vhd in the working library: ghdl -a ./components_pkg.vhd ./tb_top.vhd

Then elaborate the testbench: ghdl -e tb_top and you will see the following output: ./tb_top.vhd:27:9:warning: instance "u1" of component "dut_1" is not bound [-Wbinding] ./tb_top.vhd:9:14:warning: (in default configuration of tb_top(tb)) ./tb_top.vhd:36:9:warning: instance "u2" of component "dut_2" is not bound [-Wbinding] ./tb_top.vhd:9:14:warning: (in default configuration of tb_top(tb))

Then run the testbench: ghdl -r tb_top and you'll see the testbench fails as shown below: ./tb_top ./tb_top.vhd:47:13:@5ns:(assertion failure): ISSUE ./tb_top:error: assertion failed in process .tb_top(tb).p_verify ./tb_top:error: simulation failed

Here is the simulation window from Vivado: image Vivado wave output of tb_top

  • OS: Windows 10 WSL
  • Origin: GHDL 1.0.0 (tarball) [Dunoon edition] Compiled with GNAT Version: 9.3.0 llvm code generator

GHDLDebugging.zip

tmeissner
tmeissner

Why not use direct instantiation and ditch component declarations anyway?

Simply by using this:

    dut1_gen: if False generate
        u1: entity dut_lib.dut_1
        port map(
            clk     => clk, 
            rst     => rst,
            sig_in  => sig_1,
            sig_out => sig_2
        );