Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
15996 Discussions

TimeQuest: constraining inout ports

Honored Contributor II

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: 


entity simple is port ( CLK_MAIN : in std_logic; RESETn : 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, the architecture is just a single 32 bit register that can be read and written through the FlexBus interface) 


created clocks and virtual clocks: 


set period create_clock -period $period -name CLK_MAIN create_clock -period $period -name virt_clk_main  


defined ports: 


set flexbus_in_ports FB_ALE FB_OEn FB_WRn] set flexbus_out_ports 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): 


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: 


+-----------------------------------------------------------------------------------------------+ ; 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. 


[edit: forgot to mention the design works fine with 33 MHz even if TimeQuest says it doesn't; also there is nothing showing up "red" in timing reports]
0 Kudos
1 Reply
Honored Contributor II