Another case of "wire not found for $posedge" - related to async resets?

[robinsonb5]

I'm not sure whether or not this is related to the existing issues which mention this error message, but I have a testcase which I hope will be useful.

I'm trying to build my CPU design (https://github.com/robinsonb5/EightThirtyTwo) using oss-cad-suite which includes the gdhl-yosys-plugin. (I used GHDL extensively for simulation when developing the CPU - I must say a huge "thank you" for this wonderful tool.)

I'm getting the "ERROR: wire not found for $posedge" message when calling the ghdl plugin on eightthirtytwo_cpu.vhd from within yosys.

I have an async reset which initialises certain signals, some of which are within records. If I remove all resets relating to signals within the thread and thread2 records, the error message goes away. If I change the reset to be synchronous the error goes away.

I've removed as much as I can from the CPU design while still triggering the error message, and got it down to the following minimal testcase:

-- Just enough of the ALU definition to demonstrate the problem

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

entity eightthirtytwo_alu is
port(
	clk : in std_logic;
	reset_n : in std_logic;
	forward_q2tod1 : in std_logic := '0'
);
end entity;

architecture rtl of eightthirtytwo_alu is
begin
end architecture;

-- A minimal excerpt from the CPU, just enough to demonstrate the problem.

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

entity eightthirtytwo_cpu is
port(
	clk : in std_logic;
	reset_n : in std_logic
);
end entity;

architecture behavoural of eightthirtytwo_cpu is

constant e32_alu_maxbit : integer := 3;
constant e32_reg_maxbit : integer := 1;
constant e32_ex_maxbit : integer := 11;
subtype e32_ex is std_logic_vector(e32_ex_maxbit downto 0);
constant e32_ex_bubble : std_logic_vector(e32_ex_maxbit downto 0) := "000000000000";

type e32_thread is record
	f_alu_reg2 : std_logic_vector(e32_reg_maxbit downto 0);
	f_ex_op : std_logic_vector(e32_ex_maxbit downto 0);
	d_alu_op : std_logic_vector(e32_alu_maxbit downto 0);
	d_alu_reg2 : std_logic_vector(e32_reg_maxbit downto 0);
	d_ex_op : e32_ex;
	hazard : std_logic;
end record;

signal thread : e32_thread;

-- Execute stage signals:
signal alu_forward_q2tod1_d : std_logic;
signal alu_forward_q2tod1 : std_logic :='0';


begin

alu : entity work.eightthirtytwo_alu
port map(
	clk => clk,
	reset_n => reset_n,

	forward_q2tod1 => alu_forward_q2tod1_d
);

process(clk,reset_n)
begin
	if reset_n='0' then
		thread.d_ex_op<=e32_ex_bubble;
	elsif rising_edge(clk) then
		
		if thread.hazard='0' then
			alu_forward_q2tod1_d<=alu_forward_q2tod1;
			alu_forward_q2tod1<='0';
			thread.d_alu_reg2<=thread.f_alu_reg2;	
			thread.d_ex_op<=thread.f_ex_op;
		end if;
	
	end if;

end process;

end architecture;

[robinsonb5]

A bit more information, for the benefit of anyone else looking for a solution to this: it appears to be related to signals which aren't covered by the reset. Including thread.d_alu_reg2 within the reset is sufficient to fix the error in this example.

[janschiefer]

Can you provide an example on how you fixed his?

[robinsonb5]

Can you provide an example on how you fixed his?

In the example above I believe in the problem is related to the async reset which covers only one member of the record type. Adding an async reset for thread.d_alu_reg2 makes the error go away.
Strangely, the error also goes away if I move the d_ex_op member above the other members in the record.
(Note that I've only verified that these workarounds make the error go away - I haven't checked that the resulting output is correct.)