"The chip has a circle..." clarification

[FairFriend]

Hi everyone. When I try to load my CPU chip the hardware simulator notifies me with the following error message:

"The chip has a circle in its parts connections".

Reading other threads I gauged that such error (which seems to be more common when the computer chip, rather than the cpu, is loaded) occurs when a clocked signal is confused with a non-clocked one. But I must say that I truly don't understand this objection at all.

Could someone give me more details about the possible causes? Thank you.  

[cadet1620]

The "circle in its parts" message is complaining about unclocked feedback.  Chips like "Bit" need feedback to store their state, but that feedback is controlled through a DFF, so the circuit doesn't run wild.

An example of unclocked feedback would be this chip

CHIP Foo {
    INPUT in;
    OUTPUT out;
PARTS:
    And (a=in, b=fb, out=aout, out=out);
    Not (in=aout, out=fb);
}

Built with real parts, this circuit would oscillate between 0 and 1 output as fast as possible, whenever in is 1.

To make this a legal circuit for the Hardware Simulator, there needs to be a clocked delay somewhere. For instance

    DFF (in=fb, out=dffout);
    And (a=in, fb=dffout, ...

In the CPU, the most common unclocked feedback is ALU output somehow getting back to ALU x or y.

If you want to, feel free to email me your CPU and I'll let you know what I see.

--Mark

[FairFriend]

Thank you for the reply. The example was very clear. Regarding this part of your message

cadet1620 wrote

In the CPU, the most common unclocked feedback is ALU output somehow getting back to ALU x or y.

if the ALU output first goes through one of the two registers, as shown in figure 5.9, there should be no such problem, am I correct?

EDIT: So I followed your suggestion and I checked the ALU inputs. Actually, I still dont'see what triggered the error message. Anyway by messing with the inputs I realized that the A/M input was causing me troubles. To clock the A/M signal I let it go through a Register (say XRegister) whose load input is the same of the ARegister itself. Then the A/M signal, that is XRegister output, goes to the ALU y input. To my understanding the XRegister now acts as a buffer. Nonetheless its presence seems to me unjustified: since the multiplexer input (I'm now talking about the multiplexer with output A/M) comes from the ARegister, shouldn't the A/M signal itself be clocked?

EDIT 2: After I had implemented the aforementioned buffer I went on checking the rest of the chip. It turned out the buffer was a mistake: the ALU input would not commit to the buffer input (I don't know whether my load input was wrong or whether the buffer itself was unnecessary ). Anyway by correcting the other errors I misteriously managed to correct the "circle in a chip" error. I just don't know how...

EDIT 3: I realized that, in order to prevent the error message from appearing, I could simply copy and paste the internal logic of the decode chip in the CPU chip. I dont' know why but thanks to this I was able to succesfully test the CPU.

[cadet1620]

FairFriend wrote

EDIT 3: I realized that, in order to prevent the error message from appearing, I could simply copy and paste the internal logic of the decode chip in the CPU chip. I dont' know why but thanks to this I was able to succesfully test the CPU.

The course has done too good a job of teaching you to think of abstractions!

The problem with making an InstructionDecode chip is that the Hardware Simulator only examines feedback loops based on the declaration of clocked input and outputs (the CLOCKED command in HDL).

The feedback loop that was detected was probably
    InstructionDecode (ALU control bits) -> ALU
    ALU zr, ng -> InstructionDecode (jump logic)
Since the Hardware Simulator doesn't analyze the internal topology of the InstructionDecode chip at load time, it doesn't know that the two parts -- ALU control bits, jump logic -- don't interact.

[Hope this makes sense, it's early morning here and I'm working on my first cup of coffee...]

--Mark

[FairFriend]

Allow me to rephrase your explaination, to see whether I understood it correctly.

Some of the instruction bits (namely the most significat bit, the a bit, the dest bits and the jump bits) go to my decoder, some other (the comp bits) go to the ALU. The ALU output (zr, ng) are used in my decoder. The hardware simulator cannot tell that the two groups of control bits are in fact separated, and it assumes that there is an unclocked loop between the ALU and the decoder. Is that correct?

If that's the case is my implementation correct at least in theory?

[cadet1620]

FairFriend wrote

Allow me to rephrase your explaination, to see whether I understood it correctly.

Some of the instruction bits (namely the most significat bit, the a bit, the dest bits and the jump bits) go to my decoder, some other (the comp bits) go to the ALU. The ALU output (zr, ng) are used in my decoder. The hardware simulator cannot tell that the two groups of control bits are in fact separated, and it assumes that there is an unclocked loop between the ALU and the decoder. Is that correct?

If that's the case is my implementation correct at least in theory?

Yes, you are correct.  And your implementation using the Decode chip was theoretically correct.

I've built a version of the Hack computer running in Logisim, and it does use an InstructionDecoder part since I wanted to experiment with additional instruction types and wanted to be able to easily swap out decoders.

--Mark

[FairFriend]

Thank you Mark for you help. Unfortunately now I am presented with the same error message when I load the computer chip, but hopefuly I will find a solution on my own now that I know the causes. Thank you again for you time :)