Our Goal.

In this project we will focus on using a soft CPU in the FPGA firmware. We want to develop a robust System On Chip (SOC) for our board. The SOC is a set of firmware cores, connected either directly (point-to-point), or using a bus. A robust SOC can be easily modified by inserting new cores into the SOC framework, while keeping the framework intact. The figure shows a conceptual diagram of the on-chip SOC.

We divided the work into parallel development tracks. Initially, we are aiming at developing a particular feature (Ethernet connectivity) in two different ways. It will allow us to compare and evaluate two candidate SOC frameworks developed by Chu and Wirth.

  • The initial goal. In order to warm up the development, we will implement Ethernet connectivity using the Wiznet chips, which provide the TCP/IP stack in silicon. We will focus on the higher performance W5300. The Ethernet-over-SPI chip W5500 will be used, if time permits.

  • General Firmware development track. We will need a few general purpose IP cores throughout the entire project. We grouped the cores into a separate general firmware development to be pursued alongside the other tracks.

  • System On Chip (SOC) development track. We will need to put together a robust set of IP cores, serving the available peripherals. We can choose between two sets of IP cores and two SOC frameworks. The one developed by Niklaus Wirth is named Oberon System SOC. The one developed by Pong P. Chu is named FPro SOC. We will lean towards the latter because of its excellent implementations in both VHDL and SystemVerilog. The FPro framework provides an important advantage: we can choose either the MicroBlaze or the RISC5 processor, while the rest of the SOC stays unmodified. This approach will require modifying the RISC5 interface to make it identical to the MicroBlaze Controller System (MCS) used throughout the Chu's books.

  • MicroBlaze development track. We will adopt the Chu's FPro framework "as is", without much change other than mapping the FPro cores to the appropriate RiskFive peripherals. We will interface the Wiznet chip to FPro, write the Wiznet software driver in C, compile it with Xilinx Software Development Kit (SDK), load to the MCS memory, and test the Ethernet communication with MicroBlaze. All these steps will follow examples provided by Chu.

  • RISC5 development track will be subdivided into two sub-tracks, one dealing with the RISC5 core itself, and the other dealing with the rest of the firmware.

  • RISC5 CPU development track will aim at improving the RISC5 code clarity with SystemVerilog. Development of the MicroBlaze-compatible interface will be a part of this track.

  • Astrobe development track will adopt the Astrobe firmware and software kernel developed by Chris Burrows. (Chris's firmware closely follows the original Wirth's design.) We will reuse the Wiznet interface from the other track, and modify it to fit the Astrobe firmware framework. The Wiznet software driver will be programmed in Oberon-07, compiled with Astrobe, loaded to the RISC5 memory, and used for testing the Ethernet communication with RISC5.

  • Oberon System Software track will be started after completing the previous tracks. We will use the FPGA Oberon System, either the original Oberon System by Niklaus Wirth and Paul Reed, or the Experimental Oberon System by Andreas Pirklbauer. We will reuse the Wiznet software driver developed with Astrobe, because both Astrobe and the Oberon System use the same Oberon-07 language.


    Many IP cores listed below have been completed by the community. In such cases we only need to gather the results, document the status, and post the web pointer on our own website with proper credit. Development of our own IP cores is the last resort, when a good quality IP solution is either not available, or protected by na overly aggressive license.

  • General. Document how to use Vivado and ChipScope with Artix-7. We will need to read or write the BRAM memory content and the FPGA registers to aid debugging, load new software for the soft CPU, and test the newly developed firmware cores in the circuit.
    1. Write a detailed "how to" document and release it on the Design Resources page.

  • General. Develop an embedded video framebuffer. Large portions of Chu's books were devoted to embedded video controllers. Embedded video plus the embedded CPU will be useful for lean, low cost instruments. This development can be pursued with any FPGA kit, not necessarily RiskFive.
    1. Choose one the the Chu's video framebuffers. Learn how to use it. Examine the proof-of-principle use cases.

    2. Write documentation and add it to the web repository.

  • General. Use external ZBT memory for monochrome VGA graphics. Develop the graphics display firmware, using external ZBT memory rather than internal BRAM. This display will still be monochrome. The memory map should stay the same as the internal one.

    At the conclusion of this step, the same display software should display the same monochrome image, whether using the internal BRAM or external ZBT.

  • General. Use external ZBT memory for color VGA graphics. Modify the graphics display firmware from one bit per pixel to eight bits per pixel, using external ZBT memory. Develop a lookup table which maps the 8-bit pixel to 24-bit word driving the VGA video DAC.

  • General. Develop flexible resolution for color VGA graphics. This step is optional, though desirable. Develop flexible resolution video controller, whose X, Y, and refresh will be defined in FPro registers. The display parameters can be then changed on the fly. The standard VGA video should be supported, such as 640x480, 800x 600, and 1024x768.

  • General. Test the new color VGA graphics. At this point it is too early to drive the new color graphics with software. We will rather develop test beds in firmware, driving color patterns on screen to verify the display operation.

  • General. Implement QSPI interface for the flash memory. This step is optional, though highly desirable. The SPI flash can be connected to the FPGA with either the SPI or the QSPI with four times higher throughput.
    1. Select the best quality QSPI core and add it to to our repository.

    2. Gather the documentation and add it to the web repository. The document describe how to set up and use this core with an embedded software driver.

  • General. Implement QSPI interface for the SD card. Repeat the previous step with the SD card. Ideally, both devices will be served with the same IP core. However, the software driver for the SD may be very different from the driver for the flash chip. A separate documentation will be written addressing the differences.

  • RISC5. Improve RISC5 source code formatting. Convert the RISC5 processor source code from Verilog to a subset of System Verilog, following the style and formatting from the latest Chu's book. Do not attempt to modify RISC5 at this step.

    Add comments to RISC5 code, trying to make it better readable. At the conclusion of this step, the RISC5 code should become self-documented to aid further development efforts.

  • RISC5. Perform timing analysis of the RISC5 CPU. The RISC5 processor is reported to work at 37.5 MHz on Pepino's Spartan-6. It can run at 50 MHz when fully embedded (w/o external memory). The CPU speed is allegedly limited by long combinatorial paths within the firmware. Analyze the RISC5 code to asses potential for improving its performance.
    1. Perform timing analysis of the RISC5 code and identify the bottlenecks.

    2. Assess possible improvements and optimizations without introducing pipelining.

    3. Find out whether pipelining can be introduced without modifications of the Oberon compiler.

    4. Implement pipelining, if the Oberon compiler is not affected.

  • RISC5. Develop the RISC5 Controller System (RCS). Develop a self contained RISC5 Controller System (RCS) with the same interface as the Microblaze Controller System (MCS) used in Chu's textbooks. Both controllers will not requre any external RAM interface, and thus both can run on any FPGA board regardless of whether or not the board is offering external RAM.

    Note: A similar solution been completed by the developers of Astrobe for RISC5. It is quite possible that we only need to adopt the Astrobe version of RISC5. Otherwise, we will do the following.
    1. Combine BRAM blocks with RISC5 into a single RCS core similar to MCS.

    2. Create the RCS IP Core with an FPro interface identical to the MCS interface.

    3. Develop and document the ability to write compiled software directly to the RCS memory, using ChipScope.

    4. Write the documentation and add it to the web repository.

  • Oberon FW. Port the Oberon SOC firmware to Artix-7. Identify and assess the most recent version of the Oberon SOC. Port the SOC to RiskFive. This step is preserving as much of the original firmware as possible, without any significant modifications. Apart from remapping the FPGA pins, there are two major developments in this step.
    1. Use the ZBT memory for program and data rather than ASRAM. The ZBT memory controller is available on the Design Resources page.

    2. Adopt the internal monochrome video buffer for the display screen, rather than external RAM. The original ASRAM video controller will be replaced with the internal one developed in the previous step, because the original ASRAM video has to be discarded anyway. We can as well do it now.

    3. Write documentation and add it to the web repository.

  • Oberon FW. Convert the Oberon SOC to Fpro. Replace the original Oberon SOC cores with Chu's cores as much as possible.
    1. Replace Oberon SOC bus and firmware modules with FPro equivalents.

    2. Use the MicroBlaze-like RISC5 processor interface developed in one of the previous steps.

  • Oberon SW. Develop Board Support Tools. Develop and thoroughly document the Board Support Tools for compiling the firmware, loading into flash, compiling the software, and loading onto either the SD card or flash.

  • Oberon SW. Partition the Oberon System software into the inner core and outer core. Note that this step has already been completed for Astrobe. It may be thus sufficient to adopt and build upon the Astrobe solution. Otherwise, complete the following steps.

    Identify the "inner core" of the Oberon System to stay embedded in the RCS internal RAM. This part of the Oberon System can run at the maximum clock speed, while the rest of the Oberon software can execute from a slower external memory.
    1. Identify the candidate inner core Oberon modules.

    2. Determine if the present development tools support building an "inner core software blob" to stay locked in BRAM.

    3. Develop and document how such a blob will be compiled and linked together.

    4. Develop and document how to use ChipScope to efficiently load the blob into RISC5 Controller System.

  • Oberon SW. Port the complete Oberon System software to RiskFive. Identify the most promising version of the Oberon System software, and port it to RiskFive using the previously completed SOC.
    1. Choose one of the Systems for this proof-of-principle: the Original, Experimental, or Reduced Experimental. They are described on the Web Resources page.

    2. Port the software to RiskFive using the previously completed SOC.

    3. Write documentation and add it to the web repository.

  • Oberon SW. Test Oberon software on the board with UART. Use the the Board Support Tools to load the Oberon System to the RiskFive. Test and debug the working system. Use the UART for starting up and debugging.

  • Oberon SW. Test Oberon software on the board with VGA. Use the VGA display with the Oberon System.

  • Oberon SW. Copying files. Develop methods to copy files between the Oberon board and the PC.
    1. Identify the methods to copy the files (there are several such methods).

    2. Test and document copying the files between the Astrobe-based system and the PC.

    3. Test and document copying the files between the Oberon System and the PC.

  • Oberon SW. SD card file system. At present, the Oberon file system cannot utilize the entire SD card. Develop the SD card file system which can utilize the entire SD card.

  • Oberon SW. Flash chip file system. At present, the Oberon file system uses the SD card. An entirely feasible file system can also be used on the NOR flash chip which is using the SPI / QSPI interface. The size of the flash, either 16 MB or 32 MB, is entirely sufficient for many simpler instruments. Develop a file system for the NOR flash chip.

  • Next steps. To be continued.

    Updated Aug/05/2018.
    © 2018 by SkuTek.com.