Hi all, I'm having trouble multiplexing a number of signals without the output glitching. The following 4 to 1 multiplexer with all the inputs connected to 1 shows the issue: module multiplexertest ( input wire a,b,c,d, input wire s,t, output wire q ); assign q = (s) ? ((t) ? d : c) : ((t) ? b : a); endmodule`timescale 1 ns / 100 ps module multiplexertest_TB (); reg a,b,c,d; reg s,t; wire q; multiplexertest multiplexertest_inst ( .a(a) , // input a_sig .b(b) , // input b_sig .c(c) , // input c_sig .d(d) , // input d_sig .s(s) , // input s_sig .t(t) , // input t_sig .q(q) // output q_sig ); initial begin a = 1; b = 1; c = 1; d = 1; s = 0; t = 0; end always # 40 s = !s; endmodule Two input multiplexers don't seem to suffer from this issue though that may just be luck. Now I can fully understand that the glitches are generated due to the LUT within the LE which causing this but I would have thought that there should be a way around it. I need the fastest possible input to output performance so registering the data is something I'm trying to avoid doing.

Avoiding glitches in combinatorial circuits brings you into the field of "Asynchronous Sequential Switching Circuits" and "Asynchronous State Machines". Rewriting the equation will not really help as everything depends on the relative path delays as produced by the fitter and these will vary while compiling the design after each design change/addition.

--- Quote Start --- Rewriting the equation will not really help as everything depends on the relative path delays as produced by the fitter and these will vary while compiling the design after each design change/addition. --- Quote End --- Depends on. Glitches can be generally expected, when more than one input of a FPGA LUT are changing simultaneously. This can be avoided at least for the present test case, if you control the logic synthesis by defining nodes with a keep attribute. But at least, when more than one module input signals are changing at the same time, it can't work any more.

Yes, that is my thoughts too. In my test bench, only one of my inputs is changing so why the glitch? It is moving from one row in the LUT to another with only one input changing so I would have thought that there shouldn't be a glitch.

Ok, I've been playing some more and have used three 2 to 1 multiplexers to create the 4 to 1 and have used the /* synthesis keep */; trick (thanks FvM) so that the 2 to 1 mux's don't get reduced. This now seems to work as I require i.e. it is glitch free so it solves my problem. However, I still don't understand why my original code glitches. If two inputs changed at once, I could understand the glitch if the output from only one input change was different but this isn't the case. module multiplexertest ( input wire a,b,c,d, input wire s,t, output wire q ); wire x,y /* synthesis keep */; assign x = (t) ? d : c; assign y = (t) ? b : a; assign q = (s) ? x : y; endmodule

From the Quartus Help: --- Quote Start --- You can use this synthesis attribute to keep a combinational node so you can observe the node during simulation or with the SignalTap II Logic Analyzer. --- Quote End --- I interpret this that the Fitter/Router will 'keep' said wire/signal but it will not prevent the Fitter/Router from placing it differently on a subsequent compile. --- Quote Start --- But at least, when more than one module input signals are changing at the same time, it can't work any more. --- Quote End --- Isn't that the nature of an asynchronous circuit? To Bat Technologies: You have created a two-step solution which you can assess by viewing your design in the RTL Viewer. Before my first reply I first tried a few things in Quartus myself and rewrote your equation into a single step one. I add the code for your perusal: module multiplexertest ( input wire a,b,c,d, input wire s,t, output wire q , q2 ); assign q = (s) ? ((t) ? d : c) : ((t) ? b : a); assign q2 = !s && !t && a || !s && t && b || s && !t && c || s && t && d ; endmodule At first compile q2 was as glitchy as q. I then added a 5.000 ns tpd (for a CycloneII auto device) and then q2 becomes glitch-free. But I'm not sure whether this will stay this way.

Multiplexer Output Glitching | Altera Community

26 Replies

Altera_Forum
Honored Contributor
15 years ago
Of course I was wrong with the LUT, I should have thought a bit further ...

This effectively supports your theory that you should be able to make a 4 to 1 mux with just 3 LEs (or a 2^n to 1 mux with (n+1)*n/2 LEs)

The LUT will be glitch-free only it is purposely designed so. E.g. the TpHL is longer than the TpLH so that a 'one' disappearing overlaps the next 'one' appearing. The simulations tend to go along that line.
Altera_Forum
Honored Contributor
15 years ago
Thanks vjAlter, a search came up with the following which explains what I mean better than I managed:
http://www.alteraforum.com/forum/showpost.php?p=8506&postcount=7

--- Quote Start ---
The LUT will be glitch-free only it is purposely designed so. E.g. the TpHL is longer than the TpLH so that a 'one' disappearing overlaps the next 'one' appearing. The simulations tend to go along that line.
--- Quote End ---
That will depend on the design of the LUT. If it is AND -> OR or OR -> AND may mean that TpHL needs to be shorter than TpLH (if I understand their meaning correctly). No matter the crucial bit is that the LUTs are glitch free if one and only one input changes.
Altera_Forum
Honored Contributor
15 years ago
Something I borrowed from our friends at Xilinx:

this is the original link (http://www.castalk.com/ftopic12373.html)

--- Quote Start ---

Re: Xilinx LUT behavior question

by Peter Alfke » Thu Dec 01, 2005 9:12 am
Good question, often asked:
No glitch, and that behavior is guaranteed by the decoding structure.

Further, if you change two pins, and you know that the output is
identical for all 4 permutations of these 2 bits, there also is no
glitch.
And you can stretch that to 3 pins, where all 8 permutations must give
identical results to avoid a glitch, although this last one may be an
unrealisticl situation.

I have answered this particular question many times over the past 15
years.
Peter Alfke, Xilinx Applications
--- Quote End ---
and

--- Quote Start ---
Re: Xilinx LUT behavior question

by Peter Alfke » Fri Dec 02, 2005 9:15 am
Just to get back to the original question (which was kind of academic):
my answer still stands. The muxing inside the LUT is done by pass
transistors, and the internal capacitance holds the value during
non-overlapped switching. So: no glitches.
Austin describes glitching in a more general sense, and then mentions
on the delay differences of different LUT address inputs. Good info,
but does not contradict my statement.
Peter Alfke
--- Quote End ---

I just wonder if an Altera 'official' would explain us whether this is also the case for their products. I'm inclined to think it will be. All the simulations I have done yesterday and today point into that direction.
Altera_Forum
Honored Contributor
15 years ago
--- Quote Start ---
I just wonder if an Altera 'official' would explain us whether this is also the case for their products.
--- Quote End ---
As vjAlter explained, Altera FPGAs (and I think, Xilinx and other other vendors as well) have no specific means to support asnychronous designs. There are only a few simple cases, where you can guarantee an unregistered LUT output to be glitch free.

The above quoted statement is however addressing only a part of the problem. It's not sufficient to ask, how a LUT behaves in case of two (or more) simultaneously changing inputs. Due to routing delays, they don't change exactly simultaneously. So only, when all permutations of the changing bits keep the output state, it (hopefully) won't glitch.

As long as you are able to restructure the decoder to achieve this situation, there's a chance to avoid glitches. This has been the case with the binary multiplexer tree from the start of this discussion. It can be build glitch free, but the synthesis tool optimizes the logic in a way, that glitches are created. In this, and only in this case, synthesis attributes can help to enforce a glitch free gate level structure.

The other important hint in vjAlters statement is related to the tools. A synthesis tool, that knows about routing delays would be able to make certain (or possibly all?) asnychronous designs glitch free. But none of the common synthesis tools has this feature, because it's not made to support asynchronous operation.
Altera_Forum
Honored Contributor
15 years ago
A long time ago, I worked with async logic. I think you either need to "hold" the present output or drive all outputs to zero for a period long enough for the inputs to resolve then enable the outputs.
If you can find info on TTL (TI's 74xx series) flip-flops were designed to hold the present qout on the leading clock edge then qout could change at the trailing clock edge.
Also I think that even tho input t changes, it causes two assigns to change and the race between those 2 are the source of the glitches.
Async logic only works if glitches are eliminated and that usually involves generation of a delay to hold while changes resolve or drive to a quiescent state until changes resolve.
Async designs usually stress bus transfers and comparing inputs to outputs to determine the duration of the input clock./gate.
D FFs are used instead of latches because the double latching prevents propagation of glitches and metastable signals.
Altera_Forum
Honored Contributor
15 years ago
hi
interresting question, in fact aside mux case the question is : are LUT able to implement basic logic function (and, or) as with old TTL without glitch.
This is clearly dependant of the LUT architecture which is unknown to me.
Does the attribute "keep" that i use also actually safe ?

Forum Discussion

Multiplexer Output Glitching

26 Replies

Recent Discussions

Agilex 5 Power

Agilex 5 Sulfur Partial Write Issue on F2H ACE‑Lite I/F (256‑bit) with AXI Master of 128‑bit

Cyclone 10 LP's Extended Industrial parts

Quartus Prime Pro 25.1 fatal error during fitter: Windows "Efficiency mode" required

Quartus Pro simulation libraries for Riviera Pro