OpenArty

Description

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.

As a demonstration project, I'd love to implement an NTP server within the device. This is a long term goal, however, and a lot needs to be accomplished before I can get there. Still, a $130 NTP server isn't a bad price for an NTP server in your lab. ($99 for the Arty, $25 for the GPS receiver IIRC)

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:

The board can now reconfigure itself via the included wbprogram and program.sh scripts. Hence if an appropriate OpenArty distribution is running on the board, wbprogram can be used to write a new configuration to the board, and wbicapetwo can start the new configuration. The neat thing here, from another projects standpoint, is you could load OpenArty onto your board, use wbprogram to load another configuration at a different flash address, then use "wbregs wbstar " and "wbregs fpgacmd 15" to run the new configuration. If this process fails, you can still reboot into OpenArty as desired and thence adjust the flash to something that would work.

20160823 Update:

Well, it's time to try to integrate the WB-DDR3 SDRAM project onto the Arty. Today's efforts pushed towards that end and got ... nowhere. I got timing violations I couldn't understand. So ... I checked in my work. It builds, as checked in, but without the memory. Define SDRAM_ACCESS defines in fasttop.v and fastmaster.v if you'd like to try it, and let me know if you make progress.

20160907 Update:

If you've been following the Wishbone DDR3-SDRAM project, you'll know that I haven't been that successful (yet) with getting the memory up and running. I've built, and then rebuilt the project several times over, each time learning something more--mostly having to deal with timing and figuring out how to connect the pins to the device. The worst part is that I'm going to need to change my clock goal for the whole project. My original system clock goal was set to 200MHz since this would've been a natural rate for memory clock---given that the memory is a DDR1600. The problem is that the FPGA on the Arty is so slow, the data rates cannot be faster than 667MHz--nowhere near the 1600MHz the chip can support. Further, at that speed, the FPGA clock driving the memory is required to be one eigth the speed of the data rate (1/4th the speed of the command clock rate), requiring the memory interface clock to be no faster than about 83MHz. DDR3 memory, though, in the same units, cannot run it's clock rate slower than 303MHz, or a quarter of its clock rate slower than about 76MHz. This them means that either the design must either suffer a difficult clock transfer from 80MHz to 200MHz, or I can lower the design rate to 80MHz and then (optionally) speed it up to 160MHz. Oh, and why 80MHz when it could be anything between 76 and 83? Because I'd like to be able to support a UART at 4MBaud, and that's an even division of 80.

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:

The core is now up and running, using Xilinx's Memory Interface Generator and a pipelined wishbone to AXI bus translator at a core clock rate of 81.25 MHz. Remaining to be tested is the question of whether or not the bus translator can handle the pipelined modes it was made for. The wishbone DMA controller that ships with the ZipCPU should offer a good means to test that capability.

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.