soc_maker

= 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 http://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 (http://opencores.org/project,adv_debug_sys)
• the OR1200 OpenRISC processor (http://opencores.org/or1k/Main_Page)
• the ram_wb from the openrisc project (http://opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2/rtl/verilog/ram_wb)
• the UART16550 module (http://opencores.org/project,uart16550)
• a wishbone bus connection from the min-soc project (http://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: http://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 (C) 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 http://www.gnu.org/licenses/.