Since the FPGA is always blank upon power up, the entire functionality of the FPGA based system is defined by its firmware (FW). It is both good and bad. It is good because the same hardware board can be used for many applications, depending on the firmware loaded into the FPGA. On the other hand, development of the FPGA firmware can be a lot of work. In order to ease the FW development, we plan to take advantage of reusable FW cores, also known as intellectual property (IP) cores. Inside the FPGA project, the IP cores are connected with a bus exchanging the data, address, and control signals between the cores. This approach is very similar to how an electrical engineer would design a computer motherboard, where digital chips are interconnected with a bus such as PCI.

We will strive to adopt mature, well documented, and tested IP cores from major textbooks, electrical engineering websites, the FPGA vendor, and other reputable sources. We will also write our own firmware cores, especially when covering application areas such as data acquisition.

Sources of Firmware IP Cores.

Various textbooks on the subject, e.g., an excellent textbooks written by Professor Pong P. Chu.

Other open source cores available on the net, such as the FPGA Oberon repository.

Firmware cores provided by the Xilinx development tools.

Firmware cores described in Xilinx Application Notes.

Firmware cores developed by ourselves.

The IP cores will be serving (or "driving") major hardware features of the FOM: the DDR3 memory, the flash memory chips, gigabit Ethernet PHY, and the HDMI video controller. Other hardware features are present on the motherboard: two more Ethernet chips, the RS-232 transceiver, and the USB-3 interface. For clarity we are not showing these extra IP cores in the diagram.

There are numerous implementations of the bus interconnecting the IP cores. A simple bus named FPro was developed by Professor Pong P. Chu for his textbook on FPGA prototyping with the MicroBlaze soft CPU. Several Fpro cores are available from the book's website. An industrial strength Wishbone is often used in both hobby and industrial projects. The bus developed by Professor Niklaus Wirth for his FPGA Oberon can be valuable for academic projects. Fortunately, all these buses are quite similar to one another.

A rather special case is the DDR3 memory controller whose required performance is quite extreme. A DIY version of the DDR3 controller has been tried without full success. Having this example in mind, we plan to adopt a highly optimized DDR3 core provided by Xilinx Memory Interface Generator (MIG). Interfacing the Xilinx core to a bus like FPro or Wishbone will require a so-called "bridge" translating the core's signals to the ones required by the bus. We plan to adopt the bridge released by Dan Gisselquist on the Open Cores website.

A very important IP core is the soft CPU core shown in the diagram. A processor, whether "hard" or "soft", adds an entirely new dimension to any instrument. We will devote a separate page to the software which RiskFive will be capable of running with the addition of a suitable soft processor core.

RiskFive hardware can accomodate any soft CPU which fits into the board's FPGA. Examples include the MicroBlaze microcontroller provided by Xilinx and used in the Chu's textbook. Another example is RISC5 developed by Professor Niklaus Wirth and available from the FPGA Oberon website. Yet another example is RISC-V developed at Berkeley and adopted in several industrial projects. One should note that despite their similar names RISC5 and RISC-V are very different processors. The former is intentionally very simple in order to aid student's understanding. The latter is a fairly complex design targeting heavy duty industrial projects. A whole variety of soft processors are also available from Open Cores.

The performance of a soft CPU is usually about ten times lower than the performance of a similar CPU implemented in hard silicon. A well designed soft CPU can reach about 100 MHz clock rate. A highly optimized CPU core such as MicroBlaze can run about twice as fast. One can ask why should we care about the soft CPU approach at all, if we have a hard CPU solution on hand, namely the MicroBone shown on our main website SkuTek.com? The answer is "flexibility". A soft processor core can be surrounded with custom peripherals, it can be exchanged for another such core with a different instruction set, or it can be removed altogether and replaced with a fixed microcode executed by a state machine. Such flexibility is not available if one is using hard silicon.
The video controller shown in the diagram will be an interesting, though challenging part of the RiskFive project. A simple video controller developed by Niklaus Wirth for the FPGA Oberon will provide an inspiration, but it cannot be adopted directly because we are using an entirely different kind of memory. (FPGA Oberon used static RAM, while we are using DDR3 RAM with an entirely different interface and timing.) The video controllers developed by Pong P. Chu use the internal FPGA memory, whose capacity is very limited. These controllers can be used in the initial stages of development, but in a long run we need to adopt the main RAM for the video framebuffer.

Both the soft CPU and the video controller will share the same memory bandwidth, estimated as follows. A 32-bit CPU running at 100 MHz and fetching a 32 bit word at every clock cycle will use 400 MB/s, which is 1/4th of the bandwidth available with the DDR3 chip driven at the nominal performance of the Artix-7 memory controller. The remaining bandwidth of 1,200 MB/s can be allocated to video, providing enough margin as far as the numbers are concerned. Bandwidth requirements can be reduced if we employ a color lookup table, where an 8-bit pixel is translated to 24 bits by the video controller. The color lookup (also known as a palette) is often employed in lower end displays. The VGA/LCD core mentioned below can implement this solution out of the box.

One should note that the CPU and the video controller employ very different access patterns. The CPU is fetching words at random, while the video controller is fetching blocks of consequtive words corresponding to the image scan lines. The challenge consists of performing the video access in between CPU access with only minimal impact on the CPU performance. We note that the RISC5 processor is providing a special stall input designed to temporarily suspend the CPU cycles in order to enable video access to the same memory. Quite naturally, the use of this signal needs to be minimized. We can thus see, that the design of this firmware will be quite interesting.

At this point we are considering a combination of the following three cores to assemble a high performance video controller with the framebuffer located in DDR3 RAM. All these are well documented and proven in practice. We are hopeful that these cores can be combined into a stable, high performance video solution. On the other hand, we are aware that achieving the desired result will require quite a bit of work.

There are many other cores of similar nature on Open Cores. We will analyze their documentation and evaluate expected performance before committing substantial effort into implementation. Suggestions from the FPGA developer community will be more than welcome.

Please inquire concerning other specs and details that have not been covered above.
Our contact information is listed on the contact page.