1 |
20 |
jt_eaton |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
2 |
|
|
<html>
|
3 |
|
|
<head>
|
4 |
|
|
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
|
5 |
27 |
jt_eaton |
<title>Design Database Management</title>
|
6 |
20 |
jt_eaton |
<meta name="GENERATOR" content="OpenOffice.org 3.0 (Linux)">
|
7 |
|
|
<meta name="CREATED" content="0;0">
|
8 |
|
|
<meta name="CHANGED" content="20100309;9302100">
|
9 |
|
|
<meta name="KEYWORDS" content="start">
|
10 |
|
|
<meta name="Info 3" content="">
|
11 |
|
|
<meta name="Info 4" content="">
|
12 |
|
|
<meta name="date" content="2008-01-08T12:01:41-0500">
|
13 |
|
|
<meta name="robots" content="index,follow">
|
14 |
|
|
</head>
|
15 |
|
|
<body dir="ltr" lang="en-US">
|
16 |
|
|
<div id="toc__header" dir="ltr">
|
17 |
|
|
<p><br>
|
18 |
|
|
<br>
|
19 |
|
|
</p>
|
20 |
|
|
</div>
|
21 |
49 |
jt_eaton |
<h1><a name="socgen_project"></a><font size="+3">SOCGEN Project</font></h1>
|
22 |
|
|
<h2><br>
|
23 |
|
|
</h2>
|
24 |
|
|
The mission of the SOCGEN project is to provide a blueprint showing
|
25 |
|
|
digital designers how to create a System_on_chip (SOC) by
|
26 |
|
|
assembling components created by a variety of sources. It will
|
27 |
|
|
show how to create a component that can be reused and provides a
|
28 |
|
|
free opensourced tool set that can be used to assemble and verify
|
29 |
|
|
a design. It employs modern design for reuse techniques to reduce the
|
30 |
|
|
waste and ineffiencies that is inherent in handcrafting a design<br>
|
31 |
|
|
<br>
|
32 |
|
|
<br>
|
33 |
|
|
<br>
|
34 |
|
|
<br>
|
35 |
|
|
<br>
|
36 |
|
|
<br>
|
37 |
|
|
<h2><a name="manifesto"></a><font size="+2">Principles for Reusable
|
38 |
|
|
design</font><br>
|
39 |
|
|
</h2>
|
40 |
20 |
jt_eaton |
<p><br>
|
41 |
|
|
</p>
|
42 |
|
|
<br>
|
43 |
49 |
jt_eaton |
<h2><font size="+1">Plan ahead<br>
|
44 |
|
|
</font></h2>
|
45 |
|
|
You may start a design with the intent that it is only going to be used
|
46 |
|
|
for one specific purpose only to find out later that other designers
|
47 |
|
|
want to use it. Create all designs with the intent that they will be
|
48 |
|
|
reused in ways that you haven't imagined and you won't have to scramble
|
49 |
|
|
later. <br>
|
50 |
|
|
<br>
|
51 |
|
|
<h2><font><font size="+1">Design for the lowest common demoninator</font></font></h2>
|
52 |
|
|
Everybody loves to use some quirky little feature of the design target
|
53 |
|
|
to squeeze a little extra preformance out of the system. But if you do
|
54 |
|
|
then you are locked into that target and cannot easily reuse the design
|
55 |
|
|
on a different target. Why do you think they put those features in the
|
56 |
|
|
first place? Instead you should survey the field and only use the
|
57 |
|
|
features that all target technologies can match<br>
|
58 |
|
|
<br>
|
59 |
|
|
<br>
|
60 |
|
|
<h2><font><font><font><font size="+1">Design in a completely generic
|
61 |
|
|
technology<br>
|
62 |
|
|
</font></font></font></font></h2>
|
63 |
|
|
Design is a two step process. First the design is created and verified
|
64 |
|
|
in a completely generic behaverioral RTL format and then converted into
|
65 |
|
|
the target technology. It is tempting to try to save time be designing
|
66 |
|
|
in the target technology but this will make it harder to reuse.<br>
|
67 |
|
|
<br>
|
68 |
|
|
<br>
|
69 |
|
|
<h2><font><font><font><font><font><font><font><font size="+1">Automate
|
70 |
|
|
Everything</font></font></font></font></font></font></font></font><br>
|
71 |
|
|
</h2>
|
72 |
|
|
<p>
|
73 |
|
|
Handcrafting a design file is a time consuming and error prone
|
74 |
|
|
operation. Tasks that are preformed on every design should be done by a
|
75 |
|
|
tool. The designers job is to create the configuration files
|
76 |
|
|
needed by the tools and let automation do all the work.<br>
|
77 |
20 |
jt_eaton |
</p>
|
78 |
|
|
<p><br>
|
79 |
49 |
jt_eaton |
</p>
|
80 |
|
|
<h2><font><font><font><font><font><font><font><font size="+1">Never
|
81 |
|
|
Check Generated Files into a Database</font></font></font></font></font></font></font></font></h2>
|
82 |
|
|
The Revision Control System (RCS) that contains the design should only
|
83 |
|
|
contain the minimul seed data needed to rebuild the entire design. It
|
84 |
|
|
should never contain any files that were generated by the build
|
85 |
|
|
process. <br>
|
86 |
20 |
jt_eaton |
<br>
|
87 |
49 |
jt_eaton |
<h2><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font
|
88 |
|
|
size="+1">Do not keep duplicate copies of a file in the database</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></h2>
|
89 |
|
|
Doing so makes it difficult to ensure that bug fixes and enhancements
|
90 |
|
|
created by one user can be made available to all users. Every file
|
91 |
|
|
should have one and only one location in the database<br>
|
92 |
|
|
<br>
|
93 |
|
|
<h2><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font
|
94 |
|
|
size="+1">Do not build the design inside of an RCS database.</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></h2>
|
95 |
|
|
It is really hard to keep track of all the new files that you have
|
96 |
|
|
added that you need to check into the RCS if they are buried by
|
97 |
|
|
gigabytes of generated files from the build process. Use symbolic links
|
98 |
|
|
to create a work area where generated files are kept outside the
|
99 |
|
|
database.<br>
|
100 |
|
|
<br>
|
101 |
|
|
<p>
|
102 |
20 |
jt_eaton |
</p>
|
103 |
49 |
jt_eaton |
<p></p>
|
104 |
|
|
<h2><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font
|
105 |
|
|
size="+1">Store files based on their source and not their use.</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></h2>
|
106 |
|
|
Are you creating a chip using IP from Joe's IP Emporium? Why not create
|
107 |
|
|
a spot inside your chip database for Joes files? Because that is not
|
108 |
|
|
planning ahead. Later if your lab starts another chip that also uses
|
109 |
|
|
Joes IP then they will also need access to those files. Create a spot
|
110 |
|
|
for files where everybody can simply access them by linking the desired
|
111 |
|
|
files into there database<font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font
|
112 |
|
|
size="+1">.</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>
|
113 |
|
|
<p></p>
|
114 |
|
|
<h2><br>
|
115 |
|
|
</h2>
|
116 |
|
|
<h2><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font
|
117 |
|
|
size="+1">Do not mix unlike objects in the same container.</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></h2>
|
118 |
|
|
<p>"Unlike" is a delibertely nebulious term. It can mean anything and
|
119 |
|
|
everything. If you have a instance of a hard macro that is
|
120 |
|
|
unsynthesizable then do not put it in a file along with synthesisable
|
121 |
|
|
rtl code. If you have code belonging to one designer then do not mix it
|
122 |
|
|
with code belonging to another. If you do then you have to worry about
|
123 |
|
|
file locking. Fragment the design so that each object is in it's own
|
124 |
|
|
container and then use a tool to put them back together.<br>
|
125 |
|
|
</p>
|
126 |
|
|
<br>
|
127 |
|
|
<br>
|
128 |
|
|
<h2><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font><font>Layer
|
129 |
|
|
the
|
130 |
|
|
design.</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></h2>
|
131 |
|
|
<p>A full design will consist of several different databases that are
|
132 |
|
|
layered. Upper ones may override any content from a lower layer<br>
|
133 |
|
|
</p>
|
134 |
20 |
jt_eaton |
<p><br>
|
135 |
|
|
<br>
|
136 |
|
|
</p>
|
137 |
49 |
jt_eaton |
<br>
|
138 |
|
|
<br>
|
139 |
|
|
<br>
|
140 |
|
|
<h2><a name="manifesto"></a>Database Guidelines</h2>
|
141 |
|
|
<p></p>
|
142 |
|
|
<p></p>
|
143 |
|
|
<br>
|
144 |
20 |
jt_eaton |
<p><img style="width: 800px; height: 600px;" alt=""
|
145 |
|
|
src="../png/data_fig1.png"><br>
|
146 |
|
|
<br>
|
147 |
|
|
</p>
|
148 |
|
|
<p><br>
|
149 |
|
|
<br>
|
150 |
|
|
</p>
|
151 |
|
|
<h2>SYSTEM<br>
|
152 |
|
|
</h2>
|
153 |
|
|
<p>A system is at least one PCA containing a targeted
|
154 |
|
|
component interconnected with
|
155 |
|
|
other electronic components and bus functional models. <br>
|
156 |
|
|
</p>
|
157 |
|
|
<p><br>
|
158 |
|
|
</p>
|
159 |
|
|
<h2>TARGET</h2>
|
160 |
|
|
<p>A target is a specific physical design that can implement a
|
161 |
|
|
component. Targets can be asic or fpga and include a Printed circuit
|
162 |
|
|
board(PCB) that may include other electronic components. The goal for
|
163 |
|
|
all components is to assign them to at least one target and prove that
|
164 |
|
|
the work in silicon<br>
|
165 |
|
|
</p>
|
166 |
|
|
<p>
|
167 |
|
|
<br>
|
168 |
|
|
<br>
|
169 |
|
|
</p>
|
170 |
|
|
<h2>PROJECT</h2>
|
171 |
|
|
<p>A project is a collection of components. A database must define at
|
172 |
|
|
least one project to create an area where components may be stored.
|
173 |
|
|
Other projects may be created as needed to group similar components
|
174 |
|
|
together and reducing clutter. If any component in a project uses a
|
175 |
|
|
component from a child project then that child project must also be
|
176 |
|
|
included in the parent project.</p>
|
177 |
|
|
<p><br>
|
178 |
|
|
<br>
|
179 |
|
|
</p>
|
180 |
|
|
<p><br>
|
181 |
|
|
<br>
|
182 |
|
|
</p>
|
183 |
|
|
<h2>COMPONENT</h2>
|
184 |
|
|
<p>A component is a basic building block that may be used to make
|
185 |
|
|
other components.</p>
|
186 |
|
|
<br>
|
187 |
|
|
<p>
|
188 |
|
|
</p>
|
189 |
|
|
<br>
|
190 |
|
|
<h2>LIB</h2>
|
191 |
|
|
<p>A library is a collection of building blocks that may not be
|
192 |
|
|
synthesiable in
|
193 |
|
|
all target technologies and may require customizations. The use of lib
|
194 |
|
|
parts in the rtl code will
|
195 |
|
|
facilitate porting a component into different technologies.</p>
|
196 |
|
|
<p><br>
|
197 |
|
|
</p>
|
198 |
|
|
<h2>TOOLS<br>
|
199 |
|
|
</h2>
|
200 |
|
|
<p>The tools directory contains all of the socgen tools needed to build
|
201 |
|
|
, simulate and synthesise all of the systems and components in the
|
202 |
|
|
database. Scripts and installation instructions are provided for any
|
203 |
|
|
other opensource tools that may be required. There are also
|
204 |
|
|
instructions for any propritory tools that are used.<br>
|
205 |
|
|
</p>
|
206 |
|
|
<br>
|
207 |
|
|
<p><br>
|
208 |
|
|
<br>
|
209 |
|
|
</p>
|
210 |
|
|
<h2>BENCH<br>
|
211 |
|
|
</h2>
|
212 |
|
|
<p>A testbench is used for all simulations and test suites. Any system
|
213 |
|
|
or component may be simulated. Components can only do generic rtl sims
|
214 |
|
|
while systems may do either generic rtl ,specific rtl or gate sims.
|
215 |
|
|
Generic rtl models are included in the socgen library, specific ones
|
216 |
|
|
must be obtained from the IC vendor.<br>
|
217 |
|
|
</p>
|
218 |
|
|
<p><br>
|
219 |
|
|
</p>
|
220 |
|
|
<br>
|
221 |
|
|
<h2>DOC<br>
|
222 |
|
|
</h2>
|
223 |
|
|
The documentation directory.
|
224 |
|
|
<br>
|
225 |
|
|
<br>
|
226 |
|
|
<br>
|
227 |
|
|
<br>
|
228 |
|
|
<br>
|
229 |
|
|
<p><br>
|
230 |
|
|
</p>
|
231 |
|
|
<br>
|
232 |
|
|
<p><br>
|
233 |
|
|
<br>
|
234 |
|
|
</p>
|
235 |
|
|
<p><br>
|
236 |
|
|
<br>
|
237 |
|
|
</p>
|
238 |
|
|
<p><br>
|
239 |
|
|
<br>
|
240 |
|
|
</p>
|
241 |
|
|
<p><br>
|
242 |
|
|
<br>
|
243 |
|
|
</p>
|
244 |
|
|
<p><br>
|
245 |
|
|
<br>
|
246 |
|
|
</p>
|
247 |
|
|
<p><br>
|
248 |
|
|
<br>
|
249 |
|
|
</p>
|
250 |
|
|
<p><br>
|
251 |
|
|
<br>
|
252 |
|
|
</p>
|
253 |
|
|
<p><br>
|
254 |
|
|
<br>
|
255 |
|
|
</p>
|
256 |
|
|
<p><br>
|
257 |
|
|
<br>
|
258 |
|
|
</p>
|
259 |
|
|
<p><br>
|
260 |
|
|
<br>
|
261 |
|
|
</p>
|
262 |
|
|
<p><br>
|
263 |
|
|
<br>
|
264 |
|
|
</p>
|
265 |
|
|
</body>
|
266 |
|
|
</html>
|