{"id":1587,"date":"2023-07-10T20:57:33","date_gmt":"2023-07-11T01:57:33","guid":{"rendered":"https:\/\/www.computercollection.net\/?p=1587"},"modified":"2023-07-10T20:57:33","modified_gmt":"2023-07-11T01:57:33","slug":"ibm-1410-fpga-off-to-the-races","status":"publish","type":"post","link":"https:\/\/www.computercollection.net\/index.php\/2023\/07\/10\/ibm-1410-fpga-off-to-the-races\/","title":{"rendered":"IBM 1410 FPGA: Off to the Races??"},"content":{"rendered":"\n

Once the 1415 console emulation was up and running, I was able to run diagnostics. The first set of diagnostic failures arose in the Assembly Channel because the Automated Logic Diagrams I had for parts of the Assembly Channel were not for the 1410 Accelerator feature, unlike the vast majority of ALD pages I had.<\/p>\n\n\n\n

Once I fixed that, diagnostic CU01 ran OK in non-overlapped non-priority (interrupt) mode. However, once I enabled overlapped I\/O with the priority feature in the diagnostic settings, the diagnostic errored out with an Instruction Check. The overlapped I\/O is that of the 1415 console. The diagnostic then monitors that (along with a priority interrupt) to make sure that the channel status information and the interrupt operate as expected.<\/p>\n\n\n\n

The Assembly Channel issue had been reproducible using a single instruction, and I could set that instruction in the initialization of the first 10K memory module, so I was able to troubleshoot it using simulation. But not this one – it happens after 10s of thousands of instructions. I had been less than confident about using the built-in logic analyzer capability that Vivado affords for Xilinx chips, but this problem left me no choice. Fortunately, after just one false start, I was able to figure out how to make a change in the signals the logic analyzer had available, set triggers, and so on – so, not so bad.<\/p>\n\n\n\n

Here is what the problem looked like that caused the Instruction Check. Note that the signal +S E CYCLE REQUIRED is going active (high) just after<\/em> signal -S LOGIC GATE A. Now, that should not be a problem, except that +S ERROR SAMPLE is also high at this point, and since Logic Gate A is active, as well as E Cycle Required, the logic in the CPU sees that as a possible problem – knowing that if E Cycle Required is active, it ought to be activating Logic Gate R rather than Logic Gate A. (Note: At this point I had not included +S E CYCLE REQUIRED A (one of four different ways that +S E CYCLE REQUIRED can be asserted – and which turned out to be the “villan” in this case. Anyway, here is what the output of the logic analyzer looked like:<\/p>\n\n\n\n

\"E
E Cycle Required Request with a Race Condition<\/figcaption><\/figure>\n\n\n\n

Now, this was not occurring on all or even anywhere near a majority of overlapped I\/O operations. Below is an example (using the very same FPGA configuration) of a successful overlap. Note that in this example, +S E CYCLE REQUIRED is asserted much earlier – along with -S LOGIC GATE E so there is no race – E Cycle Required is ready and present long before the time of+S LOGIC GATE Z when the CPU makes the decision between Logic Gate A and Logic Gate R is made.<\/p>\n\n\n\n

\"IBM
IBM 1410 FPGA Overlapped I\/O Cycle With No Race Condition<\/figcaption><\/figure>\n\n\n\n

So, I went looking for possibilities:<\/p>\n\n\n\n