Mux4Way16 understanding issue.

[pvlbzn]

Dear all,

First of all big thanks for this incredible course. It is a gem.

Can you help me with an understanding of Mux4Way16?

The thing is that I was understood it before it was worked. After I modified it, it passed all test and passed by my understanding.

I made a scheme of my implementation, here it is:


If I assign an order of inputs as a, b, c, d it works. However, in code comment written following:
a if sel == 00
b if sel == 01
c if sel == 10
d if sel == 11

So, my logic is:
Top      Mux16 gate input is a and c,
Bottom Mux16 gate input is b and d.

sel[0] assigned to   input Mux16 (Top, Bottom)
sel[1] assigned to output Mux16

Lets trace:
a (Top Mux16)
sel[0] = 0
sel[1] = 0
(According to comments we will get a)

Top Mux16 will result in a, because from Mux architecture - if (sel == 0) out = a;.
Last(Out) Mux16 will pass a because of the same rule.

b (Bottom Mux16)
sel[0] = 0
sel[1] = 1
Top Mux16 will out a, Bottom Mux16 will out b, Last Mux16 will out b. *Test failed.

c (Top Mux16)
sel[0] = 1
sel[1] = 0
Top Mux16 will out c, Bottom Mux16 will out d, Last Mux16 will out c.

d (Bottom Mux16)
sel[0] = 1
sel[1] = 1
Top Mux16 will out c, Bottom Mux16 will out d, Last Mux16 will out d.

So. On paper it works, in an emulator it don't work. However the same realization but with a, b, c, d order works, but I don't understand why.

Lets assume a, b, c, d order:

a (Top Mux16)
sel[0] = 0
sel[1] = 0
Top Mux16 - a, Bottom Mux16 - c, Last Mux16 - a. OK

b (Top Mux16)
sel[0] = 0
sel[1] = 1
Top Mux16 - a, Bottom Mux16 - c, Last Mux16 - c. * Failed, there should be b, but result is c.

c (Bottom Mux16)
sel[0] = 1
sel[1] = 0
Top Mux16 - b, Bottom Mux16 - d, Last Mux16 - b. * Failse, expected c, result is b.

So I'm really confused. I checked all my previous abstractions under NAND. All of them passed tests well.
Can you point me on my mistake? I've read few articles about gates, and don't find some misunderstandings. I'm self-taught beginner and I'm sort of stress to understand not right.

I'll very appreciate you help!

With best regards, Pavel.

[cadet1620]

pvlbzn wrote

Can you help me with an understanding of Mux4Way16?

The thing is that I was understood it before it was worked. After I modified it, it passed all test and passed by my understanding.

You probably missed that hardware bus bits are numbered from right to left.  For sel = 2 (decimal) = 10 (binary), sel[0] = 0 and sel[1] = 1.  See column headers in fig. 1.10, for example.

This is a common problem for people with programming experience since arrays are numbered from left to right.

The rational for this "backwards" numbering is that bus bit N carries the 2^N bit of a number.

--Mark

[pvlbzn]

Dear Mark,

True, the problem was in "array thinking" of hardware indexes. Now everything make sense.

Also, "backwards" indexing feels logically right.

Thank you!

[Cythera]

Bless you!  I've spent 2 days beating my head against the same mistake ...