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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Tue Nov 30 20:19:35 GMT 2021


--- Comment #60 from andrey at technepisteme.xyz ---
(In reply to Luke Kenneth Casson Leighton from comment #59)
> (In reply to andrey from comment #58)
> basically from what i can gather you may have modified the actual AST,
> with potentially disastrous unpredictable results.
Sounds like fun...I'm sure this hasn't affected anyone before :)

> if you now grab the relevant GPIO resource from resource_table_pads
> then the ends of the wires can be safely toggled.
Now makes senses, thanks luke.

> (btw please do trim excessive context especially in bugzilla replies)
Apologies, will keep in mind.

>From our chat on IRC:

Next steps are:
-Create two multi-bit signals (based on number of gpios) called:

-Wire up the output signal of each gpio by XOR'ing each bit of gpio_o_test with
gpio's input:
comb += gpio0.o.eq(gpio_test[0] ^ gpio0.i)

-Wire up each bit of gpio_oe_test signal to oe signal of each gpio. 

-Have the sim run through a for-loop where the gpio_o_test is incremented like
a counter (0000, 0001...)
-At each iteration of the for-loop, assert:
+ output set at core matches output seen at pad
+ input set at pad matches input seen at core
+ if gpio_o_test bit is cleared, output seen at pad matches input seen at pad

-Another for loop to run through gpio_oe_test. Assert:
+ oe set at core matches oe seen at pad.

As there is no I/O pad logic, the state of the output signal is NOT affected by
the oe signal. I've confirmed this by setting gpio3.o and toggling gpio3.oe and
checking the waveforms.

For the moment I'll start working on this. This is simple, and it shouldn't
take me a lot of additional code. If I start to write too much, I'll ask

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

More information about the libre-soc-bugs mailing list