Saturday, September 3, 2016

Working on the core of the driver role logic

My morning was spent at a nearby fire station as a volunteer examiner for people taking FCC ham radio licensing tests - good turnout so we were busy grading and signing paperwork.


I received the shell for the new connector, which allows me to start wiring up the cable for the drive emulation role board, which will allow the tool to act as a disk drive when attached to a Xerox Alto. I will work on that later, first priority is building up the logic for the driver role.

I am still massaging the 'read field' state machine that will be used three times by the read sector FSM, but also used once or twice by the update sector FSMs. It has to drive the memory interface module that writes and reads from the RAM, plus it must interact with the synchronizer and deserializer when grabbing words from the disk head.

I decided that it makes more sense to refactor this, as there are four situations where I need to process a field. For the driver role, I need to deserialize from the head and write to buffer on a read, but read from the buffer, serialize and clock to the head on a write. Then, for the emulator role, I have to read from the buffer, serialize, generate separate clock and data signals when the host is reading, and when the host writes, I have to separate data from clock, deserialize and write to the buffer.

Each function - serialize, deserialize, memory access and field processing - should exist for all combinations of role and IO direction. Whether they should be combined or discrete is an engineering choice I have to make.

I currently have one memory access FSM which looks at a signal to determine whether it is reading or writing to RAM, but it could be split into pure read and write FSMs. It doesn't seem to be too complex as a combined function.

While I experiment with separated and combined versions, I will begin to build a testbench where I can produce realistic pulses and timings as from a real disk, to see if my logic will correctly detect, deserialize, extract fields and store in the buffer properly. Equally I can test later to see if my generated stream for writing produces signals at the right times.

No comments:

Post a Comment