Results 1 to 2 of 2

Thread: TimeQuest: constraining inout ports

  1. #1
    Join Date
    Aug 2016
    Posts
    12
    Rep Power
    1

    Default TimeQuest: constraining inout ports

    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;
            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:

    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.

    [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]
    Last edited by mfro; June 11th, 2018 at 09:32 AM.

  2. #2
    Join Date
    Aug 2016
    Posts
    12
    Rep Power
    1

    Default Re: TimeQuest: constraining inout ports

    anyone?

    .

Similar Threads

  1. [TimeQuest] constraining block-RAM
    By Szymo in forum Quartus II and EDA Tools Discussion
    Replies: 3
    Last Post: January 24th, 2012, 05:23 AM
  2. How can I set 16 inout ports in MAX3128 device?
    By dongshusong in forum FPGA, Hardcopy, and CPLD Discussion
    Replies: 2
    Last Post: September 27th, 2010, 09:29 PM
  3. inout ports for multiple modules
    By matthew.db in forum FPGA, Hardcopy, and CPLD Discussion
    Replies: 2
    Last Post: January 21st, 2010, 08:30 AM
  4. Constraining PLL in TimeQuest
    By wat_arg in forum General Altera Discussion
    Replies: 5
    Last Post: May 20th, 2009, 05:08 AM
  5. Constraining inout port
    By Eddie in forum General Altera Discussion
    Replies: 1
    Last Post: March 24th, 2009, 08:01 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •