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

[bugzilla-daemon at libre-soc.org]

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

--- Comment #67 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to andrey from comment #66)

> Ah ok, makes sense. Is it effectively trying to read/write a node between
> signals, not the wire/signal itself?

no, it's worse than that: anything of type Pin/Resource is simply 100%
categorically absolutely nothing to do with Simulations().

> I'll add this one after resolving an issue with reading core input.

which you can only do via these:

    # Grab GPIO input pad resource from JTAG BS - start of chain
    gpio0_pad_in = top.jtag.boundary_scan_pads['gpio_0__gpio0__i']['i']


> After writing a 1 or 0 to the pad input, I want to read the input value seen
> at the core.

then add a temporary Signal to Blinker into which a copy of that value
is placed.


> I tried the following to access core input (only showing GPIO0 i for
> simplicity):
> gpio0_core_in = yield top.gpio['gpio0']['i']
> and
> temp_in = yield top.gpio.gpio0.i
> 
> Both of these threw TypeError seen before, so I'm guessing that I'm trying
> to use pins, as opposed to signals.

don't guess: CHECK. use a print statement to print out the type of the
object.

*you* are in control, here.  any "guessing", your *immediate* reaction
as an Engineer should be, "how can i confirm 100% my guess?"

> Based on the yosys diagram, I thought that jtag_gpio_0__gpio0__i__core__i is
> what I can read to check if the pad input is propagating.

probably... but not via the Pins/Resources, it is completely the wrong
data structure.

git pull and check the code-comments: you missed re-reading pad0_out-pad3_out
after changing gpio0_pad_in.

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