I opened the disk cartridge to examine the platter surfaces more closely. My original thought was to see if there was any way that it made sense to keep using this cartridge, with suitable cleaning. However, when I looked on the pack, I saw some small divot marks at random points around the surface, where the aluminum substrate would shine through. I don't like the look of those, so this pack is now officially a discard.
 |
| Underside of platter, notice divot and black streak |
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
My initial test of the new error correcting fast SPI link led to it rejecting 100% of all frames - the good news is that it is detecting multi bit errors and tossing them. The cause, however, has to be determined. It isn't likely to be line noise, instead I suspect I am doing something wrong with the detection and correction.
When I looked closer, I could see that the Hamming SEC-DED function that I am using reverses the field bit for bit compared to all the other uses. That is, the bit that represents the data pattern with only the low order digit on, d0 in the rest of my logic, is at the end of the string inside the Hamming package but is at the start of the string in the rest of my logic.
Too, the placement of the additional parity bit that infers the double bit detection capability is after the parity for the cells with an address ending in 1, rather than after the parity for the cells whose address has addresses with the 64 bit position on.
I had to work with the code and definitions to get the strings oriented the same way and to merge the proper parity bits into position. It became harder than I expected, because they didn't intersperse the parity bits in the same way as the usual definition. I will have to look through the logic for the hamming package very, very carefully in order to get everything converted to work properly.
That was way too much trouble, given internal logic that divided up the range of the encoded field without interspersing parity, I had to return to the orientation and sequencing in the Hamming module, then change my frame layout to match.
With those changes made, I tested again and had a solid link reliably carrying the data to and fro, regardless of the bit patterns in the 104 data bit portion. I cobbled up some code to display the checksum on the seven-segment displays, so that I could see it was generating a non-zero and ever changing CRC in the frames. I also froze the random counters when button 0 is pressed.
With that change, I verified that there was a continual change to the CRC checksum and that if I froze the counters, it would still update as I manipulated eight of the data bits (of the 104) using the eight slide switches. This was performing very well. I transfer a frame of 104 bits every 23 microseconds,a frame rate about 45K frames per second. As long as I am dealing with devices that can handle being serviced in the range of 100us, no special engineering is needed.
I did add in all the signals for the connectors on the slave FPGA board, as a convenience, for when I assign and hook up various peripherals to this board. I have 64 connections available on the board. Each additional set of peripheral connections could be handled by adding another slave board. A slave board provides a net of 60 signals, since it takes four signals from the Ztex board to form the additional fast SPI link.
The logic also includes a medium speed SPI link operating at 50KHz, transporting single bytes, thus approaching 5K bytes per second or one byte each 200us. Since any unit hooked to the medium speed link would have multiple bytes to exchange to manage its attached peripherals, it is suitable for objects that need service in the range of milliseconds. There is no error checking or correcting on these links, as their slow speed should not leave them vulnerable to noise or other channel errors. I intend to attach devices such as Arduinos to these medium links.
That was way too much trouble, given internal logic that divided up the range of the encoded field without interspersing parity, I had to return to the orientation and sequencing in the Hamming module, then change my frame layout to match.
With those changes made, I tested again and had a solid link reliably carrying the data to and fro, regardless of the bit patterns in the 104 data bit portion. I cobbled up some code to display the checksum on the seven-segment displays, so that I could see it was generating a non-zero and ever changing CRC in the frames. I also froze the random counters when button 0 is pressed.
With that change, I verified that there was a continual change to the CRC checksum and that if I froze the counters, it would still update as I manipulated eight of the data bits (of the 104) using the eight slide switches. This was performing very well. I transfer a frame of 104 bits every 23 microseconds,a frame rate about 45K frames per second. As long as I am dealing with devices that can handle being serviced in the range of 100us, no special engineering is needed.
I did add in all the signals for the connectors on the slave FPGA board, as a convenience, for when I assign and hook up various peripherals to this board. I have 64 connections available on the board. Each additional set of peripheral connections could be handled by adding another slave board. A slave board provides a net of 60 signals, since it takes four signals from the Ztex board to form the additional fast SPI link.
The logic also includes a medium speed SPI link operating at 50KHz, transporting single bytes, thus approaching 5K bytes per second or one byte each 200us. Since any unit hooked to the medium speed link would have multiple bytes to exchange to manage its attached peripherals, it is suitable for objects that need service in the range of milliseconds. There is no error checking or correcting on these links, as their slow speed should not leave them vulnerable to noise or other channel errors. I intend to attach devices such as Arduinos to these medium links.
No comments:
Post a Comment