[Libre-soc-bugs] [Bug 490] Complete peripheral set including litex for first functional POWER9 Core

[bugzilla-daemon at libre-soc.org]

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

--- Comment #25 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
ok i have just finished (not tested yet), it will need review and testing.


(In reply to Staf Verhaegen from comment #24)
> (In reply to Luke Kenneth Casson Leighton from comment #23)
> > sfaf should i be calling c4m_jtag TAP.add_io for *all* pins?  that
> > seems somewhat excessive,
> 
> Currently only the low-level implementation of the JTAG interface is
> finished where you create for each IO cell a corresponding IOConn.

yes.  i do that here at line 47:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/debug/jtag.py;hb=HEAD#l47


> For
> higher level implementation is to integrate JTAG interface inside the nmigen
> platform.

yes, that's 

> Just like you now have XilinxPlatform you would also have
> ASICPlatform or C4MPlatform.

yes, this is here (ls180.py) which derives from GenericPlatform, it would
form the basis of an ASICPlatform

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/libresoc/ls180.py;hb=HEAD


> If possible I would like it to implement so
> that using .add_resources() you could define the type of the cells (e.g. pin
> 2,3 are UART).

at some point i want to completely replace litex with something similar to
OpenTITAN except written in nmigen.


> The platform would then automatically instantiate the right
> IO cell and add it to the JTAG boundary scan.
> Unfortunately this is still TODO.

i have some partial infrastructure done, today, it is not fully automatic
because that would need a lot more work in litex and i am not prepared
to commit huge resources to something that's based on an unstable base
(migen).

however.... i import the same "Pins" structure from soc.debug.jtag and
use exactly that in the litex core.py to create the "map" from the
(now verilog) core to litex:

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/libresoc/core.py;hb=HEAD

that is done at line 220 (declare another instance of Pins, similar to
back in soc/debug/jtag.py line 47, and enumerate them)


> Why do you need to bring IOConn into litex ?

because something has to connect up the IOConn to the actual litex peripheral
pads.  there are two ways to do it:

1) get litex to do it
2) get nmigen to do it.

this 2nd way requires passing the peripheral signals *in* to the verilog
instantiation of the core (test_issuer.v): litex still therefore needs
to know what they are, in some fashion.

i decided to go (2) because it greatly simplifies the "third stage" - the
nmigen "instantiation" of the combined litex-core verilog file.

all that the final phase needs to do now is: connect to the IO pads.
and i *think*... that actually might be a "null operation".

less work for you!

> * You define peripherals in litex
> * You get a verilog file out of litex with the IO signals as inputs and
> outputs of the top verilog module.
> * You bring this top verilog cell in nmigen using Instance()

ah, unfortunately, the litex sim code assumes that the nmigen test_issuer
is a verilog instance.

> * For each IO you do an add_io() on the TAP and connect the corresponding
> signals from the litex top in nmigen to the core part of the IOConn.

this is the bit that i have already done *before* it goes into litex.

why?

well... how can you call add_io on the tap *after* the TAP was created
in the *first* one?

and: how can we run a nmigen simulation of the TAP.add_io() calls if it
is brought in as a verilog instance?

we can't.  it would have to be done through verilator (which has to
be written) or cocotb (which has to be written) both of which are
time-consuming


> The pad
> part of the IOConn you bring out as the new top signal in a generated
> verilog file.

i have implemented it slightly differently, but making exactly the same
connections.

instead of nmigen (3rd phase) instantiating the TAP and calling TAP.add_io
it is done in the FIRST phase (because it is one JTAG class instance,
the same one used for Wishbone and DMI)


> As said above, for the moment bring out the pad part of the IOConns as
> input/outputs of the top verilog file together with clk and rst. 

already done, connected up, the pad parts of the IOConns are connected
in litex [1] for GPIO, [2] for UART

so the phase (3) $Instance is, i have a feeling, basically not needed.


> I will see
> with Jean-Paul how we add the IO cells to it.
> Later on also the nmigen platform should take care of this and instantiate
> the right IO cells but as said this is currently not implemented.

ok.  well, aside from unit tests which i will look at tomorrow, that is
currently the blocker for this because it's done.


[1] GPIO ls180soc IOconn pad connections

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/ls180soc.py;h=9c7547f7078522cedccb5cc38f2beed6e58b7f6b;hb=HEAD#l389

[2] UART ls180soc IOconn pad connections

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/litex/florent/ls180soc.py;h=9c7547f7078522cedccb5cc38f2beed6e58b7f6b;hb=HEAD#l374

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