{"id":1611,"date":"2023-07-25T11:40:10","date_gmt":"2023-07-25T16:40:10","guid":{"rendered":"https:\/\/www.computercollection.net\/?p=1611"},"modified":"2023-07-25T16:43:58","modified_gmt":"2023-07-25T21:43:58","slug":"ibm-1410-fpga-address-exit-state-right","status":"publish","type":"post","link":"https:\/\/www.computercollection.net\/index.php\/2023\/07\/25\/ibm-1410-fpga-address-exit-state-right\/","title":{"rendered":"IBM 1410 FPGA: (Address) Exit Stage Right"},"content":{"rendered":"\n

With the 1410 mode CPU running correctly, it was time to test out the 1401 side of things. The 1410 has a toggle switch, allowing the CPU to run as an IBM 1401 compatible with most 1401 programs. The 1410 and 1401 are similar, architecturally. The biggest difference is that the 1401 uses 3 character addresses, with the zone bits over the units and hundreds positions in order to address up to 16,000 characters, whereas the 1410 uses 4 character addresses, capable of addressing memory up to 100,000 characters.<\/p>\n\n\n\n

The primary 1401 diagnostic is M011. Once I figured out a problem involving the 1401 addressing scheme<\/a>, I turned my attention to the next failure: The Store A Address Register (SAR) instruction died a horrible death with B Channel, Address Channel and B Character Select Errors. That problem manifested as a failure to copy the A Address Register to the B Address Register for storing later. I tried for a bit to fix this first, but was not immediately successful, so I decided to try and NOP out the uses of SAR, that mostly had to do with storing the address of each test so it could print out a failure message. <\/p>\n\n\n\n

Having done so, the next problem quickly cropped up: the partner instruction for the B address register, Store B Address Register (SBR) also failed – it is essentially the same as SAR, but without that first step of transferring the AAR to the BAR. And the failure error was different as well: an Address Chanel Exit error. The ALD for this circuit is 18.14.02.1 . The ILD is on figure 59 at coordinate 2B – however there is also an error<\/em> in that ILD. It shows the GateOff input to trigger DEZ as ground (the usual ground symbol). However, on the ALD, the F input it connect to M, which is -12 Volts, and in my scheme, that is logic 0. (Logic 1 being 0V).<\/p>\n\n\n\n

The timing diagram below shows the timing issue. The B Address Register read out and validity check look<\/em> like they are OK with respect to the Address Exit flip flop ACSET signal. However, <\/em> the problem was that the VHDL for implementing the SMS card type DEZ has a 3 clock cycle “silo” for ACSET, so that the flip flop is not really set until 3 clock cycles after its ACSET input. In addition, there was no such silo<\/em> for the other inputs. This silo was put in place to give the ACSET signal some noise immunity – so that a 1 cycle glitch would not set the trigger. But the fact that the other inputs did not have a silo meant that they were sampled 3 clock cycles (FPGA_CLK) after ACSET, and by that time the B Address Register Readout signal (PS_RO_B_AR, i.e. +S RO B AR) had become inactive.<\/p>\n\n\n\n

\"Timing
Delay in the Address Exit Check inputs with respect to the readout of the B address Register, resulting in an Address Exit Check.<\/figcaption><\/figure>\n\n\n\n

The relevant VHDL looked like this:<\/p>\n\n\n\n

   SMS_DEZ_PROCESS: process(FPGA_CLK, ACSET, DCSET, DCRESET, DCRFORCE, DCSFORCE)\n        begin\n        if(rising_edge(FPGA_CLK)) then\n           if(DCRESET = '0' OR DCRFORCE = '1') then\n              OUTOFF <= '1';\n              OUTON <= '0';\n              SSTAGE1 <= ACSET;\n              SSTAGE2 <= ACSET;\n              SSTAGE3 <= ACSET;\n           elsif(DCSET = '0' OR DCSFORCE = '1') then\n              OUTON <= '1';\n              OUTOFF <= '0';\n              SSTAGE1 <= ACSET;\n              SSTAGE2 <= ACSET;\n              SSTAGE3 <= ACSET;\n           else\n              SSTAGE1 <= ACSET;\n              SSTAGE2 <= SSTAGE1;\n              SSTAGE3 <= SSTAGE2;\n              if(GATEON = '1' AND SSTAGE2 = '1' AND \n                SSTAGE1 = '1' AND SSTAGE3 = '0') then\n                  OUTON <= '1';\n                  OUTOFF <= '0';\n                elsif(GATEOFF = '1' AND SSTAGE2 = '1' AND\n                  SSTAGE1 = '1' AND SSTAGE3 = '0') then\n                   OUTOFF <= '1';\n                   OUTON <= '0';               \n               end if;\n            end if;\n        end if;\n        end process;\n<\/code><\/pre>\n\n\n\n
Once I realized what was going on, the fix was pretty easy.  Just add a 3 clock silo for the inputs as well as ACSET.  I took the conservative approach, however, and created a separate special instance of SMS_DEZ.vhdl, called SMS_DEZ_SYNC.vhdl to use in the Address Exit validity check logic.  This new implementation of DEZ would probably<\/em> work fine across the board, but I am just using it in the one place, for now.  <\/p>\n\n\n\n
The timing diagram below shows that now the OUTON signal does not activate – no Address Exit Check, because now the inputs are sampled at the same time as ACSET, and those inputs are still active from the B Address Register readout.<\/p>\n\n\n\n
\"Timing
Timing diagram for 1401 mode SBR after fixes.<\/figcaption><\/figure>\n\n\n\n
The relevant VHDL looks like this, for gate type SMS_DEZ_SYNC:<\/p>\n\n\n\n
    SMS_DEZ_PROCESS: process(FPGA_CLK, ACSET, DCSET, DCRESET, DCRFORCE, DCSFORCE)\n        begin\n        if(rising_edge(FPGA_CLK)) then\n           if(DCRESET = '0' OR DCRFORCE = '1') then\n              OUTOFF <= '1';\n              OUTON <= '0';\n              SSTAGE1 <= ACSET;\n              SSTAGE2 <= ACSET;\n              SSTAGE3 <= ACSET;\n              GON1 <= GATEON;\n              GON2 <= GATEON;\n              GON3 <= GATEON;\n              GOFF1 <= GATEOFF;\n              GOFF2 <= GATEOFF;\n              GOFF3 <= GATEOFF;\n           elsif(DCSET = '0' OR DCSFORCE = '1') then\n              OUTON <= '1';\n              OUTOFF <= '0';\n              SSTAGE1 <= ACSET;\n              SSTAGE2 <= ACSET;\n              SSTAGE3 <= ACSET;\n              GON1 <= GATEON;\n              GON2 <= GATEON;\n              GON3 <= GATEON;\n              GOFF1 <= GATEOFF;\n              GOFF2 <= GATEOFF;\n              GOFF3 <= GATEOFF;\n           else\n              SSTAGE1 <= ACSET;\n              SSTAGE2 <= SSTAGE1;\n              SSTAGE3 <= SSTAGE2;\n              GON1 <= GATEON;\n              GON2 <= GON1;\n              GON3 <= GON2;\n              GOFF1 <= GATEOFF;\n              GOFF2 <= GOFF1;\n              GOFF3 <= GOFF2;\n              if(GON3 = '1' AND GON2 = '1' AND GON1 = '1' AND GATEON = '1' AND\n                SSTAGE2 = '1' AND  SSTAGE1 = '1' AND SSTAGE3 = '0') then\n                  OUTON <= '1';\n                  OUTOFF <= '0';\n                elsif(GOFF3 = '1' AND GOFF2 = '1' AND GOFF1 = '1' and GATEOFF = '1' AND \n                  SSTAGE2 = '1' AND SSTAGE1 = '1' AND SSTAGE3 = '0') then\n                   OUTOFF <= '1';\n                   OUTON <= '0';               \n               end if;\n            end if;\n        end if;\n        end process;\n<\/code><\/pre>\n\n\n\n
With that out of the way, I could run M011 diagnostics quite far into the tests, until it needed to use the SAR instruction for more than just tracking the test address.<\/p>\n","protected":false},"excerpt":{"rendered":"
With the 1410 mode CPU running correctly, it was time to test out the 1401 side of things. The 1410 has a toggle switch, allowing the CPU to run as an IBM 1401 compatible with most 1401 programs. The 1410 and 1401 are similar, architecturally. The biggest difference is that the 1401 uses 3 character … Continue reading “IBM 1410 FPGA: (Address) Exit Stage Right”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,9,15],"tags":[16],"post_folder":[],"class_list":["post-1611","post","type-post","status-publish","format-standard","hentry","category-computers","category-hardware","category-ibm1410","tag-ibm1410-2"],"_links":{"self":[{"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/posts\/1611","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/comments?post=1611"}],"version-history":[{"count":3,"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/posts\/1611\/revisions"}],"predecessor-version":[{"id":1622,"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/posts\/1611\/revisions\/1622"}],"wp:attachment":[{"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/media?parent=1611"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/categories?post=1611"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/tags?post=1611"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/www.computercollection.net\/index.php\/wp-json\/wp\/v2\/post_folder?post=1611"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}