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>
Hunter Nichols
Bastian Koppelmann
Joey Kunzler
Jesse Cirimelli-Low
mrg