[Libre-soc-dev] Litex-OPENTitan clarification

Cole Poirier colepoirier at gmail.com
Mon Oct 5 03:08:18 BST 2020

On Sun, Oct 4, 2020 at 6:52 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> On 10/5/20, Cole Poirier <colepoirier at gmail.com> wrote:
> i rhink the lesson from the bsv pinmux and from opentitan is: for
> god's sake stay away from templating of HDL.
> verilog can't read JSON or CSV files. bluespec can't read them either.
> the result: hopelessly unreadable code.
> by using pyrhon to generate the AST of the pinmux we stand a chance of
> readability.

Jesus! indeed seems like an insurmountable headache!

> what we *might* be able to do is use the devicetree generation etc.
> aspect of opentitan.

Interesting, is this the LUT in the bootloader that lists the memory
addresses of all peripherals?

> >> > Or is this something that is deferred until our bugzilla
> >> > review after the code freeze deadline?
> >>
> >> realistically, it's "after".
> >
> > As in after our winter/spring 2021 130nm skywater tapeout?
> we're not doing the nov skywater 130nm.
> we are using Staf EuroPractices 180nm, Dec 2nd deadline.

I know. Note I specifically said 2021, and referred to skywater 130nm
as you (or staf, I forget which) mentioned we might do another 1 or 2
additional tapeouts *after* the Euro 180 nm 2 DEC tapeout. I assume
this is to test things like the scoreboard scheduling, and the
SMP/cache-coherency, and GPU workload (and ... ?) prior to the Fall
2021 40/45 nm quad-core CPU-GPU-VPU commercial product tapeout?

So, to clarify, you want the nmigen-litex to be discussed after the
Euro 2 DEC tapeout?

Additionally, what are our responsibilities between 30 OCT code freeze
and 2 DEC tapeout?

> > Should I create a bug report for this?
> yes please.



More information about the Libre-soc-dev mailing list