MicroBlaze Processor Reference Guide
91
UG081 (v14.7)
Lockstep Operation
Lockstep Operation
MicroBlaze is able to operate in a lockstep configuration, where two or more identical MicroBlaze
cores execute the same program. By comparing the outputs of the cores, any tampering attempts,
transient faults or permanent hardware faults can be detected.
System Configuration
The parameter
C_LOCKSTEP_SLAVE
is set to one on all slave MicroBlaze cores in the system,
except the master (or primary) core. The master core drives all the output signals, and handles the
debug functionality. The port
Lockstep_Master_Out
on the master is connected to the port
Lockstep_Slave_In
on the slaves, in order to handle debugging.
The slave cores should not drive any output signals, only receive input signals. This must be ensured
by only connecting signals to the input ports of the slaves. For buses this means that each individual
input port must be explicitly connected.
The port
Lockstep_Out
on the master and slave cores provide all output signals for comparison.
Unless an error occurs, individual signals from each of the cores are identical every clock cycle.
To ensure that lockstep operation works properly, all input signals to the cores must be synchronous.
Input signals that may require external synchronization are
Interrupt
,
Reset
,
Mb_Reset
,
Ext_Brk
, and
Ext_Nm_Brk
.
Use Cases
Two common use cases are described here. In addition, lockstep operation provides the basis for
implementing triple modular redundancy on MicroBlaze core level.
Tamper Protection
This application represents a high assurance use case, where it is required that the system is tamper-
proof. A typically example is a cryptographic application.
The approach involves having two redundant MicroBlaze processors with dedicated local memory
and redundant comparators, each in a protected area. The outputs from each processor feed two
comparators and each processor receive copies of every input signal.
The redundant MicroBlaze processors are functionally identical and completely independent of
each other, without any connecting signals. The only exception is debug logic and associated
signals, since it is assumed that debugging is disabled before any productization and certification of
the system.
The outputs from the master MicroBlaze core drive the peripherals in the system. All data leaving
the protected area pass through inhibitors. Each inhibitor is controlled from its associated
comparator.
Each protected area of the design must be implemented in its own partition, using a hierarchical
Single Chip Cryptography (SCC) flow. A detailed explanation of this flow, and further references,
can be found in the document
Hierarchical Design Methodology Guide (UG748)
For Spartan-6 target architectures, the parameter
C_AVOID_PRIMITIVES
must be set to 3
(
BOTH)
in order to follow the SCC flow.
