Hardware Simulator hangs up on loading my memory chip

[myau]

The Hardware Simulator freezes while processing my Memory.hdl file, right after I press the "Load Chip" button. The lower pane says "Loading Chip", but nothing seems to happen next (I waited for about 20 minutes). I can't spot any process activity through task manager (CPU load, abnormal RAM usage, disk load etc.), so I doubt that the simulator is actually doing anything in the background. I tried replacing all of the builtin components used in the HDL file by my own versions from the previous projects, I also tried ivant's version 2.6.2 of the simulator, no futher success so far, since I don't have any java programming experience.



I appreciate any suggestions for my HDL code, since the sumulator refuses to yield any meaningful response.

//Assuming out = 0 for any illegal address
CHIP Memory {
    IN in[16], load, address[15];
    OUT out[16];

    PARTS:
//SET part
    DMux8Way(in=load,
	     sel[0]=address[12], sel[1]=address[13], sel[2]=address[14],
	     a=ramload0, b=ramload1, c=ramload2, d=ramload3,	//000 - 011
	     e=screenloadlo, f=screenloadhi,			//100 - 101
	     g=false,						//110 (keycode can't be loaded)
	     h=false);						//111 (overflow)
    //4x4K RAM arrangement fits better than 1x16K
    RAM4K(in=in, load=ramload0, address=address[0..11], out=ramout0);
    RAM4K(in=in, load=ramload1, address=address[0..11], out=ramout1);
    RAM4K(in=in, load=ramload2, address=address[0..11], out=ramout2);
    RAM4K(in=in, load=ramload3, address=address[0..11], out=ramout3);
    //Screen
    Or(a=screenloadlo, b=screenloadhi, out=screenload);
    Screen(in=in, load=screenload, address=address[0..12], out=screenout);
//GET part
    //Keyboard
    Keyboard(out=keyval);
    //the only legit address: 110 0000 0000 0000
    Or8Way(in=address[0..7], out=overflowlo);
    Or8Way(in[0]=address[8], in[1]=address[9], in[2]=address[10], in[3]=address[11], in[4]=address[12],
	   in[5]=false, in[6]=false, in[7]=false, //final multiplexor takes care of these bits
	   out=overflowhi);
    Or(a=overflowlo, b=overflowhi, out=overflow);
    Mux16(a=keyval, b=false, sel=overflow, out=keyout);
    //final output
    Mux8Way16(a=ramout0, b=ramout1, c=ramout2, d=ramout3,	//000 - 011 (RAM banks)
	      e=screenout, f=screenout,				//100 - 101 (Screen)
	      g=keyout,						//110 (Keyboard)
	      h=false,						//111 (overflow)
	      sel[0]=address[12], sel[1]=address[13], sel[2]=address[14],
	      out=out);
}

[WBahn]

One problem that you have is that you are driving an output signal with another signal.

The lettered signals on the DMux8Way are all outputs. When you tie one of them to false, you are essentially shorting an output to the power supply. How the simulator handles that is anyone's guess. The real world often lets the magic smoke out of the part.

If you don't want to use a particular output signal, then just don't use it. Don't try to overdrive it to be something it's not.

[myau]

Thanks for your response!

I got rid of all the grounded connections, now everything works fine.

[myau]

Well, if someone's wondering, a chip design like this won't let the Computer test to pass later on. All the Computer-related tests are hard-coded to look for a RAM16K chip in your design. So they are about to throw an error if RAM16K is not present, even though the Memory chip on its own is operational.

[WBahn]

myau wrote

Well, if someone's wondering, a chip design like this won't let the Computer test to pass later on. All the Computer-related tests are hard-coded to look for a RAM16K chip in your design. So they are about to throw an error if RAM16K is not present, even though the Memory chip on its own is operational.

Which tests, specifically, are hard-coded to look inside your design for anything?

After Chapter 5 there aren't any tests, that I can find, that use the student's CPU implementation at all. Once the CPU is built and tested in Chapter 5 (and you can use any implementation you want), you move up to the next level at which point you are using their CPU Emulator (or tools that work at an even higher level of abstraction).

[myau]

The final chip to be designed in Chapter 5 is called Computer. These tests are supplied to check its functionality:

ComputerAdd-external.tst
ComputerAdd.tst
ComputerMax-external.tst
ComputerMax.tst
ComputerRect-external.tst
ComputerRect.tst

Here is the problem. Whenever I'm trying to run any of them with my Memory chip in use as part of Computer.hdl, I get this:

The problem was gone after I replaced RAM4K chips with RAM16K + some glue logic to make it work. So in this case RAM16K is a requirement, not just recommendation.

[WBahn]

The *-external.tst scripts needing the RAM16K makes sense because the whole point of the external implementations is to allow the test scripts to interact with their internals.

In looking at the non-external test scripts, it also seems like they are accessing chip internals, as well. In fact, they are accessing the internals of even more chips.

I'll try to find out from the authors what their intent was. In the text they only recommend that the built-in chips be used. It seems like if they are needed for the test scripts to work, they should note that pretty clearly.