First impressions on FPGA toolchain
Posted: Fri Jun 05, 2020 1:21 pm
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
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