[Libre-soc-bugs] [Bug 762] Peripheral Pin Muxing Development

[bugzilla-daemon at libre-soc.org]

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

--- Comment #25 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
(In reply to Luke Kenneth Casson Leighton from comment #24)
> no it's good.  with the PU/PD you can actually wiggle OE rather than IO
> and get that SCL/SDA behaviour that Cesar was talking about (the
> "on" or "high-impededance" thing rather than "on" and "off" which you
> would get by wiggling io)
Brain a bit fried, not sure what you mean there (might be a good point to
mention tomorrow).

> no need, let's do that later when there's an actual IOpad to match it.
Sure.

> nono, don't do that, but if they are intermediary then move them actually
> *into* the elaborate() function and remove "self.".  they're not intended
> to be accessed externally, so why are they made public members?  just
> move the initialisation wr_multi = blahblah actually directly into
> elaborate().
Yes, very good idea. Completely forgot about the whole "private"/"public"
thing. Will probably take some time until OOP with HDL becomes natural hahaha!

> basically you can use wr_multi and rd_multi as a means to "re-format"
> the data (match the data structure with what needs to go in/out of the
> GPIO registers), and you can do that combinatorially.
Yes! Thanks for clarifying this. I changed the code to connect wr_multi and
rd_multi combinatorially to the respective WB data buses.

> but you *must* ensure that the GPIO_index (and associated
> "sel") triggers only the storage into the GPIO_reg (for write - we=HI)
> or copying-out (for read).
Yes. The GPIO_reg data is shifted to rd_multi, and ack raised  on the same
cycle (as the data is valid).
For wr_multi, I have 1 clk delay to ensure ack is raised *after* GPIO_reg is
updated.

> yes.  what you've done requires two cycles, not one. the we needs to
> be held for *two* cycles, which is not going to happen.
You're right, I missed that ack statement.

> even has a wikipedia page https://en.wikipedia.org/wiki/Printf_format_string
Thanks, I'll be using from now on in python (to the chargrin of most devs XD)

Took a bit of thinking, but got the driver code updated to support sel.
https://git.libre-soc.org/?p=pinmux.git;a=commitdiff;h=2e4f5b6bdedbff041b4dbfaedcc468d544fecfcf
Also needed to extend the wb_write and wb_read to support different sel values
(not just 32-bit or 8-bit).
https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=919ad8e3c110f5af0779d7e1d329736c245b56ae

Unless I've missed anything else, now I can go back to the 1-pin pimux case.

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