0
\$\begingroup\$

In my FPGA design, I have some input signals that need to be delayed considerably before they reach the first clocked register. There are delay elements near the pins for exactly that purpose, but their maximal delay is still too low.

So I want to force the signals on a detour through the FPGA in order to achieve the required delay. I realize this is not "by the book", but maybe others have been in the same situation.

Question: Are there some "best practice" rules for this kind of thing?

Provided that the required delay can be achieved "on paper" in both ways, which is to be preferred: signals travelling great distances or signals going through combinatorial logic? What kind of logic is best suited for that purpose (LUT, carry chain,...)?

If you're an experienced designer and can't think of any difference, that too would be useful information.

I'm using an Altera Cyclone V, but the question should be answerable in general.

\$\endgroup\$
  • \$\begingroup\$ Your requirements seem quite strange to me. Why do you need to delay the signal before reaching synchronous logic? This appears to be an XY problem meta.stackexchange.com/questions/66377/what-is-the-xy-problem. \$\endgroup\$ – user110971 Feb 23 '18 at 15:27
  • 1
    \$\begingroup\$ @user110971: I know that thread. Its premise seems to be that every asker wants a complete solution to all of his problems. But I don't want someone else to solve X for me. I've asked about Y. \$\endgroup\$ – Stefan Feb 23 '18 at 16:12
  • \$\begingroup\$ If you provide some more information about why you have decided you need to do the asynchronous delay, I can give you some advice on a better solution. The premise of the XY problem is that you think Y solves X and you focus on Y. While there is a solution that solves your original problem X in a much easier way. \$\endgroup\$ – user110971 Feb 23 '18 at 16:23
  • \$\begingroup\$ @user110971: As I said, I don't want advice on X and accept the possibility of missing out on a much easier solution. Or rather, I trust in my ability to judge that there is none. \$\endgroup\$ – Stefan Feb 23 '18 at 16:38
  • \$\begingroup\$ Not a general answer, nor an answer for your situation (Cyclone) and a link-only, but this Lattice document describes the procedure for their IDE. \$\endgroup\$ – Spehro Pefhany Feb 23 '18 at 17:21
3
\$\begingroup\$

What I've done in a recent design is to multiply up the clock frequency and use a clocked delay. That can get me granularity in the sub-5ns region with a cheap FPGA.

This document from Lattice describes how to do exactly what you are asking (fool the compiler into not optimizing out the buffers).

\$\endgroup\$
2
\$\begingroup\$

Synchronize the input and delay it with the appropriate amount of flip-flops would be the way I'd implement it. What is your clock frequency and required input delay? Is a certain variance in delay acceptable?

\$\endgroup\$
1
\$\begingroup\$

It's quite difficult to stop the PAR 'optimising out' intentional delays.

While this suggestion is not 'best practice', it works as long as you have some spare pins. Choose a number of pins on opposite sides of the device, and put their pin numbers into the constraints file. Then run your signal from one to the next I/O. The PAR will be forced to route the signals across the chip and back. There's no need to actually have the signals driving the external pins, you can keep the outputs tri-state, although a sniff of capacitance on the external pin can add more delay if you do route it through the pin itself.

\$\endgroup\$
  • \$\begingroup\$ Thanks, that's a good idea if I really can't get him not to optimise. \$\endgroup\$ – Stefan Feb 23 '18 at 16:51
1
\$\begingroup\$

As you said: that is not recommended. I am also not sure that it is needed. The main reason to delay an input signal is so that it does not fall within the set-up and hold time of you register. The I/O pad delay should be more then enough for that.
Another way to deal with the problem is to see if you can use the opposite clock edge. It is not ideal but sometimes you have to.

I have the feeling that this is another case of "Tell us your problem, not your solution".


If you want to add another delay you have to use something which can not be optimised out. You can try to use an adder where the second input can be "programmed". You just never program it with any other value then zero. Something like:

reg [x:0] dummy;
    assign delayed_signal = signal + dummy;

always @(posedge clk or negedge reset_n)
   it (!reset_n)
       dummy <= 'b0;    
   else
      if (load_dummy)
         dummy <= {dummy,dummy_input};

Now you have to make sure that "load_dummy" and "dummy_input" are valid signals which somehow can change but never do. e.g. from a CPU register or from two input ports which are tied off.

But I suspect the delay will:

  • Be very small.
  • Not the same for all bits.

A better alternative, very accurate but more difficult, is to use an internal high speed clock to 'clock' the signals through.

\$\endgroup\$
1
\$\begingroup\$

Yes, there is a best practice: Do not delay in combinatorial logic!

If you are not using double-data-rate, then choose the appropriate edge of the external clock.

In case of double data rate --- or if external clock is plesiochronous to internal logic --- use a PLL to recover and phase-shift the external clock. Then put a dual clock FIFO between the new clock domain and your internal logic.

\$\endgroup\$
0
\$\begingroup\$

You could use a counter and a buffer? Put your data in a buffer and reset the counter. Use whatever clock and counter value you need to give you the required delay, then use a comparison of the counter output to enable the buffer output so that it spits out the data, or clocks it into wherever it's supposed to go?

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.