• 0

CMOD S7 Timing Violations with Clock Wizard


Question

I wanted to use the MMCM from the clock wizard to generate a 25MHz clock from the on-board 12MHz oscillator.
Currently I am using the code from the Getting Started Guide : Step 7.6 .  
I followed the steps given in this answer, instantiated a clock wizard IP, used the MMCM with the 12MHz clock as the input and set the output frequency to 25MHz.

Screenshots of IP Configuration and Instantiation

image.thumb.png.4180e0f746a25fc31e744e9aa0e2b873.png
IP:Config_1

------------------------------------------------------------------------------------------------------------------------------------------
image.thumb.png.7e7756f8c98e01b3ffe4ed6427c3ef36.png
IP:Config_2

--------------------------------------------------------------------------------------------------------------------------------------------
image.png.afcd5ef1a4218b1698e68bffe7da1365.png
IP-Instantiation
---------------------------------------------------------------------------------------------------------------------------------------------

My issue is that whenever I use the clock wizard IP I get a timing violation error in the implementation step irrespective of the output frequency of the MMCM. The code works well without the MMCM, using the clock directly as the input, and it fails with the MMCM even if I set the output frequency to 12MHz.

SCREENSHOTS OF THE ERROR

1.

image.thumb.png.a2c18c496faf3e520de4c47e4cb9df62.png

2.image.thumb.png.f5f1bd9a93cb90104ceb2698839f53b4.png


3. Path with timing violation

image.thumb.png.514f1a5d2b76b08954a6c7958d3a6917.png



As I mentioned before the issue does not arise when I remove the IP while keeping the rest of the design same.

Thanks in Advance
Parth.
 

Link to post
Share on other sites

4 answers to this question

Recommended Posts

  • 0

Hi @Kharade, welcome to the forums!

There is a mismatch between the frequencies used in the create_clock constraints in the master XDC file and in the XDC automatically generated by the Clocking Wizard IP core - 83.33 versus 83.333. You can resolve the issue either by editing the master XDC to match, or by commenting the line back out (note the package_pin and iostandard constraints are still necessary), as the wizard is handling it for you.

Critical warnings in the methodology tab in implementation tipped me off: "TIMING-8 Critical Warning The clocks clk_out1_clk_wiz_0_1 and clk_out1_clk_wiz_0 are found related (timed together) but have no common (expandable) period."

The generated XDC can be found in the IP sources view, see below.

Thanks,

Arthur

 

image.png.d307ff663f6abccc91ce488ea3a472a4.png

Link to post
Share on other sites
  • 0

The red "X" in "Inter-clock" paths is a dead giveaway ("inter", latin, "from one to the other"): There are two clocks. they aren't simply coperiodic therefore any timing analysis between them will be ... difficult. The solution is, get rid of the unintended clock.

Link to post
Share on other sites
  • 0
5 hours ago, xc6lx45 said:

The solution is, get rid of the unintended clock.

Yes, and @artvvbgave a reply that should resolve the problem.

In this project you have two clocks. One is the MMCM input clock and the other is the derived 25 MHz output clock. Since you aren't using the input clock clk anywhere in your design there can't be inter-clock failing paths, or even inter-clock analysis. I've had experience with the board design tool for ZYNQ design get wrapped around the axle, so to speak, because I specified a non-integer PL clock in the Zynq System and made it an output to the PL only to have Vivado change the frequency assignment for the output pin symbol  by rounding or dropping a digit, creating just this kind of silly mis-match. I've had more than a few go-rounds with Vivado with this. And the board design messages don't make it easy to figure out what's going on. Fortunately, I don't often use the board design approach. Could the difference between 83.33 ns and 83.333 ns be enough to completely confuse the tool's timing analysis? There's not much else to go on. This idea would be supported by the fact that Vivado thinks that there are 2 derived clock domains when clearly you are instantiating only one.

I'm suspect about the Wizard created timing constraints after create_clock and wonder if that's an issue or just a side effect of buggy software ( 83.33 and 83.333 shouldn't be different frequencies ). I've usually never seen anything beyond that one when I use the IP to create MMCM or PLL clocks. Your screen shot doesn't show the whole clk_wiz_0.xdc file so it's hard to say. It is conceivable that demanding too tight a jitter specification for a particular output frequency would cause problems; but not the gross timing issues that Vivado is reporting.

I started off writing about timing constraints, until I re-read the post, and deleted those comments. There should be absolutely no timing errors for the code posted on the CMOD-A7 target. I believe that you are just a victim of a bug in your version of Vivado.

[edit] I'm surprised that you didn't get any error messages when you validated the board design prior to generating output products. In my experience I've always gotten enough warnings and errors before leaving the board design schematic...

Edited by zygot
Link to post
Share on other sites
  • 0

Ignore my previous post edit reference to board design validation for your project which is clearly a Verilog source... yeah, sometimes I wonder what it is that I was thinking too...

I do want to point out that when you use the Xilinx IP Wizard you often get hard to find Vivado generated constraint files embedded into your project; like the Clocking wizard. If you specify an input clock frequency to the Clocking Wizard you will always get at least one timing constraint, that is the frequency specification of the MMCM or PLL input clock. If you also add a user constraint referencing the same clock in your .xdc file(s) Vivado will give you a warning that it is ignoring it's own create_clock constraint and using the one from you. This has happened to me many times, sometimes because I've forgotten to comment out the default create_clock constraint copied from the master constraint file,sometimes because I'd rather have it visible. I write my own constraint files rather than have Vivado do it for me. There are reasons for this suitable for another discussion.

In general, if you connect a clock from an external source, and use the Clocking Wizard to create derived clocks from it for your design, you should comment out any duplicate timing reference to the same input clock in your user constraints file(s). This makes Vivado happier. When you start having complicated designs with multiple clock domains you might want to take over control from Vivado. Vivado isn't good at sharing but the effort to wrest control from Vivado is usually worth it, if for no other reason than it compels you to conscientiously think about important elements of what it is that you are doing. At some point in your FPGA development career you will find that hidden or out of view constraints are an impediment rather that a help.

If there's a point for all of this, it would be to read through all of those warning messages from the Synthesis and implementation tools, looking for red or yellow flags that indicate the perhaps you need to think about parts of your instructions more carefully. And that's all that HDL and constraints are: instructions for helping tyhe tools understand what is is that you want them to do.

Edited by zygot
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now