UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Scholar helmutforren
Scholar
2,306 Views
Registered: ‎06-23-2014

Can I make new clock domain out of thin air?

Jump to solution

I'm using Vivado 2017.1 and SystemVerilog.

 

My design has several dozen modules using the same clock, each connected up via single clock FIFOs.  Deep down in there, a section is failing to meet timing.  The worst case slack is -0.388ns on a 5ns period.  So I need to make up that -0.388ns in the design.

 

On the worst path, I find that the source clock delay is 4.577ns, almost a whole clock period.  The destination clock delay is 9.101, again a large portion of a clock period after the initial 5ns for the destination.  Together, they seem to allow my data path only 4.524ns.  This is shy of the 5ns clock by a larger amount than my worst case slack.  This makes me begin to wonder about my clock distribution.

 

After wondering the above, I do some subtractions and I find in the timing summary for this path, that it's telling me already the Clock Path Skew of -0.113ns and the Clock Uncertainty of 0.035ns.  Now, added together, these don't account for all of my -0.388ns worst case slack, but they are a significant contribution.

 

FIRST QUESTION: Am I barking up the wrong tree?  That is, I realize I must speed up this circuitry anyway, so is pursuing the timing of the clock itself a waste of time?  Will pushing this module off into a separate clock domain perhaps allow for other optimizations to help me out?  Or are the facts that (A) the clock is already globally buffered and considered in detail by the timing analysis, (B) the inside of the module itself won't be improved by such a clock change, and (C) the connections between modules via FIFOs also won't really be changed much by changing them to dual-clock FIFOS...  are these facts actually telling me that such a split out to a new domain isn't really going to help at all?  (Oh, sorry, this last sentence foreshadowed the next question without me giving you the context first.  Sorry.  Just maybe read that next question then come back to this one! LOL)

 

SECOND QUESTION: I consider changing a few of those interconnecting FIFOs to dual-clock FIFOs, and then splitting off the timing-failing module (with sub-modules) into a separate clock domain.  If I do this, how do I cause my clock inside that module to suddenly be considered a separate clock domain?  Must I separate it physically some how, such as manually inserting a BUFG?  I don't want to have to put in a PLL or MMCM which is not already there. 

 

 

THIRD QUESTION: In addition, I have vague recollection of constraints and clocks being derived from other clocks.  Might it be the case that Vivado will sort of logically undo anything I try to do to make the clock seem like a separate clock?  I think there is a way to force the issue with constraints, but do I want to do this?

 

FIRST QUESTION SORT OF AGAIN: I realize I'm not posting the actual path timing here.  I'm seeking a more generalized answer, because if it IS a good idea to split up this clock domain, I may do it elsewhere as well.  However, if I do this, is it perhaps that the only real change I'm making is to change the interconnecting FIFOs to multiple clocks?  If that's the case, then might doing so ONLY help failing paths that are involved with these interconnecting FIFOs, to the extent that paths which are NOT involved with these interconnecting FIFOs won't benefit at all?  Well, my worst case path does NOT involve these interconnecting FIFOs.  So maybe it won't benefit at all.

 

Now I'm stuck analyzing in circles!

 

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
3,294 Views
Registered: ‎01-23-2009

Re: Can I make new clock domain out of thin air?

Jump to solution

After wondering the above, I do some subtractions and I find in the timing summary for this path, that it's telling me already the Clock Path Skew of -0.113ns and the Clock Uncertainty of 0.035ns.  Now, added together, these don't account for all of my -0.388ns worst case slack, but they are a significant contribution.

 

First, the difference in the clock paths is just the clock skew - the clock uncertainty is in addition to the clock skew.

 

What you are seeing here is the effect of clock pessimism. The clock skew you get by subtracting source clock delay (SCD) and destination clock delay (DCD) is pessimistic due to the same components being timed differently in the SCD and DCD. This pessimism is added back to the timing calculation using the "clock pessimism" number in the timing report. If you subtract the clock pessimism from the 0.388 you see, you will get the 0.113 the tool reports as clock skew. See this post for a more detailed description of clock pessimism

 

Am I barking up the wrong tree?

 

Probably. The clock skew is a function of the placement of the cells. A global clock (distributed on a BUFG) reaches potentially all clocked elements on the die. It is physically impossible to have the clock arrive at every endpoint under every process/voltage/temperature combination at exactly the same time. The difference in the arrival time of this common signal at the startpoint and endpoint is the clock skew. These skew affect the timing checks, both positively and negatively

  - a late destination delay will help setup checks but hurt hold checks

  - an early destination delay will hurt setup checks, but help hold checks

 

The magnitude and sign of the clock skew depends on placement. Almost anything you do to the design will change the placement, and hence will affect the clock skew, but there is no real way to have a direct influence over it (i.e. there is nothing "magic" you can do to make it better, or even make it work in your favor).

 

Of course, this is all assuming you have a single clock on a single clock buffer. When you are dealing with a clock that starts and ends on different clocks (even if they are synchronous), there are other things that affect the clock skew; the clocks may start with some phase uncertainty (i.e. different clocks out of the same MMCM/PLL) and the different clock networks have less in common, so "clock pessimism" will remove less of the overall clock skew.

 

The skew doesn't really have anything to do with which clock network you are on; all 32 clock networks are pretty much identical. So if you were to move even only these two flip-flops to a different clock buffer, but leave the two flip-flops placed in the same location, the skew would be almost identical.

 

NOTE: This is true for all device architectures up to UltraScale - in UltraScale the clocking architecture is quite different, and smaller clock domains may actually have less skew.

 

SECOND QUESTION:

 

If this new clock domain is from the same source and at the same frequency then this doesn't solve anything (except maybe in UltraScale). To put it on a separate clock network (not a separate clock domain - if they are the same clock then they are the same clock domain), you would instantiate a separate BUFG. But again, this would not make things better in the 7-series.

 

In UltraScale, this probably doesn't make sense to do either. While smaller networks can have less skew, phys_opt_design in UltraScale can play all kinds of games with fine grained clock skew control in UltraScale to fix timing paths - anything you do manually would likely only hurt.

 

Might it be the case that Vivado will sort of logically undo anything I try to do to make the clock seem like a separate clock?  I think there is a way to force the issue with constraints, but do I want to do this?

 

It might, but I don't think so. Generally Vivado doesn't muck with user instantiated clocking resources. If it did (which, again, I don't think it will), you can override it with the DONT_TOUCH attribute set on the two clock nets.

 

But again, this won't accomplish anything.

 

As for the rest of your question, we are back to the first - you are barking up the wrong tree. Clock skew is inevitable, and it is based on placement. Nothing you can do will make it better. You need to find other ways of fixing your timing.

 

That being said, skew can be fixed by "better" placement. A large clock skew (and 113ps isn't that large) can happen if the source and destination are "far enough apart" - generally that means in different clock regions (there is a jump discontinuity in clock skew across clock regions in the 7 series) or physically far from each other in the same clock network. If you can reduce the size of your logic, critical logic can end up getting placed closer together which will improve timing due to less routing, but also due to less clock skew.

 

You may also be able to improve clock uncertainty - although 0.035 is pretty much nothing. A PLL has better clock uncertainty than an MMCM. Changing the bandwidth parameter on the PLL/MMCM can also affect clock uncertainty. That being said, clock uncertainty is often under-reported. Did you set a proper "set_input_jitter" on your input clock? If not then your design is under-constrained. Furthermore, there is also set_system_jitter, which has a pre-defined value, which @austin often points out may be too small for many designs.

 

So there is no magic solution here. To obtain timing closure you need to either simplify the path (usually the best way to do it), play with different tool options to hope for a better result, or try floorplanning (which, in Vivado almost never helps since the placer tends to do a really good job when you let it do what it wants).

 

Avrum

13 Replies
Historian
Historian
3,295 Views
Registered: ‎01-23-2009

Re: Can I make new clock domain out of thin air?

Jump to solution

After wondering the above, I do some subtractions and I find in the timing summary for this path, that it's telling me already the Clock Path Skew of -0.113ns and the Clock Uncertainty of 0.035ns.  Now, added together, these don't account for all of my -0.388ns worst case slack, but they are a significant contribution.

 

First, the difference in the clock paths is just the clock skew - the clock uncertainty is in addition to the clock skew.

 

What you are seeing here is the effect of clock pessimism. The clock skew you get by subtracting source clock delay (SCD) and destination clock delay (DCD) is pessimistic due to the same components being timed differently in the SCD and DCD. This pessimism is added back to the timing calculation using the "clock pessimism" number in the timing report. If you subtract the clock pessimism from the 0.388 you see, you will get the 0.113 the tool reports as clock skew. See this post for a more detailed description of clock pessimism

 

Am I barking up the wrong tree?

 

Probably. The clock skew is a function of the placement of the cells. A global clock (distributed on a BUFG) reaches potentially all clocked elements on the die. It is physically impossible to have the clock arrive at every endpoint under every process/voltage/temperature combination at exactly the same time. The difference in the arrival time of this common signal at the startpoint and endpoint is the clock skew. These skew affect the timing checks, both positively and negatively

  - a late destination delay will help setup checks but hurt hold checks

  - an early destination delay will hurt setup checks, but help hold checks

 

The magnitude and sign of the clock skew depends on placement. Almost anything you do to the design will change the placement, and hence will affect the clock skew, but there is no real way to have a direct influence over it (i.e. there is nothing "magic" you can do to make it better, or even make it work in your favor).

 

Of course, this is all assuming you have a single clock on a single clock buffer. When you are dealing with a clock that starts and ends on different clocks (even if they are synchronous), there are other things that affect the clock skew; the clocks may start with some phase uncertainty (i.e. different clocks out of the same MMCM/PLL) and the different clock networks have less in common, so "clock pessimism" will remove less of the overall clock skew.

 

The skew doesn't really have anything to do with which clock network you are on; all 32 clock networks are pretty much identical. So if you were to move even only these two flip-flops to a different clock buffer, but leave the two flip-flops placed in the same location, the skew would be almost identical.

 

NOTE: This is true for all device architectures up to UltraScale - in UltraScale the clocking architecture is quite different, and smaller clock domains may actually have less skew.

 

SECOND QUESTION:

 

If this new clock domain is from the same source and at the same frequency then this doesn't solve anything (except maybe in UltraScale). To put it on a separate clock network (not a separate clock domain - if they are the same clock then they are the same clock domain), you would instantiate a separate BUFG. But again, this would not make things better in the 7-series.

 

In UltraScale, this probably doesn't make sense to do either. While smaller networks can have less skew, phys_opt_design in UltraScale can play all kinds of games with fine grained clock skew control in UltraScale to fix timing paths - anything you do manually would likely only hurt.

 

Might it be the case that Vivado will sort of logically undo anything I try to do to make the clock seem like a separate clock?  I think there is a way to force the issue with constraints, but do I want to do this?

 

It might, but I don't think so. Generally Vivado doesn't muck with user instantiated clocking resources. If it did (which, again, I don't think it will), you can override it with the DONT_TOUCH attribute set on the two clock nets.

 

But again, this won't accomplish anything.

 

As for the rest of your question, we are back to the first - you are barking up the wrong tree. Clock skew is inevitable, and it is based on placement. Nothing you can do will make it better. You need to find other ways of fixing your timing.

 

That being said, skew can be fixed by "better" placement. A large clock skew (and 113ps isn't that large) can happen if the source and destination are "far enough apart" - generally that means in different clock regions (there is a jump discontinuity in clock skew across clock regions in the 7 series) or physically far from each other in the same clock network. If you can reduce the size of your logic, critical logic can end up getting placed closer together which will improve timing due to less routing, but also due to less clock skew.

 

You may also be able to improve clock uncertainty - although 0.035 is pretty much nothing. A PLL has better clock uncertainty than an MMCM. Changing the bandwidth parameter on the PLL/MMCM can also affect clock uncertainty. That being said, clock uncertainty is often under-reported. Did you set a proper "set_input_jitter" on your input clock? If not then your design is under-constrained. Furthermore, there is also set_system_jitter, which has a pre-defined value, which @austin often points out may be too small for many designs.

 

So there is no magic solution here. To obtain timing closure you need to either simplify the path (usually the best way to do it), play with different tool options to hope for a better result, or try floorplanning (which, in Vivado almost never helps since the placer tends to do a really good job when you let it do what it wants).

 

Avrum

Scholar helmutforren
Scholar
2,256 Views
Registered: ‎06-23-2014

Re: Can I make new clock domain out of thin air?

Jump to solution

Thanks for the quick and thorough reply, @avrumw .

 

By the way, are you manually formatting those quotes?  I don't see a quote button on the post message window.  So I will manually format a quote below.  If you are using some button to quote, please tell me which button that is!

 

You may also be able to improve clock uncertainty - although 0.035 is pretty much nothing. A PLL has better clock uncertainty than an MMCM. Changing the bandwidth parameter on the PLL/MMCM can also affect clock uncertainty. That being said, clock uncertainty is often under-reported. Did you set a proper "set_input_jitter" on your input clock? If not then your design is under-constrained. Furthermore, there is also set_system_jitter, which has a pre-defined value, which @austin often points out may be too small for many designs.

 

 

Yes, I was wondering about that just before you got to it.  I'm using the KC705 right now with external 200MHz clock.  I do *not* have a jitter spec at all in the constraints.  Hmmm...  my constraints are derived from the example project, so perhaps it did not have a jitter spec either.  I see how actual physical clock jitter can cause instances of shorter than 5ns between clocks, and how the clock uncertainty value can reflect that by my setting a jitter constraint.  This means I see how my lack of a jitter spec/constraint can mean I'm under constrained -- perhaps dangerously so.  I'll get on that...  (LOL, I think I'm moving backward faster than I'm moving forward!)

0 Kudos
Scholar helmutforren
Scholar
2,254 Views
Registered: ‎06-23-2014

Re: Can I make new clock domain out of thin air?

Jump to solution

UPDATE: In [UG810 (v1.7) July 8, 2016] I find on page 29 a description of the System Clock Source, including PPM frequency jitter: 50 ppm.  I think this is the number I need to feed into the constraints.  Next, I'll go research how to do jitter in constraints...

0 Kudos
Historian
Historian
2,253 Views
Registered: ‎01-23-2009

Re: Can I make new clock domain out of thin air?

Jump to solution

By the way, are you manually formatting those quotes?

 

No - I manually change the color and indent them (it has sort of become my "signature look")

 

This means I see how my lack of a jitter spec/constraint can mean I'm under constrained -- perhaps dangerously so.

 

The good news is that both a PLL and an MMCM do very good jobs at jitter attenuation. So if you are using a PLL/MMCM on your clock, most of the jitter from the set_input_jitter is filtered out; only a small percentage will remain on the output of the PLL/MMCM.

 

But, yes, unless you have specified input jitter and have a realistic system jitter, your design can be under-constrained...

 

Avrum

0 Kudos
Scholar helmutforren
Scholar
2,232 Views
Registered: ‎06-23-2014

Re: Can I make new clock domain out of thin air?

Jump to solution

...well... 

 

Two things.  First, if 

 

Right now, the KC705 200MHz clock UG810 says "PPM frequency jitter: 50 ppm", should I assume that I do a simple translation to ns?  I can do that math easily: 50ppm on 5ns period corresponds to 0.25ps (0.00025ns).  But I don't know if these numbers are peak-to-peak or two std dev or whatever.  Furthermore, I think the input to set_input_jitter is nanoseconds.  Adding 0.00025ns means absolutely nothing!!!  For example, the timing calculates in ps, and this is a quarter of the timing resolution.  Am I confused?

 

Second, maybe the above makes the following nonsense...  Right now, the KC705 200MHz clock comes in and goes through this:

    wire SYS_CLK_intermediate;
    IBUFGDS #(
        .DIFF_TERM("FALSE")
    ) 
    CL_iob (
        .I(SYSCLK_P),
        .IB(SYSCLK_N),
        .O(SYS_CLK_intermediate)
    );
    BUFG CL_ob2 (.I(SYS_CLK_intermediate),.O(SYS_CLK)) ;

to produce my SYS_CLK that goes everywhere.

 

I do *not* have a PLL or MMCM.  But then, if the jitter really is a quarter of a picosecond, need I waste effort adding one?

 

Now, we are building a target and I don't know its clock jitter.  I might need to do something else for it, and I'll be aware of some of the considerations.

 

0 Kudos
Historian
Historian
2,226 Views
Registered: ‎01-23-2009

Re: Can I make new clock domain out of thin air?

Jump to solution

Oscillator jitter is almost always specified in RMS. You need to multiply it (by a lot) to get a reasonable confidence interval for peak-to-peak jitter.

 

Take a look at this post on RMS jitter - one of the later postings (#6) has a link to a jitter table...

 

Avrum

0 Kudos
Scholar helmutforren
Scholar
2,222 Views
Registered: ‎06-23-2014

Re: Can I make new clock domain out of thin air?

Jump to solution

...will do.  Thx.

 

By the way, do you know Verilog or SystemVerilog?  I was wondering.  I see the Vivado GUI accepts "reg1 = (reg2 = statement);", where I intend to assign "statement" to both "reg1" and "reg2", without having to type "statement" twice and risk a typo error.  Do you know if Vivado will handle that the same as simply "reg1 = statement; reg2 = statement"?  Or might it add some additional implementation or routing constraints that I don't intend?

0 Kudos
Historian
Historian
2,216 Views
Registered: ‎01-23-2009

Re: Can I make new clock domain out of thin air?

Jump to solution

By the way, do you know Verilog or SystemVerilog?  I was wondering.  I see the Vivado GUI accepts "reg1 = (reg2 = statement);", where I intend to assign "statement" to both "reg1" and "reg2", without having to type "statement" twice and risk a typo error. 

 

I use both Verilog and SystemVerilog, and even a little bit of VHDL.

 

Until I saw this post, I was not even aware that SystemVerilog supported assignments within an expression (like C) of the form

  reg1 = (reg2 = expression);

 

I looked at the SystemVerilog LRM and it is legal syntax (clause 11.3.6). These are only supported as blocking procedural assignments, and hence inside an initial or always block, and they may not contain any time control (#, @ , or wait).

 

However, I have never used it, nor have I ever seen anyone use it, so I have no personal experience with it. Even if it is supported in Vivado synthesis (and I have no idea if it is or it isn't), I would be worried that other synthesis tools may not support it, so I would tend to stay away from it.

 

However, if it was supported, I highly doubt there would be any difference in result between

 

reg1 = expression;

reg2 = expression;

 

or

 

reg1 = expression;

reg2 = reg1;

 

or

 

reg2 = (reg1 = expression);

 

They should all be functionally equivalent...

 

Avrum

Scholar helmutforren
Scholar
2,142 Views
Registered: ‎06-23-2014

Re: Can I make new clock domain out of thin air?

Jump to solution

@avrumw do you believe I did this correctly?

 

The KC705 datasheet says 200MHz clock with 50ppm jitter (RMS assumed).  I translated that as 5ns period.  I applied 50ppm to that to get 0.25ns RMS jitter. 

 

Then I used the calculator at https://www.jitterlabs.com/support/calculators/rms-peak-peak-calculator .  We don't have an MTBF spec.  Initially, I thought 1 error in 10 million might suffice.  I got the DTD from the table below the calculator.  The image below shows the calculator result, with p-p jitter 2.6ps.  This will end up subtracting 1.3ps from my 5000ps period...  only a small change in ability to meet timing.

Jitter if 10 Million.jpg

 

Then I noticed "Crest Factor" in the table below the calculator doesn't really rise very fast with failure probability improvement.  So I tried 1E-16 (an error once in 10,000 million millon) and DTD=1.  I get the below:

Jitter if 10K Million Million.jpg

Well, the p-p jitter only rose from 2.6ps to 4.152ps.  Small increase for tremendously more reliability.  Remember context, I have 5000ps in a perfect clock.  

 

I wonder if I should simply specify 5ps jitter?  My initial thought is that there shouldn't be too many paths within 0.1% of the allowed time.  If there are, I should be able to fix them.  This increase from 4.152ps to 5ps ought to give me another tremendous increase in reliability.  I know it all can't be this accurate, but playing with the calculator more, I find P = 1.6E-23 gives me about 5ns p-p jitter.  This is another million reduction in error.

Jitter if 160K Million Million Million.jpg

So I'll go try adding "set_input_jitter [get_clocks -of_objects [get_ports SYSCLK_P]] 5.0" to my constraints, and see what happens.

 

NEXT, I'm wondering how to use "set_system_jitter".  Is the syntax indeed akin to "set_system_jitter 5.0"?  Then I have no clue what kind of value to use...

 

Thanks again,

Helmut

0 Kudos
Scholar markcurry
Scholar
1,267 Views
Registered: ‎09-16-2009

Re: Can I make new clock domain out of thin air?

Jump to solution

Helmut,

 

While not specifically addressing your questions - since you're knee deep in this now - thought I'd also throw out this little nugget.

 

EDIT names below for correct terminology...

 

The relevant parameter with respect to static timing and digital design is neither cycle-to-cycle, nor long-term jitter.  The relevant parameter is "period" jitter and is an entirely different measurement.  The former two are important parameters used by the person designing the PLL.  The latter is the number you need for STA.

 

The latter is hardly ever specified, however, so one usually has to wing it from the other two defined values. 

 

A quick google search on "period jitter" for me brought up this link.  From my quick read it's a good place to start:

 

https://www.sitime.com/api/gated/AN10007-Jitter-and-measurement.pdf

 

Regards,

 

Mark

0 Kudos
Scholar helmutforren
Scholar
819 Views
Registered: ‎06-23-2014

Re: Can I make new clock domain out of thin air?

Jump to solution

@markcurry , here I am nearly a year later and it is **finally** time for me to actually address this.  I am hoping you will pick up on this thread with me.  You too, @avrumw .

The last post that I wrote said that I felt it was time to add the constraint "set_input_jitter [get_clocks -of_objects [get_ports SYSCLK_P]] 5.0" and that this should get me pretty good MTBF.

I also mentioned that I should possibly add something akin to "set_system_jitter 5.0".  I wasn't sure of the syntax or value.  CAN YOU PLEASE ADVISE?

Finally, @markcurry also mentioned "period jitter" and a detailed reference.  WELL, I NEED TO "DO", NOT "READ".  Sorry about that.  There's a limit to the degree of understanding required or available.  I need to just make a choice and move on.  I don't think I can ever get to 100.000%.  This brings me back to juse using set_input_jitter and set_system_jitter...

0 Kudos
Historian
Historian
807 Views
Registered: ‎01-23-2009

Re: Can I make new clock domain out of thin air?

Jump to solution

The last post that I wrote said that I felt it was time to add the constraint "set_input_jitter [get_clocks -of_objects [get_ports SYSCLK_P]] 5.0" and that this should get me pretty good MTBF.

NO! the set_input_jitter specifies the jitter in NANOseconds - you want to specify 5ps of jitter (not 5ns of jitter). So you want 0.005. (But see below).

I can't advise on system jitter - I just leave it alone...

As for the different kinds of jitter, while I don't doubt that the terminology in the paper quoted by @markcurry is correct, we generally are only concerned with two kinds of jitter:

  • RMS jitter 
  • "Cycle-to-cycle Period Jitter" (using the terminology of the paper)

However, most people interchangeably call the latter one "Cycle-to-cycle jitter" or "Period jitter" rather than the name used by the paper. It may be incorrect to call this "Period Jitter" (at least according to that paper), but it is my belief that everyone uses the term "Period jitter" to refer to "Cycle-to-cycle Period Jitter" (others can feel free to contradict this if they know otherwise).

But I am not sure of this 50ppm jitter - this may be an error in the KC705 user guide. If we look at the SiTime datasheet, there are two numbers:

  • The "Frequency Stability" which is 50ppm
    • This means that the "nominal" frequency of the oscillator is 200MHz +/-50ppm, which means the frequency may be as high as 200.01MHz (meaning a period of 4.99975ps)
  • The RMS Period Jitter, which it quotes as 1.8ps max
    • So assuming the 16.61x multiplier, the "Cycle-to-cycle period jitter" would be 29.9ps

Thus, you would technically want

create_clock -period 4.99975 ...
set_input_jitter ... 0.0299

(Although at least the first of these is approaching the 3 significant digit accuracy used in the timing analysis)

Avrum

0 Kudos
Scholar helmutforren
Scholar
699 Views
Registered: ‎06-23-2014

Re: Can I make new clock domain out of thin air?

Jump to solution

@avrumw , please allow me to simplify your advice. [EDIT: THANKS FOR YOUR HELP IN GETTING ME TO A WORKING END POINT]

I round your set_input_jitter from 0.0299 to 0.030.  Meanwhile, I find in my project that the microblaze block diagram is doing "set_input_jitter [get_clocks -of_objects [get_ports FPGA_SYSCLK_P]] 0.050" and my own attempt to set it for FPGA_SYSCLK_P is thwarted.  Well, this 0.050 exceeds your 0.0299.  So I'll just leave that part well enough alone.

Furthermore, you say "create_clock -period 4.99975".  That differs from "create_clock -period 5.000" by only 0.00025.  Given that the jitter spec of 0.050 dwarfs the 0.00025, I just fall back to "create_clock -period 5.000".  And guess what, the microblaze block diagram is already doing this.  Furthermore, I had elsewhere in my design a 4.940ns and when I later included a Xilinx ref design for ISERDES, it had some kind of code in it that forced the need back to 5.000. 

So, with all of the above, I just fall back to both specs that the microblaze block diagram is enforcing (via base_mb_clk_wiz_1_0.xdc), which is a 5ns clock and 0.050 jitter.

NEXT, I really wanted to add additional safety in here.  I had experimented before with set_clock_uncertainty and I'm trying that again.  I'm going to try 0.101 on FPGA_SYSCLK_P and 0.501 on a slower auxiliary clock.  First, with that low 1 digit I can hopefully SEE where things are coming from.  Second, those large values hint at great safety.  [EDIT: THIS WORKED]

Overall, how these constraints work, how the values are input as ns only and nothing else, how the constraints interact and the ones you type do nothing (as can often be confirmed with TCL write_xdc), gets really complicated!  We'll see if my resolution du jour works...

0 Kudos