[Libre-soc-bugs] [Bug 731] potential design oversight in Partitioned SimdSignal Cat/Assign/etc lhs/rhs
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Sun Oct 17 22:46:42 BST 2021
https://bugs.libre-soc.org/show_bug.cgi?id=731
Jacob Lifshay <programmerjake at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |programmerjake at gmail.com
--- Comment #2 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #1)
> thus, we conclude that for "lhs" mode there must be a *list of outputs*
> rather than as is the case currently only a list of *inputs*.
Yup, having a list of outputs is exactly what I did in SwizzledSimdValue...That
list (actually a dict from Signals to be assigned to to the computed values to
assign to those Signals) is AssignSwizzle.outputs.
> determining which mode to use, unfortunately, cannot be determined until
> the actual Assignment takes place!
>
> therefore, Assignment must actually perform an analysis of its lhs and
> rhs arguments and set which mode (lhs or rhs) they are set to!
Well, actually, the exact same object can be used as both a lhs and a rhs:
a = Signal(16)
s = a[5]
b = Signal()
m.d.comb += [b.eq(s), s.eq(1)]
> this is a rather large piece of work so should only be done if it
> turns out to be entirely necessary, and, furthermore, evaluated against
> whether the existing HDL can be adopted to avoid LHS AST assignments,
> temporarily. there are a number of known uses of Cat for example
I'm expecting that we will want to support a[3:5].eq(...) since that's very
common iirc. Assigning to Cat is very uncommon (I don't think we ever do it,
but I could be wrong .. maybe as part of assigning to a Record?)
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list