Fmax and Restricted Max

[Altera_Forum]

Hello, 

 In the Time Quest, the Fmax for my design is 303 MHz , but the Restricted Fmax is 250 MHz with a Note that says 'limit due to minimum period restriction (max I/O toggle rate)' . The clock frequency = 333 MHz.  Does this mean that I need to operate the design not beyond 250 MHz or will 303 MHz work too?  Thanks

[Altera_Forum]

--- Quote Start ---  Hello,  In the Time Quest, the Fmax for my design is 303 MHz , but the Restricted Fmax is 250 MHz with a Note that says 'limit due to minimum period restriction (max I/O toggle rate)' . The clock frequency = 333 MHz.  Does this mean that I need to operate the design not beyond 250 MHz or will 303 MHz work too?  Thanks  --- Quote End ---    I am afraid yes the ultimate fmax is that figure of the most restrictive case.

[Altera_Forum]

The restricted fmax is usually due to the part you are using.

[Altera_Forum]

--- Quote Start ---  The restricted fmax is usually due to the part you are using.  --- Quote End ---     Tricky.. I did not understand your reply. Can you please explain what it means?

[Altera_Forum]

There are different speed grades of chip, Like C1,2,3,4 etc. These will have restricted FMax because they are not as strict on testing the dies as the number increases. So C1 will have a higher restricted FMax than a C5

[Altera_Forum]

I have a few more questions.  

1) What exactly is the difference between a netlist and a timing netlist?   2) How is the Fmax and Restricted Fmax calculated? One of the report says: "Restricted fmax considers hold timing in addition to setup timing, as well as minimum pulse and minimum period restrictions. " But nothing is said about the unrestricted Fmax. Does it mean that unrestricted Fmax considers only setup time?  3) Now the restriction is only due to the width of the clock cycle and not due to the "delay" of the circuit. Will it make sense to consider Fmax and NOT restricted Fmax if we take only propagation delay into consideration?  Thank you.

[Altera_Forum]

1. A netlist is literally a list of nets. It could be part of a design so it may fill in a hole (black box) in the design so that it is added on during the fit stage. A timing netlist contains timing information which allows it to be simulated. 

 2and 3. The important thing is that you are limited to the lower of the 2 values. Do you have a specific problem? Do you have a lot of async logic?

[Altera_Forum]

Thank you for the reply Tricky.  

 No, I don't have any specific problem. I was wondering if the unrestricted Fmax can be considered so that everything is measured using just the propagation delay.   I need to report frequency values for my research where the design is not specific to Cyclone IV (which I am working on currently) or any FPGA. So using the Restricted Fmax which restricts the frequency because of pulse width limitation might not give true delay dependent value. What do you think about this?

[Altera_Forum]

--- Quote Start ---   1) What exactly is the difference between a netlist and a timing netlist?    --- Quote End ---    Adding further to notes by Tricky, Tools produce from your source code(or schematic entry) some other language-like text code called netlist that just describes the connections. The connections may be at logic level (i.e. your rtl as mapped to generic logic, no details of device mapping), this is rtl netlist. Or it is for connections after P&R plus delay information(which could be separate) and this is timing netlist(e.g vho). netlists may also be supported for initial design entry along with other source code. An encrypted netlist is favoured by those who want to make money. Other netlist types include edif, atom, and xilinx has ngc...etc.    --- Quote Start ---   2) How is the Fmax and Restricted Fmax calculated? One of the report says: "Restricted fmax considers hold timing in addition to setup timing, as well as minimum pulse and minimum period restrictions. " But nothing is said about the unrestricted Fmax. Does it mean that unrestricted Fmax considers only setup time?  --- Quote End ---    The classic fmax was and is still calculated as follows: minimum clock period = reg tSU + reg tCO + reg to reg data delay - reg to reg clock delay fmax = 1/minimum clock period  note all above are fixed intrinsically per device path.  restricted fmax is relatively new concept and resulted from very fast designs in which above fmax is achieved but further restrictions arise due to minimum pulse/period and hold violation and io toggle rate.  The restriction by hold violation is interesting and undocumented and I believe it is due to the case when clock period is so short that tCO of a launch register directly violates tH at previous latch edge at latching register even though clock/data delay is not to blame.    --- Quote Start ---   3) Now the restriction is only due to the width of the clock cycle and not due to the "delay" of the circuit. Will it make sense to consider Fmax and NOT restricted Fmax if we take only propagation delay into consideration?  Thank you.  --- Quote End ---    For a given device, the worst fmax applies. But if you are thinking of a generic design that reports speed only on tSU/tCO and delay basis then you can report fmax only.

[Altera_Forum]

Restricted Fmax comes into play when using things like DSP and memory blocks. the timing paths inside of these blocks are not explicitly calculated using the formula that kaz lists above due to their complicated structure. instead, the datasheet specs of these blocks in their various modes are programmed into Quartus and will show up as Restricted Fmax 

 as others have pointed out, you'll need to look at the lower of these two numbers to see how fast your design will actually run. better yet, take a look at the Top Failing Paths or similar

[Altera_Forum]

--- Quote Start ---  Restricted Fmax comes into play when using things like DSP and memory blocks. the timing paths inside of these blocks are not explicitly calculated using the formula that kaz lists above due to their complicated structure. instead, the datasheet specs of these blocks in their various modes are programmed into Quartus and will show up as Restricted Fmax  as others have pointed out, you'll need to look at the lower of these two numbers to see how fast your design will actually run. better yet, take a look at the Top Failing Paths or similar  --- Quote End ---    Just got this answer from Altera regarding restricted fmax due to hold check:  "Usually Fmax is not limited by hold checks as they are generally same edge relationships and therefore independent of frequency. If you have an inverted clock transfer of a multicycle transfer the hold relationship is no longer same edge but changes with frequency. If the hold check limits the Fmax more than the setup check then you will see “limit due to hold check” as the reason."  But in a project I noted fmax was 300 plus while restricetd fmax was below 200 due to hold check yet the design did not tell where is that restriction and all hold slack was positive with regard to fmax (not restricted fmax).

[Altera_Forum]

wow, thanks for the tip

[Altera_Forum]

--- Quote Start ---  wow, thanks for the tip  --- Quote End ---    I tried to visualise the case given by Altera and I believe it is not straight forward. It seems the only case for hold check to limit fmax. I believe they mean the case when launch and latch registers are both sampling on same edge (rising edge,or falling edge) but the clock is inverted. This means there would be some half period delay of the latch clock relative to launch clock and the tool will need to be given instruction not to check current launch with next latch(for setup) as it is too restrictive, instead a multicycle of 2 is to be applied by user for tool's sake(this is not a true two clock multicycle). Thus the data launched may hit latch hold window or latch setup window and as such either may restrict fmax.  I am still puzzled why the tool does not give any red warnings on hold slack in our case, neither it tells where the problem lives.