The in and inout’s of VHDL


On Friday I rocked up to the lab in the early afternoon, having taken the liberty of a good sleep in. Although my part was more or less finished at that point, with everything working fine – finally! – I wanted to add in some extra features, as I noted previously. Also, we needed to get Rob’s part up to speed with it all. While his LCD display is all good and shiny, it wasn’t really until late in the piece that he actually began to work on, say, the real code. 😛

Anyway, we got onto that and it all came together relatively quickly. Rob seemed to have a fair bit of trouble with my design, which I couldn’t quite understand… I felt it was pretty intuitive myself. Ah well. It was compounded to a degree by him refusing to use anything other than raw VHDL source in his own side of the project, whereas I had and was not too concerned with the raw VHDL’s readability as a result. It was easy enough, though, to get packets into his design and decode them… passing them through seems to be another thing; going through one way they’re mostly okay, but the other way he’s corrupting them. Not just the packet on the wire, but the actual contents – and recalculating the CRC with the new, corrupt packet. Thus, one of the two boards flashes like a Christmas tree. Whoops. I presume he’s just miss-wired things somewhere, so probably a trivial fix on Monday when he gets onto it again.

While he was toying with that, I started testing out the SRAM. I really wanted to get buffering going. 🙂 I had been surprised to learn that the board had SRAM; if I’d known that I would have pushed much harder for our original switch design; it really makes networking stuff way easier.

Anyway, long story short I did manage to get a simple test project working – writing the switch states to SRAM and reading them immediately back out onto the LEDs – although oddly I couldn’t get it to work in the real project. Any packet which went into SRAM came back out as garbage. I couldn’t figure it out… I started to think it must be a timing issue; that the simple project had lower latency by virtue of it’s simplicity and was just getting lucky. But I really wasn’t able to make significant progress on Friday… since the project on my side was already done well enough, I didn’t need to stress over it. So I let it go, and went home.

I came back in at about 11am on Saturday. It was a lot easier coming in now that there was less stress; I was now just working on cool, fun stuff, not worrying about some stupid bug. Even if the SRAM wasn’t working.

I started out, still thinking it was a timing issue, by toying with the Xilinx constraints editor, trying to figure out it’s interface and terminology… long story short I spent a few hours on it, reading up about it, but couldn’t see a way to do what I want… the editor’s really just a flimsy sham GUI over the raw UCF, which didn’t really add anything of value. In the end I gave up; it was way easier to adjust the timing by rewriting the VHDL than trying to figure out the UCF that really left a lot to be desired.

So, I manually added wait states, to no avail. Hmm.

It was sometime just after Tony left the lab, at about 3:45pm, that I suddenly realised what was going on… the outgressController (that does all the SRAM work) is buried about four layers deep in the hierarchy… and while I had declared it’s data lines as inout (i.e. tristate) in it’s implementation, I’d mindlessly connected them as vanilla out’s in every other level of the design. D’oh! So I fixed that, and voila, it’s all working!

So now SRAM buffering is working perfectly. Awesome.

I then cleaned up the code a bit before zipping it up and off to Rob & Tony. I was planning on heading down to Mt. Eliza, but since it was still relatively early – 4:30pm or so – I decided to play around a bit. I wanted to add sliding window flow control… I started looking at it, thinking about how best & easiest to integrate it into the existing design. It looked like it was going to be a fair amount of work… so I ended up getting sidetracked somewhat intentionally, by looking at type & subtype declarations, to simplify the design. Prior to this, the 4-digit BCD counter & student numbers were being passed around as separate buses for each digit, which was taking up a fair bit of space on many of the block diagrams. I had tried to declare custom types previously, but hadn’t had any luck; unbeknown to me at the time you can only declare new types inside architectures, processes and packages. Ah. Once I realised that, I created a package, added some types, and in relatively little time had it working! Bingo. I then worked on converting everything to the new types. While I was doing that, I started toying with records. It took me a while to figure out how to get that working properly – including how to write the conversion functions necessary – but with Tony’s help that came together. It then took a while also to convert all the code over to the new record use, but that was straightforward; the problem arose not in compilation but when trying to synthesise the new code with Xilinx’s compiler.

It crashed. It seemingly cannot synthesise records. Tony & I together spent a fair bit of time fiddling with it, but Tony was evidently used to failures in the compiler; he mentioned that he’s a very frequent flyer of their bug-base. Hmm.

So, we tried the Precision compiler. From memory it at least stated that it couldn’t synthesise records, rather than just crashing. Hooray.

We also tried Leonardo Spectrum or whatever it’s called… that was no good either. Brilliant. Three way overpriced VHDL synthesisers that don’t support records. Do the people making these every actual develop them, or are they totally occupied with cracking the whips over the monkeys?

So, we can perhaps try the latest version of Xilinx’s compiler on Rob’s laptop on Monday, but odds are we’ll just have to give up on records. It’s no huge loss, but it wouldn’t have been nice to actually have some semi-advanced syntax support.

It’s odd, because I really like working with VHDL, and yet all the development tools for it are just useless. It’s a very sad state of affairs.

At that point I decided to give it a rest; I was starving and close to the point of no return on my headache, so I headed home.

Leave a Reply