Free FPGA: Reimplement the primitives models
blog.elphel.com
Free FPGA: Reimplement the primitives models
1–10 of 17 posts
Re: Free FPGA: Reimplement the primitives models
#2As an FPGA developer, I think this is a noble effort, but will be of limited use in porting their design (one of their stated goals).
Essentially all of the modules they are asking for "clones" of directly instantiate hardware primitives on the FPGA die. Many of the blocks are basically analog pieces that won't be easily synthesizable from Verilog. While the simulation would work with other tools, the block won't be able to be mapped in other FPGA architectures.
Re: Free FPGA: Reimplement the primitives models
#3As an FPGA developer, I think this is a noble effort, but will be of limited use in porting their design (one of their stated goals). Essentially all of the modules they are asking for "clones" of directly instantiate hardware primitives on the FPGA die. Many of the blocks are basically analog pieces that won't be easily synthesizable from Verilog. While the simulation would work with other tools, the block won't be…
Yeah, that's absurd. It's like asking for C intrinsics to be implemented as functions.
Those primitives are just a way to force the synthesis tool to infer specific hardware features.
Re: Free FPGA: Reimplement the primitives models
#4A more productive route might be to port the camera project [1] (for which the models are being requested) to use the Lattice ICE series of FPGAs and use the open source Project ICEstorm tool chain [2]?
That would have the dual effect of further developing the free tool chain, and sending a (small) signal to Xilinx that if they don't take Free Software seriously they will start to lose customers.
[1] https://github.com/Elphel/x393
[2] http://www.clifford.at/icestorm/
-----
edit: change "GPL licensed" to "open source", as a variety of licenses are used.
Re: Free FPGA: Reimplement the primitives models
#5As an FPGA developer, I think this is a noble effort, but will be of limited use in porting their design (one of their stated goals). Essentially all of the modules they are asking for "clones" of directly instantiate hardware primitives on the FPGA die. Many of the blocks are basically analog pieces that won't be easily synthesizable from Verilog. While the simulation would work with other tools, the block won't be…
Yeah, that's absurd. It's like asking for C intrinsics to be implemented as functions. Those primitives are just a way to force the synthesis tool to infer specific hardware features.
In the case of some of these primitives, like I/OSERDES -- high-speed input/output de/serializers -- they can't even be inferred. The only way you'll get one is if you specifically ask for it.
Re: Free FPGA: Reimplement the primitives models
#6As an FPGA developer, I think this is a noble effort, but will be of limited use in porting their design (one of their stated goals). Essentially all of the modules they are asking for "clones" of directly instantiate hardware primitives on the FPGA die. Many of the blocks are basically analog pieces that won't be easily synthesizable from Verilog. While the simulation would work with other tools, the block won't be…
Not really many are "analog" and we already have GTX model. Some primitives are just buffers, some - memories (block RAM), one PLL. I do not think it is a "rocket science" to create functional models without precise timing.
As for different architectures - sure these will not work, but we keep all the primitives in "wrapper" modules to simplify porting. With missing primitives it will be possible to run complete simulation, after that you can start replacing primitives to match different devices.
Re: Free FPGA: Reimplement the primitives models
#7A more productive route might be to port the camera project [1] (for which the models are being requested) to use the Lattice ICE series of FPGAs and use the open source Project ICEstorm tool chain [2]? That would have the dual effect of further developing the free tool chain, and sending a (small) signal to Xilinx that if they don't take Free Software seriously they will start to lose customers. [1] https://github.c…
Project uses 84% of Zynq (7030), it will not fit in Lattice :-(
Re: Free FPGA: Reimplement the primitives models
#8A more productive route might be to port the camera project [1] (for which the models are being requested) to use the Lattice ICE series of FPGAs and use the open source Project ICEstorm tool chain [2]? That would have the dual effect of further developing the free tool chain, and sending a (small) signal to Xilinx that if they don't take Free Software seriously they will start to lose customers. [1] https://github.c…
Project uses 84% of Zynq (7030), it will not fit in Lattice :-(
Fair enough, and there is an order of magnitude between size of the the 7030 and supported ICE parts (125K cells vs. 7680 cells), so it's beyond optimisation.
Out of curiosity, is there any one block/function that is consuming a majority of the cells? What is that block?
Re: Free FPGA: Reimplement the primitives models
#9"I hope that in the future there will be laws that will limit the monopoly of the device manufacturers and require complete documentation for the products they release to the public."
Oh god, please no.
On another note though, I'm a big fan of the work done by Clifford in bringing up a full working synthesis toolchain for iCE40; and I'd love for Lattice to cooperate and, dare say, fund the work.
I would program big FPGAs if I could do it with a free toolchain. Current toolchains are really cumbersome, and assume far too much about the designer's workflow. On top of that, they're absolutely insane to set up and activate. I bought a Zybo a few months ago to try their tools out, but after activating the seat I still wasn't allowed to synthesize to my device and basically just gave up. Lattice can take credit for theirs being the least painful; but it's still not what it could be if it were modular and free.
Re: Free FPGA: Reimplement the primitives models
#10Earlier quoted context omitted.
Project uses 84% of Zynq (7030), it will not fit in Lattice :-(
Fair enough, and there is an order of magnitude between size of the the 7030 and supported ICE parts (125K cells vs. 7680 cells), so it's beyond optimisation. Out of curiosity, is there any one block/function that is consuming a majority of the cells? What is that block?
No single dominating block. Camera has 4 sensor channels (now either 12 bit parallel or Aptina HiSPI) with gamma and histograms, 16-channel DDR3 controller, 4 compressor channels, inter-camera synchronization and high-speed IMU logger. And AHCI SATA2 controller (with provisions to be later upgraded to SATA3). The last module uses 6%, others share other 78% slices. As most of them have 4 identical instances, it makes about 10% each. Years ago one similar channel (1 sensor, 1 compressor, slower clocks) was implemented on Spartan-3e.