OpenArty - Implementing ZipCPU on an Arty platform

The purpose of the OpenArty project is to implement a ZipCPU on an Arty platform, together with open source drivers for all of the Arty peripherals. In my case, that will include drivers for additional PMods that I have purchased for this project. Hence the OpenArty platform will support:

1. EQSPI Flash, to include all of the flash's functionality such as being able to read its ID as well as being able to read and set the one time programmable memory. Further, when complete, a ZipCPU will launch code automatically from the flash on startup.
2. DDR3 SDRAM
3. The Internal Configuration Access Port (ICAPE2), to allow for dynamic (not partial) reconfiguration
4. Ethernet
5. SD Card. The program currently uses the SDSPI controller, although I intend to upgrade to a full SDIO controller with (hopefully) the same identical or nearly identical interface.
6. OLEDrgb display.
7. GPS clock module, and external USB-UART
8. This leaves one open PMOD port which ... I haven't decided what to connect it to.

Current Status

 

I currently have all the hardware on my desk.

The design builds, as of 20160910, at an 81.25MHz clock speed.

• ZipCPU: The ZipCPU should be fully functional at the current clock speed. I'd like to boost it to twice this speed, but that may remain a later project.
• FLASH: The flash controller has now passed all of the tests given it, both simulated and live. It can read and write the flash, and so it can place configurations onto the flash as desired. As built, though, the controller is optimized for a 200MHz clock speed, and a 100MHz bus speed. It's being run at an 81.25MHz clock speed (40.625MHz bus speed), so some performance improvement might yet be achieved.
• SDRAM: I intend to implement the work from DDR3 SDRAM controller on the Arty. For now, the project builds with a Xilinx Memory Interface Generated (MIG) core, and a pipelined wishbone to AXI translator.
• NET: An MDIO controller has been integrated into the device. It has yet to be properly tested. Even with it, though, the network doesn't yet send or receive packets--this just offers the possibility to control the interface.
• SD: The SDSPI controller has been integrated into the device, yet not tested yet. Work remains to turn this from a SPI controlled driver to an SDIO based driver.
• OLEDRGB: The driver is built, and has been integrated into the project, but testing is on hold until a build with the ZipCPU, and more than that the DMA controller from the ZipSystem, is functional.

So ... it's a work in progress.

 

20160813 Update:

at a different flash address,

 

20160823 Update:

 

20160907 Update:

Wishbone DDR3-SDRAM,

This is good news and bad news. The good news is that the ZipCPU should now be able to work without modification at 80MHz. That should help to get this project up and running sooner. The bad news is that the flash, which was running at 100MHz, will now only run at 40MHz. However, if I can bring the clock back up to 160MHz, perhaps via a 2:1 clock transfer, then the flash will be able to support execute in place in Quad I/O mode, reducing the flash access latency from 320ns to 175ns. (It could only support Quad output mode at 100MHz with an 8 clock delay, so it needed SPI mode to get the data address. At 160MHz, it can get the data address in QuadSPI mode.)

Going back to the memory, I decided to try a different tack: I tried configuring the (gasp!) Xilinx Memory Interface Generator. Yeah, I know, what good is an open source project that uses a proprietary interface? At the same time, what good is a DDR3-SDRAM controller that only works on one chip? So I built a wishbone to AXI translator. Unlike the previous wb2axi translator in use by the OpenRISC project, this one is designed from the beginning to be pipelined. It should allow multiple transactions to be in flight at the same time. If it works, it will be able to transfer 128 bits to/from memory every 12.5ns. Why 128-bits? Because that's the natural width of the memory. At a 128 bit transfer width, the AXI controller should not need to break transactions up and reorder them. Certainly building this translator was faster and easier than getting the WB DDR3-SDRAM controller running. Still, although built, I can't declare it to be working yet--having no valid test cases, and not having the memory on the Arty up and running yet. Yeah, I know, just building the memory interface in the "approved" fashion seems to be a problem.

I guess my point is, for anyone following this project, that it is a work in progress. Sure, it doesn't work ... yet, but at this rate I'm at least moving forward.

 

20160911 Update:

pipelined wishbone to AXI bus translator,wishbone DMA controller,ZipCPU,

GitHub

Due to problems with the OpenCores SVN server, specifically the difficulty of moving and deleting files, the most current OpenArty distribution may be found on GitHub.