jcarr
/
coriolis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
coriolis/documentation/output/pages/check-toolkit.html

1135 lines
61 KiB
HTML
Raw Blame History

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="Printable Version of this Document Alliance Check Toolkit. Contents Printable Version of this Document Toolkit Purpose Release Notes Toolkit Contents Toolkit Layout Benchmark Makefiles Setting Up the ...">
<meta name="keywords" content="">
<link rel="icon" href="../favicon.ico">
<title>Alliance Check Toolkit - Coriolis VLSI CAD Tools [offline]</title>
<!-- Stylesheets -->
<link href="../theme/css/bootstrap.css" rel="stylesheet">
<link href="../theme/css/fonts.css" rel="stylesheet">
<link href="../theme/css/nest.css" rel="stylesheet">
<link href="../theme/css/pygment.css" rel="stylesheet">
<link href="../theme/css/coriolis.css" rel="stylesheet">
<!-- /Stylesheets -->
<script src="../theme/js/jquery.min.js"></script>
<script src="../theme/js/bootstrap.min.js"></script>
<!-- RSS Feeds -->
<!-- /RSS Feeds -->
<!-- HTML5 shim and Respond.js for IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
<script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
<![endif]-->
</head>
<body>
<!-- Header -->
<div class="header-container" style="background: linear-gradient(rgba(0, 0, 0, 0.2), rgba(0, 0, 0, 0.2)), url('../images/common/layout-motif-faded-4.png'); background-position: center; ">
<!--
<div class="container">
<nav class="navbar navbar-default">
<div class="container-fluid">
<div class="navbar-header">
<a class="navbar-brand" href="../"><img class="mr20" src="../images/common/Coriolis-logo-white-4-small.png" alt="logo">Coriolis VLSI CAD Tools [offline]</a>
</div>
<ul class="nav navbar-nav">
<li><a href="../pages/gitlab.html">Git</a></li>
<li><a href="../pages/documentation.html">Documentation</a></li>
<li class="dropdown">
<button class="btn btn-default dropdown-toggle" type="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="true">
<span class="caret"></span>Topics
</button>
<ul class="dropdown-menu">
<li><a class="dropdown-item " href="../pages/homepage.html">Coriolis <span class="sc">vlsi</span> Backend Tools</a></li>
<li><a class="dropdown-item " href="../pages/symbolic-layout.html">Symbolic Layout</a></li>
</ul>
</li>
</ul>
</div>
</nav>
</div> <!-- navbar container -->
-->
<!-- Static navbar -->
<div class="container">
<div class="header-nav">
<div class="header-logo">
<a class="pull-left" href="../"><img class="mr20" src="../images/common/Coriolis-logo-white-4-small.png" alt="logo">Coriolis VLSI CAD Tools [offline]</a>
</div>
<div class="nav pull-right">
<a href="../pages/gitlab.html">Git</a>
<a href="../pages/documentation.html">Documentation</a>
</div>
<div class="nav pull-right">
<div class="dropdown">
<button class="btn btn-default dropdown-toggle" type="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="true">
<span class="caret"></span>Topics
</button>
<ul class="dropdown-menu">
<li><a class="dropdown-item " href="../pages/homepage.html">Coriolis <span class="sc">vlsi</span> Backend Tools</a></li>
<li><a class="dropdown-item " href="../pages/symbolic-layout.html">Symbolic Layout</a></li>
</ul>
</div>
</div>
</div>
</div>
<!-- /Static navbar -->
<!-- Header -->
<div class="container header-wrapper">
<div class="row">
<div class="col-lg-12">
<div class="header-content">
<a href="https://www.lip6.fr/"><img class="mr20" height="60px" src="../images/common/LogoLIP6Blanc.png" alt="LIP6"></a>
<a href="https://www.sorbonne-universite.fr/"><img class="mr20" height="60px" src="../images/common/logo-SU-blanc-700px.png" alt="Sorbonne Universite"></a>
<a href="https://www.cnrs.fr/"><img class="mr20" height="60px" src="../images/common/LOGO-cnrs-white-large.png" alt="CNRS"></a>
<h1 class="header-title text-uppercase">Alliance Check Toolkit</h1>
<div class="header-underline"></div>
</div>
</div>
</div>
</div>
<!-- /Header -->
</div>
<!-- /Header -->
<!-- Content -->
<div class="container content">
<!-- -*- Mode: rst -*- -->
<!-- URLs that changes between the various backends. -->
<div class="section" id="printable-version-of-this-document">
<h2><a class="toc-backref" href="#id3">Printable Version of this Document</a></h2>
<p><a class="reference external" href="../pdfs/CheckToolkit.pdf">Alliance Check Toolkit</a>.</p>
<div class="contents topic" id="contents">
<p class="topic-title first">Contents</p>
<ul class="simple">
<li><a class="reference internal" href="#printable-version-of-this-document" id="id3">Printable Version of this Document</a></li>
<li><a class="reference internal" href="#toolkit-purpose" id="id4">Toolkit Purpose</a></li>
<li><a class="reference internal" href="#release-notes" id="id5">Release Notes</a></li>
<li><a class="reference internal" href="#toolkit-contents" id="id6">Toolkit Contents</a></li>
<li><a class="reference internal" href="#toolkit-layout" id="id7">Toolkit Layout</a></li>
<li><a class="reference internal" href="#benchmark-makefiles" id="id8">Benchmark Makefiles</a></li>
<li><a class="reference internal" href="#setting-up-the-user-s-environement" id="id9">Setting Up the User's Environement</a></li>
<li><a class="reference internal" href="#benchmarks-special-notes" id="id10">Benchmarks Special Notes</a></li>
<li><a class="reference internal" href="#libraries-makefiles" id="id11">Libraries Makefiles</a></li>
<li><a class="reference internal" href="#macro-blocks-makefiles" id="id12">Macro-Blocks Makefiles</a></li>
<li><a class="reference internal" href="#tools-scripts" id="id13">Tools &amp; Scripts</a></li>
<li><a class="reference internal" href="#cadence-support" id="id14"><span class="sc">Cadence</span> Support</a></li>
<li><a class="reference internal" href="#technologies" id="id15">Technologies</a></li>
</ul>
</div>
<!-- -*- Mode: rst; explicit-buffer-name: "definition.rst<documentation/etc>" -*- -->
<!-- HTML/LaTeX backends mixed macros. -->
<!-- Acronyms & names. -->
<!-- URLs -->
<!-- Standard CAO/VLSI Concepts. -->
<!-- Alliance & MBK Concepts -->
<!-- Hurricane Concepts. -->
<!-- -*- Mode: rst -*- -->
<!-- Acronyms & Names -->
</div>
<div class="section" id="toolkit-purpose">
<h2><a class="toc-backref" href="#id4">Toolkit Purpose</a></h2>
<p>This toolkit has been created to allow developpers to share through <span class="cb">git</span> a set
of benchmarks to validate their changes in <span class="sc">Alliance</span> &amp; <span class="sc">Coriolis</span> before commiting
and pushing them in their central repositories. A change will be considered as
validated when all the developpers can run successfully all the benchs in their
respective environments.</p>
<p>As a consequence, this repository is likely to be <em>very</em> unstable and the commits
not well documenteds as they will be quick corrections made by the developpers.</p>
</div>
<div class="section" id="release-notes">
<h2><a class="toc-backref" href="#id5">Release Notes</a></h2>
<div class="section" id="august-30-2019">
<h3>August 30, 2019</h3>
<p><span class="sc">Katana</span> is now used as the default router. It can now manage a complete chip design
with I/O pads. As a consequence, the <span class="cb">Makefile</span> are all modificated, the variable
<tt class="docutils literal">USE_KATANA=Yes</tt> is changed to <tt class="docutils literal">USE_KITE=No</tt> (see <a class="reference internal" href="#benchmark-makefiles">Benchmark Makefiles</a>).</p>
<p>Designs with I/O pads are also modificated to be processed by <span class="sc">Katana</span> as it uses
a different approach.</p>
<p></p>
</div>
</div>
<div class="section" id="toolkit-contents">
<h2><a class="toc-backref" href="#id6">Toolkit Contents</a></h2>
<p>The toolkit provides:</p>
<ul class="simple">
<li><strong>OK Status.</strong> A set of eight benchmark designs that are used as regression tests (see <a class="reference internal" href="#go-sh">go.sh</a>).
Benchmarks with multiple target technologies still count as one.</li>
<li><strong>KO Status.</strong> Examples that currently fails due to incomplete or poorly implemenented
features of <span class="sc">Coriolis</span>.</li>
<li><strong>Unchecked.</strong> Non-fonctional examples, or really too long to run for a regression test.</li>
</ul>
<table class="table">
<colgroup>
<col width="28%" />
<col width="25%" />
<col width="37%" />
<col width="10%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Design</th>
<th class="head">Technology</th>
<th class="head">Cell Libraries</th>
<th class="head">Status</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">adder</tt></td>
<td><span class="sc">mosis</span></td>
<td><tt class="docutils literal">nsxlib</tt>, <tt class="docutils literal">mpxlib</tt>, <tt class="docutils literal">msplib</tt></td>
<td>Unchecked</td>
</tr>
<tr><td><span class="sc">am2901</span> (standard cells)</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">pxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">am2901</span> (datapath)</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">dp_sxlib</tt>, <tt class="docutils literal">pxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">alliance-run</span></tt> (<span class="sc">am2901</span>)</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">dp_sxlib</tt>, <tt class="docutils literal">padlib</tt></td>
<td>Unchecked</td>
</tr>
<tr><td><tt class="docutils literal">RingOscillator</tt></td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">cpu</span></td>
<td><span class="sc">mosis</span></td>
<td><tt class="docutils literal">nsxlib</tt>, <tt class="docutils literal">mpxlib</tt>, <tt class="docutils literal">msplib</tt></td>
<td>OK</td>
</tr>
<tr><td colspan="4"><strong>SNX</strong></td>
</tr>
<tr><td><span class="sc">snx</span> / Alliance</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sclib</tt></td>
<td>Unchecked</td>
</tr>
<tr><td><span class="sc">snx</span> / sxlib2M</td>
<td>Symbolic cmos 2M</td>
<td><tt class="docutils literal">sxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">snx</span> / cmos</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">pxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">snx</span> / cmos45</td>
<td>Symbolic cmos 45</td>
<td><tt class="docutils literal">nsxlib</tt>, <tt class="docutils literal">mpxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">snx</span> / FreePDK_45</td>
<td>FreePDK 45</td>
<td><tt class="docutils literal">gscl45</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">snx</span> / c35b4</td>
<td>AMS 350nm c35b4</td>
<td><tt class="docutils literal">corelib</tt></td>
<td>KO</td>
</tr>
<tr><td colspan="4"><strong>6502</strong></td>
</tr>
<tr><td><span class="sc">6502</span> / cmos45</td>
<td>Symbolic cmos 45</td>
<td><tt class="docutils literal">nsxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">Arlet6502</span> / cmos350</td>
<td>Symbolic cmos 45</td>
<td><tt class="docutils literal">nsxlib</tt></td>
<td>OK</td>
</tr>
<tr><td colspan="4"><strong>MIPS</strong></td>
</tr>
<tr><td><span class="sc">mips</span> (microprogrammed)</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">dp_sxlib</tt>, <tt class="docutils literal">rf2lib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">mips</span> (pipeline)</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">dp_sxlib</tt>, <tt class="docutils literal">rf2lib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">mips</span> (pipeline+chip)</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">dp_sxlib</tt>, <tt class="docutils literal">rf2lib</tt>, <tt class="docutils literal">pxlib</tt></td>
<td>Unchecked</td>
</tr>
<tr><td colspan="4"><strong>Miscellaneous</strong></td>
</tr>
<tr><td><span class="sc">fpga</span> (<tt class="docutils literal">Moc4x4_L4C12</tt>)</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt></td>
<td>KO</td>
</tr>
<tr><td><span class="sc">ispd05</span> (<tt class="docutils literal">bigblue1</tt>)</td>
<td>None</td>
<td>Generated on the fly</td>
<td>Unchecked</td>
</tr>
<tr><td><span class="sc">ARMv2a</span></td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">pxlib</tt></td>
<td>OK</td>
</tr>
<tr><td colspan="4"><strong>Vex RISC-V</strong></td>
</tr>
<tr><td><span class="sc">VexRiscV</span> / cmos</td>
<td>Symbolic cmos</td>
<td><tt class="docutils literal">sxlib</tt>, <tt class="docutils literal">pxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">VexRiscV</span> / cmos45</td>
<td>Symbolic cmos 45</td>
<td><tt class="docutils literal">nsxlib</tt>, <tt class="docutils literal">mpxlib</tt></td>
<td>OK</td>
</tr>
<tr><td><span class="sc">VexRiscV</span> / FreePDK_45</td>
<td>FreePDK 45</td>
<td><tt class="docutils literal">gscl45</tt></td>
<td>KO</td>
</tr>
<tr><td><span class="sc">VexRiscV</span> / c35b4</td>
<td>AMS 350nm c35b4</td>
<td><tt class="docutils literal">corelib</tt></td>
<td>KO</td>
</tr>
<tr><td colspan="4"><strong>nMigen basic ALU example</strong></td>
</tr>
<tr><td><span class="sc">alu</span> / scn6m_deep_09</td>
<td><span class="sc">mosis</span></td>
<td><tt class="docutils literal">nsxlib</tt></td>
<td>Unchecked</td>
</tr>
</tbody>
</table>
<p></p>
<ul>
<li><p class="first">The <span class="sc">nMigen</span> design is the basic <span class="sc">alu</span> taken from the distribution to perform
integration test in the design flow. The target technology is the <span class="sc">mosis</span> 180nm
(<tt class="docutils literal">scn6m_deep</tt>).</p>
</li>
<li><p class="first">The <span class="sc">Arlet6502</span> is taken from <a class="reference external" href="https://github.com/Arlet/verilog-6502">Arlet's MOS 6502 core</a> and is routed using the
four metal symbolic technology (so the router has three availables).</p>
</li>
<li><p class="first">Three cell libraries.</p>
<p>All thoses libraries are for use with <span class="sc">mosis</span> and <span class="sc">FreePDK45</span> technologies.
We provides them as part of the toolkit as we are still in the process of validating
that technology, and we may have to perform quick fixes on them. The design are
configured to use them instead of those supplied by the <span class="sc">Alliance</span> installation.</p>
<ol class="arabic simple">
<li><tt class="docutils literal">nsxlib</tt> : Standard Cell library, compliant with <span class="sc">mosis</span>.</li>
<li><tt class="docutils literal">mpxlib</tt> : Pad library, compliant with <span class="sc">Coriolis</span>.</li>
<li><tt class="docutils literal">msplib</tt> : Pad library, compliant with <span class="sc">Alliance</span> / <tt class="docutils literal">ring</tt>. Cells in this
library are <em>wrappers</em> around their counterpart in <tt class="docutils literal">mpxlib</tt>, they provides
an outer layout shell that is usable by <tt class="docutils literal">ring</tt>.</li>
</ol>
</li>
<li><p class="first">The <span class="sc">rds</span> files for <span class="sc">mosis</span> (<tt class="docutils literal">scn6m_deep_09.rds</tt>) and <span class="sc">FreePDK45</span> technologies,
for the same reason as the cell libraries.</p>
</li>
<li><p class="first">Miscellenous helper scripts.</p>
</li>
</ul>
</div>
<div class="section" id="toolkit-layout">
<h2><a class="toc-backref" href="#id7">Toolkit Layout</a></h2>
<p>The files are organized as follow :</p>
<table class="table">
<colgroup>
<col width="44%" />
<col width="56%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Directory</th>
<th class="head">Contents</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">./etc/</tt></td>
<td>Configuration files</td>
</tr>
<tr><td><tt class="docutils literal">./etc/mk/</tt></td>
<td>Makefiles rules to build benchmarks. This directory
must be symbolic linked into each benchmark directory</td>
</tr>
<tr><td><tt class="docutils literal">./etc/mk/users.d/</tt></td>
<td>Directory holding the configuration for each user</td>
</tr>
<tr><td><tt class="docutils literal">./bin/</tt></td>
<td>Additionnal scripts</td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">./cells/&lt;LIBDIR&gt;</span></tt></td>
<td>Standard cells libraries.</td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">./benchs/&lt;BENCH&gt;/&lt;techno&gt;/</span></tt></td>
<td>Benchmark directories</td>
</tr>
<tr><td><tt class="docutils literal">./doc/</tt></td>
<td>This documentation directory</td>
</tr>
</tbody>
</table>
<p></p>
</div>
<div class="section" id="benchmark-makefiles">
<h2><a class="toc-backref" href="#id8">Benchmark Makefiles</a></h2>
<p>A benchmark <span class="cb">Makefile</span> is build by setting up variables <tt class="docutils literal"><span class="pre">USE_&lt;FEATURE&gt;=Yes/No</span></tt>
then including the set of rules <tt class="docutils literal"><span class="pre">./mk/design-flow.mk</span></tt>. The directory
<tt class="docutils literal"><span class="pre">alliance-check-toolkit/etc/mk/</span></tt> must be symlinked in the directory where the
<span class="cb">Makefile</span> resides.</p>
<p>The <span class="cb">Makefile</span> provides some or all of the following targets. If the place
and route stage of a benchmark has multiple target technology, one directory
is created for each.</p>
<table class="table">
<colgroup>
<col width="14%" />
<col width="22%" />
<col width="64%" />
</colgroup>
<tbody valign="top">
<tr><td rowspan="9"><span class="sc">Coriolis</span></td>
<td><tt class="docutils literal">blif</tt></td>
<td>Synthetize the netlist with <tt class="docutils literal">Yosys</tt>.</td>
</tr>
<tr><td><em>layout</em></td>
<td>The complete symbolic layout of the design (P&amp;R).</td>
</tr>
<tr><td><tt class="docutils literal">gds</tt></td>
<td>Generate the real layout (<span class="sc">gdsii</span>)</td>
</tr>
<tr><td><tt class="docutils literal">druc</tt></td>
<td>Symbolic layout checking</td>
</tr>
<tr><td><tt class="docutils literal">lvx</tt></td>
<td>Perform <span class="sc">lvs</span>.</td>
</tr>
<tr><td><tt class="docutils literal">graal</tt></td>
<td>Launch <tt class="docutils literal">graal</tt> in the <span class="cb">Makefile</span> 's environement</td>
</tr>
<tr><td><tt class="docutils literal">dreal</tt></td>
<td>Launch <tt class="docutils literal">dreal</tt> in the <span class="cb">Makefile</span> 's environement, and load
the <tt class="docutils literal">gds</tt> file of the design.</td>
</tr>
<tr><td><tt class="docutils literal">view</tt></td>
<td>Launch <span class="cb">cgt</span> and load the design (chip)</td>
</tr>
<tr><td><span class="cb">cgt</span></td>
<td>Launch <span class="cb">cgt</span> in the <span class="cb">Makefile</span> 's environement</td>
</tr>
</tbody>
</table>
<p>A top <span class="cb">Makefile</span> in a bench directory must looks like:</p>
<div class="highlight"><pre><span></span> <span class="nv">LOGICAL_SYNTHESIS</span> <span class="o">=</span> Yosys
<span class="nv">PHYSICAL_SYNTHESIS</span> <span class="o">=</span> Coriolis
<span class="nv">DESIGN_KIT</span> <span class="o">=</span> nsxlib45
<span class="nv">USE_CLOCKTREE</span> <span class="o">=</span> No
<span class="nv">USE_DEBUG</span> <span class="o">=</span> No
<span class="nv">USE_KITE</span> <span class="o">=</span> No
<span class="nv">NETLISTS</span> <span class="o">=</span> VexRiscv
<span class="cp"> include ./mk/design-flow.mk</span>
<span class="nf">blif</span><span class="o">:</span> <span class="n">VexRiscv</span>.<span class="n">blif</span>
<span class="nf">layout</span><span class="o">:</span> <span class="n">vexriscv_r</span>.<span class="n">ap</span>
<span class="nf">gds</span><span class="o">:</span> <span class="n">vexriscv_r</span>.<span class="n">gds</span>
<span class="nf">lvx</span><span class="o">:</span> <span class="n">lvx</span>-<span class="n">vst</span>-<span class="n">vexriscv</span>
<span class="nf">drc</span><span class="o">:</span> <span class="n">druc</span>-<span class="n">vexriscv_r</span>
</pre></div>
<p></p>
<p>Where variables have the following meaning:</p>
<table class="table">
<colgroup>
<col width="30%" />
<col width="70%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Variable</th>
<th class="head">Usage</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">LOGICAL_SYNTHESIS</tt></td>
<td>Tells what synthesis tool to use between <tt class="docutils literal">Alliance</tt> or
<tt class="docutils literal">Yosys</tt>. Netlists must be pre-generated if this variable
is empty or not present</td>
</tr>
<tr><td><tt class="docutils literal">PHYSICAL_SYNTHESIS</tt></td>
<td>Tells what place &amp; route tools to use between <tt class="docutils literal">Alliance</tt>
(i.e. <tt class="docutils literal">ocp</tt>, <tt class="docutils literal">nero</tt> &amp; <tt class="docutils literal">ring</tt>) and <tt class="docutils literal">Coriolis</tt></td>
</tr>
<tr><td><tt class="docutils literal">DESIGN_KIT</tt></td>
<td>The target technology and the standard cell libraries to
use, for the supported values see below.</td>
</tr>
<tr><td><tt class="docutils literal">NETLISTS</tt></td>
<td>The list of <em>netlists</em> that are requireds to perform the
place and route stage. See the complete explanation below</td>
</tr>
<tr><td><tt class="docutils literal">VST_FLAGS</tt></td>
<td>Flags to be passed to the tools driving <span class="cb">vst</span> files.
Due to some non-standard syntax in the <span class="sc">Alliance</span> format,
if you have a hierarchical design, please set it to
<tt class="docutils literal"><span class="pre">--vst-use-concat</span></tt></td>
</tr>
<tr><td><tt class="docutils literal">USE_CLOCKTREE</tt></td>
<td>Adds a clock-tree to the design (<span class="sc">Coriolis</span>)</td>
</tr>
<tr><td><tt class="docutils literal">USE_DEBUG</tt></td>
<td>Use the debugger enabled version of <span class="cb">cgt</span></td>
</tr>
<tr><td><tt class="docutils literal">USE_KITE</tt></td>
<td>Use the old <span class="sc">Kite</span> (digital only) router</td>
</tr>
</tbody>
</table>
<p>Detailed semantic of the <tt class="docutils literal">NETLISTS</tt> variable:</p>
<ul class="simple">
<li>Netlists name must be given without file extensions. Those are guessed according
to the selected synthesis tool.</li>
<li>According to the value of <tt class="docutils literal">LOGICAL_SYNTHESIS</tt> they are user supplied or generated.
In the later case, be aware that calling the <tt class="docutils literal">clean</tt> target will remove
the generated files.</li>
<li>In case the logical synthesis stage is needed, the file holding the behavioral
description is the <em>first</em> of the item list. In certain contexts, it will also be
considered as the chip's core.</li>
<li>If the behavioral description is hierarchical, each sub model must be added to
the <tt class="docutils literal">NETLISTS</tt> variable (<em>after</em> the top level one). In case of <span class="sc">Yosys</span>
synthesis, <tt class="docutils literal">blif2vst.py</tt> will generate a <span class="cb">vst</span> file for each model of the
hierarchy. We add them to the list so a <tt class="docutils literal">make clean</tt> will remove not only
the top level <span class="cb">vst</span> (and associated <span class="cb">ap</span> after placement), but the whole
hierarchy.</li>
</ul>
<p>A slightly more complex example is below. The behavioral description that will
be synthetised must be in <tt class="docutils literal">alu_hier</tt> (in fact <tt class="docutils literal">alu_hier.il</tt> or <tt class="docutils literal">alu_hier.v</tt>
as we are using <span class="sc">Yosys</span>). Two sub-model are generated by the synthesis, <tt class="docutils literal">add</tt>
and <tt class="docutils literal">sub</tt>, so we add them in tail of the <tt class="docutils literal">NETLISTS</tt> variable.</p>
<div class="highlight"><pre><span></span> <span class="nv">LOGICAL_SYNTHESIS</span> <span class="o">=</span> Yosys
<span class="nv">PHYSICAL_SYNTHESIS</span> <span class="o">=</span> Coriolis
<span class="nv">DESIGN_KIT</span> <span class="o">=</span> nsxlib
<span class="nv">YOSYS_FLATTEN</span> <span class="o">=</span> No
<span class="nv">VST_FLAGS</span> <span class="o">=</span> --vst-use-concat
<span class="nv">USE_CLOCKTREE</span> <span class="o">=</span> No
<span class="nv">USE_DEBUG</span> <span class="o">=</span> No
<span class="nv">USE_KITE</span> <span class="o">=</span> No
<span class="nv">NETLISTS</span> <span class="o">=</span> alu_hier <span class="se">\</span>
add <span class="se">\</span>
sub
include ./mk/design-flow.mk
blif: alu_hier.blif
vst: alu_hier.vst
layout: alu_hier_r.ap
gds: alu_hier_r.gds
lvx: lvx-alu_hier_r
druc: druc-alu_hier_r
view: cgt-alu_hier_r
graal: graal-alu_hier_r
</pre></div>
<p>Availables design kits (to set <tt class="docutils literal">DESIGN_KIT</tt>):</p>
<table class="table">
<colgroup>
<col width="30%" />
<col width="70%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Value</th>
<th class="head">Design kit</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">sxlib</tt></td>
<td>The default <span class="sc">Alliance</span> symbolic technology. Use the
<tt class="docutils literal">sxlib</tt> and <tt class="docutils literal">pxlib</tt> libraries.</td>
</tr>
<tr><td><tt class="docutils literal">nsxlib</tt></td>
<td>Symbolic technology fitted for <span class="sc">mosis</span> 180nm, 6 metal
layers <span class="sc">scn6m_deep</span></td>
</tr>
<tr><td><tt class="docutils literal">nsxlib45</tt></td>
<td>The symbolic technology fitted for 180nm and below.
Used for <span class="sc">FreePDK45</span> in symbolic mode.</td>
</tr>
<tr><td><tt class="docutils literal">FreePDK_45</tt></td>
<td>Direct use of the real technology <span class="sc">FreePDK45</span>.</td>
</tr>
<tr><td><tt class="docutils literal">c35b4</tt></td>
<td>AMS 350nm c35b4 real technology.</td>
</tr>
</tbody>
</table>
<p></p>
</div>
<div class="section" id="setting-up-the-user-s-environement">
<h2><a class="toc-backref" href="#id9">Setting Up the User's Environement</a></h2>
<p>Before running the benchmarks, you must create a configuration file to tell
where all the softwares are installeds. The file is to be created in the directory:</p>
<pre class="literal-block">
alliance-check-toolkit/etc/mk/users.d/
</pre>
<p>The file itself must be named from your username, if mine is <tt class="docutils literal">jpc</tt>:</p>
<pre class="literal-block">
alliance-check-toolkit/etc/mk/users.d/user-jpc.mk
</pre>
<p>Example of file contents:</p>
<div class="highlight"><pre><span></span><span class="c"># Where Jean-Paul Chaput gets his tools installeds.</span>
<span class="k">export </span><span class="nv">NDA_TOP</span> <span class="o">=</span> <span class="si">${</span><span class="nv">HOME</span><span class="si">}</span>/crypted/soc/techno
<span class="k">export </span><span class="nv">AMS_C35B4</span> <span class="o">=</span> <span class="si">${</span><span class="nv">NDA_TOP</span><span class="si">}</span>/AMS/035hv-4.10
<span class="k">export </span><span class="nv">FreePDK_45</span> <span class="o">=</span> <span class="si">${</span><span class="nv">HOME</span><span class="si">}</span>/coriolis-2.x/work/DKs/FreePDK45
<span class="k">export </span><span class="nv">CORIOLIS_TOP</span> <span class="o">=</span> <span class="k">$(</span>HOME<span class="k">)</span>/coriolis-2.x/<span class="k">$(</span>BUILD_VARIANT<span class="k">)$(</span>LIB_SUFFIX_<span class="k">)</span>/<span class="k">$(</span>BUILD_TYPE_DIR<span class="k">)</span>/install
<span class="k">export </span><span class="nv">ALLIANCE_TOP</span> <span class="o">=</span> <span class="k">$(</span>HOME<span class="k">)</span>/alliance/<span class="k">$(</span>BUILD_VARIANT<span class="k">)$(</span>LIB_SUFFIX_<span class="k">)</span>/install
<span class="k">export </span><span class="nv">CHECK_TOOLKIT</span> <span class="o">=</span> <span class="k">$(</span>HOME<span class="k">)</span>/coriolis-2.x/src/alliance-check-toolkit
<span class="k">export </span><span class="nv">AVERTEC_TOP</span> <span class="o">=</span> /dsk/l1/tasyag/Linux.el7_64/install
<span class="k">export </span><span class="nv">YOSYS_TOP</span> <span class="o">=</span> /usr
</pre></div>
<p>All the variable names and values are more or less self explanatory...</p>
<div class="section" id="coriolis-configuration-files">
<h3><span class="sc">Coriolis</span> Configuration Files</h3>
<p>Unlike <span class="sc">Alliance</span> which is entirely configured through environement variables
or system-wide configuration file, <span class="sc">Coriolis</span> uses configuration files in
the current directory. They are present for each bench:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">&lt;cwd&gt;/coriolis2/__init__.py</span></tt> : Just to tell <span class="sc">Python</span> that this directory
contains a module and be able to <em>import</em> it.</li>
<li><tt class="docutils literal"><span class="pre">&lt;cwd&gt;/coriolis2/settings.py</span></tt> : Override system configuration, and setup
technology.</li>
</ul>
</div>
<div class="section" id="coriolis-and-clock-tree-generation">
<h3><span class="sc">Coriolis</span> and Clock Tree Generation</h3>
<p>When <span class="sc">Coriolis</span> is used, it create a clock tree which modificate the original
netlist. The new netlist, with a clock tree, has a postfix of <tt class="docutils literal">_clocked</tt>.</p>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last"><strong>Trans-hierarchical Clock-Tree.</strong> As <span class="sc">Coriolis</span> do not flatten the
designs it creates, not only the top-level netlist is modificated. All the
sub-blocks connected to the master clock are also duplicateds, whith the
relevant part of the clock-tree included.</p>
</div>
</div>
<div class="section" id="rhel6-and-clones">
<h3><span class="sc">rhel6</span> and Clones</h3>
<p>Under <span class="sc">rhel6</span> the developpement version of <span class="sc">Coriolis</span> needs the <tt class="docutils literal"><span class="pre">devtoolset-2</span></tt>.
<tt class="docutils literal">os.mk</tt> tries, based on <tt class="docutils literal">uname</tt> to switch it on or off.</p>
<p></p>
</div>
<div class="section" id="yosys-wrapper-script-yosys-py">
<h3>Yosys Wrapper Script <tt class="docutils literal">yosys.py</tt></h3>
<p>As far as I understand, <tt class="docutils literal">yosys</tt> do not allow it's scripts to be parametriseds.
The <tt class="docutils literal">yosys.py</tt> script is a simple wrapper around <tt class="docutils literal">yosys</tt> that generate a
custom tailored <span class="sc">tcl</span> script then call <tt class="docutils literal">yosys</tt> itself. It can manage two
input file formats, <span class="sc">Verilog</span> and <span class="sc">rtlil</span> and produce a <tt class="docutils literal">blif</tt> netlist.</p>
<div class="highlight"><pre><span></span>ego@home:VexRiscv/cmos350$ ../../../bin/yosys.py <span class="se">\</span>
--input-lang<span class="o">=</span>Verilog <span class="se">\</span>
--design<span class="o">=</span>VexRiscv <span class="se">\</span>
--top<span class="o">=</span>VexRiscv <span class="se">\</span>
--liberty<span class="o">=</span>../../../cells/nsxlib/nsxlib.lib
</pre></div>
<p>Here is an example of generated <span class="sc">tcl</span> script: <tt class="docutils literal">VexRiscv.ys</tt>:</p>
<div class="highlight"><pre><span></span><span class="k">set</span> verilog_file VexRiscv.v
<span class="k">set</span> verilog_top VexRiscv
<span class="k">set</span> liberty_file ...<span class="o">/</span>alliance-check-toolkit<span class="o">/</span>cells<span class="o">/</span>nsxlib<span class="o">/</span>nsxlib.lib
<span class="nv">yosys</span> read_verilog <span class="nv">$verilog_file</span>
<span class="nv">yosys</span> hierarchy <span class="o">-</span>check <span class="o">-</span>top <span class="nv">$verilog_top</span>
<span class="nv">yosys</span> synth <span class="o">-</span>top <span class="nv">$verilog_top</span>
<span class="nv">yosys</span> dfflibmap <span class="o">-</span>liberty <span class="nv">$liberty_file</span>
<span class="nv">yosys</span> abc <span class="o">-</span>liberty <span class="nv">$liberty_file</span>
<span class="nv">yosys</span> clean
<span class="nv">yosys</span> write_blif VexRiscv.blif
</pre></div>
</div>
</div>
<div class="section" id="benchmarks-special-notes">
<h2><a class="toc-backref" href="#id10">Benchmarks Special Notes</a></h2>
<div class="section" id="alliance-run">
<h3><tt class="docutils literal"><span class="pre">alliance-run</span></tt></h3>
<p>This benchmark comes mostly with it's own rules and do not uses the ones supplieds
by <tt class="docutils literal">rules.mk</tt>. It uses only the top-level configuration variables.</p>
<p>It a sligtly modified copy of the <tt class="docutils literal"><span class="pre">alliance-run</span></tt> found in the <span class="sc">Alliance</span> package
(modification are all in the <span class="cb">Makefile</span>). It build an <span class="sc">am2901</span>, but it is
splitted in a control and an operative part (data-path). This is to also check
the data-path features of <span class="sc">Alliance</span>.</p>
<p>And lastly, it provides a check for the <span class="sc">Coriolis</span> encapsulation of <span class="sc">Alliance</span>
through <span class="sc">Python</span> wrappers. The support is still incomplete and should be used
only by very experienced users. See the <tt class="docutils literal">demo*</tt> rules.</p>
</div>
<div class="section" id="am2901-standard-cells">
<h3><span class="sc">am2901</span> standard cells</h3>
<p>This benchmark can be run in loop to check slight variations. The clock tree generator
modify the netlist trans-hierarchically then saves the new netlist. But, when there's
a block <em>without</em> a clock (say an <span class="sc">alu</span> for instance) it is not modificated yet saved.
So the <tt class="docutils literal">vst</tt> file got rewritten. And while the netlist is rewritten
in a deterministic way (from how it was parsed), it is <em>not</em> done the same way due
to instance and terminal re-ordering. So, from run to run, we get identical netlists
but different files inducing slight variations in how the design is placed and routed.
We use this <em>defect</em> to generate deterministic series of random variation that helps
check the router. All runs are saved in a <tt class="docutils literal">./runs</tt> sub-directory.</p>
<p>The script to perform a serie of run is <tt class="docutils literal">./doRun.sh</tt>.</p>
<p>To reset the serie to a specific run (for debug), you may use <tt class="docutils literal">./setRun.sh</tt>.</p>
<p></p>
</div>
</div>
<div class="section" id="libraries-makefiles">
<h2><a class="toc-backref" href="#id11">Libraries Makefiles</a></h2>
<div class="note">
<p class="first admonition-title">Note</p>
<p>For those part to work, you need to get <tt class="docutils literal">hitas</tt> &amp; <tt class="docutils literal">yagle</tt>:</p>
<blockquote class="last">
<a class="reference external" href="https://soc-extras.lip6.fr/en/tasyag-abstract-en/">HiTas -- Static Timing Analyser</a></blockquote>
</div>
<p>The <tt class="docutils literal"><span class="pre">bench/etc/mk/check-library.mk</span></tt> provides rules to perform the check of a library
as a whole or cell by cell. To avoid too much clutter in the library directory,
all the intermediate files generated by the verification tools are kept in a
<tt class="docutils literal">./check/</tt> subdirectory. Once a cell has been validated, a <tt class="docutils literal"><span class="pre">./check/&lt;cell&gt;.ok</span></tt>
is generated too prevent it to be checked again in subsequent run. If you
want to force the recheck of the cell, do not forget to remove this file.</p>
<div class="section" id="checking-procedure">
<h3>Checking Procedure</h3>
<ul class="simple">
<li>DRC with <tt class="docutils literal">druc</tt>.</li>
<li>Formal proof between the layout and the behavioral description. This is a
somewhat long chain of tools:<ol class="arabic">
<li><tt class="docutils literal">cougar</tt>, extract the spice netlist (<tt class="docutils literal">.spi</tt>).</li>
<li><tt class="docutils literal">yagle</tt>, rebuild a behavioral description (<tt class="docutils literal">.vhd</tt>) from the spice
netlist.</li>
<li><tt class="docutils literal">vasy</tt>, convert the <tt class="docutils literal">.vhd</tt> into a <tt class="docutils literal">.vbe</tt> (Alliance <span class="sc">vhdl</span> subset
for behavioral descriptions).</li>
<li><tt class="docutils literal">proof</tt>, perform the formal proof between the refence <tt class="docutils literal">.vbe</tt> and the
extracted one.</li>
</ol>
</li>
</ul>
<table class="table">
<colgroup>
<col width="33%" />
<col width="67%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Rule or File</th>
<th class="head">Action</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal"><span class="pre">check-lib</span></tt></td>
<td>Validate every cell of the library</td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">clean-lib-tmp</span></tt></td>
<td>Remove all intermediate files in the <tt class="docutils literal">./check</tt>
subdirectory <strong>except</strong> for the <tt class="docutils literal">*.ok</tt> ones.
That is, cells validated will not be rechecked.</td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">clean-lib</span></tt></td>
<td>Remove all files in <tt class="docutils literal">./check</tt>, including <tt class="docutils literal">*.ok</tt></td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">./check/&lt;cell&gt;.ok</span></tt></td>
<td>Use this rule to perform the individual check of
<tt class="docutils literal">&lt;cell&gt;</tt>. If the cell is validated, a file of
the same name will be created, preventing the cell
to be checked again.</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="synopsys-liberty-lib-generation">
<h3>Synopsys Liberty .lib Generation</h3>
<p>The generation of the liberty file is only half-automated. <tt class="docutils literal">hitas</tt> / <tt class="docutils literal">yagle</tt>
build the base file, then we manually perform the two modifications (see below).</p>
<p>The rule to call to generate the liberty file is: <tt class="docutils literal"><span class="pre">&lt;libname&gt;-dot-lib</span></tt> where
<tt class="docutils literal">&lt;libname&gt;</tt> is the name of the library. To avoid erasing the previous one (and
presumably hand patched), this rule create a <tt class="docutils literal"><span class="pre">&lt;libname&gt;.lib.new</span></tt>.</p>
<ol class="arabic">
<li><p class="first">Run the <tt class="docutils literal">./bin/cellsArea.py</tt> script which will setup the areas of the cells
(in square um). Work on <tt class="docutils literal"><span class="pre">&lt;libname&gt;.lib.new</span></tt>.</p>
</li>
<li><p class="first">For the synchronous flip-flop, add the functional description to their
timing descriptions:</p>
<pre class="literal-block">
cell (sff1_x4) {
pin (ck) {
direction : input ;
clock : true ;
/* Timing informations ... */
}
pin (q) {
direction : output ;
function : &quot;IQ&quot; ;
/* Timing informations ... */
}
ff(IQ,IQN) {
next_state : &quot;i&quot; ;
clocked_on : &quot;ck&quot; ;
}
}
cell (sff2_x4) {
pin (ck) {
direction : input ;
clock : true ;
/* Timing informations ... */
}
pin (q) {
direction : output ;
function : &quot;IQ&quot; ;
/* Timing informations ... */
}
ff(IQ,IQN) {
next_state : &quot;(cmd * i1) + (cmd' * i0)&quot; ;
clocked_on : &quot;ck&quot; ;
}
}
</pre>
</li>
</ol>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">The tristate cells <strong>ts_</strong> and <strong>nts_</strong> are not included in the <tt class="docutils literal">.lib</tt>.</p>
</div>
</div>
<div class="section" id="helpers-scripts">
<h3>Helpers Scripts</h3>
<p><span class="sc">tcl</span> scripts for <tt class="docutils literal">avt_shell</tt> related to cell validation and characterization,
in <tt class="docutils literal">./benchs/bin</tt>, are:</p>
<ul class="simple">
<li><tt class="docutils literal">extractCell.tcl</tt>, read a spice file and generate a <span class="sc">vhdl</span> behavioral
description (using <tt class="docutils literal">yagle</tt>). This file needs to be processed further by
<tt class="docutils literal">vasy</tt> to become an Alliance behavioral file (<tt class="docutils literal">vbe</tt>). It takes two
arguments: the technology file and the cell spice file.
Cell which name starts by <tt class="docutils literal">sff</tt> will be treated as D flip-flop.</li>
<li><tt class="docutils literal">buildLib.tcl</tt>, process all cells in a directory to buil a liberty
file. Takes two arguments, the technology file and the name of the
liberty file to generate. The collection of characterized cells will
be determined by the <tt class="docutils literal">.spi</tt> files found in the current directory.</li>
</ul>
</div>
</div>
<div class="section" id="macro-blocks-makefiles">
<h2><a class="toc-backref" href="#id12">Macro-Blocks Makefiles</a></h2>
<p>The <tt class="docutils literal"><span class="pre">bench/etc/mk/check-generator.mk</span></tt> provides rules to perform the check of a
macro block generator. As one library cell may be used to build multiple macro-blocks,
one <span class="cb">Makefile</span> per macro must be provided. The <em>dot</em> extension of a <span class="cb">Makefile</span> is
expected to be the name of the macro-block. Here is a small example for the register
file generator, <tt class="docutils literal">Makefile.block_rf2</tt>:</p>
<div class="highlight"><pre><span></span> <span class="nv">TK_RTOP</span> <span class="o">=</span> ../..
<span class="nb">export</span> <span class="nv">MBK_CATA_LIB</span> <span class="o">=</span> <span class="k">$(</span>TOOLKIT_CELLS_TOP<span class="k">)</span>/nrf2lib
<span class="cp"> include $(TK_RTOP)/etc/mk/alliance.mk</span>
<span class="cp"> include $(TK_RTOP)/etc/mk/mosis.mk</span>
<span class="cp"> include $(TK_RTOP)/etc/mk/check-generator.mk</span>
<span class="nf">check-gen</span><span class="o">:</span> ./<span class="n">check</span>/<span class="n">block_rf</span>2<span class="n">_p_b_</span>4<span class="n">_p_w_</span>6.<span class="n">ok</span> \
./<span class="n">check</span>/<span class="n">block_rf</span>2<span class="n">_p_b_</span>2<span class="n">_p_w_</span>32.<span class="n">ok</span> \
./<span class="n">check</span>/<span class="n">block_rf</span>2<span class="n">_p_b_</span>64<span class="n">_p_w_</span>6.<span class="n">ok</span> \
./<span class="n">check</span>/<span class="n">block_rf</span>2<span class="n">_p_b_</span>16<span class="n">_p_w_</span>32.<span class="n">ok</span> \
./<span class="n">check</span>/<span class="n">block_rf</span>2<span class="n">_p_b_</span>32<span class="n">_p_w_</span>32.<span class="n">ok</span>
</pre></div>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">In the <tt class="docutils literal"><span class="pre">check-gen</span></tt> rule, the name of the block <strong>must</strong> match the <em>dot</em>
extension of the <span class="cb">Makefile</span>, here: <tt class="docutils literal">block_rf2</tt>.</p>
</div>
<p>Macro-block generators are parametrized. We uses a special naming convention
to pass parameters names and values trough the rule name. To declare a parameter,
add <tt class="docutils literal">_p_</tt>, then the name of the parameter and it's value separated by a <tt class="docutils literal">_</tt>.</p>
<table class="table">
<colgroup>
<col width="46%" />
<col width="54%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">String in Rule Name</th>
<th class="head">Call to the generator</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">_p_b_16_p_w_32</tt></td>
<td><tt class="docutils literal"><span class="pre">-b</span> 16 <span class="pre">-w</span> 32</tt></td>
</tr>
</tbody>
</table>
<p>When multiple flavor of a generator could be built upon the same cell library,
one <span class="cb">Makefile</span> per flavor is provided. To run them all at once, a <tt class="docutils literal">makeAll.sh</tt>
script is also available.</p>
<p>The <tt class="docutils literal"><span class="pre">check-gen</span></tt> rule only perform a <span class="sc">drc</span> and a <span class="sc">lvs</span> to check that their
router as correctly connected the cells of a macro-block. It doesn't perform
any functional verification.</p>
<p>To perform a functional abstraction with <tt class="docutils literal">yagle</tt> you may use the following
command:</p>
<pre class="literal-block">
ego&#64;home:nrf2lib&gt; make -f Makefile.block_rf2 block_rf2_b_4_p_w_6_kite.vhd
</pre>
<p>Even if the resulting <span class="sc">vhdl</span> cannot be used it is always good to look in
the report file <tt class="docutils literal">block_rf2_b_4_p_w_6_kite.rep</tt> for any error or warning,
particularly any disconnected transistor.</p>
<div class="section" id="calling-the-generator">
<h3>Calling the Generator</h3>
<p>A script <tt class="docutils literal">./check/generator.py</tt> must be written in order to call the generator
in standalone mode. This script is quite straigthforward, what changes between
generators is the command line options and the <tt class="docutils literal">stratus.buildModel()</tt> call.</p>
<p>After the generator call, we get a netlist and placement, but it is not finished
until it is routed with the <span class="sc">Coriolis</span> router.</p>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">Currently all macro-block generators are part of the <span class="sc">Stratus</span> netlist capture
language tool from <span class="sc">Coriolis</span>.</p>
</div>
</div>
<div class="section" id="scaling-the-cell-library">
<h3>Scaling the Cell Library</h3>
<p>This operation has to be done once, when the cell library is initially ported.
The result is put in the <span class="cb">git</span> repository, so there's no need to run it again
on a provided library.</p>
<p>The script is <tt class="docutils literal">./check/scaleCell.py</tt>. It is very sensitive on the way
the library pathes are set in <tt class="docutils literal">.coriolis2/settings.py</tt>. It must have the
target cell library setup as the <tt class="docutils literal">WORKING_LIBRARY</tt> and the source cell
library in the <tt class="docutils literal">SYSTEM_LIBRARY</tt>. The technology must be set to the target
one. And, of course, the script must be run the directory where <tt class="docutils literal">.coriolis2/</tt>
is located.</p>
<p>The heart of the script is the <tt class="docutils literal">scaleCell()</tt> function, which work on the
original cell in variable <tt class="docutils literal">sourceCell</tt> (argument) and <tt class="docutils literal">scaledCell</tt>, the
converted one. Although the script is configured to use the <em>scaled</em>
technology, this do not affect the values of the coordinates of the cells
we read, whatever their origin. This means that when we read the <tt class="docutils literal">sourceCell</tt>,
the coordinates of it's components keeps the value they have under <tt class="docutils literal">SxLib</tt>.
It is <em>when</em> we duplicate them into the <tt class="docutils literal">scaledCell</tt> that we perform the
scaling (i.e. multiply by two) and do whatever adjustments we need.
So when we have an adjustment to do on a specific segment, say slihgtly shift
a <tt class="docutils literal">NDIF</tt>, the coordinates must be expressed as in <tt class="docutils literal">SxLib</tt> (once more: <em>before</em>
scaling).</p>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">There is a safety in <tt class="docutils literal">./check/scaleCell.py</tt>, it will not run until the
target library has not been emptied of it's cells.</p>
</div>
<p>The script contains a <tt class="docutils literal">getDeltas()</tt> function which provide a table on how
to resize some layers (width and extension).</p>
<p>As the scaling operations is very specific to each macro-block, this script
is <em>not</em> shared, but customized for each one.</p>
</div>
</div>
<div class="section" id="tools-scripts">
<h2><a class="toc-backref" href="#id13">Tools &amp; Scripts</a></h2>
<div class="section" id="one-script-to-run-them-all-go">
<span id="go-sh"></span><h3>One script to run them all: <tt class="docutils literal">go.sh</tt></h3>
<p>To call all the bench's <tt class="docutils literal">Makefile</tt> sequentially and execute one or more rules on
each, the small script utility <tt class="docutils literal">go.sh</tt> is available. Here are some examples:</p>
<pre class="literal-block">
ego&#64;home:bench$ ./bin/go.sh clean
ego&#64;home:bench$ ./bin/go.sh lvx
</pre>
</div>
<div class="section" id="command-line-cgt-dochip">
<h3>Command Line <span class="cb">cgt</span>: <tt class="docutils literal">doChip.py</tt></h3>
<p>As a alternative to <span class="cb">cgt</span>, the small helper script <tt class="docutils literal">doChip.py</tt> allows to
perform all the P&amp;R tasks, on an stand-alone block or a whole chip.</p>
</div>
<div class="section" id="blif-netlist-converter">
<h3>Blif Netlist Converter</h3>
<p>The <tt class="docutils literal">blif2vst.py</tt> script convert a <tt class="docutils literal">.blif</tt> netlist into an <span class="sc">Alliance</span> one
(<span class="cb">vst</span>). This is a very straightforward encapsulation of <span class="sc">Coriolis</span>.
It could have been included in <tt class="docutils literal">doChip.py</tt>, but then the <tt class="docutils literal">make</tt> rules
would have been much more complicateds.</p>
</div>
<div class="section" id="pad-layout-converter-px2mpx">
<h3>Pad Layout Converter <tt class="docutils literal">px2mpx.py</tt></h3>
<p>The <tt class="docutils literal">px2mpx.py</tt> script convert pad layout from the <tt class="docutils literal">pxlib</tt> (<span class="sc">Alliance</span> dummy
technology) into <tt class="docutils literal">mpxlib</tt> (<span class="sc">mosis</span> compliant symbolic technology).</p>
<p>Basically it multiplies all the coordinate by two as the source technology
is 1µ type and the target one a 2µ. In addition it performs some adjustement
on the wire extension and minimal width and the blockage sizes.</p>
<p>As it is a one time script, it is heavily hardwired, so before using it
do not forget to edit it to suit your needs.</p>
<p>The whole conversion process is quite tricky as we are cheating with the
normal use of the software. The steps are as follow:</p>
<ol class="arabic simple">
<li>Using the <span class="sc">Alliance</span> dummy technology and in an empty directory, run
the script. The layouts of the converted pads (<tt class="docutils literal">*_mpx.ap</tt>) will be
created.</li>
<li>In a second directory, this time configured for the <span class="sc">mosis</span> technology
(see <tt class="docutils literal">.coriolis2_techno.conf</tt>) copy the converted layouts. In addition
to the layouts, this directory <strong>must also contain</strong> the behavioral
description of the pads (<tt class="docutils literal">.vbe</tt>). Otherwise, you will not be able to
see the proper layout.</li>
<li>When you are satisfied with the new layout of the pads, you can copy
them back in the official pad cell library.</li>
</ol>
<div class="note">
<p class="first admonition-title">Note</p>
<p><strong>How Coriolis Load Cells.</strong>
Unlike in <span class="sc">Alliance</span>, <span class="sc">Coriolis</span> maintain a much tighter relationship
between physical and logical (structural or behavioral) views. The
loading process of a cell try <em>first</em> to load the logical view, and
if found, keep tab of the directory it was in. <em>Second</em> it tries to
load the physical view from the same directory the logical view was
in. If no logical view is found, only the physical is loaded.</p>
<p>Conversely, when saving a cell, the directory it was loaded from
is kept, so that the cell will be overwritten, and not duplicated
in the working directory as it was in <span class="sc">Alliance</span>.</p>
<p class="last">This explains why the behavioral view of the pad is needed in
the directory the layouts are put into. Otherwise you would only see
the pads of the system library (if any).</p>
</div>
</div>
</div>
<div class="section" id="cadence-support">
<h2><a class="toc-backref" href="#id14"><span class="sc">Cadence</span> Support</a></h2>
<p>To perform comparisons with <span class="sc">Cadence</span> <span class="sc">edi</span> tools (i.e. <tt class="docutils literal">encounter</tt>
<span class="sc">NanoRoute</span>), some benchmarks have a sub-directory <tt class="docutils literal">encounter</tt>
holding all the necessary files. Here is an example for the design
named <tt class="docutils literal">&lt;fpga&gt;</tt>.</p>
<table class="table">
<colgroup>
<col width="36%" />
<col width="64%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head" colspan="2"><tt class="docutils literal">encounter</tt> directory</th>
</tr>
<tr><th class="head">File Name</th>
<th class="head">Contents</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">fpga_export.lef</tt></td>
<td>Technology &amp; standard cells for the design</td>
</tr>
<tr><td><tt class="docutils literal">fpga_export.def</tt></td>
<td>The design itself, flattened to the standard
cells.</td>
</tr>
<tr><td><tt class="docutils literal">fpga_nano.def</tt></td>
<td>The placed and routed result.</td>
</tr>
<tr><td><tt class="docutils literal">fpga.tcl</tt></td>
<td>The <span class="sc">tcl</span> script to be run by <tt class="docutils literal">encounter</tt></td>
</tr>
</tbody>
</table>
<p>The LEF/DEF file exported or imported by Coriolis are <em>not</em> true physical
files. They are pseudo-real, in the sense that all the dimensions are
directly taken from the symbolic with the simple rule <tt class="docutils literal">1 lambda = 1 micron</tt>.</p>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last"><strong>LEF/DEF files:</strong> Coriolis is able to import/export in those
formats only if it has been compiled against the <span class="sc">Si2</span> relevant libraries
that are subjects to specific license agreements. So in case we don't
have access to thoses we supplies the generated LEF/DEF files.</p>
</div>
<p>The <tt class="docutils literal">encounter</tt> directory contains the LEF/DEF files and the <span class="sc">tcl</span>
script to be run by <tt class="docutils literal">encounter</tt>:</p>
<pre class="literal-block">
ego&#64;home:encounter&gt; . ../../etc/EDI1324.sh
ego&#64;home:encounter&gt; encounter -init ./fpga.tcl
</pre>
<p>Example of <span class="sc">tcl</span> script for <tt class="docutils literal">encounter</tt>:</p>
<div class="highlight"><pre><span></span><span class="nv">set_global</span> _enable_mmmc_by_default_flow <span class="nv">$CTE::mmmc_default</span>
<span class="nv">suppressMessage</span> ENCEXT-2799
<span class="nv">win</span>
<span class="nv">loadLefFile</span> fpga_export.lef
<span class="nv">loadDefFile</span> fpga_export.def
<span class="nv">floorPlan</span> <span class="o">-</span>site core <span class="o">-</span>r <span class="mf">0.998676319592</span> <span class="mf">0.95</span> <span class="mf">0.0</span> <span class="mf">0.0</span> <span class="mf">0.0</span> <span class="mf">0.0</span>
<span class="nv">getIoFlowFlag</span>
<span class="nv">fit</span>
<span class="nv">setDrawView</span> place
<span class="nv">setPlaceMode</span> <span class="o">-</span>fp false
<span class="nv">placeDesign</span>
<span class="nv">generateTracks</span>
<span class="nv">generateVias</span>
<span class="nv">setNanoRouteMode</span> <span class="o">-</span>quiet <span class="o">-</span>drouteFixAntenna <span class="mi">0</span>
<span class="nv">setNanoRouteMode</span> <span class="o">-</span>quiet <span class="o">-</span>drouteStartIteration <span class="mi">0</span>
<span class="nv">setNanoRouteMode</span> <span class="o">-</span>quiet <span class="o">-</span>routeTopRoutingLayer <span class="mi">5</span>
<span class="nv">setNanoRouteMode</span> <span class="o">-</span>quiet <span class="o">-</span>routeBottomRoutingLayer <span class="mi">2</span>
<span class="nv">setNanoRouteMode</span> <span class="o">-</span>quiet <span class="o">-</span>drouteEndIteration <span class="mi">0</span>
<span class="nv">setNanoRouteMode</span> <span class="o">-</span>quiet <span class="o">-</span>routeWithTimingDriven false
<span class="nv">setNanoRouteMode</span> <span class="o">-</span>quiet <span class="o">-</span>routeWithSiDriven false
<span class="nv">routeDesign</span> <span class="o">-</span>globalDetail
<span class="k">global</span> dbgLefDefOutVersion
<span class="k">set</span> dbgLefDefOutVersion <span class="mf">5.7</span>
<span class="nv">defOut</span> <span class="o">-</span>floorplan <span class="o">-</span>netlist <span class="o">-</span>routing fpga_nano.def
</pre></div>
</div>
<div class="section" id="technologies">
<h2><a class="toc-backref" href="#id15">Technologies</a></h2>
<p>We provides configuration files for the publicly available <span class="sc">mosis</span>
technology <tt class="docutils literal">SCN6M_DEEP</tt>.</p>
<ul class="simple">
<li><tt class="docutils literal">./bench/etc/scn6m_deep_09.rds</tt>, <span class="sc">rds</span> rules for symbolic to real
transformation.</li>
<li><tt class="docutils literal">./bench/etc/scn6m_deep.hsp</tt>, transistor spice models for <tt class="docutils literal">yagle</tt>.</li>
</ul>
<p>References:</p>
<ul class="simple">
<li><a class="reference external" href="https://www.mosis.com/files/scmos/scmos.pdf">MOSIS Scalable CMOS (SCMOS)</a></li>
<li><a class="reference external" href="ftp://ftp.mosis.com/pub/mosis/vendors/tsmc-018/t92y_mm_non_epi_thk_mtl-params.txt">MOSIS Wafer Acceptance Tests</a></li>
</ul>
</div>
</div>
<!-- /Content -->
<!-- Footer -->
<div class="footer gradient-2">
<div class="container footer-container ">
<div class="row">
<div class="col-xs-4 col-sm-3 col-md-3 col-lg-3">
<div class="footer-title">Social</div>
<ul class="list-unstyled">
</ul>
</div>
<div class="col-xs-4 col-sm-3 col-md-3 col-lg-2">
</div>
<div class="col-xs-4 col-sm-3 col-md-3 col-lg-3">
<div class="footer-title">Links</div>
<ul class="list-unstyled">
<li><a href="https://coriolis.lip6.fr/" target="_blank">Alliance/Coriolis</a></li>
<li><a href="https://www-soc.lip6.fr/" target="_blank">CIAN Team Website</a></li>
<li><a href="https://f-si.org" target="_blank">Free Silicon Foundation</a></li>
</ul>
</div>
<div class="col-xs-12 col-sm-3 col-md-3 col-lg-4">
<p class="pull-right text-right">
<small><em>Proudly powered by <a href="http://docs.getpelican.com/" target="_blank">pelican</a></em></small><br/>
<small><em><span class="sc">NEST</span> theme by <a href="https://github.com/molivier" target="_blank">molivier</a></em></small><br/>
<small>Copyright © 2020-2020 Sorbonne Universite</small>
</p>
</div>
</div>
</div>
</div>
<!-- /Footer -->
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink