Incomplete PC chip specification

[phayter]

The book and API have a very simple spec for the PC chip which specifies behavior only when the individual controls (load, inc, reset) are *individually* asserted. There is no specification for when more than one are asserted. The cmp file contains and the YouTube video shows expected behavior when more than one control is asserted. Apparently the control pins have a priority to each other, but this is not specified. For instance, reset and load assertions each individually override an inc assertion.

Please update the specification to fully describe the expected behavior. The only other alternatives are to reverse engineer the cmp file (an unnecessary pain) or skip the implementation of this chip (an unfortunate, but practical choice).

[phayter]

More information for others who run into this. Reverse engineering the cmp file gives the following additional requirements for this chip:

reset    load    inc        behavior
  0         1       1     --> load
  1         1       0     --> reset
  1         1       1     --> reset
  1         0       1     --> reset

There are 4 legal states for these control lines (3 individually asserted and one none-asserted). The table above has expected behavior for the 4 other states, for a total of 8 states of these 3 control lines.

My design passed the test file with modifications to meet these additional requirements.

[WBahn]

Are you talking about the 1ed or 2ed of the book?

The 1ed is very explicit about the prioritization of the control signals. Look at the spec given in Figure 3.5. I would be a bit surprised if the 2ed didn't have the same spec.

The reset signal takes priority over everything. Only if it is NOT asserted does anything else come into play (everything else is in the 'else' clause of the spec). The remaining signals are described similarly. Hence the priority is: reset, load, inc

reset load  inc function
  0      0     0   hold 
  0      0     1   increment 
  0      1     0   load 
  0      1     1   load 
  1      0     0   reset 
  1      0     1   reset
  1      1     0   reset
  1      1     1   reset

Personally, I think the spec is unnecessarily complicated. There's no situation where you want it to just hold the current value (unless it's due to reset or load being asserted) and the CPU design provides no means to place it in a hold condition anyway. Thus the 'inc' pin could be eliminated altogether and the logic trimmed considerably.

[phayter]

I am talking about the 2nd edition of the book.

While the API with its if..else structure connotes the priority of reset, then load, then inc, the text on bottom of page 54 does not, particularly the 'Usage' section:

    When inc==1, the counter increments its state in every clock cycle, effecting the operation PC++. If we want to reset the counter to 0, we assert the reset bit; if we want to set the counter to the value v, we put v in the in input and assert the load bit, as we normally do with registers. ...

    Usage: ... To reset the PC, assert the reset bit and the other control bits to 0. To have the PC increment by 1 in each time unit until further notice, assert the inc bit and set the other control bits to 0, To set the PC to the value v, set the in input to v, assert the load bit, and set the other control bits to 0.

I guess in my initial design, which failed the tests, I relied too much on the written text rather than a strict interpretation of the API. There is no text description of behavior when more than one control line is asserted, while there are specific descriptions of asserting only one control line.

My recommendation is to clarify the text to be consistent with the full expectation of the API.

[WBahn]

The Usage section is compliant with the spec. In essence, the spec describes how the chip is supposed to behave under all combinations of the control signals, while the description of the "proper" way to use the chip is to assert only one control signal at a time. I don't know why the authors chose to recommend a more limited use. My guess is that they felt it would be easier for some people to understand the use of the part if only one control signal is asserted at a time. But making that the spec would significantly complicate the design of the part as well as result in undefined behavior, so the spec is prioritized, making the implementation super simple, while being compatible with the recommended use.

Years ago I recommended that the 'inc' signal be eliminated from the design, but they chose to retain it in the 2ed. I don't know if that was a deliberate decision, or just something that was too low a priority and fell off the radar.