Not not working

[methermeneus]

The variables have been changed to protect the people who are still working on the implementation.

I'm trying to write the HDL implementations for chapter 1, and I ran into a brick wall on Mux. For some reason, when I try to include Not as a part, it doesn't do anything. I'm pretty sure I wrote it correctly:

Not(in=x, out=notx);

and put it into the header correctly:

CHIP Mux {
   IN x, y, z;
   OUT out;

but when I test it in the hardware simulator, notx=1 regardless of what x is. It does this with both the Not implementation I wrote for the project and the built-in implementation. Furthermore, the Not part works just fine in Xor, and I double-,triple-, and quadruple-checked that I wrote both the same way, and everything else in the Mux implementation outputs what it ought to based upon its inputs.

Anyone have any ideas? I checked other online resources to see if I'd designed my multiplexor correctly, but this strikes me as possibly indicative of a bigger problem.

EDIT: The Not part also works fine in DMux. If I encounter another implementation in which it doesn't work, I'll list it here.

[cadet1620]

Firstoff, you need to use the standard names for the I/Os in Mux so that your Mux can be used seamlessly with the builtin version. The standard header for Mux is

// This file is part of the materials accompanying the book
// "The Elements of Computing Systems" by Nisan and Schocken,
// MIT Press. Book site: www.idc.ac.il/tecs
// File name: projects/01/Mux.hdl

/**
 * Multiplexor.  If sel=0 then out = a else out = b.
 */

CHIP Mux {

    IN  a, b, sel;
    OUT out;

    PARTS:
    // Implementation missing.
}

If you didn't find these skeleton files, they are in http://www1.idc.ac.il/tecs/projects/01/index.htm, etc. There is a link to a zip file with the whole set for the chapter at the bottom of the page.

There are also test scripts in the project zip files that require the standard I/O names.

Another thing to try is to rename your Not.hdl to something like MyNot.hdl. This will force the simulator to use the built in Not so you can see if the problem is in your Not or in your Mux.

--Mark

[methermeneus]

I already said I changed the variables in my post; I certainly did use a, b, and sel in my implementation. Not that that actually matters, since I haven't used Mux as a part for any other implementation except Mux16, and I made sure to use the built-in version for that. The forum rules are that we're not supposed to publish completed (proper) implementations, and I think that saying how I used the Not part would be a larger hint than I ought to give to anyone who hasn't done the exercise yet. (Personally, I figured from the beginning that I'd have to negate something, but figuring out what was my breakthrough in making a Mux that should have worked.)

If you want, I can email you what I did do; I was just bringing up that Not didn't work in that one implementation because it strikes me as possibly being symptomatic of a problem in the Hardware Simulator's programming, or at least how it interfaces with some systems. I've already finished the Chapter 1 exercises, and it worked in everything else, including Mux4Way16 and Mux8Way16, but for some reason not in Mux.

[cadet1620]

I can't believe I missed the first sentence of your post. Sorry about that. I blame it on the head cold I've had for the past few days.

"Not" failing in only one of the HDLs sounds really strange. Feel free to mail me your project 1 HDLs and I'll take a look at them.

--Mark

[cadet1620]

The apparent Not failure was caused by the the Hardware Simulator not correctly updating the variable values when it stops at a miscompare.  I spent a couple minutes scratching my head over the apparent failure, too.  Then I noticed that there was an error in the Methermeneus' HDL that was causing it to output incorrect results, unrelated to the Not.

--Mark

[methermeneus]

Wow, I feel like an idiot. Yes, I missed that entirely, and now... well, oddly enough, I've still got the same problem.

What I find particularly odd is that the simulator had no problem loading a chip that's missing an "out" pin entirely, but at least cadet1620 was good enough to notice that error for me. Still no idea what's going on with that Not gate, but given that everything else through Project 03 works, with plenty more Not gates being implemented along the way, I'm just going to assume there's something wrong with my computer that made a very minor bug show up in the program and move on with my life.