[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 #24 from Staf Verhaegen <staf at fibraservi.eu> ---
(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. For higher level
implementation is to integrate JTAG interface inside the nmigen platform. Just
like you now have XilinxPlatform you would also have ASICPlatform or
C4MPlatform. 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). The platform would then automatically instantiate the right IO cell and
add it to the JTAG boundary scan.
Unfortunately this is still TODO.

> and now that i think about it it's a *lot* of work:
> 
> * call add_ios in nmigen
> * expose both the pad wires *and* the the jtag-io wires (IOConn Record)
> * add all IOConn records to the litex libresoc core.py code
> * get litex to generate the ls180.v
> * join up the libresoc core (in verilog) to ls180.v
> * re-import ls180.v into nmigen
> * *finally* wire up the connections between jtag-io and pads

Why do you need to bring IOConn into litex ?
* 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()
* 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. The pad
part of the IOConn you bring out as the new top signal in a generated verilog
file.
* This new top goes then to synthesis and P&R

> 
> i might actually do that last step in litex (ls180soc.py) to save some
> messing about, and reduce the number of wires routed between different
> compilers.
> 
> so if it's ok with you i'm going to do the 16 GPIO, and the 2nd UART.
> this will cover:
> 
> * IOType.In (uart1 rx)
> * IOType.Out (uart1 rx)
> * IOType.InTriOut (gpios 0-15 yes i worked out how to do o/i/oe)
> 
> also: do you have a template for re-building the actual SoC with the
> c4m IO cells?  i can throw something together if not but i will need
> some guidance / pointer-to-some-code.

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

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