[SOLVED] XST synthesis without user constraints

[syn_rocks]

Hi,
I'm new to FPGA based designs and using XST on Xilinx ISE to synthesize my designs.
Xilinx reports a maximum freqency for the design when synthesis is done without using ucf or xcf.
How reliable is the freqency reported? And does the tool check all timing paths and then report a maximum freqency?
If it takes all paths in to consideration and then report a maximum possible freqency then is there any advantage of explicitly defining clocks via ucf/xcf?

 

[ads-ee]

Xilinx reports a maximum freqency for the design when synthesis is done without using ucf or xcf.
How reliable is the freqency reported? And does the tool check all timing paths and then report a maximum freqency?

That is the timing that you have given the lack of constraints, so yes it has been fully analyzed.

If it takes all paths in to consideration and then report a maximum possible freqency then is there any advantage of explicitly defining clocks via ucf/xcf?

This shows how new you are to FPGA design.

Say you are told to meet a 450 MHz clock in an FPGA to get there you need to heavily pipeline your design and use a constraint file. If you don't the maximum frequency without the constraints will likely be a few hundred MHz as the synthesis tools and place and route tools will take the easiest path to complete the design.

So using an analogy, if you want to travel from point A to point B on a horse.
1. let the horse decide where it's going.
2. guide the horse with reins telling it where to go.
Now 1. might get you there if there is a canyon between point A and B that is only slightly wider than the horse (so it can't turn around), or 2. use reins and tell the horse to go from A to B even if there is a wide open area between A and B.

If you want predictable timing and lack of variability and your frequency is as good as you can get without constraints, then only use PLDs (horse canyons ;-)). FPGAs are more like ASICs the timing can be all over the place unless you constrain the design with a UCF, XCF, SDF, XDF, etc.

 

[syn_rocks]

That is the timing that you have given the lack of constraints, so yes it has been fully analyzed.

Okay, so if my design has different clocks, one being a generated clock with respect to another, can XST time such paths without clock constraints? Would it use a single cycle timing on these paths and generate a max freq?
More generally, if there is transfer of data from one clock domain to another, how would XST understand and time such paths?

 

[ads-ee]

It just reports what the timing is, including any clock paths between synchronous output clocks generated from a PLL/MMCM/DCM. What I mean by synchronous is that the slower clock's rising edges all line up with the faster clock's edges, and in this case the timing between clock domains uses the closest edges between domains, so the timing between domains is the same as the faster clock's period regardless of which way you cross the domains (i.e. it uses single cycle paths between the synchronous domains).

If the tools say the design can run at some frequency, then you can add a constraint at that frequency and run timing analysis on the design and see for yourself that it passes. (What is up with students now days they don't seem to have any gumption to experiment on their own to develop a better understanding of something? Or is it that the smart phone generation wants everything served to them via twitter and facebook?. Maybe it's just a lack of focus due to being online all the time and having short attention spans :thumbsdown

If you want to have the design run at a specific clock frequency CONSTRAIN the design and stop trying to come up with a justification to avoid doing that. If all your design will use a clock below the XXX MHz number that comes out of tools then fine, but what happens when you need to add some other function and now the tools report your design only runs at 131 MHz when it used to run at 331 MHz are you going to remove your 300 MHz clock oscillator and replace it with a 100 MHz oscillator?

 

[mrflibble]

First off, I admire your sense of optimism.

Okay, so if my design has different clocks, one being a generated clock with respect to another, can XST time such paths without clock constraints?

Can? Sure, it will happily do so. Will it do it's thing precisely such that it magically guesses your timing requirement? Not very likely.

Would it use a single cycle timing on these paths and generate a max freq?

It will most certainly generate a max freq number. FYI: it will always generate a max freq number, no matter what shit you feed it. Translation: max freq is a nice distraction to give you a false sense of "gee, this is a useful metric" while in fact you are better off forgetting that number even exists. That max freq is a very VERY rough indicator, period. Nothing more, possibly less. That number is so useless I never even look at it, because who cares? I only care how a design meets timing on the constraints I specifically specified, because that is really the only way to properly tell the tools (ISE) your design intent. Using no constraints and just hoping for the best is highly optimistic at best, and silly at worst.

More generally, if there is transfer of data from one clock domain to another, how would XST understand and time such paths?

It would make stuff up, and fsck up your design. Free of charge.

I realize that if you just started with fpga's this may be a "Noooo, not more manuals" moment, but you really should give the Timing Closure User Guide a quick look. For older versions of ISE that document was called "Timing Constraints User Guide", and it's always been UG612 document number AFAIK. And you really also want to read a bit in the regular Constraints Guide, even if only to get a rough idea.

I promise, you will waste more time guessing "WTF is ISE doing" when you choose the "no constraints" way of working. Reading those two documents and actually using some constraints will be cheaper in terms of time spent and definitely be cheaper in terms of sanity/hair loss.