Open Xiretza opened 4 years ago
I understand the reason of the bug, but I am not sure how to fix it. The result can either be a RAM (with a read port that has a fixed address) or an expanded register sets.
I plan to fix it by generating an expanded register set. But your testcase is a little bit too artificial.
Might it be worth supporting some specific attribute, as some vendors do? Typically, options are "all RAM", "all registers", "choose automatically" or "set through attribute". The latter allows to override the general setting for some specific signal/constant.
I'm facing a similar issue when trying to use assertions on RAM content (for formal verification):
library ieee;
use ieee.std_logic_1164.all;
entity ram_assertion is
port (
clk : in std_logic;
data : in std_logic_vector(7 downto 0);
addr : in integer range 0 to 15);
end entity;
architecture rtl of ram_assertion is
type t_ram is array (natural range <>) of std_logic_vector(7 downto 0);
signal ram : t_ram(15 downto 0);
begin
process(clk)
begin
if rising_edge(clk) then
ram(addr) <= data;
end if;
end process;
default clock is rising_edge(clk);
assert always ram(0) = x"00";
end architecture;
This leads to
# yosys -m ghdl
Yosys 0.9+3582 (git sha1 8fbb5171, clang 7.0.1-8 -fPIC -Os)
yosys> ghdl --std=08 -i ram_assertion.vhd -e ram_assertion
1. Executing GHDL.
Importing module ram_assertion.
ERROR: wire not found for $posedge
ERROR: Assert `GetSize(ports) >= it.second->port_id' failed in kernel/rtlil.cc:1613.
An option to implement the RAM as registers would be a nice workaround.
@efykse Sure that the ram array isn't optimized away? I don't know exactly if an assertion count as something similar like an output, but without the assert the ram would be a write-only memory, which is optimized away in synthesis tools I know.
As an example, a design of mine with an array as register file can be successfully compiled & proven: formal_hw_verification: vai_reg. One of the differences is that there is logic which depends on the content of the register file.
Yes, good point @tmeissner. But the error is still the same if I add an output that depends on the ram contents (please see code below).
In your example, I see that you have a reset on the contents of s_register. If I add a reset of the RAM contents (commented-out below), I get no errors. The reset probably prevents the synthesis of a dedicated RAM, preventing the error from occuring.
library ieee;
use ieee.std_logic_1164.all;
entity ram_assertion is
port (
clk : in std_logic;
sreset : in std_logic;
data_in : in std_logic_vector(7 downto 0);
addr : in integer range 0 to 15;
data_out : out std_logic_vector(7 downto 0));
end entity;
architecture rtl of ram_assertion is
type t_ram is array (natural range <>) of std_logic_vector(7 downto 0);
signal ram : t_ram(15 downto 0);
begin
process(clk)
begin
if rising_edge(clk) then
ram(addr) <= data_in;
data_out <= ram(addr);
-- if sreset then
-- ram <= (others => (others => '0'));
-- end if;
end if;
end process;
default clock is rising_edge(clk);
assert always ram(0) = x"00";
end architecture;
@efykse Yes, that could be the case with the reset. For formal, you don't want a dedicated BRAM, as you can't really verify it's content anymore.
However, even when I remove the reset in my vai_reg design, the compilation & verifiying works. So, it also depends on other things like write or read logic implementation.
Yes, I agree. Ideally any assertions on the RAM content should prevent its inference as a RAM, the same way that the reset does.
I found a workaround by invoking GHDL with the "-dm" option to prevent inference of memories.
This is still an issue with 8b3e740 - here's a less artificial test case, since that was a concern:
library ieee;
use ieee.std_logic_1164.all,
ieee.numeric_std.all;
entity ent is
port (
clk : in std_logic;
set : in std_logic;
index : in std_logic_vector(1 downto 0);
val : in std_logic_vector(7 downto 0);
out0 : out std_logic_vector(7 downto 0);
out1 : out std_logic_vector(7 downto 0);
out2 : out std_logic_vector(7 downto 0);
out3 : out std_logic_vector(7 downto 0)
);
end entity;
architecture a of ent is
type arr_t is array(3 downto 0) of std_logic_vector(7 downto 0);
signal arr : arr_t;
begin
process(clk)
begin
if rising_edge(clk) then
if set = '1' then
arr(to_integer(unsigned(index))) <= val;
end if;
end if;
end process;
out0 <= arr(0);
out1 <= arr(1);
out2 <= arr(2);
out3 <= arr(3);
end architecture;
Without -dm
(which just isn't an option for larger designs):
$ yosys -m ghdl -p 'ghdl ent.vhd -e'
[...]
Yosys 0.9+3830 (git sha1 b00e55a16, gcc 10.2.0 -march=x86-64 -mtune=generic -O2 -fno-plt -fvar-tracking-assignments -fdebug-prefix-map=/build/yosys-git/src=/usr/src/debug -fPIC -Os)
[...]
1. Executing GHDL.
note: top entity is "ent"
Importing module ent.
ERROR: wire not found for $posedge
I ran into this problem today as well, or at least it seems so, I haven't been able to pinpoint the problem in our code yet but the 'wire not found on $posedge' error appears and adding -dm seems to get the design loaded properly. The problem is though that it explodes then without the RAM inference...
This is running with today's build of https://github.com/YosysHQ/fpga-toolchain
I am still having this issue. The -dm option does not let yosys synthesis my vhdl design. could you please assist?
Please, open a different issue with a reproducer, as this one is fixed.
The following file:
When run through yosys, produces the following error:
Looking at the output of
ghdl --synth
, it's suspicious that not a single process is generated, instead everything is represented with latch semantics (sig <= sig when not set else next
):Not entirely sure if the plugin should support this kind of construct, or if GHDL shouldn't be generating it in the first place.