Rob & I spent most of the day in the ADD lab, working on ADD and, in his case, the ENP presentation for tomorrow morning. It took me a little while to get the code to compile; HDL Designer had gone and randomly renamed dozens of signals, as it tends to do, which I then had to work around. Once it got compiling, I was able to start simulation. And then it was just a matter of banging out the bugs. The first one was, sadly, that absolutely nothing interesting was happening. After delving deep into the schematic I discovered that there were multiple drivers for several signals. Yep, HDL Designer strikes again. Not only can it not connect signals with different names, but it can’t not connect different signals that happen to have the same name. So the transmitter and receiver were both sharing the same data buffer. Duh.
I should say in it’s defense that some of these issues are limitations in VHDL, in so far as it comes to abstracting VHDL in block diagrams. But still; to not issue an appropriate warning in this case was just stupid.
After fixing that, things started to get moving, slowly. I realised that my transmitter was not in fact working… it was rotating the data 16 bits too far; it was still rotating the data while the CRC was being calculated, even though in those last 16 cycles the data wasn’t used. Whoops. So that was easy enough to fix.
Then there were some race conditions that I’d suspected were there, but hadn’t yet showed up; the valid signal for the CRC was sometimes lagging behind the busy signal, so the controller would see the receiver was no longer busy, check it’s data, and find it invalid. D’oh. That only occurred at certain transmission rates, oddly enough; 2045 was one such. It didn’t actually break the system; I’ve designed it so it progressively increases the transmission rate while there are no errors, and reduces it while there are. So it just backed off a bit.
Anyway. There were a few other issues as well; for certain data the CRC wasn’t being calculated correctly. Again, basically a race condition; the algorithm was terminating prematurely.
And then suddenly, after fixing these few bugs, it worked. Just worked. Voilá.
‘course, that’s just in simulation. I then fought for a while with the Xilinx compiler to get it onto the board. The compiler had no issues directly; it’s little “PACE” pin assignment program did… I think I’ve worked around it, but I’m still not sure.
Anyway, once on the board, it did a whole lot of nothing. The seven-segment displays show something, but it’s all mangled; it looks like the digits are being overwritten. There’s also the problem that the local counter appears to be fixed at zero. Hmm. And there’s really no transmission happening… twice after resets or programming the board it looks like at least one packet got through, but that’s it.
I have no idea what it’s problem is. I guess it’s something to look forward to tomorrow. Hooray.
