I spent some time in the morning working on two issues: getting the FMC Carrier S6 board flash programmed with the logic configuration, and figuring out how to access a string embedded in a structure using ctypes and Python.
Digilent just opened a forum for users to communicate with them and each other. I posted a query about the problem programming my FMC Carrier S6 board, hoping to hear back in a few days when the return from holiday shutdown.
I switched the system on and once again I had reliable behavior of the signals injected into the 1131. I began mapping the signals that correspond to the incoming state from the 1131, with a fair degree of success right away. The signals are all scrambled compared to what I think I am sensing but I could locate 14 of the 16 B register bits, all four of the T clock signals and the Phase A signal.
Two of the B bits didn't seem to change any of the LEDs, which must mean they are actually different signals into the FPGA than I think because of mismapping of connector, 1131 signal and fpga pin. If the pattern I detect from the 19 known signals is consistent, I can infer the remaining signals, correct all the assignments and test again.
I did find a pattern, although it has a few oddities. I will rearrange all the incoming signals to what makes sense based on the pattern, then do some testing. Updating the documentation is the really tedious task but has to be done if I am to have any chance of maintaining this interface in the future.
Changing all the documentation then updating the VHDL took all day, but it was finally done before I went to bed. Tomorrow I can validate the correctness of all the signals using the 1130. The basic method for validation is to:
Two of the B bits didn't seem to change any of the LEDs, which must mean they are actually different signals into the FPGA than I think because of mismapping of connector, 1131 signal and fpga pin. If the pattern I detect from the 19 known signals is consistent, I can infer the remaining signals, correct all the assignments and test again.
I did find a pattern, although it has a few oddities. I will rearrange all the incoming signals to what makes sense based on the pattern, then do some testing. Updating the documentation is the really tedious task but has to be done if I am to have any chance of maintaining this interface in the future.
Changing all the documentation then updating the VHDL took all day, but it was finally done before I went to bed. Tomorrow I can validate the correctness of all the signals using the 1130. The basic method for validation is to:
- use Load mode to test the B register bits
- single step through the machine states and instructions to verify the T clocks and phase A
- execute an XIO instruction to validate XIOE1
- check interrupt level correspondence
- cause a parity error to validate parity stop
- verify clock out and meter out signals
Testing the cycle steal related incoming signals is more complex because the eight X clock steps can't be single stepped, they occur within a few hundred microseconds. I will change the use of a slide switch from triggering an interrupt level to commanding a cycle steal operation, which should show me the occurrence of the cycle steal L1 status signal as the machine loops continuously in cycle steal mode.
On the flash programming front, I discovered that the Adept utility should recognize the FMC Carrier S6 board and present a Flash Programming tab. Since it doesn't know what board it is seeing, it doesn't give me the means to load the flash. I should be able to load the flash through Xilinx Impact in the toolchain, if I can figure out the proper settings and configurations for the tool.
No comments:
Post a Comment