Live data from Hacker News

Free FPGA: Reimplement the primitives models

blog.elphel.com

11–17 of 17 posts

Re: Free FPGA: Reimplement the primitives models

#11

"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 F…

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?

Re: Free FPGA: Reimplement the primitives models

#12
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.

Re: Free FPGA: Reimplement the primitives models

#13

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…

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.

Re: Free FPGA: Reimplement the primitives models

#14

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…

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…

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

Re: Free FPGA: Reimplement the primitives models

#15
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 
Then tools like vivado, quartus, synplify will infer a 1k x 32bits ram.

Re: Free FPGA: Reimplement the primitives models

#16

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]; alway…

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.

Re: Free FPGA: Reimplement the primitives models

#17

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…

Here is the github for that:

https://github.com/haojunliu/OpenFPGA

Post reply on HN