How to increase max frequency due to half cycle constraints

Join the discussion
Ask a follow-up here, or get your own question answered by working scientists, mathematicians and engineers — people, not an autocomplete.
Real named experts · corrections over time · the nuance an AI answer skips
Sign up Log in
5 replies · 4K views
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.