HN Academy

I haven't personally taken these so can't comment on quality but there is:

1. https://www.coursera.org/learn/vlsi-cad-logic

2. https://www.coursera.org/learn/vlsi-cad-layout

I second this course. It's awesome. The next step from there is probably Coursera's VLSI course, starting with https://www.coursera.org/learn/vlsi-cad-logic. It's all about how real-world VLSI CADs work.

⬐ fstephany

Thanks! I finished Nand2Tetris and was wondering where to look for a good next step.

You just described a few different sub-fields of computer engineering:

1. Processes, which involves lots of materials science, chemistry, and low-level physics. This involves the manufacturing process, as well as the low-level work of designing individual transistors. This is a huge field.

2. Electrical circuits. These engineers use specifications given to you by the foundry (transistor sizes, electrical conductance, etc.) and using them to create circuit schematics and physically laying out the chip in CAD. Once you finish, you send the CAD file to the group from #1 to be manufactured. Modern digital designs have so many transistors that they have to be laid out algorithmically, so engineers spend lots of time creating layout algorithms (called VLSI).

3. Digital design. This encompasses writing SystemVerilog/VHDL to specify registers, ALUs, memory, pipelining etc. and simulating it to make sure it is correct. They turn the dumb circuit elements into smart machines.

It's worth noting that each of the groups primarily deals with the others through abstractions (Group 1 sends a list of specifications to group 2, Group 3 is given a maximum chip area / clock frequency by group 2), so it is possible to learn them fairly independently. Even professionals tend to have pretty shallow knowledges of the other steps of the process since the field is so huge.

I'm not super experienced with process design, so I'll defer to others in this thread for learning tips.

To get started in #2, the definitive book is the Art of Electronics by Horowitz & Hill. Can't recommend it enough, and most EEs have a copy on their desk. It's also a great beginner's book. You can learn a lot by experimenting with discrete components, and a decent home lab setup will cost you $100. Sparkfun/Adafruit are also great resources. For VLSI, I'd recommend this coursera course: https://www.coursera.org/learn/vlsi-cad-logic

To learn #3, the best way is to get a FPGA and start implementing increasingly complicated designs, e.g. basic logic gates --> counters --> hardware implementation of arcade games. This one from Adafruit is good to start: https://www.adafruit.com/product/451?gclid=EAIaIQobChMIhKPax..., though if you want to make games you'll need to pick up one with a VGA port.

Silicon design & manufacturing is super complicated, and I still think that it's pretty amazing that we're able to pull it off. Good luck with learning!

(Source: TA'd a verilog class in college, now work as an electrical engineer)

⬐ None

None

⬐ amelius

There's also the field of "Computer Architecture", which is a level above the ones you've described.

I'd start with learning a hardware description language and describing some hardware. Get started with Verilog itself. I'm a fan of the [Embedded Micro tutorials](https://embeddedmicro.com/tutorials/mojo) -- see the links under Verilog Tutorials on the left (they're also building their own HDL, which unless you own a Mojo board isn't likely of interest). Install Icarus Verilog and run through the tutorials making sure you can build things that compile. Once you get to test benches, install Gtkwave and look at how your hardware behaves over time.

You can think of "IP cores" as bundled up (often encrypted/obfuscated) chunks of Verilog or VHDL that you can license/purchase. Modern tools for FPGAs and ASICs allow integrating these (often visually) by tying wires together -- in practice you can typically also just write some Verilog to do this (this will be obvious if you play around with an HDL enough to get to modular design).

Just writing and simulating some Verilog doesn't really give you an appreciation for hardware, though, particularly as Verilog can be not-particularly-neatly divided into things that can be synthesized and things that can't, which means it's possible to write Verilog that (seems to) simulate just fine but gets optimized away into nothing when you try to put it on an FPGA (usually because you got some reset or clocking condition wrong, in my experience). For this I recommend buying an FPGA board and playing with it. There are several cheap options out there -- I'm a fan of the [Arty](http://store.digilentinc.com/arty-a7-artix-7-fpga-developmen...) series from Digilent. These will let you play with non-trivial designs (including small processors), and they've got lots of peripherals, roughly Arduino-style.

If you get that far, you'll have discovered that's a lot of tooling, and the tooling has a lot of options, and there's a lot that it does during synthesis and implementation that's not at all obvious. Googling around for each of the phases in the log file helps a lot here, but given what your stated interest is, you might be interested in the [VLSI: Logic to Layout](https://www.coursera.org/learn/vlsi-cad-logic) course series on Coursera. This talks about all of the logic analysis/optimization those tools are doing, and then in the second course discusses how that translates into laying out actual hardware.

Once you've covered that ground it becomes a lot easier to talk about FPGAs versus ASICs and what does/doesn't apply to each of them (FPGAs are more like EEPROM arrays than gate arrays, and for standard-cell approaches, ASICs look suspiciously like typesetting with gates you'd recognize from an undergrad intro-ECE class and then figuring out how to wire all of the right inputs to all of the right outputs).

Worth noting: getting into ASICs as a hobby is prohibitively expensive. The tooling that most foundries require starts in the tens-of-thousands-per-seat range and goes up from there (although if anyone knows a fab that will accept netlists generated by qflow I'd love to find out about it). An actual prototype ASIC run once you've gotten to packaging, etc. will be in the thousands to tens of thousands at large (>120nm) process sizes.

⬐ namibj

If i correctly understand what you are saying, it cold pe possible to make a custom small chip for doing some crypto capable of a little more than what those smartcards offer for under 10k$? That would be awesome, from a trust perspective, at least if you could realistically compare the chip you get back with what you know to expect, using an electron microscope.

⬐ jsolson

Not for an ASIC without spending a LOT on tooling, and really $10k is awfully optimistic even if you had all of that tooling (I probably should've just said tens of thousands).

For <100k, yes, you can absolutely do a small run in that range.

Honestly, you might be better off just buying functional ICs (multi-gate chips, flip flops, shift registers, muxes, etc.) and making a PCB, though. Most crypto stuff is small enough that you can do a slow/iterative solution in fairly small gate counts plus a little SRAM.

⬐ namibj

In the usecase a lack of accessibility of sram content through probing is very important. The benefit of this over some μC or fpga is that you can account for every spec on a scanning tunnel electron microscope. And the high resolution xray you made before while the chip was still in it's package. Which you can compare with all the chips you will use and ship. It is sadly easy to backdoor with just a single hidden gate.

⬐ jwatte

If you do that, why wouldn't you use a FPGA or just a fast CPU? Microcontrollers and CPUs are blending in performance, and are cheap enough to plop on a board and call it done for many applications.

⬐ jsolson

Sure, but if really want to avoid trusting trust (and you're of the mind to build your own hardware), FPGAs and µcs offer a lot of room for snooping.

Given the GPs suggested use, it seemed trusting trust was not on the table.

Certainly even a tiny FPGA can fit pretty naïve versions of common crypto primitives, as can any modern micro-controller. Assuming you only need to do a handful of ops for whatever you're looking to assert/verify, that is by far simpler than building a gate-level representation :)

⬐ namibj

I was thinking about a chip with only sram for secret storage that could be bundled into a ID-1 sized card with some small energy storage for the sram (there are affordable .5mm LiPo Cells that fit inside such a card), and then use the card to fit some display capable of giving some little data out, as well as a touch matrix,possibly by just using a style similar to carbon-contacts on cheap rubber membrane keyboards, but gold plated like the smartcard interface. But it seems like you can't afford to store one decompressed ed25519 or dare rsa, so the idea is moot by virtue of requiring sub-100nm technology to fit at least some sram.

⬐ lvoudour

I actually want to understand the chip manufacturing process - design, prototyping (using FPGAs, etc), baking process in foundries. And also at least a basic understanding of how IP is managed in chip industry - like "IP core" is a term that I frequently hear but due to the myriad interpretations available online, I don't really understand what an "IP core" really means. Hoping to get useful advice from veterans in the chip industry.

I was about to write a thorough answer but jsolson's very good answer mostly covered what I had to say. I'll add my 2 cents anyway

- To understand the manufacturing process you need to know the physics and manufacturing technology. That's very low level stuff that takes years to master. There are books and scientific papers on the subject but it's a game very few players can play (ie. big manufacturers like intel and TSMC, maybe top universities/research centres). You can try some introductory books like Introduction to Microelectronic Fabrication [1] and Digital Integrated Circuits [2] by Rabaey if you're curious

- You can design ASICs without being an "expert" on the low level stuff, but the tools are very expensive (unless you're a student and your college has access to those tools). You need to learn VHDL/Verilog, definitely need the right tools (which, I'll say it again, are too expensive for hobbyists) and extra money to spend for manufacturing.

- FPGAs are different. No need to know the physics and you don't have to bother with expensive tools and foundries, the chip is already manufactured. My advice is to

(a) get an FPGA board. Digilent boards are a good choice as jsolson said, but there are other/cheaper solutions as well [3][4]. You'll still need software tools but (for these boards) they are free

(b) learn VHDL and/or Verilog. Plenty of books and online resources. A good book I recommend is RTL Hardware Design Using VHDL [5]

(c) I assume you know some basic principles of digital design (gates, logic maps, etc.). If not you'll need to learn that first. A book is the best option here, I highly recommend Digital Design [6] by Morris Mano

[1] https://www.amazon.com/Introduction-Microelectronic-Fabricat...

[2] https://www.amazon.com/Digital-Integrated-Circuits-2nd-Rabae...

[3] https://www.scarabhardware.com/minispartan6/

[4] http://saanlima.com/store/index.php?route=product/product&pa...

[5] http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471720925...

[6] https://www.amazon.com/Digital-Design-3rd-Morris-Mano/dp/013...

⬐ CyberFonic

The website http://semiengineering.com/category-main-page-sld/ is also has lots of interesting articles about semiconductor industry.

⬐ duskwuff

A quick warning about Embedded Micro: do not use the "Mojo IDE". It's extremely barebones, and lacks many important features -- in particular, it has no support for simulation workflows or timing analysis.

It is[0] and electrical engineering students make them pretty regularly, it's just much more expensive and complicated if you actually want to make a chip with the output of one instead of just simulating it.

[0]https://www.coursera.org/learn/vlsi-cad-logic

PART 3/3

MY PROJECT: I want to pave the way for FPGAs to be usable in everything from laptop/desktop computers to phones (if the static power consumption gets better). I have some very interesting ideas of what an average user could do with in system FPGAs that can be reconfigured at runtime.

My main target is fixing the huge tangled JTAG mess. I mentioned earlier that even though the JTAG standard is pretty solid, everything built on it and around it are highly non standard. There is one more problem; there were standards to address how to build boxes to let your PC talk JTAG since that is not the IEEE's area. Each company has their own JTAG Controller which is often USB. Each controller only works with the Company's software and only with the company's chips. The good news is that there is no physical reason these controllers can not talk to all JTAG devices. Each of them have custom USB protocols for how to make the box talk JTAG, and only the company's software knows how to talk to it. The limitation here is the software on the PC and not the controller itself. All we need is documentation on the controllers USB protocol, which is where my project started.

As a final note on JTAG controllers, almost all of them require being loaded with firmware every time they plug in. This means that you have to have the proprietary firmware available. But since this firmware is not allowed to be distributed by anyone other than the company that created it, even if we know the secret USB protocol, we can not use these controllers with our own open tools out of the box without writing custom open firmware for each one.

I first started documenting JTAG controller protocols. This is available on my github (though it needs to be cleaned up). Next I started work on an open tool for talking JTAG to all chips independent of what JTAG controller is used. I only support a few chips for now, but all you have to do to add support another JTAG controller is write a driver and all supported chips will work with it (independent of manufacturer). To address propriatary firmware issue, I started writing my own open source replacements and have a stable (though limited functionality) version of the Xilinx Platform Cable controller available on github. And I am working on firmware for digilent boards (including the Atlys). My next step is to rewrite my tool in something other than python (likely C though I have a fantasy of Rust). The future version will not require controllers to be USB (and will support controllers that use ethernet, PCIe, etc), will support more than just JTAG (Debug Wire, SPI, etc), and likely be a daemon that keeps track of all jtag hardware. I want to see tools like OpenOCD (provides GDB interfaces to embedded systems, etc) to replace its dated controller architecture with calls to my daemon. I want to unify how all of these devices are communicated to so we have something to use when we get configurable FPGAs on the PCIe bus so the kernel or user software can configure them as needed.

NOTES: The mathematical theory and how to implement it in computers of the de-duplication step of SYNTHESIS, the TECHNOLOGY MAPPING step, and the PLACE AND ROUTE step are all taught in the VLSI CAD Coursera course https://www.coursera.org/course/vlsicad http://diamondman.github.io/Adapt/ My initial configuration tool https://github.com/diamondman/adapt-xpcusb-firmware Firmware for Xilinx Platform Cable

⬐ nkurz

Brilliant writeup, thanks! Please publish this somewhere more permanent and resubmit so it gets more attention (and hopefully discussion).

⬐ diamondman

My friend put it up on his blog until I get around to making mine again. http://curtis.io/others-work/open-tooling-for-fpgas

You can write the tools you describe on top of any existing tool stack -- you'll just have to use the hardware description language as an IL. (Indeed, many tools already do this.)

You could write your own synthesis front-end and place-and-route back-end, but they're not like any compilers you've ever seen before. (A recent Coursera class [1] went into pretty good detail about how synthesis and place and route work.) I think that the unfamiliarity is probably why there are no Open Source toolchains for it.

For Virtex-II platform, Xilinx provided a tool to edit bitfiles, called JBits [2], but it seems to be well and truly dead[3].

[1] https://www.coursera.org/course/vlsicad

[2] http://www.xilinx.com/labs/projects/jbits/

[3] http://forums.xilinx.com/t5/Virtex-Family-FPGAs/Question-abo...

⬐ lambda

Sure, you could use tools that target the HDL as an IL, if you wanted to write that code yourself and then ship it to your customers as a binary blob, as their HDL compilers need to be specifically licensed, and aren't, as far as I know, something designed to be used as a back-end component in shipping software.

But that limits its usefulness for something like, say, writing a GLSL compiler so you can use your FPGA as a GPU, and are then able to run arbitrary GLSL code on it.

I agree that it's definitely a much different than writing a compiler backend for a CPU. You are definitely going to have different abstractions that will apply well to it. But that's fine; that's what I'm interested in, writing a compiler for a very different kind of platform. The problem is, as far as I can tell, they don't document their actual bitstream format, so you must use their licensed tools any time you actually want to compile something new for the FPGA. And that precludes a lot of use cases.

The author touches on this, when he says:

"To write Verilog that will produce correct hardware, you have to first picture the hardware you want to produce."

I think that's the crux of the issue. Most digital designers do have a picture of the actual hardware, as a block diagram, in their heads. When I write RTL, the process is very front-loaded: I spend hours with a pen and paper before I even sit down at the keyboard. The algorithms in question are only a small part of the work of building functioning hardware; where when designing software, I would let the compiler make decisions about how long it expects certain operations to take, and what to inline where, these are all things that I plot "by hand" when building hardware, before I even open a text editor.

I think, then, that the author kind of misses the point when he goes on to say that "you have to figure out how to describe it in this weird C-like [...] language" -- to be honest, that's the same for all types of programming: when I go home and write C, I have to take abstract concepts and express them in this weird C-like language, too! Arcane syntax is irritating, but is not something fundamentally 'hard' (unless it's too arcane, anyway).

By the way -- I also often wondered "why the hell does synthesis take so long?". I originally assumed it was because Xilinx's (and Synopsys's, and ...) software engineers were terrible and had no idea how to write efficient programs. This might be true, but I now believe is probably not the majority of it; if "why's it taking so long?" is a question that interests you, I recommend looking into the VLSI CAD tools class on Coursera.

[1] https://www.coursera.org/course/vlsicad

⬐ sateesh

Thanks for the course pointer. It seems to me that there is no new offering of this course in near future. Do you have any pointers to similar online courses related to VLSI CAD tools ?

⬐ alok-g

>> if "why's it taking so long?" is a question that interests you, I recommend looking into the VLSI CAD tools class on Coursera.

Could you please provide a summary? I know optimization is hard and thereby slow. But is that why? Thanks.

⬐ cyanoacry

By far, most of my time spent in FPGA dev so far has been envisioning the state machines and timing details involved. I use VHDL, so it's never been a question of "how can I make VHDL output what I want?"---for me, it's always the struggle of "why can't I just ask VHDL to make n of these units?", where n is some upstream provided number.

I think the author might need to step away and look at it from the other side: how can we take a working, but overly-verbose language like VHDL and make it more powerful? At least VHDL was envisioned from the beginning as a hardware description language, and it definitely shows.

⬐ DigitalJack

Generate statements are your friend.

⬐ cyanoacry

VHDL generics and generate work nicely for 1d cases, but for 2d cases (systolic arrays), it's difficult to make the scripting really work without hard-coding a bunch of corner cases.

Another example is that defining barrel shifters is impossible to parameterize, because you need to hardcode the mux cases (see the Xilinx datasheet[1]). That's kind of insane, considering that bit-shifting is a very common and basic operation. This is particularly problematic if you're trying to describe something without having to resort to platform-specific instantiation blocks.

It's a little frustrating that VHDL doesn't have a higher-level standard instantiation library, because you're chained to a platform the moment you start doing anything other than basic flip-flops.

[1] http://www.xilinx.com/support/sw_manuals/2_1i/download/xsisy... (pg 51)

⬐ ta_vhdl

Why not using a higher level language like confluence, or some other tool which help you generate the verilog boilerplate for this kind of situation?

⬐ DigitalJack

Well, I suppose you could say assembly is an analog of writing hdl that is very structural.

I haven't done it myself, but generates can be nested. You'd have to check to see if your tools support it or not though.

With the xilinx example, I'm not sure what you mean. Is it choosing to do multi-level muxing vs a naive muxing solution? I'd start by just writing a simple behavioral version, and only if that didn't meet performance constraints would I bother doing anything structural about it.

It's late and maybe I'm just not thinking it through. I'll take a stab at some of this and maybe it'll be clearer to me.