Project maintainers


Name: s6soc
Created: Mar 22, 2016
Updated: Apr 7, 2018
SVN Updated: Mar 28, 2017
SVN: Browse
Latest version: download (might take a bit to start...)
Statistics: View
Bugs: 0 reported / 0 solved
Star4you like it: star it!

Other project properties

Category:System on Chip
Development status:Stable
Additional info:Design done, FPGA proven, Specification done
WishBone compliant: Yes
WishBone version: B.4
License: GPL


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.


A SoC is really a soft core CPU combined with a bus, giving the CPU access to a variety of peripherals. In this case, the CMOD-S6 SoC offers the user with the following peripherals:

  1. An I/O space containing
    1. an interrupt controller,
    2. the address of the last bus error,
    3. two system timers,

      20160510 Update: The second timer has been swapped for a watchdog timer since 1) that's what I found most useful, and 2) without the autoreload logic it used fewer resources.

    4. an audio controller consisting of a PWM driver and another (supporting) timer,
    5. a GPIO controller capable of implementing SPI and I2C (SPI is working--this drives the display successfully),
    6. UART Rx/Tx,
    7. support for the on-board LED's and buttons, as well as for
    8. an external 16-character keypad controller.
  2. A debug scope, capable of recording 1024-words of debugging information within the core upon any given trigger.
  3. Access to the internal Spartan-6 configuration port, for the purpose of being able to reload the FPGA configuration when/if needed. In particular, this (will) allow an alternate configuration to be loaded, without the CPU, but which may be used to erase or reprogram the flash using the UART port.

    20160510 Update: In the end, I may not need this configuration port. Using Digilent's JTAG controller, I can load whatever configuration I need into the device by force. Hence, all that is necessary to switch configurations is to plug the device in and switch. To make matters worse, when the JTAG controller is plugged in, I can't test the internal configuration port. So it may take a while before I know this port actually works.

  4. A Real-time clock

    20160428 Update: The real-time clock was removed to make room for 32x32 bit multiplies within the ZipCPU. If I get more free space again, I'll bring it back, but it doesn't seem all that likely.

    20160510 Update: The real-time clock has been replaced with software functionality as part of the O/S. As long as scheduling doesn't get so tight that the real-time clock task doesn't run every second, it should be able to set and maintain time.

  5. 16-kB On-chip Block RAM
  6. 16-MB Flash for holding both the CMOD configuration as well as any user programs. (The configuration takes about 512 KB of flash, or 1MB for two configurations.)
20160523 Update: As of today, all of the peripherals mentioned above (with the exception of the hardware RTC which was removed for space, and the configuration port which could not be tested while connected to its umbilical), have been tested and are known to work.

The Demo Task

This board will be proven with the (imaginary) task of implementing a security light. The light works in this fashion: when someone presses the doorbell (pressing one of the on-board buttons), the system will then play a doorbell sound on the audio port, and turn on the outdoor lights for a half an hour. Further, the keypad will allow a user to set the current time, and set times when the outdoor lights should not be turned on (i.e., during the daytime). Finally, the GPIO pins will be used to control a 2-line display that will show either a blank screen (if not being used), the time of the last doorbell press, or a menu driven screen for use with the keypad.

The UART will be used primarily as a debug port, both to output current status (ala debug by printf), as well as to allow access to a second S6 configuration which can be used for programming the flash.

Current Status

20160523: I am going to place this project down in my "done" category of projects. It currently does all that I have asked of it and all that I intended the project to do. Please feel to write if you have comments, thoughts, or questions.

20170126: Resurrected from "DONE" to add the 8-bit byte ZipCPU functionality into the processor

20170309: All of the prior ZipOS functionality now works (again), using the new ZipCPU supporting 8-bit bytes.

Due to errors with the SVN server, the most up-to-date version resides on GitHub.