[Libre-soc-bugs] [Bug 50] nmigen pinmux

[bugzilla-daemon at libre-soc.org]

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

--- Comment #58 from andrey at technepisteme.xyz ---
(In reply to Luke Kenneth Casson Leighton from comment #57)
> (In reply to andrey from comment #56)
> 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 :)
Hahaha, I'll try to keep this in mind. Poke things until something does
something else.

>  
> > Now it makes sense though, given that the gpio object was not a public
> > attribute.
> 
> 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
> *only* be:
> 
> 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.
> 
Ok, only use integer values, or return records themselves.

> 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".
Everything is separated, ok.

>  
> > You can see the GPIO 2 and 3 outputs being toggled in the attached
> > screenshot :)
> 
> exccellent!
It is indeed a little scary that the signals even toggled at all, when I set
them to be equal to a signal object as opposed to an integer :')

> 
> 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.
> 
Makes sense, I'll play with it some more.

> 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
Thanks Luke

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