Clifford Wolf

Regarding the ASIC part: There are several good courses online that explain the whole process from hardware description in a hardware description language to GDSII file, which you could send to a foundry in some detail. See for example this course https://web.csl.cornell.edu/courses/ece5745/, there are also very good courses available from Berkeley and MIT. What is usually missing is the more gory details of the backend flow, which can become very involved and complicated depending on your design and process.

Unfortunately someone who has no access to the EDA tools by cadence / synopsis or standard library files from foundries, cannot really follow along all that far, you are limited to working at the RTL level.

There are several good open source RTL simulators available, I have personally used mostly verilator, which supports (almost) all synthesizable constructs of system verilog and has performance close to the best commercial simulators like vcs. It compiles your design to C++ code which you can then wrap in any way you like.

You should also check out https://chisel.eecs.berkeley.edu/, which is a hardware description language embedded in scala, the nice thing about it is that it has a relatively large number of high quality open source examples, designs (https://github.com/freechipsproject/rocket-chip) and a library of standard components available, something which can't really be said of verilog / vhdl unfortunately. As an added bonus you can actually use IntelliJ as…

No - it's the massive investment in tooling.

I see comments like these all the time about 'open source bitstream generators' and whatnot. If you have a very simple, regular architecture, then P&R (place & route) is relatively simple, and has been done (there is an open-source bitstream generator for the Lattice iCE40 chips, see http://www.clifford.at/icestorm/). This line from that page in particular:
"It has a very minimalistic architecture with a very regular structure. "

For anything close to a modern FPGA, the P&R is only the start of the problem - timing is the next big one. Having a large design not meet timing can be a nightmare, but the tools take delay (extracted from the design) into account for routing, so you'd have to add that; also, I think the amount of effort to get the "hard macros"/specialized in-silicon blocks configured correctly would be amazing. You'll notice that even in the iceSTORM project, PLL's and timing analysis are not yet implemented. I use the Xilinx Zynqs at work, and they contain high speed serdes, dual-core ARM processors, and a boatload of other items.

There are large teams who are employed full-time, and frequently get their Masters/PhD with a specialty in VLSI/EDA, developing these algorithms, testing them extensively, and then implementing them. With the money someone like Xilinx brings to the table, they can pick those individuals out from school directly.

It isn't a CPU, and it never will be. I'm amazed at what free software can…

You should not use AWS F1 instances if you are just starting out. They will burn a nice-sized hole in your wallet and the only thing you'll get in return is confusion and frustration as a beginner.

The AWS F1 devkit and APIs are largely oriented around making OpenCL-based designs easy and fast to develop (using Xilinx's "SDAccel" framework), but if you're just starting out you almost certainly want to start with classic RTL development using Verilog or whatnot. But "traditional" RTL development is substantially more involved. The documentation and the environment itself is largely oriented with the assumption you're a semi-experienced RTL developer and there's no real way around that part. (For example, even when using OpenCL, you're going to have a hell of a time optimizing anything without understanding real RTL/digital design principles.)

The F1 also has a non-trivial build system, meaning you have to do literally everything on AWS. Not a deal-breaker, but considering the equivalent of a "Hello World" will take you something like 30+ minutes to compile using something like a t2.2xlarge, and anything beyond that will be multi-hour (yes, this isn't an exaggeration) -- you probably don't want to just be spending money on every minor iteration.

I would suggest getting a cheap Lattice FPGA and using Project Icestorm, which is a free FOSS Verilog toolchain, in order to get started. This will cost you closer to $20 USD. https://www.latticesemi.com/icestick and…

I'm on my first foray into FPGA development, using IceStorm as the toolchain for a Lattice iCE40 FPGA (iCE40HX4K) to implement a system controller for my homebrew 6502 single board computer. The FPGA is (work in progress) doing clock management, address decoding, memory bank switching, SPI comms, some GPIO, and bootstrap to RAM from SPI flash memory.

It's fantastic having an open-source toolchain! It's why I chose the Lattice iCE40, and perhaps what got me over the line to even try FPGA development; the closed proprietary tools are very off-putting to new starters. I had previously dabbled with a Xilinx FPGA dev board, but spent most of my time battling the giant Xilinx ISE toolchain.

Big thanks to Claire Wolf for creating IceStorm and making FPGA dev more accessible to software engineering types like me.

Aside (cc: dang?) I think http://bygone.clairexen.net/icestorm/ is the newer/better canonical URL for IceStorm, since the creator changed their name, as linked to from their projects page at https://www.clairexen.net/projects and mentioned at the bottom of the current http://www.clifford.at/icestorm/ page.

> However, if this initiative takes off, it'll be a big help in creating an open source EDA toolchain community.

The opensource EDA toolchain community is already producing some good stuff, Symbiflow: https://symbiflow.github.io/ is a good example, it's an open source FPGA flow targeting multiple devices. It uses Yosys (http://www.clifford.at/yosys/) as a synthesis tool which is also used by the OpenROAD flow: https://github.com/The-OpenROAD-Project/OpenROAD-flow which aims to give push-button RTL to GDS (i.e. take you from Verilog, which is one of the main languages used in hardware to the thing you give to the foundry as a design for them to produce).

The Skywater PDK is a great development, which is a key part of a healthy opensource EDA ecosystem though there's plenty of other great developments happening in parallel with it you will note there's some people who are involved in several of these projects they're not all being developed in isolation. The next set of talks on the Skywater PDK include how OpenROAD can be used to target Skywater: https://fossi-foundation.org/dial-up/

For some context this is a very popular and cheap series of FPGA devices. For example you can buy the Arty board which has one of these FPGAs for $99 (https://store.digilentinc.com/arty-a7-artix-7-fpga-development-board-for-makers-and-hobbyists/), or the slightly more advanced Nexys 4 DDR for $265 (https://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommended-for-ece-curriculum/).

Currently you must use the Xilinx Vivado tool which is a 40 GB download [no, that isn't a typo], requires a paid license to unlock the full features, and is generally awful to use.

This work should eventually lead to a complete open source toolchain to program these devices, just like Project IceStore for the Lattice devices (http://www.clifford.at/icestorm/ https://rwmj.wordpress.com/2018/03/17/playing-with-picorv32-on-the-ice40-hx8k-fpga-breakout-board-part-1/)