[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:
> higher level implementation is to integrate JTAG interface inside the nmigen
> 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  for GPIO,  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.
 GPIO ls180soc IOconn pad connections
 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