This techerature is on ARM Cortex-M3 based system design. Most of
the things applies to ARM Cortex-M4 processor as well. Howver
the list of I/Os which are describled below are taken from Cortex-M3
processor.
Cortex-M3
processor is available to download free of charge from ARM Design
Start Website.
The Cortex-M3/M4 are one of the most popular choices on
Microcontrollers. The M4 is suited for application which require DSP
processing, and it offers an optionnal Folating Point Unit (M4F).
Use of thes processors are also common in small SoCs such as IoT
SoCs, Audio SoCs, WiFi SoCs, BlueTooth SoCs etc.
However irrespective of whether these are being used in
Microcontrollers or SoCs, the integration issues are constant.
This techerature first gives a very breif overview on these
processors and their features, and then considers the pinout of
Cortex-M3 processor, defining the function/use of each and every I/O
and how the I/Os needs to be connected or used in a system. This
will enable the user to integrate a Cortex-M3 processor in a system
they wish do design.
Interfaces:
Cortex M3/M4 are low power low gate cound 32 bit processors. Both
processors have 3 AHB Lite interfaces, Namely the ICODE, DCODE and
SYSTEM bus. A fourth interface/Bus called the Private Peripheral Bus
is also present, but this is for processor's internal use.
A AHB-AP (AHB Access Port) is present to allow debugger accesses.
A WIC interface for power management features.
Trace Port.
1. Power domain
Signals
// PMU
input
ISOLATEn;
// Isolate core power domain
input
RETAINn;
// Retain core state during power-down - unused
The above 2 signals are as the name suggest related to power
domains for the cortex m3 processor.
If the Cortex-M3 does not implement any power domains, these are
to be left floating. These wont be connected to anything in the
RTL hence they will be removed by the synthesis tools.
While ISOLATIONn is used for activating the 'Isolation cells' in
the design, the RETAINn signal has to do with 'retention' of the
states of the flops inside the Cortex-m3 core, when the power
domain inside which the cortex-m3 resides has been shut down.
More on the power
managemnt of ARM Cortex M4 processor can be found here. The
M3 is quite similar to M4, so from power perspective, the M4
principles would apply to M3 as well.
2. Serial Wire Debug Signals:
// Debug
input
nTRST;
// Test reset
input
SWDITMS;
// Test Mode Select/SWDIN
input
SWCLKTCK;
// Test clock / SWCLK
input
TDI;
// Test Data In
input
CDBGPWRUPACK; // Debug power
up acknowledge
3. RESET Signals:
// Miscellaneous
input
PORESETn;
// PowerOn reset
This is the main reset to the cortex-m3. It should reset
everything in the processor including the debug logic.
input
SYSRESETn;
// System reset
This resets the cortex-m3 core except the debug logic. It is
possible to access the 'System-Bus' of the cortex m3 processor
while PORESETn is not asserted and SYSRESETn is asserted via the
AHB-AP.
This is of significant importance becasue even when this reset is
asserted, a path from external debug port to the memory is
possible via the DAP_AHB_AP. This will enable the debugger to
download the code into the system's RAM, while the processor is
still held in RESET. This is important for multi-processor system,
where this cortex-m3 processor is not the boot processor, and it
does not have a ROM. In this situation, the boot-code has to be
copied into its RAM before the processor can boot.
Now during development, the user may want to copy code to the
system's ram using debug port.
While the development process is over, even then, the code copy
into the system's RAM will be done, while the SYSRESETn is held
asserted, while de-assertion of PORESETn will and should enable
the path from external system bus to the RAM so that the boot code
may be copied to the RAM.
If the SYSRESETn is not asserted, then the processor starts to run
un-controlably while there isn't any valid code in the RAM.
In later CPUs, ARM introduced a new port on the processor called
CPUWAIT to hold the processor from running un-controlably while
there isn't any valid code in its boot ROM.
input
RSTBYPASS;
// Reset Bypass
This is to help DFT, i.e. design for test. While the chip is
tested for production, it is essential for the tester to have full
control over the functional resets, internally generated resets,
and clocking gating logic. This is to allow the tester to scan
patterns in and out of the scan chains, and for this it is
essential that every flop inside the design is out of reset, and
every flop gets the clock.
This signal when set to '1', will and should bypass any internally
generated resets.
input
CGBYPASS;
// Architectural clock gate bypass
For the reason describled above, this signal will enable any
clock-gating for the purpose of Scan-testing.
4. CLK Signals
input
FCLK;
// Free running clock
This is the always-on clock on the M3/M3 based sub-system. The
frequency of this clock can be reduced, when the processor is
sleeping. The WIC usually works on this clock, hence this clock
should be ticking to allow the processor to wake-up using
Interrupt.
input
HCLK;
// System clock
This is the clock that clocks most of the M3/M4 processor
internals. This can be gated, when the processor is in sleep mode.
HCLK MUST be derived from FCLK.
input
TRACECLKIN; //
TPIU trace port clock
5. System Tick Clock And System Timer Signals:
input
STCLK;
// System Tick clock
input [25:0]
STCALIB;
// System Tick calibration
SYS TICK timer provide periodic pulses. Usually these pulses are
used by RTOS for time slicing
Systick is an internal timer inside the processor.
It can either count on the processor's FCLK or it can count on a
clock supplied on
the pin STCLK. This STCLK must be slower than the FCLK so that
FCLK can sample it easily.
Internal to the processor the STCLK signal is synchronised using
FCLK.
The ARM document says that you need external synchronisation of
STCLK before use but that is
not true. There is no need to synchronise it external to the
processor.
The STCALIB is a calibration count value for counting 10ms on
STCLK
6. Auxiliary Fault Status Register
input [31:0]
AUXFAULT;
// Auxillary FSR pulse inputs
This input directly maps to 32 bits of Auxiliary Fault Status
Register.
This signal is used to provide user specified information to the
software.
The software will ead the Auxiliary fault status register, and
since these bits map to this register,
there exists a possibiliy for the system to provide any
information to the software.
7. ENDIAN Ness signal
input
BIGEND;
// Static endianess select
This input pin is sampled at reset and stored in Interrupt and
Reset Control Register Bit [15].
1 => big endian
0 => Little endian
8. Interrupt signals:
// Interrupt
input [239:0]
INTISR;
// Interrupts
input
INTNMI;
// Non-maskable Interrupt
9. ICODE Bus Input Signals
These signals are the AHB-Lite signals for the ICODE bus from
the processor
This is a read-only bus, and can only access memory region
0x0000_0000 -> 0x1FFF_FFFF
Code fetches are performed on this bus. The following are ICODE
bus Input siganls.
// Code (instruction & literal) bus
input
HREADYI;
// ICode-bus ready
input [31:0]
HRDATAI;
// ICode-bus read data
input [1:0]
HRESPI;
// ICode-bus transfer response
input
IFLUSH;
// ICode-bus buffer flush
11. DCODE Bus Input Signals:
These signals are the AHB-Lite signals
for the DCODE bus from the processor
It can access memory region 0x0000_0000 -> 0x1FFF_FFFF
Data fetches are usually performed on this bus. The following
are DCODE bus Input siganls.
input
HREADYD;
// DCode-bus ready
input [31:0]
HRDATAD;
// DCode-bus read data
input [1:0]
HRESPD;
// DCode-bus transfer response
input
EXRESPD;
// DCode-bus exclusive response
13. SYSTEM Bus Input Signals
// System Bus
input
HREADYS;
// System-bus ready
input [31:0]
HRDATAS;
// System-bus read data
input [1:0]
HRESPS;
// System-bus transfer response
input
EXRESPS;
// System-bus exclusive response
14. Receive Event Input
// Sleep
input
RXEV;
// Wait for exception input
This input signal is typically used in multi-processor system.
This wakes the processor up, if the processor has executed WFE
instruction before going to sleep.
This signal makes sure that if one processor wakes up, all
processors are woken-up. The first one to wake up will emit a
signal called TXEV (Transmit Event) this will be connected to
another processors's RXEV. In a system with only 1 processor RXEV
can be tied to '0'.
15. Extend Sleep Signal.
input
SLEEPHOLDREQn; // Hold core in sleep
mode
This signal helps the processor to be in extended sleep mode, when
SLEEPING output signal from the processor is asserted.
This is the part of the handshaking pair of signals SLEEPHOLDREQn
and SLEEPHOLDACKn.
Following a wake-up event, while the SLEEPING is de-asserted, the
SLEEPHOLDREQn can be kept asserted by the system to 'extend' the
sleep till the point the processor or the processor sub-system is
ready to wake up.
This provides the user time to do 'things' following a wake-up
event, before the processor starts to run.
16. Debug Req/Start Signal.
// External Debug Request
input
EDBGRQ;
// Debug Request
EDBGRQ, when asserted, will halt the processor at the next
instruction boundary.
Its typical use is in multiprocessor systems, to enable proessor
halting, it there is debug event in another processor. However if
coresight infrastructure is used, then this halting is done using
CTI (Cross Trigger Interface), and in that case this signal can be
tied to '0'. This signal is tied to '0' in a single processor
system as well.
input
DBGRESTART; //
External Debug Restart request
DBGRESTART is kind of just the opposite of EDBGRQ. When this
signal is asserted, the processor is taken out of Halted state.
Again its typical use is in mutiprocessor system to ensure that
all the processors comes out of HALTED state simultaneously. Again
if CTI is being used in muliprocessor systms OR if it is a single
processor system, this can be tied to '0', and the complimentry
output signal DBGRESTARTED can be left unused.
17. Master ID signal
// DAP HMASTER override
input
FIXMASTERTYPE; // Override HMASTER
for AHB-AP accesses
This signal can override the the values on signals HMASTERD (DCODE
bus) and HMASTERI (ICODE Bus).
When this signal is set to '1', the accesses from the debugger is
always issed with HMASTERD and HMASTERI value of '1'. When this
signal is '0', the HMASTERD and HMASTERI takes values as defined
by software using the CSW (Control and Status Word).
With this set to '1', the accesses reflect true owner of the
transaction.
18. WIC enable signal
// WIC
input
WICENREQ;
// WIC mode Request from PMU
For the WIC to come into action, before the processor goes to
sleep, the WIC operation must be 'enabled'
This is done by the pair of signals WICENREQ & WICENACK.
The PMU will generate this request, and the processor will confirm
by asserting WICENACK.
This merely means an 'agreement' that the next time processor goes
to sleep WIC related action will take place.
This pin can be tied permanently to '1' (and WICENACK left unused)
to make sure that all the sleep requests are WIC mode sleeps, i.e.
the WIC related actions are taken for every sleep entry/exit.
19. Global Timestamp value.
// Timestamp intereace
input [47:0]
TSVALUEB;
// Binary coded timestamp value
This signal is used as a binary count value of global timestamping
is needed. Otherwise it MUST be tied to all 0s.
20. Scan Enable Signal.
// Scan
input
SE;
// Scan Enable
21. DEBUG related signals.
// Logic disable
input
MPUDISABLE; //
Disable the MPU (act as default)
input
DBGEN;
// Enable debug
input
NIDEN;
// Enable non-invasive debug
22. Parallel/Sequential selection of ICODE And DCODE
buses.
// Tie-High if code mux is used
input
DNOTITRANS; //
I/DCode arbitration control
This signal decides, if the ICODE and DCODE buses may be used in
parallel.
IF this is tied to '0', the buses operate in parallel
IF this is tied to '1', the ICODE bus's HTRANS, ie. HTRANSI is
suppressed internal to the processor whenever there is a parallel
access from ICODE and DCODE.
// Debug
output
TDO;
// Test Data Out
output
nTDOEN;
// Test Data Out Enable
output
CDBGPWRUPREQ; // Debug power
up request
// Single Wire
output
SWDO;
// SingleWire data out
output
SWDOEN;
// SingleWire output enable
output
JTAGNSW;
// JTAG mode(1) or SW mode(0)
// Single Wire Viewer
output
SWV;
// SingleWire Viewer Data
// TracePort Output
output
TRACECLK;
// TracePort clock reference
output [3:0]
TRACEDATA;
// TracePort Data
// HTM data
output [31:0]
HTMDHADDR;
// HTM data HADDR
output [1:0]
HTMDHTRANS; // HTM
data HTRANS
output [2:0]
HTMDHSIZE;
// HTM data HSIZE
output [2:0]
HTMDHBURST; // HTM
data HBURST
output [3:0]
HTMDHPROT;
// HTM data HPROT
output [31:0]
HTMDHWDATA; // HTM
data HWDATA
output
HTMDHWRITE; // HTM
data HWRITE
output [31:0]
HTMDHRDATA; // HTM
data HRDATA
output
HTMDHREADY; // HTM
data HREADY
output [1:0]
HTMDHRESP;
// HTM data HRESP
// Code (instruction & literal) bus
output [1:0]
HTRANSI;
// ICode-bus transfer type
output [2:0]
HSIZEI;
// ICode-bus transfer size
output [31:0]
HADDRI;
// ICode-bus address
output [2:0]
HBURSTI;
// ICode-bus burst length
output [3:0]
HPROTI;
// ICode-bus protection
output [1:0]
MEMATTRI;
// ICode-bus memory attributes
output [1:0]
HMASTERD;
// DCode-bus master
output [1:0]
HTRANSD;
// DCode-bus transfer type
output [2:0]
HSIZED;
// DCode-bus transfer size
output [31:0]
HADDRD;
// DCode-bus address
output [2:0]
HBURSTD;
// DCode-bus burst length
output [3:0]
HPROTD;
// DCode-bus protection
output [1:0]
MEMATTRD;
// ICode-bus memory attributes
output
EXREQD;
// ICode-bus exclusive request
output
HWRITED;
// DCode-bus write not read
output [31:0]
HWDATAD;
// DCode-bus write data
// System Bus
output [1:0]
HMASTERS;
// System-bus master
output [1:0]
HTRANSS;
// System-bus transfer type
output
HWRITES;
// System-bus write not read
output [2:0]
HSIZES;
// System-bus transfer size
output
HMASTLOCKS; //
System-bus lock
output [31:0]
HADDRS;
// System-bus address
output [31:0]
HWDATAS;
// System-bus write data
output [2:0]
HBURSTS;
// System-bus burst length
output [3:0]
HPROTS;
// System-bus protection
output [1:0]
MEMATTRS;
// System-bus memory attributes
output
EXREQS;
// System-bus exclusive request
// Core Status
output [3:0]
BRCHSTAT;
// Branch status
output
HALTED;
// Core is halted via debug
output
DBGRESTARTED; // External
Debug Restart Ready
output
LOCKUP;
// Lockup indication
output
SLEEPING;
// Core is sleeping
output
SLEEPDEEP;
// System can enter deep sleep
output
SLEEPHOLDACKn; // Indicate core is
force in sleep mode
output [8:0]
ETMINTNUM;
// Interrupt that is currently active
output [2:0]
ETMINTSTAT; //
Interrupt activation status
output
TRCENA;
// Trace Enable
output [7:0]
CURRPRI;
// Current Int Priority
// Reset request
output
SYSRESETREQ; // System
reset request
// Events
output
TXEV;
// Event output
// Clock gating control
output
GATEHCLK;
// when high, HCLK can be turned off
// WIC
output
WICENACK;
// WIC mode acknowledge from WIC
output
WAKEUP;
// Wake-up request from WI
SITE HOME