Many times we designers face an unassuming challenge. Pick the latest and greatest part... or go the old way and pick a less fancy part that gets the job done.

In this design the design for manufacture is important, and that includes the analysis of potential supply chain shortcomings.

In particular, the neverending issue of parts getting out of stock right before you hit the big red "MFG" button.

This could be less of a concern if the board had 10 or 15 types of parts, but with 100+ lines in the BOM, the odds are against you.

We can classify the risk of a non-stock line according to the damage it creates to the production schedule. For example if a resistor goes out of stock you can easily change the part#... but if suddenly your microcontroller goes unobtanium you are screwed. What's the cost and time required for software migration, testing, and pcb update and re-tooling? Hint: its very non-zero.

So for Axiom there are only a few dangerous components in this regard, and we can show the countermeasures we have taken:

MCU: A shortage of STM32F405 would be a disaster for a product like this, as the firmware despite making extensive use of ChibiOS its still heavily interwinded with low level peripheral access for max performance, so no easy migration.

Luckily we have a viable replacement that is the STM32F407, which is pretty much the same die with an ethernet peripheral. It can be more expensive but you don't care when you're against the ropes handling a shortage. Also, these ST oldies are ubiquitous and heavily stocked, it would be super odd to see a shortage.

FPGA: In general I find most HDL design software to be full of crap, so going for an open source toolchain gives some peace of mind here, as you could be locked away due to licensing for example. Then there is regular part# issue, which is actually what triggered this log.

Right now the super cool and amazing FPGA Axiom uses is non stocked in the major suppliers, so one would have to start poking the manufacturers or the shady suppliers that apparently have the part but you never heard of them. But here is where the strategy shines, we have already identified this as a possible issue and early in the game we developed the verilog code for a different family of fpga that happens to be pin compatible, and I assembled, tested and validated the board with the alternative part, so we were always ready for a shortage.

Connectors: Here's the weak point in our supply chain. Even if JST connectors, and Amphenol RJ45 - 4 port assemblies are common, there are no alternatives in the current design, so in case of a shortage its likely that we will need to update the pcb design and have a talk with the assembler about the change. This little deviation can easily translate to a $200 fee. At least there is no software development involved and likely no need to update the user manual.

IGBT's: This is another example of a part that can become difficult to source. The IGBT listed in the BOM is currently out of stock, but this is where the choice of using EconoDual becomes evident: we can easily use another part with the same package! So for now we upped the part voltage from 650V to 1200V, but there are many options, even a 1200V 1000A part is available (more about that in a future episode)

Power supply: You'll see that the LDO has non populated feedback resistors, thats because it allows to use the adjustable version in case the fixed 3.3V version goes dark. It also allows to run the MCU domain at a bit higher voltage, like 3.45V to have a bit better signal/noise ratio on the analog frontend (this has been validated on consumer grade boards but not for the high power builds).

The DC/DC supply already went through alternative mosfets, thanks to the common footprint used and the switcher IC comes in both Automotive qualified and industrial grade variants.

CANbus circuit: We had a few comments about that part of the schematic, like why did you choose discrete isolator+CAN phy? The answer is... supply shortages! We don't want to tie ourselves to fancy parts like the ISO1050, we use easily replaceable discretes.

So I hope you see where is this going, we really care about the present and future of this product and the platform it represents, and we want it to be relevant for many many decades. This kind of documentation is not something you will see in a product datasheet or in a user manual, and represents real value to our customers. It's no joke when we say its meant to be the next-gen motor controller.