Designing a Custom Carrier Board for AMD Kria™ SOMs Part 1

Over the past few years, AMD has released a series of SOM (System-on-Module) boards based on a specialized, custom-built version of the AMD Zynq™ UltraScale+™ MPSoC. This device is known as the AMD Kria™ SOM. So far, there are two versions of the Kria SOM available with the mid-range AMD Kria K26 SOM and the cost-optimized AMD Kria K24 SOM.

Along with the K24 and K26 SOMs, AMD has also released a few application-specific carrier boards to highlight their capabilities. There are two boards available for the K26 SOM (denoted by the "26" in their part numbers). The AMD Kria KV260 Vision AI Starter Kit is equipped with peripherals for vision AI applications, while the AMD Kria KR260 Robotics Starter Kit is equipped with peripherals for robotics applications.

For the Kria K24 SOM, there is currently one board available (denoted by the "24" in its part number). The AMD Kria KD240 Drives Starter Kit is equipped with peripherals for driving 3-phase brushless DC (BLDC) motors.

During my time of using and developing multiple applications for both the K24 and K26 SOMs on each of the aforementioned boards, I found myself wishing for some different features in a carrier card that led me to the decision to create my own custom carrier card.

Thankfully, AMD provides lots of helpful documentation for this effort in the form of a design guide (UG1091 - Kria SOM Carrier Card Design Guide) and a schematic review checklist for each Kria SOM.

In combination with the data sheets for each Kria SOM (DS985 K24 data sheet and DS987 K26 data sheet), I felt pretty confident that I had enough information to be able to design and layout the custom carrier card I wanted for my applications. But first, I'll explain what led me to this decision.

Background

As I mentioned previously, while I was able to successfully implement my applications using the AMD boards for the Kria SOMs, I was left wishing for a few additional features.

The most notable of these projects was my automated Lego robot car that I developed a vision AI application to implement basic obstacle avoidance for. The first version utilized the Pmod connectors and camera connection ports to take visual data in of where obstacles were, then drive two DC motors for steering and forward/backward movement accordingly.

In this first version, I used the K26 SOM with the Kria KR260 Robotics Starter Kit and placed the boards on the roof rack of the Lego car. This worked great until I started looking at power sources for the KR260 Robotics Starter Kit.

The DC input requirement of the KR260 Robotics Starter Kit (as well as the other two AMD boards) is 12V/3A. My original plan was to use a battery of some sort to power the KR260 Robotics Starter Kit that I could also mount on the Lego car, but I quickly found that there was no 12V/3A battery light enough for the Lego car to be able to carry.

Which lead me to redesign the setup to implement a small microcontroller that could be powered off a small 3.7V lithium-ion battery to drive the motors based on commands received via Bluetooth, and a RTSP security camera powered by a 9V D cell battery that streamed image data over Wi-Fi. This way, the KR260 Robotics Starter Kit could sit on my desk and control the Lego car wirelessly as long as it was within Wi-Fi/Bluetooth range.

This new design worked, but despite my best attempts, I wasn't able to fully eliminate all of the lag in the RTSP video feed between the security camera and the K26 SOM. So the Lego car ultimately couldn't navigate any obstacles that were less than a foot or two away because the K26 SOM was getting the image data with a 5 - 10 second delay at minimum.

During development of the second version, since I was using Edge Impulse (EI) to develop my obstacle avoidance ML algorithm (AMD FPGAs aren't officially supported so I wrote my own custom driver for it), I had been using a Raspberry Pi 4 so I wasn't stuck troubleshooting both my custom EI driver and my ML algorithm at the same time.

With the Raspberry Pi 4 (which only has a power input requirement of 5V/2.4A), I was able to easily place the Pi, a USB webcam, and 5V/2.4A portable battery on the roof of the Lego car without its suspension even sagging.

Since the Raspberry Pi 4 has built-in Bluetooth, I was able to simply transfer over the Python script from the K26 SOM I had been using to command the microcontroller module driving the motors.

And this is what sparked my initial idea that since I seem to gravitate towards using the Kria SOMs in edge-computing applications like this autonomous Lego car, a footprint/power optimized carrier card for such was what I needed.

Custom Carrier Card Concept

Because the Raspberry Pi form factor is such a universally common thing at this point (and dare I say standard in a way?), I decided to just make a Raspberry Pi carrier card that simply replaces Pi processing circuitry with the connectors for a Kria SOM.

After looking at the dimensions and power requirements of the K24 and K26 SOMs, I decided to go with the K24 SOM because 1) its power input requirements made it possible to be powered off a 5V/2.4A source and 2) its dimensions allowed it to fit within a Raspberry Pi footprint while still allowing room for the 40-pin GPIO header, Ethernet connector, USB ports, etc.

Using the dimensions from a Raspberry Pi 4 drawing and the dimension data for the K24 SOM from its data sheet: I superimposed images of the two with the actual dimensions to get an idea of what it would actually look like:

As I found with the KR260 Robotics Starter Kit, the Raspberry Pi GPIO header is basically a Swiss army knife of connectors because so many peripheral hats and adapters are available for it, and they can be stackable. This seemed like a great way to guarantee my carrier card could be universally used for any low/medium speed applications.

Since high-speed interfaces are a bit intensive in terms of PCB layout and I haven't utilized anything but 1G Ethernet thus far, I decided to just have a 1Gbps Ethernet for now (also there is already a designated spot for it in the Raspberry Pi layout haha).

This gave me the following list of peripherals to design a schematic for and layout on my PCB:

• 40-pin GPIO header
• USB PHY with 4 peripheral ports and 2 ports for JTAG/Power
• FTDI for JTAG & UART over USB
• 1G Ethernet PHY + RJ45 port
• AMD Kria K24 SOM connectors
• SD card slot + PHY

Power Supply Inputs

At this point, I know what my footprint is going to look like and I have a list of the peripherals I'm going to put on the board, so it's time to start the schematic design.

I decided to start with the input power circuitry, and because I want to match the power input of a Raspberry Pi (5V/2.4A) that left me with a few questions:

• Am I stretching the capabilities of a 5V/2.4A source to drive a Zynq UltraScale+ device? Yes.
• Is there probably a reason I haven't found any development boards with a Zynq UltraScale+ device that can be powered from a USB port? Most likely.
• Am I still going to try a design I know works for AMD 7 Series FPGAs? Heck yes.

According to the K24 SOM data sheet, the maximum input current you can drive into the main 5V power input of the SOM is 4A. So 2.4A isn't out of the question in terms of being viable, but it probably will limit my processing power at some point in certain applications. But maybe not, because the product table stated its maximum power draw is 7.5W and a 5V/2.4A can provide up to 12W. So I feel fairly confident that this isn't a totally dumb idea.

As a backup though, I decided to go the route I've seen other FPGA development boards take like the Digilent Arty-Z7 where both a wall wart and USB port and options for input power with some sort of switch to select between them.

Ultimately, a Kria SOM needs a 5V main power input, and that main input can be used to create all other necessary power rails (ie - 1.2V, 1.8V, 3.3V, etc. for the processing system and programmable logic).

Taking inspiration from the KD240 Drives Starter Kit schematic, I figured I'd reuse most of the main power supply circuitry, but splice in at the point where the 12V is stepped down to 5V with a 3-pin male header.

The 5V from the 12V DC jack would be on one end of the header, while the 5V from my USB input circuit would be on the other side of the header. Then with the pin in the middle of the header being the 5V that ultimately feeds the rest of the downstream circuitry. This way a jumper could be placed on one side of the header or the other to connect one of the two inputs.

The 5V USB supply circuit is a PMOSET controlled by a current mirror.

While I used different regulator chips in my SPICE simulation, I still was able to supply the amount of downstream regulators I think the carrier board would need with adequate current to create the 0.9V, 1.2V, 1.8V, and 3.3V rails I needed for all of the peripherals (which was about 1A - 2A).

Once I felt like I had improved my odds of the board not just being a magic smoke generator with my simulation, I went ahead and drew up the circuit in KiCad. And luckily every part I wanted to use was available in Ultra Librarian for me to add in their symbols/footprints into KiCad.

I also added test points for each of the voltage rails to make troubleshooting hardware later easier (hopefully I won't need them though).

Since I had filled up the first sheet with just the input part of the power supply circuitry and the always-on 5V (SOM_5V) and 3.3V (UTIL_3V3) domains, I decided to split out the regulators for the processing system peripherals and the programmable logic peripherals onto their own sheets.

Again, most of these circuits I just copied straight from the KD240 Drives Starter Kit schematic since they are just basic regulator circuits, and all of the parts are currently in stock. But if you choose different regulator chips, just make sure that they have a chip enable input signal and a power good output signal as these are required for the K24 SOM's boot sequence on a carrier card (explained in the next section).

In terms of processing system peripherals, I only need 4 different voltage rails:

• 0.9V for the Ethernet PHY
• 1.2V for the USB PHY
• 1.8V for the JTAG, Ethernet PHY, USB PHY, and watchdog timer
• 3.3V for the system EEPROM, Oscillator, Ethernet PHY, USB PHY, and SD Card PHY

While I only needed 2 different power rails for the programmable logic peripherals:

• 1.8V for the K24 SOM, and 40-pin Raspberry Pi GPIO
• 3.3V for the K24 SOM, and 40-pin Raspberry Pi GPIO

In a future revision I might add another regulator to create a 2.5V rail. Since I'm routing all of the GPIO of the 40-pin Raspberry Pi GPIO connector to programmable logic pins for maximum flexibility, only having a 1.8V and 3.3V rail supplied to the SOM will limit me to only being able to use those two values for IO.

As I briefly mentioned earlier in this section, there is intention in each power regulator chip used having an enable input signal, and before I explain that in the next section I also want to point out that all of the regulators powering peripherals connected to the K24 SOM's processing system are tied to one enable signal (VCCOEN_PS_M2C) while all of the regulators powering peripherals connected to the programmable logic are connected to a different enable signal (VCCOEN_PL_M2C). This is a hard requirement for a carrier board.

AMD Kria™ K24 SOM Power Sequence

While the K24 SOM is mostly an independent board, there is a specific power sequence its own power management circuit expects to see from a carrier board after it provides the main +5V power input (VCC_SOM). This sequence is the same for both the K24 and K26 SOMs.

As outlined in the Kria SOM Carrier Design Guide (UG1091), there are four main steps to this power sequence:

1. Once the power rail supplying VCC_SOM to the K24 SOM reaches +5V and is stable, the carrier board sets the POWER_OFF_C2M_L signal to logic level zero/low.

2. The K24 SOM kicks off its onboard power sequence.

3. The K24 SOM sets the VCCOEN_PS_M2C signal to logic level one/high to tell the carrier board to turn on the power regulators powering peripherals connected to the K24 SOM's processing system.

4. The K24 SOM sets the VCCOEN_PL_M2C signal to logic level one/high to tell the carrier board to turn on the power regulators powering peripherals connected to the K24 SOM's programmable logic.

In all of these "handshaking" signals between the K24 SOM and the carrier board, they are notated as following to easily tell which direction they go:

• C2M = Carrier to Master (K24 SOM)
• M2C = Master (K24 SOM) to Carrier

To help myself fully understand how this sequence would be executed in my schematic design, I drew up the flow diagram above with the individual actions of the K24 SOM (the gray bubbles) and my carrier board (the yellow bubbles).

AMD Kria™ K24 SOM Reset Sequence

Along with a specific power sequence, the K24 SOM also expects a specific reset sequence that ultimately requires a supervisor reset chip on a carrier board.

The main function the supervisor reset chip is to hold all output reset signals in the reset state while the main supply voltage is not at the needed value and/or stable.

Since the K24 SOM is a custom-built AMD Zynq UltraScale+ MPSoC device, there are two types of reset signals:

• PS_POR_B = Power-on reset signal of a Zynq UltraScale+ MPSoC device that is an active low reset and must be asserted (logic level one) during the power-on process.
• PS_SRST_B = System reset signal of a Zynq UltraScale+ MPSoC device that is also an active low reset but is more of a soft reset for debugging purposes since it doesn't clear a certain subset of PS power-on and error registers.

Now the Kria SOM Carrier Card Design Guide didn't really explain the sequence aside from defining what the aforementioned reset signals above were, it just points to the UG1085 Zynq UltraScale+ Device Technical Reference Manual for Zynq UltraScale+ devices in general (see the section titled POR Reset Sequence).

As a cheat to extrapolate the details specific to the K24 SOM, I looked up the Board Reset section in the Kria KD240 Drive Starter Kit User Guide UG1093 to make sure I had understood what the reset sequence specifically needed to be.

Which also gave me an example block diagram of how to configure my reset supervisor chip:

The most valuable thing I found in looking at the KD240 Drives Starter Kit as an example that I didn't see mentioned in the Zynq UltraScale+ Device Technical Reference Manual was that all processing system and programmable logic peripherals need to be held in reset for 25ms after the power regulators on the carrier board are powered up and stable.

Since this delay is triggered by the power-good output from those particular regulators (which they don't assert their own power-good signal until their output is on and stable), I have to assume this requirement is some sort of requirement of the K24 SOM itself.

Using the power-on reset sequence from the KD240 Drives Starter Kit User Guide, I added the 3 steps to my power-on sequence flow diagram:

The actual reset supervisor chip used on the KD240 Drives Starter Kit carrier board is behind a "contact us" wall when its part number is looked up on Renesas' website so I'm designing my own reset supervisor circuit until I heard back from them. Otherwise, I'd just copy that circuit from the KD240 Drives Starter Kit schematic as well (because why reinvent the wheel when you have a circuit that works and the parts are readily available?).

Power + Reset Sequence Circuitry

This is my first time designing a circuit with a reset supervisor chip, so I'm just going to break out the functionality I need then start through the list of Supervisors & Monitors on Newark until I find the chip that meets these needs.

First of all, the chip needs to hold the POWER_OFF_C2M_L signal high to hold the K24 SOM itself in reset until the main +5V power input is on and stable.

This requirement is easy and doesn't really narrow anything down for me since this is the core basic functionality of reset supervisor chips in general.

The other main functionalities I derived from the KD240 Drives Starter Kit user guide was the need to hold all peripheral reset signals in the reset state for 25ms and have an enable pin to also hold its output in reset until the CC_PS/PL_GOOD signals are asserted by the power-good outputs each respective power regulator chip.

A commonly used and currently in-stock part I found was the Micrel MIC2793 reset supervisor chip. It's a simple power-on reset chip with programmable delay input, enable pin, and manual reset to connect a push button to.

Ultimately, given the reset sequence between the K24 SOM and carrier card, I chose to use a dedicated MIC2793 for the main SOM 5V rail to output the power-on reset signal, PS_POR_B, to the SOM.

Then for each of the core power rails for the processing system and programmable logic (PS_3V3, PS_1V8, PL_3V3, and PL_1V8), I gave them each their own MIC2793 chip with the 25ms timeout programmed via a 4nF capacitor connected to the CTH pin and tied their enable pins to the power-good outputs from each respective power regulator chip (CC_PS/PL_GOOD).

I also tied all MIC2793 chips to the same manual reset source which is an active-low push button.

While this circuit simulates as expected, I'm still making quite a few assumptions based on the KD240 Drives Starter Kit user guide as to the reset functionality the K24 SOM is expecting, so we'll see if this works when I get my order back from the PCB fab house!

Boot Mode Signals

Every AMD Zynq MPSoC and SoC chip has boot mode pins to specify the physical device the boot firmware is located and read from during boot up. These physical devices can be an SD card, eMMC, QSPI flash, USB, NAND, or some external source via JTAG depending on how the boot mode inputs are bootstrapped via selection resistors.

For the AMD Zynq™ UltraScale+™ MPSoC that is on the K24 SOMs, there are 4 boot mode pins that should be boot strapped with 499Ω resistors to ground with boot mode pin 1 (MODE1_C2M) left configurable with a jumper between the bootstrap resistor and ground.

When all four boot mode signals are pulled low by placing a jumper on the header for pin 1, the boot mode is set to JTAG. Otherwise with boot mode pin 1 pulled high by the jumper being removed, the boot mode is set to boot the K24 SOM from the onboard QSPI flash. So in normal operation, the jumper is not present but for debugging purposes such as launching debug runs on hardware of applications from the AMD Vitis™ software platform, the jumper will need to be in place (which is why I highly recommend populating the jumper header in your carrier card schematic).

It is important to note that the K24 SOMs only support two boot modes: QSPI and JTAG. So they can only boot from either the Quad SPI flash that is on the SOM itself or via JTAG. They cannot be booted from an SD card or USB source. There is no point in making the boot mode pins on your schematic any more configurable that I have in mine with pin 1.

Next Steps

At this point with the power, reset, and boot mode elements of the design covered, I think this is a good point to break for a part two before I get into the super-specific elements of my carrier board design since this these initial elements are common to just about any AMD Kria™ K24 SOM carrier.

AMD sponsored this project. The opinions expressed in this project are those of Whitney Knitter. All opinions are provided by Whitney Knitter and have not been independently verified by AMD. Performance benefits are impacted by a variety of variables. Results herein are specific to Whitney Knitter and may not be typical. AMD, the AMD Arrow logo, Kria, UltraScale+, Vitis, Zynq and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this project are for identification purposes only and may be trademarks of their respective companies.