OpenCores
URL https://opencores.org/ocsvn/soc_maker/soc_maker/trunk

Subversion Repositories soc_maker

[/] [soc_maker/] [trunk/] [README.md] - Blame information for rev 4

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 2 feddischso
soc_maker
2 3 feddischso
===========
3 2 feddischso
 
4 4 feddischso
The System-on-Chip (SoC) Maker is a tool to create SoC
5 3 feddischso
in a simple way.
6
At the moment, only command line interface (CLI) is supported.
7
It is intended, that future implementations will allow to
8 4 feddischso
create and manage SoC with a graphical user interface (GUI).
9 3 feddischso
 
10
This software is in a development stage and highly experimental.
11
 
12 4 feddischso
 
13 3 feddischso
Features
14
--------
15
 
16
* A CLI for easy interaction
17
* All configuration files are YAML based
18
  (see http://en.wikipedia.org/wiki/YAML)
19
 
20
 
21
Examples
22
--------
23
 
24
No real or useful examples have been tested, yet.
25
Only a simple script exists: examples/run.txt
26
 
27 4 feddischso
 
28
 
29
Motivation
30
--------
31
The motivation of this project is the need of an open-source application
32
to create system-on-chips easily and fast on a higher level than vhdl or verilog.
33
By creating a generic application, it can support a wide range of
34
processors, cores, controllers and bus-topologies.
35
By using the SoC-Maker, it should be easy for a system-designer to assemble
36
multiple IP-cores together with a low effort and without low-level knowledges.
37
Furthermore, pre-defined SoCs can be published and extended. This makes it
38
interesting for IP-core developers. An existing SoC created with the
39
Soc-Maker can be easily extended by a custom IP core which is then tested
40
and used.
41
Not only memory-mapped systems are a target application, also signal-processing
42
systems are interesting, where signal-processing blocks are concatenated.
43
 
44
One useful example is an Open-RISC based SoC, where it would be nice, if
45
core and system-developers can easily create a SoC with an
46
Open-RISC CPU. The need of a detailed knowledge of the Open-RISC, the Wishbone
47
bus and so on is not needed anymore.
48
 
49
A second example is a any kind of wireless receiver, where signals are filtered, mixed,
50
decimated and further processed. All the signal processing can be put
51
together into a subsystem with
52
parameters (mixer-resolution, decimation-rate and son on). On a higher level, this
53
sub-system can then be used in a typical memory-mapped SoC together with other
54
IP-cores and sub-systems.
55
 
56
 
57
 
58
 
59
 
60
The Goal
61
------------
62
 
63
The goal in one sentence: the SoC-Maker should make it possible to parameterize and assemble
64
one or multiple IP-cores into one IP-core on a high level.
65
 
66
 
67
IP-core:
68
IP stands for Intellectual Property and the definition can be found on wikipedia:
69
\url{http://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core}.
70
 
71
 
72
Parameterization:
73
Parameterization of IP-cores says, that the user can configure and setup all
74
required parameters of an IP-core.
75
 
76
 
77
Assembly:
78
Assembly in this context means, that the IP-cores are connected in a pre-defined
79
or user-defined way, that the final IP-core works as required by the
80
user.
81
 
82
 
83
One or Multiple IP-cores:
84
The minimum number of IP-cores, which are used in such a system is one. Of course,
85
the common case is that more than one IP-core is used to create one final
86
IP-core.
87
 
88
 
89
Into one IP-core:
90
The assembly into one IP-core can be seen in different ways: on the one hand,
91
this final IP-core can be seen as a System-on-Chip. On the other-hand, it can
92
be defined as a subsystem with additional parameters. This parameters are then
93
passed to the single IP-cores. The subsystem, which is one big IP-core, can then
94
be used in other systems or sub-systems.
95
 
96
 
97
The High Level:
98
The high level says, that the user must not work on code or RTL level.
99
Furthermore, the high-level can can be different: one way could be
100
a graphical user interface. A second way might be an easy to read ASCII file
101
written for example in XML, YAML or JSON.
102
 
103
 
104
 
105
 
106
 
107 3 feddischso
Requirements
108
------------
109
 
110 4 feddischso
 - The user is able to organize IP cores and interfaces in a library, which includes
111
   * adding existing IP cores / interfaces
112
   * removing IP cores / interfaces
113
   * displaying IP cores (which are in the library)
114
   * adding IP cores to the target-SOC
115 3 feddischso
 
116 4 feddischso
 - There should be a library functionallity: the library should hold
117
   * core definitions
118
   * interface definitions
119
 
120 3 feddischso
 
121 4 feddischso
 - There should exist a core definition for each core. The definition should define the following data
122
   * all source files, which are required for synthesis only
123
   * all source files, which are required for simulation only
124
   * all source files, for synthesis and simulation
125
   * top-level source file
126
   * top-level port and parameters
127
   * parameter configuration and validation
128
   * an option to download/check out files from a repository (svn, git ...)
129
 
130
 
131
 - There should exist an interface specification for each interface used in the library
132
   * The interface specification defines, how the IP cores are connected
133
   * Allow versioning
134
   * Allow a wide range of topologies
135
 
136
 - There should be a SOC definition
137
   The SOC definition defines, which IP cores are used
138
   by the target-SOC, how they are connected and how the IP cores
139
   are parameterized.
140
 
141
 - IP-core configuration
142
   It must be possible to configure an IP core. The configurable parameters
143
   are defined in the IP-core definition and set in the SOC definition.
144
   The parameters are then used to instantiate the IP-core during the HDL generation
145
 
146
 - Toplevel-Generation
147
   The SoC maker should auto-generate a toplevel in VHDL or Verilog.
148
   Both HDL languages should be supported for generation.
149
 
150
 - Configuration Files
151
   All configuration should be stored in YAML files, this includes
152
   * SOC definition
153
   * Core definition
154
   * Interface specification
155
   * SoC maker configuration
156
 
157
 
158
 
159
 
160
 
161 3 feddischso
Install
162
-------
163
 
164
sudo gem install
165
 
166
Author
167
------
168
 
169
Original author: Christian Haettich
170
 
171
 
172
License
173
-------
174
 
175
Copyright (C) 2014  Christian Haettich  - feddischson [ at ] opencores.org
176
 
177
This program is free software: you can redistribute it and/or modify
178
it under the terms of the GNU General Public License as published by
179
the Free Software Foundation, either version 3 of the License, or
180
(at your option) any later version.
181
 
182
This program is distributed in the hope that it will be useful,
183
but WITHOUT ANY WARRANTY; without even the implied warranty of
184
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
185
GNU General Public License for more details.
186
 
187
You should have received a copy of the GNU General Public License
188
along with this program.  If not, see .
189
 
190
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.