this was the remainder of applying a diff using "patch". To avoid this
mistake, add the filetypes created by "patch" to the .gitignore.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
we don't want to propagate the sense amp's bl/br names out of the
sense_amp_array. Thus the sense_amp_array gets them named as
"bl"/"br" again.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
all pin names should be wrapped into a function/property. This ensures
that there is exactly one place to change the name.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
we don't want to propagate the write driver bl/br names out of the
write_driver_array. Thus the write_driver_array gets them named as
"bl"/"br" again.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
all pin names should be wrapped into a function/property. This ensures
that there is exactly one place to change the name.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
both functions share a lot of code and are passing around a lot of data
under similar names (inst1, inst1_start_bit, inst1_bl_name, ...). Thus
we group all these elements in a named tuple to ease passing around
these elements.
All callers of channel_route/connect_bitlines() either pass in the bl/br
names or rely on "br_{}"/"bl_{}" as defaults. These hard coded values
should be determined by the instances. Thus we get the bitline names
based on the instances passed in. The callers only provide a template
string, to take care of the case that bitlines are called "bl_out_{}".
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
if we rely on the names of the submodules (sense_amp_array,
write_driver_array, etc.) for port_data's pins, we get into trouble on
multiport SRAMs. To avoid this we use explicit names for br/bl depending
on the port number in port_data. Now each submodule does no longer need to
figure out the right name depending on the port number.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
before the names of bl/br from the bitcell were assumed. If we want to
allow renaming of bl/br from bitcells, we have to seperate the other
modules from that. Note, that we don't touch every occurence of bl/br,
but only the once necessary that pin renaming of the bitcell works.
Signed-off-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
each module should be able to state how their bl/br lines are named. Here we
always connect port_data with the bitcell_array, so port_data needs function
that return the names of bl/br.
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>
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>
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>
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
Joey Kunzler
Bastian Koppelmann
Hunter Nichols
Jesse Cirimelli-Low