| 1 |
103 |
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 |
|
|
<TITLE>Design Database Management</TITLE>
|
| 6 |
|
|
<META NAME="GENERATOR" CONTENT="LibreOffice 3.4 (Linux)">
|
| 7 |
|
|
<META NAME="CREATED" CONTENT="0;0">
|
| 8 |
|
|
<META NAME="CHANGEDBY" CONTENT="Ouabache Designworks">
|
| 9 |
|
|
<META NAME="CHANGED" CONTENT="20120130;10245000">
|
| 10 |
|
|
<META NAME="KEYWORDS" CONTENT="start">
|
| 11 |
|
|
<META NAME="Info 3" CONTENT="">
|
| 12 |
|
|
<META NAME="Info 4" CONTENT="">
|
| 13 |
|
|
<META NAME="date" CONTENT="2008-01-08T12:01:41-0500">
|
| 14 |
|
|
<META NAME="robots" CONTENT="index,follow">
|
| 15 |
|
|
<META NAME="CHANGEDBY" CONTENT="Ouabache Designworks">
|
| 16 |
|
|
<META NAME="CHANGEDBY" CONTENT="Ouabache Designworks">
|
| 17 |
|
|
<META NAME="CHANGEDBY" CONTENT="Ouabache Designworks">
|
| 18 |
|
|
<STYLE TYPE="text/css">
|
| 19 |
|
|
<!--
|
| 20 |
|
|
H2.cjk { font-family: "WenQuanYi Micro Hei" }
|
| 21 |
|
|
H2.ctl { font-family: "Lohit Hindi" }
|
| 22 |
|
|
-->
|
| 23 |
|
|
</STYLE>
|
| 24 |
|
|
</HEAD>
|
| 25 |
|
|
<BODY LANG="en-US" DIR="LTR">
|
| 26 |
|
|
<H1><A NAME="socgen_project"></A><FONT SIZE=6>SOCGEN Design
|
| 27 |
|
|
Environment </FONT>
|
| 28 |
|
|
</H1>
|
| 29 |
|
|
<H1> <FONT SIZE=6>Users Guide</FONT></H1>
|
| 30 |
|
|
<H2 CLASS="western"><BR><BR>
|
| 31 |
|
|
</H2>
|
| 32 |
|
|
<P>SOCGEN is a complete EDA design environment that simplifies
|
| 33 |
|
|
the creation of component IP and makes it easy integrate it into a
|
| 34 |
|
|
System-on-Chip (SOC). Its tool set uses IP-xact files to build and
|
| 35 |
|
|
retarget a complete SOC. It is designed to create of complex designs
|
| 36 |
|
|
from components obtained from a variety of different designers.
|
| 37 |
|
|
It is free ,opensourced and available from opencores.org.<BR><BR><BR>
|
| 38 |
|
|
</P>
|
| 39 |
|
|
<H2 CLASS="western"><A NAME="manifesto"></A>Installation</H2>
|
| 40 |
|
|
<P><BR>There are two ways to install and run socgen. The project on
|
| 41 |
|
|
opencores also contains a variety of different example IP modules
|
| 42 |
|
|
from other opencores projects. These have test suites and may be
|
| 43 |
|
|
synthesized into fpgas using the provided scripts.
|
| 44 |
|
|
</P>
|
| 45 |
|
|
<P>The second way is to use only the socgen/tools directory and add
|
| 46 |
|
|
that to your own design environment to furnish the tools.
|
| 47 |
|
|
</P>
|
| 48 |
|
|
<P><BR><BR>
|
| 49 |
|
|
</P>
|
| 50 |
|
|
<H2 CLASS="western"><FONT SIZE=4>Full SOCGEN Tool set with Example IP</FONT></H2>
|
| 51 |
|
|
<P>Start by checking out the complete socgen project from
|
| 52 |
|
|
opencores.org. You will need a login to do this. <BR><BR><BR><BR>
|
| 53 |
|
|
%> svn co -user <UserName> -passwd <Password>
|
| 54 |
|
|
opencores.org/ocsvn/socgen/socgen/trunk socgen<BR><BR><BR>There are
|
| 55 |
|
|
several opensource tools needed by socgen that must be installed in
|
| 56 |
|
|
your host machine. The directory socgen/tools/install contains
|
| 57 |
|
|
install scripts for the various supported operating systems.Once
|
| 58 |
|
|
installed then all socgen scripts are called from a Makefile at the
|
| 59 |
|
|
top level. These scripts will create a workspace area for
|
| 60 |
|
|
generated files , create all of the verilog files as well as
|
| 61 |
|
|
filelists and tool controls, compiles all the software embedded in
|
| 62 |
|
|
the design, runs all test suites with linting and code coverage,
|
| 63 |
|
|
synthesizes all fpgas and reports the results. <BR><BR><BR>
|
| 64 |
|
|
</P>
|
| 65 |
|
|
<P><BR><BR>
|
| 66 |
|
|
</P>
|
| 67 |
|
|
<P><BR><BR>
|
| 68 |
|
|
</P>
|
| 69 |
|
|
<P><BR><BR>
|
| 70 |
|
|
</P>
|
| 71 |
|
|
<P><BR>The commands to do all of this are: <BR><BR><BR>
|
| 72 |
|
|
%>make workspace<BR> %>make build_hw<BR>
|
| 73 |
|
|
%>make build_sw<BR> %>make run_sims<BR>
|
| 74 |
|
|
%>make build fpgas<BR> %>make check_sims<BR>
|
| 75 |
|
|
%>make check_fpgas<BR><BR><BR><BR><BR><BR>
|
| 76 |
|
|
</P>
|
| 77 |
|
|
<H2 CLASS="western"><FONT SIZE=4>SOCGEN Tools only </FONT>
|
| 78 |
|
|
</H2>
|
| 79 |
|
|
<P>Start by creating a subdirectory with the name of your design
|
| 80 |
|
|
environment and then check out the socgen tools from opencores.org
|
| 81 |
|
|
into this directory. <BR><BR><BR><BR> %>
|
| 82 |
|
|
svn co -user <UserName> -passwd <Password>
|
| 83 |
|
|
opencores.org/ocsvn/socgen/socgen/trunk/tools tools<BR><BR><BR>Copy
|
| 84 |
|
|
the Makefile from ./tools/install up to your top level. Create a new
|
| 85 |
|
|
subdirectory name projects.All of your ip repositories will be
|
| 86 |
|
|
checked out into this directory. This IP must be IP-Xact compliant
|
| 87 |
|
|
and it's top level directory name must match the vendor's name and
|
| 88 |
|
|
follow the socgen component database guidelines. All of the socgen
|
| 89 |
|
|
scripts will work on this IP.<BR><BR><BR><BR><BR><BR>
|
| 90 |
|
|
</P>
|
| 91 |
|
|
<P><BR><BR>
|
| 92 |
|
|
</P>
|
| 93 |
|
|
<P><BR><BR>
|
| 94 |
|
|
</P>
|
| 95 |
|
|
<P><BR><BR>
|
| 96 |
|
|
</P>
|
| 97 |
|
|
<P><BR><BR>
|
| 98 |
|
|
</P>
|
| 99 |
|
|
<P><BR><BR>
|
| 100 |
|
|
</P>
|
| 101 |
|
|
<P><BR><BR>
|
| 102 |
|
|
</P>
|
| 103 |
|
|
<H2 CLASS="western"><A NAME="manifesto1"></A><FONT SIZE=5>Using
|
| 104 |
|
|
IP-Xact in a modern design for reuse environment</FONT></H2>
|
| 105 |
|
|
<P>Modern asics have grown to the point where it is no longer
|
| 106 |
|
|
possible for a design team to create a chip from scratch in any
|
| 107 |
|
|
reasonable amout of time. Todays designs rely on reusing major
|
| 108 |
|
|
amounts of code from past designs or 3rd party IP providers. A modern
|
| 109 |
|
|
asic will combine modules created by an inhouse design team with many
|
| 110 |
|
|
others from outside designers to create a code base that can be
|
| 111 |
|
|
synthesized and turned into a IC.<BR><BR>IP-Xact (IEEE-1685) plays a
|
| 112 |
|
|
crucial role in this effort. IP-Xact defines sets of file that
|
| 113 |
|
|
provides a "Data Sheet" for each component module. This
|
| 114 |
|
|
data sheet is not meant for human consumption but rather is designed
|
| 115 |
|
|
to ease the importation of that module into the asics tool flows.
|
| 116 |
|
|
</P>
|
| 117 |
|
|
<P>There are three different jobs in designing a modern asic and
|
| 118 |
|
|
designers need to understand what each one provides.</P>
|
| 119 |
|
|
<H2 CLASS="western"><FONT SIZE=4>Component Designer</FONT></H2>
|
| 120 |
|
|
<P> A component designer creates a module that performs
|
| 121 |
|
|
some usefull task. Along with documentation and IP-Xact files they
|
| 122 |
|
|
will also create a test suite that verifies that the component design
|
| 123 |
|
|
is correct.</P>
|
| 124 |
|
|
<H2 CLASS="western"><FONT SIZE=4>System Architect</FONT></H2>
|
| 125 |
|
|
<P> An architect selects various modules, configures them
|
| 126 |
|
|
and then interconnects them to create a hierarchial module. They also
|
| 127 |
|
|
create documentation, IP-Xact files and a test suite for this module.
|
| 128 |
|
|
This module can then be used by other architects until finally you
|
| 129 |
|
|
have one module the represents a single IC.<BR><BR><BR>
|
| 130 |
|
|
</P>
|
| 131 |
|
|
<H2 CLASS="western"><FONT SIZE=4>Silicon Maker</FONT></H2>
|
| 132 |
|
|
<P> The silicon maker will take that module to synthesize
|
| 133 |
|
|
what they can and instantiatates library modules for the rest. It is
|
| 134 |
|
|
made testable before it is placed and routed. Timing is closed
|
| 135 |
|
|
and the design is made into a silicon die.<BR><BR><BR>IP-Xact is a
|
| 136 |
|
|
key player in passing design configuration and other information
|
| 137 |
|
|
along with the rtl code. Design for reuse is all about
|
| 138 |
|
|
efficiency and that requires a robust and proven EDA tool set capable
|
| 139 |
|
|
of using the IP-Xact standard.</P>
|
| 140 |
|
|
<P><BR><BR><BR>
|
| 141 |
|
|
</P>
|
| 142 |
|
|
<P><BR><BR>
|
| 143 |
|
|
</P>
|
| 144 |
|
|
<P><BR><BR>
|
| 145 |
|
|
</P>
|
| 146 |
|
|
<P><BR><BR><BR>
|
| 147 |
|
|
</P>
|
| 148 |
|
|
<H2 CLASS="western"><A NAME="manifesto11"></A><FONT SIZE=5>adHoc and
|
| 149 |
|
|
bus signals</FONT></H2>
|
| 150 |
|
|
<P>All signals in a design are either adHoc or a member of a bus. An
|
| 151 |
|
|
adHoc signal is any signal connecting two or more instances where the
|
| 152 |
|
|
designers are free to pick their own signal name. You can do an
|
| 153 |
|
|
entire asic using nothing but adHoc signals but in a large design
|
| 154 |
|
|
this leads to chaos and makes the design very hard to understand and
|
| 155 |
|
|
maintain. Busses are used to bring order to this mess. You
|
| 156 |
|
|
create a bus by first defining some characteristic shared by a subset
|
| 157 |
|
|
of the adHoc signals and choosing a name for this group. Then
|
| 158 |
|
|
all adhoc signals that belong in this group will change their signal
|
| 159 |
|
|
names to match the buses signal name. Furthermore if there are any
|
| 160 |
|
|
adhoc signals that are not a member of this group that happen
|
| 161 |
|
|
to have signal names that match must change them to something that
|
| 162 |
|
|
doesn't collide. <BR><BR>For example a design team will decide to
|
| 163 |
|
|
create a bus for all signals that drive the clock port of a flipflop
|
| 164 |
|
|
and that they will uses the name "clk". Then all signals
|
| 165 |
|
|
driving clock ports must change their names to include "clk"
|
| 166 |
|
|
and any non clock port signals using "clk" must find
|
| 167 |
|
|
something else that doesn't collide
|
| 168 |
|
|
</P>
|
| 169 |
|
|
<P>The IP-Xact files for a design will have different sections for
|
| 170 |
|
|
adHoc and buses. This gives the tools more information about bus
|
| 171 |
|
|
signals that can be used to the tools advantage.</P>
|
| 172 |
|
|
<P><BR>Both adHoc and bus signals may be passed up the hierarchy but
|
| 173 |
|
|
can be changed anytime along the way. For example a lcd
|
| 174 |
|
|
controller module creates a 8-bit vga output as adHoc signals.
|
| 175 |
|
|
Rather than port these out as adHoc it will create a busInterface for
|
| 176 |
|
|
a vga bus consisting of eight RGB levels and a horizontal and
|
| 177 |
|
|
vertical sync signal. This bus is then ported up the hierarchy using
|
| 178 |
|
|
a hierConnection at each level until the last level before the pad
|
| 179 |
|
|
ring. At that level a bus interConnection will be used to connect to
|
| 180 |
|
|
the lower level while a busInterface of ten pad signals are created
|
| 181 |
|
|
using the same names as the vga bus. The top level padring will use
|
| 182 |
|
|
interConnections to connect all the pads to the core.</P>
|
| 183 |
|
|
<P>
|
| 184 |
|
|
</P>
|
| 185 |
|
|
<P><BR><BR>
|
| 186 |
|
|
</P>
|
| 187 |
|
|
<P><BR><BR>
|
| 188 |
|
|
</P>
|
| 189 |
|
|
<P><BR><BR>
|
| 190 |
|
|
</P>
|
| 191 |
|
|
<P><BR><BR>
|
| 192 |
|
|
</P>
|
| 193 |
|
|
<P><BR><BR>
|
| 194 |
|
|
</P>
|
| 195 |
|
|
<P><BR><BR>
|
| 196 |
|
|
</P>
|
| 197 |
|
|
<P><BR><BR>
|
| 198 |
|
|
</P>
|
| 199 |
|
|
<P><BR><BR>
|
| 200 |
|
|
</P>
|
| 201 |
|
|
<P><BR><BR>
|
| 202 |
|
|
</P>
|
| 203 |
|
|
<P><BR><BR>
|
| 204 |
|
|
</P>
|
| 205 |
|
|
<H2 CLASS="western"><A NAME="manifesto12"></A><FONT SIZE=5>Design
|
| 206 |
|
|
Repositories</FONT></H2>
|
| 207 |
|
|
<P>"Every piece of knowledge must have a single, unambiguous,
|
| 208 |
|
|
authoritative representation within a system." From The
|
| 209 |
|
|
Pragmatic Programmer</P>
|
| 210 |
|
|
<P><BR><BR>
|
| 211 |
|
|
</P>
|
| 212 |
|
|
<P>A Revision Control System (RCS) is mandatory for all design work.
|
| 213 |
|
|
This provides a location for backup data as well as design history
|
| 214 |
|
|
and the ability to restore the design to any previous version. Design
|
| 215 |
|
|
for reuse has had a profound change on how component IP is stored. A
|
| 216 |
|
|
SOC that was a in-house design could create a single RCS repository
|
| 217 |
|
|
that would store the entire design including all of it's
|
| 218 |
|
|
subcomponents. When component IP is reused you will have multiple
|
| 219 |
|
|
designs all needing the same components. In this case the component
|
| 220 |
|
|
designer must create their own repository for each component with a
|
| 221 |
|
|
test suite and make that repository available to all users. A
|
| 222 |
|
|
modern SOC is comprised of many different components and each one
|
| 223 |
|
|
should maintain a single location to serve as the source for
|
| 224 |
|
|
that component. The design environment for a SOC is a very minimal
|
| 225 |
|
|
database that contains only the scripts needed to locate and check
|
| 226 |
|
|
out all the repositories needed to build the SOC.</P>
|
| 227 |
|
|
<P>When a piece of component IP is obtained from outside the
|
| 228 |
|
|
organisation then then a copy of that IP should be kept in a central
|
| 229 |
|
|
location for use in all SOCs that need it. This avoids have
|
| 230 |
|
|
having multiple copies of a component floating around and protects
|
| 231 |
|
|
against loss if the original source disappears. It also aids in
|
| 232 |
|
|
distributing updates and bug fixes.</P>
|
| 233 |
|
|
<P><BR>SOC design may involve working with an outside asic vendor.
|
| 234 |
|
|
A seperate respository should be used by the vendor to add all of
|
| 235 |
|
|
their libraries and components for synthesis. A seperate repository
|
| 236 |
|
|
prevents the vendor from accessing source code and documentation that
|
| 237 |
|
|
must be controlled.</P>
|
| 238 |
|
|
<P>The choice of RCS software is up to the component designers and
|
| 239 |
|
|
any modern SOC will likely use a mixture of systems. When choosing a
|
| 240 |
|
|
RCS system remember that your component IP code will likely outlive
|
| 241 |
|
|
whatever the RCS-du-jour happens to be and that you will eventually
|
| 242 |
|
|
have to port over to a new system.
|
| 243 |
|
|
</P>
|
| 244 |
|
|
<P>A design repository for a socgen IP component must be IP-Xact
|
| 245 |
|
|
compliant and follow the socgen guidelines for directory structure.
|
| 246 |
|
|
<BR><BR><BR><BR><BR>
|
| 247 |
|
|
</P>
|
| 248 |
|
|
<P><BR><BR>
|
| 249 |
|
|
</P>
|
| 250 |
|
|
<P><BR><BR>
|
| 251 |
|
|
</P>
|
| 252 |
|
|
<P><BR><BR>
|
| 253 |
|
|
</P>
|
| 254 |
|
|
<P><BR><BR>
|
| 255 |
|
|
</P>
|
| 256 |
|
|
<P><BR><BR>
|
| 257 |
|
|
</P>
|
| 258 |
|
|
<P><BR><BR>
|
| 259 |
|
|
</P>
|
| 260 |
|
|
<H2 CLASS="western"><A NAME="manifesto111"></A><FONT SIZE=5>Workspaces</FONT></H2>
|
| 261 |
|
|
<P><BR>The build and verification process will expand size of the
|
| 262 |
|
|
design environment by several orders of magnitude. It is important
|
| 263 |
|
|
that generated files are never stored in a active RCS repository. The
|
| 264 |
|
|
possibility that the presence or time stamp of a defunct generated
|
| 265 |
|
|
file could alter the build is to much of a risk to take. A workspace
|
| 266 |
|
|
is created for the build process that creates a linked file image of
|
| 267 |
|
|
all the pertinent repositories in a separate directory. Source files
|
| 268 |
|
|
are all available and generated files are stored there. A clean build
|
| 269 |
|
|
is guaranteed by deleting the workspace and rebuilding a new one.<BR><BR>It
|
| 270 |
|
|
is really hard to keep track of all the new files that you have added
|
| 271 |
|
|
that you need to check into the Revision Control System if they
|
| 272 |
|
|
are buried by gigabytes of generated files from the build process.
|
| 273 |
|
|
The workspace uses symbolic links to create a area where generated
|
| 274 |
|
|
files are kept outside the RCS repository. Never check a generated
|
| 275 |
|
|
file in an RCS repository. They should only contain the minimal seed
|
| 276 |
|
|
data needed to rebuild the entire design. It should never contain any
|
| 277 |
|
|
files that were generated by the build process. <BR><BR><BR>A similar
|
| 278 |
|
|
workspace is also created for tools.
|
| 279 |
|
|
</P>
|
| 280 |
|
|
<P><BR><BR>
|
| 281 |
|
|
</P>
|
| 282 |
|
|
<P><BR><BR>
|
| 283 |
|
|
</P>
|
| 284 |
|
|
<P><BR><BR>
|
| 285 |
|
|
</P>
|
| 286 |
|
|
<P><BR><BR>
|
| 287 |
|
|
</P>
|
| 288 |
|
|
<P><BR><BR>
|
| 289 |
|
|
</P>
|
| 290 |
|
|
<P><BR><BR>
|
| 291 |
|
|
</P>
|
| 292 |
|
|
<P><BR><BR>
|
| 293 |
|
|
</P>
|
| 294 |
|
|
<P><BR><BR>
|
| 295 |
|
|
</P>
|
| 296 |
|
|
<P><BR><BR>
|
| 297 |
|
|
</P>
|
| 298 |
|
|
<P><BR><BR>
|
| 299 |
|
|
</P>
|
| 300 |
|
|
<P><BR><BR>
|
| 301 |
|
|
</P>
|
| 302 |
|
|
<P><BR><BR>
|
| 303 |
|
|
</P>
|
| 304 |
|
|
<P><BR><BR>
|
| 305 |
|
|
</P>
|
| 306 |
|
|
<P><BR><BR>
|
| 307 |
|
|
</P>
|
| 308 |
|
|
<P><BR><BR>
|
| 309 |
|
|
</P>
|
| 310 |
|
|
<P><BR><BR>
|
| 311 |
|
|
</P>
|
| 312 |
|
|
<H2 CLASS="western"><A NAME="manifesto121"></A><FONT SIZE=5>Projects</FONT></H2>
|
| 313 |
|
|
<P><BR>A project is a database structure that is used to store
|
| 314 |
|
|
component IP. All projects are stored under the projects subdirectory
|
| 315 |
|
|
in a socgen design environment and delivering a component to another
|
| 316 |
|
|
designer simply means creating a package containing the project for
|
| 317 |
|
|
the top level and all sub projects that are part of the design.
|
| 318 |
|
|
Once received the projects are placed in the projects directory and
|
| 319 |
|
|
the component can then be added by any IP-Xact editor by calling form
|
| 320 |
|
|
it by it's vlnv. <BR><BR>The top level directory of a project is the
|
| 321 |
|
|
vendor name from the IP-Xact vlnv. Under that are as many libraries
|
| 322 |
|
|
as needed with the library name used for the directory
|
| 323 |
|
|
name.<BR><BR>Libraries are used to manage the database by grouping
|
| 324 |
|
|
related components together into one library. Each library can have
|
| 325 |
|
|
up to four subdirectories. <BR><BR><BR><BR><BR>
|
| 326 |
|
|
</P>
|
| 327 |
|
|
<H2 CLASS="western"><FONT SIZE=4>DOC</FONT></H2>
|
| 328 |
|
|
<P>./doc/ contains any needed documentation.
|
| 329 |
|
|
</P>
|
| 330 |
|
|
<H2 CLASS="western"><FONT SIZE=4>BIN</FONT></H2>
|
| 331 |
|
|
<P>./bin/ contains any needed scripts or tools needed to build
|
| 332 |
|
|
the IP or compile the software. These tools are called by
|
| 333 |
|
|
componentGenerators in the IP-Xact files</P>
|
| 334 |
|
|
<H2 CLASS="western"><FONT SIZE=4>IP</FONT></H2>
|
| 335 |
|
|
<P>./ip/ contains all the IP components. The directory name
|
| 336 |
|
|
matches the component name from the components vlnv.</P>
|
| 337 |
|
|
<H2 CLASS="western"><FONT SIZE=4>SW</FONT></H2>
|
| 338 |
|
|
<P>./sw/ contains any sw that must be embedded inside the
|
| 339 |
|
|
design. <BR> <BR>
|
| 340 |
|
|
</P>
|
| 341 |
|
|
<P><BR><BR>
|
| 342 |
|
|
</P>
|
| 343 |
|
|
<P><BR><BR>
|
| 344 |
|
|
</P>
|
| 345 |
|
|
<P><BR><BR>
|
| 346 |
|
|
</P>
|
| 347 |
|
|
<P><BR><BR>
|
| 348 |
|
|
</P>
|
| 349 |
|
|
<H2 CLASS="western"><A NAME="manifesto13"></A><FONT SIZE=5>Components</FONT></H2>
|
| 350 |
|
|
<P><BR>A component is used to store the files needed to create the
|
| 351 |
|
|
component rtl code. It also can contain a simulation tool flow with
|
| 352 |
|
|
test benchs and the test suite that demonstrates the components
|
| 353 |
|
|
functionality or a synthesys tool flow to convert the component into
|
| 354 |
|
|
gates.<BR><BR>The example designs included in the socgen project use
|
| 355 |
|
|
verilog only. Tool flows are included that use Icarus verilog for
|
| 356 |
|
|
simulation, Covered for code coverage , Verilator for linting and
|
| 357 |
|
|
Xilinx ISE 13.3 for synthesis.<BR><BR>Notice that socgen components
|
| 358 |
|
|
do NOT include an extra level to store the different versions of a
|
| 359 |
|
|
component. The reason for this is that versioning by its very nature
|
| 360 |
|
|
will create designs where very few lines of code are actually
|
| 361 |
|
|
changed. If you are changing a significant amount of code then you
|
| 362 |
|
|
should not release a new version, you should release a new
|
| 363 |
|
|
component. Placing each version in it's own subdirectory will
|
| 364 |
|
|
result in a significant amount of code that is duplicated between the
|
| 365 |
|
|
different versions. This would break our rule about having a single
|
| 366 |
|
|
place to store each piece of data.<BR><BR>Components can contain /doc
|
| 367 |
|
|
and /bin directories are well as others<BR><BR><BR>
|
| 368 |
|
|
</P>
|
| 369 |
|
|
<H2 CLASS="western"><FONT SIZE=4>IP-XACT</FONT></H2>
|
| 370 |
|
|
<P>./ip-xact/ contains any needed ip-xact designConfiguration
|
| 371 |
|
|
files for this component and all of its versions. These files are
|
| 372 |
|
|
only needed for hierarchal designs that contain other socgen
|
| 373 |
|
|
components.
|
| 374 |
|
|
</P>
|
| 375 |
|
|
<P><BR>It also contains a design.xml file that is a non-ip-xact file.
|
| 376 |
|
|
It is used for "yellow pages" functions and to provide
|
| 377 |
|
|
setup information to the tool flows. This function will take in a
|
| 378 |
|
|
vlnv and return the absolute path to the file containing that ip-xact
|
| 379 |
|
|
object.</P>
|
| 380 |
|
|
<P><BR><BR>
|
| 381 |
|
|
</P>
|
| 382 |
|
|
<P>The design.xml file contains.</P>
|
| 383 |
|
|
<P> (1) List of all designs by their component and
|
| 384 |
|
|
version<BR> (2) List of all testbenchs with
|
| 385 |
|
|
design_under_test and code coverage information<BR> (3)
|
| 386 |
|
|
List of all non-default configurations with name<>value
|
| 387 |
|
|
pairs<BR> (4) List of all simulations with testbench and
|
| 388 |
|
|
config<BR> (5) List of all synthesizable designs with
|
| 389 |
|
|
their component and target</P>
|
| 390 |
|
|
<P><BR><BR>
|
| 391 |
|
|
</P>
|
| 392 |
|
|
<P><BR><BR>
|
| 393 |
|
|
</P>
|
| 394 |
|
|
<P><BR><BR>
|
| 395 |
|
|
</P>
|
| 396 |
|
|
<P><BR><BR>
|
| 397 |
|
|
</P>
|
| 398 |
|
|
<H2 CLASS="western"><FONT SIZE=4>RTL</FONT></H2>
|
| 399 |
|
|
<P>./rtl/verilog contains all the verilog code needed by all
|
| 400 |
|
|
versions of the design. These can be any of three possible types:
|
| 401 |
|
|
<BR><BR> (1) verilogSource
|
| 402 |
|
|
complete verilog module where the module name matches the filename.<BR>
|
| 403 |
|
|
(2) verilogInclude
|
| 404 |
|
|
consists only of `define statements.<BR>
|
| 405 |
|
|
(3) verilogFragment is a `include "filename"
|
| 406 |
|
|
inside of a verilog module.<BR><BR>./rtl/xml contains all the
|
| 407 |
|
|
ip-xact components and designs for all the versions of the component.
|
| 408 |
|
|
Leaf cells will only have a component file while hierarchal cells
|
| 409 |
|
|
will also have a design file. <BR><BR><BR>Most components will have
|
| 410 |
|
|
several versions and it is important to understand how ip-xact uses
|
| 411 |
|
|
versioning. A component can have different versions released over
|
| 412 |
|
|
time. Six months after you release version 1.0 you fix some bugs and
|
| 413 |
|
|
rerelease as verison 1.1. In this case the affected verilog files are
|
| 414 |
|
|
copied to a different name , modified and the file sets in the
|
| 415 |
|
|
ip-xact component files are modified to point to the new files.<BR><BR>You
|
| 416 |
|
|
can also version a component over design space. If you have a cpu
|
| 417 |
|
|
where the user can configure it with or without I-cache and D-Cache
|
| 418 |
|
|
then your component can have four different versions. The best way to
|
| 419 |
|
|
configure these is to use parameters. Then each instance can set it's
|
| 420 |
|
|
own configuration and you only need one ip-xact component file.<BR><BR>But
|
| 421 |
|
|
there are two situations where you cannot use parameters. These are
|
| 422 |
|
|
when the parameter will change a port list or when it will change a
|
| 423 |
|
|
filelist. If either of these occur then you must create a seperate
|
| 424 |
|
|
ip-xact component file with it's own vlnv. This creates a problem
|
| 425 |
|
|
because the vlnv has four places to store five fields. Good
|
| 426 |
|
|
luck.<BR><BR>Some designers try to avoid this issue by creating a
|
| 427 |
|
|
superset design. The design is created with all possible ports and
|
| 428 |
|
|
any unneeded output ports are tied off to safe values and the file
|
| 429 |
|
|
list includes files that may not be used in the design. This is a
|
| 430 |
|
|
design-for-reuse disaster waiting to happen and must NEVER be done.
|
| 431 |
|
|
Have you ever spent several hours assembling something only to end up
|
| 432 |
|
|
with a few parts left over? It could be that the manufacturer had
|
| 433 |
|
|
several products needing simialar part kits and simply created one
|
| 434 |
|
|
superset kit for all of them. Or you could have made a mistake and
|
| 435 |
|
|
the thing will break when you try to use it. How much time will you
|
| 436 |
|
|
spend to figure out which one is correct? This is why we do not do
|
| 437 |
|
|
superset designs. If you make a mistake in your rtl and forget to
|
| 438 |
|
|
instantiate a needed module then that module will show up in a
|
| 439 |
|
|
simulation as a second top level module that you can track down and
|
| 440 |
|
|
fix. If component designers do a superset filelist then your easiest
|
| 441 |
|
|
chance of catching that error will be buried under thousands of
|
| 442 |
|
|
unused files. </P>
|
| 443 |
|
|
<P>IP-Xact component filenames follow the form</P>
|
| 444 |
|
|
<P> component_version_config.xml</P>
|
| 445 |
|
|
<P>where</P>
|
| 446 |
|
|
<P> component
|
| 447 |
|
|
component name from vlnv<BR>
|
| 448 |
|
|
version
|
| 449 |
|
|
version name from vlnv<BR>
|
| 450 |
|
|
config
|
| 451 |
|
|
user assigned configuration name ( _def is for the default
|
| 452 |
|
|
configuration)</P>
|
| 453 |
|
|
<P><BR><BR>
|
| 454 |
|
|
</P>
|
| 455 |
|
|
<P><BR><BR>
|
| 456 |
|
|
</P>
|
| 457 |
|
|
<P>IP-Xact design files follow the form</P>
|
| 458 |
|
|
<P> component_verison_config.design.xml</P>
|
| 459 |
|
|
<P><BR><BR>
|
| 460 |
|
|
</P>
|
| 461 |
|
|
<P>./rtl/fsm A finite state machine generator is a very useful
|
| 462 |
|
|
tool. You use a GUI to enter the states and transitions defining the
|
| 463 |
|
|
state machine and save that datafile in the ./fsm directory. You then
|
| 464 |
|
|
use a componentGenerator in the ip-xact component file to read the
|
| 465 |
|
|
fsm datafile and create a new verilogSource or verilogFragment file.
|
| 466 |
|
|
Socgen supports the fizzim opensourced FSM tool but any others could
|
| 467 |
|
|
be easily added.</P>
|
| 468 |
|
|
<P><BR>A register tool that creates register logic, documentation,
|
| 469 |
|
|
#include files etc is also very useful but we do not have a place for
|
| 470 |
|
|
the register tool source files. That is because ip-xact supports
|
| 471 |
|
|
register descriptions and we use a componentGenerator to read the
|
| 472 |
|
|
ip-xact component file and create the verilog.<BR><BR><BR>./rtl/views
|
| 473 |
|
|
Views are the biggest change that most designers will have to
|
| 474 |
|
|
adjust to when using ip-xact. Many designers create a single
|
| 475 |
|
|
deliverable that is used by all tools. This means that any
|
| 476 |
|
|
unsynthesizable code must use a pragma or a `ifdef to hide itself
|
| 477 |
|
|
from synthesys tools. Ip-xact lets each tool create its own
|
| 478 |
|
|
deliverable that contains exactly what it needs. Nothing more or
|
| 479 |
|
|
nothing less. Each socgen component has a view for
|
| 480 |
|
|
simulation(sim) and a seperate on for synthesys(syn). <BR><BR>When
|
| 481 |
|
|
the socgen build_hw flow has finished then the rtl/views directories
|
| 482 |
|
|
will each contain a ./sim and ./syn subdirectory. Inside these will
|
| 483 |
|
|
be one file for each version of the component and the filename with
|
| 484 |
|
|
match the component_verison name. This file will be a verilog Library
|
| 485 |
|
|
file that contains all the modules needed by that version. This is
|
| 486 |
|
|
created by a socgen tool that reads every ip-xact component file to
|
| 487 |
|
|
find the filesets for each view and then processes every file in the
|
| 488 |
|
|
fileset through a verilog preprocessor putting all the output files
|
| 489 |
|
|
into a single verilog library file.<BR><BR>This means that the SOC
|
| 490 |
|
|
designer using a component only has to read one file to get all the
|
| 491 |
|
|
code of that component. They do not have to set any search paths
|
| 492 |
|
|
since these were all resolved by the preprocessor. All of the verilog
|
| 493 |
|
|
ttic statements(`) have also been resolved so that there is no danger
|
| 494 |
|
|
of name space collisions.<BR><BR>In order for this to work we need to
|
| 495 |
|
|
ensure that there are no module name collisions between the different
|
| 496 |
|
|
versions of a component. This is accomplished by the
|
| 497 |
|
|
preprocessor by setting <BR><BR><BR>`define VARIANT
|
| 498 |
|
|
component_version<BR><BR>and using that variable to set all of the
|
| 499 |
|
|
module names and instantiations in the verilog code. The module name
|
| 500 |
|
|
for the top most module will be</P>
|
| 501 |
|
|
<P> module `VARIANT</P>
|
| 502 |
|
|
<P><BR>and an instantiation for a module named rx_fsm will be</P>
|
| 503 |
|
|
<P><BR> `VARIANT`RX_FSM rx_fsm1 (</P>
|
| 504 |
|
|
<P><BR>The build_verilogLibrary script is used to create the
|
| 505 |
|
|
verilogLibrary file in the views/ directory. This script is run using
|
| 506 |
|
|
a componentGenerator in each ip-xact component file that takes all
|
| 507 |
|
|
the verilogInclude and verilogSource files in each views fileset and
|
| 508 |
|
|
runs them through a verilog preprocessor before storing the results
|
| 509 |
|
|
in the views directory.</P>
|
| 510 |
|
|
<P><BR><BR>
|
| 511 |
|
|
</P>
|
| 512 |
|
|
<P>The top level file for a component can be stored in a
|
| 513 |
|
|
verilogSource file but this cannot be modified or reconfigured when
|
| 514 |
|
|
the design changes. The preferred method is the run the
|
| 515 |
|
|
build_verilog script from a componentGenerator. This script will read
|
| 516 |
|
|
the ip-xact component and design files and recreate the verilog
|
| 517 |
|
|
module that they describe. If there is any logic that cannot be
|
| 518 |
|
|
described by ip-xact then it is placed in a verilogFragment file
|
| 519 |
|
|
listed in the fileset. This file is included by the build_verilog
|
| 520 |
|
|
script.</P>
|
| 521 |
|
|
<P>Simulation only code is placed in a verilogFragment file that is
|
| 522 |
|
|
listed in the sim fileset but omitted from the syn fileset. If a
|
| 523 |
|
|
design uses `ifdef SYNTHESYS then the syn fileset will have a
|
| 524 |
|
|
verilogInclude file with a `define SYNTHESYS. Translate on/off
|
| 525 |
|
|
pragmas are not supported.
|
| 526 |
|
|
</P>
|
| 527 |
|
|
<P><BR><BR>
|
| 528 |
|
|
</P>
|
| 529 |
|
|
<H2 CLASS="western"><FONT SIZE=4>SIM</FONT></H2>
|
| 530 |
|
|
<P>./sim/xml contains all the ip-xact components and designs
|
| 531 |
|
|
for testbenchs. Each version must have at least one testbench
|
| 532 |
|
|
</P>
|
| 533 |
|
|
<P>Testbench filenames follow the form</P>
|
| 534 |
|
|
<P> component_version_type_tb.xml</P>
|
| 535 |
|
|
<P>where</P>
|
| 536 |
|
|
<P> component
|
| 537 |
|
|
component name from vlnv<BR>
|
| 538 |
|
|
version
|
| 539 |
|
|
version name from vlnv<BR> type
|
| 540 |
|
|
|
| 541 |
|
|
only needed if there is more than one testbench for a version
|
| 542 |
|
|
</P>
|
| 543 |
|
|
<P>Testbenches are always hierarchial designs. They will instatiate
|
| 544 |
|
|
the design_under_test(DUT) along with all bus_functional_models(BFM)s
|
| 545 |
|
|
and other simulation models. The models used in simulations are all
|
| 546 |
|
|
independent socgen components that are stored in a different socgen
|
| 547 |
|
|
project. Avoid storing simulation models in the component directory.
|
| 548 |
|
|
If it is useful for you then the designer using your component may
|
| 549 |
|
|
also want to reuse it for their test suite. All shared code must be
|
| 550 |
|
|
placed in their own socgen projects.</P>
|
| 551 |
|
|
<P>./sim/verilog contains any remaining verilog code needed by
|
| 552 |
|
|
testbenches that will never be reused by other designers
|
| 553 |
|
|
<BR><BR><BR>./sim/icarus/ Each
|
| 554 |
|
|
simulation tool has it's own run area in the sim workspace.
|
| 555 |
|
|
Socgen currently only supports icarus verilog for simulations. Each
|
| 556 |
|
|
test in the test suite has its own subdirectory to store the
|
| 557 |
|
|
test and all of it's results files. Separating each test this way
|
| 558 |
|
|
makes it easier to farm out a test suite to different cpu's.
|
| 559 |
|
|
</P>
|
| 560 |
|
|
<P>Simulation directories follow the form</P>
|
| 561 |
|
|
<P> component_version_config_testSequence</P>
|
| 562 |
|
|
<P>where</P>
|
| 563 |
|
|
<P> component
|
| 564 |
|
|
component name from vlnv<BR>
|
| 565 |
|
|
version
|
| 566 |
|
|
version name from vlnv<BR> config
|
| 567 |
|
|
configuration
|
| 568 |
|
|
name from ./ip-xact/design.xml file<BR>
|
| 569 |
|
|
testSequence user assigned name for
|
| 570 |
|
|
code in test_define file</P>
|
| 571 |
|
|
<P>Inside the directory is the test_define file which contains
|
| 572 |
|
|
the verilog code that directs the entire test. Also included is a
|
| 573 |
|
|
vcddump control file (dump_define) to control what signals are dumped
|
| 574 |
|
|
as well as a wave.sav file for use be a vcddump viewer.
|
| 575 |
|
|
</P>
|
| 576 |
|
|
<P><BR><BR>./sim/lint/
|
| 577 |
|
|
All testbenchs are check for syntax
|
| 578 |
|
|
and structrual error by verilator. The log files for each one are
|
| 579 |
|
|
stored here.</P>
|
| 580 |
|
|
<P><BR>./sim/cov/
|
| 581 |
|
|
Each testbench can define what areas should be covered by code
|
| 582 |
|
|
coverage. The accumulated results for each testbench are stored here.</P>
|
| 583 |
|
|
<P><BR><BR>
|
| 584 |
|
|
</P>
|
| 585 |
|
|
<P><BR><BR>
|
| 586 |
|
|
</P>
|
| 587 |
|
|
<P><BR><BR>
|
| 588 |
|
|
</P>
|
| 589 |
|
|
<P><BR><BR>
|
| 590 |
|
|
</P>
|
| 591 |
|
|
<H2 CLASS="western"><FONT SIZE=4>SYN</FONT></H2>
|
| 592 |
|
|
<P>./syn/ise/ Each synthesis tool has it's
|
| 593 |
|
|
own work area. Socgen currently only supports Xilinx ISE webpack.
|
| 594 |
|
|
The only thing needed is a bsdl directory with the bsdl file for the
|
| 595 |
|
|
design. All other information is either in the ./ip-xact/design.xml
|
| 596 |
|
|
file or the component file.
|
| 597 |
|
|
</P>
|
| 598 |
|
|
<P><BR><BR>
|
| 599 |
|
|
</P>
|
| 600 |
|
|
<P><BR><BR>
|
| 601 |
|
|
</P>
|
| 602 |
|
|
<P><BR><BR>
|
| 603 |
|
|
</P>
|
| 604 |
|
|
<P><BR><BR>
|
| 605 |
|
|
</P>
|
| 606 |
|
|
<P><BR><BR>
|
| 607 |
|
|
</P>
|
| 608 |
|
|
<P><BR><BR>
|
| 609 |
|
|
</P>
|
| 610 |
|
|
<H2 CLASS="western"><A NAME="manifesto2"></A>Tools</H2>
|
| 611 |
|
|
<P><BR><BR>
|
| 612 |
|
|
</P>
|
| 613 |
|
|
<P><BR><BR>
|
| 614 |
|
|
</P>
|
| 615 |
|
|
<H2 CLASS="western"><FONT SIZE=4>Makefile</FONT></H2>
|
| 616 |
|
|
<P>clean<BR>all<BR>workspace
|
| 617 |
|
|
project=name<BR>build_hw<BR>build_sw<BR>run_sims<BR>build_fpgas<BR>check_sims<BR>check_fpgas
|
| 618 |
|
|
<BR><BR><BR><BR><B>soc_builder<BR><BR></B>Usage: soc_builder
|
| 619 |
|
|
project_name<BR> <BR><BR><BR><BR><B>soc_generate<BR><BR></B>Usage:
|
| 620 |
|
|
soc_generate -prefix prefix_path -project
|
| 621 |
|
|
project_name -lib_comp_sep lib_comp_sep -component
|
| 622 |
|
|
component_name -comp_xml_sep comp_xml_sep -variant variant_name
|
| 623 |
|
|
<BR><BR><BR><BR><BR><BR><B>build_sim_filelist <BR><BR></B>Usage:
|
| 624 |
|
|
build_sim_filelist -work_site
|
| 625 |
|
|
work_path -vendor vendor_name -project project_name
|
| 626 |
|
|
-lib_comp_sep lib_comp_sep -component component_name
|
| 627 |
|
|
-comp_xml_sep comp_xml_sep -variant variant_name
|
| 628 |
|
|
root_comp_xml<BR><BR><BR><B>build_syn_filelist <BR><BR></B>Usage:
|
| 629 |
|
|
build_sim_filelist -work_site
|
| 630 |
|
|
work_path -vendor vendor_name -project project_name
|
| 631 |
|
|
-lib_comp_sep lib_comp_sep -component component_name
|
| 632 |
|
|
-comp_xml_sep comp_xml_sep -variant variant_name
|
| 633 |
|
|
cde_library<BR><BR><B>build_coverage<BR><BR></B>Usage:
|
| 634 |
|
|
build_coverage -work_site
|
| 635 |
|
|
work_path -vendor -project project_name
|
| 636 |
|
|
-lib_comp_sep lib_comp_sep -component component_name
|
| 637 |
|
|
<BR><BR><BR><BR><BR><B>build_verilog <BR><BR></B>Usage:
|
| 638 |
|
|
build_verilog -view view_name
|
| 639 |
|
|
-prefix prefix_path -project project_name -lib_com_sep
|
| 640 |
|
|
lib_comp_sep -component component_name -comp_xml_sep comp_xml_sep
|
| 641 |
|
|
-variant variant_name fragment no_port destination_name
|
| 642 |
|
|
dest_dir<BR><BR><BR><BR><BR><B>build_verilogLibrary <BR><BR></B>Usage:
|
| 643 |
|
|
build_verilogLibrary -view view_name
|
| 644 |
|
|
-prefix prefix_path -project project_name -lib_com_sep
|
| 645 |
|
|
lib_comp_sep -component component_name -comp_xml_sep comp_xml_sep
|
| 646 |
|
|
-variant variant_name dest_dir</P>
|
| 647 |
|
|
<P><BR><BR>
|
| 648 |
|
|
</P>
|
| 649 |
|
|
<P><B>build_registers <BR><BR></B>Usage: build_registers
|
| 650 |
|
|
-view view_name -prefix prefix_path -project
|
| 651 |
|
|
project_name -lib_com_sep lib_comp_sep -component
|
| 652 |
|
|
component_name -comp_xml_sep comp_xml_sep -variant variant_name
|
| 653 |
|
|
-bigendian dest_dir</P>
|
| 654 |
|
|
<P><BR><BR>
|
| 655 |
|
|
</P>
|
| 656 |
|
|
<P><B>build_fizzim <BR><BR></B>Usage: build_fizzim
|
| 657 |
|
|
-view view_name -prefix prefix_path -project
|
| 658 |
|
|
project_name -lib_com_sep lib_comp_sep -component
|
| 659 |
|
|
component_name -comp_xml_sep comp_xml_sep -variant variant_name
|
| 660 |
|
|
-encoding encoding source destination</P>
|
| 661 |
|
|
<P><BR><BR>
|
| 662 |
|
|
</P>
|
| 663 |
|
|
<P><BR><BR>
|
| 664 |
|
|
</P>
|
| 665 |
|
|
<P><BR><BR>
|
| 666 |
|
|
</P>
|
| 667 |
|
|
<P><BR><BR>
|
| 668 |
|
|
</P>
|
| 669 |
|
|
<P><BR><BR>
|
| 670 |
|
|
</P>
|
| 671 |
|
|
<P><BR><BR>
|
| 672 |
|
|
</P>
|
| 673 |
|
|
<H2 CLASS="western"><A NAME="manifesto131"></A>Rules to live by</H2>
|
| 674 |
|
|
<P>(1) plan ahead</P>
|
| 675 |
|
|
<P>You may start a design with the intent that it is only going to be
|
| 676 |
|
|
used for one specific purpose only to find out later that other
|
| 677 |
|
|
designers want to use it. Create all designs with the intent that
|
| 678 |
|
|
they will be reused in ways that you haven't imagined and you won't
|
| 679 |
|
|
have to scramble later. <BR><BR><BR>
|
| 680 |
|
|
</P>
|
| 681 |
|
|
<P><BR>(2) maintain the design</P>
|
| 682 |
|
|
<P>Releasing a chip to production is not the end of the job. You must
|
| 683 |
|
|
still continue to maintain the design. You cannot archive a chip data
|
| 684 |
|
|
base into offline storage and simply put it on the shelf. Do you
|
| 685 |
|
|
really think that you can pull it down 20 years later and recreate
|
| 686 |
|
|
the chip? Bit Rot is real. Even if you can read the bits off the
|
| 687 |
|
|
magtape that you used to use then you will find that you can no
|
| 688 |
|
|
longer get the same version of the tools that you used to
|
| 689 |
|
|
build the chip. The original IC process will be long gone and the
|
| 690 |
|
|
current ones have added new requirements that your code doesn't
|
| 691 |
|
|
meet.<BR><BR>When you finish a chip you archive an exact copy of all
|
| 692 |
|
|
the data and freeze that forever. Your design then continues to live
|
| 693 |
|
|
on. When you get a new version of a tool you rebuild and test
|
| 694 |
|
|
everything and fix problems. As new processes come online you
|
| 695 |
|
|
retarget the design to use them. As component ip is reved you upgrade
|
| 696 |
|
|
and run the test suite.<BR><BR>Then when your original product is
|
| 697 |
|
|
winding down and someone wants a follow up product then you have a
|
| 698 |
|
|
head start.</P>
|
| 699 |
|
|
<P><BR><BR>
|
| 700 |
|
|
</P>
|
| 701 |
|
|
<P>(3) design for the lowest common denominator</P>
|
| 702 |
|
|
<P>Everybody loves to use some quirky little feature of the design
|
| 703 |
|
|
target to squeeze a little extra performance out of the system. But
|
| 704 |
|
|
if you do then you are locked into that target and cannot easily
|
| 705 |
|
|
reuse the design on a different target. Why do you think they put
|
| 706 |
|
|
those features in the first place? Instead you should survey the
|
| 707 |
|
|
field and only use the features that all target technologies can
|
| 708 |
|
|
match<BR><BR><BR><BR>
|
| 709 |
|
|
</P>
|
| 710 |
|
|
<P>(4) design in a completely generic technology</P>
|
| 711 |
|
|
<P>Design is a two step process. First the design is created and
|
| 712 |
|
|
verified in a completely generic behavioral RTL format and then
|
| 713 |
|
|
converted into the target technology. It is tempting to try to save
|
| 714 |
|
|
time be designing in the target technology but this will make it
|
| 715 |
|
|
harder to reuse.<BR><BR><BR><BR>
|
| 716 |
|
|
</P>
|
| 717 |
|
|
<P>(5) Automate everything</P>
|
| 718 |
|
|
<P>Handcrafting a design file is a time consuming and error prone
|
| 719 |
|
|
operation. Tasks that are preformed on every design should be done by
|
| 720 |
|
|
a tool. The designers job is to create the configuration files
|
| 721 |
|
|
needed by the tools and let automation do all the work.</P>
|
| 722 |
|
|
<P>(6) Store files based on their source and not their use</P>
|
| 723 |
|
|
<P>Are you creating a chip using IP from Joe's IP Emporium? Why not
|
| 724 |
|
|
create a spot inside your chip database for Joes files? Because that
|
| 725 |
|
|
is not planning ahead. Later if your lab starts another chip that
|
| 726 |
|
|
also uses Joes IP then they will also need access to those files.
|
| 727 |
|
|
Create a spot for files where everybody can simply access them by
|
| 728 |
|
|
linking the desired files into there database<FONT SIZE=4>.</FONT></P>
|
| 729 |
|
|
<P><BR><BR>
|
| 730 |
|
|
</P>
|
| 731 |
|
|
<P>(7) Do no mix unlike objects in the same file</P>
|
| 732 |
|
|
<P>"Unlike" is a deliberately nebulous term. It can mean
|
| 733 |
|
|
anything and everything. If you have a instance of a hard macro that
|
| 734 |
|
|
is unsynthesizable then do not put it in a file along with
|
| 735 |
|
|
synthesisable rtl code. If you have code belonging to one designer
|
| 736 |
|
|
then do not mix it with code belonging to another. If you do then you
|
| 737 |
|
|
have to worry about file locking. Fragment the design so that each
|
| 738 |
|
|
object is in it's own file and then use a tool to put them back
|
| 739 |
|
|
together.</P>
|
| 740 |
|
|
<P><BR><BR>(8) Layer the design</P>
|
| 741 |
|
|
<P>A full design will consist of several different databases that are
|
| 742 |
|
|
layered. Upper ones may override any content from a lower layer.
|
| 743 |
|
|
Requirements created by the Component Designers are only minimums,
|
| 744 |
|
|
The Architects and Si-Makers are free to override and tighten any
|
| 745 |
|
|
requirement from any lower level. Parameters should be used to
|
| 746 |
|
|
give the downstream designers the ability to tune the design
|
| 747 |
|
|
for the target process.</P>
|
| 748 |
|
|
<P><BR>(9) Reuse other components</P>
|
| 749 |
|
|
<P>The best way to create a reusable component is to build it using
|
| 750 |
|
|
other reusable components whenever possible. If something is useful
|
| 751 |
|
|
for you then it is likely that others could also need it. Look
|
| 752 |
|
|
through any available libraries before creating a new function and if
|
| 753 |
|
|
you have to create one then make it available to others.</P>
|
| 754 |
|
|
<P><BR><BR>
|
| 755 |
|
|
</P>
|
| 756 |
|
|
<P><BR><BR>
|
| 757 |
|
|
</P>
|
| 758 |
|
|
<P><BR><BR>
|
| 759 |
|
|
</P>
|
| 760 |
|
|
<P><BR><BR>
|
| 761 |
|
|
</P>
|
| 762 |
|
|
<P><BR><BR>
|
| 763 |
|
|
</P>
|
| 764 |
|
|
<P><BR><BR>
|
| 765 |
|
|
</P>
|
| 766 |
|
|
</BODY>
|
| 767 |
|
|
</HTML>
|
