Honored ContributorI am studing using TimeQuest now. When I follow the "TimeQuest Analyzer Quick Start Tutorial" instruction, Analysis & Synthesis a project, then open TimeQuest, created a post-map timing netlist, next update timing netlist. It's strange that I never wrote any constrains, but the software automatically created some clocks. And I can't overwrite this clocks anymore. Why this happen?
Thanks!
Honored ContributorIt does that so at least "something" can be looked at. Otherwise it's kind of useless, and that aggravated users who were used to the old Classic Timing Analyzer which did a lot of things by default. You don't want to "overwrite" them. Create an .sdc file and add constraints. To use it, reset_design, which gets the netlist to write after being created before any constraints were added. Read in your .sdc rather than the default.
Honored ContributorYes, you are right. What I should do is create a new .sdc and add my constrains.
Thanks!Honored ContributorCreate a new .sdc from TimeQuest. (It's just a text file). Add:
1) Add the following for each clock coming into the port. Naturally, change the period value, name and I/O port name to match what your design. create_clock -period 10.0 -name clk100 [get_ports clk100] 2) derive_pll_clocks 3) If 65nm or newer family, add: derive_clock_uncertainty That's a good start. When you're ready, add a set_clock_groups constraint to show which clocks are not related(by default all clocks are related, and so paths between clocks with weird frequnecies like 6.666ns to an 8ns clock won't be analyzed correctly). When editing, just keep editing the .sdc, then saving, going into TimeQuest and click on: Reset Design Report All Summaries keep repeating until you get what you want. That's the quick 3 minute starter. Read the documentation after that...Honored ContributorWhy is there non-zero clock network delay even with PLL? For example, I used altpll to generate a 200MHz clock which exactly matches an input clock at chip boundary. However, timequest shows 0.623ns "clock network delay". Isn't PLL supposed to make it 0?
Another question is why does timequest not preserve signal names in the report? For example, it shows "sig~242|dataa", "sig~242|combout", "n|Mux0~1|datac", "n|Mux0~1|combout", "m|fifo|auto_generated|rdptr_g1p|countera9|combout", ... all of these signals are so obscured that the timing report becomes useless. When I tried "Locate->in rtl viewer" on these signals, I got warning "Can't find instance name xxx in current RTL schematic".Honored Contributor1) PLLs aren't perfect. (I assume you mean closer to 0.)
2) The PLL doesn't compensate for everything. For example, there is a delay from the input buffer to the PLL which is not part of the feedback path, and therefore can't be 100% compensated for(the delay should be minimal, but the buffer is not). Note that you can try different PLL compensation modes depending on your requirements. To keep signal names, each signal would have to be the output of a LUT. This would generally give very bad synthesis. You can put keep attributes on any nets you really want to keep, but I would avoid this practice as much as possible. Register names are the ones that are generally kept, and I base all my analysis using them at tent-posts between combinatorial logic, accepting that it will be a somewhat undecipherable cloud of logic in between. That's why you can't locate to the RTL view, as they don't match up. (And all synthesis tools work this way. I'm sure there are technical reasons for this, as it's been a bane of the industry. If the combinatorial logic was synthesized/named in a deterministic way, then preserving results, including synthesis, placement and routing, would be much easier...)Honored ContributorThanks for the explanation.
1) Isn't pad delay the same for all pins? So that should result in net 0 between clk and data. Also 0.63ns delay seems big for cyclone3-6 device. 2) I understand what you are saying, but other synthesis tools ATTACH some unique names to combination logic between two flops instead of making up something that's impossible to decipher.Honored ContributorIf you put the PLL in source synchronous compensation mode(first page of megawizard), then you're correct that they'll be vary close. That doesn't mean the clock delay will be 0, just that your clock delay should match your data delay very closely.
I do see unique names. Hierarchy is pretty much always there, and final node names often have something indicitave of their function, like mux or add in the name. Do you have hierarchy? Is this a schematic?Honored ContributorWhat is the difference between normal mode, source-synchronous mode, and zero-delay buffer mode?
My design is verilog based, and the clock is generated by another FPGA onboard, which also drives some inputs to cyclone3 and samples outputs from cyclone3. It is a hierarchical design, as you can see there's fifo controller involved. However, I got lost when tracing the critical path, because many signals are difficult (if not impossible) to correlate with rtl.
