[Libre-soc-bugs] [Bug 713] PartitionedSignal enhancement to add partition-context-aware lengths
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Thu Oct 7 00:23:06 BST 2021
https://bugs.libre-soc.org/show_bug.cgi?id=713
--- Comment #21 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #20)
> wip layout demo script:
fantastic, i suspected it would be that short. i'll test
it tomorrow. thank you, really, for trusting me.
the second function "setup" stuff will be a bit longer,
but perhaps a Simulation by doing m = Module() would
evade needing to write an Elaboratable class,
the function needs to have as args:
* the dict spec
* a 2-bit Signal() (for now)
* the PartitionPoints that were created from the dict
* a module
it should:
* create an m.Switch on the 2bit signal which
* enumerates the dict key/values
* for each key, "enable" the mask bits that were
linked to it in the layout() in the PartitionPoints
this function should likewise be ridiculously short.
if layout() needs to adapt/change so that there is
a way to *get* the partition setting on a per-spec-key
basis, either as just a simple binary value that is literally
chucked at PP.mask.values() feel free.
so if the dict spec was
0b00: (64, 11)
0b01: (...)
...
...
then the extra dict returned from layout
which setss mask values would be something
like
0b00: 0b1111000, # 1s to cut off (empty) partitions
0b01: 0b0010100
this rather than the actual numerical partition points
because PP.mask.values() gives you the underlying
mask, Cat() them together and assignment from the dict
is possible.
i can never remember which way round PPs specify masks,
if it's set to close or set to open a partition, apologies
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list