Got to debug a few fun board bringup problems at work recently, and even have been writing a pile of code for the project in VHDL, and Labview FPGA. One involved an HDMI receiver chip that wasn’t putting out stable hsync pulses, there were periodic weird glitches that would cause the downstream logic to get confused about how many lines were in the frame. The solution turned out to be adding an obscure and almost undocumented set of reset commands to its initialization sequence. Send the magic incantation to the chip and voila, clean signal. Took days to find that one. Someone ought to tell Silicon Image that stuff like that should be at the front of the programmers’s ref in big bold type, not buried at the end in obscure language.
The next one was finding a fun off-by-one error in a VHDL CRC calculator. Pipeline delay was causing the calculation to start and end one value too late at its input stream. Had to use Isim to prove that what we were producing was a wrong value, and validate the fix.
It’s fun playing Developer for a while, but I also remember now why I went into program management. Debugging drives me berserk some days. About a week ago it took me nearly an entire day to find a tiny missing line segment in a Labview diagram that would’ve been an instant compiler warning in pretty much any other language… But find it I did, much to my blood pressure’s relief.
After a few more pokes and prods, I did finally get some response from Digilent tech support, but they pointed out to me something I should’ve tried up front. In short, the Flash chip needs to be sent a reset command, and then it acts like a normal ROM just fine. I figured since the chip is reset as part of the powerup sequence anyway that it shouldn’t be necessary, but that was clearly a faulty assumption. One line of code at the front of the app makes it all work well.
Well, anyway, once I had the bootloader working and solved a few more Duh problems with running my app out of the PSRAM, I think I finally found the one issue that puts the bullet in the head of running this project on a Microblaze – memory bandwidth. The PSRAM asynchronous mode gets you a 70ns access time. It can be sped up if you can put the chip into fully synchronous mode, but I believe that’s not currently supported by the Digilent memory multiplexer. With 70ns access, the Microblaze pipeline is effectively perpetually starved by the lack of memory access bandwidth, and simply clearing the 16×32 display with a nice tight C routine takes over a millisecond. Trying to maintain a 60hz framerate with the memory heavy frame buffer manipulations required to scroll the text and shift colors would probably be pretty difficult.
I even looked into the possibility of attaching a faster DRAM to the VHDCI connector and using the onboard memory controller on the Spartan-6, but unfortunately the layout of the Nexys-3 board makes that impossible, the required pins aren’t wired up to that connector. You’d need the next board up the lineup, the Atlys, which includes the DRAM onboard already. So, I think it’s back to Picoblaze and assembly programming.
My most recent habit has been trying to build a cooler/faster RGB scrolling board with a Spartan-6 FPGA using the Nexys-3 development board from Digilent. The board itself is pretty solid and works just fine with the basic VHDL and Verilog tools from Xilinx. This is good for creating the “hardware” inside the FPGA. The trick comes when you want to write some ordinary sequential software, say in C, to make it do something. You can put a tiny CPU into the FPGA like Picoblaze, but the program size will be very limited and you’ll have to write the whole thing in assembly, or you can use the Xilinx embedded development kit to create a more powerful CPU that is capable of running C apps and has a real debugger.
The trick is that there isn’t enough built in memory in the chip to run programs of any significant size. Then you need to use external memory. Now, this shouldn’t be a problem because the board has 16MB of “pseudo-static RAM” plus a couple of 16MB flash chips. You link the program such that the code lives in flash, and uses the RAM as memory space for data, and then you use a small bootloader in the FPGA to jump to the code in flash. Well, this is where it all turns sour. Digilent provides packaged files for the board that are supposed to allow you to use both the flash and the RAM, which share control,data, and address lines, but so far I am only able to access the RAM successfully. Reading from the flash (preprogrammed with some data using Digilent’s own tool) returns complete garbage within the EDK C environment. The prepackaged stuff is supposed to handle the multiplexing between the chips for you, which is not a very straightforward task in this environment.
Mail to Digilent tech support has so far resulted in radio silence, as has requests for help to other users in the Xilinx forums. At this point I’m wondering whether anyone has used a Nexys-3 for anything other than college classes to blink an LED. Sigh.