[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