Hi,

Am Sonntag, 23. April 2017 15:37:50 UTC+2 schrieb David Bridgham:
> And there's my question.  Will the AND gate implementation in an FPGA do
> that?  Or are LUTs odd enough that I can't depend on it?  If the answer
> is FPGA specific, I'm using an Artix 7 FPGA.

About the LUT itself a lot told you in this thread. 
But be aware that your verilog code will be optimized by synthesis tool. Usually synthesis tools don't care about glitch free result, so you need to ensure your final result is glitch free. 

regards Thomas

> more common back in the day, the entire industry has gone synchronous
> since sometime back in the 1960s and so there must be a reason.  Yep,
> probably.
> 
> What I'm thinking of is more along the lines of the Balsa synthesis
> system from University of Manchester.

OK, as long as you know what you're getting into.  If you want to publish papers, that's great, but if you have something to deliver on a deadline, I'd avoid this whole line of thought...

On Wed, 26 Apr 2017 13:38:11 -0700, Kevin Neilson wrote:

> I don't know what you are trying to do but that description almost
> sounds like what Achronix was doing when they started out.  You'll
> observe, that despite their name, they eventually switched to
> synchronous logic.

I'm not familiar with Achronix but I know of one other asynchronous FPGA
project that ended up being flushed.  Certainly this line of argument is
similar to a friend's who keeps pointing out to me that, while async was
more common back in the day, the entire industry has gone synchronous
since sometime back in the 1960s and so there must be a reason.  Yep,
probably.

What I'm thinking of is more along the lines of the Balsa synthesis
system from University of Manchester.

http://apt.cs.manchester.ac.uk/ftp/pub/apt/papers/FDL00.pdf
http://apt.cs.manchester.ac.uk/ftp/pub/apt/balsa/

On 4/26/2017 4:38 PM, Kevin Neilson wrote:
>> The other way to provide timing is to have the logic signals
>> themselves come with their own, inherent validity signal.  Delay
>> insensitive (or quasi-delay insensitive) is the name for this idea
>> and the dual-rail encoding that I referred to is one way to
>> implement that.
>>
> I don't know what you are trying to do but that description almost
> sounds like what Achronix was doing when they started out.  You'll
> observe, that despite their name, they eventually switched to
> synchronous logic.

When push came to shove the async logic aspect was not as important as 
it was to just make fast FPGAs which Achronix did by getting a leg up on 
the major FPGA players by using Intel's 22 nm FINFET technology.

The part I don't get is that Intel has bought Altera, so the fab service 
contract with Achronix is now competing with another Intel arm (pun 
intended).

-- 

Rick C

> The other way to provide timing is to have the logic signals themselves
> come with their own, inherent validity signal.  Delay insensitive (or
> quasi-delay insensitive) is the name for this idea and the dual-rail
> encoding that I referred to is one way to implement that.
> 
I don't know what you are trying to do but that description almost sounds like what Achronix was doing when they started out.  You'll observe, that despite their name, they eventually switched to synchronous logic.

On Mon, 24 Apr 2017 16:36:15 -0700, Kevin Neilson wrote:

> Writing your own tools is probably quixotic.

No question that my own design tools (also a simulator) is quixotic.
Gotta dream big.

On Mon, 24 Apr 2017 16:54:55 -0400, rickman wrote:

> I am not current on async designs, but I believe at least some async 
> designs are self timed.  This actually puts more rigorous requirements 
> on delays as the timing path has to be slower than the logic path.

There are two general ways I know to provide async timing.  One is to
have timing circuits run in parallel with the logic circuits and this
implies the timing requirements you mention here.

> But someone pointed me to info on a method of using the logic to
> provide the timing signal.  It makes the logic much larger though.
> Not sure what it does to the real world, useful timing.

The other way to provide timing is to have the logic signals themselves
come with their own, inherent validity signal.  Delay insensitive (or
quasi-delay insensitive) is the name for this idea and the dual-rail
encoding that I referred to is one way to implement that.

It definitely results in larger logic circuits but proponents argue that
that's balanced by no longer needing all the complication of carefully
tuned H-trees for clock distribution.  Obviously FPGAs have the clock
distribution networks already so using an FPGA to implement async design
doesn't see any benefit on that side of things.  I'm interested in FPGAs
for this only because they're a really convenient source of programmable
logic.  I can swing programming an FPGA; I can't manage doing my own
custom VLSI.  FPGAs could let me experiment with the idea which is
really my intermediate goal.

On Mon, 24 Apr 2017 13:03:17 -0400, rickman wrote:

> On 4/24/2017 12:30 PM, Marko Zec wrote:
>> Gabor <nospam@nospam.com> wrote:
>> ...
>>> AND gates in an FPGA work like real AND gates.  The LUTs are designed
>>> not to glitch when inputs change, but the output should remain the
>>> same.
>>
>> As the claim about glitch-free properties of FPGA LUTs has surfaced
>> here repeadetly, could you cite some vendor-specific documents where
>> you draw such conclusions from?
> 
> This doesn't seem to be documented in any data sheet or app note that
> I've found, but you can get verbal confirmation.  Here's a link where a
> Xilinx representative confirms it in a forum conversation, twice.
> 
> https://forums.xilinx.com/t5/7-Series-FPGAs/data-strobe-decoder-
combinatorial-loops-R-S-latches-and-LUT/td-p/567448
> 
> 
> The reason they are glitch free is because of the use of pass
> transistors as the muxing elements.  A 4 input LUT has 16 memory
> elements and a number of series pass transistors.  Only one path through
> the pass transistors is turned on at a time.  The logic is timed so they
> are break before make.  This leaves the output of the switches in a high
> impedance state briefly during a change and the parasitic capacitance is
> enough to hold the logic state.  It's that simple.


It's in XAPP024.pdf, which doesn't seem to be on Xilinx's web site.

This is for the XC3000 series.  I understand that more recent series 
(about 10 generations now!) behave in a similar manner, but you won't 
find any documentation saying that it's so.


Here's something written by Peter Alfke in a this thread from 2001:
https://groups.google.com/d/msg/comp.arch.fpga/F6AYhYzDmi0/w14s0Cuw-x8J



"Here is what I wrote ten years ago ( you can find it, among other 
places, in the 1994 data book, page 9-5:

"Function Generator Avoids Glitches
...
Note that there can never be a decoding glitch when only one select input 
changes. Even a non-overlapping decoder cannot generate a glitch problem, 
since the node capacitance would retain the previous logic level...
When more than one input changes "simultaneously", the user should 
analyze the logic output for any intermediate code. If any such code 
produces a different result, the user must assume that such a glitch 
might occur, and must make the system design immune to it...
If none of the address codes contained in the "simultaneously" changing 
inputs produces a different output, the user can be sure that there will 
be no glitch...."

This still applies today.

Peter Alfke, Xilinx Applications
============================================="



Regards,
Allan

> Oh, that's interesting.  Part of my plan for doing async design is to
> develop my own tools as well.  I thought I couldn't use FPGAs to realize
> my designs but if that's not the case that'd be really useful.
> 
> > If you want to code at the level of LUTs, then you can do whatever you 
> > want with FPGAs.  You can even use HDL, it's just a lot harder than 
> > synchronous design, a LOT harder.
> 
> At some point, then, I'll have to learn about how one codes at the level
> of LUTs.  That project is for the future though.

I had to instantiate LUTs recently (as a last resort) and it was pretty straightforward.  But why would you want to do this?  Just resync your async signals to a clock.  Writing your own tools is probably quixotic. 

On 4/24/2017 3:51 PM, David Bridgham wrote:
> On Mon, 24 Apr 2017 12:25:46 -0400, rickman wrote:
>
>> It's not so much that LUTs can't be used for asynchronous designs,
>> rather the tools don't lend themselves to asynchronous design analysis.
>> In fact, the tools can optimize away some of the logic unless you know
>> how to prevent that.
>
> Oh, that's interesting.  Part of my plan for doing async design is to
> develop my own tools as well.  I thought I couldn't use FPGAs to realize
> my designs but if that's not the case that'd be really useful.
>
>> If you want to code at the level of LUTs, then you can do whatever you
>> want with FPGAs.  You can even use HDL, it's just a lot harder than
>> synchronous design, a LOT harder.
>
> At some point, then, I'll have to learn about how one codes at the level
> of LUTs.  That project is for the future though.

One way is to write behavioral HDL code and apply attributes to keep 
signals as wires and to not combine with other logic.  In some FPGA 
families you can instantiate LUTs.  I haven't done any of this in 
decades, so I don't know anything about it anymore.  Someone was posting 
about this not too long ago, maybe earlier this year.

-- 

Rick C