Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

setup and hold (multi clocks)

Status
Not open for further replies.
E

ee1

Full Member level 2
Joined
May 31, 2011
Messages
120
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,298
Activity points
2,036
Hi,
how do i calculate setup and hold between two F.F with 2 clocks...

thanks!
 

Do you mean two unrelated clocks? If so then you should be asking about metastability.
 
  • Like
Reactions: ee1

    E

    ee1

    Points: 2
    Helpful Answer Positive Rating
2 sync clocks....
 

Not sure I understand the question. What do you mean by "setup and hold between two F.F"? If you don't know the phase relationship between the two clocks, even if they are synchronous, then you can still get into trouble. If this is in an FPGA then the tools will take care of meeting timing between ffs. If you're talking about two discrete ffs, then you need more information. It's not a question of just setup and hold; it's also clock-to-output prop delay,clock1-clock2 skew, etc.
 
  • Like
Reactions: ee1

    E

    ee1

    Points: 2
    Helpful Answer Positive Rating
i mean somthing like this:
 

Still not sure what you're trying to determine. Your drawing shows two non-phase locked clocks, i.e., the distance between the rising edges of the two clocks is not a fixed amount. If you look at the first rising edge of the top clock, it occurs simultaneously with the bottom clock's rising edge, but the second rising edge occurs two units prior the bottom clock's rising edge. You have a clock-domain-crossing situation. You need to use a synchronizer.
 
  • Like
Reactions: ee1

    E

    ee1

    Points: 2
    Helpful Answer Positive Rating
I am trying to understand if there is a path between those 2 flops that should be checked for timing?

Thanks.
 
You can't really check this for timing-it's indeterminate (even if you know all the propagation delays, etc) because of the non-integer relationship between the two clocks. Is this an FPGA or ASIC design? If so, then depending on the specifics of this circuit you may want to give it a relaxed constraint (like a multi-cycle or ignore). However, if this is a critical path then you're going to have to add a synchronizer or FIFO. There's no way (that I'm aware of) that you can guaranteed the exact timing of the output of the second ff. Using your timing diagram above, after the first A clock edge data will appear at the D input of the B ff. But at time 6, NEW data will be clocked out to the D input of B. Thus, the output of the B FF after the B rising edge at time 8 will be the SECOND data bit from A; the first one never gets clocked into B. Classic multiple-clock-domain problem.

I suggest you either add a FIFO or a multi-cycle constraint. You've got two different data rates. If the input rate were the slower one then it would be a different story (but still messy). There's a lot of info out there about clock-domain crossing, synchronizers, etc. Check them out.
 
  • Like
Reactions: ee1

    E

    ee1

    Points: 2
    Helpful Answer Positive Rating
Thanks u helped me alot!
 

Any STA tool will try to find the LCM of the 2 clocks and time the path using that clock period...in your case, its 24ns...now as barry mentioned, you have different clocks and would need a FIFO or synchronizer ..If its source synchronous clock , you might not need...by applying multicycle path, you are only avoiding th problem here as STA will not see it as critical path anymore...check from the design spec if a path between those 2 domains is intended and if not, false path the paths between those 2 clock domains else proceed as barry suggested by having a synchronizer...
 
  • Like
Reactions: ee1

    E

    ee1

    Points: 2
    Helpful Answer Positive Rating
hi Ee,

I am completly agree with above mention explanation. But still as per my understanding .. your initial question was .. whether we can check the setup and hold in a circuit which is sourced by 2 different clocks. if its correct.. then practically .. we have a lot of situation in real world .. where such type of situation exist in the design.. dnt know about rest of the STA tools . but PT (primeTime ) has such feature.. means you can play with the options and setting and figure out whether there is a setup and hold violation or not....

ya its true that as berry mention that you may hv to define a few more constraint.. but keeping those in mind you can do it. If you have query .. regarding this let me know .. I will try my best to explain you regarding this.
 
  • Like
Reactions: ee1

    E

    ee1

    Points: 2
    Helpful Answer Positive Rating
barry said:
You can't really check this for timing-it's indeterminate (even if you know all the propagation delays, etc) because of the non-integer relationship between the two clocks. Is this an FPGA or ASIC design? If so, then depending on the specifics of this circuit you may want to give it a relaxed constraint (like a multi-cycle or ignore). However, if this is a critical path then you're going to have to add a synchronizer or FIFO. There's no way (that I'm aware of) that you can guaranteed the exact timing of the output of the second ff. Using your timing diagram above, after the first A clock edge data will appear at the D input of the B ff. But at time 6, NEW data will be clocked out to the D input of B. Thus, the output of the B FF after the B rising edge at time 8 will be the SECOND data bit from A; the first one never gets clocked into B. Classic multiple-clock-domain problem.

I suggest you either add a FIFO or a multi-cycle constraint. You've got two different data rates. If the input rate were the slower one then it would be a different story (but still messy). There's a lot of info out there about clock-domain crossing, synchronizers, etc. Check them out.
Click to expand...

I think we can still check timing for these two flops. I don't agree with Barry. One thing most people here are confusing is that both the FFs are not positive edge triggered. Launch flop is rise edge triggered and capture flop is Falling edge triggered. Also, the two clocks are in phase, c'mon see the edges lining up at 0 and then 12ns and again at 24ns. Let's not get all delusional instead lets stick to the given facts. The reason that the figure has waveform drawn for 24ns is because the LCM of 6 and 8 is 24. Next, you gotta figure out what the cycle adjust is between the two clocks. Its ofcourse not a full clock cycle, neither is it half of 6 ns or 8ns clock. Cycle adjust calculation is what is shown how it is calculated. Possible candidates are:
1. Data launched at 0ns and captured at 4ns. This gives 4ns as candidate.
2. Data launched at 6ns and captured at 12ns. This gives 6ns as candidate but since we already have lesser value from #1, throw it out.
3. Data launched at 12ns and captured at 12ns. This gives 0ns as candidate but its not accepted as cycle adjust, throw this out too.
4. Data launched at 18ns and captured at 20ns. This is less than #1 and hence the correct cycle adjust.

What cycle adjust of 2ns will mean is that, there can only be data path delay of 2ns on this path (assuming zero clock skew) to avoid setup violation.
Hold timing doesnot depend on clock frequency so lets leave that out.
If its greater than 2ns, manipulate clock skews.

Thanks,
 
Last edited:

huckle said:
I think we can still check timing for these two flops. I don't agree with Barry. One thing most people here are confusing is that both the FFs are not positive edge triggered. Launch flop is rise edge triggered and capture flop is Falling edge triggered. Also, the two clocks are in phase, c'mon see the edges lining up at 0 and then 12ns and again at 24ns. Let's not get all delusional instead lets stick to the given facts. The reason that the figure has waveform drawn for 24ns is because the LCM of 6 and 8 is 24. Next, you gotta figure out what the cycle adjust is between the two clocks. Its ofcourse not a full clock cycle, neither is it half of 6 ns or 8ns clock. Cycle adjust calculation is what is shown how it is calculated. Possible candidates are:
1. Data launched at 0ns and captured at 4ns. This gives 4ns as candidate.
2. Data launched at 6ns and captured at 12ns. This gives 6ns as candidate but since we already have lesser value from #1, throw it out.
3. Data launched at 12ns and captured at 12ns. This gives 0ns as candidate but its not accepted as cycle adjust, throw this out too.
4. Data launched at 18ns and captured at 20ns. This is less than #1 and hence the correct cycle adjust.

What cycle adjust of 2ns will mean is that, there can only be data path delay of 2ns on this path (assuming zero clock skew) to avoid setup violation.
Hold timing doesnot depend on clock frequency so lets leave that out.
If its greater than 2ns, manipulate clock skews.

Thanks,
Click to expand...
You cannot do a timing analysis on async paths. That's the nature of asynchronous logic and data gets captured by whatever clock edge available.
So, analyzing the timing in the above diagram with 2ns cycle window has no value.

Furthermore, if the logic meets 2ns path delay as you said, you would have a hold violation at 6ns to 8ns.
 
  • Like
Reactions: sam33r

    sam33r

    sam33r

    Points: 2
    Helpful Answer Positive Rating
lostinxlation said:
You cannot do a timing analysis on async paths. That's the nature of asynchronous logic and data gets captured by whatever clock edge available.
So, analyzing the timing in the above diagram with 2ns cycle window has no value.

Furthermore, if the logic meets 2ns path delay as you said, you would have a hold violation at 6ns to 8ns.
Click to expand...

Why you call the clocks asynchronous, What more do you you ask for when the waveform edges line up as they are shown.
I never said there would be a hold violation. Its not dependent on your clock waveform - all that is there. A 2ns data path delay normally should not normally have hold problem.
 

Okay, this is what is my own humble opinion.

The circuit captures the 0,1,3 bit of a 4 bit serial data stream.

Your max data delay (-> setup time ) should be less than the time from pos edge of first clock to the neg edge of second clock in the portion marked green with a circle.

Your min data delay (- > hold time ) should be more than zero ( the point where the neg edge and pos edge meet)

You can add OCV, PLL jitter, setup & hold time of the flops for a more comprehensive analysis.
 

huckle said:
Why you call the clocks asynchronous, What more do you you ask for when the waveform edges line up as they are shown.
I never said there would be a hold violation. Its not dependent on your clock waveform - all that is there. A 2ns data path delay normally should not normally have hold problem.
Click to expand...

Be very careful when you say hold violation doesn't depend on your clock waveform. In this case what is the design intent ? You can design for worst case setup, but you could easily run into hold problem if driver flop captured new data on back to back clock edges.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top