URL
https://opencores.org/ocsvn/socgen/socgen/trunk
Subversion Repositories socgen
[/] [socgen/] [trunk/] [doc/] [src/] [guides/] [guide_users.html] - Rev 124
Go to most recent revision | Compare with Previous | Blame | View Log
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
<TITLE>Design Database Management</TITLE>
<META NAME="GENERATOR" CONTENT="LibreOffice 3.4 (Linux)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Ouabache Designworks">
<META NAME="CHANGED" CONTENT="20120130;10245000">
<META NAME="KEYWORDS" CONTENT="start">
<META NAME="Info 3" CONTENT="">
<META NAME="Info 4" CONTENT="">
<META NAME="date" CONTENT="2008-01-08T12:01:41-0500">
<META NAME="robots" CONTENT="index,follow">
<META NAME="CHANGEDBY" CONTENT="Ouabache Designworks">
<META NAME="CHANGEDBY" CONTENT="Ouabache Designworks">
<META NAME="CHANGEDBY" CONTENT="Ouabache Designworks">
<STYLE TYPE="text/css">
<!--
H2.cjk { font-family: "WenQuanYi Micro Hei" }
H2.ctl { font-family: "Lohit Hindi" }
-->
</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
<H1><A NAME="socgen_project"></A><FONT SIZE=6>SOCGEN Design
Environment </FONT>
</H1>
<H1> <FONT SIZE=6>Users Guide</FONT></H1>
<H2 CLASS="western"><BR><BR>
</H2>
<P>SOCGEN is a complete EDA design environment that simplifies
the creation of component IP and makes it easy integrate it into a
System-on-Chip (SOC). Its tool set uses IP-xact files to build and
retarget a complete SOC. It is designed to create of complex designs
from components obtained from a variety of different designers.
It is free ,opensourced and available from opencores.org.<BR><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto"></A>Installation</H2>
<P><BR>There are two ways to install and run socgen. The project on
opencores also contains a variety of different example IP modules
from other opencores projects. These have test suites and may be
synthesized into fpgas using the provided scripts.
</P>
<P>The second way is to use only the socgen/tools directory and add
that to your own design environment to furnish the tools.
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>Full SOCGEN Tool set with Example IP</FONT></H2>
<P>Start by checking out the complete socgen project from
opencores.org. You will need a login to do this. <BR><BR><BR><BR>
%> svn co -user <UserName> -passwd <Password>
opencores.org/ocsvn/socgen/socgen/trunk socgen<BR><BR><BR>There are
several opensource tools needed by socgen that must be installed in
your host machine. The directory socgen/tools/install contains
install scripts for the various supported operating systems.Once
installed then all socgen scripts are called from a Makefile at the
top level. These scripts will create a workspace area for
generated files , create all of the verilog files as well as
filelists and tool controls, compiles all the software embedded in
the design, runs all test suites with linting and code coverage,
synthesizes all fpgas and reports the results. <BR><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR>The commands to do all of this are: <BR><BR><BR>
%>make workspace<BR> %>make build_hw<BR>
%>make build_sw<BR> %>make run_sims<BR>
%>make build fpgas<BR> %>make check_sims<BR>
%>make check_fpgas<BR><BR><BR><BR><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>SOCGEN Tools only </FONT>
</H2>
<P>Start by creating a subdirectory with the name of your design
environment and then check out the socgen tools from opencores.org
into this directory. <BR><BR><BR><BR> %>
svn co -user <UserName> -passwd <Password>
opencores.org/ocsvn/socgen/socgen/trunk/tools tools<BR><BR><BR>Copy
the Makefile from ./tools/install up to your top level. Create a new
subdirectory name projects.All of your ip repositories will be
checked out into this directory. This IP must be IP-Xact compliant
and it's top level directory name must match the vendor's name and
follow the socgen component database guidelines. All of the socgen
scripts will work on this IP.<BR><BR><BR><BR><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto1"></A><FONT SIZE=5>Using
IP-Xact in a modern design for reuse environment</FONT></H2>
<P>Modern asics have grown to the point where it is no longer
possible for a design team to create a chip from scratch in any
reasonable amout of time. Todays designs rely on reusing major
amounts of code from past designs or 3rd party IP providers. A modern
asic will combine modules created by an inhouse design team with many
others from outside designers to create a code base that can be
synthesized and turned into a IC.<BR><BR>IP-Xact (IEEE-1685) plays a
crucial role in this effort. IP-Xact defines sets of file that
provides a "Data Sheet" for each component module. This
data sheet is not meant for human consumption but rather is designed
to ease the importation of that module into the asics tool flows.
</P>
<P>There are three different jobs in designing a modern asic and
designers need to understand what each one provides.</P>
<H2 CLASS="western"><FONT SIZE=4>Component Designer</FONT></H2>
<P> A component designer creates a module that performs
some usefull task. Along with documentation and IP-Xact files they
will also create a test suite that verifies that the component design
is correct.</P>
<H2 CLASS="western"><FONT SIZE=4>System Architect</FONT></H2>
<P> An architect selects various modules, configures them
and then interconnects them to create a hierarchial module. They also
create documentation, IP-Xact files and a test suite for this module.
This module can then be used by other architects until finally you
have one module the represents a single IC.<BR><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>Silicon Maker</FONT></H2>
<P> The silicon maker will take that module to synthesize
what they can and instantiatates library modules for the rest. It is
made testable before it is placed and routed. Timing is closed
and the design is made into a silicon die.<BR><BR><BR>IP-Xact is a
key player in passing design configuration and other information
along with the rtl code. Design for reuse is all about
efficiency and that requires a robust and proven EDA tool set capable
of using the IP-Xact standard.</P>
<P><BR><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto11"></A><FONT SIZE=5>adHoc and
bus signals</FONT></H2>
<P>All signals in a design are either adHoc or a member of a bus. An
adHoc signal is any signal connecting two or more instances where the
designers are free to pick their own signal name. You can do an
entire asic using nothing but adHoc signals but in a large design
this leads to chaos and makes the design very hard to understand and
maintain. Busses are used to bring order to this mess. You
create a bus by first defining some characteristic shared by a subset
of the adHoc signals and choosing a name for this group. Then
all adhoc signals that belong in this group will change their signal
names to match the buses signal name. Furthermore if there are any
adhoc signals that are not a member of this group that happen
to have signal names that match must change them to something that
doesn't collide. <BR><BR>For example a design team will decide to
create a bus for all signals that drive the clock port of a flipflop
and that they will uses the name "clk". Then all signals
driving clock ports must change their names to include "clk"
and any non clock port signals using "clk" must find
something else that doesn't collide
</P>
<P>The IP-Xact files for a design will have different sections for
adHoc and buses. This gives the tools more information about bus
signals that can be used to the tools advantage.</P>
<P><BR>Both adHoc and bus signals may be passed up the hierarchy but
can be changed anytime along the way. For example a lcd
controller module creates a 8-bit vga output as adHoc signals.
Rather than port these out as adHoc it will create a busInterface for
a vga bus consisting of eight RGB levels and a horizontal and
vertical sync signal. This bus is then ported up the hierarchy using
a hierConnection at each level until the last level before the pad
ring. At that level a bus interConnection will be used to connect to
the lower level while a busInterface of ten pad signals are created
using the same names as the vga bus. The top level padring will use
interConnections to connect all the pads to the core.</P>
<P>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto12"></A><FONT SIZE=5>Design
Repositories</FONT></H2>
<P>"Every piece of knowledge must have a single, unambiguous,
authoritative representation within a system." From The
Pragmatic Programmer</P>
<P><BR><BR>
</P>
<P>A Revision Control System (RCS) is mandatory for all design work.
This provides a location for backup data as well as design history
and the ability to restore the design to any previous version. Design
for reuse has had a profound change on how component IP is stored. A
SOC that was a in-house design could create a single RCS repository
that would store the entire design including all of it's
subcomponents. When component IP is reused you will have multiple
designs all needing the same components. In this case the component
designer must create their own repository for each component with a
test suite and make that repository available to all users. A
modern SOC is comprised of many different components and each one
should maintain a single location to serve as the source for
that component. The design environment for a SOC is a very minimal
database that contains only the scripts needed to locate and check
out all the repositories needed to build the SOC.</P>
<P>When a piece of component IP is obtained from outside the
organisation then then a copy of that IP should be kept in a central
location for use in all SOCs that need it. This avoids have
having multiple copies of a component floating around and protects
against loss if the original source disappears. It also aids in
distributing updates and bug fixes.</P>
<P><BR>SOC design may involve working with an outside asic vendor.
A seperate respository should be used by the vendor to add all of
their libraries and components for synthesis. A seperate repository
prevents the vendor from accessing source code and documentation that
must be controlled.</P>
<P>The choice of RCS software is up to the component designers and
any modern SOC will likely use a mixture of systems. When choosing a
RCS system remember that your component IP code will likely outlive
whatever the RCS-du-jour happens to be and that you will eventually
have to port over to a new system.
</P>
<P>A design repository for a socgen IP component must be IP-Xact
compliant and follow the socgen guidelines for directory structure.
<BR><BR><BR><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto111"></A><FONT SIZE=5>Workspaces</FONT></H2>
<P><BR>The build and verification process will expand size of the
design environment by several orders of magnitude. It is important
that generated files are never stored in a active RCS repository. The
possibility that the presence or time stamp of a defunct generated
file could alter the build is to much of a risk to take. A workspace
is created for the build process that creates a linked file image of
all the pertinent repositories in a separate directory. Source files
are all available and generated files are stored there. A clean build
is guaranteed by deleting the workspace and rebuilding a new one.<BR><BR>It
is really hard to keep track of all the new files that you have added
that you need to check into the Revision Control System if they
are buried by gigabytes of generated files from the build process.
The workspace uses symbolic links to create a area where generated
files are kept outside the RCS repository. Never check a generated
file in an RCS repository. They should only contain the minimal seed
data needed to rebuild the entire design. It should never contain any
files that were generated by the build process. <BR><BR><BR>A similar
workspace is also created for tools.
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto121"></A><FONT SIZE=5>Projects</FONT></H2>
<P><BR>A project is a database structure that is used to store
component IP. All projects are stored under the projects subdirectory
in a socgen design environment and delivering a component to another
designer simply means creating a package containing the project for
the top level and all sub projects that are part of the design.
Once received the projects are placed in the projects directory and
the component can then be added by any IP-Xact editor by calling form
it by it's vlnv. <BR><BR>The top level directory of a project is the
vendor name from the IP-Xact vlnv. Under that are as many libraries
as needed with the library name used for the directory
name.<BR><BR>Libraries are used to manage the database by grouping
related components together into one library. Each library can have
up to four subdirectories. <BR><BR><BR><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>DOC</FONT></H2>
<P>./doc/ contains any needed documentation.
</P>
<H2 CLASS="western"><FONT SIZE=4>BIN</FONT></H2>
<P>./bin/ contains any needed scripts or tools needed to build
the IP or compile the software. These tools are called by
componentGenerators in the IP-Xact files</P>
<H2 CLASS="western"><FONT SIZE=4>IP</FONT></H2>
<P>./ip/ contains all the IP components. The directory name
matches the component name from the components vlnv.</P>
<H2 CLASS="western"><FONT SIZE=4>SW</FONT></H2>
<P>./sw/ contains any sw that must be embedded inside the
design. <BR> <BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto13"></A><FONT SIZE=5>Components</FONT></H2>
<P><BR>A component is used to store the files needed to create the
component rtl code. It also can contain a simulation tool flow with
test benchs and the test suite that demonstrates the components
functionality or a synthesys tool flow to convert the component into
gates.<BR><BR>The example designs included in the socgen project use
verilog only. Tool flows are included that use Icarus verilog for
simulation, Covered for code coverage , Verilator for linting and
Xilinx ISE 13.3 for synthesis.<BR><BR>Notice that socgen components
do NOT include an extra level to store the different versions of a
component. The reason for this is that versioning by its very nature
will create designs where very few lines of code are actually
changed. If you are changing a significant amount of code then you
should not release a new version, you should release a new
component. Placing each version in it's own subdirectory will
result in a significant amount of code that is duplicated between the
different versions. This would break our rule about having a single
place to store each piece of data.<BR><BR>Components can contain /doc
and /bin directories are well as others<BR><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>IP-XACT</FONT></H2>
<P>./ip-xact/ contains any needed ip-xact designConfiguration
files for this component and all of its versions. These files are
only needed for hierarchal designs that contain other socgen
components.
</P>
<P><BR>It also contains a design.xml file that is a non-ip-xact file.
It is used for "yellow pages" functions and to provide
setup information to the tool flows. This function will take in a
vlnv and return the absolute path to the file containing that ip-xact
object.</P>
<P><BR><BR>
</P>
<P>The design.xml file contains.</P>
<P> (1) List of all designs by their component and
version<BR> (2) List of all testbenchs with
design_under_test and code coverage information<BR> (3)
List of all non-default configurations with name<>value
pairs<BR> (4) List of all simulations with testbench and
config<BR> (5) List of all synthesizable designs with
their component and target</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>RTL</FONT></H2>
<P>./rtl/verilog contains all the verilog code needed by all
versions of the design. These can be any of three possible types:
<BR><BR> (1) verilogSource
complete verilog module where the module name matches the filename.<BR>
(2) verilogInclude
consists only of `define statements.<BR>
(3) verilogFragment is a `include "filename"
inside of a verilog module.<BR><BR>./rtl/xml contains all the
ip-xact components and designs for all the versions of the component.
Leaf cells will only have a component file while hierarchal cells
will also have a design file. <BR><BR><BR>Most components will have
several versions and it is important to understand how ip-xact uses
versioning. A component can have different versions released over
time. Six months after you release version 1.0 you fix some bugs and
rerelease as verison 1.1. In this case the affected verilog files are
copied to a different name , modified and the file sets in the
ip-xact component files are modified to point to the new files.<BR><BR>You
can also version a component over design space. If you have a cpu
where the user can configure it with or without I-cache and D-Cache
then your component can have four different versions. The best way to
configure these is to use parameters. Then each instance can set it's
own configuration and you only need one ip-xact component file.<BR><BR>But
there are two situations where you cannot use parameters. These are
when the parameter will change a port list or when it will change a
filelist. If either of these occur then you must create a seperate
ip-xact component file with it's own vlnv. This creates a problem
because the vlnv has four places to store five fields. Good
luck.<BR><BR>Some designers try to avoid this issue by creating a
superset design. The design is created with all possible ports and
any unneeded output ports are tied off to safe values and the file
list includes files that may not be used in the design. This is a
design-for-reuse disaster waiting to happen and must NEVER be done.
Have you ever spent several hours assembling something only to end up
with a few parts left over? It could be that the manufacturer had
several products needing simialar part kits and simply created one
superset kit for all of them. Or you could have made a mistake and
the thing will break when you try to use it. How much time will you
spend to figure out which one is correct? This is why we do not do
superset designs. If you make a mistake in your rtl and forget to
instantiate a needed module then that module will show up in a
simulation as a second top level module that you can track down and
fix. If component designers do a superset filelist then your easiest
chance of catching that error will be buried under thousands of
unused files. </P>
<P>IP-Xact component filenames follow the form</P>
<P> component_version_config.xml</P>
<P>where</P>
<P> component
component name from vlnv<BR>
version
version name from vlnv<BR>
config
user assigned configuration name ( _def is for the default
configuration)</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P>IP-Xact design files follow the form</P>
<P> component_verison_config.design.xml</P>
<P><BR><BR>
</P>
<P>./rtl/fsm A finite state machine generator is a very useful
tool. You use a GUI to enter the states and transitions defining the
state machine and save that datafile in the ./fsm directory. You then
use a componentGenerator in the ip-xact component file to read the
fsm datafile and create a new verilogSource or verilogFragment file.
Socgen supports the fizzim opensourced FSM tool but any others could
be easily added.</P>
<P><BR>A register tool that creates register logic, documentation,
#include files etc is also very useful but we do not have a place for
the register tool source files. That is because ip-xact supports
register descriptions and we use a componentGenerator to read the
ip-xact component file and create the verilog.<BR><BR><BR>./rtl/views
Views are the biggest change that most designers will have to
adjust to when using ip-xact. Many designers create a single
deliverable that is used by all tools. This means that any
unsynthesizable code must use a pragma or a `ifdef to hide itself
from synthesys tools. Ip-xact lets each tool create its own
deliverable that contains exactly what it needs. Nothing more or
nothing less. Each socgen component has a view for
simulation(sim) and a seperate on for synthesys(syn). <BR><BR>When
the socgen build_hw flow has finished then the rtl/views directories
will each contain a ./sim and ./syn subdirectory. Inside these will
be one file for each version of the component and the filename with
match the component_verison name. This file will be a verilog Library
file that contains all the modules needed by that version. This is
created by a socgen tool that reads every ip-xact component file to
find the filesets for each view and then processes every file in the
fileset through a verilog preprocessor putting all the output files
into a single verilog library file.<BR><BR>This means that the SOC
designer using a component only has to read one file to get all the
code of that component. They do not have to set any search paths
since these were all resolved by the preprocessor. All of the verilog
ttic statements(`) have also been resolved so that there is no danger
of name space collisions.<BR><BR>In order for this to work we need to
ensure that there are no module name collisions between the different
versions of a component. This is accomplished by the
preprocessor by setting <BR><BR><BR>`define VARIANT
component_version<BR><BR>and using that variable to set all of the
module names and instantiations in the verilog code. The module name
for the top most module will be</P>
<P> module `VARIANT</P>
<P><BR>and an instantiation for a module named rx_fsm will be</P>
<P><BR> `VARIANT`RX_FSM rx_fsm1 (</P>
<P><BR>The build_verilogLibrary script is used to create the
verilogLibrary file in the views/ directory. This script is run using
a componentGenerator in each ip-xact component file that takes all
the verilogInclude and verilogSource files in each views fileset and
runs them through a verilog preprocessor before storing the results
in the views directory.</P>
<P><BR><BR>
</P>
<P>The top level file for a component can be stored in a
verilogSource file but this cannot be modified or reconfigured when
the design changes. The preferred method is the run the
build_verilog script from a componentGenerator. This script will read
the ip-xact component and design files and recreate the verilog
module that they describe. If there is any logic that cannot be
described by ip-xact then it is placed in a verilogFragment file
listed in the fileset. This file is included by the build_verilog
script.</P>
<P>Simulation only code is placed in a verilogFragment file that is
listed in the sim fileset but omitted from the syn fileset. If a
design uses `ifdef SYNTHESYS then the syn fileset will have a
verilogInclude file with a `define SYNTHESYS. Translate on/off
pragmas are not supported.
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>SIM</FONT></H2>
<P>./sim/xml contains all the ip-xact components and designs
for testbenchs. Each version must have at least one testbench
</P>
<P>Testbench filenames follow the form</P>
<P> component_version_type_tb.xml</P>
<P>where</P>
<P> component
component name from vlnv<BR>
version
version name from vlnv<BR> type
only needed if there is more than one testbench for a version
</P>
<P>Testbenches are always hierarchial designs. They will instatiate
the design_under_test(DUT) along with all bus_functional_models(BFM)s
and other simulation models. The models used in simulations are all
independent socgen components that are stored in a different socgen
project. Avoid storing simulation models in the component directory.
If it is useful for you then the designer using your component may
also want to reuse it for their test suite. All shared code must be
placed in their own socgen projects.</P>
<P>./sim/verilog contains any remaining verilog code needed by
testbenches that will never be reused by other designers
<BR><BR><BR>./sim/icarus/ Each
simulation tool has it's own run area in the sim workspace.
Socgen currently only supports icarus verilog for simulations. Each
test in the test suite has its own subdirectory to store the
test and all of it's results files. Separating each test this way
makes it easier to farm out a test suite to different cpu's.
</P>
<P>Simulation directories follow the form</P>
<P> component_version_config_testSequence</P>
<P>where</P>
<P> component
component name from vlnv<BR>
version
version name from vlnv<BR> config
configuration
name from ./ip-xact/design.xml file<BR>
testSequence user assigned name for
code in test_define file</P>
<P>Inside the directory is the test_define file which contains
the verilog code that directs the entire test. Also included is a
vcddump control file (dump_define) to control what signals are dumped
as well as a wave.sav file for use be a vcddump viewer.
</P>
<P><BR><BR>./sim/lint/
All testbenchs are check for syntax
and structrual error by verilator. The log files for each one are
stored here.</P>
<P><BR>./sim/cov/
Each testbench can define what areas should be covered by code
coverage. The accumulated results for each testbench are stored here.</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>SYN</FONT></H2>
<P>./syn/ise/ Each synthesis tool has it's
own work area. Socgen currently only supports Xilinx ISE webpack.
The only thing needed is a bsdl directory with the bsdl file for the
design. All other information is either in the ./ip-xact/design.xml
file or the component file.
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto2"></A>Tools</H2>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><FONT SIZE=4>Makefile</FONT></H2>
<P>clean<BR>all<BR>workspace
project=name<BR>build_hw<BR>build_sw<BR>run_sims<BR>build_fpgas<BR>check_sims<BR>check_fpgas
<BR><BR><BR><BR><B>soc_builder<BR><BR></B>Usage: soc_builder
project_name<BR> <BR><BR><BR><BR><B>soc_generate<BR><BR></B>Usage:
soc_generate -prefix prefix_path -project
project_name -lib_comp_sep lib_comp_sep -component
component_name -comp_xml_sep comp_xml_sep -variant variant_name
<BR><BR><BR><BR><BR><BR><B>build_sim_filelist <BR><BR></B>Usage:
build_sim_filelist -work_site
work_path -vendor vendor_name -project project_name
-lib_comp_sep lib_comp_sep -component component_name
-comp_xml_sep comp_xml_sep -variant variant_name
root_comp_xml<BR><BR><BR><B>build_syn_filelist <BR><BR></B>Usage:
build_sim_filelist -work_site
work_path -vendor vendor_name -project project_name
-lib_comp_sep lib_comp_sep -component component_name
-comp_xml_sep comp_xml_sep -variant variant_name
cde_library<BR><BR><B>build_coverage<BR><BR></B>Usage:
build_coverage -work_site
work_path -vendor -project project_name
-lib_comp_sep lib_comp_sep -component component_name
<BR><BR><BR><BR><BR><B>build_verilog <BR><BR></B>Usage:
build_verilog -view view_name
-prefix prefix_path -project project_name -lib_com_sep
lib_comp_sep -component component_name -comp_xml_sep comp_xml_sep
-variant variant_name fragment no_port destination_name
dest_dir<BR><BR><BR><BR><BR><B>build_verilogLibrary <BR><BR></B>Usage:
build_verilogLibrary -view view_name
-prefix prefix_path -project project_name -lib_com_sep
lib_comp_sep -component component_name -comp_xml_sep comp_xml_sep
-variant variant_name dest_dir</P>
<P><BR><BR>
</P>
<P><B>build_registers <BR><BR></B>Usage: build_registers
-view view_name -prefix prefix_path -project
project_name -lib_com_sep lib_comp_sep -component
component_name -comp_xml_sep comp_xml_sep -variant variant_name
-bigendian dest_dir</P>
<P><BR><BR>
</P>
<P><B>build_fizzim <BR><BR></B>Usage: build_fizzim
-view view_name -prefix prefix_path -project
project_name -lib_com_sep lib_comp_sep -component
component_name -comp_xml_sep comp_xml_sep -variant variant_name
-encoding encoding source destination</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<H2 CLASS="western"><A NAME="manifesto131"></A>Rules to live by</H2>
<P>(1) plan ahead</P>
<P>You may start a design with the intent that it is only going to be
used for one specific purpose only to find out later that other
designers want to use it. Create all designs with the intent that
they will be reused in ways that you haven't imagined and you won't
have to scramble later. <BR><BR><BR>
</P>
<P><BR>(2) maintain the design</P>
<P>Releasing a chip to production is not the end of the job. You must
still continue to maintain the design. You cannot archive a chip data
base into offline storage and simply put it on the shelf. Do you
really think that you can pull it down 20 years later and recreate
the chip? Bit Rot is real. Even if you can read the bits off the
magtape that you used to use then you will find that you can no
longer get the same version of the tools that you used to
build the chip. The original IC process will be long gone and the
current ones have added new requirements that your code doesn't
meet.<BR><BR>When you finish a chip you archive an exact copy of all
the data and freeze that forever. Your design then continues to live
on. When you get a new version of a tool you rebuild and test
everything and fix problems. As new processes come online you
retarget the design to use them. As component ip is reved you upgrade
and run the test suite.<BR><BR>Then when your original product is
winding down and someone wants a follow up product then you have a
head start.</P>
<P><BR><BR>
</P>
<P>(3) design for the lowest common denominator</P>
<P>Everybody loves to use some quirky little feature of the design
target to squeeze a little extra performance out of the system. But
if you do then you are locked into that target and cannot easily
reuse the design on a different target. Why do you think they put
those features in the first place? Instead you should survey the
field and only use the features that all target technologies can
match<BR><BR><BR><BR>
</P>
<P>(4) design in a completely generic technology</P>
<P>Design is a two step process. First the design is created and
verified in a completely generic behavioral RTL format and then
converted into the target technology. It is tempting to try to save
time be designing in the target technology but this will make it
harder to reuse.<BR><BR><BR><BR>
</P>
<P>(5) Automate everything</P>
<P>Handcrafting a design file is a time consuming and error prone
operation. Tasks that are preformed on every design should be done by
a tool. The designers job is to create the configuration files
needed by the tools and let automation do all the work.</P>
<P>(6) Store files based on their source and not their use</P>
<P>Are you creating a chip using IP from Joe's IP Emporium? Why not
create a spot inside your chip database for Joes files? Because that
is not planning ahead. Later if your lab starts another chip that
also uses Joes IP then they will also need access to those files.
Create a spot for files where everybody can simply access them by
linking the desired files into there database<FONT SIZE=4>.</FONT></P>
<P><BR><BR>
</P>
<P>(7) Do no mix unlike objects in the same file</P>
<P>"Unlike" is a deliberately nebulous term. It can mean
anything and everything. If you have a instance of a hard macro that
is unsynthesizable then do not put it in a file along with
synthesisable rtl code. If you have code belonging to one designer
then do not mix it with code belonging to another. If you do then you
have to worry about file locking. Fragment the design so that each
object is in it's own file and then use a tool to put them back
together.</P>
<P><BR><BR>(8) Layer the design</P>
<P>A full design will consist of several different databases that are
layered. Upper ones may override any content from a lower layer.
Requirements created by the Component Designers are only minimums,
The Architects and Si-Makers are free to override and tighten any
requirement from any lower level. Parameters should be used to
give the downstream designers the ability to tune the design
for the target process.</P>
<P><BR>(9) Reuse other components</P>
<P>The best way to create a reusable component is to build it using
other reusable components whenever possible. If something is useful
for you then it is likely that others could also need it. Look
through any available libraries before creating a new function and if
you have to create one then make it available to others.</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
<P><BR><BR>
</P>
</BODY>
</HTML> Go to most recent revision | Compare with Previous | Blame | View Log