Son of '9572 is alive
A good night’s rest didn’t help the ‘9572. It remains destroyed. After talking it over with a few people, I believe any of the following is possible:
- It was close to death already from having powered it from 5 volts for so long, and it simply gave out.
- I was careless with a logic probe pin and briefly touched two opposing outputs.
- While juggling pins on the UCF, I uploaded a new program that caused Possibility #2 to happen. I don’t think this was the case, because I think I would have noticed it when I rearranged the pins.
- Or the chip just died, maybe from ESD, maybe from cosmic rays. It does happen.
No matter what the cause, I don’t think it was the VHDL, and I don’t think it was a currently-held misunderstanding on my part. So I’m back in the saddle with one of the Dorkbot PCBs.
As you can see, the latch clock is tied to the 1MHz Q clock. I managed to flick the latch button for less than a millionth of a second during the clock’s rising edge (it doesn’t look right on this graph, but I think this is sample error or else a difference in opinion between the Saleae and the ‘9572 about when the level fell again). The high value is latched into D0 on the next rising edge, then it’s shifted to D1 as D0 obtains the new low value, then it goes from D1 to D2, etc. Then about 21 clocks after that, we see it shift through A15. If I had more probe pins, we would have been able to see it go all the way from D0-D7, then A0-A15.
There is a bug in this code. The shift into D0 doesn’t happen until the rising edge after the one that should have latched it in. I will investigate. (Update: that was easy. I changed the REGISTER_TEMP vector from a signal to a variable so that it was evaluated in the order of the statements in the process block. There’s probably a better way.)