Free FPGA: Reimplement the primitives models

[blackguardx]

As 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.

[Andrey_Filippov]

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.

[CamperBob2]

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.

[nickpsecurity]

Someone please tell these people about Archipelago FPGA:

http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-43...

It's already at 45-65nm with configurable logic and memory cells. They're working on multipliers next. Open-source flows for bitstream and synthesis already exist that can be targeted to this if it hasn't already. Lean on those people for something to use and you might get it. Write other students working in FPGA-related fields to contribute their prototype enhancements to Archipelago and all get published. We'll get stuff over time that commercial or grant-based efforts can turn into a real chip.

[Andrey_Filippov]

Thank you, at leas one of "these people" got it. Interesting project, but again - it is still far performance-wise. We really appreciate work of developers of the Free Software toolchain, but we work in a slightly different area as we need much larger devices. Yes, we use proprietary tools (with some limitations described in the original post). These tools are physically isolated from my workstation - they are held a "jail" - a separate Linux box controlled from the IDE on a Free Software -only workstation. Icarus/GtkWave are launched locally, but ISE/Vivado(tcl console)/Quartus - over ssh+rsync.

[ashitlerferad]

Here is the github for that:

https://github.com/haojunliu/OpenFPGA

[scott_wilson46]

It should be possible to write the majority of the code for an FPGA in a generic fashion and get the tools to infer things like RAM's by the way the Verilog or VHDL is written. Ideally, I think you should only have FPGA specific blocks in the very toplevel of a design and the majority of the design should be agnostic to the FPGA architecture. For example if you write your code like this:

  reg [31:0] mem[0:1023];
  
  always @(posedge clk) begin
    rd_data <= mem[rd_addr];
    if (wr_en)
      mem[wr_addr] <= wr_data;
  end

Then tools like vivado, quartus, synplify will infer a 1k x 32bits ram.

[Andrey_Filippov]

Scott, you are right, and I try to do it that way (there are many registers in the design with "_ram" suffix. But I did have some problems when Vivado incorrectly inferred small non-registered RAM as Block RAM.

I was able to modify the design (moving registers from inputs to outputs - https://github.com/Elphel/x393/blob/master/x393_sata/host/el... ) to force Vivado to infer correctly, but still have suspicion that it may not always be the case. So I used wrapper modules for Block RAMS with direct instances, they can be replaced as you suggested.

[femto]

A 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.

[Andrey_Filippov]

Project uses 84% of Zynq (7030), it will not fit in Lattice :-(

[microcolonel]

"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.

[Andrey_Filippov]

What objections do you have to the requirements to release documentation? Similar anti-monopoly laws already exist in other areas. It would make Clifford's job much easier (so you will benefit too), don't you think?