Hi all,
this is probably a question to Rysc (as he's the author of the TimeQuest User Guide) but of course any helpful answer from anybody is more than welcome as well.
Discontent with my past understanding of timing constraints (I was just fiddling with them to the extend of getting my designs running but wouldn't really claim I've understood them), I decided to work through the TimeQuest User Guide. I guess I know have lot more thorough understanding regarding them (@Rysc: thank you for enlightment, btw., really appreciated).
Then I decided to test my newly acquired knowledge: set up a (really simple) design and started to constrain it by the book. My toplevel entity (stripped down from a real project) looks like this:
Code:
entity simple is
port
(
CLK_MAIN : in std_logic;
RSTO_MCFn : in std_logic;
-- FlexBus signals
FB_AD : inout std_logic_vector(31 downto 0);
FB_ALE : in std_logic;
FB_SIZE : in std_logic_vector(1 downto 0);
FB_CSn : in std_logic_vector(3 downto 1);
FB_BURSTn : in std_logic;
FB_OEn,
FB_WRn : in std_logic;
FB_TAn : out std_logic
);
end entity simple;
(if it matters, this is a Cyclone III attached to a 33MHz FreeScale FlexBus interface)
created clocks and virtual clocks:
Code:
set period [expr roundto(1000000.0 / 33000.0, 3)]
create_clock -period $period -name CLK_MAIN [get_ports {CLK_MAIN}]
create_clock -period $period -name virt_clk_main
defined ports:
Code:
set flexbus_in_ports
[list FB_AD[*] FB_ALE FB_OEn FB_WRn]
set flexbus_out_ports
[list FB_AD[*] FB_TAn]
(FB_AD is an inout port, i.e. the multiplexed address/data bus of the FlexBus, therefore it appears in both lists)
and constrained them (according to the guide):
Code:
foreach in_port $flexbus_in_ports {
set_input_delay -clock virt_clk_main -min -0 $in_port
set_input_delay -clock virt_clk_main -max 0 $in_port
}
foreach out_port $flexbus_out_ports {
set_output_delay -clock virt_clk_main -min -0 $out_port
set_output_delay -clock virt_clk_main -max 0 $out_port
}
So far, so good. Works as expected up to this point (I'm well aware that I'm not finished and still need to add reasonable outside timing consumes).
But there is one thing that concerns me: as soon as I constrain the inout bus both directions, I get a ridiculously low restricted Fmax:
Code:
+-----------------------------------------------------------------------------------------------+
; Slow 1200mV 85C Model Fmax Summary ;
+------------+-----------------+---------------+------------------------------------------------+
; Fmax ; Restricted Fmax ; Clock Name ; Note ;
+------------+-----------------+---------------+------------------------------------------------+
; 61.66 MHz ; 5.81 MHz ; virt_clk_main ; limit due to minimum period restriction (tmin) ;
; 141.96 MHz ; 141.96 MHz ; CLK_MAIN ; ;
+------------+-----------------+---------------+------------------------------------------------+
and have no idea where this is coming from. For now, I tell TimeQuest that the outside world works in zero time and doesn't require any timing margin. Even if I replace the min and max delays with more "real" numbers, restricted Fmax stays at (exactly) 5.81 MHz.
Does anyone know where this is coming from or what I'm supposed to do with that? Is TimeQuest assuming a toggle rate for a "virtual register" outside the FPGA?
I might have overlooked something in the TimeQuest User Guide but didn't find anything specific on inout signals.
For now, I helped myself with a second virtual clock (one for in and one for out). Once I do that, the numbers look a lot more reasonable. But is that the right way to handle this case?
Thanks in advance for any enlightening answers.
