4 ms·

random rant not really related to op but spurred by it: i know it will probably never happen, but it would be 'truly epic' if hard PCIe endpoints became as ubi

random rant not really related to op but spurred by it: i know it will probably never happen, but it would be 'truly epic' if hard PCIe endpoints became as ubiquitous as say, SPI peripheral blocks, within MCUs/MPUs and the general silicon jelly-bean world. just a very high speed, very low latency, very widespread, very standard, very boring communication channel. and ofcourse an atmega328p can't keep up with the full b/w, but even something like an rp2040 could take serious advantage of such a fast port. it would mean that fast information interchange would be available for "anyone", and most importantly, could be interfaced with a bog-standard run of the mill desktop PC. it feels like, right now, if you want to do pcie stuff you have to either go FPGA, which seem like theyre quite far behind: artix stuff is pcie gen 2, i think gowin announced some pcie4 products but im not sure if they ever became real - and fpgas ofcourse are expensive and drag in a bunch of other considerations that you may not want or may be detrimental to your project... or go for a limited selection of (often closed source) mcus/mpus, thankfully the raspberry pi isnt that closed, but if the rpi doesnt have what you want then you have to go for say a rockchip, or whatever asian SOC that often has a very ambivalent relationship with datasheet availability. and even then they might not support operating the pcie in device mode (might be misremembering) whatever, maybe im talking rubbish. i remember wanting to make some kind of USB3 gadget and being incredibly frustrated that the only option among the ocean of MCUs was the cypress ezkit bridged to a parallel bus to an FPGA. so lame! i think xilinx offered a usb3 peripheral IP block but it was behind an expensive license. i think since then there have become available USB3-capable RISC-V MCUs, thankfully, but im still surprised that nobody seems to really care about fast low latency data transfer. i guess its just not very important for "real" applications out in the wild.

Neywiny 2y ago
I'm hoping UCIe starts to fix this. It's touted as being something that can combine the low power with the high speed. As is PCIe is a relatively high power for anything that doesn't need the speed. You need to be moving pretty well past normal MCU interfaces (spi, uart, etc) before you see the power trade off. As is, PCIe would add sizable die area consumption, raise power consumption by an order of magnitude, and likely raise part cost dramatically. Couple this with cheapy board designs that often can't even get USB 1.0-2.0 right (recalling the amount of boards that get the pull up resistors or power supply schema wrong), and it sounds like a nightmare to manage. I think gigabit Ethernet is where I'd prefer the effort spent. Most micros have at most 100 Mb. NXP's i.MX RT line has gigabit but that's the only one I know of.
- sitkack 2y ago
  PCIe is extremely scalable, from Gen1 to Gen5. There is no reason that you couldn't extend one of the GenX specs down to Gen0 speeds. We are already drowning in transistors, I am not convinced by your area argument, esp in the face of shrinking nodes, we have more area than we know what to do with. https://eps.ieee.org/images/files/TC_article_Universal_Chiplet_Interconnect_Express_UCIe.pdf https://eps.ieee.org/images/files/TC_article_Universal_Chipl... https://www.hpcwire.com/2022/05/11/intel-says-ucie-to-outpace-pcie-in-speed-race/ https://www.hpcwire.com/2022/05/11/intel-says-ucie-to-outpac... I'd love to see UCIe scale down to SPI. I also agree on more pervasive use of Ge would be nice.
  - Neywiny 2y ago
    Yeah uh if you think microcontrollers are on 3nm... No. Most microcontrollers are on 28-40 if not larger. Lower gate widths can sometimes increase logic density and sometimes fmax but they dramatically increase static power, yields, and by extension cost (along with the other factors as outlined by your ieee source). This gross look shows what I believe are some PCIe block die areas. https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F4b5f0dbd-bd9c-4ac5-beee-fc0dd49b4dd9_1920x1080.png https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_pr... This is roughly half the size of what I've seen to be some of the smallest micros, and those are most likely not on the same lithographies. When you combine the amount of additional RAM/ROM needed to run a PCIe stack, maybe divide by 4 for 1 lane instead of 4 to be generous, you're still likely going to double the die area used. On top of that which I didn't mention earlier is that PCIe transceivers are going to need more per supply circuity. ST's been doing a good job of integrating things in for stuff like DSI but those app notes show more complexity than the aforementioned atmega328p which is so simple it can sometimes be run without decoupling caps on a breadboard. If you look at die shots for micros, a lot of the time you'll see most of the area is consumed by large arrays of SRAM or flash. And SRAM is known to not scale to lower lithographies. So, I don't expect to see this changing really. To be PCIe compliant you'll likely need to have the ability to store a full TLP. On a 328p, that could double if not more the SRAM needed. So the chip would get idk ballpark 3x bigger with all the stuff included? I just don't see manufacturers wanting to do this, which is likely why they haven't. There are very few cortex M chips with PCIe that come to mind. Some more cortex Rs. I figure if it was really the silver bullet, somebody would've done it by this point.
BeefySwain 2y ago
I may be way off here, but doesn't USB do what you want? Like if I have a Teensy and I want to plug a USB device into it, isn't that relatively simple? And fast?
- zamalek 2y ago
  These are on-board communication channels. I guess you could run USB traces, but you would end up using I2C or SPI (via a USB chip) for devices that don't have built-in USB - which is many.

Neywiny 2y ago

I'm hoping UCIe starts to fix this. It's touted as being something that can combine the low power with the high speed. As is PCIe is a relatively high power for anything that doesn't need the speed. You need to be moving pretty well past normal MCU interfaces (spi, uart, etc) before you see the power trade off. As is, PCIe would add sizable die area consumption, raise power consumption by an order of magnitude, and likely raise part cost dramatically. Couple this with cheapy board designs that often can't even get USB 1.0-2.0 right (recalling the amount of boards that get the pull up resistors or power supply schema wrong), and it sounds like a nightmare to manage. I think gigabit Ethernet is where I'd prefer the effort spent. Most micros have at most 100 Mb. NXP's i.MX RT line has gigabit but that's the only one I know of.

sitkack 2y ago
PCIe is extremely scalable, from Gen1 to Gen5. There is no reason that you couldn't extend one of the GenX specs down to Gen0 speeds. We are already drowning in transistors, I am not convinced by your area argument, esp in the face of shrinking nodes, we have more area than we know what to do with. https://eps.ieee.org/images/files/TC_article_Universal_Chiplet_Interconnect_Express_UCIe.pdf https://eps.ieee.org/images/files/TC_article_Universal_Chipl... https://www.hpcwire.com/2022/05/11/intel-says-ucie-to-outpace-pcie-in-speed-race/ https://www.hpcwire.com/2022/05/11/intel-says-ucie-to-outpac... I'd love to see UCIe scale down to SPI. I also agree on more pervasive use of Ge would be nice.
- Neywiny 2y ago
  Yeah uh if you think microcontrollers are on 3nm... No. Most microcontrollers are on 28-40 if not larger. Lower gate widths can sometimes increase logic density and sometimes fmax but they dramatically increase static power, yields, and by extension cost (along with the other factors as outlined by your ieee source). This gross look shows what I believe are some PCIe block die areas. https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F4b5f0dbd-bd9c-4ac5-beee-fc0dd49b4dd9_1920x1080.png https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_pr... This is roughly half the size of what I've seen to be some of the smallest micros, and those are most likely not on the same lithographies. When you combine the amount of additional RAM/ROM needed to run a PCIe stack, maybe divide by 4 for 1 lane instead of 4 to be generous, you're still likely going to double the die area used. On top of that which I didn't mention earlier is that PCIe transceivers are going to need more per supply circuity. ST's been doing a good job of integrating things in for stuff like DSI but those app notes show more complexity than the aforementioned atmega328p which is so simple it can sometimes be run without decoupling caps on a breadboard. If you look at die shots for micros, a lot of the time you'll see most of the area is consumed by large arrays of SRAM or flash. And SRAM is known to not scale to lower lithographies. So, I don't expect to see this changing really. To be PCIe compliant you'll likely need to have the ability to store a full TLP. On a 328p, that could double if not more the SRAM needed. So the chip would get idk ballpark 3x bigger with all the stuff included? I just don't see manufacturers wanting to do this, which is likely why they haven't. There are very few cortex M chips with PCIe that come to mind. Some more cortex Rs. I figure if it was really the silver bullet, somebody would've done it by this point.

BeefySwain 2y ago

I may be way off here, but doesn't USB do what you want? Like if I have a Teensy and I want to plug a USB device into it, isn't that relatively simple? And fast?

zamalek 2y ago
These are on-board communication channels. I guess you could run USB traces, but you would end up using I2C or SPI (via a USB chip) for devices that don't have built-in USB - which is many.