Page 1 of 2

First impressions on FPGA toolchain

Posted: Fri Jun 05, 2020 1:21 pm
by tnt
Hi,

I got the link to the toolchain this morning, so I thought I'd give it a try to build it.
And yes, build it. I'm not interesting in "Installers" or anything like that, the whole point of the OSS toolchain is I can integrate it in my existing flow and environment.

The first part, yosys and associate plugins was straightforward enough. The separate repo merge without conflicts with yosys master. I'm hoping that it will all be pushed to upstream soon. I played a bit with just the synth_quicklogic command on some verilog code I had and results looked very decent.
There seem to be more to it than just calling synth_quicklogic though. I saw in some document there was a some magic ql_symbiflow command, but I'm not interested in some magic script, I have an existing flow that calls yosys directly and want to integrate in that. I'm looking for a document that explain exactly how to use yosys to produce the required files for the next step.

The next step though didn't work so well. Compared to how easy it is to install nextpnr for the ice40 and ecp5, it's a nightmare. Sorry if this sounds harsh but that's the reality. nextpnr is simple and clean design, with few external dependencies. The VTR arch defs stuff is ... the opposite of that:

1) It uses conda which I consider broken by design and want nothing to do with. There is a way to disable it so I can properly use my package manager to manage dependencies ( using -DUSE_CONDA=FALSE ) but it seems obvious nobody has tested this option because it's just utterly broken at so many places ... For instance many XX_TARGET are accessed using get_property_required but those variable are _empty_ if conda isn't used. Then at some other places those vars will end up as defined to 'NOT_FOUND' and not empty. Some dependency check for non-existing executables, that don't exist even if the package is installed system wide. Some

2) It has _SO_MANY_ dependencies to so many stuff. 95% of it I don't care about. Lots of them are needed only for Xilinx device, why would I need to clone those sumodules or install those dependencies if all I want is a toolchain for QuickLogic devices. Some are only for devs, like python formatting and linting should not be _required_ dependencies. Some I just can't explain why on earth you'd even use them ... NodeJS for a FPGA flow? Like seriously ? If that's really a hard requirement, I'll pass ...

3) It used relative submodules and so if you happen to have the QL repo as a secondary remote and not the primary origin ( I just added it as remove to an original clone from symbiflow ), the references to those submodules will be broken.

All in all, after 5 hours, I still don't have a working toolchain. I hacked the CMake logic to build mostly, but it crashes at some step when trying to run vtr on a passthrough design or something:
Error 1: /home/tnt/projects/fpga/toolchain/symbiflow-arch-defs/build/quicklogic/devices/ql-eos-s3-virt/arch.timing.xml:2427 <pb_type> timing-annotation/<model> mismatch on port 'TBS' of model 'T_FRAG', timing annotation specifies combinational connection to port 'XZ' but the connection does not exist in the model
(full error at https://pastebin.com/raw/c4Mn2ixM )

And even if it did succeed, I also have no idea how to actually call VPR correctly either, any example of the parameters and explanation of what each of them do ?

My advice ... Go and give whatever he asks to David Shah to get a nextpnr port to that architecture ASAP because that looks like the only hope for a usable toolchain from where I'm standing.


Cheers,

Sylvain

Re: First impressions on FPGA toolchain

Posted: Fri Jun 05, 2020 3:49 pm
by lsharma
Thanks for the detailed feedback Sylvain.
Currently, we have listed down the steps to compile from source. As you rightly mentioned, we have currently not merged into Yosys master and same is the case with symbiflow. So, for now it is recommended to use the repos present in Quicklogic-Corp GitHub and these are mentioned in the steps to compile from source. For now, we are compiling symbiflow using Conda and your feedback is well taken. Will see if we can come up with a compilation with no_conda.

- Lalit

Re: First impressions on FPGA toolchain

Posted: Fri Jun 05, 2020 4:14 pm
by lsharma
Sylvain - please try running the test case mentioned as last step in compile from source list. You may access this file to refer to vpr commands used to run the PnR flow: CMakeFiles/file_quicklogic_tests_quicklogic_testsuite_bin2seven_bin2seven-ql-chandalar_ql-s3-ql-eos-s3-virt-ql-eos-s3-wlcsp_top.net.dir/build.make
This file is present at symbiflow-arch-defs/build/quicklogic/tests/quicklogic_testsuite/bin2seven in symbiflow-arch-defs repo.

Re: First impressions on FPGA toolchain

Posted: Fri Jun 05, 2020 4:42 pm
by tnt
Same error as above when trying to run the test.

Something goes wrong when the xml are generated and they're not valid, no clue why ...
I included the full build log (zipped because this forum doesn't allow .txt or .log attachements :/)

There is plenty of warnings durin build , but no idea if they are expected or not ...

Code: Select all

WARNING: No pin in tile at 'Loc(x=8, y=10)' found for switchbox pin 'CZ' of 'SB_LC_X8Y10' at 'Loc(x=8, y=10)'
or :

Code: Select all

WARNING: For 'SB_LC (3, 27, 0, 6)' the delay model slope is negative! (a=-7.50e-12)
WARNING: Error of the timing model of 'SB_LC (3, 1, 0, 6)' is too high:

Re: First impressions on FPGA toolchain

Posted: Fri Jun 05, 2020 9:27 pm
by tnt
So the issue above was because I'm using a more recent yosys (on top of which I merged the QL branch).
In newer yosys whitebox blocks are not considered during 'select' operation by default and so v2x needed patching : See https://pastebin.com/tJjzTaiG

Re: First impressions on FPGA toolchain

Posted: Fri Jun 05, 2020 10:55 pm
by mithro
The separate repo merge without conflicts with yosys master. I'm hoping that it will all be pushed to upstream soon.
FYI There is a pull request open to get this stuff merged upstream at https://github.com/YosysHQ/yosys/pull/1816 which was opened in March. It would be useful to express support for getting it merged.
My advice ... Go and give whatever he asks to David Shah to get a nextpnr port to that architecture ASAP because that looks like the only hope for a usable toolchain from where I'm standing.
I believe David Shah was contacted about nextpnr support but sadly did not have the time to work on the project (IIRC He is 100% solidly booked for the next 12 months).

I'm sure QuickLogic would love to see nextpnr support! Unlike other manufacturers which require people to first document a part, QuickLogic is providing all the raw source data (including bitstream and timing data) needed for someone to write both synthesis and place and route tooling. You can find it at https://github.com/QuickLogic-Corp/EOS-S3

Re: First impressions on FPGA toolchain

Posted: Sat Jun 06, 2020 6:41 am
by tnt
Great about the PR. Posted my result in it.
The requirement for the v2x patch above to deal with changes in yosys 'select' is a bit annoying since applying the patch breaks the old yosys AFAICT :/

Too bad about David, nextpnr sure could use some other devs.

Re: First impressions on FPGA toolchain

Posted: Sun Jun 07, 2020 4:38 pm
by tnt
There seem to be another issue with the toolchain source : The installed scripts ( from quicklogic/toolchain_wrappers ) are completely different from the one in the binary release. I have no idea where the latter are supposed to come from, I couldn't find them in any source repository ...

Re: First impressions on FPGA toolchain

Posted: Mon Jun 08, 2020 7:58 am
by kkumar
The installed scripts from the package are modified to support additional targets(generate header files, post verilog and jlink) to run. These needs to be run only with the tar package.

Re: First impressions on FPGA toolchain

Posted: Tue Jun 16, 2020 10:23 pm
by kakkamies
I downloaded the installer Symbiflow_v1.0.0.gz.run and tried to install it on a Debian running under Linux Subsystem for Windows.
The installer fetches stuff from the web and part of it fails.

Code: Select all

Collecting package metadata (current_repodata.json): failed

CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://conda.anaconda.org/quicklogic-corp/linux-64/current_repodata.json>
Elapsed: -
ls
An HTTP error occurred when trying to retrieve this URL.
HTTP errors are often intermittent, and a simple retry will get you on your way.
'https://conda.anaconda.org/quicklogic-corp/linux-64'