Converting design to Vivado toolchain
I worked on the learning what it takes to import the logic over from ISE to Vivado, using the simpler slave fpga code first. Once that synthesized, but of course couldn't create a bit stream since the slave board fpga type (Spartan 6) is not supported in Vivado.
I moved onto the main board, where I had a FIFO whose IP had changed since I generated the module I was using. I got Vivado to upgrade it to the Artix 7 version and resynthesize. Next up was getting the UCF entries converted to some new 'XDC' format used by Vivado.
This learning curve chewed up quite a bit of time until I figured out how to build an XDC file that was equivalent to my old UCF document. Then, the actual entry of the file was an hour of tedium. I saw that the new board had the same connectors as the old board and the same number of IO connections from the fpga, but the pin numbers on the Artix 7 chip are completely different from the pin numbers of the Spartan 6 chip.
The same connector position but it requires a change of the pin number, which means changing 100 entries in the new constraint file. Sigh - another hour of tedium. Fortunately, I am getting closer to have a successful run of the toolchain through to bitstream creation. Syntax has changed to use TCL language, so a UCF entry for a std_logic_vector named FD would be FD<0> etc but in TCL it is {FD[0]} etc.
My block RAM used as buffers for 1403 and 1442, among others, required a new IP generation to use the native BRAM on the Artix 7 chip. Once I get those straightened out and my constraints file sorted properly, I managed to run the toolchain through to a bitstream.
Implementing mirror 1442 reader/punch
Fellow 1130 system restorers have a need for a variant of my virtual 1442 functionality - a mirror adapter that will capture card images being read and/or punched on a real 1442, so that a PC based file is captured. I began the work of altering the virtual 1442 function to provide mirror capability, switchable by the user of my SAC Interface Box.
A mirror device will follow all the XIO instructions, cycle steals and interrupts that are involved with the use of a real device, shadowing the behavior in order to grab the data that is being transferred between the reader/punch and the 1130. A mirror device needs to be fast enough to have the data written or read picked up by the PC side program and put into a file, before the next card is read or written.
In order to use the virtual 1442 capabilities, the machine needs to have additional signals wired between the 1130 and my box. The SAC cable on an 1130 does not display nor trigger interrupts on level 0, which are used by the reader/punch to transfer the data for each card column. Mirror functionality doesn't actually need to see when IL0 is active, while virtual functionality needs to both observe and trigger IL0. The 1442 does not use cycle steal.
My Python program on the PC side will get a copy of the XIO Control command used to start reading a card, start punching a card, select the alternate stacker, or feed a card without reading. The Python program then writes the card image from a PC file into the pre-read station buffer of the fgpa. With mirror function, these are assumed to always be blank cards, so that is what is pushed down by the Python code.
When the real 1442 card has data approaching the solar cells, for each card column, it triggers an interrupt on IL0 and the software on the 1130 issues an XIO Read to capture the card image into core memory. I just need to grab the data word that is being written into core for each of the 80 XIO Read instructions, overwriting the pre-read buffer with those contents. At the end of the 80th column, my function will claim to the Python program that it saw an XIO Init Write instruction, to have the PC side do some things before the mirror card reader copies the contents of the pre-read buffer to the pre-punch station buffer.
For a card punching operation, the IL0 interrupts cause the software in the 1130 to issue XIO Write commands that fire punches in the current card column of the card in the pre-punch station. The mirror adapter will OR the bits from the word written by the XIO Write into the pre-punch buffer location, since a real punch will add holes atop whatever was in the card before. At the end of the cycle, it also mocks up an XIO Init Write command to have the PC side do its thing
The PC side will see the false XIO Init Write and fetch the contents of the pre-punch buffer, which has has the N-1 card image that was read plus any new holes punched. If not punching, or simply doing a feed, the data in the pre-punch buffer is the N-1 card that was read or fed. This models the real 1442 which has multiple stations where cards sit during operation. There can be two cards sitting in the machine at any time, one ready to be read and the next, which already passed the read station via read or feed, is ready to be punched.
The PC program for the mirror 1442 will fetch the pre-punch buffer on every read/feed/punch except for the first, since the first time a new set of cards is put in the hopper, the pre-punch station was empty and nothing comes out of the hopper. The read or feed will have advanced card 1 from pre-read to pre-punch, but nothing moved from the pre-punch to the stacker. On subsequent cards, the N-1 card read will pop out into the stacker. The Non Process Run Out (NPRO) button flushes any cards inside the machine to the stacker.
I have to add a command that switches the 1442 adapter between mirror and virtual modes. The user has to pull down a signal inside the 1131 when running as a virtual device, to block the action of the real 1442 adapter circuitry, then remove that pull down if using the physical device. This should be a switch operated by the user, rather than a jumper wire.
My Python program on the PC side will get a copy of the XIO Control command used to start reading a card, start punching a card, select the alternate stacker, or feed a card without reading. The Python program then writes the card image from a PC file into the pre-read station buffer of the fgpa. With mirror function, these are assumed to always be blank cards, so that is what is pushed down by the Python code.
When the real 1442 card has data approaching the solar cells, for each card column, it triggers an interrupt on IL0 and the software on the 1130 issues an XIO Read to capture the card image into core memory. I just need to grab the data word that is being written into core for each of the 80 XIO Read instructions, overwriting the pre-read buffer with those contents. At the end of the 80th column, my function will claim to the Python program that it saw an XIO Init Write instruction, to have the PC side do some things before the mirror card reader copies the contents of the pre-read buffer to the pre-punch station buffer.
For a card punching operation, the IL0 interrupts cause the software in the 1130 to issue XIO Write commands that fire punches in the current card column of the card in the pre-punch station. The mirror adapter will OR the bits from the word written by the XIO Write into the pre-punch buffer location, since a real punch will add holes atop whatever was in the card before. At the end of the cycle, it also mocks up an XIO Init Write command to have the PC side do its thing
The PC side will see the false XIO Init Write and fetch the contents of the pre-punch buffer, which has has the N-1 card image that was read plus any new holes punched. If not punching, or simply doing a feed, the data in the pre-punch buffer is the N-1 card that was read or fed. This models the real 1442 which has multiple stations where cards sit during operation. There can be two cards sitting in the machine at any time, one ready to be read and the next, which already passed the read station via read or feed, is ready to be punched.
The PC program for the mirror 1442 will fetch the pre-punch buffer on every read/feed/punch except for the first, since the first time a new set of cards is put in the hopper, the pre-punch station was empty and nothing comes out of the hopper. The read or feed will have advanced card 1 from pre-read to pre-punch, but nothing moved from the pre-punch to the stacker. On subsequent cards, the N-1 card read will pop out into the stacker. The Non Process Run Out (NPRO) button flushes any cards inside the machine to the stacker.
I have to add a command that switches the 1442 adapter between mirror and virtual modes. The user has to pull down a signal inside the 1131 when running as a virtual device, to block the action of the real 1442 adapter circuitry, then remove that pull down if using the physical device. This should be a switch operated by the user, rather than a jumper wire.
No comments:
Post a Comment