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.
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.
Those primitives are just a way to force the synthesis tool to infer specific hardware features.
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.
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:
reg [31:0] mem[0:1023];
always @(posedge clk) begin
rd_data <= mem[rd_addr];
if (wr_en)
mem[wr_addr] <= wr_data;
end
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.
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.
Out of curiosity, is there any one block/function that is consuming a majority of the cells? What is that block?
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.