All within a mere 2300 logic elements.
\n
\nThere are a few gotchas, however:<\/p>\n
Firstly, Block RAM usage is fairly high, especially if your Boot ROM is large.\u00a0 I currently have a SD-Loader which is a shade under 8kb.\u00a0 I’m hoping I can massage that down to 4kb in time, but we shall see.\u00a0 Removing the Two-way cache would also save a fair bit of BlockRAM.<\/p>\n
Secondly, while I now have support for writing 16-bit halfwords and 8-bit bytes to SDRAM, I haven’t attempted to support these writes to BlockRAM.\u00a0 This means that global variables in the boot code currently need to be 32-bit in size, and 32-bit aligned.\u00a0 (This issue can be avoided by disabling hardware storeb and storeh support (and you save a handful of LEs in the process), but if your firmware does a lot of 8- and 16-bit writes, there will be a major speed penalty.)<\/p>\n
Full source can be found at GitHub<\/a>, and a binary snapshot for the DE1 board (.sof file to be JTAGged to the board, and four images to be placed on an SD card) can be found here<\/a>, for anyone who might be interested.<\/p>\n The boot firmware contains some really ugly hacks to put some global structures in SDRAM – they should be allocated properly, but I certainly don’t want to pull a full malloc() implementation into the project!\u00a0 [Edit: I’ve since replaced said ugly hacks with some linker script magic to put the BSS section into SDRAM.]<\/p>\n My experiments with the “small” variant of the ZPU processor have resulted so far in a reasonably functional and tiny System-on-Chip. Supported so far are: ZPU processor with GCC toolchain support SDRAM controller with cache VGA video output, 640x480x16-bit (Dithered … Continue reading ![\"Slideshow\"](\"http:\/\/retroramblings.net\/wp-content\/uploads\/2013\/05\/Slideshow.jpg\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"