cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
4,009 Views
Registered: ‎06-09-2018

timing question about create_generated_clock

Jump to solution

Hi every body

 

I have two questions about create_generated_clock constraint :

 

1-in the image below, what's difference between these two constraints : 

#1 : 

create_generated_clock -name clkdiv2 -source [get_ports clkin] -divide_by 2 [get_pins REGA/Q]

#2 :

create_generated_clock -name clkdiv2 -source [get_pins REGA/C] -divide_by 2 [get_pins REGA/Q]

 

and : 2-synthesizer what to do if select each of them?

Capture.PNG
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
4,274 Views
Registered: ‎01-23-2009

As markg@prosensing.com said, the two commands are equivalent. For the -source option, you need to specify a net or a pin that carries the clock that is the master clock of the generated clock. Both the clkin port and the C pin of REGA carry the clock, so they are both acceptable. Like Mark, I prefer REGA/C since it is "closer" to the clock generating cell.

 

But, I want to point out that generating a clock this way is legal in XDC, it is not recommended in the FPGA. Inside the FPGA it is recommended that clocks remain on dedicated clocking resources - the clock capable input, the MMCM, the BUFG. Doing what you have done creates a clock in the general fabric logic, and the clock is then locally routed (not on a clock tree) from the output of REGA to the C pin of REGB. The routing delay of this net can be long and will vary from implementation run to run.

 

If you need to use a divided clock, you should consider generating it from a dedicated clock resource - either use an MMCM or PLL to really generate the divided clock, or use the BUFGCE or BUFHCE to generate a "decimated" clock. (See this post on using the BUFGCE/BUFHCE).

 

Avrum

View solution in original post

25 Replies
Highlighted
3,983 Views
Registered: ‎01-22-2015

Hi @hrmt,

 

       1-in the image below, what's difference between these two constraints :

As explained on page 85 of Xilinx document UG903, the two constraints are equivalent  -because you can specify the -source clock by referring to the input-port, clkin, for the clock or by referring to a device clock-pin, REGA/C, that the clock is connected to.  I prefer the #2 constraint because it is often the easiest way to identify the source clock.

 

       2-synthesizer what to do if select each of them?

You should use one or the other of the constraints – but not both – since this is redundant and will probably cause an error.

 

Cheers,

Mark

Highlighted
Guide
Guide
4,275 Views
Registered: ‎01-23-2009

As markg@prosensing.com said, the two commands are equivalent. For the -source option, you need to specify a net or a pin that carries the clock that is the master clock of the generated clock. Both the clkin port and the C pin of REGA carry the clock, so they are both acceptable. Like Mark, I prefer REGA/C since it is "closer" to the clock generating cell.

 

But, I want to point out that generating a clock this way is legal in XDC, it is not recommended in the FPGA. Inside the FPGA it is recommended that clocks remain on dedicated clocking resources - the clock capable input, the MMCM, the BUFG. Doing what you have done creates a clock in the general fabric logic, and the clock is then locally routed (not on a clock tree) from the output of REGA to the C pin of REGB. The routing delay of this net can be long and will vary from implementation run to run.

 

If you need to use a divided clock, you should consider generating it from a dedicated clock resource - either use an MMCM or PLL to really generate the divided clock, or use the BUFGCE or BUFHCE to generate a "decimated" clock. (See this post on using the BUFGCE/BUFHCE).

 

Avrum

View solution in original post

Highlighted
Explorer
Explorer
3,940 Views
Registered: ‎06-09-2018

thank you @avrumw

I have a question about this post. if instead of method that you said in this post, I put a BUFG after counter what problem will happen?

Untitled.png
0 Kudos
Highlighted
Explorer
Explorer
3,929 Views
Registered: ‎06-09-2018

Hi markg@prosensing.com

thank you so much for your answer

0 Kudos
Highlighted
3,876 Views
Registered: ‎01-22-2015

@hrmt

 

Your sketch has the right concepts but the wrong architecture.  For creating a slow clock from a fast clock, Avrum is suggesting that you use the following architecture, which is from his post <Deriving a slow clock> :

slow_clock.jpg

 

You will find more information about the BUFGCE and BUFHCE in Xilinx documents UG472 and UG953.

 

Mark

0 Kudos
Highlighted
Explorer
Explorer
3,870 Views
Registered: ‎06-09-2018

markg@prosensing.com

@avrumw

yes i seen Arum suggestion. now my question is : What problem will happen, if I use the following method (Image below)?

Capture.PNG
0 Kudos
Highlighted
3,841 Views
Registered: ‎01-22-2015

@hrmt

 

When using the architecture suggested by Avrum, edges of the slow clock will always correspond to an edge of the fast clock – and the slow clock period will be an exact integer multiple of the fast clock period. So, stability of the slow clock is tied to stability of the fast clock. 

 

When using your architecture, the period of the slow clock will change as delays through the components (in the FPGA fabric) used to build the counter change with Process, Voltage, and Temperature (PVT).

 

Said another way, Avrum’s architecture can overcome PVT changes in the counter whereas your architecture can not.

 

If you are using the slow clock to blink LEDs, then any method of creating the slow clock is fine.  However, if the slow clock is a "true" clock that will be used for clocked-logic (eg. registers) then the method of creating the clock can determine whether or not your design will pass timing analysis.

 

 

Highlighted
Guide
Guide
3,809 Views
Registered: ‎01-23-2009

The output of a BUFG is the dedicated global clock network. This network distributes the clock to potentially all flip-flops on the die. This clock tree is "balanced" - it is designed so that the clock will reach all the endpoints at almost the same time; the difference between the earliest and latest arrival is called skew, and this is minimized. To do this, though, there may be a fair amount of delay through the global clock network.

 

Your counter will be one of the endpoints of the global clock network. However, your counter will have a clock->out delay, and (more importantly) will have routing delay; the output of the flip-flop that generates the divided "clock" will have to be routed through regular routing channels back to the input of the BUFG. This delay is highly process/voltage/temperature (PVT) dependent and will also vary from run to run. From there it goes through the BUFG and to a second global clock network, which will again add a lot more PVT dependent delay.

 

The net result is that the divided clock, while it will be the correct frequency, will be significantly later than the base (fast) clock (it will also have more jitter since it traversed the general fabric routing).  If this clock is used only as a frequency reference and only "by itself" (i.e. all flip-flops on this clock only have paths to other flip-flops on this clock), then this is fine - again, the frequency will be what you want. But the phase will be late, somewhat unknown, and PVT and route dependent. As a result

  - any path between the base clock and the divided clock will have significant hold time problems

  - any path between the divided clock and the base clock will have a significantly shortened setup requirement

  - it will be very difficult (if not impossible) to get any reasonable timing requirements on I/O that use this clock

 

For these reasons, it is almost always preferred to use a solution that keeps clocks on the dedicated clock resources.

 

Avrum

Tags (1)
Highlighted
Explorer
Explorer
3,777 Views
Registered: ‎06-09-2018

thank you for perfect answer @avrumw

but some question : 

1- i accept that phase of my slow clk is unknown but in my method and your methods there are a counter module so your methods have PVT problems and are route dependent too, it is not true?

 

2- if frequecy is less than about 4 MHz i use this method otherwise i use a MMCM for creating a slow frequency(MMCM generate CLK frequency greater than about 4 MHz) however can i have problems with setup time and hold time because clk period is big enough.

 

3- can you explain shortened setup requirement ?

0 Kudos
Highlighted
Explorer
Explorer
3,771 Views
Registered: ‎06-09-2018

thank you for perfect answer @avrumw

i have some questions : 

 

1- i accept that in my method phase of slow clk is unknown but in my method and your methods there is Counter Module so your methods have PVT problems and are routing dependent too, this is not true?

 

2- i use this method when clk frequency is less than about 4 MHz otherwise i use MMCM(because min clk frequency MMCM is about 4 MHz). in this circumstances that clk period is big enough can i have set up and hold time problems?

 

3- can you explain "shortened setup requirement" ?

0 Kudos
Highlighted
Guide
Guide
3,756 Views
Registered: ‎01-23-2009

your methods there is Counter Module so your methods have PVT problems and are routing dependent too

 

No.

 

All synchronous digital design has to deal with PVT variation. It is for this reason that setup and hold checks on all static timing paths (data paths) are done at both process corners. My design is purely synchronous - there is a static timing path from the output of the counter to the CE input of the BUFGCE. The tools will implement this path to ensure that it meets the setup/hold requirement of the CE input.

 

But the clock paths in my solution are balanced. Each of the two clocks (the base clock and the divided clock) start at the same point, go through exactly one BUFG (a BUFG and BUFGCE are the same cell) and go through exactly one global clock network. So the PVT variation on both clock paths cancel; the delay through one BUFG will be almost the same as the delay through the other BUFGCE; the delay through one global clock tree will be the same as the delay though the other global clock tree. So the two clocks will arrive at startpoint/endpoints at almost the same time.

 

In your solution, one clock goes through one BUFG and one global clock network, whereas the other one goes through

  - one BUFG (the same as the base clock)

  - one global clock network (the same as the base clock)

  - the counter (not balanced with anything)

  - the route back to the input of another BUFG (not balanced with anything)

  - a second BUFG (not balanced with anything)

  - a second global clock network (not balanced with anything)

 

The delay on these last 4 things are delay on the divided clock that are "on top of" the delay of the base clock. This delay causes problems.

 

2- i use this method when clk frequency is less than about 4 MHz otherwise i use MMCM

 

You can do what you want, but the solution I showed you is the correct mechanism of dividing a clock without an MMCM

 

3- can you explain "shortened setup requirement" ?

 

Lets say your base clock is 100MHz (and the divided one is 50MHz). If the two clocks are balanced, than all static timing paths have 10ns for the setup check, and 0ns for the hold check

  - the time from the rising edge of the divided clock to the next rising edge of the base clock is 10ns

  - the time from the rising edge of the base clock to the next rising edge of the divided clock is either 10ns or 20ns, depending on which edge it is

    - the tools choose the worst for static timing analysis, which is 10ns

 

But lets say the base clock has 3ns of delay (through the BUFG and the global clock network) and the divided clock has 6 (through the two BUFGs, the two global clock networks and the divider) then

 

   - the base clock to the divided clock has has 13ns for the setup check (from 3ns to 10+6ns), but 3ns [edit] for the hold check (from 3ns to 6ns [edit])

       - this causes extra routing to fix the hold time violation (which may not be possible)

   - the divided clock to the base clock has 7ns for the setup check - from 6ns to the next base clock edge at 10+3ns, and a -3ns hold check (from 6ns to 3ns)

       - this is less than the normal 10ns setup check, so is a shortened setup requirement.

 

This is a simplistic example (since it doesn't consider PVT - just delay), but it illustrates the point.

 

Avrum

  

Tags (1)
Highlighted
Explorer
Explorer
3,728 Views
Registered: ‎06-09-2018

thank you, thank you so much @avrumw

 

i understand shortened setup requirement but i have another question : you said "the base clock to the divided clock has has 13ns for the setup check (from 3ns to 16ns), but -3ns for the hold check (from 6ns to 3ns)" in below image can you explain why from "3 to 16"

and why hold time is negative?

IMG_20180821_110325.jpg
0 Kudos
Highlighted
Guide
Guide
3,707 Views
Registered: ‎01-23-2009

I have corrected some minor errors

 

Base -> Divided: 13ns setup requirement, 3ns hold requirement

  - a 13ns setup requirement is easier to meet than the normal 10ns

  - a 3ns hold requirement is VERY hard to meet - it requires delaying some paths by as much as 3ns

 

Divided -> Base: 7ns setup requirement, -3ns hold requirement

  - a 7ns setup requirement is harder to meet than the normal 10ns

  - a -3ns hold requirement is virtually impossible to violate - anything less than 0 (after clock skew) is easy to meet.

 

Avrum

0 Kudos
Highlighted
Explorer
Explorer
3,596 Views
Registered: ‎06-09-2018

@avrumw

markg@prosensing.com

 

i use method in fig. 1. but i have a problem:

when i see waveform (Specified with the red square in Figure 2) in oscilloscope the output of bufgce is not expected(blue waveform is input of bufgce and yellow is output of it). especially in fig. 6 (peak of input signal isn't in output signal). What is the reason for this problem?

Capture.PNG
blk.PNG
blk2.PNG
rclk.PNG
rclk1.PNG
clkwiz.PNG
0 Kudos
Highlighted
3,573 Views
Registered: ‎01-22-2015

@hrmt

 

I cannot see how you have routed your clocks to FPGA pins for inspection.  However, if you are simply connecting clock-to-pin then this may be the cause of problems you are seeing.

 

When sending a clock to an FPGA pin, you should use the ODDR primitive as shown below.

 

ODDR_FWD_CLOCK.jpg

 

You can instantiate the ODDR into your design as shown in Xilinx document UG953 and by the VHDL code below:

ckf: ODDR 
generic map(
    DDR_CLK_EDGE => "OPPOSITE_EDGE",-- "SAME_EDGE" or "OPPOSITE_EDGE"
    INIT =>'0',                     -- Initial value for Q port ('1' or '0')
    SRTYPE => "SYNC"                -- Reset Type ("ASYNC" or "SYNC")
)
port map(
    Q => CLK_OUT,       -- 1-bit DDR output
    C => CLK_IN,        -- 1-bit clock input
    CE => '1',          -- 1-bit clock enable input
    D1 => '1',          -- 1-bit data input (positive edge C)
    D2 => '0',          -- 1-bit data input (negative edge C)
    R => '0',           -- 1-bit reset input  
    S => '0'            -- 1-bit set input
);	

 

Normally, clocks can be connected only to device clock pins and to other components (eg. clock buffers) in the clock tree.  The ODDR is a safe and proper way to "remove" a clock from the FPGA clock tree (so that it can be routed to other things - like FPGA pins).

 

Mark

Highlighted
Guide
Guide
3,568 Views
Registered: ‎01-23-2009

First, the comment from markg@prosensing.com regarding how to bring a clock out of the FPGA (via an ODDR) is a good one. However, it should be pointed out the decimated clock generated by a BUFGCE/BUFHCE has a very asymmetric duty cycle, which is rarely "good enough" for a board level clock...

 

That being said - whatever it is you are seeing on your oscilloscope has nothing to do with how the clock is generated. Digital is digital - it consists of ones and zeros - all signals inside the FPGA (no matter how they are generated) are digital (except for the high speed serial I/O outputs from the GTX/GTH/GTY...). Whatever you are seeing on your scope is not - there is some analog effect going on here... The things I can think of

  - you have contention on your board (there is a second driver on these clock pins)

  - this is measurement error (what the scope is showing you is not what is really happening)

  - you have some gross problem with your power supply on VCCO

 

Avrum

Highlighted
3,551 Views
Registered: ‎01-22-2015

@avrumw

 

      ...whatever it is you are seeing on your oscilloscope has nothing to do with how the clock is generated.

You are, of course, correct.  How silly of me - and thank you!

 

     …the decimated clock generated by a BUFGCE/BUFHCE has a very asymmetric duty cycle, which is

      rarely "good enough" for a board level clock.

If @hrmt is using only the rising edge of this clock, then things should work(I think).  What else about clocks with very asymmetric duty cycle makes them unsuitable for a board level clock?

0 Kudos
Highlighted
Guide
Guide
3,545 Views
Registered: ‎01-23-2009

What else about clocks with very asymmetric duty cycle makes them unsuitable for a board level clock?

 

Obviously if the clock is used for any kind of DDR interface then it is unsuitable. Similarly, if it is used for a protocol that use the falling edge (like some SPI and I2C) then it is unsuitable.

 

Also, some devices - even ones that take relatively low speed clocks - specify the minimum high and low time of the clock - this clock may fail the minimum high time requirement.

 

But if none of these apply, then it should be fine.

 

Avrum

0 Kudos
Highlighted
3,538 Views
Registered: ‎01-22-2015

Thank you, Avrum!

0 Kudos
Highlighted
Explorer
Explorer
3,456 Views
Registered: ‎06-09-2018

@avrumw

 

 you have contention on your board (there is a second driver on these clock pins)

 

all connections for seeing these 4 waveforms in my board are similar and are in below image.

 

this is measurement error (what the scope is showing you is not what is really happening)

- you have some gross problem with your power supply on VCCO

 

if these are true, why in this post Fig. 4 bule waveform is OK?

 

Untitled.png
0 Kudos
Highlighted
Explorer
Explorer
3,444 Views
Registered: ‎06-09-2018

@avrumw

 

Excuse me Avrum, i have also another question when i use bufgce, i encountered with timing issues with ila core, i have connected not(i_RCLKn[6]) to ila clk port.

why this timing issues encountered and what i do?

Capture.PNG
aa.PNG
a.PNG
0 Kudos
Highlighted
Guide
Guide
3,430 Views
Registered: ‎01-23-2009

all connections for seeing these 4 waveforms in my board are similar and are in below image.

 

Why? What is the purpose of this diode&resistor?

 

First, are these signals "open collector" - are you supposed to be relying on the resistor to do the pull-up?

 

I am not sure why, but I am fairly certain that this diode has something do with your problem. The small jump around the beginning of the transition and then the plateau looks suspiciously like a diode drop.

 

And all your signals look "abnormal". The blue one looks a bit less abnormal than the others (probably due to the longer high time), but it is still abnormal.

 

Avrum

0 Kudos
Highlighted
Explorer
Explorer
3,417 Views
Registered: ‎06-09-2018

@avrumw

 

Why? What is the purpose of this diode&resistor?

so sorry, these are LED and resistor, these are for tests in my board, i want see waveforms of my signals so i connected these signals to these pins.

 

and what is your opinion about this problem?

 

 

0 Kudos
Highlighted
Guide
Guide
3,365 Views
Registered: ‎01-23-2009

Are you attaching your oscilloscope to the FPGA pin, or between the resistor and the diode. If the latter, that probably explains the weird pulse shapes.

 

As for the timing failure with the ILA, well, it's an ILA (Internal Logic Analyzer). A logic analyzer is a piece of test equipment that samples a number of synchronous digital signals and stores their value for later read back. The sampling is done with the ILA clock, which must be synchronous to the input signals (or closely related to). You don't show exactly what the clock for the ILA is, but for the signal you are trying to look at (which is your input clock), there is no clock signal that is "synchronous" and properly phase matched to that point - so no matter what clock you are using for your ILA it is "wrong" (I will leave this in quotes for the moment).

 

Clearly the o_CLK256K is not a valid clock for sampling this signal - depending on what is in the Inst_transmit, this is either the a buffered version of same clock (and sampling a clock with itself is, by definition, meaningless) or a phase shifted version of the same clock. In either case this isn't going to work.

 

The only time you can try and sample a clock signal is by using oversampling - you can sample the clock using a clock that is significantly higher frequency. Even here, you will only get an idea of what the clock looks like; around the changes of the slower clock, you will get samples that are on the edge of your sampling clock, which will go either way (0 or 1) or go metastable. In fact, you should not sample the incoming clock directly, you must first metastability harden it.

 

If you are oversampling a signal, normal timing constraints are incorrect - they need an exception - either a set_max_delay -datapath_only or a set_false path.

 

And finally, if you bring a buffered clock (i.e. the output of your BUFGCE) into a data input of a cell (i.e. anything other than the clock port), you are forcing the router to take this clock off the dedicated clock network and route it in the FPGA fabric (for this data connection). The phase of this branch of the "clock" can be significantly different than the phase of the clock at all other endpoints in the device.

 

Avum

 

 

 

0 Kudos
Highlighted
Explorer
Explorer
3,335 Views
Registered: ‎06-09-2018

@avrumw

 

          Are you attaching your oscilloscope to the FPGA pin, or between the resistor and the diode. If the latter, that probably explains            the weird pulse shapes.

 

yes my oscilloscope probe is between the resistor and LED, but when i simulated this situation in hspice, the output of this software was not similar to my oscilloscope waveform, i program this design with another fpga and board, waveform is similar to previous too.

 

i attached my HDL.

 

          ... you must first metastability harden it

what's your mean?

0 Kudos