But a STM32 is more than sufficient for the management interface on both.
(Like I like retro stuff and during COVID I bought an old DSP56k dev board with a book about the assembly language but oh boy, oh dear)
PIO has extraordinarily sloppy timing (skew in all categories) compared to the cheapest and smallest FPGAs.
Checking sketchier places Win-Source has the CLG400 package for $22.20 and even the cheapest aliexpress seller wants $4.84 for something marked as a 7Z010 that may or may not be legit.
Also "fight the chip" is pretty much the definition of what I did last time I did a zynq project. Just give me a plain FPGA and MCU with no wizards or GUIs or automatic code generation.
I've ordered trays (and they send the OEM tray) - unique barcodes, legit.
> Just give me a plain FPGA and MCU with no wizards or GUIs or automatic code generation.
You can pretty much cut out all of their tools and get a pure Yocto/Vivado TCL build for the bitstream for the 7 series Zynqs. Very low touch.
Their IO planner (in the Vivado IP integrator) is somewhat necessary for complex peripheral scenarios and is one of the few things I ever use Xilinx GUI applications for anymore.
On the chance they're half reasonable, thanks for the link.
I've previously struggled to roll the dice for higher end parts as the cost difference isn't as extreme and had some obvious reballed parts a few years ago. If they're OK then their $20 XC7K325T will be at the top of my list...
In the way that that Aliexpress vendor lists the 7010 parts at 1/10th the price of LCSC, some of their $20-60 listings are also shockingly cheap in comparison.
Thanks for your write-ups btw, been following glScope development for a while.
Nowadays, I only often wish I had their ARMv8 chips instead of the old ARMv7 32bit architecture because that’s just showing its age, but that’s par for the course of using ARMv7, and doesn’t affect the PL side (much, except for interfacing sometimes).
I've always wanted to do an FPGA project but haven't looked seriously into where to start. Can the Zynq 7010 handle something like data transfer from a 4K image sensor to a USB 3 transceiver?
> PIO has extraordinarily sloppy timing
Do you have any data on this? I was under the impression the PIO has fairly precise timing if you set up your clocks right, but maybe I've been misled here.
The Zynq 7010 is less-than-ideal for this because you'd have to use some kind of USB3 interface PHY - which would increase cost and be pretty limited functionality-wise.
If you use an FPGA with transceivers (some 7 series Artix chips - https://www.lcsc.com/product-detail/Programmable-Logic-Devic..., most 7 series Virtex/Kintex chips, all US/US+ chips), you can implement USB3 without an external PHY: https://github.com/enjoy-digital/usb3_pipe
The Z7010 probably has the area to do this type of translation but not the transceivers. There are other chips in the 7 series Zynq family with capable transceivers, but they are much more expensive ($15-$35 from CN).
> I was under the impression the PIO has fairly precise timing if you set up your clocks right, but maybe I've been misled here.
No measured data, but when I was once implementing JTAG and SPI at 50MHz+ with an extremely overclocked chip, the edges were very inconsistent in relation to each other and in pulse width - 5-15ns (estimating from memory, they were sloppy.)
PIO is very precise within its specified capabilities, this range is just very low compared to cheap FPGAs.
> PIO is very precise within its specified capabilities, this range is just very low compared to cheap FPGAs.
Good to know, I don't plan on pushing RP2040s to their limit any time soon. They're still excellent for lower speed projects.
The MCU is for control plane only. Several hundred Mbps between the control and data plane is more than enough for a SSH management CLI and poking registers on the FPGA to move a port to a different VLAN in response to a CLI command or add an ACL rule or something.
Embedded is about solving problems more physical in nature, as you are physically closer to reality in nearly all aspects.
--------
An MCU + FPGA project could implement... say... the VFIR IrDA (Infrared) protocol at 16Mbit.
Traditional IrDA is widely supported at SIR and MIR levels (upto 1.152MBit or so). Anything faster and the equipment has basically been lost to the 1990s (and never was very popular anyway).
IrDA I'd explain as a remote-controller on steroids. Its infrared based (like TV Remote Controllers), so you need to line up both devices and have them looking at each other. Infrared can reliably travel about 3 meters over the open air in a variety of conditions. IrDA allows for bidirectional communications. Its a truly wireless protocol, albeit one that requires significant alignment to function correctly. But ~3 meters is good range and practical for many applications.
Nominally, you could use an entire MCU to handle the encoding / decoding of these light-pulses. However, that's a bit redundant. Its far more cost efficient to dedicate a few LUTs in an FPGA to the task.
Yes, the MCU is needed for the final application-level / OSI layer 4/5/6/7 aspects of IrDA protocol. But the lowest PHY and MAC levels of the protocol can and (probably) should be a small section of FPGA.
Upgrading from standard MCU 1MBit to 16MBit would be a 1600% improvement to communications compared to what's readily available with commercial-off-the-shelf solutions. If you've determined that IR Communications is good for whatever purpose you're using, maybe the 1600% improvement is going to be useful.
------------
EDIT: The "physicality" of this is because photodiodes react very quickly to light pulses. And an expensive enough transistor can amplify that at the ~100MHz speeds needed to run VFIR (at least in theory. I've never done this).
The FPGA (or MCU if you go that route...) just needs to clock at 100MHz or so, and interpret the start-of-frame and end-of-frame signals, while also interpreting a few other low-level details. Overall, this turns the sequence of light pulses into bits-and-bytes for higher-level processing (which code can and should handle).
That's a bit of an overly broad statement.
I have several times at work done projects that use FPGAs to do things faster than a computer can do, e.g. some specific processing of a full 10Gbps UDP stream, which is much easier to get 100% reliable without packet drop in digital logic than it is in software land.
The FPGA+CPU combo allows you to do a LOT of things. I tend to use just a straight Zynq so I already have my memory buses wired up from processing system to digital logic, but this is an interesting architecture.