URL
https://opencores.org/ocsvn/socgen/socgen/trunk
Subversion Repositories socgen
Compare Revisions
- This comparison shows the changes necessary to convert path
/socgen/trunk/doc
- from Rev 99 to Rev 103
- ↔ Reverse comparison
Rev 99 → Rev 103
/src/guides/guide_users.html
0,0 → 1,767
<!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> |
/pdf/guide_users.pdf
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
pdf/guide_users.pdf
Property changes :
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property