[Libre-soc-bugs] [Bug 736] SimdSignal's integration with nmigen needs to handle first args not being SimdSignals

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=736

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #3)
> (In reply to Luke Kenneth Casson Leighton from comment #2)
> > as in, rather than:
> > 
> > s = SimdSignal(...)
> > Cat(Const(...), s)
> > 
> > it would be e.g.:
> > s = SimdSignal(...)
> > c = SimdSignal(...)
> > comb += c.eq(Const(...))
> > Cat(c, s)
> > 
> > which "avoids" the problem that i think might turn out
> > to be unique to Cat()
> 
> nope, it also occurs in Mux and Part.

ok.

> s1 = Signal()
> s2 = SimdSignal()
> Mux(s1, Const(), s2)

yeah this one i went with the rule "selector is the priority".

> Part(Const(), s2, 3, 5)
> 
> For Cat, we look for the most-derived subclass and use that.

ahh that makes sense.  except... oh i know.  a static SimdSignal.Cat.
find the most-derived class then call the static function with the
complete list.

def Cat(*arglist)
   kls = find_most_derived_class(arglist)
   kls.Cat(*arglist)



> more when I
> have time.

ok.

these are things i am happy to go with a workaround for the
first version, in order to keep the patch to nmigen to a bare
minimum.

the last thing we need right now is for that 400 line diff to
turn into 4,000.

also, remember, we need to get off critical path so if work
can proceed on the ALUs with workarounds such as converting Consts
to SimdSignal, and not using mixed Signal and SimdSignal, *great*.

the ALU conversion gives us data about what the priorities are:
what matters and what doesn't

pragmatic.

-- 
You are receiving this mail because:
You are on the CC list for the bug.