since the bitlines alternate in the bitcell array we also need to mirror
the port_data elements.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
since the bitlines alternate in the bitcell array we also need to mirror
the port_data elements.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
this allows for bitcells that need to be mirrored on the y axis, like
thin cells. However, the portdata elements also need to be mirrored on
the y axis. Otherwise the router will fail horribly when connecting
bitlines.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
this is technology specific database to store data about the custom
design cells. For now it only contains on which axis the bitcells are
mirrored. This is a first step to support thin cells that need to be
mirrored on the x and y axis.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
this is the first step to allow engineers, porting technologies, more room
for routing their handmade cells.
For now, we don't allow the specification of power_grids where the lower layer
prefers to be routed vertically. This is due to the router not
connecting some pins properly in that case.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
this allows us to simplify add_power_pin() and gives a clean
API to create vias through multiple layers.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
a lot of functions of dummy- and bitcell-array are either copy-pasted or
have just slight differences. Merge all of those into an abstract base
class such that we don't have too much duplicate code.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
this can take considerable amount of time, so the user knows that
useful work is done.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
the hash value only depends of the properties 'rect' and 'layer' so we
only compute the hash if those values are changed. Otherwise we just
return the precomputed value. This gives us a major speedup (~10x) if
the hash is used as a key in a dict.
During the grouping of pins in analyze_pins() this gives the best
improvements. For example for FreePDK45 with num_bits=8, num_words=256
Improved
**** Analyzing pins: 20.9 seconds
** Routing: 293.8 seconds
** SRAM creation: 349.8 seconds
Non-improved
**** Analyzing pins: 267.9 seconds
** Routing: 537.5 seconds
** SRAM creation: 592.9 seconds
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
only rect and layer are used to compute the hash for a pin. Having
those as properties allows us to cache the hash value and only update it
if either rect or layer are written.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
sram_factory cannot handle duplicate module name, thus we bail out and
raise an error if a user attempts that.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
modules overridden by the user are the highest priority, then modules
overridden by the technology. If nothing is overriden, use the defaults
from OPTS (if they exist) or use the requested module_type.
This fixes that custom tech_modules could not be used, if they had a default in
OPTS even if the latter was not overridden by the user.
We don't need extra defaults in the tech_modules, as we now only use them,
if they have been overridden by the tech_module.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
mrg
Bastian Koppelmann