Double standards

It’s now been a little over two months since we announced Raspberry Pi 5, and the time has flown by. We knew we’d built something quite special, but we’ve been overwhelmed by the positive response from the community.

The production ramp has been steeper than for any previous flagship product: we’ve been producing 70,000 units a week for the last few weeks, and this rate is set to increase to 90,000 units a week by the end of January.

Once people had recovered from the shock of seeing both a power button and a real-time clock on a Raspberry Pi, one of the most commented-on features of the new platform was the small, vertical, 16-way FFC (Flat Flexible Cable) connector on the left-hand side of the board, which exposes a single-lane PCI Express interface.

The 16-way FFC PCIe connector


Peripheral Component Interconnect Express (PCI Express or PCIe) is, as the name suggests, a board-level interconnect that allows high-speed data transfer between a processor chip (in our case BCM2712) and external peripherals such as NVMe SSDs, Ethernet cards, or more exotic things like AI/ML accelerators.

PCIe works by serialising data transfers and sending one bit at a time down a single channel. Each channel sends data down one or more ‘differential pairs’ on the PCB, which are basically controlled waveguides made by two closely spaced wires (with a ground plane beneath) that can carry very fast signals with high noise immunity and low signal loss and distortion. For a single-lane (×1) PCIe interface, we have a single transmit pair, a single receive pair, and a clock pair. This means that three differential pairs (and six wires) are required. Higher-capacity PCIe interfaces have more lanes (×2, ×4, ×8, ×16); on Raspberry Pi 5, BCM2712 is connected to our RP1 I/O controller via an ×4 interface.

Each lane run at 5Gbits/s for PCIe 2.0 (the fastest mode that we officially support on Raspberry Pi 5); after coding overhead, this translates into a capacity of 4Gbits/s. Even taking into account other protocol overheads, you’re likely to see ~450MBytes/sec to and from a good NVMe SSD. Pretty fast!

Alongside the data and clock channels, the PCIe specification requires some sideband signals like reset, clock request (which does double duty as a power state signal), and wakeup.

Our 16-way connector provides all these signals. We also have two pins that allow us to control board power, and to ensure that an appropriately designed PIP (our new word for a PCIe Peripheral) is automatically detected by the Raspberry Pi firmware.

Not an M.2

Why didn’t we add an M.2 connector to the Raspberry Pi 5? The M.2 connector is large, relatively expensive, and would require us to provide a 3.3V, 3A power supply. Together these preclude us offering it in the standard Raspberry Pi form factor.

Using a small, low-cost FFC connector allowed us to provide a PCIe interface without growing the board, or imposing the cost of an M.2 connector and its supporting power-supply circuitry on every Raspberry Pi user.

Specification the first

One thing we did not have ready at Raspberry Pi 5 launch was a specification for how to build peripherals that attach to the 16-way PCIe connector. The interaction of PCIe peripherals with Raspberry Pi power states and firmware required detailed consideration, and we wanted to make sure we had done extensive testing of our own prototype product to make sure everything was working as expected.

Today, we’re releasing the first revision of that specification. Our own M.2 M Key HAT+ is in the final stage of prototyping, and will be launched early next year.

A prototype of our M.2 HAT. Nope, it’s not going to look like this, and it’s no longer “just” a HAT.

Specification the second

For those of you reading closely, you’ll have noticed that we’re calling our M.2 HAT a “HAT+”. If one new specification wasn’t enough for you, today we’re also releasing a preliminary version of the new HAT+ specification.

HAT+ on the Raspberry Pi 5 silkscreen, sort of gave the game away?

The original HAT specification was written back in 2014, so it is now very overdue for an update. A lot has changed since then. The new specification simplifies certain things, including the required EEPROM contents, and pulls everything into one document in the new Raspberry Pi documentation style, along with adding a few new features.

There’s still work to be done on this standard, and our EEPROM utilities haven’t yet been updated to support the generation of the new style of EEPROMs. So today’s release is very much for people that want to get a feel for how the HAT standard is changing.

We really wanted to get the HAT+ standard right, as it’s likely to be around for as long as the old HAT standard. One of the reasons for the delay in getting the PCIe connector standard published was our sense that PCIe boards (PIPs!) that go on top, rather than boards that go beneath, should probably be HAT+ boards. Ours is going to be!

Standards for Christmas!

We hope that the two new standards will prove to be enjoyable Christmas reading material. If you want to discuss them with the community, head over to the Raspberry Pi forums, where you’ll find a dedicated area to talk about HATs, HAT+ and other peripherals.

Watch this space for the new M.2 HAT+, and a final version of the HAT+ standard, which we’ll release alongside it in the new year.

Jump to the comment form

Naveen avatar

I am wondering whether the new M.2 M key Hat+ allow 2280 NVMe since the prototyping board looks small?

Reply to Naveen

Liz Upton avatar

Go have a look at the silkscreen in the picture!

Reply to Liz Upton

Naveen avatar

It says 2230 and 2242. I am looking for 2280 that is longer.

Reply to Naveen

Alasdair Allan avatar

Yup, and electrically using a 2280 will work just fine. Mechanically you can attach it with a cable tie perhaps? That’s not going to be officially supported though! 😆

Reply to Alasdair Allan

Naveen avatar

Or, maybe trim it down if there are no traces or components at the tail side. ;)

Anton avatar

Please, one question: there was an article [1] describing how to reduce power consumption of powered down Pi and the reason for that being not the default behaviour was attributed to HAT: “Apparently some HATs have trouble if the 3v3 power rail is off, but 5v is still active—which would be the case if you completely power off the SoC, but still have your 5V power supply plugged in.”
Does HAT+ bring any changes to this? Could you commend on the power consumption? Thanks!

Reply to Anton

Alasdair Allan avatar

From the HAT+ specification, “HAT+ boards must be electrically compatible with the STANDBY power state, where the 5V power rail is powered, but the 3.3V rail is unpowered.”

Reply to Alasdair Allan

Jeff Geerling avatar

Ooh, in that case, do you know if there may be plans to set the settings to power saving mode by default, instead of leaving the SoC power rails active?

Reply to Jeff Geerling

Ray Allen avatar

We can always trust Jeff to have a good question

Reply to Ray Allen

James Adams avatar

Maybe- we have been thinking about how to do this safely but also not confuse users with behaviour changing depending on attached hardware..

Reply to James Adams

andrum99 avatar

I don’t think changing the default would be a good idea, nor would the default changing depending on what was attached be sensible. Perhaps you could emit a kernel message when the Pi was running with nothing attached, or something other than a HAT (not HAT+) attached, containing a short URL pointing to a page in the documentation explaining that they can change the setting to reduce power consumption when the Pi is in the powered off mode, along with the various caveats? Also, a switch in raspi-config would potentially make it less scary to use for folk that are not tech savvy.

Laurent avatar

Regular PCIe opens up the way for so many potential upgrades, can’t wait to see Raspberry Pi and third party additions which will coming to our Pi 5.
I remember the very first Pi struggling with its shared single USB2 link, if someone told be that few years later we would have PCIe, USB3, Gbit Ethernet…
Good work folks!

Reply to Laurent

Theo avatar

I would really like to see a
M.2 M key + POE + Fan HAT+++
Yes, the one HAT to rule them all ;-)

Reply to Theo

Jeff Geerling avatar

I believe Seeed Studios (or maybe one of the other vendors) was working on a combo HAT with a fan and M.2 slot already. It would be interesting if someone could cram a 2230/2242, digital audio interface, PoE hardware, and a fan all into one tidy package. It might be expensive but would just about do everything I could imagine needing for many of my Pis :)

Reply to Jeff Geerling

Paul Miilligan avatar

I’d take my hat off to that one. Suspect it would cost as much as the Pi 5.

Reply to Paul Miilligan

Thor avatar

4Gbit translates to 400MB (in communication, all speeds and speed translations are in 1000’s, not 1024’s.) Which means that 400MB (base 10) translates to 381MiB (base 2).

Reply to Thor

DimeCadmium avatar

4000/8 is 500, not 400. 476MiB/s.

Reply to DimeCadmium

gus3 avatar

Storage is not the same as communication. The IP transmission involves breaking down into frames, then adding the TCP/IP wrapping to each frame, plus whatever raw network stuff (cable modem, DSL, wireless). And, in a “happy accident” of the Internet, each 8 bits of data turns into 10+ bits of transmission, on average.

Reply to gus3

Gary Stewart avatar

While the PCIe interface to the RPI controller is x4 (I assume that is what the IC on the board is for), per the cable specification the interface to the Pi 5B is x1. This limits the maximum data bandwidth to the Pi 5 to ~500MB/s or around 4Gb/s which is less than a SATA 6Gb/s interface.
Naveen, Pimoroni has in the works a M.2 PCIe board that mounts on the bottom of the Pi 5. and accepts 2280 SSDs.
I don’t believe they are shipping yet but they are advertising it.

Reply to Gary Stewart

PeterF avatar

Pineberry Pi (in Poland) has announced two NVME boards (1 top, 1 under) and have started manufacturing, testing and shipping. I took a punt and placed an order back in 3rd week of November. I got a shipping email last week. I’m now waiting to see how Fedex perform. X (F Tw) has more realtime information on how their manufacturing & despatch is going.

Reply to PeterF

Geist avatar

Does the PCIe implementation on the Pi5 support HMB (Host Memory Buffer)? Lower cost NVMe drives don’t include their own DRAM, instead using HMB to borrow a chunk of RAM from the CPU, but some host platforms don’t support it.

Reply to Geist

TheMoose avatar

I would love to have an answer to this question.

Reply to TheMoose

Gavin McIntosh avatar

“more exotic things like AI/ML accelerators.”
With two cameras, OpenCV etc could do with more acceleration. This is a good way to do it, for those that need it. Hmm, perhaps with a GPU/NN Hat+ running OpenCL?

Reply to Gavin McIntosh

Doug avatar

Woah, is that an RP2 chip I spot on the hat 👀

Reply to Doug

Liz Upton avatar
Tom Gidden avatar

To be fair, it does say RP2-B2 on it.

Reply to Tom Gidden

Liz Upton avatar

That’s an RP2040. It’s not present on the final device.

Reply to Liz Upton

andrum99 avatar

All RP2040s say RP2-something on the top of them, instead of RP2040. The something is the stepping, basically the version, of the chip.

Reply to andrum99

Alasdair Allan avatar

RP2 because it’s the second chip we designed. RP1 was the first chip, but didn’t appear in public till after RP2 because we shipped Pi 5 after we shipped Pico. RP3 is our first SIP and is used on the Pi Zero 2 W.

The fact RP2040 starts with RP2 is just a lucky (for us because nobody asked where RP1 was) coincidence!

Liz Upton avatar

Thanks M.A.! Appealing as ever.

andrum99 avatar

Technically the RP2040 is also called an RP2. However, the official name of the chip is of course RP2040.

Reply to andrum99

Carlos Luna avatar

That´s an RP2040.

Reply to Carlos Luna

Nick avatar

Would be nice to have an SSD main drive without resorting to USB plugs/leads faff.

Reply to Nick

Blaz avatar

When you get around to RPi 500 – or whatever it ends up being called – please please *pretty please* provide an actual M.2 slot on the main PCB, 2280 if possible (but shorter will do in a pinch). It doesn’t have to be super-accessible like the laptop drive bays, just provision enough space for it somewhere under the hood.
The way prices stand right now any add-on PCB/HAT will inevitably cost close to or more than vast majority of M.2 format accessories one might want to pair their RPi with.

Reply to Blaz

horace avatar

i agree. it would be a pity if a RPi 500 didn’t have a M.2 slot. and 8GB. :)

Reply to horace

Jim Darby avatar

Can I also add to that. The 400 can remain as the lower cost option but that 500 should have a M.2 interface. That would make it an absolute monster of a machine.

Reply to Jim Darby

ME avatar

So you are stating that the increase cost to implement this feature should be borne by everybody who buys whether or not that want it. Also how much more mainboard space would be required and what would be removed to accommodate. Yes wants are great, but reality is often an overriding factor. Last but not least *IF* a 500 appears it will already have been designed so you are a few years late for requesting.

Reply to ME

horace avatar

yes, since a RPi 500 won’t be able to use optional M.2 HATs a $10 price increase for a M.2 would be ok for much better desktop performance (IO is important for desktop snappiness!).

also it’s more like people state what would be nice. you don’t have to read it as requests. don’t take it so seriously. :)

R avatar

Thanks for the interesting update, James!
A nice NVMe PIP from pirates (supporting 2280):
In the future, it may be nice to see soldered SSDs as eMMC in CM4, despite the overcost… ;P

Reply to R

Red avatar

That design looks great, but I’m not a fan of the M.2 being sandwiched in the middle of the boards. It takes the open for a cooler on SSD off the table. I wonder if it would be possible to reverse mount it…

Reply to Red

R avatar

I completely agree, although it is probably better than sandwiching the SoC active cooler with a HAT+…

Reply to R

Aaron Holtzman avatar

A few comments on the spec after putting together a design that uses it.

Section 2 – Figure 2:
– indicate where the board edge is
– offset the connector pads like the real footprint
– add pin 1 indicator
Section 2.1 Pinout
– Add a table of all the signals and their I/O directions wrt to the RPI
Section 3
– suggest a part number for a compliant off the self FFC

Reply to Aaron Holtzman

Aaron Holtzman avatar

Also in Section 1, perhaps suggest a specific right angle connector suitable for use on the HAT+. What are you using on the M2 board?

Reply to Aaron Holtzman

Aaron Holtzman avatar

Also to add to that pinout table, which pair need AC decoupling on the HAT+ side. Presumably PCIE_RX which is Tx on the HAT+?

Reply to Aaron Holtzman

stan423321 avatar

The standby requirements seem solid. Power button keeps getting better.

I do appreciate the mention of the spacers for people with coolers, though I can’t help but wonder how that will work out.

The PIP tape flip requirement is a tough one. On one hand, certain business from my homeland just started making M.2 boards for one-sided tape. On the other, the mess-up potential is indeed high.

Would it have been that hard to backronym PIPE instead of PIP though and go full Sholmes with the theme? I think PIP would go better with HELMET or BERET than a HAT…

Reply to stan423321

Red avatar

Will the final design be compatible with the stock active cooler, or is it an either/or situation?

Reply to Red

Liz Upton avatar

They’ll be compatible.

Reply to Liz Upton

HemannSW avatar

Looking at the photo of the M.2 M Key HAT+ photo in this article, the hat PCB is on top of Pi5 USB connector height.
Now looking at my active cooler I see its top is lower than top of USB connectors.
Does “compatible” mean that the M.2 M Key HAT+ will be mounted on top of the active cooler?

Reply to HemannSW

Peter Strong avatar

Pleased to see the Specification Document released but puzzled by the lack of information in Section 2 re Pins 15 and 16, PCIE_RST_B and PCIE_CLKREQ_N. Surely these are relevant and provide some necessary functionality for this interface to work correctly? If not and they can be left as No Connect then some mention of that would be helpful. To not say anything about them is puzzling. I also agree with Aaron that it would be very helpful if inputs and outputs could be defined, particularly with regard to transmit and receive directionality out of and into the Pi5 interface, as it would seem that the letters TX in a pin label is not always an output and RX in a pin label not always an input in PCIe nomenclature ! Clarification here would be most helpful.

Reply to Peter Strong

CooliPi avatar

What is the nominal impedance of PCIe traces on a RPI5 board? PCIe has nominally 85Ohms, but it’s better to use the same impedance for cables as is for PCB traces. So I’m asking whether 85Ohms (may also be 93, 100, …) is used.
Nice discussion regarding impedance mismatches here:

Reply to CooliPi

Techclicky avatar

Can I run any games in this version of Raspberry Pi ???

Reply to Techclicky

Morgan Christensen avatar

Would you guys mind releasing the specs and documentation on the ffc connector so that 3rd parties can create pcie breakout (is that the right term?) boards so we can use pcie boards? If you already have, would you direct me to the docs?

Reply to Morgan Christensen

Ashley Whittaker avatar
Ashley Whittaker avatar

And the person that wrote that said:

PCIe connector standard should be read alongside the new HAT+ standard,

Reply to Ashley Whittaker

Leave a Comment