RAM problems due to Xilinx handling of tristates (again)

Wednesdays are when I meet with the 1401 Restoration team at CHM. We had problems with one tape drive, which a team member traced back to a bad SMS card; swapped the card and tape drive now working just fine. Overall, the systems are in fairly good shape - exceptional shape given their age.

XEROX ALTO - DIABLO DISK TOOL CREATION

I know that RAM itself works because I can write data via the Adept utility and retrieve it successfully the same way, but my logic to write each extracted word from the disk into RAM is failing.

As I set up instrumentation, I think I discovered the source of the problem. It is the incompetent handling of tristate signals by the Xilinx toolchain. There are quite a few places where the Digilent provided code treats output signals as tristates - emits Z unless the module is active. I also followed that practice.

HOWEVER, the signals as defined in the top level module are type OUT, not INOUT, which means they are not tristate pins. I suspect that nothing good comes from having two separate sources that are treating the signal as a tristate - only emitting values when active - but the actual signal is not tristate hardware.

After I changed everything to INOUT, the Adept function to read and write to disk no longer worked. Grrrrrrrr. All because I leveraged some reference code which insisted on this stupid tristate behavior and won't play nice if integrated.

It is time to write my own logic to replace at least some of the Digilent reference code. I will be successful when I can read or write RAM. Before I coded it all from scratch, I realized that I could take all the control signal assignments out of the Digilent provided code section, where they used tristate Z as the default, and reimplement them in my memory access FSM.

Any time my memory FSM was in the idle state, it would connect the signals the same way as in the Digilent code, yet not use Z for inactive. In other words, these assignments in the idle state were replaced in toto by my assignments in all the other memory FSM states.

My first stab at this didn't work correctly - reading and writing via the Adept utility is funky, which is the only way I can verify things right now. Don't know if my routine is writing correctly but can't retrieve it or if everything hosed up. Still trying to avoid writing a lot of logic from scratch.

I came up with an improved scheme and will implement it tomorrow.

Problem with driver board seems to be with RAM write and read

More woodwork today with Diablo tool work in the afternoon in between tasks. Once the last pieces are painted, I can nail them down and this facade is ready to be assembled on site this weekend.

Roof behind columns

Sign to install near roofline

XEROX ALTO - DIABLO DISK TOOL CREATION

I discovered that slide switch 6 is not working on the Digilent board I am using - just a random defect of some sort. Everything else appears to work, most likely this is a failure in the switch itself.

I am directly watching the pattern generator output and the bits being emitted don't match what should be delivered. I was not sure if the pattern itself is malfunctioning or that the problem is in the way the driver logic is recognizing sync words and other data.

I programmed the analyzer to give me symbolic names for the state machines I am tracking - much easier to interpret than the binary digits emitted from the board. It will help me see if the logic is going awry somewhere.

I am seeing the state machine correctly collect the words as it should see them based on the pattern generator, therefore I have to turn my attention to whether I am writing properly to the on board RAM. I looked over examples of how this is addressed by Digilent reference code and adjusted my logic accordingly.

Logic simulator results look correct, so time to run this transactionally from the PC. The advantage of the built in test pattern generator is that I can trigger a read sector, it should write the results to memory, and then I can read out the words using the Adept utility. I should quickly see whether I wrote the proper data or not

The results were disappointing. The logic analyzer showed me triggering the writes with the proper extracted word, but when I read the RAM back afterwards nothing had been written there. I ran out of time tonight, but the resolution to this will require me to significantly reinstrument the signals going out to the logic analyzer, so that I can watch the RAM signals myself.

The big open question is whether the signal quality from the real Diablo drive through my level shifters will give me a good clean read of the sector. I need to hook up to the drive at our next session on Friday.

Testing with built in pattern generator and logic analyzer

Once again my time is divided, in this case I am helping build a Bavarian building facade with my wife, to be used for guest photos at a Oktoberfest themed fundraiser for the organization where she is involved.

Fortunately for my electronic hobbies, the building involves cutting batches of wood which must be painted by my wife and dry out before I can install them and repeat the cycle. This gives me an hour or two of free time in each go-around.

XEROX ALTO - DIABLO DISK TOOL CREATION

I put in some final instrumentation for use with the logic analyzer, then continued the wiring of all the signals into the unit. After the analyzer was wired, I had to jumper the outputs of the pattern generator to some of the input lines.

Once the physical wiring was done, I began to set up the logic analyzer to properly group and report the signals it is watching. This will take a bit of time but makes debugging much easier when looking through traces.

With the analyzer configured and everything wired, I began to capture some traces to see what was happening. My first problem was that the logic analyzer complained about slow or missing clocks, which is probably an issue with the connection I used to get the 50ns clock out of the board. I will try to use a different route that might have better signal characteristics.

Debugging fpga with built in pattern generator

Now I am reading the clock and seeing data, but it doesn't line up with what I expect. I will do more runs with various trigger and search patterns until I get an idea what is happening. Next were some runs where I triggered on the first 1 bit coming in on Read Data and contrasted that with what was being clocked in by my logic.

I had to smarten up the trigger criteria - Sector Mark followed by read sector FSM going to setup to read field 1, then look for '1' data bits. I found this occurred about 9 word times into the sector, which is far too early.

Back to the simulator to look over my test generator code, then more logic analyzer work until the test generator itself is doing the right thing. I can't debug the behavior of my disk driver logic if the input it sees is scrambled.

Built in test generator to produce signals 'as if' real disk were being read

XEROX ALTO - DIABLO DISK TOOL CREATION

Having created a generator for test input, to loop back into my board instead of needing a real Diablo drive spinning, I have to sort out how to produce the essential bit stream of data as it would come in off the disk surface.

I figured out a technique that should allow me to produce a two dimensional array (an array of bit strings essentially), one array element per word in the sector and each entry is the 16 bits that will serially be produced for the word. That requires 327 16 bit words initialized in the testgenerator module.

The trick will be to adjust the timing to emit this just when the ReadData pulse should occur, but I can do that in the process which is currently producing the ReadClock pulses. For simplicity, I will emit the same sector pattern for every sector, for this incarnation of the test generator.

Luckily there is a single cycle state in the clock generator FSM which I can watch for, which resets the indices for word and bit so that I can cycle through them at the ReadData bit emission time. When the bit in question is 1, I emit a pulse, otherwise no pulse is produced.

I spent quite a bit of time creating realistic data patterns and ensuring the checksums would match. A very manual process, although I did set up an Excel spreadsheet to process the checksum calculations.

Getting the test generator to emit the right sequence of pulses to match my intended disk sector contents took more time than I expected, tripping over subtleties in two dimensional indexing in VHDL, something I do only rarely. Finally it was producing the bitstream I think we would see from the read head, at the times it should appear.

I used the Xilinx simulator to check the output and timing of everything, but the proof is the actual pulses being created.To finish testing this out, I will hook up the FPGA to my logic analyzer, then capture and record the patterns produced.

When the generated signals are right, I can jumper them to the appropriate 'inputs' of the tool and monitor the outputs and the diagnostic pins. I was still wiring the analyzer when the day ran out but I did have good looking results from the simulator.

As a side note, much of the logic I am working out here to produce the test signals will also be used for the emulator role. Therefore I am making progress on the rest of the tool while I work on the debugging of the driver role.

Developing better testing and debugging functions

XEROX ALTO - DIABLO DISK TOOL CREATION

To make debugging easier, I embarked on two directions at the same time. One was to build in a test pattern generator, using spare I/O pins and some of the sizeable unused gates on the fpga. The other was to route key internal state out through 32 external I/O pins on the PMOD connectors of the board, in addition to whatever I can display via the eight LEDs and four 7-segment displays.

My test pattern generator now emits index and sector marks at the timing of a real disk drive. It produces the read data clock pulses at 600ns separation. Now, I have to work out a way to emit a realistic sector worth of read data pulses spaced directly in between the clock pulses at the appropriate timing.

The PMOD connectors now have the word that is extracted by the deserializer from the string of disk bits, along with the memory strobe pulse that triggers the writing of the value into RAM. I also plan to output the state of the key state machines involved in reading.

Testing of disk tool with real Diablo drive

Today we met to work on the Xerox Alto. Since we believe the one pack we had does not contain a boot sector or software, we need to wait to run with a different cartridge. We expect a diagnostics cartridge to arrive Monday, being shipped to us by the Living Computer Museum. We also have two packs picked up from Xerox PARC.

We don't want to risk booting from a cartridge until we have retrieved its contents and archived it, which puts my disk tool in the critical path. We will test out my tool today, using the one cartridge that we think is already wiped (actually overwritten with a pseudo random sequence), since we are not risking precious contents.

I set up the tool so it won't attempt to write, only seek or read, which is what we need to retrieve the contents. The current state of the process is a bit clunky - using the Adept tool to set the cylinder, head and sector, then asking for seek or read sector operations.

These operations write into the RAM buffer on the card, which we retrieve with a File Upload operation of the utility to produce a file on the PC containing any data we have read.  The file has to be read and transformed to collect the data in a meaningful format.

Ken brought his ethernet emulator, partially built but ready for some live testing to prove out part of the design. His packet was seen by the Alto and it began to try to boot from Ethernet, but he needs to fine tune the tool until its output is completely correctly received by the Alto.

XEROX ALTO - DIABLO DISK TOOL CREATION

I am properly setting the cylinder, and seek operations work exactly as expected. The read sector transaction completed, but when I checked RAM the contents don't match the disk. I manually wrote zeroes to the beginning of RAM, read the sector again, and still had zeroes in memory.

We had the scope on the signal lines and could see the disk data streaming in from the drive. The fpga can see it too, or it would have hung waiting for the sync word. However it may not have extracted the words properly or it may not have stored them correctly.

I am going to have to instrument signals on the 'PMOD' connectors to let us use the logic analyzer on the words that my logic believes are on the disk. I will also use the unused connectors NA16 to NA25 on the extension board as drivers of various inputs, so that I can generate my own test signals from within the fpga.

In addition, I want to complete the recording of checksum errors and other status information so that we can interrogate those after each read operation. That will have to wait until after I finish the built in stimulus generator to let me test without a real Diablo drive on hand.

Some of the logic I develop will be the core of the emulator role as well, where this tool will hook to a computer and pretend to be a Diablo disk drive.

Tool ready for first test with Diablo 31 drive

XEROX ALTO - DIABLO DISK TOOL CREATION

My first task in the morning was to walk through the results in simulation of the read sector and write sector commands to make everything was correct.  Seek to cylinder had a flaw, it was not putting up the cylinder address so that every seek would be to cylinder 0.

With the seek logic updated, I had good operation of seeks and could 'sign off' on that function. Next up was to work on the read sector function. I went back to fundamentals, carefully studying the Diablo manual and Alto documentation to be certain I was handling the read and write precisely as would be done on the Alto.

Some timing recommendations from Diablo are ignored in the Alto implementation. The most significant is the recommendation by Diablo that the write gate for a new sector is not turned on until 25us after the sector and that writing of zeroes at the end of the data record continues through the next sector marker for 25us.

I continued to pore over the situation when doing an update - where we finish reading one record of a sector and switch over to write the subsequent record(s). The precise way this is done is essential to producing a readable sector for future read commands.

My detailed examination of the read sector command showed it to perform apparently perfectly,

• finding the correct sector
• waiting for the right delay
• scanning preambles to find the sync word
• extracting data words
• calculating checksums
• verifying the check word against the calculated sum. 

It did this for all three records in sequence, in a way that should work properly with a real disk. I hope to test tomorrow with the Diablo drive on the Alto, at least to examine the first sector and compare it to what we think is being read.

When I began to examine the write sector command in detail, I quickly found a flaw. It was not writing out the sync bit to start each field. That was corrected, but the next problem is a defect in my design approach for writing a sector.

I switch off the write gate and stop writing zeroes as soon as I am through with the checksum of the data record, but I should continue up until the sector mark, I think, or at least for a reasonable postamble duration.

Since I am not going to do any writing tomorrow, I will put this change on the back burner and work on readying the tool for reading from the disk.

Another task today was to use my Analog Discovery to inject signals into each input wire on the Diablo cable and verify the expected results on the fpga input pin. Too, I would inject signals on the fpga output pins and verify the results were correct on the disk cable. This was essential before hooking up to the fpga.

I was able to confirm all the signals, assignments and quality except for two signals whose outputs seem to be bridged or shorted together somewhere on the board. Once I found that and corrected it, this was ready to hook up.

I also found a problem with the substitution I made of the CD4050 chip, but this is delivering +5V signals not 3.3V signals. I did some rewiring and it now produces +3.3 output on the signals into the fpga.

With a working connection board and presumed good logic in the fpga, it was time to trigger some functions and watch them on the logic analyzer. I tried to use of the Analog Discovery to drive index marker, sector marker, address acknowledge, file ready and ready to seek/read/write signals, which I hoped would work in spite of being generated at 3.3V to an input expecting 5V TTL.

The documentation on the Analog Discovery is paltry, to say the least, so it took some time to figure out how I might produce the bare minimum to drive my tool. I need to emit Index and Sector markers, with steady levels on File Ready and Read to Seek/Read/Write. Too, it would be necessary to emit Read Clock and a button to intermittently emit a Read Data pulse.

At the end of the day, I decided that I didn't have the means to adequately drive it with this tool. It might be possible to loop some signals from the fpga back to the cable, but that is a lot of logic coding to try to do in one night.