Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

f4pga.org

Post reply on HN
Print view View original

21–30 of 32 posts

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

#21

Post by vardump »

jpm_sd wrote: post #20
vardump wrote: post #4

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 fr…

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 hobbyist…

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...

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

#22

Post by packetlost »

jpm_sd wrote: post #20
vardump wrote: post #4

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 fr…

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 hobbyist…

> 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.

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

#23

Post by jpm_sd »

packetlost wrote: post #22
jpm_sd wrote: post #20

Earlier quoted context omitted.

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 hobbyist…

> 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?

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

#24

Post by packetlost »

jpm_sd wrote: post #23
packetlost wrote: post #22

Earlier quoted context omitted.

> 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)

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

#25

Post by egberts1 »

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.

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

#26

Post by vardump »

jpm_sd wrote: post #23
packetlost wrote: post #22

Earlier quoted context omitted.

> 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?

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.

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

#27

Post by vardump »

packetlost wrote: post #24
jpm_sd wrote: post #23

Earlier quoted context omitted.

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.

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

#28

Post by packetlost »

vardump wrote: post #27
packetlost wrote: post #24

Earlier quoted context omitted.

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)

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

#29

Post by vardump »

packetlost wrote: post #28
vardump wrote: post #27

Earlier quoted context omitted.

> (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 i…

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

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

#30

Post by varispeed »

benrow wrote: post #11
zargon wrote: post #6

If only it were possible to buy such chips.

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.

Post reply on HN