Possible bug in builtin Mux16 or in how sel[2] is read

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

Possible bug in builtin Mux16 or in how sel[2] is read

yarmish
In order to build a Mux4way16 we used the code: Mux16(a=a, b=c, sel=sel[0], out=ac); Mux16(a=b, b=d, sel=sel[0], out=bd); Mux16(a=ac, b=bd, sel=sel[1], out=out); We removed the file for Mux16 in order for the builtin Mux16 to be used. See this image:
In the graphic you can see that numbers are in binary. when sel[2] is 01 the output should be b[16] /** * 4-way 16-bit multiplexor: * out = a if sel == 00 * b if sel == 01 <------------------ * c if sel == 10 * d if sel == 11 */ but it chooses c[16]. It seems that it is reading the sel[2] input backwards. When you set the format to “binary” (on the top) then we can set sel[2] by bits. When its 01 it seems to be reading it first the 1 for sel[0] and then the 0 for sel[1]. You can see below that its choosing c for ac and d for ad – the wrong choice - it seems to be using sel[0] to be 1 from the rightmost bit. Then it chooses ac for out using the left bit of 0. So either the Mux16 is problematic or sel[2] array is being read in backwards.
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in builtin Mux16 or in how sel[2] is read

cadet1620
Administrator
yarmish wrote
It seems that it is reading the sel[2] input backwards.

When you set the format to “binary”  (on the top) then we can set sel[2] by bits.
When its 01 it seems to be reading it first the 1 for sel[0] and then the 0 for sel[1].
This is correct behavior. Hardware bits are numbered from right to left.

This is so that when a hardware bus is carrying a binary number, bus[n] is the 2^n binary bit.

--Mark

[Edit your post and uncheck the "Message is in HTML Format" box and your post will be much more readable.]