[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