Multiplexer Output Glitching

That is the major problem with asynchronous logic and FPGAs: they are not made for each other. Almost all FPGAs are pure synchronous beasts. (Except Achronix and maybe some newer start-up).

You are right about those 12 LE's to implement the 4 to 1 hazard free mux. A 4 input LUT isn't that powerful: it only enables you to decode one of the 16 squares in the corresponding Karnaugh map.

The code you propose to build a 2 to 1 mux is not hazard free:

assign x = (t) ? d : c;

will translate into

  x = !t & c
    |  t & d
    ;

Where the hazard elimination term "| a & b" is missing.

Hi Josyb,

Your code makes the assumption that a two input AND and three input NOR doesn't glitch when a single input changes in a state which doesn't change the output. For example with an AND gate with inputs a and b, if a = 0 and b changes from 0 to 1 you would expect the output to stay at 0 and not glitch to 1. If this assumption is false, there isn't anything you can do about it to make you whole circuit glitch free.

Now the assumption of a two input gate not glitching is likely to be true as it will always fit into a single LE which I believe to be glitch free. However a three input gate could be potentially be spread across two LEs depending on how the fitter decides to do things. Once spread across multiple LEs a three input gate will potentially have glitches in its output.

Now in your design, you have the synthesis keep option so each logic statement will be in its own LE and the overall design will be glitch free. The downside is that is complicated and I guess will use 12 LEs. (I can't check this nor anything else at the moment as my main computer decided to allow a power inductor to fall out of the power supply PCB and is currently rattling around the case - this isn't recommended...)

If you make the assumption that a single LE is glitch free by design then ANY combinatorial logic with up to 4 inputs will be glitch free as it will fit into a single LE. This then enables a 4 to 1 mux to be made glitch free from 3 LEs using the code below.

    wire x,y /* synthesis keep */;
    assign x = (t) ? d : c;
    assign y = (t) ? b : a;
    assign q = (s) ? x : y;

It may just be possible to make a 4 to 1 mux glitch free using just 2 LEs and some clever coding but I can't find a way to do it. I'm fairly certain it is impossible but haven't proved it yet.

Now all of this relies on a single LE being glitch free which is a bit of an assumption to make. I've previously looked at the Altera docs but I didn't find anything relevant. I'll have another look now and will report back if I find anything.

I couldn't keep from searching a bit deeper and went back to some 'old' textbooks.

I.e. what we call a glitch here is in effect called a 'logic hazard'. Making hazard free circuits for a single input changing is relatively easy by adding 'redundant' (at first sight) coverage terms. For a logic hazard free 2 to 1 mux it looks like this

 
 y = !s & a
   |  s & b
   |  a & b
   ;

Unfortunately the 3rd term eliminating the logic hazard will optimized away, so the equation becomes abit elaborate

 wire gab , gcd , gabcd,  hab, hcd , habcd , iab , icd , iabcd , rab , rcd/* synthesis keep*/ ;
 assign  gab = !s & a0 ;
 assign  hab =  s & b0 ;
 assign  iab = a0 & b0 ;
 assign  rab = gab | hab | iab ;
	
 assign  gcd = !s & c0 ;
 assign  hcd =  s & d0 ;
 assign  icd = c0 & d0 ;
 assign  rcd = gcd | hcd | icd ;
	
 assign  gabcd = !t & rab ;
 assign  habcd =  t & rcd ;
 assign  iabcd = rab & rcd ;
 assign  q0 = gabcd | habcd | iabcd ;

This will generate a hazard-free 4 to 1 multiplexer for a single input change.

It should be possible to harness a 2 to 1 mux with hazard-coverage into a single LUT, but we may need some help form Altera here to 'tame' the optimizer.

I don't see that equation glitching in my project. I compiled and simulated the project for different families and get different results in the gate level simulation (and that is not exactly the real world ...)

If you really need 'full' asynchronous behaviour, you will need to use 'full' asynchronous design procedures.

--- Quote Start ---

But in theory even the simple circuit which muxes two inputs onto one output could glitch when the output selection tuns off faster than the other selection turns on.

--- Quote End ---

Very true and that is what is worrying me.

The problem seems to occur when two LEs are required to contain the code rather than one. If this occurs then it may be an output from one LUT which has to turn on/off at the same time as a LUT in another LE. Due to the delays that this may cause, glitches result. If the code fits exactly into one LUT then no glitches result as it is designed to be glitch free.

To try an understand this a bit more I have tried to simplify the design to the minimum that causes a glitch and came up with the following:

    assign q = s & a 
                | s & b
                | !s & c
                | !s & d;

With a,b,c,d set to 1, toggling s causes a glitch. If you remove one of the inputs, so it has 4 rather than 5, it will fit into one LE and no glitches result.

I think this explains it so I can now design around it.

Now if you only have to consider one input changing at at time, your above design with the 'keep' attributes seems to work best without glitching as 't' works on the first tier while 's' decides on the second tier in the purposely designed 2-tier logic. We now have 3 times the same circuit. But in theory even the simple circuit which muxes two inputs onto one output could glitch when the output selection tuns off faster than the other selection turns on. So if we could force a 'delayed' turnoff we would be glitchfree by design. But here we depend on the physical process in the LUT. In the days of TTL logic we could select devices with a TpHL > TpLH. We could infer that the same may be true inside an FPGA, but this might just be wishful thinking. Maybe you could ask Altera about the LUT TpLH and TpHL of the device you are using?

BTW the q5 output will also be glitchfree if we consider the above TpHL > TpLH to be true.

Interesting. I'm using Quartus 10.0 and Model Sim Altera SE.

I'm up on async logic which is why I have issues with the way that the altera gear is working. Async logic relies on the basic building blocks not glitching when a single input changes state. It means that you can't use gray coding and other tricks to ensure correct operation which is worrying me.

That's funny, in my simulation (using Quartus 9.1sp2 internal simulator) it is q4 and q5 that are glitch free even for the simultaneous changing of 's' and 't'.

If you inspect the Netlist, first RTL and then the Technology map you will find that some of the fitted/routed results aren't that different from the other.

If you look in the tpd report of the timing analyzer you will see that the respective tpd's for 's' and 't' to q4 and q5 are very close together explaining why they seem to be glitchfree, but in real life for some sequence of 's' and 't' changing a glitch will show up.

If you definitely ned absolutely glitchfree outputs you will have to do some reading on asynchronous sequential circuits like I mentioned before. This link (http://web.cecs.pdx.edu/~mperkows/class_573/febr-2007/ieee-asyntutorial.pdf) shows how an asynchronous state machine only differs slightly for a synchronous one idea-wise, but implementation is a different story.

Thanks for that.

In my simulation of your file, the only one that doesn't glitch is output q3 which is the same as my solution above. It is the only version that only combines a maximum of three signals together where as all the others are four or more. Maybe this is the limiting factor? More experiment is needed I think.

I did some variations as well. (Always fun to learn something on a Sunday afternoon! Verilog is still new to me so I used this occasion to study it a tiny bit)) See the attached QAR.

If you simulate the design you will see that the 'keep' directive doesn't always work either ...

I notice that on every compile/addition the behavior changes slightly and glitching either disappears or reappears.