As the haze and malaise of my fever begins to subside, I've started looking for the problems in my Verilog implementation. I found a couple minor problems — one allowed the external data bus to float when POC was asserted, the other failed to output the Carry bit on D0 during the X3 phase — but nothing that would prevent basic functionality from operating, like initializing the IP DRAM array during POC.
While I won't be surprised if there are more real errors, it's starting to look like most of the problem is how picky the Verilog simulator is being regarding uninitialized, or 'X', inputs. I suspect that the system would eventually stabilize if these inputs were either 0 or 1 (most likely 1, given the resistive pull-ups), but the X values keep propagating.
Update: I decided to initialize the OPR and OPA registers to zero. These are the inputs to the instruction decoder, and thus cause almost all the 'X' signals to become defined by the end of the first instruction cycle. My test bench code drives an "INC R1" instruction onto the external data bus during each instruction cycle, and I can see scratchpad register 1 incrementing. This is a HUGE step forward.
Unfortunately, I also see the Instruction Pointer counting 000, 001, 002, 062, 063, 062, 063 (hex) and so on. The IP incrementer works properly in the unit test, so there must be something in the interaction with the other components on the data bus. An "INC R1" instruction is coded as 61 (hex), which could be a hint.
Later update: After spending three hours looking for a bug in the incrementer that would cause a jump from 002 to 062, the truth occurred to me: there isn't a bug in the incrementer, there's a bug in the instruction decoder. Because of an error in interpreting the schematic, it's executing my "INC R1" opcode as a JCN instruction and as an INC instruction. At the same time. With ugly results.
That it took me three hours to notice this is why I'm not working on "real work" yet: I'm not quite back to normal and I'd probably screw it up.
While I won't be surprised if there are more real errors, it's starting to look like most of the problem is how picky the Verilog simulator is being regarding uninitialized, or 'X', inputs. I suspect that the system would eventually stabilize if these inputs were either 0 or 1 (most likely 1, given the resistive pull-ups), but the X values keep propagating.
Update: I decided to initialize the OPR and OPA registers to zero. These are the inputs to the instruction decoder, and thus cause almost all the 'X' signals to become defined by the end of the first instruction cycle. My test bench code drives an "INC R1" instruction onto the external data bus during each instruction cycle, and I can see scratchpad register 1 incrementing. This is a HUGE step forward.
Unfortunately, I also see the Instruction Pointer counting 000, 001, 002, 062, 063, 062, 063 (hex) and so on. The IP incrementer works properly in the unit test, so there must be something in the interaction with the other components on the data bus. An "INC R1" instruction is coded as 61 (hex), which could be a hint.
Later update: After spending three hours looking for a bug in the incrementer that would cause a jump from 002 to 062, the truth occurred to me: there isn't a bug in the incrementer, there's a bug in the instruction decoder. Because of an error in interpreting the schematic, it's executing my "INC R1" opcode as a JCN instruction and as an INC instruction. At the same time. With ugly results.
That it took me three hours to notice this is why I'm not working on "real work" yet: I'm not quite back to normal and I'd probably screw it up.
No comments:
Post a Comment