The problem with the use of the wrong two leads on the C-D side cable has been corrected. I removed the two inappropriate lines, which were connected to the 3.3V supply on the fpga, and connected the two leads which are my chosen replacement, which were left full length when I originally manufactured the cable.
I cleaned up the few mixups in the fpga logic and in the PC side program, thus ready to commence testing as soon as it was light enough outside. I also converted the power connectors on the three old boards into fixed connections, since the connectors were all too prone to pop off.
I had a good morning steadily resolving issues and validating signals. The toughest inbound signals to test are those that occur fleetingly, such as the X-clocks and CS level signal, or parity stop that requires me to force a parity check. Slightly tougher are the XIO E1 signal and the other three (2, 3 and 4) interrupt levels, but there are means to drive the system to get to these states.
The incoming signal wires for bits 0 and 1 of the B register were touching together on the receiver board, which I easily corrected. I also found that the wires for Parity Stop and X2 are reversed relative to my documentation, as far as which circuit on the receiver cards each is wired to. A simple matter to adjust the FPGA logic and the documentation, correcting this flaw.
I found that my wiring for the signals for bits 12, 13, 14 and 15 of the B register doesn't correspond to my documentation, nor the fpga logic, which required some investigation. The bits are wired to rows 13 and 14 of connector A-B, but I was looking for them at rows 24 and 25.
I updated the documentation and then the FPGA logic during my lunch break, then went out to test again. I now had 15 of the 16 bits working properly, but when I looked at voltage levels on board 2, they ran a bit low. Further, the signals were noisy and muddy. This was the board that had the ground pin unconnected, which I tried to fix by hooking a wire to a via pad that was attached to ground. It is obvious that this introduced too much resistance, bouncing the ground level up and down to the detriment of good signal behavior.
I hauled out the reflow oven, a spare board blank and my remaining components. I had enough to build a board with all twelve receiver circuits, with a board that has good ground connectivity. Using my paste mask, I spread paste solder onto the pads for all the components, then painstakingly placed 96 teeny surface mount parts in their proper locations. The board went in the oven to reflow, then after cooling I hand soldered all the headers on that provide the connections on and off the board, plus power lines.
Time to cut 27 wires away from the existing board 2, install them on the replacement board and place it in position inside the SAC interface. Right now the four boards and the fpga are loose, allowing access to all the cabeling and the signal pins, but once I am done debugging the signal paths from fpga to 1131, and reverse, I can mount them and close up the box.
I still have the problem with the failed ROM on the FPGA board from which it should load its bitstream on power-up. Presently I am manually loading the bitstream each time I turn the box on, but this has to be fixed in order to really close this up and concentrate purely on logical reconfigurations via USB.
After replacing board 2, I have accurate capture of the B register and the other signals to the extent that I can check them. Here are the anomalies to investigate, some of which may be intended behavior:
- Meter Out is active whether the machine is running or not
- Inhibit Cycle Steal is erratically delivered
I want to do tests to verify the following, all of which require a bit more cleverness or some additional logic in the FPGA to drive certain conditions:
- Verify that Parity Stop is flagged when we experience a parity check
- Ensure that XIO E1 is raised at the appropriate machine cycle
- Trigger interrupts on the four levels and verify the proper line is on in return
- Trigger cycle steal and verify CS Level is returned, reads from loc 0 and contents in B
- Verify the states X0, X2, X4 and X6 during cycle steal, in proper sequence
- check to see that Chan Write Gate is activated by fpga
I have a few open lines to the FPGA that I can use with switches, in pullup mode, to select specific conditions to test. Wiring them in, I did my first set of tests, verifying that I can trigger interrupts on levels 2, 3, 4 or 5 and correctly see that status back from the 1131. I began to work on use of the switches to trigger cycle steal, allowing me to verify several other signals as well as the proper activation and status signal.
The switches didn't trigger any behavior I could detect - although if cycle steal is a single shot trigger rather than continuous requests, then I would need to watch with the scope to catch the cycle as it is full speed, 3.6 microseconds in duration. Some study required to formulate the best testing regimen.
I checked my driver board circuits for the four signals I was trying to drive - cycle steal request, channel write gate, block clock advance and advance entry - discovering that one of the circuits is not working properly. It should be up around 2.8 or 2.9V until I pull it down to zero when activated, but this is down around a quarter volt whether the input is on or off. I suspect this is the cycle steal request line, but whatever it is, something is not right.
I did figure out how to force a parity error - pretty easy, actually. Single Step the machine up to T2, by which time it will have read the contents of the core location, but not yet rewritten the location. Reading core is a destructive process, requiring the data that is read to be written back if you want the location unchanged.
Since I stopped it at T2 and did a reset, we had zeroed out location 0 but not yet written back data. All zeroes requires that the two parity bits P1 and P2 be set to achieve the odd parity level for each half. When we read it out, it reset all 16 data bits and both parity bits.
The next time the contents of the location are read, when that value is checked for parity, the processor detects an even number of 'on' bits and goes into a Parity Check stop. That condition is clearly reflected on card 1 circuit 11, turning on for a parity stop and off when the system is in normal state.
I then hand coded an XIO Sense Device instruction and stepped it in SMC mode until I was in the E1 state of the instruction. At that point, I validated that the XIO E1 signal is properly detected. More solid progress!
I looked at the Inhibit CS signal which seemed to be active according to my PC program, but shouldn't be. Putting a voltmeter on the signal from the 1131, I can see that the signal is not activated, yet my circuit is putting out 3.3V when it should be down near zero. This is on the newly rebuilt board, but is similar to the erroneous behavior with the old. This tells me I have a problem that needs some investigation.
I will be prioritizing the diagnosis of the driver circuit and the inhibit CS signal receiver circuit, since I can't really test the cycle stealing related signals until the driver is working. I am in from the workshop and doing some FPGA logic development, preparing for using the PC link in two way mode. My first function from the PC will be a simple 'write this word in this address' command using the cycle steal circuitry.
I had a good morning steadily resolving issues and validating signals. The toughest inbound signals to test are those that occur fleetingly, such as the X-clocks and CS level signal, or parity stop that requires me to force a parity check. Slightly tougher are the XIO E1 signal and the other three (2, 3 and 4) interrupt levels, but there are means to drive the system to get to these states.
The incoming signal wires for bits 0 and 1 of the B register were touching together on the receiver board, which I easily corrected. I also found that the wires for Parity Stop and X2 are reversed relative to my documentation, as far as which circuit on the receiver cards each is wired to. A simple matter to adjust the FPGA logic and the documentation, correcting this flaw.
I found that my wiring for the signals for bits 12, 13, 14 and 15 of the B register doesn't correspond to my documentation, nor the fpga logic, which required some investigation. The bits are wired to rows 13 and 14 of connector A-B, but I was looking for them at rows 24 and 25.
I updated the documentation and then the FPGA logic during my lunch break, then went out to test again. I now had 15 of the 16 bits working properly, but when I looked at voltage levels on board 2, they ran a bit low. Further, the signals were noisy and muddy. This was the board that had the ground pin unconnected, which I tried to fix by hooking a wire to a via pad that was attached to ground. It is obvious that this introduced too much resistance, bouncing the ground level up and down to the detriment of good signal behavior.
I hauled out the reflow oven, a spare board blank and my remaining components. I had enough to build a board with all twelve receiver circuits, with a board that has good ground connectivity. Using my paste mask, I spread paste solder onto the pads for all the components, then painstakingly placed 96 teeny surface mount parts in their proper locations. The board went in the oven to reflow, then after cooling I hand soldered all the headers on that provide the connections on and off the board, plus power lines.
 |
| Replacement circuit board for board 2 - receiver circuits |
 |
| Boards connected but not mounted in position yet |
After replacing board 2, I have accurate capture of the B register and the other signals to the extent that I can check them. Here are the anomalies to investigate, some of which may be intended behavior:
- Meter Out is active whether the machine is running or not
- Inhibit Cycle Steal is erratically delivered
I want to do tests to verify the following, all of which require a bit more cleverness or some additional logic in the FPGA to drive certain conditions:
- Verify that Parity Stop is flagged when we experience a parity check
- Ensure that XIO E1 is raised at the appropriate machine cycle
- Trigger interrupts on the four levels and verify the proper line is on in return
- Trigger cycle steal and verify CS Level is returned, reads from loc 0 and contents in B
- Verify the states X0, X2, X4 and X6 during cycle steal, in proper sequence
- check to see that Chan Write Gate is activated by fpga
I have a few open lines to the FPGA that I can use with switches, in pullup mode, to select specific conditions to test. Wiring them in, I did my first set of tests, verifying that I can trigger interrupts on levels 2, 3, 4 or 5 and correctly see that status back from the 1131. I began to work on use of the switches to trigger cycle steal, allowing me to verify several other signals as well as the proper activation and status signal.
The switches didn't trigger any behavior I could detect - although if cycle steal is a single shot trigger rather than continuous requests, then I would need to watch with the scope to catch the cycle as it is full speed, 3.6 microseconds in duration. Some study required to formulate the best testing regimen.
I checked my driver board circuits for the four signals I was trying to drive - cycle steal request, channel write gate, block clock advance and advance entry - discovering that one of the circuits is not working properly. It should be up around 2.8 or 2.9V until I pull it down to zero when activated, but this is down around a quarter volt whether the input is on or off. I suspect this is the cycle steal request line, but whatever it is, something is not right.
I did figure out how to force a parity error - pretty easy, actually. Single Step the machine up to T2, by which time it will have read the contents of the core location, but not yet rewritten the location. Reading core is a destructive process, requiring the data that is read to be written back if you want the location unchanged.
Since I stopped it at T2 and did a reset, we had zeroed out location 0 but not yet written back data. All zeroes requires that the two parity bits P1 and P2 be set to achieve the odd parity level for each half. When we read it out, it reset all 16 data bits and both parity bits.
The next time the contents of the location are read, when that value is checked for parity, the processor detects an even number of 'on' bits and goes into a Parity Check stop. That condition is clearly reflected on card 1 circuit 11, turning on for a parity stop and off when the system is in normal state.
I then hand coded an XIO Sense Device instruction and stepped it in SMC mode until I was in the E1 state of the instruction. At that point, I validated that the XIO E1 signal is properly detected. More solid progress!
I looked at the Inhibit CS signal which seemed to be active according to my PC program, but shouldn't be. Putting a voltmeter on the signal from the 1131, I can see that the signal is not activated, yet my circuit is putting out 3.3V when it should be down near zero. This is on the newly rebuilt board, but is similar to the erroneous behavior with the old. This tells me I have a problem that needs some investigation.
I will be prioritizing the diagnosis of the driver circuit and the inhibit CS signal receiver circuit, since I can't really test the cycle stealing related signals until the driver is working. I am in from the workshop and doing some FPGA logic development, preparing for using the PC link in two way mode. My first function from the PC will be a simple 'write this word in this address' command using the cycle steal circuitry.
No comments:
Post a Comment