F4PGA: Open FPGA Tooling: Xilinx 7-Series, Lattice iCE40/ECP5, QuickLogic EOS S3 | Hacker News Reader

F4PGA: Open FPGA Tooling: Xilinx 7-Series, Lattice iCE40/ECP5, QuickLogic EOS S3

f4pga.org

95 pointspabs331 comments

It's an extremely nice breath of fresh air to use open source tools to compile an FPGA design.

Yes, can anyone comment on the xilinx 7 series support? Is bitstream 100% reversed today?

There are some phys missing like PCIe.

Anyone here ever try using this for only place and route, while sticking to the proprietary tools for synthesis and bitstream generation? I'm honestly not even sure how you'd start (generate xdc and edif in vivado, convert to more common formats, and somehow get timing information?). I get the impression a lot of emphasis is put on bitstream generation when it comes to open source fpga stuff. However, it seems like that's probably not where the real gains are for build time in any production system. Especially since there's no OSS supporting bitstream generation for the highest end boards anyway.

How do you want to do place and route for the high end boards that are not open/reversed anyway? Related to the gains, I don't think bitstream generation is the biggest emphasis, its just a no-brainer after you have everything reversed and can do place&route in OSS.

I agree it would be great for users to be able to mix and match EDA tools, but EDA tool vendors seem to disagree, and consider the state of poor interoperability among EDA tools as a nice barrier to entry. As far as I can tell open source tools work on bitstream generation because it is unnecessarily painful to interoperate with proprietary tools.

The sorry landscape of open source FPGA tools has kept me away from them whenever possible.

Programmable IO such as RP2040 (Raspberry Pi Pico) are eating a tiny (but increasing) part of FPGA lunch.

Altera (well, Intel) and Xilinx (well, AMD) are just hurting themselves by not working to move towards an open ecosystem.

Edit: Oh, so AMD is partially behind F4PGA. Well, points for them, perhaps it's time to move away from Altera altogether?

I avoid Altera altogether because Intel doesn't seem to care much about them. Quartus has either been abandoned, or received the barest minimum updates. Setting up a new system is an adventure in patches & workarounds.*

*It's possible that some of this has been remedied, I gave up on them a few years ago and haven't checked back...

The RP2040 is an example of a "microcontroller", a low-power processor with onboard program storage (typically Flash these days), and a bunch of handy peripherals (UART, I2C, PWM etc.) in a single small package. This is a modern type with 32 bit ARM processor but microcontrollers have been used by the millions, for decades(!) in consumer products, automotive hardware, etc. Not too many 8 bit machines used by hobbyists today, but 8051 and PIC and AVR live on in numerous product lines.

The RP2040 is definitely not pioneering here. More of a well-marketed "me too" device IMHO.

FPGAs, on the other hand, have always been for specialized applications. High speed signal processing for imaging, sonar, or radar. Boundary-pushing network interface design. That kind of thing. They use a ton of power and developers are hard to find.

I completely agree with what you said.

However, there are applications where you just need high speed "bit banging", where you pretty much had to use an FPGA before.

I meant to mention RP2040 as an example, since I was talking about it's PIO feature, not because other microcontrollers do not have similar features, but because it's the most well known.

For example, RP2040 PIO is flexible and fast enough to run DVI/HDMI purely in software. Bit banging at 133 MHz (and even at 252 MHz overclocked, I'm sure there's no need for the do-not-use-in-production OC disclaimer).

https://hackaday.com/2021/02/12/bitbanged-dvi-on-a-raspberry...

> The RP2040 is definitely not pioneering here. More of a well-marketed "me too" device IMHO

Have you actually used one or looked at the datasheet? The 4 PIO state machines are pretty unique in the MCU ecosystem as far as I can tell. It makes "bitbanging" a completely acceptable approach for a huge number of protocols.

Completely acceptable as a clever hack, or for real production designs?

It's the explicit purpose of the submodule. It's like a microprocessor with fine-grained clockspeed control (fraction of the main CPU clock) and like 9 instructions that focus on driving GPIO pins. There's FIFO queues for pushing/pulling data from/to the PIO from/to the main CPU, so you don't have to waste any real clock cycles (other than to make sure your buffers aren't starved)

> (fraction of the main CPU clock)

Just watch out for aliasing jitter at higher fractions (frequencies). If that's going to be an issue, it's best to use integer fractions of the main CPU clock, if possible.

Yeah, that's definitely a concern! The datasheets gives an example of serial communication and recommends using non-standard baud-rates to avoid this problem. It's not perfect, but my point was it's not just another MCU, there is actually some hardware that makes it somewhat unique.

You can also adjust the system clock if you're desperate, though I'm not sure if that would entirely eliminate jitter (I haven't tried it)

FPGAs definitely do have their place with their nice (fractional) PLLs and separate clock domains when it comes to applications like these.

I'd say RP2040 PIO good for real production designs. Better documented and less surprises than many (most?) other microcontrollers. Haven't used it professionally, though, so caveat emptor.

Ooooh, those are nice.

Reminiscent of my time with early Xilinx and their provided Linux ~2.28 version.

One of the those times where I as a software engineer (with home hobbyist electronic background) can actually fix the Rocket IO FPGA by doing the tweak-resynthesize-burn-testing cycles, extremely fast.

Great times, great times.

Are these tools able to handle the Xilinx blocks like BUFGMUX_CTRL? Or I should still have fun by myself? That makes the difference. Writing plain VHDL and constraints is the smallest pain point for me.

Yes, you can use existing blocks and IPs.

E.g. if you use the f4pga+migen+LiteX stack, this looks like this in the end: https://github.com/enjoy-digital/litex/blob/d36f98bf45c20e2f...

How is an fpga different from an emulator? From what I've read it looks like just a microcontroller that emulates a cpu chip.

I think the critical difference is that the 'emulation' is effectively done in hardware instead of software, so designs can be clocked much higher than traditional emulation (GHz+ speeds)

No, an FPGA is a lot lower level thing; it's basically a bag full of small logic blocks, each one that can only do a very small logic function (something like a 16 entry table lookup?) and some blocks of RAM and IO. The FPGA user has to figure out how to wire those blocks up to do what you want; you can build a micro with it, but you can build most other logic systems as well.

I think of it this way in terms of efficiency vs. flexibility vs. cost:

- fixed-function ASICs tend to be very efficient (as they are optimized for a fixed function) but are inflexible; cost can be very low in volume but design and lead time can be high

- FPGAs can provide much of the the functionality and efficiency of fixed-function ASICs, with increased flexibility - and overhead - due to reconfigurability; per-device cost is usually higher than an ASIC but may be good for low-volume designs; design and lead time are much shorter; they're also great for prototyping

- CPUs offer extreme flexibility due to software programmability, with commensurate overhead and potential loss of efficiency; highly optimized for software; (application) design/implementation time is usually lowest, and, for some applications, cost may be cheaper than an FPGA or a low-volume ASIC.

These aren't absolute rules, and there are also other intermediate points like as FPGAs with embedded CPU cores or soft CPU cores, CPUs with reconfigurable logic, etc..

I think it's interesting that over time many functions are "softwarized" when it just becomes cheaper and easier to put them into either a cheap commodity microcontroller or a CPU that is already in your device. I've seen designs (posted on HN I think?) where a vintage hardware CPU is implemented on a cheap modern microcontroller as a sort of drop-in replacement/upgrade for the original hardware.

I also like the flexibility of generic FPGA systems that can implement and/or replicate a range of hardware with highly accurate functionality and timing. It's also fun to design your own CPU and then run code on it at hardware speed, or your own custom network device that runs at line rate (see also programmable switching chips.)

If only it were possible to buy such chips.

https://www.crowdsupply.com/search?q=fpga

There's a good number of open source boards with relatively active communities.

I have my own boards, I need only chips. Looked at Spartan 7 from Mouser today. Initial happiness disappeared when I realized, that it’s January 2024 and not 2023.

Ah I see, yeah getting components nowadays is a challenge.

I received an ice40 hx8k breakout board two days ago, my first foray into FPGA. Looking forward to playing with IceStorm over the weekend.

Stock for these seems OK, at least in the UK where I am based. It was ordered from Farnell. Mouser also have them in stock, but the situation may be different in other countries.

It's not much problem getting one or two chips (but sometimes you have to pay even 10x or more the retail price to scalpers).

The issue is that if you have a design of an actual product in mind rather than just learning, then at current climate you have to secure all needed stock (+30% just in case) of chips before you even start. This is because even if you successfully complete the prototype, everything is working and ready for production run, chances are you will have to wait year or longer for the chips to come and that is not guaranteed. Sometimes you could buy it from unauthorised distributors, but they ask hefty premium that only makes sense if your product is niche enough so you can still make profit even after using now an extremely expensive part.

Also investing time in learning a platform is risky, because you don't know if in a year or two they decide to make the platform obsolete.

Thanks for explaining - I hadn't considered it from that angle.

Reply on news.ycombinator.com