Inffering logic delays in an asynchronous FPGA design

[shaiko]

I'm working on an asynchronous ( completely clockless ) design on on Actel Igloo FPGA.
To avoid race conditions, I'd like to inffer logic delays between signals:

delayed_a_signal <= a_signal ;
I want "a_signal" to be transffered to "delayed_a_signal" after a time delay.

How can I achieve this ?

 

[TrickyDicky]

you cannot infer actual delays, you can only do it by routing signals through extra LUTs. Altera used to have an AHDL function called LCELL to do exactly this, but now I think you have to do it via the assignments editor to prevent it stripping out "uneccesary" LUTs.

Be warned, LUT delays are prone to vary with temperature, so they are never very favourable.

 

[shaiko]

What about Actel?

 

[xtcx]

How about using logic gates to delay?..

 

[mrflibble]

If by logic gates you mean flip flops ... then it will depend.

On what will it depend? On your level of pedantics. Because depending on how pedantic you feel that day you may argue for or against it then still being a "clockless design".

If you want it to be really clockless, you cannot use a flipflop. What you could do is:

1) like TrickyDicky suggest use the routing delays.

or

2) use a transparant latch while making damn sure that you don't use any clock anywhere near that latch. That is the latch will just be a tiny delay element, no clocking.

If you need short delays you can place your elements close together on the die and just use routing. If you need somewhat longer delays you can use one or more latches. And you can also use carry chains.

Oh yeah and slap on a heat sink if your design takes up any significant portion of the fpga. Large amounts asynchronous logic == no longer igloo.

 

[std_match]

If you can create delays, you can create a ring oscillator and do a normal synchronous design for the project.
That will save you a lot of time and headache.

I have not used this FPGA family, but a quick look in the documentation shows that a "routed clock" is probably what you need. If you create a ring oscillator, possibly followed by an asynchronous (ripple) or synchronous counter, and use the output as a "routed clock", the rest of the design can be synchronous.

 

[mrflibble]

I'm not sure if a ring oscillator qualifies as "normal synchronous design" in the context of an fpga. But in principle you're correct. You get an oscillator that will burn lots of power and have poor jitter characteristics. Clocking with a ring oscillator doesn't really qualify as "headache prevention". However the headache you get will probably be less severe compared to doing the whole thing async.

But hey, I doubt the objective here is "no headache". At least I hope so, because asynchronous anything is asking for trouble on an fpga. So we'll have to assume shaiko has a good reason to take the async route.

Anyways, async design on fpga IS FUN as far as I am concerned. You learn a lot. But it is not recommended design practice.

 

[std_match]

I'm not sure if a ring oscillator qualifies as "normal synchronous design" in the context of an fpga. But in principle you're correct. You get an oscillator that will burn lots of power and have poor jitter characteristics.

Since it is easy to start/stop a ring oscillator in no time, it is probably possible to have it running only when something happens. The start/stop logic will be partly asynchronous, of course.

 

[mrflibble]

That is indeed entirely possible. Amusingly enough that is a good way to get even worse jitter characteristics. Oscillator startup and all that.

Anyways, back to the OP: Yes you can make asynchronous designs in fpga. It's not really the most obvious choice, and you will have to fight the tools to get things working juuuust right. FPGA tools are highly optimized for synchronous designs, so async is large amounts of DIY. But hey, it's fun.

 

[std_match]

I agree that the ring oscillator can have a lot of jitter and bad stability, but not bad reliability. If the generated frequency is so low that the setup timing is met even in the worst-case situation, the jitter will have no effect on the operation of the synchronous logic driven by it. There are microcontrollers that can be run from an internal ring oscillator, and that operation has no reliability problems. A ring oscillator with sufficient total delay can not have startup problems.

 

[xtcx]

If by logic gates you mean flip flops ... then it will depend.

On what will it depend? On your level of pedantics. Because depending on how pedantic you feel that day you may argue for or against it then still being a "clockless design".

If you want it to be really clockless, you cannot use a flipflop. What you could do is:

1) like TrickyDicky suggest use the routing delays.

or

2) use a transparant latch while making damn sure that you don't use any clock anywhere near that latch. That is the latch will just be a tiny delay element, no clocking.

If you need short delays you can place your elements close together on the die and just use routing. If you need somewhat longer delays you can use one or more latches. And you can also use carry chains.

Oh yeah and slap on a heat sink if your design takes up any significant portion of the fpga. Large amounts asynchronous logic == no longer igloo.

No, I meant AND\OR gate (LUT) element as a delay element. Cascaded LUT can be used to insert long delays instead of using long route lines
Also, I wonder what "Trickydicky" said about temperature affecting the LUT delays....

---------- Post added at 17:01 ---------- Previous post was at 16:58 ----------

Why LUTs delays are prone to change in temperature?.