Mux4way16 Implementation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Mux4way16 Implementation

loof
Hi all.

Currently working on the Mux4way16 gate implementation. I'm able to successfully pass all but the final test and was wondering if I'd be able to email my HDL code to someone so I could get some feedback.

Thanks :)
Reply | Threaded
Open this post in threaded view
|

Re: Mux4way16 Implementation

WBahn
Administrator
You can go ahead and post it here. We just need to be sure to delete it once the discussion runs it's course.
Reply | Threaded
Open this post in threaded view
|

Re: Mux4way16 Implementation

loof
Great! Here it is:

CHIP Mux4Way16 {
    IN a[16], b[16], c[16], d[16], sel[2];
    OUT out[16];

    PARTS:
    Mux16(a=a, b=b, sel=sel[0], out=out1);
    Mux16(a=c, b=d, sel=sel[1], out=out2);
    Mux16(a=out1, b=out2, out=out);
}

I imagine my error has to do with the selector bit, but I'm not sure what to do differently. My reasoning was you plugged in each selector bit independently in the first two Mux16s and therefore didn't need one for the third.  
Reply | Threaded
Open this post in threaded view
|

Re: Mux4way16 Implementation

WBahn
Administrator
You have the right basic topology, but your reasoning is going off the rails.

The Mux16 has to have a sel signal controlling it. Otherwise which of the two inputs will appear at the output? Whichever one it is, it means that the other one can never appear at the output. Never leave inputs unconnected.

Make a truth table showing first your two select bits and which output you want for each possibility. There should be four rows (not counting the column headings).

Then start looking at what signals have to feed each of the three Mux16s for each case. For instance, in the case where both sel bits are zero, your 'a' input has to go into the first input of one of the two (first-line) Mux16 and then the output of that one has to go to the first input of the third (second line) Mux16 in order to get to the output.

Reply | Threaded
Open this post in threaded view
|

Re: Mux4way16 Implementation

loof
Ok. Would finding the canonical representation be helpful here? If so, how do I go about that with gates like Mux and DMux?
Reply | Threaded
Open this post in threaded view
|

Re: Mux4way16 Implementation

WBahn
Administrator
If the canonical representation you are referring to is something like the Sum-of-Products (or Product-of-Sums) representation, then probably not.

But how about doing this.

You have the basic topology (two of your input signals going into one Mux16 and the other two going into the another and then the outputs of those two Mux16s going into a third Mux16 that provides the final output.

So you have three control signals (one for each Mux16). Call them X, Y, and Z.

For each combination of the two select input bits, what do the X, Y and Z signals need to be in order to get the desired result? This gives you three logic problems (one for X, one for Y, and one for Z) each of which is  a function of two inputs (sel[1] and sel[0]).

You could randomly assign the four input signals ('a', 'b', 'c', and 'd') to the Mux16 inputs and make the circuit work this way (and, at the end of the day, that's all the matters for this project). But you will discover that if you choose your assignments with a bit of care, that the logic for each of the Mux16 select inputs becomes trivial.