
Free FPGA: Reimplement the primitives models - chei0aiV
http://blog.elphel.com/2016/03/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.

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

~~~
duskwuff
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.

------
nickpsecurity
Someone please tell these people about Archipelago FPGA:

[http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-43...](http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-43.pdf)

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.

~~~
nickpsecurity
"but we work in a slightly different area as we need much larger devices"

Doing analog design at a deep submicron node is _very_ hard and expensive.
Unlikely to be open-sourced. That's why I encouraged you to find academics
developing digital cell libraries or open-source FPGA's to tell them what you
need. They might develop it for you as part of their academic work.

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

Good that you're making an attempt. Must remember threat model, though:
hackers hitting box from firmware to OS to software to audio/wireless devices
onboard; subversion of EDA tooling lets them active trap door with simple
command or hide exploit in an update; physical theft of the box. You need
mitigation for each of them.

A separate box is always best. Use write-only media for backups of source and
for updates to EDA software if possible. The box distributes its software
either via a data diode for one-way transmission or a CD burner. Full-disk
encryption to mitigate theft optionally with tamper-resistant marking on PC
and inspections for keyloggers/implants. That you use OSS simulation after
proprietary tooling is smart and my exact recommendation. ;)

Btw, check out Qflow as there's not enough projects testing it and providing
Cliff feedback:

[http://opencircuitdesign.com/qflow/](http://opencircuitdesign.com/qflow/)

------
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...](https://github.com/Elphel/x393/blob/master/x393_sata/host/elastic1632.v)
) 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](https://github.com/Elphel/x393)

[2] [http://www.clifford.at/icestorm/](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 :-(

~~~
femto
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?

~~~
Andrey_Filippov
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.

------
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?

