Forum Discussion
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_ForumThanks for having a play josyb, it is appreciated.
I've tried all sorts of arrangements for the 4 to 1 (though not yours...) and all suffer from the same problem as I would guess that they synthesize into the same thing. I now have a solution that appears to work (see above) but I am not sure that it is guaranteed to work as I don't understand the mechanism as to why it is glitching. Putting in delays may well cure it but again I'm not sure it is a robust solution. If you change the testbench code to the following then I would expect glitching as two inputs are changing at once and it transits through a state with a different output. Interestingly, this produces glitches that are 7ns in size compared to the 1ns glitches I was seeing initially.`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 = 0; c = 0; d = 1; s = 0; t = 0; end always begin # 40 t = !t; s = !s; end endmodule- Altera_Forum
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:
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.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 - Altera_Forum
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 - Altera_Forum
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.
- Altera_Forum--- 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.
- Altera_Forum
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.
