ARM Cortex M3/M4 Integration Guide
-Aviral Mittal
Connect Aviral Mittal @ https://www.linkedin.com/in/avimit/
SITE HOME
Link To
SoC Design Web Training

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