[Libre-soc-dev] adding PartitionedSignal support to nmigen's If/Switch/Case
programmerjake at gmail.com
Tue Sep 21 20:50:29 BST 2021
On Tue, Sep 21, 2021, 07:38 lkcl <luke.leighton at gmail.com> wrote:
> i checked the notes in the bugreport,
> tracked through the original conversation with whitequark:
> i'm going to write out what i can remember. it's written as "statements".
> however *please automatically assume* that it is perfectly fine to say
> "that's wronggg... because".
> also "screaming and running away in horror at the inefficiency" is
> perfectly fine.
> the logic is as follows:
> * with the "rules" established by PartitionedMux being that ALL bits are
> set in a given partition, the "if" statements, which ordinarily and
> conceptually think if themselves as "single bit" and comprise exclusively
> the use of AND, OR, NOT, and MUX, all abstract perfectly to a multi-bit
> context, producing HDL statements that result in a multi-bit boolean not a
> single-bit boolean.
Generating a bunch of Ifs, one for each maximally-partitioned
PartitionedSignal lane will theoretically work for If, though it will be
incredibly inefficient and i don't think yosys will have an easy time
optimizing it back to sane levels. There is also the problem that all code
inside the If will still need to be vectorized (not a simple
process)...essentially ending up with a very similar problem to the
original idea of just reimplementing yosys's process passes.
essentially...we will need to have the same
vectorization/control-flow-into-data-flow-conversion code, the code just
has a slightly different output format.
However, beyond even the difficulties of If, Switch/Case has the additional
problem of deciding what code like the following means:
v = make_partitioned_signal() # assume it can be partitioned to at least
4x8-bit or 1x32-bit
# per-lane matching, or matching whole 32-bit word, or something else?
with m.Case('0101---- 11110000 -1-1-1-1 00000000'):
m.d.comb += x.eq(3)
More information about the Libre-soc-dev