Hi, professional FPGA developer here. A couple of things I would advise:
Firstly, development kits are great - they provide the hardware you need and all of the IP to drive that hardware. Grab a dev kit - there are lot's of other posts advising you which one. The IP that actually interacts with the real world is by far the most difficult bit.
Secondly, 99% of hardware design is simply know what actually maps to hardware. It's important to understand that hardware languages fit: FPGAs, ASICs, simulators. So what can be coherently written in VHDL/Verilog can't necessarily work if it doesn't map to the hardware platform you're writing for. So you need to actually understand the structures of an FPGA - LUTs, Registers, DSPs and Memories. Once you know what you're writing you're 90% of the way there. Real FPGA devs spend months in simulators before they get to actually hardware test. The simulator will allow you to do things that the compiler will warn you about and the hardware will simply do wrong. Each compiler (modelsim, Vivado, Quartus, VCS etc.) will have a unique interpretation of the language you're using.
Finally, in terms of tools, use whatever comes with your dev kit, but in terms of simulators Modelsim is industry standard and Intel (Altera) ships a free version.
I don't really have advise for learning material- I learnt at Uni.
I think it's because so many of them are sold/licensed that way. You buy an Arm core, an Ethernet, USB or BT interface, etc. Often you do it from your EDA (electronic design automation) vendor so that it fits into your design/test/layout flow. Even the ones you don't pay for often can't be redistributed. Lots of them are literally black box or "hard" IPs that you can't change or test except through defined interfaces... but they often have been validated much more than anything you can write and may be much smaller or lower power than you would naively write.
I would attribute the weird FPGA dev attitudes to Stockholm syndrome. I always get the most mind boggling replies in defense of the evil vendors when I criticize FPGA’s embarrassingly small amount of freedom.
> [black box components] often have been validated much more than anything you can write and may be much smaller or lower power than you would naively write.
Sure but if an entire community was validating and improving these common components, they’d be way better still. (See gcc/llvm, linux, git, etc).
Hardware validation is like hardware startups, much harder to do. With software, all you need is a computer, time, and will. With hardware, your toolchains have a material cost, a calibration cost, shipping cost, shipping schedules, in addition to a computer, time, and will. If you screw up your equipment or prototype, thats at least another week or month of waiting for replacement parts.
Software is like music, as long as the instrument is works, all you need is time and will to develop/create.
Yup. If you have an engineer who's paid $100 000 a year with three weeks vacation, that's 407.05 a day. It starts to make sense that you'd buy $4000 IP for an Ethernet core, unless by some ungodly powers they can write that in less than 10 days.
If you have an engineer who's paid $100 000 a year with three weeks vacation, that's 407.05 a day. It starts to make sense that you'd buy $4000 IP for an operating system, unless by some ungodly powers they can write that in less than 10 days.
I see what you're trying to say, but the analogy doesn't exactly work. Everyone still uses a COTS operating systems because the cost of building one from scratch is so high. We're lucky that the market provides multiple free options, but if it didn't the rational business move for most projects would be to license one.
It's also worth noting that are clear examples of closed-source software that essentially acted like malware. I've not heard of any such examples with IP cores.
This whole thread is frankly, so dumb. One of my best friends is a SoC designer at Apple and we talk about this stuff all the time.
First thing people need to understand: this whole world operates at scale. You don't bother making an ASIC unless you really need one -- you're either making millions/hundreds of millions of them, or the individual application is so high-value that the hassle, complexity, and expense of moving off a general-purpose CPU onto something completely custom is worth it.
Second, 4K is chump change. You need an entire team of people to do anything meaningful with FPGAs/ASICs. Less than that, just buy a $100 CPU that will do more, be immediately available, and have an entire software stack (OS, user-space programs, compilers, etc) for it. And teams that know how to build this stuff well cost MONEY. A lot of it. Not $100K/year. More like $250-300K minimum per person at Silicon Valley rates.
I get that the OP wants to do this as a sort of hobbyist undertaking, just realize, he's cutting against the grain of the entire ecosystem. Everything about this stuff is made for huge companies to do massive projects that will ship at gargantuan scale. Not hobbyists in a garage.
The major part of hardware development is NOT tooling. It is manufacturing the hardware.
I disagree with this, you don't necessarily need a whole team of people and massive amounts of cash to do FPGA development and you don't necessarily need expensive tools. For my current company I created a complete FPGA based trading system from scratch on my own with free tools (apart from Vivado which I just used to turn my RTL into an actual design I could put onto the FPGA board). The board I used cost around £2k and the Vivado tools were £4k (athough if I was going to do it again, it appears you can just pay for your usage of Vivado using the cloud (nimbix has machines that have the Vivado suite on them). The cost to the company for this is pretty much my salary + the board costs.
His point still stands as all the tooling and IPs are the same for FPGA and ASIC and ASIC drives developement of new IPs and tools. FPGA are still the minor market here by far
Place and route tool is different and IPs might use different memory and multiplier macros depending on technology. Serdes transceives will also be different. Ideally this is all hidden from the integrator by parameter selecting technology.
Linting tools, simulation tools, formal verification and synthesis tools are all the same. Verification methodology is also the same.
Tooling is a blip on the radar of the cost of the designs I work on. Verification is usually the most expensive aspect. 10x tooling even if the tools were purchased for, that project alone, which would be very unusual.
However, for open source to flourish, high quality open source simulators are required. I think if we had that, synthesis and place&route would follow. You don't need synthesis or par to do design and verification, but you do need simulation.
I look into the state of OS simulators periodically. Some are impressive, but mostly just handle the design basics... an OS systemverilog, static and dynamic, simulator would be a game changer.
It's a Herculean task though. I don't know how much Xilinx makes off tooling. I have to think they would make more from FPGA sales if tooling were free, and if it were open source, it would no doubt be improved upon by degrees I can only fantasize about.
Simulators, and by extension synthesis and place & route tools, are complementary goods to FPGA hardware. Make your complementary goods cheap, and you make a lot of money.
But there are tool companies out there such as Mentor and Synopsys that make a lot of money from such proprietary tooling. I imagine simulators have a tough patent field to navigate.
> when I criticize FPGA’s embarrassingly small amount of freedom.
It takes a critical mass of knowledgeable people who don't necessarily want to be compensated monetarily for their efforts for this to happen (think early GCC and Linux teams). It took a few decades of largely unpaid effort before GCC and Linux convincingly took over as the leading compiler and OS respectively and people started being paid to work on them. To achieve the end you have in mind, you will need to start building that community
> I would attribute the weird FPGA dev attitudes to Stockholm syndrome. I always get the most mind boggling replies in defense of the evil vendors when I criticize FPGA’s embarrassingly small amount of freedom.
I'm not sure you understand FPGA development. Until FPGA manufacturers do something like software vendors where they bundle actual malware with the closed-source hardware they sell, it doesn't really bother me.
Personally, I kind of prefer having detailed documentation of a black box rather than trying to read source code. The latter is all too common in software development.
I have multiple FPGA designs in use today. What does or doesn’t bother you is irrelevant.
I don’t really care to explain the obvious net win that open source designs (and tools) are for society. The only argument I’d consider reasonable is that the FPGA/hardware world is too small to justify the initial investment.
Writing robust cores is usually substantially harder than writing the equivalent software library. You usually have to design the logic to satisfy various different criteria (area, performance, or power), and, especially when implementing high speed design, take into account the targeted device.
Unfortunately, the number of people who are competent to design, test, and implement these cores is fairly small, and usually well funded. Oftentimes, these cores represent very non-trivial time savings, especially when it comes to characterizing performance and closing timing, so there is tremendous value in the marketing and selling of these cores.
On the other hand, sites like opencores are great for finding useful IP that people have contributed and may be adapted to your device.
Firstly, development kits are great - they provide the hardware you need and all of the IP to drive that hardware. Grab a dev kit - there are lot's of other posts advising you which one. The IP that actually interacts with the real world is by far the most difficult bit.
Secondly, 99% of hardware design is simply know what actually maps to hardware. It's important to understand that hardware languages fit: FPGAs, ASICs, simulators. So what can be coherently written in VHDL/Verilog can't necessarily work if it doesn't map to the hardware platform you're writing for. So you need to actually understand the structures of an FPGA - LUTs, Registers, DSPs and Memories. Once you know what you're writing you're 90% of the way there. Real FPGA devs spend months in simulators before they get to actually hardware test. The simulator will allow you to do things that the compiler will warn you about and the hardware will simply do wrong. Each compiler (modelsim, Vivado, Quartus, VCS etc.) will have a unique interpretation of the language you're using.
Finally, in terms of tools, use whatever comes with your dev kit, but in terms of simulators Modelsim is industry standard and Intel (Altera) ships a free version.
I don't really have advise for learning material- I learnt at Uni.