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.

Clock in the Data Path - BAD IDEA - WHY ?

Status
Not open for further replies.

rohit_singh1

Junior Member level 3
Joined
Jan 28, 2011
Messages
29
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,283
Activity points
1,495
Hi All,

Referring to the attached figure (which I pulled from a blog that talks about double-edge triggered FFs), the author goes on to point out that this implementation is not good. That's because its a bad idea to have a clock in the data path. Could anybody explain me why this is so ?

Any help is appreciated.
TIA
Rohit
 

Attachments

  • deff2.png
    deff2.png
    9 KB · Views: 132

Because you have 2 levels of clocking on a path and it can easily cause setup/hold viols down the path.
 

You'll find similar construct (multilexers operated by a clock) in DDR interfaces, here's a DQ output cell from a Cyclone III FPGA. I think, they can't be avoided when dealing with double edge clocked circuits in FPGA or ASIC design. In both case, the clock driven multiplexer won't cause timing violations, but possibly glitches.

11_1296249246.gif
 

You'll find similar construct (multilexers operated by a clock) in DDR interfaces, here's a DQ output cell from a Cyclone III FPGA. I think, they can't be avoided when dealing with double edge clocked circuits in FPGA or ASIC design. In both case, the clock driven multiplexer won't cause timing violations, but possibly glitches.

11_1296249246.gif


Could you please explain how/why ?
 

In a perfect world, it works, but the life isn't perfect. If you have a skew between clock pin of the flop and mux select, data width changes depends on the process corner.

Of course, if you did a very careful timing analysis, you can make it work, but you need to be extra careful.

I have done exactly the same logic before. it was a debug interface on a microprocessor and we only had 64bit data bus, but wanted to output as much data as possible to make the debugging easier. We muxed 128 bit data into 64bit with a double pumping mechanism exactly like the picture. The issue is if you have 128 flops and muxes, you can't drive all of them at a single clock net therefore you have to buffer it, which creates clock branches. That makes some clock skews between some flops and muxes which results in shorter data time or longer data time depending on how the skew is and process corner etc.. We made it with a custom circuit to make sure there are no skews between the flops and muxes.
 
Last edited:
Could you please explain how/why ?
The circuit is needed to drive double data rate outputs, which are basically multiplexing two signals to a single pin. Their purpose doesn't need to be explained in this context, I think. Timing violations can only happen down the path, if the multiplexer output is driven without sufficient delay to the next register. But it won't make much sense to sent the mux output to same clock domain register without additional logic in between. Glitches must be expected, because the multiplexer is switching to early, the new register output will reach it after a transition delay. So for a practical circuit. e.g. a DDR-RAM driver, the clock to the multiplexer will be delayed, e.g. by additional logic gates. Timing violations can be avoided by similar means, if necessary.
 
I think its because of cross talk....we dont preffer signals and clocks crossing over...
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top