glitching AND gate

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I have a question about how FPGAs handle signals into combinational
logic.  I have following setup:

always @(posedge interrupt_check) interrupt_detect <= interrupt_request;

assign interrupt_ack = interrupt_request & enable;

The interrupt_request signal may happen at any time relative to
interrupt_check so I know that interrupt_detect may be metastable for a
bit.  However, enable is guaranteed to be asserted a minimum of 150ns
after interrupt_check so it ought to hold interrupt_ack low until
interrupt_detect is stable.

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.

I've considered "fixing" this by changing the AND gate to a flop with:

always @(posedge enable) interrupt_ack <= interrupt_detect;

but that has the problem that I'm left looking for a signal to clear
that flop at the right time.  I want to clear it when enable goes low
again but that's not allowed.

Thanks for any insight,
Dave

Re: glitching AND gate
On 4/23/2017 9:34 AM, David Bridgham wrote:
Quoted text here. Click to load it

I'm sorry but I can't picture the timing from your description.  You  
have two circuits with one input in common.  You then ask "Will the AND  
gate implementation in an FPGA do that?"  I don't understand what you  
are asking.

Are you saying that enable is not asserted *until* at least 150 ns after  
interrupt_check rising edge?  Or that enable is *held* for 150 ns after  
the interrupt_check rising edge?

Is the idea that interrupt_detect is not considered by other logic until  
interrupt_ack is asserted?  Or is interrupt_detect supposed to be  
conditioned by enable rather than interrupt_request?

--  

Rick C

Re: glitching AND gate
On Sun, 23 Apr 2017 15:51:33 -0400, rickman wrote:

Quoted text here. Click to load it

One input in common?  Well crap, I screwed up the verilog.  Try this
instead:

always @(posedge interrupt_check) interrupt_detect <= interrupt_request;

assign interrupt_ack = interrupt_detect & enable;

Quoted text here. Click to load it

If an actual AND gate has an input that's 0, the output will be 0
regards of the other input.  If the other input is 0, is 1, is a clock,
or even if it's somewhere in-between because the driver has gone
metastable, the output of the AND gate will be 0.  My question was, can
I depend on that from a synthesized AND gate in an FPGA?

Quoted text here. Click to load it

The former; enable is not asserted until at least 150ns after
interrupt_check rising edge.

Quoted text here. Click to load it

Both, I think.  Well, interrupt_detect is not used by any other logic,
only interrupt_ack.  interrupt_detect is internal to just what you see
there while interrupt_ack is the signal that goes on to the rest of the
logic.

To see more of the context of this question, I'm working on bus
arbitration circuitry for the Unibus and QBUS.  I'm writing up what I'm
doing in a short paper that you can find at the URL below.  The paper
isn't done yet but it's starting to get closer.

http://www.froghouse.org/~dab/papers/bus-arbitration/ba.html

Re: glitching AND gate
On 4/24/2017 8:46 AM, David Bridgham wrote:
Quoted text here. Click to load it

That's what I thought.  This makes sense.

The answer is that in the case of Xilinx parts it is well known that the  
LUTs are glitchless for any one input changing.  That is the real  
question you seem to be asking.

I believe this is also true for other manufacturers, but I've never  
explicitly asked.  The Lattice devices are derived from the Xilinx  
designs through a license bought from Lucent a long time ago.  So their  
fundamental LUT design is the same and should work the same.  The Altera  
parts are different in some ways, but I expect the aspect of the LUTs  
that make them glitchless is the same.

This comes from using transmission gates as the logic elements in the  
multiplexer that selects the output from the LUT.  The logic controlling  
the pass transistors is timed to break before make and the capacitance  
on the output line is enough to hold a value until the next transmission  
gate is turned on.  So if both driven levels are the same there is no  
glitch.


Quoted text here. Click to load it

I'll pass on reading the paper just now, but keep posting your progress.  
  I'd like to catch up on this effort at some point.

I used to have an LSI-11, but at some point someone convinced me to toss  
it out along with the 8 inch floppy drives, etc.

--  

Rick C

Re: glitching AND gate
On Mon, 24 Apr 2017 12:22:37 -0400, rickman wrote:

Quoted text here. Click to load it

Happy to.  The project itself lives on Github (look for dabridgham/QSIC)
and I occasionally post updates to the cctalk mailing list.

Re: glitching AND gate
On Monday, 4/24/2017 8:46 AM, David Bridgham wrote:
Quoted text here. Click to load it

I did a Unibus design back in the days of one-time programmable
(fusible-link) PALs.  I remember it was a bitch without using a
clock, but I got away without one by using at least one delay-line.
One thing I recall is that boards that actually plugged into the
bus had six connector sections, where the A and B sections were
not used.  The pinout of the other sections was in an internal
DEC document I got through some sort of third-hand source.  If you
look at the spec in DEC's external documentation, it only describes
the A and B sections.  However you quickly see that these can only
be used to bring bus signals in and out of a chassis, not to go from
board to board.  That's because they only have a single pin for
each daisy-chain signal.  The Qbus was much better documented.

--  
Gabor

Re: glitching AND gate
On Sunday, 4/23/2017 9:34 AM, David Bridgham wrote:
Quoted text here. Click to load it

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.
LUTs may glitch when multiple inputs change and some combination of
values during the change would cause the output to change.  However
this is usually due to the skew between inputs.  Also in an AND gate
of any size that fits in one LUT, any combination of other inputs
would not make the output go high, and therefore you should not get
a glitch on the outputs.

On the other hand, FPGAs are not really designed to do asynchronous
sequential logic well.  What you're trying to do is typically done
using a high-speed free-running clock to sample the input signals
and then make decisions synchronously.

--  
Gabor

Re: glitching AND gate
On Mon, 24 Apr 2017 08:30:06 -0400, Gabor wrote:

Quoted text here. Click to load it

I've read this before, that FPGAs are not really suitable for
asynchronous logic.  And yet, if the gates are glitch-free than I'm not
seeing the problem with doing what I'm suggesting here.  Converting the
input signals to synchronous seems like a bunch of extra work for
something that ought to be fairly straightforward.

In the larger picture, I do have a desire someday to play around with
asynchronous designs.  Not this project with the QBUS but a future
project, possibly even implementing an entire processor asynchronously.
Being able to use FPGAs would sure be easier than having to get out the
wire-wrap gun.

Re: glitching AND gate
On Mon, 24 Apr 2017 14:04:34 -0000 (UTC)

Quoted text here. Click to load it

Aren't there usually handy latches in the input buffer
structure? Better safe than frustrated...

  
Quoted text here. Click to load it

I'd also like to prototype a fully asynchronous processor in
an FPGA.  The Microsemi (ex Actel) Igloo/ProASIC3 parts have no
LUTs. An element of the fine grained fabric can either be a
latch or the equivalent of a LUT3.  But, you may have to
hand-wire the input delays if timing is really critical?

It seems to me that the 2 wire 4 state logic should be fastest,
because only one of the wires needs to make a single transition
to indicate the next data phase.  

On-chip RAM would seem to be a problem though - any ideas?.  


Jan Coombs
--  


Re: glitching AND gate
On Mon, 24 Apr 2017 16:48:47 +0100, Jan Coombs wrote:

Quoted text here. Click to load it

Part of my interest in async is the idea that the design can be
(quasi) delay-intolerant.

Quoted text here. Click to load it

Yeah, the dual-rail encoding seems the best match for normal digital
logic.  I've seen references to one-of-four as well but I don't
understand why it's better.

Quoted text here. Click to load it

One of my thoughts is that there are and will always be synchronous
parts and systems that this would need to interface to.  I want to
make sure that the async dev tools do a good job of handling the
transition between the two worlds.

Re: glitching AND gate
On 4/24/2017 3:56 PM, David Bridgham wrote:
Quoted text here. Click to load it

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.  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.


Quoted text here. Click to load it

I don't think you'll be able to do any of that in FPGAs, at least not soon.


Quoted text here. Click to load it

I believe the reason they started using sync RAMs in FPGAs was more  
about the user interface that it was the technology.  Users were abusing  
the timing of async RAMs, so they gave them a sync interface which is  
harder to abuse.  I think distributed RAM is still async on read and  
that should be good enough since even async RAM is really synchronous on  
writes, just not edge driven.

--  

Rick C

Re: glitching AND gate
On Mon, 24 Apr 2017 16:54:55 -0400, rickman wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: glitching AND gate
Quoted text here. Click to load it
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.

Re: glitching AND gate
On 4/26/2017 4:38 PM, Kevin Neilson wrote:
Quoted text here. Click to load it

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

Re: glitching AND gate
On Wed, 26 Apr 2017 13:38:11 -0700, Kevin Neilson wrote:

Quoted text here. Click to load it

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/

Re: glitching AND gate
Quoted text here. Click to load it

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...

Re: glitching AND gate
On 4/24/2017 10:04 AM, David Bridgham wrote:
Quoted text here. Click to load it

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.

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.

--  

Rick C

Re: glitching AND gate
On Mon, 24 Apr 2017 12:25:46 -0400, rickman wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: glitching AND gate
On 4/24/2017 3:51 PM, David Bridgham wrote:
Quoted text here. Click to load it

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

Re: glitching AND gate
Quoted text here. Click to load it

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.  

Site Timeline