So, this article that I was rambling about last night / this morning... Advanced Synthesis Techniques argues the merits of Sequential versus Parallel in VHDL code by using the example of a UART. Coincidentally, that's exactly the program I was trying to solve... Actually, I spotted my stop bit error by reading this, although I still reimplemented the UART myself rather than copying his because I want mine to be driven by the master 16MHz clock, not the transmit speed clock, but after rewriting my implementation using things I'd learned in this guide it worked... first time!
I came to this via Mike Tresler's pages which are also worth perusing...
Random thought... I'm still using a signal and determining the current state based on the bits counter being 0 rather than the state engine he proposed. I just realised that doing that introduces a lot more gates than having a latch on a single bit to determine state... I obviously still need to readjust my mindset to VHDL some more...
Well, after what seems like an eternity (well, it is 4am and I've been at this for about 3 days), I've finally got the serial port working reliably at all speeds with my emulator. It's a bit annoying that I've spent so much time over a serial port, but I've learned a lot about VHDL in the process and realised that I've still got a lot more learning to do before I'm even half way competent.
I'll post links to some really useful VHDL resource tomorrow when I'm more awake! (I have actually already been to bed once already tonight, but I kept waking up with ideas...)
Anyway, the real point was that if I can't get a serial port working, what hope have I of getting a high-speed SPI connection working (especially without a useful debug system in place!) So, that's conquered now.
So, tomorrow, tomorrow... I need to get something good done before New Year. I can't decide between CRTC emulation or getting the SPI working on the flash chip or a serial based bootloader so I don't need to rely on rebuild the FPGA image completely just to change a few bytes of boot code.
I've pretty much started again from scratch with my FPGA design because I was getting lots of errors about global clocks when I was synthesizing. I started again with just a single 16MHz clock generated by the PLL from the 20MHz input. I then added the T80 soft-core from opencores.
My main problem with this was the Actel synplify tool was aggressively optimising the design and turning the T80_Regs.vhd into an SRAM block, which manifested itself with things appearing to work, but subtleties in the ALU appearing, e.g. "INC HL" would be act like "HL=BC+1". The problem is that the register file is triple-ported on output, which clearly won't work with the SRAM block that got synthesized. More annoyingly, even after removing the vectors and producing a complicated set of case statements to multiplex writing and reading to these registers, it still realised it was effectively a RAM and decided to migrate it to one of the SRAM units. This was annoying as it took about 8 hours for me to figure out what was going wrong and how to coax synplify to not destroying my design. The solution btw looks like this:
attribute syn_ramstyle : string; attribute syn_ramstyle of reg0h, reg0l, ... reg7h, reg7l : signal is "registers";
Obvious, huh?
Anyway, with that out of the way and my serial port (mostly) working, I plucked up the courage to hook in my SRAM module. It didn't work. My experiment with heat-gun soldering the edge connectors didn't work and there was still unmelted solder shorting some of the pins underneath the mound of flux gunk. I removed the chip (my design meant that the edge connector was covered by the SRAM chip) and tidied this up before reattaching the chip with an iron this time. It worked! BTW: the heat gun is awesome for removing things... :)
So far, I've not hooked up the flash ROM yet as I need to built an SPI interface and I want to fix up the serial output because occasionally I get corrupt data (maybe 1 character in 1000), but here's a video showing the SRAM being initialised and then incremented in a pattern:
The ROM data by the way is hard coded. There's a makefile which uses pasmo to assemble to binary and from there I've got a python script to create a big VHDL case statement. I'll be using something similar to bootstrap the RAM with contents from the SPI flash rather than directly accessing the flash as it's needed - I think that will introduce too many wait states and I want the CPU to be able to access the SPI bus anyway so data can be put onto the flash chip by the Z80...
So, I've been playing with the FPGA boards I bought several years ago...
At the start of December, I made good progress in the first couple of days with experiments in sound which you can see in these youtube videos day 1 and day 2 .
Hurr, bloody Google's world dominance. It seems it's now a royal pain in the ass to be able to log into blogger.com if you already use google. Fortunately, I seem to have found a workaround here: http://support.google.com/blogger/bin/answer.py?hl=en&answer=41448
So, now I can get back to describing my FPGA project instead... :)
