[Libre-soc-bugs] [Bug 1004] FPGA bring up for platform definitions

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1004

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #2)
> Summary of experimentation done so far:

good report.

> 44:25
> 
> 7) Compiled the previous verilog file (without nMigen) with
> yosys+next-pnr-xilinx. Didn't work. Toolchain confirmed non functional for
> the XC7A200T.

it really should not fail. if it does that needs a report upstream with a
suitable repro case. please keep interaction with upstream developers to
an absolute minimum.

> https://libre-soc.org/irclog/%23libre-soc.2023-08-27.log.html#t2023-08-27T17:
> 57:58
> 
> 8) Installed Symbiflow, an alternative toolchain. Compiled a Symbiflow demo.
> Konstantinos reported it to work.

last i checked symbiflow was awful.  many Cells within the FPGA are
unsupported (including some IO pads!), vtr was made multi-threaded and
spends 95% of its time contending for a global lock, resulting in a 7x
performance slowdown compared to nextpnr, and there are the most awful
hacks exporting multi-gigabyte files into JSON, parsing them in *python*
scripts then *re-importing* them as workarounds on carry-save propagation
which don't do the job.

then it was also incapable of
dealing with add/sub/cmp (anything using the Xilinx CARRY4 block)
greater than 96 bits in length because in each "Tile" of a XIlinx
FPGA there are ony 25 such CARRY4 blocks and symbiflow fails to
take that into account.

unless there has been a massive amount of work done, counting on symbiflow
for large designs such as ours would be a serious mistake.

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