Displaying 1 to 8 from 8 results

autofpga - A utility for Composing FPGA designs from Peripherals


After now having built several FPGA designs, such as the xulalx25soc, s6soc, openarty, zbasic, icozip, and even a Basys-3 design of my own that hasn't been published, I started recognizing that all of these designs have a lot in common. In particular, they all have a set of bus masters, such as the UART-to-wishbone bridge that I use, the hexbus debugging bus that offers a simpler version of the same, or even the zipcpu. Many of these designs have also started to use (and reuse) many of the peripherals I've developed, such as the generic UART, the QSPI flash controller, the SD-card controller, the block RAM controller, the RMII Ethernet Controller, the Real-Time Clock, the Real-Time Date, the Organic LED controller, Xilinx's Internal Configuration Access Port, the wishbone scope, the GPS controlled clock, or even the PWM Audio Controller. All of these peripherals have a very similar format when included within a top level design, all of these require a certain amount of care and feeding as part of that top level design, but yet rebuilding that top level design over and over just to repeat this information becomes a pain. Where things were really starting to get annoying is where the C++ information was depending upon Verilog information. A classic example of this is the base address of any bus components. However, if you add clock rate into the mix, you can then also control things such as any default UART configuration, default clock stepping information (for the RTC clock), or even default video clock information.

openarty - An Open Source configuration of the Arty platform


This version of the OpenArty project is designed to support an 8-bit byte branch of the ZipCPU. Once the ZipCPU is proven here and in some other locations, the 8-bit branch of the ZipCPU will become the master. The design builds, as of 201710, at an 81.25 MHz clock speed, with the ZipCPU 8-bit byte updates. As of this writing, the design builds only. It has yet to be tested on the hardware (again--the trunk works on the hardware).

s6soc - CMod-S6 SoC


This CMOD-S6 SoC grew out of the desire to demonstrate that a useful ZipCPU soft core implementation could be made in a very small space. In particular, one of the purposes of the ZipCPU was to be able to operate successfully in a very area-challenged environment. The CMOD-S6, as sold by Digilent Inc., provides this environment for this project. For those not familiar with the ZipCPU, it is a soft core CPU designed specifically for small area implementations. The CPU is a full 32-bit CPU, designed as a RISC load/store architecture, having a full set of thirty-two 32-bit registers (of which 16 may be used at any one time), and has a single wishbone bus for both instructions and data (Von Neumann architecture). The particular implementation of the ZipCPU used for this SoC project is not pipelined, nor does it have either instruction or data caches--they simply wouldn't fit within the FPGA. Still, a CPU is a CPU and this CPU will execute the instructions given to it faithfully.

sdspi - SD-Card controller, using a SPI interface that is (optionally) shared


This Verilog core exports an SD card controller interface from internal to an FPGA to the rest of the FPGA core, while taking care of the lower level details internal to the interface. Unlike the other OpenCores SD Card controller which offers a full SD interface, this controller focuses on the SPI interface of the SD Card. While this is a slower interface, the SPI interface is necessary to access the card when using a XuLA2 board, or in general any time the full 9--bit, bi--directional interface to the SD card has not been implemented. Further, for those who are die--hard Verilog authors, this core is written in Verilog as opposed to the XESS provided demonstration SD Card controller found on GitHub, which was written in VHDL. For those who are not such die--hard Verilog authors, this controller provides a lower level interface to the card than these other controllers. Whereas the XESS controller will automatically start up the card and interact with it, this controller requires external software to be used when interacting with the card. This makes this SDSPI controller both more versatile, in the face of potential changes to the card interface, but also less turn-key. While this core was written for the purpose of being used with the ZipCPU, as enhanced by the Wishbone DMA controller used by the ZipCPU, nothing in this core prevents it from being used with any other architecture that supports the 32-bit Wishbone interface of this core.




wb2axip - A pipelined wishbone to AXI converter


Since the initial build of the core, I've added the WB to AXI lite bridge. This is also a pipelined bridge, and like the original one it is also formally verified. Since the project began, a full-fledged AXI4 to Wishbone bridge has been added to the project. This converter handles synchronizing the write channels, turning AXI read/write requests into pipeline wishbone requests, maintaining the AXI ID fields, etc. It ignores the AXI xSIZE, xLOCK, xCACHE, xPROT, and xQOS fields. It supports xBURST types of FIXED (2'b00) and INCR (2'b01), but not WRAP (2'b10) or reserved (2'b11). It does not (yet) support bridging between busses of different widths, so both the AXI and the WB bus must have the same width.

wbscope - A wishbone controlled scope for FPGA's


This is a generic/library routine for providing a bus accessed 'scope' or (perhaps more appropriately) a bus accessed logic analyzer for use internal to an FPGA. The general operation is such that this 'scope' can record and report on any 32 bit value transiting through the FPGA that you have connected to the scope. Once started and reset, the scope records a copy of the input data every time the clock ticks with the circuit enabled. That is, it records these values up until the trigger. Once the trigger goes high, the scope will record for bw_holdoff more counts before stopping. Values may then be read from the buffer, oldest to most recent. After reading, the scope may then be reset for another run. The Wishbone scope was featured on zipcpu.com as a conclusion to the discussion of the example debugging bus. That example discussed how to hook up the scope to your logic, as well as how to employ the scope software to create a VCD file that could then be viewed in GTKWave. The scope was also mentioned as a means of capturing traces of button bounces, with the short discussion of how to set it up for that task here.

wbuart32 - A simple UART controller that can easily be wishbone controlled.


Forasmuch as many have taken in hand to set forth a UART core, ... It seemed good to me also, having had perfect (a good) understanding of all things from the very first, to write ... my own UART core. This Verilog core contains two UART modules, one for transmit and one for receive. Each can be configured via one 32-bit word for just about any baud rate, one or two stop bits, five through eight data bits, and odd, even, mark, or space parity. If you are looking for an example Verilog UART module containing all these features, then you have just found it.

zipcpu - A small, light weight, RISC CPU soft core


If you'd like to get started with the ZipCPU, you might wish to know that this repository contains the CPU, its documentation, and the toolchain. The CPU implementation found here, though, is just that: a CPU. This implementation requires a bus with peripherals hanging off of it, things such as RAM, flash (ROM), serial port, etc. This is just where I keep the CPU apart from any necessary peripherals. So, if you want to try out the CPU, feel free to download and build this repository (use git-clone with a depth of 1--there's a lot of stuff in the git repo that you don't necessarily need). You'll need it for the binutils, GCC, and newlib support provided by it.