DG32-LITE is the lockstep motor-control SoC; DG32-2DOM adds an INT8 attention engine on its own clock. Choose one for its diagram, every block and why it exists, the constraints that shaped it and how data moves through it, or see the die as recorded for tape-in.
DG32-LITE / LOCKSTEP ARCHITECTURE
DG32-LITE combines a RISC-V microcontroller, the peripherals a brushless drive needs and a hardware safety monitor on one 130 nm die. The monitor is a second, identical core that runs two cycles behind the first. If the two ever disagree, the chip latches the first cause and drives a pin that can turn the power bridge off without waiting for firmware.
Six block groups share one deterministic bus on a single 50 MHz clock. Below: the four constraints that shaped the chip, then the full diagram, every block and why it exists, and how a control loop, a boot and a fault move through it.
ARCHITECTURAL CONSTRAINTS
Read across a row to see what each constraint means and what the design does about it.
| Constraint | What it means | What the design does |
|---|---|---|
| No debugger halt on the die | Nothing outside the chip can stop or inspect a hung CPU, and there is no management core to rescue it. | Every bad access returns a bus error instead of hanging; blank flash starts a UART monitor; the watchdog catches hangs and runaways. |
| Lockstep core fmax ~55–62 MHz | The CPU pair is the slowest block on the die; every peripheral hardens above 90 MHz. | The whole die runs one 50 MHz clock domain, with margin under the core’s ceiling. |
| ~8 clock cycles per instruction | The core fetches every instruction over the bus, so control maths in plain C is slow: an int8 multiply-accumulate took 54 cycles, not the ~6 a cached core gives. | Sampling, the Park transforms and PWM edges move into dedicated blocks; the CPU keeps only the PI regulators. |
| Memory macros have no spare bits | There is no room for parity or ECC in the 130 nm SRAM macros. | The chip ships without memory ECC and says so. The idle second read port becomes a feed for a DMA or accelerator. |
THE BLOCK GROUPS & ROLES
Select a group to highlight it on the illustrative die and read what every block inside it does, and why it was built that way.
GROUP 01 / SAFE
Motor control drives power electronics. A silent CPU fault can destroy a bridge; a second core that must agree bit-for-bit turns that fault into an observable signal.
MAIN runs the application; CHECKER runs the same instructions two cycles later on mirrored inputs and bus responses.
WHYTwo cores that must agree bit for bit turn a silent datapath fault into an observable one. Mirroring the bus responses means firmware can branch on peripheral reads without the cores diverging.
Compares every committed store; the first mismatch sets a sticky latch with its cause and drives FAULT_N.
WHYComparing on the store gives a signature that does not depend on external timing, and the first cause is the diagnostic one. A locked injection register lets firmware fire the path on purpose, the only way to prove it on real silicon.
Two supply-good inputs with deglitching and reset sequencing, plus a watchdog that faults on a kick that is too early or too late.
WHYA window catches runaway code as well as a hang. It arms only when firmware enables it, so it can never hold the chip in reset on a cold boot.
The 3D model is illustrative: region placement indicates grouping, not the fabricated floorplan.
DETERMINISTIC DATA PATHS
Three sequences explain most of the chip: the current loop it exists to run, the boot it performs on its own, and what happens when the two cores disagree.
About 300 hardware cycles, the same at every loop rate.
The PWM period centre fires the ADC, where current ripple is lowest.
The SAR ADC converts the phase current: 177 cycles.
CORDIC runs the Clarke/Park transform with the encoder angle: 53–58 cycles per operation.
The CPU runs the d and q PI regulators in plain C at ~8 cycles per instruction.
CORDIC runs the inverse Park rotation.
New duty cycles load into the PWM shadow registers at the next period boundary.
No management core and no debugger: the ROM is the whole path.
The ROM prints a boot banner on UART0.
It reads and checks the image header in external QSPI flash.
It copies the application into SRAM.
It jumps to SRAM; the application installs its trap handler and enables interrupts.
With no valid image, a UART monitor starts so a bare board can still be read, written and started.
From a wrong value to a safe bridge, without firmware.
A transient or permanent error changes a value the MAIN core is about to commit.
CHECKER runs the same instructions two cycles later on mirrored inputs and bus responses, so it commits the correct value.
Every committed store is compared. The first mismatch is caught on that store, not at the next software self-test.
A sticky fault latch holds the first cause, because later faults are usually its consequences. Firmware can read it after the fact.
FAULT_N goes low within 39 cycles of an injected fault in simulation. Wired to the gate-driver enable, it stops the bridge without waiting for firmware.
LOCKED DESIGN DECISIONS
These are settled. Each trades something away on purpose, and the reason is recorded with it.
The lockstep pair, its boot path and the bus decode are closed until silicon test.
WHYIt is hardened, gate-level clean and simulated end to end. Reopening it for features risks the one part that must be right on a shuttle with no respin.
Instruction fetch reads a private boot ROM and SRAM port; the shared bus carries only data.
WHYSeparating fetch from data traffic removes a whole class of arbitration bugs instead of patching them, and data traffic can never stall execution.
Unmapped or clock-gated addresses complete with a bus error.
WHYWith no debugger and no halt, a hung bus would brick the chip. Firmware has to see a bad access and survive it.
DShot is multiplexed onto the PWM output pads and selected at boot.
WHYAn output is either a complementary PWM leg or a DShot line, never both. Duplicating pads would spend package pins for no added capability.
TIMING HEADROOM & FMAX
Maximum frequency of each hardened block after place-and-route. Every peripheral clears 90 MHz; the lockstep core reaches ~55–62 MHz, which is why the die runs at 50 MHz. The same limit is why DG32-2DOM puts its engine on a second clock instead of raising this one.
Post-route figures on the 130 nm process. The lockstep-core bar is drawn at 55 MHz, the low end of its measured range.
Pre-silicon. Figures are design values verified in simulation and static timing, not measurements on fabricated parts, unless marked otherwise.