[Libre-soc-dev] Suggestions and clarifications to overcome symbiflow stuck at VPR - Reg.,

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Oct 11, 2021 at 5:17 AM MANIKANDAN NAGARAJAN
<manikandan_phd at outlook.com> wrote:
>
> Dear Team,
>
> I have been observing the conversation related to the symbiflow adoption and it is stuck somewhere in VPR.

yes.  a third party libre-licensed tool outside of our control, time,
and budget.

> Base on my learning I would like to suggest that symbiflow support *nextpnr* also for the same purpose VPR is exist in symbiflow.

this requires some investigation and confirmation.  it *may* be the
case that it is an option as a drop-in replacement.  it *may* however
simply be that nextpnr has no idea - at all - about the arty a7 - but
that VPR does, and that's why it was chosen.  we just don't know.

> (Ref:https://symbiflow.readthedocs.io/en/latest/toolchain-desc/design-flow.html)
> (pls check Place & Route in SymbiFlow section in the above link)

unfortunately there's simply one word on that page. there's no mention
of *how* to use nextpnr, how to enable it.

> Libre-SoC flow is already well compatible with nextpnr and bitstream files generated for ECP5 with that.

... for the purposes of connecting to a completely different FPGA, the
ECP5, via a toolchain that has been tested and confirmed functional by
multiple people other than ourselves.

> May I know anybody has already verified this with nextpnr?

we have no idea.  we are simply end-users of the symbiflow tool, just
like you and Varun are.

> if no, my suggestion is to give a try with nextpnr and I believe that will successfully complete the symbiflow.

apologies: it's really just not that simple.  there is a fundamental
assumption that this has been a tested path, and/or that this is a
commercial "supported" tool where the expectation is that
"everything's been tested by the Commercial Corporation and is
therefore expected to work".

there *is* no Commercial Company developing all of these disparate tools.

(in this particular case, with the symbiflow suite, i believe it was
google who paid a third party company - advantec i think - to put all
of these disparate pieces together into a cohesive whole, with a
specific goal of testing on a specific pre-determined set of FPGA
boards, as determined by google)

Libre/Open Software, especially when under development, simply isn't
anything like that.  in early stages, if it works *at all* you're
extremely lucky.  beyond that, if you want it to work / want more, you
have to either find the developers and pay them, find the developers
and convince them to work on it, or get involved directly with the
source code and with the project itself.

as a third party tool completely outside of our remit, control, budget
and time, for "immediate" results it is basically down to _someone
else_ to take responsibility for that at the moment, until we can
properly plan ahead for a budget request to NLnet to cover it, and
that has an associated latency of approximately 3-4 *months* and
requires that we also find someone willing to be paid to do the work.


now, there *may* be another way: we avoid the problem entirely.

veera pointed out that symbiflow requires its own version of yosys,
with some specific "fixes".  those "fixes" *may* be designed to
*avoid* creating output that causes vtr to segfault.

this gives a number of options:

1) find out what those "fixes" are and back-port them to the version
of yosys that we use

2) attempt to use *exactly* that version of yosys and hope that it works

3) bring nmigen forward *as well* - to the same timestamp (roughly) or
just the latest version and hope that that works, too

(1) is complicated, it requires c programming.  (2) is easy.  (3) is
also easy and may not be necessary.

this avoids a massive stack of work, basically.

l.