BIT working but still..

[mH]

Hi,
I just started implementing the chips from chapter 3 and i'm now bumping into something i don't understand:
I thought i had understood pretty well how to build a 1 bit register so i draw a diagram and immediatly turned it into an hdl. It didn't not work. So i started to wonder why since i was sure to have understood and i went to check on the internet how other people did it and i noticed that someone had the EXACT same code as mine except he/she had the two pins of the mux reversed.
So i dared to tried it, and it worked!
Now the problem is, I don't understand WHY. For the moment it makes absolutely no sense for me that if i input in the mux the DFF's output in a it works and doesn't in b.
If someone has a clue, it'll be more than welcome.
Thanks.

[cadet1620]

When the Mux's sel is 0, its a input is connected to its out.

When the Bit's load is false, the DFF's in is effectively connected to its out so it continuously sets itself to its current value when the clock ticks. The Bit is in storage mode.

When load is true, the DFF's in is connected to the Bit's in so the DFF sets itself to the Bit's input value.

--Mark

[mH]

Thank for answering but i still don't get why it works this way? why can't it be the other way around?
why does exchanging a and b makes the comparison fail. It doesn't make sense (at least to me).

[cadet1620]

mH wrote

Thank for answering but i still don't get why it works this way? why can't it be the other way around?
why does exchanging a and b makes the comparison fail. It doesn't make sense (at least to me).

    

Mux's input's are not interchangeable. When sel is false (upper schematic) a is connected to out so the DFF maintains its value. When sel is true (lower schematic) b is connected to out so the DFF gets the value from the Bit's in.

If you exchange the Mux inputs, the Bit will maintain its value when load is TRUE and will update its value when load is FALSE.

--Mark

[mH]

Thank you again for answering.
I'm ok with that but how come is out in b wrong?
Correct me if i'm mistaking here but it's only wrong because the test script states that out of DFF goes in a? or do i always have to put the out in a in this kind of situation? (and if yes why)

[cadet1620]

The test script does not say anything about how the circuit is wired. The test script only validates how the circuit functions. The script changes in and load and tests that out changes to the correct values at the correct time.

This complex circuit, using 2 DFFs is also a Bit because it satisfies the specified behavior.

CHIP Bit {
    IN  in, load;
    OUT out;
PARTS:
    Xor(a=in, b=p, out=ixa);
    Not(in=load, out=nl);
    Or(a=load, b=q, out=lob);
    Or(a=nl, b=ixa, out=nxi);
    Not(in=p, out=p1);
    Nand(a=nxi, b=lob, out=q1);    
    DFF(in=p1, out=p);
    DFF(in=q1, out=q);
    Xor(a=p, b=q, out=out);    
}

--Mark

[mH]

Yeah but it assumes that the out of the DFF is wired in the a pin of the mux otherwise why would it work when out is plugged in a but not when it's plugged in b?

[cadet1620]

I truly do not understand your question. The Bit.tst script makes absolutely no assumptions about the internal structure of the Bit.hdl file.

Your question seems to me to be identical to asking, "If I switch the a and b inputs to the "f" multiplexor in the ALU, why doesn't the ALU.tst script pass?"

--Mark

[mH]

I'm sorry, English is not my mothertongue thus sometimes it's hard to clearly make my point.
You are absolutely right though, I don't understand why it works when the DFF's output is in the MUX's a and does not when in b.

[cadet1620]

Let's take this off line.  I'll contact you directly by e-mail.

--Mark

[Jeff George]

For those that find this thread later on, I found Mark's answer very helpful. I made the same mistake as the OP on my first version of the Bit: I connected in to the Mux's a pin, and the output from the DFF to the Mux's b pin. This is a natural mistake to make, connecting the Mux pins alphabetically as you trace from top to bottom in the diagram in the text (p. 43) or the lecture (slide 7). Doing so, however, made my chip fail the test.

The key is that the a- and b-pins on the Mux aren't interchangeable, as Mark explains. It matters which pin you connect to what source. The a-pin is "active" when the selector is set to false; the b-pin is ''active" when the selector is set to true.

In this implementation, the Bit takes on a new value through its input when the load is set to true; it keeps its old value, fed from the output of the DFF, when the load is set to false. The Bit's "load" is the Mux's selector, so when the load is false, it's taking its value from the a-pin; when load is true, it's taking its value from the b-pin. Thus, you need to connect the a-pin to the source you want selected when the load is false: the output from the DFF. And when load is true, the b-pin is selected; that's when you want to get the new value from the Bit's input. So you need the Mux's a-pin connected to the DFF output loop, and the b-pin connected to the Bit's input.

I apologize for any mis-use of the vocabulary in my explanation, but I thought I might be able to help bridge any communications gap that might exist between the experienced computer scientists leading this course, and laymen like myself who might be taking it on their own.

[ybakos]

I like to think that this is a subtle intent of the author, to help catalyze an understanding of the Mux and DMux: yes, the inputs matter! Facing the fact that a and b matters now will help you avoid subtle errors when working on other chips, such as the PC, ALU and CPU.