Subversion Repositories soc_maker

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:

\url{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.

 - 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