counter clock latency

[Altera_Forum]

I am new to QuartusII tool. 

 My requirement is to design 16 bit up counter and implement STARTIX II device with 1 clock cycle latency at 300Mhz with Quartus II tool.   I written simple code as shown below.   begin    -- behavior describe the counter    process(clock, clear)  begin  if clear = '1' then  Pre_Q <= Pre_Q - Pre_Q;  elsif (clock='1' and clock'event) then  Pre_Q <= Pre_Q + 1;  end if;  end process;    -- concurrent assignment statement  Q <= Pre_Q;   end behv; =======================================  I gave the timing parameters as TSU 3.33 ns and TCO 3.33ns and Max frequency 300Mhz.   After implementation, results shows TCO is 5.071ns (191Mhz).   Can i improve the timing by setting any timing parameters or change RTL code . Even i tried mega function , the results are almost same with RTL code.   Can any one suggest me to improve the timing ?. Is it restriction about STARTIXII devices. I am uising EP2S90F1508C3 device .Suggest me if i need any default settings need to change to improve timing. Any inputs will be appreciated .   Regards,  sam

[Altera_Forum]

For a simple counter, the synthesis tool will infer about the same implementation for a counter described in RTL as you will get for a counter implemented with an instantiated megafunction. 

 The frequency involving tsu and tco at the I/O pins matters only if it is system frequency that you care about. This is the clock rate of a system with data passing between devices that use the same clock signal or related clock signals. The period for system fmax is tco of the driving device plus board delay effects plus tsu of the receiving device. If you just care how fast the counter is running internal to the FPGA, then the I/O timing at the pins is irrelevant for that.  Fully constrain your timing. Quartus needs to know how fast you want the clocks to run and how fast you want the tsu and tco at the device pins to be. I/O timing is best constrained with input delays and output delays. Since you are apparently new to FPGA design, use TimeQuest so that you are learning how to use the best timing analysis tool. The TimeQuest documentation explains how to use set_input_delay and set_output_delay. I suspect you are using the Classic Timing Analyzer with device-wide tsu and tco constraints. That's OK to get started but is not the best way to learn how to do an FPGA design. Besides TimeQuest being the preferred timing analyzer, it is better to constrain the timing on each pin instead of using device-wide constraints. If you constrain each pin individually (even if all pins need the same constraint number), it will be more obvious to someone maintaining the design later that you really did want that requirement on each of those pins.  After you have compiled with all timing paths fully constrained, use "Tools --> Advisors --> Timing Optimization Advisor". Check the recommendations in the "Maximum Frequency (fmax)" category. If you really do care about system fmax including I/O timing, then also check the "I/O Timing (tsu, tco, tpd)" category.  The Advisor's I/O category includes the I/O cell registers that were recommended to you in your other recent thread entitled "Latency and Famx calcualtion [sic]". A register must connect directly to a device pin with no logic between the register and pin in order to place the register in the I/O cell for fastest I/O timing.  The best possible timing depends on the device family, to some extent on the specific device within the family, and on the speed grade. If you have not constrained your design properly yet, the Fitter might not be giving you the best possible timing for the currently selected device. (Later edit: I first wrote this paragraph before I noticed you said that you had constrained the design with fmax and I/O timing requirements. The Fitter probably was already trying to meet those requirements, but still check the Advisor to see what setting changes you should try.)

[Altera_Forum]

Thanks Brad. i will look into your solutions. It really helps your inputs.  

 Regards,  Sam

[Altera_Forum]

I doubt, if the design can work as intended. You can't count on a static input signal 

if clear = '1' then Pre_Q <= Pre_Q - Pre_Q; elsif (clock='1' and clock'event) then If you performed timing analysis on this design, it won't give any meaningful results.  An operational counter is like this: if clear = '1' then Pre_Q <= (others => '0'); elsif (clock='1' and clock'event) then

[Altera_Forum]

--- Quote Start ---  I gave the timing parameters as TSU 3.33 ns and TCO 3.33ns and Max frequency 300Mhz.   After implementation, results shows TCO is 5.071ns (191Mhz).    --- Quote End ---    I think you have a misunderstanding of how Tco is computed and what it represents with respect to overall system timing.   * Tco is the amount of time between a clock signal's arrival at the FPGA and the corresponding transition of an output pin that is driven (directly or indirectly) by a signal clocked by the aforementioned clock signal.   * Fmax is the maximum clock frequency that you can apply without violating the setup requirements of any register in the design.  A 300 MHz Fmax constraint does not imply a 3.33ns Tco constraint, nor does a 3.33ns Tco constraint imply a 300 MHz Fmax constraint. When the tool reports that your design has a Tco of 5.071ns, that doesn't imply Fmax is limited to 191MHz (1/5.071ns). Actually, it doesn't imply anything about Fmax.  As another poster mentioned, Tco timing is (typically) only important when your system is trying to latch the output signal's data to another register sourced by the same clock. Based on your problem specifications, I don't believe you need to specify a Tco constraint (nor a Tsu constraint) in order to satisfy your design requirements.  - Mark