[Libre-soc-dev] Litex-OPENTitan clarification

Cole Poirier colepoirier at gmail.com
Sat Oct 3 06:30:48 BST 2020


On Friday, October 2, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Sat, Oct 3, 2020 at 1:08 AM Cole Poirier <colepoirier at gmail.com> wrote:
>
> > subsequent tape-out in 2021). There's a SystemVerilog IEEE compliant
> > parser library in rust, so I was thinking I could work with Jacob on
> > creating a tool that uses this to convert the parts we want from
> > OPENTitan into our litex-replacement nmigen implementation. I suggest
> > creating a sv2nmigen translator because doing this any other way than
> > automated/auto-generated would be massively time-consuming (the
> > project is >100K LOC).
>
> what you mean this?
> https://git.libre-soc.org/?p=sv2nmigen.git;a=tre
> <https://git.libre-soc.org/?p=sv2nmigen.git;a=tree>e


I thought I recalled seeing that somewhere, but I couldn’t recall with
enough clarity, probably one of the reasons I thought of this now that I
think about it... hmm.


> > Ideally, Jacob and I would work on this largely
> > without 'bothering' you, as I wouldn't want to distract you from the
> > priority of our 30 OCT code-freeze deadline. Also, this is assuming
> > that Jacob is even interested in working on this... Brain still a tad
> > melty so pardon the style of this email, but I think this is possibly
> > a good idea... let me know what you think :)
>
> whilst what the lowRISC team did is great, it reinforces the lesson
> that i also learned from the BSV generator:
>
> *templates are unreadable* and ultimately unmaintainable.
>
> because they use code-fragments with substitution, you can't write a
> parser (sv2nmigen) for the *pre-completed* fragments because they
> don't comply with the verilog syntax.
>
> the templates only comply with verilog.... *AFTER* they have been used
> to create actual verilog.
>
> thus, they are worse than useless to us: they're a massive hindrance,
> because the entirety of OpenTITAN must be a dependency.
>
> thus, therefore, we must become experts in modifying (forking)
> OpenTITAN and become experts in OpenTITAN's verilog templating system
> and become experts in OpenTITAN configuration.
>
> the fact that it is exclusively targetted at RISC-V processors makes
> it *even less* attractive.
>
> so we'd have to:
>
> * learn verilog
> * learn OpenTITAN configuration
> * modify OpenTITAN to understand OpenPOWER and XICS interrupts
> * generate verilog
> * convert that to nmigen (fully convert: not partial-convert)
>
> how reliable and workable do you think that's going to be?
>
> does it not sound more attractive to work in python, to create
> something that is direct and along the lines of what _we_ need,
> define, and control the direction of?


This is the exact reason I asked, thank you for such a rich explanation. I
love having the ability to ask someone better informed than myself. I get
to the conclusion without having to waste time doing something someone else
has already thought out, and therefore knows why it won’t work. Advice is a
magical thing, it would be foolish for me to *actually* pursue this. So
fascinating, and delightful really.

Have you outlined our direct, based-on-our-needs python version on the wiki
or a bug report? Or is this something that is deferred until our bugzilla
review after the code freeze deadline?


> if the OpenTITAN / lowRISC team had consulted us, sought our input,
> and looked for ways to collaborate, i would not be asking that
> question.
>

Am I correct in recalling that they used your pinmix work?

Besides the work on icache.py and the related wb_get work, what else can I
be working on that would be helpful?

Cole


More information about the Libre-soc-dev mailing list