Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorMultiplexer Output Glitching
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
26 Replies
Altera_Forumhi
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 ?- Altera_Forum
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--- 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
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
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
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--- Quote Start --- Now I'm pretty confident that the LUT is designed to be glitch free as if it wasn't simple logic gates such as ANDs and ORs would also glitch and there would be complaints everywhere. I do need to get this confirmed though as my design now relies on this fact. I can't find anything in the Altera docs though. I will keep on trying. --- Quote End --- We talked about this a couple of times here. Search the forum for "LUT glitches". The bad news is that this is mostly an undocumented feature. For some reason it seems to be undocumented on most other FPGA vendors as well. The concensus seems to be that LUT is, by design glitch free for a single input change, but it might be not if two or more inputs change at the same time. There were some doubts if this applies to ALUTs as well. But then, the relevant question is how far apart the change in two LUT inputs should be for avoiding glitches. And of course, not being a formally documented parameter, nobody would tell you. Basically, this agrees with josyb statement, that FPGAs are synchronous beasts. They were not designed for async logic, quite the contrary. And it is not just the silicon, but the tools and documentation as well. This doesn't mean, of course, it is totally impossible to implement async logic.
- Altera_Forum
I should also add for those reading this thread that all the above applies to Cyclone III and other devices with 4 input LUTs. Other devices may have LUTs with different designs.
- Altera_Forum--- Quote Start --- A 4 input LUT isn't that powerful: it only enables you to decode one of the 16 squares in the corresponding Karnaugh map. --- Quote End --- I don't follow you there. A 4 input LUT allows you implement all 16 squares in an arbitrary Karnaugh map which makes them very powerful and is why FPGAs are full of them.
- Altera_Forum
I think you are wrong but please don't take that the wrong way, I'm not 100% sure that I'm right and would like to discuss this until we are both happy that we understand what is going on. Please rip anything I say to shreds so we can get to the bottom of it and both learn.
x = (!t & c) | (t & d) will be implemented in the LUT as follows:
Now from the above, it is easy to see that if c and d are the same value then the output won't change when t changes value. Now if the LUT is designed to be glitch free (which I am very sure it would have to be) then the output won't glitch as it is just moving from one row in the LUT to the next. No additional logic is required. Now if instead of being made from a LUT, the logic was being made from two AND gates and an OR gate then I would agree with you, the design would potentially glitch and the extra logic is required to stop this. However, it isn't, it is made from a LUT so the extra logic isn't required as long as the LUT was designed to be glitch free when swapping between rows with a single input change. Now I'm pretty confident that the LUT is designed to be glitch free as if it wasn't simple logic gates such as ANDs and ORs would also glitch and there would be complaints everywhere. I do need to get this confirmed though as my design now relies on this fact. I can't find anything in the Altera docs though. I will keep on trying. I also agree that asynchronous logic in FPGAs is a minefield and very difficult to get right. If anybody else reading this thread wants to pitch in then please do.c d t | x ========= 0 0 0 | 0 0 0 1 | 0 0 1 0 | 0 0 1 1 | 1 1 0 0 | 1 1 0 1 | 0 1 1 0 | 1 1 1 1 | 1
