Bare Metal Programming Made Easy: Beginner Roadmap

What Is Bare Metal Firmware

Bare metal firmware controls hardware directly. There is no operating system and no background scheduler. Every operation is handled through low-level C programming and direct register access.

On a custom ASIC, this firmware performs tasks such as:

• Initializing clocks, PLLs, and power domains
• Running Boot ROM routines
• Setting up memory interfaces like SRAM and DDR
• Configuring custom peripherals
• Running initial hardware tests

This is the first code the chip executes after reset.

Why Bare Metal Development on ASICs Is Different

• No vendor libraries – There is no HAL, CMSIS, or predefined startup code. Everything must be written by the engineering team.
• Custom and evolving hardware – ASIC documentation is internal. Firmware, RTL design, and hardware teams work together continuously.
• Hardware software co-verification – Issues can arise from firmware, RTL logic, timing, or clocking. Debugging needs close coordination.

Development Workflow for ASIC Bare Metal Firmware

1. Defining the boot flow and memory map

Before writing code, the engineering team defines:

• Reset vector
• Boot ROM boundaries
• SRAM regions
• Peripheral address ranges
• External memory layout

This becomes the base for the linker script and startup code.

2. Setting up the toolchain and build environment

Since no SDK exists, the team creates:

• Compiler setup (GCC or LLVM for ARM or RISC-V)
• Custom linker scripts
• Startup assembly for reset handling
• Minimal C runtime

Startup code usually:

• Initializes the stack pointer
• Sets up .data and .bss
• Jumps to main

Everything is built manually for full control.

3. Creating hardware abstraction layers

Because the ASIC is custom, the team writes:

• Register maps
• Reset values
• Bit masks
• Driver initialization functions

This is based on RTL or Verilog specifications. Tools like SystemRDL, JSON, or IP-XACT can auto-generate register files.

4. FPGA-based prototyping

Before silicon is ready, firmware runs on FPGA platforms or hardware emulators.

• Register access verification
• Clock & PLL configuration
• Memory tests
• GPIO functionality

5. First silicon bring-up

When the first ASIC arrives, early testing includes:

• Reset sequence execution
• Clock and PLL setup
• Built-in self-tests
• Memory initialization
• UART logging

A simple UART print is often the first major post-silicon milestone.

6. Firmware for silicon validation

After basic bring-up, firmware is used to verify real silicon behavior:

• Timing margin checks
• Power domain transitions
• DVFS testing
• Peripheral validation
• OTP and security fuse tests

Challenges in ASIC Bare Metal Firmware Development

• No second chances – Hardware bugs cannot be fixed after fabrication. Firmware must provide workarounds through patches or configuration tweaks.
• Limited debug options – Early silicon may not have JTAG or trace units. Debug depends on UART, GPIO toggling, or status registers.
• Complex co-verification – Issues can arise from RTL, timing, or firmware logic. Teams must work in sync.

Best Practices

• Begin firmware development long before silicon is ready.
• Use FPGA and simulation platforms extensively.
• Maintain automated tests for every peripheral.
• Continuously update specifications as RTL evolves.
• Use defensive coding and assertions.
• Include mechanisms for Boot ROM patching.

Conclusion

Bare Metal Firmware Development for a custom ASIC is like guiding a new chip through its first steps. It requires strong hardware understanding, low-level embedded expertise, and close coordination across firmware, verification, and design teams. Done correctly, it ensures a stable and reliable ASIC.