[Libre-soc-bugs] [Bug 951] Standard Cell based SRAM for ethmac
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Oct 17 16:29:05 BST 2022
https://bugs.libre-soc.org/show_bug.cgi?id=951
--- Comment #4 from Jean-Paul Chaput <Jean-Paul.Chaput at lip6.fr> ---
Evaluation results could be rebuild with:
* coriolis commit #9594476a
* alliance-check-toolkit commit #9eec8a0
Updated SRAM results
~~~~~~~~~~~~~~~~~~~~
Added results for the NAND2/NOR2 output multiplexer version.
All the benchs have been run using the Google/SkyWater 130nm DK, with a port
of Chips4Makers/Flexlib. The version using TSMC_C180 has also been done, but
needs access to NDA to be run outside Sorbonne Université/LIP6.
.. note:: All length are in micro-meters.
+--------+--------------+-----------------------------+-----------------------------+
| Arch | Kind | Generator | Yosys
|
+========+==============+=============================+=============================+
| Mux | # Gates | 23209 (-25.4%) | 32121
|
+--------+--------------+-----------------------------+
|
| Nao | # Gates | 34637 (+7.8%) |
|
+--------+--------------+-----------------------------+-----------------------------+
| 1 Fold
|
+--------+--------------+-----------------------------+-----------------------------+
| | Area | 7182 x 330 (-5.5%) | 7380 x 340
|
| Mux
+--------------+-----------------------------+-----------------------------+
| | Wirelength | 1841036 (-4.3%) | 1924153
|
+--------+--------------+-----------------------------+-----------------------------+
| | Area | 6680 x 340 (-14.9%) |
|
| Nao +--------------+-----------------------------+
|
| | Wirelength | 1637781 (-14.9%) |
|
+--------+--------------+-----------------------------+-----------------------------+
| 2 Fold
|
+--------+--------------+-----------------------------+-----------------------------+
| | Area | 3599 x 660 (-5.3%) | 3690 x 680
|
| Mux
+--------------+-----------------------------+-----------------------------+
| | Wirelength | 1670455 (-6.3%) | 1782558
|
+--------+--------------+-----------------------------+-----------------------------+
| | Area | 3350 x 680 (-9.2%) |
|
| Nao +--------------+-----------------------------+
|
| | Wirelength | 1548358 (-13.1%) |
|
+--------+--------------+-----------------------------+-----------------------------+
| 4 Fold
|
+--------+--------------+-----------------------------+-----------------------------+
| | Area | 1812 x 1320 (-4.6%) | 1900 x 1320
|
| Mux
+--------------+-----------------------------+-----------------------------+
| | Wirelength | 1699810 (-1.5%) | 1726436
|
+--------+--------------+-----------------------------+-----------------------------+
| | Area | 1692 x 1360 (-8.2%) |
|
| Nao +--------------+-----------------------------+
|
| | Wirelength | 1512107 (-12.4%) |
|
+--------+--------------+-----------------------------+-----------------------------+
The difference between the two implementations resides only in the *output*
multiplexer. With a 4 inputs mux made of mux2+mux3 or 2 inputs multiplexer
made of alternate layers of nand2+nor2.
Conclusions for the mux2+mux3 implementation :
1. The generator version uses subtantially less gates than the Yosys one.
As the both SRAM uses the exact same number of SFFs, the difference is
only due to the decoder for the control of input and output muxes.
2. Notwithanding having less gates the generator version uses similar areas,
which means that we use fewer but significantly *bigger* cells.
3. The FlexLib library supplied for SkyWater 130nm do not contains all
SxLib one, effectively restricting our choices.
In particular, to build the output multiplexer we only have mx2 and
mx3 cells, which are large. The density of the SRAM could be much
increased if we did have nmx2 and nmx3.
Furthermore for the output multiplexers, as it is a controlled case,
we may also uses three-state drivers cells (which have not been
ported either).
Conclusion for the nand2+nor2 implementation:
1. The multiplexer allows us for a much more compact area and noticeably
lesser wire length. With an increased number of cells (not an issue).
2. The total wire length is extremely sensitive to the placement, which
in our case is just a column ordering. To optimize, the binary tree
(for the netlist) is not placed fully symmetrically but slightly
"askew".
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list