Sunday, September 4, 2016

Debugging Diablo disk driver logic using Xilinx simulator, building out core functionality

XEROX ALTO - DIABLO DISK TOOL CREATION

I worked on the testbench this morning, building up the processes to model the index and sector marker pulses during rotation. I hard coded a preamble, header field, checksum and postamble to let me watch how the read field, deserializer, synchronizer and RAM write would work. This will let me debug much of the code I already have written and establish a sound foundation for building up the rest of the tool.

I cleaned up a couple of issues right away with the testbench, before I even had a full field composed and ready to read. I set up the getfield logic to be triggered by a virtual button push, which I can trigger from the simulator testbench, to watch how the logic performs in its job of syncing, deserializing and for forth.

I began with watching it attempt to serialize, although I was emitting nothing but 0 bits which will keep it from finding sync. The great thing about the simulator is that I can drill down and display any signals at all, no matter at what level or in what module.

Next up, I worked through my mechanism detecting the sync word but I had some issues with how my bit timer process is working - this routine watches the Read Clock and Read Data signals to capture the 0 and 1 bits, feeding them to my deserializer.

I worked on that during the early afternoon, tweaking the logic until it worked correctly. Once it is feeding correct words out of the serial stream from the 'disk drive', I can check the logic to wait for preambles, read a target number of words, and then read the checksum word.

During my vacation in San Diego, from tomorrow until Thursday, I can sit in my poolside cabana at the Del Coronado, enjoy the weather, breezes, poolside activity, drinks, while building logic and simulating it until it works properly. I hope to make substantial progress by the end of the week.

Sync and deserialize reliably delivers words; time to move on to debug the read field FSM fully including checksum calculation and comparison. Unfortunately, I have hit a brick wall, thanks to the Xilinx toolchain. I synthesize the design itself, everything is good.

I do a check on the simulation, all is good. But when I try to run the simulator, it aborts instantly and with nary a message to suggest a cause. I have tried restarting and even rebooting the PC. Until I can bypass this, I can't test a thing. Grrrrr.

Here is how it starting working again: I added one space at the end of a line, then backspaced, then saved the file. In other words, it was EXACTLY the same as before. When I clicked to start the simulator, everything is back in operation. What a rickety product. Imagine if I paid over $10,000 for a license!

By dinner time, I was working on the RAM putaway of the word that came in from the disk head, tuning up the RAM control FSM. I haven't peered into the RAM simulation itself to verify the writing, but the control FSM and upper FSMs are behaving properly.

I set up a preamble delay of 2 microseconds and a memory location to put a two word field (modeling the first record, the header field). The FSM waited, streamed through the remaining preamble of zeroes until it found a sync bit. It then deserialized and extracted the two words, computing the checksum as it did this, passing each to the memory FSM to put it away.

Addresses bumped, the word count decremented, and after the second word was read, the state machine read the checksum word (word 3), tested it and triggered an error because I hadn't set up a correct checksum in the testbench file yet. As soon as it finished with the checksum word, it dropped out of synchronization and we stopped extracting and deserializing bits.

In other words, at this level it worked perfectly. I have to peer inside the memory to confirm that it will write the buffer as I expect, with proper timing for all those signals, but it looks very good right now. I will figure out the right checksum and place it in the testbench so I can confirm that it will recognize a proper match.

I am running out of time tonight, having just about enough left to finish the deep checkout of memory and a good checksum match. Next up once it is working, I have to build a higher level FSM to read a sector - this will call the read field FSM three times with the proper preamble, location and word counts, after matching the desired sector to the sector counter running in the fpga.

Addressing worked right, when the checksum on disk matches the computed value from the data words, the FSM emits the right signal. However, my memory FSM is not doing the right things yet with the RAM chip signals. That will be the first problem I tackle tomorrow.

No comments:

Post a Comment