Setup time constraints

[Altera_Forum]

Hi all, 

I am currently doing some maintanence on a Flex 10K design which was done many years ago. The deisgn is too implement a VME bus controller which replaces the VIC068A chip from cypress which was taken of the market some time ago. I need to make sure the design functions at 64 MHz as opposed to the 50 MHz at which it currently runs.   Anyway I´ve just started and I´ve seen many timing warnings (at 50 MHz)reported in the classic timing analyzer (clock setup, tco, tsu). The design is a real nightmare to understand, as its way to complicated, without comments and poorly coded. Many of the timing warnings are are explained by the poor coding but the original designer has also placed 1000´s of timing constraints, many of which were set too aggressively it seems and cannot be met by Quartus. I have not been given permission to redo the design so I´m stuck with trying to improve the current design.   Initially I am concered with the Tsu warnings which appear on input pins. These warnings are due to contraints put in place by the original designer (other company) too aggresively. I am thinking that it is not nessesery to have these constraints and that I can safely remove them. As the interface is asynchrous and each signal that is read in from the outside is passed through a couple of flip flops. Therefore if the nessesery pre cautions are taken to avoid metastability, it should be ok to remove these containts?   I understand what setup time is, but what I do not understand is how it can change, and why it would have been nessesery to place these constraints in the first place. I see warnings which have an actual tsu of 11.700 ns.    -7.700 ns(slack) 4.000 ns (Required) 11.700 ns (actual)  a2] (From) ic068:vic068_inst_1|vme_if:vme_if_inst_1|vme_in:vme_in_inst_1|i_addr_cntr[2] (To) clk64m (To clock)   11.700 ns seems like a real long time to me? and some are up at 17.2 ns.   If i change parts of the code (or clock speed) it also affecs the setup up time. Could someone please explain to me why this is. At the moment I can´t get my head around it. I understood that Tsu meant that the signal had to be present at the input pin a specified amount of time before a clk edge but I think there are also some other basics that I haven´t grasped. I be grateful if someone could take a minute to explain why I see what i have described above.   Many thanks for your help.

[Altera_Forum]

Have you thought about just throwing out all the timing constraints and coming up with your own? Or maybe you are afraid of the stack of cards all falling apart. Wouldn't take more than a couple of days to just peel out all those constraints and start over from a very basic timing point of view. Having never done a VME bus controller though, it's just a "thinking outside the box" thing.

[Altera_Forum]

Hi Ardni 

   --- Quote Start ---  I understood that Tsu meant that the signal had to be present at the input pin a specified amount of time before a clk edge...  --- Quote End ---    Basically you are right here except that the setup time is for the register - i.e. the time that the input to the register has to be stable for before a clock edge. If you assume that the signal and clk edge arrive at FPGA pins together then the setup time is the routing delay inside the chip and propagation delay of any combinatorial logic in front of the register. If you make any change to the chip then it will affect the timing to some degree or other - for some designs any change or recompilation will be a real pain if you are really tight on resources and performance; for other designs you could pretty much forget about it.    --- Quote Start ---  I am thinking that it is not nessesery to have these constraints and that I can safely remove them. As the interface is asynchrous and each signal that is read in from the outside is passed through a couple of flip flops.  --- Quote End ---    I would believe this to be correct - if the signals are not related to any clock then constraining them in this way would appear to be meaningless.  Have a look at some of the Quartus options:   compilation for speed or area automatically add logic / registers - may help increase the speed use fast input registers (uses the registers in the I/O cell where it can) fast output registers (as above but output)  I'm not sure how many of these would apply to the FLEX devices (I've not used them myself) but give them a whirl and dig around and see if you can find anything else in Quartus that might help - there are many options and constraints, most of which you don't realise are there until you need them.  Good luck

[Altera_Forum]

Thanks for the explanation Batfink. 

So would it be true to say (assuming the clk and data arrive at the pin at the same point in time) that the Tsu would be the difference in the routing and propagation delays between the the clock and data plus the actual setup up time that would be required?  So by placing a Tsu constraint it is actually affecting the routing delays to the register pins? (Its probably what does always but I never realised)   I'm going to delete these constaints but just one more thing I'm curious about:  As quartus does not know when the clock or data wil arrive at the input pins. Does quartus try and match the propagation and rounting delays of the clock and data inputs (or any input pin for that matter), or could one input pin have a completely different delay from the nexy?   So is it the reponsibility of the designer to ensure that a constraint is put in place if the data and clock are presented to the input pins too close together and the setup time is not met?  Many thanks again for the help.

[Altera_Forum]

--- Quote Start ---  Tsu would be the difference in the routing and propagation delays between the the clock and data plus the actual setup up time that would be required?  --- Quote End ---    Hopefully someone will correct me if I'm wrong but I think Quartus looks after the internal setup time of the register itself so you can forget about it (i.e. assume it's zero)    --- Quote Start ---  So by placing a Tsu constraint it is actually affecting the routing delays to the register pins?   --- Quote End ---    Pretty much yes - Quartus is placing logic and routing connections in a way that will try and meet those timing requirements - setting the requirement doesn't guarantee that Quartus will meet the timing constraints but it does make it try and at least tell you if it can't.    --- Quote Start ---  As quartus does not know when the clock or data wil arrive at the input pins. Does quartus try and match the propagation and rounting delays of the clock and data inputs (or any input pin for that matter), or could one input pin have a completely different delay from the nexy?  --- Quote End ---    The clock should be routed along dedicated global clock paths internally with powerful buffers so that it can reach all parts of the chip with very little skew. Quaruts doesn't try and match the routing delays between clock and data - it just tries to meet your setup requirement. What happens externally is part of your analysis to calulate what those setup times should be. If, for example, your data has a long windy track on the PCB and a much greater delay than the clock then this will mean that you need to set a smaller setup time in Quartus.   Really to work out your setup times you need to know the clock to output time of the transmitting device, the routing delay (time of flight) and the clock period. You could have a decent guess at your PCB routing delays - they might be pretty small unless you have long tracks - have an interweb search engine search for signal transmission speeds in PCBS (or something similar) - it depends on the dielectric material (e.g. FR4) of the PCB mind. It's been a while since I've done this sort of thing so I can't give you a figure off the top of my head.  Good luck  batfink

[Altera_Forum]

I have removed the Tsu constarints that the original designer placed, but still Quartus produces 56 Tsu warnings from inputs pins.  

 For each warning Quartus informs me that there is a required Tsu of 10 ns on each one, but there is no such constraint. However there are other constraints in place (Tco and multicycle) which I haven´t gotten to as of yet. Is it possible that a Tco constraint would also impose setup time constraint and that this could be the cause?   Many thanks for any help.

[Altera_Forum]

See if the default setup time has been set: Assignments>>Settings>>Classic Timing Analyser Settings (assuming your man has used the Classic Timing Analyser). 

 If memory serves me correctly then you can also set timing constraints from your source code.  The tco shouldn't produce a setup violation - I'm pretty sure that is unrelated.  Have a browse through the qsf file and see if you can see the tsu requirement - you can always hack this file manually (do it without Quartus running though).

[Altera_Forum]

Cheers Batfink, Good spot. A default setup time of 10 ns was specified. 

I don´t know how long I would have been looking until I found it otherwise.   Thanks again.

[Altera_Forum]

no worries