[HN Gopher] Recreating RP2040 PIO Interface in an FPGA
       ___________________________________________________________________
        
       Recreating RP2040 PIO Interface in an FPGA
        
       Author : f_devd
       Score  : 63 points
       Date   : 2023-05-21 16:51 UTC (6 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | Accujack wrote:
       | As soon as I read about the programmable I/O setup, it reminded
       | me of the Propeller series chips from Parallax. The "cogs" that
       | are the main processors of those chips aren't as general use as
       | something like the STM32 cores, but they do certain things very,
       | very well.
        
         | mysterydip wrote:
         | The P2 is a huge step up from the old propeller. If you haven't
         | checked it out, I recommend it. "smart pins" are able to do all
         | kinds of things, almost like having mini cores along with the
         | main cogs. I used it for a project and was able to achieve all
         | my goals. Really happy with it.
        
           | yetanotherloser wrote:
           | You've got me intrigued,but also wanting more specifics. Did
           | you share any details of this anywhere you can link to?
           | (don't worry if not, I'm just nosy)
        
             | mysterydip wrote:
             | https://www.parallax.com/propeller-2/ tons of improvements
             | in terms of memory access etc, but pay attention to the "64
             | smart pins" section specifically. I use them to buffer out
             | sub-microsecond waveforms 3ms at a time. I send it off to
             | the smart pins then my cog is freed up for other things. I
             | also previously used some for an HDMI GUI.
        
       | synergy20 wrote:
       | that's very cool, maybe one day it can be burnt into a CPLD or
       | integrated into other MCUs' designs directly.
       | 
       | Motorola used to have CPM, TI has PRU for higher end chips.
       | 
       | All of these are doing similar things: using software to create
       | IO peripherals on the fly.
        
         | bri3d wrote:
         | The Pi engineers claim that at least some aspects of PIO are
         | "patent-pending," [0] so a 1:1 reimplementation in another MCU
         | would probably infringe on some claim or another eventually.
         | 
         | Yes, software defined I/O is not uncommon which is one reason
         | I'm quite curious about the specific claims in the PIO patents.
         | Another good example is the Infineon Peripheral Control
         | Processor (PCP) used in Tricore. It's much more powerful ISA
         | wise than PIO, but conceptually extremely similar.
         | 
         | 0:
         | https://forums.raspberrypi.com/viewtopic.php?t=307115#p18374...
        
           | snvzz wrote:
           | Disgusting stuff.
           | 
           | Meantime, RISC-V is trying to standardize GPIO, Watchdogs and
           | other common peripheral interfaces.
        
           | [deleted]
        
       | sfrigon wrote:
       | That's interesting!
       | 
       | If AMD incorporates scaled down Xilinx's FPGAs into their
       | x86-family product line, that could bring a lot of RasperryPi's
       | community effort into a mainstream products too (home PC) and let
       | us experiment embedded software directly on our PC! ...and break
       | our main PC during our experiments too, oopsie. But it would be
       | worth it haha.
        
         | coupdejarnac wrote:
         | You can already experiment with fpgas on a pc. Get Vivado, and
         | then you can code and simulate logic.
        
         | ThrowawayTestr wrote:
         | While I love the idea of FPGA co-processors on CPUs, I'm
         | wondering how useful they could be. I guess you could replace
         | the video transcoding unit so you're not tied to one codec but
         | how often do those change anyway.
        
           | Accujack wrote:
           | Check out the Xilinx "Zynq" series of FPGAs. They have a lot
           | of uses.
        
             | rcxdude wrote:
             | In that case the CPU is basically the co-processor for the
             | FPGA. I've yet to see a use that wasn't primarily using the
             | FPGA because it needed to be an FPGA, they're not great if
             | you just want to run something fast (outside of a few small
             | uses).
        
           | sfrigon wrote:
           | I must admit I did not think this whole thing fully.
           | 
           | But what was interesting to me was the fact that you could
           | add a peripheral that was not initially intended by the
           | manufacturers, making a mainstream motherboard more
           | versatile.
           | 
           | For you it may be a video transcoding unit, for someone else
           | it may be an SPI or I2C device, PCIe, or extra ethernet, or
           | high quality audio.
           | 
           | I'm not sure what peripherals were implemented by the
           | community for the RP2040 either, maybe they would not make
           | sense on a PC.
        
             | bpye wrote:
             | Doesn't PCIe already get you that today? Either with an
             | existing PCIe -> X bridge chip, or an FPGA with PCIe
             | capability?
             | 
             | It's not cheap, and you need to write device drivers etc -
             | but that's the case regardless.
        
               | sfrigon wrote:
               | Maybe PCIe already does something similar, that's not
               | something I have knowledge about.
               | 
               | Though there is a small difference in my opinion, where,
               | from the point of view of the CPU, it should behave as a
               | normal interface, thus the driver should already exist,
               | and only require a change in the device tree (for linux).
               | 
               | It would still require quite a bit of work: - The PIO has
               | to behave bug-for-bug compatible with an existing driver
               | - The exposed pins need have the proper voltage levels &
               | electrical protection
               | 
               | .. but that's just fantasy for now.
        
             | mschuster91 wrote:
             | > I'm not sure what peripherals were implemented by the
             | community for the RP2040 either, maybe they would not make
             | sense on a PC.
             | 
             | Well, someone implemented bit-banging Ethernet TX:
             | https://news.ycombinator.com/item?id=35810281
        
         | marcosdumay wrote:
         | Always keep in mind that one of the harshest limits on PC
         | design is the number of pins on the CPU.
         | 
         | I really doubt we will see GPIO pins available directly from
         | the CPU, and if they don't come directly from there, there
         | isn't much difference from using a PCIe or USB adapter.
         | 
         | Or, in other words, what you want can already be done about as
         | well as it will ever get. The hype for adding FPGAs into PCs is
         | for using them as co-processors, completely inaccessible for
         | any other hardware.
        
         | aseipp wrote:
         | What you're asking for now exists, Zen 4 mobile SKUs allegedly
         | ship a Xilinx design on the die for "AI Acceleration" (some of
         | their Versal fabric over some weird bus), that has absolutely 0
         | external software consumers beyond some vaporware about video
         | effect software for Windows 11 e.g. background image removal
         | and background noise removal. They really just aren't very easy
         | to program or use externally, and require lots of integration
         | work, and that remains a major limiting factor in practice. The
         | pure silicon-area overhead is also pretty severe compared to a
         | fixed ASIC (think ~50-100x worse), limiting their practical
         | size.
         | 
         | There are other considerations; large FPGAs are kind of slow to
         | program and have limited or fixed support for multi-tenancy,
         | for example, you have to carve up the device into fixed units
         | ahead of time and divvy those out, and unused resources cannot
         | be re-used. It seems like "time-multiplexed" FPGAs, such as
         | what Tabula was trying to accomplish before going bankrupt,
         | might be better suited for that, which has other tradeoffs. I
         | do wish you could get something high-speed, attached to a
         | desktop class processor.
         | 
         | Fun peripherals aren't really the reason for the RPi's large
         | community, anyway. That result is mostly a mix of software
         | support, pricing, and being in the right place at the right
         | time.
        
           | oscillonoscope wrote:
           | Coarse Grained Reconfigurable Arrays (CGRAs) are the only way
           | I see accelerators taking off. They reconfigure a lot faster
           | and I believe they have better area utilization at the
           | expense of bit-level programmability. I don't see many use
           | cases for the FPGAs bit-level reconfiguration in an
           | accelerator anyway so I doubt it would be missed.
        
           | yetanotherloser wrote:
           | "compared to a fixed ASIC" seems like a bit of a harsh
           | comparison.
           | 
           | The ideal fixed ASIC is as die-facilities-efficient a
           | solution to a particular problem as you're going to get. The
           | ideal FPGA is as generalised a solution to a large bucket of
           | problems as you can get. Do they have to compete?
           | 
           | Ease of programmability though, there I agree and more. A
           | chip facility can't be exciting or even interesting if it's
           | hidden behind being a giant pain in the backside to drive.
           | 
           | (disclaimer: I used to be really interested in this stuff,
           | but the problems I was interested in were eaten up by general
           | processors and simple uses of GPUs and I'm just not
           | interesting enough to have problems that really justify
           | exciting hardware any more... more power to you if you still
           | do)
        
       ___________________________________________________________________
       (page generated 2023-05-21 23:00 UTC)