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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu Sep 24 21:43:04 BST 2020


--- 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:

> 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


> 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

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:


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.


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

> 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

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


[2] UART ls180soc IOconn pad connections


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

More information about the libre-soc-bugs mailing list