Forum Discussion
Timing analysis error on Asynchronous control signals
Hello,
In my design, there is an asynchronous bus between FPGA and Microcontroller (Master). FPGA uses the edges on the signals WRN (Write active) and ALE (Address Enable) to classify if the signals on the bus indicate Data or Address .
As the logic is checking for the edges on WRN and ALE in a process, Quartus thinks they are clocks and gives timing errors: "WRN and ALE are clocks and they are not constrained".
How do I solve this issue having known that WRN and ALE are not clocks?
23 Replies
- SyafieqS
Super Contributor
Hi Naveen,
"In any case, how can I solve the unconstrained clock warning by the timing analyzer"
- Assuming I understand your question, have you able to constrain all the clocks in sdc? This should reflect in Timing Analyzer
- NShan12
Occasional Contributor
Hi,
Yes, all the clocks (on IO ports, generated clocks, virtual clocks etc.) are constrained in the SDC file. Since WRN and ALE are not clocks only false path constraints exist on them.
- sstrell
Super Contributor
I 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?
- NShan12
Occasional Contributor
This 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!
- sstrell
Super Contributor
You're coding them like clocks so the tool will think they're clocks.
What do your false path constraints look like?
- NShan12
Occasional Contributor
The false path constraints are as follows:
set_false_path -from [get_ports WRN]
set_false_path -from [get_ports ALE]
- sstrell
Super Contributor
Set the signals as false paths.
- NShan12
Occasional Contributor
Yes, I had set false paths on them. But Timing analyzer report still shows these two signals as unconstrained clocks in the clock status summary.
My Code:
--somewhere in the architecture
PROCESS ( ale, adbus )
BEGIN
IF ( ale'event AND ale = '0' ) THEN
address <= adbus;
END IF ;
END PROCESS;PROCESS ( wrn, clearn, adbus )
BEGIN
IF clearn = '0' THEN
data<= "0000000000000000" ;
ELSIF ( wrn'event AND wrn = '1' ) THEN
data <= adbus( 15 DOWNTO 0 );
END IF ;END PROCESS
I am using the edges of ALE and WRN to identify if it is address or data on the adbus, and the tool thinks these are clocks.
There are also warnings:
Warning (332060): Node: wrn was determined to be a clock but was found without an associated clock assignment.
Warning (332060): Node: ale was determined to be a clock but was found without an associated clock assignment.