Occasional Contributor
Super ContributorI think as long as you are using edges instead of logic levels for these control signals, the tool will still look at these as clocks.
Is there a reason why you must do this and can't just turn these processes into combinatorial logic instead of registers?
Occasional ContributorThis is a legacy design and I am using the same.
I anyways gave a try by changing the code as below:
PROCESS ( ale, adbus )
BEGIN
IF ( ale = '1' ) THEN
address <= adbus;
END IF ;
END PROCESS;
PROCESS ( wrn, clearn, adbus )
BEGIN
IF clearn = '0' THEN
data<= "0000000000000000" ;
ELSIF ( wrn = '0' ) THEN
data <= adbus( 15 DOWNTO 0 );
END IF ;
END PROCESS
Surprisingly, timing analyzer still shows that the clocks ALE and WRN are unconstrained.
I see in the RTL viewer that ALE and WRN are used as the latch enable signals which concurs with the code above. I do not understand why the timing analyzer still complains that these are unconstrained clocks.
Is it critical to proceed with these timing errors? Can I go back to existing legacy solution where edges of ALE and WRN are used?
In any case, how can I solve the unconstrained clock warning by the timing analyzer?
Thank you very much!
