How to increase max frequency due to half cycle constraints

Click For Summary

Discussion Overview

The discussion revolves around the design of synchronous logic using negative edge flip-flops to shift data out of a chip, particularly in the context of the IEEE1149.1 standard. Participants explore the constraints on maximum clock frequency due to half-cycle limitations and the physical layout of the chip affecting signal timing.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Experimental/applied

Main Points Raised

  • One participant describes the timing constraints affecting maximum clock frequency, including setup and propagation times of various flip-flops and the impact of clock skew due to physical distance on the chip.
  • Another participant suggests that minimizing long signal paths and optimizing the clock tree layout could improve performance.
  • A participant expresses uncertainty about the clock tree design and notes the challenges posed by the chip's large size and partitioning, which complicates grouping fast logic together.
  • There is a mention of the typical operational speed of JTAG at 10 MHz, with a desire to improve this speed while addressing the half-cycle limitation between positive and negative edge flip-flops.
  • A later post questions whether the current design constraints are insurmountable and seeks methodologies for improvement.

Areas of Agreement / Disagreement

Participants do not reach a consensus on the best approach to increase maximum frequency, with multiple competing views on design strategies and challenges remaining unresolved.

Contextual Notes

Participants acknowledge limitations related to the physical layout of the chip, the design of the clock tree, and the inherent characteristics of JTAG interfaces, but do not resolve these issues.

Who May Find This Useful

Individuals involved in digital design, particularly those working with synchronous logic, JTAG implementations, or facing similar timing challenges in large chip designs.

flybanana
Messages
4
Reaction score
0
I'm trying to design a synchronous logic that uses a negative edge flop to shift data out of a chip (as part of the IEEE1149.1 standard). The input to this negedge flop is muxed from a whole bunch of shift registers within the chip, and these registers are all on posedges.

Ideally, if skew of clock signal between this negedge flop and the posedge flops that feed it is 0, then I know my max clock frequency is limited by
Tsetup of posedge flop + Tprop of input to output of posedge flop + Time to go through the mux + Tsetup of nedgedge flop.

However, some posedge register are situated far from the negedge flop physically on the chip, and in those cases, the clock for the posedge register is a delayed version of clock for the nedge flop, and that dramatically reduces my max clock frequency too.

Anybody have past experience designing this kind of logic and have suggestion as to how I can increase the the max frequency? (I can't want to change the clock edge dependcy of the flops)
 
Engineering news on Phys.org
If you want it to be fast, you shouldn't have long paths -- group the fast stuff toghether. Also, what does your clock tree look like?
 
I'm not too sure what the clock tree look like (somebody else did that part), but the chip is quite big and has many partitions, so I believe we have an entry point into each partition and then branches out to different logic within the partition that needs the clock.

Also because of the large size of the chip, some of registers that I mentioned that feed the TDO(test data out) negedge register is situated far away from TDO itself. But all the registers do need to go out through the TDO pad, so I am not sure what I can do to "group the fast stuff together".
 
How fast does your JTAG look so far in simulation? JTAG is not traditionally a blazing interface, mainly for the reasons that you are mentioning about the chip-wide nature of the scan chains.
 
10mhz - which is typical at most companies I think, but I'd like to look into improving that, more specifically to see if there's anything I can do about the half-cycle limitation from the posedge->negege nature of flopping the values into the final TDO register.
Thanks for your help!
 
So am I stuck with what I have? If anybody knows a methodology to do this, I'm much obliged. Thanks.
 

Similar threads

Replies
17
Views
6K
Replies
3
Views
2K