Passing data between clock edges (any design notes to take)?

Dear Experts,

I have part of the design sensitive on rising_edge and reset on falling_edge of the same clock.

Looking at register path, I have enough margin to satisfy setup and hold time. So the data register should be bullet proof.

Just wondering if there is any design principle I shall take why design these kind of circuitry.

Any comments are welcomed.

Regards,

Is this ASIC or FPGA? How fast is this clock?

It's targeting FPGA, fastest clock rate: 200MHz.

Then this design wont be , or very difficult. You're essentially looking for a setup and hold time of 400 Mhz (limits of FPGA) if you need it reset by the falling edge. But that is a very odd scheme. Why have you done this?

TrickyDicky said:

Then this design wont be , or very difficult. You're essentially looking for a setup and hold time of 400 Mhz (limits of FPGA) if you need it reset by the falling edge. But that is a very odd scheme. Why have you done this?

Click to expand...

Thanks for reply, I am looking at building DDR type of data capturing. Data captured on the falling edges will have to be transferred to rising edge clock driving registers. I can do FIFO, but I assume if direct register passing works, it's simpler.

So is this an issue with DDR registers and having resets?

legendbb said:

I have part of the design sensitive on rising_edge and reset on falling_edge of the same clock.

Click to expand...

Thanks for reply, I am looking at building DDR type of data capturing. Data captured on the falling edges will have to be transferred to rising edge clock driving registers.

Click to expand...

If the registers are data and not control, do they really need resets? I've seen so many instances of engineers using resets on the entire datapath when it doesn't mater if the data isn't valid from reset. They seem to forget that a reset has to be routed over the entire die from a single source so will have 1000's or 10000's of loads.

If your DDR register is for data then I would suggest not having a reset on it, and make sure you have a timing constraint that covers the rising-falling or falling-rising data setup/hold paths. If there is a DDR control path involved keep the reset but also include an isolated DDR specific reset (assuming you are using a synchronous deassert) to reduce fanout to the more critical timing paths into the opposite edge triggered FF.

Regards

ads-ee said:

If the registers are data and not control, do they really need resets? I've seen so many instances of engineers using resets on the entire datapath when it doesn't mater if the data isn't valid from reset. They seem to forget that a reset has to be routed over the entire die from a single source so will have 1000's or 10000's of loads.

Click to expand...

Exactly! So many times people insist on "But I must reset this, because I learned that stuff in class. I like repeating things without applying some original thought!". Reset circuitry is there for a purpose. Are you sure what the purpose is of resetting everything? Because if the answer is "but but but, I must have a know state!" then I suggest reading the configuration sections of the fpga docs.

Alernative version: after configuration, all registers in your design should be in a known state. Only a small subset of registers will require a reset AFTER configuration.