Friday, February 5, 2016

Need to upgrade to bigger FPGA to continue developing SAC Interface Unit


Implementing and testing the virtual 1442 function

My research into the 1442 adapter highlighted that a XIO Control with Stacker Select bit set will NOT cause an operation complete interrupt. Therefore, the only handling I need when a SS is issued is for the Python program to detect that and cause the punch buffer from the fpga to be written into the alternate file (if open). This eliminates the need to force op end interrupts by a transaction from the PC; it can be handled purely locally in the fpga.

After some discussions with Peter Vaughan of TNMoC (The National Museum of Computing in Bletchley, UK), it seems there is value in also supporting a 1442 mirror mode, capturing card images of physical cards as they are read or punched on a real 1442. The logic to support this is relatively close to the logic for the virtual function.

From a design standpoint, I need to add a switch to the 1130 to enable or disable its 1442 adapter and I need some means to tell the fpga to operate as a mirror or a virtual adapter. I can send a transaction from the Python code that tells the fpga which mode it will assume.

In the Python program, I need some logic to cause the first card to feed, when a new file was opened for reading and/or punching, when the program issues a Start Punch. On a real 1442, readying the device with cards in the hopper causes one card to feed into the pre-read station, but nothing is yet in the pre-punch area. The 1442 adapter logic will force a feed cycle on the Start Punch if this is so, advancing the card from pre-read to pre-punch in order to begin punching.

Hopper empty condition turns the device Not Ready, although a last card may be in the pre-read station and the next to last may be in the pre-punch station. Pushing the Start button on the read causes it to go ready and allow one more Start Read but has also set the Last Card bit in the DSW.

As I made the refinements to the 1442 logic that I had mentioned yesterday, the unthinkable happened. I ran out of space on the fpga! Too many LUTs needed. I suspect that some of my registers and buffers could be placed into block ram, freeing up a decent number of LUTs, but from this point I am going to have to start optimizing and making choices. Drat! This could slow me down.

In lieu of all the juggling and optimization, or removal of desired functions, I just bought a replacement ztex board, with the same 100 I/O pins but a much larger and faster Artix 7 FPGA on board. I moved from the 2.01 board with a XC6LX16 chip to to the 2.13c board with the XC7A75T fpga chip. I also get a huge onboard RAM as a bonus. It should arrive in about a week, meanwhile I can comment out some portions of the design to free up LUTs for near term testing.


  1. This post tickles my memory on stacker select. Does it perform any physical action T all, or does it just tell the 1442 where to put the card during the next punch cycle?

  2. The only action it takes in the 1442 is to energize a solenoid which stays latched until the end of the feed cycle that moves cards forward. The solenoid causes a card to be diverted to the alternate stacker.