Testing 1442 reader/punch logic
Imagine my surprise to find that I had not instantiated a module to respond to XIO Control, which explains perfectly why my adapter logic didn't trigger on the attempt to read a card. Doh. Software reads using an XIO Control with a modifier bit to signal Start Read. I added that in along with some good diagnostics.
I found the spot to jumper off the recognition of XIOs to area code 2, which is the 1442 device. Gate A, compartment C1, card F3, pin D06 will be jumpered to ground, pin D08. This keeps the Area 2 signal false at all times. That leaves my adapter free to respond to any XIOs aimed at the virtual card reader. Later I will replace the simple jumper with a nice SPST switch and label it "Disable 1442 support".
blue jumper disables 1442 adapter inside 1130 |
I found a comment somebody posted on an EDA board that the too many bits false error I have been hitting can be fixed by setting the Xilinx ISE tool to windows 7 compatibility mode. I did this and so far no more errors, which were happening almost every other time I tried to build a new bitstream. Crossing my fingers this works.
I have my new Artix 7 75T chip based board but will continue my testing with the current Spartan 6 16C based board since I believe I have to switch over to the Vivado design suite from ISE in order to build logic for the Artix. That brings a whole set of possible problems that I don't want to trigger right now. Since my current logic is less than half the size of the Spartan 6 board, I don't have to make a move right away.
New board, FPGA more than 5X capacity of old board |
I dug into the logic and found that my trigger to spot when an XIO is executing on behalf of the card reader took the area code from my UCW table, but I had incorrectly initialized that to 00011, area code 3, instead of area code 2, 00010. The fix was made and I got back out to test once the bitstream was generated. Still no sign of the false errors now that the Xilinx ISE toolchain is in Win7 compatibility mode!
Now my logic saw and responded to the XIO Control, correctly saw that bit 13 was on, indicating Start Read, but my logic in the Python program failed to see it properly. I mistook it for an invalid Control code. I proceeded to correct a series of Python code flaws hoping to finally get to the point where I pushed down the card image to the pre-read buffer and began triggering fpga logic again.
I confirm that my write logic is pushing 80 words of data in 8 transactions, loading the pre-read buffer. What should happen, but does not, is the last push of the data should move the 'feed cycle' FSM forward but I see it sitting in the idle state. I am now narrowing my look at the FPGA logic that handles the push of the pre-read words and the feed cycle FSM.
I thought I knew what was wrong but I still am not seeing the 1442 kick off its feed cycle after the data is pushed down to the pre-read buffer. I am going to need plenty of diagnostics as well as to pore over the logic. With only 7 LEDS (plus eight bits I could display on the GUI), it may take many cycles picking sets of signals until I find the most informative set.
After more progress, I ended the evening with the feed cycle moved to its armed state and waiting for the write process that loaded the pre-read buffer to signal completion. Somehow that next step is not take. Now I now what to zoom in and watch.
No comments:
Post a Comment