Last night I redesigned the logic for the PC link, building up in layers from a solid approach. The innermost logic is a state machine that reads two words from the PC then waits until triggered to write back words or return to idle waiting for the next input. The next level up establishes the transactions, such as 'store in core' or 'trigger interrupt' or 'fetch WCA address'.
The transactions consist of a command word followed by a second word - the command may request an action or it may ask for data. These types are called imperative and interrogative respectively. Each transaction ends with an echo of the first (command) word and either an echo of word 2 for imperatives or some data returned as the second word for interrogatives.
The lowest level machine - to read two words then write a variable number of words - should be set as it is, subject to testing. The next machine, establishing transactions, is the one that also sets up the outgoing data or latches incoming values, so it needs to be more carefully written to work with the lowest machine. The transactional machine waits after it latches in the second word, having set off another state machine assigned to each command. When the other state machine has completed its function, it triggers the transaction machine when then writes back results until done.
Building up the layers involved various FSMs that will produce an output word that is transmitted back to the PC at the end of a transaction. I was most concerned with the FSM to send back status words, as that should be easiest to test. After that, I would work on the machines that load the SAR and SDR shadow registers. Finally, a test of cycle steal fetch and store would be a solid stopping point. For each test, I worked out some diagnostic signals to emit on the temporary lights.
The first test was to watch the link while the Python program sends a status request to the box and the box returns the correct status. I will be able to tell if the innermost link FSM completes or sticks in one state, same with the transactional FSM. I also watched to see what command was latched and the word sent back from the viewpoint of the fpga.
The link was not working and I wasn't sure which side of the link was at fault. After some detailed testng I found a couple of flaws in the fpga logic and successfully get through the innermost FSM, latching in the command and data words. The higher level transaction FSM recognizes the send status command, fired off that state machine, received the completion trigger and wrote both words back.
The problem I am now having is a timeout on the PC side trying to read the second word. It will take a bit of investigation to determine whether I failed to send the second word or whether the code on the PC side is in error. The general functioning of the link and transaction machines seem good.
I did have a problem with the pyusb code on the PC side, which is now fixed. At this point, I sent a Status Request interrogative to the fpga and got back the echo of those two words. I will go through some additional functionality next, first loading the SAR shadow register and then doing a cycle steal fetch and a store. I had to change the instrumentation in order to diagnose these next steps. It was getting late so the remaining testing time was limited.
The second word returned on each transaction should be either an echo of what I sent for an imperative type ("do this") command, or a value for an interrogative type ("give me this") command. The Status Command is interrogative but I received the same value I sent for word two. The Set SAR imperative command should echo what I sent but it returned all zeroes. Further, I didn't see my diagnostic lights indicating the value I sent for word two.
I have a link operating and the basic transaction completing, but the higher level functions including determining what to write back at transaction end are not yet debugged. Basically just slow careful slogging through the logic, doing tests and reconfiguring until it is all vetted (and fixed where defective).
Building up the layers involved various FSMs that will produce an output word that is transmitted back to the PC at the end of a transaction. I was most concerned with the FSM to send back status words, as that should be easiest to test. After that, I would work on the machines that load the SAR and SDR shadow registers. Finally, a test of cycle steal fetch and store would be a solid stopping point. For each test, I worked out some diagnostic signals to emit on the temporary lights.
The first test was to watch the link while the Python program sends a status request to the box and the box returns the correct status. I will be able to tell if the innermost link FSM completes or sticks in one state, same with the transactional FSM. I also watched to see what command was latched and the word sent back from the viewpoint of the fpga.
The link was not working and I wasn't sure which side of the link was at fault. After some detailed testng I found a couple of flaws in the fpga logic and successfully get through the innermost FSM, latching in the command and data words. The higher level transaction FSM recognizes the send status command, fired off that state machine, received the completion trigger and wrote both words back.
The problem I am now having is a timeout on the PC side trying to read the second word. It will take a bit of investigation to determine whether I failed to send the second word or whether the code on the PC side is in error. The general functioning of the link and transaction machines seem good.
I did have a problem with the pyusb code on the PC side, which is now fixed. At this point, I sent a Status Request interrogative to the fpga and got back the echo of those two words. I will go through some additional functionality next, first loading the SAR shadow register and then doing a cycle steal fetch and a store. I had to change the instrumentation in order to diagnose these next steps. It was getting late so the remaining testing time was limited.
The second word returned on each transaction should be either an echo of what I sent for an imperative type ("do this") command, or a value for an interrogative type ("give me this") command. The Status Command is interrogative but I received the same value I sent for word two. The Set SAR imperative command should echo what I sent but it returned all zeroes. Further, I didn't see my diagnostic lights indicating the value I sent for word two.
I have a link operating and the basic transaction completing, but the higher level functions including determining what to write back at transaction end are not yet debugged. Basically just slow careful slogging through the logic, doing tests and reconfiguring until it is all vetted (and fixed where defective).
No comments:
Post a Comment