[Libre-soc-bugs] [Bug 50] nmigen pinmux
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Nov 29 22:26:03 GMT 2021
--- Comment #57 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to andrey from comment #56)
> Due to not really understanding the topology, my brain basically switched
understanding comes later and is not strictly necessary: results generate
their own understanding-map based on repeated observations. this is the
basics of auto-didact / self-learning. babies do this with spectacular
results. why larger humans lose this ability is bewildering to me :)
> Now it makes sense though, given that the gpio object was not a public
you would not be very happy with python as a language if it magically
added hidden objects without your consent or knowledge.
> Also in regards to topology, the "gpio" object seems to me to be a core side
> block (thus you can control the o/oe signals). Is there a corresponding
> "pad" object (which would allow me to control the i signal)?
reminder: forget - for now - about JTAG. at this point you should
1) yield-eq'ing the o/oe record objects to integer values (python values)
2) yield-ing i.e. GETTING the / record objects.
gpio2_input_value = yield top.gpio.gpio2.i
do NOT attempt to set (as you have been) any record objects equal
to other record objects or Signals. this is DIRECTLY interfering
with the AST tree and it is guaranteed to be precisely and exactly
what you DO NOT want.
> > > I thought the GPIO block is accessible as an attribute of top module.
> > to the nmigen *AST*, yes. but you are not directly accessng the
> > AST, here, you are accessing the python object named "top" which
> > happens to be an instance of Blinker().
> I seem to remember you talking about AST and then some other object after
> the AST step, but this escaped me.
you created a Blinker() instance. you put it into a variable named "top".
that instance has absolutely nothing to do with Simulations() in any
way, shape or form.
it CAN - if REQUESTED - create an Abstract Syntax Tree - IF REQUESTED
TO DO SO.
you are conflating things in your head again. the object that is
**CAPABLE** of creating (on-demand) an Abstract Syntax Tree is not
**ITSELF** the **ACTUAL** Abstract Syntax Tree.
the AST happens to be the return result of a function provided **BY**
the object that you happened to have assigned to a python variable,
which you chose to call by the name "top"
this is about conceptual separation: you need to be absolutely clear
about it, and not "mentally lump stuff together just because it happens
to be in the same source code file".
> I'm able to control o and oe signals by using top.gpio.gpio2.oe (for
> example), which is a great step forward.
> Not sure how to control the i signal, but I'm using your print method for
> seeing the objects contained in JTAG, and I'll try to figure it out tomorrow.
> Made uart signals public by writing
> self.uart = uart
> Tried to control the rx, (as in this example, rx sets "intermediary" signal,
> which then sets tx), but not working. I'm guessing this is a similar issue I
> have with gpio i where I'm trying to drive the wrong signal.
> You can see the GPIO 2 and 3 outputs being toggled in the attached
> screenshot :)
ok, well, i totally lied about not having to get involved with JTAG Boundary
Scan stuff (or, not quite). try setting the new no_jtag_connect argument
to True and, magically, by *disconnecting* the gpio and uart resources from
the JTAG Boundary scan, suddenly you can set them successfully.
you cannot "tap into" a wire and set it in the middle, you have to get the
end of the chain, which in this case (sigh) is the stuff created by
Boundary Scan, i.e. right back at the "pads" as you probably suspected.
these are accumulated in a data structure Blinker.jtag.resource_table_pads
i've committed some more stuff which should in theory be self-evident
from the diffs at least
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs