Recommended buffer capacitance on carrier board


Please I’d like to ask what is the recommended bulk capacitance for robust operation that shall be placed on custom made carrier board for SYS_VIN_HV and SYS_VIN_MV supply voltages?

We tried to implement similar values as on B03 carrier board. It was not that easy to get oriented in the schematic what all caps counts to SYS_VIN_HV and SYS_VIN_MV bulk capacitance, so we maybe missed something.

At the moment we have about:

  • about 300uF on SYS_VIN_HV
  • more than 350uF on SYS_VIN_MV
  • another more than 300uF on the supply input to our carrier board (de-facto direct connected to SYS_VIN_HV and input caps to SYS_VIN_MV buck converter)

I have to admit that at them moment we noticed occasional quite deep voltage drops on both SYS_VIN_HV (up to 2V) and SYS_VIN_MV (up to 3V). Voltage drops happens with occurrence in seconds to few seconds (but not periodically) and seems to be related to SoM module operation (ie even during booting). This supply voltage drops sometimes leads to some erratic behavior or reset of the SoM (especially when operating closer to lower input voltage range ~9V)

Are our bulk capacitors values reasonable or shall we consider adding more?

Many thanks

Actually after further measurement the SYS_VIN_MV voltage drops seems to be consequence of the voltage drop of SYS_VIN_HV, rather than the problem on it’s own. Our SYS_VIN_MV buck converter is momentarily disabled by the watchdog trying to restart the system after the surge on SYS_VIN_HV.

=> anyway the question about recommended bulk capacitance remains (but now mainly for SYS_VIN_HV).

Many thanks

We found no guidance either, so we just added in some bulk ceramic capacitance by each set of HV/MV pins near the 699 pin connector.

Not sure if what we did was good enough or not, but I agree that this is a gap in documentation, and probably could be reverse engineered by examining the carrier reference design - but would be much easier for the implementing design engineers to have a simple set of suggested values for each supply rail in the guide. Even if it is just the values that ended up near the connector in the nVidia design.

Thanks for suggestion.

But I really don’t like the idea of reverse engineering or experimenting. Nvidia carrier board is eval kit for development purposes with no aspiration to guarantee any reliability.
We need to design system that will be working robustly under defined operation conditions …

I am in agreement with you.

Hi, all capacitors of SYS_VIN_HV/MV can be found in the schematic of carrier board (P2822). Generally they are enough for normal power on. We really suggest customer to follow reference power part design of P2822.


As I mentioned above. We’re trying to design product that must work robustly over defined operational range.
Reverse engineering of eval kit is approach that would be appropriate if we want to do design also only some technological demonstrator (where are pretty much no other requirements that it should function “somehow”).

Please we would really appreciative if it would be possible to provide relevant information for proper supply design as is common for high performing chips. Ie.:

  • List of appropriate caps and their parameters (ie. capacitance & ESR)
  • PDN target impedance
  • allowed ripple for given load step
    …and similar

many thanks

Devkit can only be used for development not for product. You need to design the custom board to fit the robust work requests.

As for the info of caps and boards (P2822), please check the BOM and SCH in DLC.

To all at nVidia:

We understand that we as the designers are responsible for our own products - this doesn’t stop other companies that offer modules like this from providing some guidance or suggestions based on their own experience in making their evaluation kits.

Altera/Intel has a PDN tool that will literally tell you if you have reached your target impedance in providing power to their SoC.

Other developers of SoM carrier modules will often put notes in the carrier design guide like:

This net includes a 0.1uF cap. Add the bulk capacitance necessary to meet the USB specification for your device application. This will generally be 1uF to 100uF and is specific to the mode of operation for the USB endpoint.
Switching supplies are recommended as the best design practice. These reduce wasted power and
result in a better product design. As temperature increases in a design, the cooling requirements
become more onerous. Higher temperatures also increase part failures and reduce the MTBF of a

You’ve literally offered zero guidance at all - no specs on ripple, on module capacitance, even the sequencing and power-down information is nearly incoherent.

Then when folks come here and ask for help you just say ‘look at the eval board’ which by the way, ‘is not intended to be a product’.

So if the actual designers of the module can’t offer guidance or insight as to how to make a robust/rugged product with their own product, how are we supposed to have a better idea?

You are literally offering no support to basic hardware questions that any seasoned engineer would ask, and I myself asked and gave up when working directly with you.

These will be as successful as you are willing to support designers in using them, or people will give up and find a company that works harder to make designers have an easier time designing a very complex module into what is almost assuredly a more complex product.

Xilinx has like 10,000 pages of documentation on a single MPSoC family - you’ve got like 120 pages on designing hardware around this SoM. I hope you understand how shockingly light your support and documentation are.


Yes, the robustness of the design of our custom board shall be done by us, I completely agree. In order to do that we need relevant reliable input information about all components that we’re going to use, so Xavier SoM as well.

I guess that we all agree that doing reverse engineering of eval kit is not really the proper approach for getting reliable information.

Please would it be possible to address the Xavier SoM design team if they could provide some application note for this, or add relevant information into OEM Product Design Guide.

I understand that would a process that can take a while, but I believe that filing this important gap in the official documentation this is the right think to do.

Many thanks

Move discussion to same question topic