11-24-2015 08:05 AM
Hello Forum Members,
once again a simple question about synthesis options.
I am using ISE 14.7 (I know, I should switch to Vivado, but I simply cannot). In the design panel -> synthesize -> right click-> process properties -> synthesis options -> Cross Clock Analysis .
in the xilinx online documentation
Cross Clock Analysis (Advanced) (FPGAs only)
Now, I have a DCM which generates a 120Mhz signal from a 100Mhz input the two clocks are clearly related with a fixed phase shift (hopefully 0) given by the DCM thanks to the feedback capability of the DCM itself. But the two clocks belong to two different clock domains (in phase) and are constrained properly with period constraint
in the following UG http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/ug612.pdf
and in the following AR http://www.xilinx.com/support/answers/13752.html
is clearly written that:
By default CDC paths associated with automatically or manually related synchronous clocks are analyzed under the PERIOD constraint of the destination clock.
is also clear that the CDC is done during place and route. so what is the sense of this synthesis option? Do I have to set it true to have a full cross clock analysis?
11-24-2015 10:52 AM
In a nut shell, don't worry about this.
The timing analysis done by synthesis is essentially meaningless. I have yet to find an instance where timing constraints to XST make any meaningful difference. So, whether the tool attempts to do timing across clock domains or not, is pretty much irrelevent...
Real timing analysis is only done by the later tools (map, par, trce), and they use the UCF constraints (not the XCF constraints used by synthesis), and this flag has no effect on these tools.
Of course, the best solution is to switch to Vivado, but you can only do that for 7 series parts and newer. In Vivado, synthesis does real timing analysis, uses the same constraints as the later processes and constraints matter.
11-25-2015 12:12 AM
unfortunately our architecture uses a Spartan 6 and we are updating the FPGA design with new capabilities. It is impossible to switch to 7 series without a redesign of the whole PCB which costs money and time.
these synthesis options are just making a lot of confusion.
Anyway I was wondering if put a synchronization circuitry between the two clock domains, but, as far as I understood, the tool should mauintain the worst case while placing the flip flops and calculate setup time and hold time violation between 120 and 100Mhz basing on the period constraint set at the input of the DCM (basically I have a 80Mhz --> PLL -->100Mhz --> DCM --> 120Mhz)
11-25-2015 08:03 AM
Yes, if you constrain the input to the system, the tool will derive all the clocks and the clocking relationships.
Going from a 120MHz to a 100MHz clock gives 1.66ns. This is BARELY doable, assuming the clocks are perfectly in phase. However, your clocks are the input and output of a DCM respectively - there will be clock skew between them, and hence it is very unlikely that this path can meet timing.
Why do you have a DCM following a PLL? Can't you generate the 120MHz clock directly from the PLL? If so, then the 100MHz and 120MHz clock will come from the same source (the PLL) - if you buffer them the same (i.e. both use BUFGs), then you may be able to cross synchronously between these two clocks (but it will be very tight...).
Otherwise, you will need a clock crossing circuit on this path.
11-25-2015 11:26 PM
The cross between 100Mhz and 120Mhz domains is at bit level (must send serially bits synchronous with 120Mhz clock (@10, 7.5, 3.75Mbps), thanks to deskewing I believe the tool can manage it, but in case I am already providing a synchronization handshaking.
I cannot use the same PLL for two reasons:
1_ the clock generator is inside a XPs project for a microblaze (that comes from the past I cannot modify it without changing a lot in the project and the microblaze part shall be re evaluated and re released). The clocks which are generated herein are 16, 32, 50, 100, 800Mhz (and 800 + 180° phase shift) for ddr2 (I know the maximum speed is 640 but we evaluated our products with 800 and they are working in our temperature range) with a single pll is not possible to obtain the 120 Mhz without modifying the other frequencies
2_ the wonderful clock generator for microblaze casscades a PLL and a DCM if you configure the 120 Mhz clock (as I did in VHDL) BUT, of course, the design is not synthetisable because the locked signal of cascaded PLL and DCM shall be ANDed to the locked _in signla for Microblaze reset logic, and clearly it appears to be not possible for an FPGA to make this basic operation (Or at least set an Error flag during XPS project generation). very frustrating, as usual.
I was basically checking the synthesis options because to meet constraints I had to play a lot with them. It is very odd that I run the same project on a spartan 6 100T and on a 75T devices (same package, same pcb prjects) and with the 75T full at 80% I can meet timings and in the 100T I cannot (same settings, it means same goals and strategy). And the timing failures are always into the µBlaze part.