Created: Jul 20, 2014
Updated: Sep 11, 2014
SVN Updated: Aug 17, 2014
Other project properties
Development status: Planning
WishBone Compliant: No
This work is managed via git:
and synchronized to this SVN repository.
DUE TO A OPENCORES SVN SERVER BUG, THE SYNCHRONIZATION FAILS FOR REVISION 11 (AND EVERYTHING LATER).
THIS MEANS, THAT THE CURRENT SVN REPOSITORY IS NOT UP TO DATE.
PLEASE USE https://github.com/feddischson/soc_maker UNTIL THIS ISSUE IS FIXED AND TRACK THE ISSUE HERE: http://opencores.org/forum,Other,0,5524
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!!
This application is developed and tested under Linux, but there are no OS dependencies.
Therefore, it is intended and it should be possible to use it on a windows host, but this needs to be tested first.
- All configuration files are YAML based see
- Hierarchical systems can be designed
- Usage of an IP core library
- A CLI for an easy interaction
- Ruby interface to interact with the soc_maker on a lower level
- VHDL output
- instance parameterization (vhdl-generics/verilog-parameters)
- global/static parameterization (vhdl-packages/verilog-includes)
- 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
- User-Guide (with YAML API documentation)
- API version check
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
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 )
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
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 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 stands for Intellectual Property and the definition can be found on wikipedia: http://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core
Parameterization of IP-cores says, that the user can configure and setup all required parameters of an IP-core.
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.
- 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
- 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
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
Christian Haettich , feddischson [ at ] opencores.org
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/.