[Libre-soc-dev] daily kan-ban update 07mar22

[Andrey Miroshnikov]

On 07/03/2022 20:12, Luke Kenneth Casson Leighton wrote:
> niice. got yourself a shed-load of pharmaceutical-grade vitamin D?
> (you also need magnesium: vit D doesn't "work" unless it's got
> magnesium to hang on to)

Ah, I didn't realise the magnesium was so necessary. Don't have any in 
the cupboard so will buy some. I've been taking vit D and separate Zinc. 
At the moment I have a cough remaining (annoying but bearable). Also 
flow test is positive, so I'll probably keep generating the little 
buggers for a while...

> oh yeh i remember that.  yeah creating just a "single mux thing" should
> be ridiculously easy, almost comically so.  i recommend using an Array.
> suggest doing one MuxIn class and one MuxOut class.

I'm not sure why there are two classes. The diagram I linked shows a 
single block, so I've probably forgotten something here.
Do you mean a class for the out/oe direction and a class for the i 
direction? So that the ports could have prefix names of the attached 
peripherals and chip pad pin?

> 
> remember the primary focus is to be able to give these mux class instances
> signal "names" that then make it blindingly-obvious in the gtkwave and graphviz
> diagrams what the hell is going on.

Yes...with the sheer number of signals we will have anything else is 
madness XD

> 
> so a list (or dict) mapping 0 1 2 3 blahblah to pin-names is a crucial part of
> the [two] Mux classes.
> 
> remember though that it's fine to have connections missing!  although we have
> a convention in pinmux.py that you never miss out pin numbered 0, that is always
> a GPIO, you *can* strictly speaking have 0 2 3 where 0=GPIOA0, 2=SCL 3=TX
> something like that.

Ok, I'll make sure the method will  be able to cope with that (hardwire 
unconnected to zero). Or would it be useful to give the designer a 
choice of hardwire-1 as well?


Andrey