System-on-Chip Maker (soc_maker)

The System-on-Chip (SoC) Maker is a tool to design and create SoCs in a simple way, written in Ruby.

PLEASE NOTE: THIS SOFTWARE IS IN DEVELOPMENT AND HIGHLY EXPERIMENTAL!!

Current Features

• All configuration files are YAML based (see en.wikipedia.org/wiki/YAML)

• Hierarchical systems can be designed

• Usage of an IP core library

• A CLI for an easy interaction (not completed, needs to be re-designed or removed, interaction is not that easy)

• Ruby interface to interact with the soc_maker on a lower level

• VHDL output

• parameterization of cores

  • instance parameterization (vhdl-generics/verilog-parameters)

  • global/static parameterization (vhdl-packages/verilog-includes)

Install

• from git:

  git clone https://github.com/feddischson/soc_maker.git
  cd soc_maker
  git checkout tags/v0.1.0         # please adapt version if necessary
                                   # see https://github.com/feddischson/soc_maker/releases
  gem build soc_maker.gemspec
  gem install soc_maker-0.1.0.gem  # requires ruby >= 2.0
  

TODOs

• User-Guide

  • YAML API documentation

• API version check

Planed Features

• Graphical User Interface (GUI)

• Import wizzard: should scan IP core sources and suggest configuration

• Verilog output

• Plugin-interface

• Synthesis and Simulation support plugins

• More cores

Status

A first “Hellow World” SOC has been created, simulated, synthesized and tested on a Spartan-3AN starter kit board. The system consists of an OpenRISC CPU, some on-chip memory and a UART core (see ./examples/or1200_test).

Furthermore, some dummy cores have been assembled to a hierarchical system, where a SOC contains a few cores and a sub-SOC.

The following cores are integrated into the SOC-Maker core library and can be used:

• the Advanced Debug System (opencores.org/project,adv_debug_sys)

• the OR1200 OpenRISC processor (opencores.org/or1k/Main_Page)

• the ram_wb from the openrisc project (opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2/rtl/verilog/ram_wb)

• the UART16550 module (opencores.org/project,uart16550)

• a wishbone bus connection from the min-soc project (www.minsoc.com/)

Motivation

The motivation of this project is the need of an open-source application to create system-on-chips easily and fast on a higher level than vhdl or verilog. By creating a generic application, it can support a wide range of processors, cores, controllers and bus-topologies. By using the SoC-Maker, it should be easy for a system-designer to assemble multiple IP-cores together with a low effort and without low-level knowledges. Furthermore, pre-defined SoCs can be published and extended. This makes it interesting for IP-core developers. An existing SoC created with the Soc-Maker can be easily extended by a custom IP core which is then tested and used. Not only memory-mapped systems are a target application, also signal-processing systems are interesting, where signal-processing blocks are concatenated.

One useful example is an Open-RISC based SoC, where it would be nice, if core and system-developers can easily create a SoC with an Open-RISC CPU. The need of a detailed knowledge of the Open-RISC, the Wishbone bus and so on is not needed anymore.

A second example is a any kind of wireless receiver, where signals are filtered, mixed, decimated and further processed. All the signal processing can be put together into a subsystem with parameters (mixer-resolution, decimation-rate and son on). On a higher level, this sub-system can then be used in a typical memory-mapped SoC together with other IP-cores and sub-systems.

The Goal

The goal in one sentence: the SoC-Maker should make it possible to parameterize and assemble one or multiple IP-cores into one IP-core on a high level.

IP-core IP stands for Intellectual Property and the definition can be found on wikipedia: en.wikipedia.org/wiki/Semiconductor_intellectual_property_core

Parameterization Parameterization of IP-cores says, that the user can configure and setup all required parameters of an IP-core.

Assembly Assembly in this context means, that the IP-cores are connected in a pre-defined or user-defined way, that the final IP-core works as required by the user.

One or Multiple IP cores The minimum number of IP-cores, which are used in such a system is one. Of course, the common case is that more than one IP-core is used to create one final IP-core.

Into one IP core The assembly into one IP-core can be seen in different ways: on the one hand, this final IP-core can be seen as a System-on-Chip. On the other-hand, it can be defined as a subsystem with additional parameters. This parameters are then passed to the single IP-cores. The subsystem, which is one big IP-core, can then be used in other systems or sub-systems.

The High Level The high level says, that the user must not work on code or RTL level. Furthermore, the high-level can can be different: one way could be a graphical user interface. A second way might be an easy to read ASCII file written for example in XML, YAML or JSON.

Requirements

• The user is able to organize IP cores and interfaces in a library, which includes

  • adding existing IP cores / interfaces

  • removing IP cores / interfaces

  • displaying IP cores (which are in the library)

  • adding IP cores to the target-SOC

• There should be a library functionallity: the library should hold

  • core definitions

  • interface definitions

• There should exist a core definition for each core. The definition should define the following data

  • all source files, which are required for synthesis only

  • all source files, which are required for simulation only

  • all source files, for synthesis and simulation

  • top-level source file

  • top-level port and parameters

  • parameter configuration and validation

  • an option to download/check out files from a repository (svn, git …)

• There should exist an interface specification for each interface used in the library

  • The interface specification defines, how the IP cores are connected

  • Allow versioning

  • Allow a wide range of topologies

• There should be a SOC definition The SOC definition defines, which IP cores are used by the target-SOC, how they are connected and how the IP cores are parameterized.

• IP-core configuration It must be possible to configure an IP core. The configurable parameters are defined in the IP-core definition and set in the SOC definition. The parameters are then used to instantiate the IP-core during the HDL generation

• Toplevel-Generation The SoC maker should auto-generate a toplevel in VHDL or Verilog. Both HDL languages should be supported for generation.

• Configuration Files All configuration should be stored in YAML files, this includes

  • SOC definition

  • Core definition

  • Interface specification

  • SoC maker configuration

• User-Interaction It should be possible to use the SOC-Maker on three levels:

  • Script-level: this is the lowest level and uses the ruby API directly

  • CLI-level: a commandline-interface can be used to interact with the API

  • GUI-Level: this is the highest level: a graphical user interface should

  make it possible to have a simple interaction with the API

Author

Christian Haettich, feddischson [ at ] opencores.org

License

Copyright © 2014 Christian Haettich - feddischson [ at ] opencores.org

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see <www.gnu.org/licenses/>.