glitching AND gate

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

On 4/23/2017 9:34 AM, David Bridgham wrote:
> 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.

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

On Sunday, 4/23/2017 9:34 AM, David Bridgham wrote:
> 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
> 

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

On Sun, 23 Apr 2017 15:51:33 -0400, rickman wrote:

> I'm sorry but I can't picture the timing from your description.  You 
> have two circuits with one input in common.

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;

> You then ask "Will the AND gate implementation in an FPGA do that?"  I
> don't understand what you are asking.

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?

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

The former; enable is not asserted until at least 150ns after
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?

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

On Mon, 24 Apr 2017 08:30:06 -0400, Gabor wrote:

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

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.

On Mon, 24 Apr 2017 14:04:34 -0000 (UTC)
David Bridgham <dab@froghouse.org> wrote:

> On Mon, 24 Apr 2017 08:30:06 -0400, Gabor wrote:
> 
> > 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.
> 
> 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. 

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

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

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

On 4/24/2017 8:46 AM, David Bridgham wrote:
> On Sun, 23 Apr 2017 15:51:33 -0400, rickman wrote:
>
>> I'm sorry but I can't picture the timing from your description.  You
>> have two circuits with one input in common.
>
> 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;

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.


>> You then ask "Will the AND gate implementation in an FPGA do that?"  I
>> don't understand what you are asking.
>
> 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?
>
>> 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?
>
> The former; enable is not asserted until at least 150ns after
> 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?
>
> 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

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

On 4/24/2017 10:04 AM, David Bridgham wrote:
> On Mon, 24 Apr 2017 08:30:06 -0400, Gabor wrote:
>
>> 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.
>
> 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.

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

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?

Marko

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.

-- 

Rick C