Spartan® Family FPGAs

[corran42]

Hello,

I have an application where I was hoping to read in a single signal, but apply multiple programmable temporal delays (by using many IODELAY2's on asynchronous copies of the one signal).  These multiple asynchronously delayed copies of the same signal would then finally be synchronously read into the FPGA fabric.  I'm using the SP605 development board.

My strategy was (ex. for 2 copies of input signal):

--pinin--> IBUF

--IBUF --> sigraw (asynchronously assigned in FPGA fabric)

--sigraw --> IOBUF1 

--IOBUF_1 --> IODELAY2_inst1  --> delayedsig1

--sigraw --> IOBUF2 

  --IOBUF_2 --> IODELAY2_inst2  --> delayedsig2

The IOBUF's are configured to give a variable delay as described here: http://www.xilinx.com/support/answers/34276.htm

However, this fails at PAR as 'sigraw' refuses to route.  I'm guessing I'm illegally tying together 1 IBUF directly to multiple IOBUF2's.  After reading the documentation in UG381 (SelectIO resources), I'm unsure whether there is a workaround.  Any ideas, or is this capability just not possible?

Oh, and I know about the warnings about the absolute timings of IODELAY2 not being guaranteed, and the need for calibration of the delay.  Even with these caveats, I was still hoping to achieve the above.  Thanks for any help.

[gszakacs]

Maybe there's another way to accomplish what you're trying to do.  For example a long

time ago I remember seeing an App Note (I think it was written for Virtex E) that described

how to use carry chains as delay elements.  The basic principle was that you put your

input signal into the carry chain and register the chain at each bit position to get a large

number of successive input delays.  Then you would select the delay you want by using the

output of the associated register.  I think you may find that the carry chain delays in

Spartan 6 are not monotonic as they were in the older Virtex series, but perhaps something

like this could still help in your application.

-- Gabor

[ccon67]

So I guess your PAR is still failing, or you've got it work ?

Anyway, at least there's another approach and it should work... I'm not familiar with SP605 but assume you can modify the board:

You need to route that signal to an output pin, and then feedback to multiple (fanout) others input pins.  Now on each input you can constraint the IODELAY_n as you want

[corran42]

Thanks for the suggestions.  

Gabor--I was hoping to get the extremely small asynchronous time delay steps that IODELAY enables (tens of picoseconds).  Perhaps you can comment if carry chains would still be appropriate.

ccon67--Thanks for the tip, but I don't want to modify my board.  It's either accomplish it all via FPGA internal routing or don't do it at all.

To add to my first post, the programmable output IODELAY part seems to be routing OK.  I'm just surprised that I haven't been able to asynchronously take an input, do a fan out asynchronously in the FPGA fabric, and then asynchronously put the fanout into the individual IOBUFs.  It seems like this fanout should be doable (if I'm willing to accept all the hazards of these asynchronous operations).  

Any further ideas?

[gszakacs]

I built a test project to see if the carry chain idea would work in S6.  What I found is that

the carry chain delay is not monotonic within a group of 4 bits (due to "look-ahead") but

each group of 4 bits has a delay of something under 100 ps with respect to the next lower

4 bits.

Take a look at the attached code and run the test bench in post-route simulation mode.

What you will see is that as the input data slides past the clock edge, the bits turn on

or off one or two at a time, but not in order.  However groups of 4 bits behave similarly

to other 4-bit groups.

-- Gabor

[corran42]

Thanks for supplying the example project Gabor.  However, I'm not sure it will work for my application.  I believe I need individually programmable time delays applied to asynchronous copies of a single input signal.  It appears the signal is read in synchronously...am I mistaken?

Let me clarify a bit.  I want to use the FPGA as a coincidence counter between two input signals with sub-clock period resolution.  The two input signals are not synchronized with the clock of the FPGA, are approx 20 ns in duration, arrive roughly every 1 microsecond, and should only be counted as 'coincident' if their posedge's arrive within, say, 1 ns of one another.  With the 400 MHz clock on my current program, this obviously isn't possible in a simple coincidence counter as the temporal resolution isn't sufficient.  

However, IODELAY does supply a very fine temporal resolution, in a way.  The hope was to take a signal in, copy and fan it out, then run these copies through individual IODELAY elements--all of this would be done asynchronously and hopefully totally internal to the FPGA (no external routing out and back in via the PCB).  Say you have two raw signals, and each are fanned out into 10 IODELAY elements that are programmed to give delays in approx 250 ps steps (0, 250 ps , 500 ps , 750 ps etc delays on input A....and the same replicated on input B).  Now, all these asynchronously delayed copies are checked on every posedge clk.  Checking the relative number of delayed copies that are high from each detector gives finer temporal resolution on their relative arrival times.  For example, when posedge clk arrives, if A has 3 delayed copies high and B has 4, then they arrived within 1 ns of one another.  If A has 3 copies high, and B has 9...then they arrived more than 1 ns apart.

I'm still an FPGA newbie and am unsure if this is possible.  I thought it was impossible to do this all internal to the FPGA, because it requires, effectively, a programmable output IODELAY...which I read wasn't possible.  But this webnote showed a workaround for that:  http://www.xilinx.com/support/answers/34276.htm  .  However, I've had trouble actually accomplishing the asynchronous fanout of an input signal to multiple IOBs.  So, I can get a variable output delay, but I can't asynchronously copy the input and route it to these programmable output delays.  However, it's very possible I'm making a silly mistake.

Any thoughts?  This is definitely far outside what IODELAY was intended for (I think), but it would be a really neat capability.

[ccon67]

---

corran42 wrote:

I'm still an FPGA newbie and am unsure if this is possible.  I thought it was impossible to do this all internal to the FPGA, because it requires, effectively, a programmable output IODELAY...which I read wasn't possible.  But this webnote showed a workaround for that:  http://www.xilinx.com/support/answers/34276.htm 

-----------------------------------------------------------------

Yup, the schematic in the link is do-able.  that's good idea, you don't have to route the sinal to the outside then re-enter the FPGA as I though.   It's kind of cheating the PAR by fanout the signal to unused IO, so that you can ultilize the its IDELAY element

Remember, it's the input programmable delay you gonna use,...and there's no such thing call "programmable output delay" as you mentioned

regards,

[gszakacs]

Thanks for supplying the example project Gabor.  However, I'm not sure it will work for my application.  I believe I need individually programmable time delays applied to asynchronous copies of a single input signal.  It appears the signal is read in synchronously...am I mistaken?

The signal is read in "synchronously" by many flip-flops, each with a different input setup time.  This is

similar to running the signal into a tapped delay line and then sampling it at each tap.  Theoretically

you could create a delay line that has a total delay of one cycle of the system clock and use it to

effectively sample the input N times per clock period, where N is the number of taps in the delay

line.  Unfortunately these delays are not calibrated.

An example of the behavior when you receive a 1 ns pulse in a 10-tap delay line totalling 2.5 ns

(your clock period at 400 MHz) might look like:

0011110000 - Pulse comes about 0.5 ns after the start of a clock period

0000000011

1100000000 - Pulse straddles the system clock edge

Note that the bits from each flip-flop correspond to a different sampling time of the input.

If you only need 4 samples per system clock, then you can use 4 phase outputs of a DCM

or PLL to clock 4 flops.  The problem you will always have is that when using general

routing to feed the signal into each flop, the sampling time difference can depend as much

on the routing delay as on the clock phase.  Using a carry chain has the advantage of

using dedicated carry routing between taps (although you still have general routing delays

to the start of the carry chain).

I think that any way you slice this problem, it is not easy to get accurate measurements of

this type.

-- Gabor

[corran42]

Thanks for the explanation, now I understand what you're proposing with the carry chain.  I agree, that should work in principle.  I'll try to implement and test it.  I'm envisioning a fair amount of calibration: put in two signals with known time separation and see how the individual carry chains for each input respond, and how stable the response is over time.

On a separate note, I'm still curious if it is possible to perform an asynchronous fan out of an input signal straight to multiple output buffers.  I thought this would be trivial, and was surprised when I ran into so much trouble!  If anybody has suggestions, they'd be appreciated.  Thanks!