dm00045895

RM0319
Reference manual
SPEAr320S architecture and functionality
Introduction
The SPEAr320S is a member of the SPEAr3xx family (includes SPEAr320S, SPEAR320,
SPEAr310 and SPEAr300).
SPEAr3xx devices all feature ARM926EJ-S core running up to 333 MHz, an external DDR2
memory interface, a common set of powerful on-chip peripherals. Each member of the
SPEAr3xx family has a specific set of IPs implemented in its reconfigurable array subsystem
(RAS).
This document provides technical details about the architecture and functionality of
SPEAr320S, and is intended to be used by system-level and board-level product designers,
as well as software developers.
The SPEAr320S address map and detailed register descriptions are provided in a separate
reference manual: RM0321: SPEAr320S address map and registers.
For the pin out, ordering information, mechanical, electrical and timing characteristics,
please refer to the SPEAr320S datasheet.
November 2012
Doc ID 022640 Rev 3
1/368
www.st.com
Contents
RM0319
Contents
1
2
3
4
5
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.1
Terms and conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.1
Numbering conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.2
Bits description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.3
Typographical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Device overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1
Simplified block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2
IP groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
ARM926EJ-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1
Memory management unit (MMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2
Caches and write buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3
Bus interface unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Multilayer interconnect matrix (BUSMATRIX) . . . . . . . . . . . . . . . . . . . . 30
4.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2
Interconnection matrices (ICMs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
BootROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1
Boot modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2
Boot stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3
Booting pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4
Hardware overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5
5.4.1
eROM (Embedded ROM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4.2
Shadow memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4.3
System controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Software overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5.1
2/368
ARM processor modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Doc ID 022640 Rev 3
RM0319
Contents
5.6
6
5.5.2
SoC peripheral interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5.3
Memory overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5.4
X-Loader and U-Boot header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5.5
X-Loader and U-Boot authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Boot flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6.1
Serial NOR Flash boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6.2
Serial (UART0) boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6.3
BootROM Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6.4
NAND Flash boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6.5
USB boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6.6
Parallel NOR Flash boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6.7
Ethernet boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Multiport DDR controller (MPMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4
6.3.1
AHB memory controller interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.2
AHB register port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3.3
AHB transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3.4
Arbiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3.5
Write data queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3.6
DRAM command processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.7
Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.8
Multiport arbiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.1
Low power modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.2
Low power mode control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4.3
Low power control programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.4.4
Low power and clock forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.5
Mobile DDR/SDRAM devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.6
Out-of-range address checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.4.7
Mobile devices DQS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.4.8
Half datapath option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.4.9
User-defined registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.4.10
Address mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.4.11
DCC tuning timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Doc ID 022640 Rev 3
3/368
Contents
RM0319
6.5
Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.6
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.6.1
7
Serial NOR Flash controller (SMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.4
7.3.1
Clock prescaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.3.2
Data processing and control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.3.3
Operation modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.3.4
Data transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.4.1
7.5
9
4/368
Booting from external memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Parallel NAND Flash controller (FSMC) . . . . . . . . . . . . . . . . . . . . . . . . 101
8.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.3.1
AHB interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.3.2
NAND Flash controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
External memory interface (EMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.4
10
Latencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.5.1
8
Initializing the MPMC controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.3.1
EMI cycles definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.3.2
Data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
USB 2.0 Host ports (UHC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Doc ID 022640 Rev 3
RM0319
Contents
10.4
11
10.3.1
AHB bus interface unit (BIU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.3.2
EHCI host controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.3.3
OHCI host controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
USB 2.0 Device ports (UDC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.3.1
USB transaction layer interface (UTLI) . . . . . . . . . . . . . . . . . . . . . . . . 119
11.3.2
Interrupt manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.3.3
SOF tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.3.4
Receive FIFO controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.3.5
Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.3.6
Endpoint FIFO controller (Transmit FIFO controller) . . . . . . . . . . . . . . 122
11.3.7
Control and status registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.3.8
AHB slave-only interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.3.9
DMA (AHB master interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.3.10 DMA transfer engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.3.11 DMA controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.3.12 AHB interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.3.13 CSRs slave access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.4
12
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.4.1
DMA mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.4.2
In operation (Data transfer To USB Host) . . . . . . . . . . . . . . . . . . . . . . 125
11.4.3
Out operation (Data transfer from USB Host) . . . . . . . . . . . . . . . . . . . 127
11.4.4
Slave-only mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.4.5
Data memory structure in DMA mode . . . . . . . . . . . . . . . . . . . . . . . . . 132
11.4.6
Operation modes in DMA mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
11.4.7
USB plug detect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Fast Ethernet port (MII0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
12.3.1
AHB slave interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Doc ID 022640 Rev 3
5/368
Contents
13
RM0319
6/368
AHB master interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
12.3.3
DMA controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
12.3.4
Transmit and receive FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
12.3.5
MAC management counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
12.3.6
Power management module (PMT) . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
12.3.7
DMA descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
12.4
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
12.5
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
12.6
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Fast Ethernet ports (RMII0/RMII1/MII1) . . . . . . . . . . . . . . . . . . . . . . . . 154
13.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
13.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
13.3
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
13.4
14
12.3.2
13.3.1
MII configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
13.3.2
RMII configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.4.1
Address checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.4.2
Statistics register block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.4.3
Control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.4.4
Receive block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.4.5
DMA interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
13.5
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
13.6
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
13.6.1
Enabling the MII interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
13.6.2
Enabling the RMII interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
13.6.3
Initializing and configuring MACB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
13.6.4
Creating a receive buffer list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
13.6.5
Creating a transmit buffer list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
13.6.6
Using the PHY maintenance register . . . . . . . . . . . . . . . . . . . . . . . . . . 177
13.6.7
Transmitting frames in MII/RMII mode . . . . . . . . . . . . . . . . . . . . . . . . . 178
13.6.8
Receiving frames in MII/RMII mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
MMC-SD card/SDIO controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
14.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
14.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Doc ID 022640 Rev 3
RM0319
15
Contents
14.3
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
14.4
Functional overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
14.5
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
14.5.1
Detecting the SD card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
14.5.2
Supplying the SD clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
14.5.3
Issuing a command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
14.5.4
Completing a command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
14.5.5
Transferring data without DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
14.5.6
Transferring data with SDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
14.5.7
Transferring data with ADMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
14.5.8
Aborting the transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Controller area network ports (CAN) . . . . . . . . . . . . . . . . . . . . . . . . . . 193
15.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
15.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
15.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
15.3.1
15.4
Message handler state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
15.4.1
Initializing the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
15.4.2
Transferring messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
15.4.3
Using the disabled automatic retransmission mode . . . . . . . . . . . . . . 198
15.4.4
Using the test mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
15.4.5
Using the silent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
15.4.6
Using the loop back mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
15.4.7
Using the loop back mode combined with silent mode . . . . . . . . . . . . 200
15.4.8
Managing message objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
15.4.9
Configuring a transmit object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
15.4.10 Updating a transmit object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
15.4.11 Configuring a receive object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
15.4.12 Updating a transmit object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
15.4.13 Configuring a receive object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
15.4.14 Handling received messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
15.4.15 Configuring a FIFO buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
15.4.16 Receiving messages with FIFO buffers . . . . . . . . . . . . . . . . . . . . . . . . 205
15.4.17 Reading from a FIFO buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
15.4.18 Handling interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Doc ID 022640 Rev 3
7/368
Contents
RM0319
15.4.19 Configuring the bit timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
15.4.20 Configuring the CAN protocol controller . . . . . . . . . . . . . . . . . . . . . . . 213
16
Asynchronous serial ports (UART) . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
16.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
16.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
16.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
16.3.1
APB Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
16.3.2
Register Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
16.3.3
Baud Rate Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
16.3.4
Transmit FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
16.3.5
Receive FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
16.3.6
Transmit Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
16.3.7
Receive logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
16.3.8
DMA interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
16.3.9
Synchronization registers and logic . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
16.3.10 RS485 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
17
16.4
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
16.5
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
UART hardware flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
16.5.2
Modem operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
I2C bus ports (I2C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
17.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
17.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
17.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
17.4
8/368
16.5.1
17.3.1
APB interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
17.3.2
I2C protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
17.3.3
DMA controller Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Operation modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
17.4.1
Slave mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
17.4.2
Master mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
17.4.3
Multimaster mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
17.5
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
17.6
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Doc ID 022640 Rev 3
RM0319
18
Contents
Synchronous serial ports (SSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
18.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
18.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
18.3
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
18.4
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
18.5
18.6
19
18.4.1
APB slave interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
18.4.2
Register block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
18.4.3
Clock prescaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
18.4.4
Transmit FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
18.4.5
Receive FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
18.4.6
Transmit and receive logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
18.4.7
DMA interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
18.4.8
Interrupt generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
18.5.1
Configuring the SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
18.5.2
Enabling SSP operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
18.5.3
Programming the SSPCR0 control register . . . . . . . . . . . . . . . . . . . . . 242
18.5.4
Programming the SSPCR1 control register . . . . . . . . . . . . . . . . . . . . . 242
18.5.5
Frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
18.6.1
Receive interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
18.6.2
Transmit interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
18.6.3
Receive overrun interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
18.6.4
Receive timeout interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
18.6.5
Combined interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Fast infrared port (IRDA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
19.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
19.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
19.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
19.3.1
Synchronization unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
19.3.2
Demodulation unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
19.3.3
Wrapper unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
19.3.4
Modulation unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
19.3.5
Baud rate generation unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
19.3.6
FIFO unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Doc ID 022640 Rev 3
9/368
Contents
RM0319
19.4
20
21
22
Legacy IEEE 1284 parallel port (SPP) . . . . . . . . . . . . . . . . . . . . . . . . . 255
20.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
20.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
20.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
20.4
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Analog-to-digital converter (ADC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
21.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
21.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
21.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
21.3.1
Operation modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
21.3.2
Enhanced mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
21.3.3
High-resolution mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Basic general purpose I/Os (basGPIO) . . . . . . . . . . . . . . . . . . . . . . . . 261
22.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
22.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
22.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
22.4
23
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
22.3.1
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
22.3.2
Interrupt detection logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
22.3.3
Mode control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
22.4.1
How to read from and write to input/output lines . . . . . . . . . . . . . . . . . 263
22.4.2
Control interrupt generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Extended general purpose I/O (PL_GPIO) . . . . . . . . . . . . . . . . . . . . . 265
23.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
23.2
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
23.2.1
24
10/368
PL_GPIO external interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
LCD display controller (CLCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
24.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
24.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
24.3
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Doc ID 022640 Rev 3
RM0319
Contents
24.4
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
24.4.1
AHB slave interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
24.4.2
AHB master interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
24.4.3
Dual DMA FIFOs and associated control logic . . . . . . . . . . . . . . . . . . 275
24.4.4
Pixel serializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
24.4.5
RAM palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
24.4.6
Gray scaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
24.4.7
Upper and lower panel formatters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
24.4.8
Panel clock generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
24.4.9
Timing controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
24.4.10 Interrupt generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
24.4.11 Bus architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
24.5
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
24.6
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
24.7
25
26
27
24.6.1
CLCDMBEINTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
24.6.2
LCDVCOMPINTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
24.6.3
CLCDLNBUINTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
24.6.4
CLCDFUFINTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Touchscreen interface (TOUCHSCREEN) . . . . . . . . . . . . . . . . . . . . . . 285
25.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
25.2
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
JPEG codec accelerator (JPGC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
26.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
26.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
26.3
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
26.4
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
26.4.1
Codec core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
26.4.2
Codec controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
26.4.3
DMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
26.4.4
FIFO buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
26.4.5
Internal memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Digital audio port (I2S) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Doc ID 022640 Rev 3
11/368
Contents
28
RM0319
27.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
27.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
27.3
External pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
27.4
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Transmit channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
27.4.2
Receive channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
27.4.3
Audio data interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
27.4.4
External I2S_CLK gating and enable signal . . . . . . . . . . . . . . . . . . . . 293
27.5
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
27.6
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
27.7
Programming examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
27.7.1
Using the I2S transmitter (Tx mode) . . . . . . . . . . . . . . . . . . . . . . . . . . 294
27.7.2
Using the I2S receiver (Rx mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
27.7.3
Programming FIFO thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
27.7.4
Exchanging data with system memory . . . . . . . . . . . . . . . . . . . . . . . . 295
Security co-processor (C3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
28.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
28.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
28.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
28.4
29
27.4.1
28.3.1
HIF (High speed bus interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
28.3.2
SIF (Slave bus interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
28.3.3
IDS (Instruction dispatchers sub-system) . . . . . . . . . . . . . . . . . . . . . . 300
28.3.4
Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
28.3.5
CCM (Coupling/Chaining module) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
28.4.1
Channel ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
28.4.2
DES channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
28.4.3
AES channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
28.4.4
Unified hash with HMAC channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
System controller (SYSCTR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
29.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
29.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
29.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
29.3.1
12/368
System modes control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Doc ID 022640 Rev 3
RM0319
30
Contents
29.3.2
System control state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
29.3.3
Interrupt response mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
29.3.4
Reset control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
29.3.5
Core clock control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
29.3.6
Watchdog module clock enable generation . . . . . . . . . . . . . . . . . . . . . 320
Power, reset and clock control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
30.1
30.2
30.3
30.4
30.5
System control state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
30.1.1
SLEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
30.1.2
DOZE (reset state) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
30.1.3
SLOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
30.1.4
NORMAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Transition states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
30.2.1
XTAL control transition state, XTAL CTL . . . . . . . . . . . . . . . . . . . . . . . 326
30.2.2
Switch to XTAL transition state, SW TO XTAL . . . . . . . . . . . . . . . . . . . 326
30.2.3
Switch from XTAL transition state (SW from XTAL) . . . . . . . . . . . . . . . 327
30.2.4
Switch to PLL transition state (SW to PLL) . . . . . . . . . . . . . . . . . . . . . 327
30.2.5
Switch from PLL transition state (SW from PLL) . . . . . . . . . . . . . . . . . 327
Power management techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
30.3.1
Dynamic Frequency Scaling (applicable in NORMAL state) . . . . . . . . 328
30.3.2
Dynamic clock switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
30.3.3
Combining frequency scalling and clock techniques . . . . . . . . . . . . . . 329
30.3.4
Statically frequency selection and clock switching OFF . . . . . . . . . . . 329
Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
30.4.1
Main reset (MRESET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
30.4.2
Software reset control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
30.4.3
Watchdog reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Clock control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
30.5.1
Main clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
30.5.2
PLL programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
30.5.3
Clock distribution scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
30.5.4
DDR memory controller clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
30.5.5
Bus clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
30.5.6
Watchdog module clock enable generation . . . . . . . . . . . . . . . . . . . . . 335
30.5.7
RAS clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
30.5.8
Clock synthesizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Doc ID 022640 Rev 3
13/368
Contents
31
RM0319
System configuration registers (MISC) . . . . . . . . . . . . . . . . . . . . . . . . 339
31.1
32
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Reconfigurable array subsystem (RASCFG) . . . . . . . . . . . . . . . . . . . 340
32.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
32.2
I/O multiplexing scheme configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 340
32.2.1
33
32.3
Bootstrap register configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
32.4
RAS interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Vectored interrupt controller (VIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
33.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
33.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
33.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
33.4
33.3.1
Interrupt request logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
33.3.2
Non-vectored FIQ interrupt logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
33.3.3
Non-vectored IRQ interrupt logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
33.3.4
Vectored interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
33.3.5
Interrupt priority logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
33.3.6
Software interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
33.3.7
AHB slave interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
33.4.1
34
14/368
Reducing interrupt latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Watchdog timer (WDT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
34.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
34.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
34.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
34.4
35
Alternate functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
34.3.1
AMBA APB interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
34.3.2
Free running counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Real-time clock (RTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
35.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
35.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Doc ID 022640 Rev 3
RM0319
36
Contents
DMA controller (DMAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
36.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
36.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
36.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
36.4
36.3.1
Signal interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
36.3.2
AHB slave interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
36.3.3
AHB master interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
36.3.4
DMA interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
36.3.5
Scatter/gather . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
36.3.6
How to program the DMAC for scatter/gather DMA . . . . . . . . . . . . . . . 355
Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
36.4.1
37
General purpose timers (GPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
37.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
37.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
37.3
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
37.3.1
37.4
38
How to operate single combined DMACINTR interrupt request signal 356
External pin connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Pulse width modulators (PWM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
38.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
38.2
Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Appendix A Interrupt request table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Appendix B Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Appendix C Reference documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Doc ID 022640 Rev 3
15/368
List of tables
RM0319
List of tables
Table 1.
Table 2.
Table 3.
Table 4.
Table 5.
Table 6.
Table 7.
Table 8.
Table 9.
Table 10.
Table 11.
Table 12.
Table 13.
Table 14.
Table 15.
Table 16.
Table 17.
Table 18.
Table 19.
Table 20.
Table 21.
Table 22.
Table 23.
Table 24.
Table 25.
Table 26.
Table 27.
Table 28.
Table 29.
Table 30.
Table 31.
Table 32.
Table 33.
Table 34.
Table 35.
Table 36.
Table 37.
Table 38.
Table 39.
Table 40.
Table 41.
Table 42.
Table 43.
Table 44.
Table 45.
Table 46.
Table 47.
Table 48.
16/368
Typographical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
SPEAr320S IP groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Connectivity matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Connectivity matrix table definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
ICM master layers (Initiators) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ICM slaves (targets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Booting types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Command format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Device descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuration descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Interface descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Bulk OUT endpoint descriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Bulk IN endpoint descriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
String descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Configured AHB settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
READ/WRITE data alignment - Little Endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
READ/WRITE data alignment - Big Endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
AHB-Memory controller translation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Round-Robin operation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Relative priority example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Port ordering example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
System D specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
System D operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
System E specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
System E operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
System F specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
System F operation with priority relaxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
System G specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
System G operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Low power mode parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Low power mode controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Memory interface buses with Half Datapath option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Delay parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
SMI supported instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
EMI data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Endpoints assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
SETUP data memory: status quadlet bit assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Out data memory: buffer status quadlet bit assignments (for Non-Isochronous OUT) . . . 134
Out data memory: buffer status quadlet bit assignments (for Isochronous OUT). . . . . . . 135
In data memory: buffer status quadlet bit assignments (for non-isochronous IN) . . . . . . 136
In data memory:buffer status quadlet bit assignments (for isochronous) . . . . . . . . . . . . . 137
Plug status register bit assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Plug pending register bit assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Transmit descriptor 0 (TDES0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Transmit descriptor 1 (TEDS1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Transmit descriptor 2 (TDES2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Transmit descriptor 3 (TDES3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Receive descriptor 0 (RDES0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Doc ID 022640 Rev 3
RM0319
Table 49.
Table 50.
Table 51.
Table 52.
Table 53.
Table 54.
Table 55.
Table 56.
Table 57.
Table 58.
Table 59.
Table 60.
Table 61.
Table 62.
Table 63.
Table 64.
Table 65.
Table 66.
Table 67.
Table 68.
Table 69.
Table 70.
Table 71.
Table 72.
Table 73.
Table 74.
Table 75.
Table 76.
Table 77.
Table 78.
Table 79.
Table 80.
Table 81.
Table 82.
Table 83.
Table 84.
Table 85.
Table 86.
Table 87.
Table 88.
Table 89.
Table 90.
Table 91.
Table 92.
Table 93.
Table 94.
Table 95.
Table 96.
Table 97.
Table 98.
Table 99.
Table 100.
List of tables
Receive descriptor 1 (RDES1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Receive descriptor 2 (RDES2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Receive descriptor 3 (RDES3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Pin configuration in MII mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Pin configuration in RMII mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Receive buffer descriptor entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Transmit buffer descriptor entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Pause frame support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Address match register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Signal description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Initialization of a transmit object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Initialization of a receive object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Initialization of a receive object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Parameters of the CAN Bit Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
UART interrupt summary together with combined outputs . . . . . . . . . . . . . . . . . . . . . . . . 221
Control bits to enable and disable hardware flow control . . . . . . . . . . . . . . . . . . . . . . . . . 223
Meaning of UART0/1 modem input/output in DTE and DCE modes . . . . . . . . . . . . . . . . 224
First byte assignment in addressing slave protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
I2C controller interrupt sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
SSP pin description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
External CS selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
4PPM encoding scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Settings of K,L and (N+1) parameters for SIR,MIR and FIR in baud rate generation unit 251
Request signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
FIrDA controller interrupt summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
GPIO signal interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
CLCD signal interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
LCD STN panel signal multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
LCD TFT panel signal multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
LBLP, DMA FIFO output bit 31 to bit 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
LBLP, DMA FIFO output bit 15 to bit 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
BBBP, DMA FIFO output bit 31 to bit 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
BBBP, DMA FIFO output bit15 to bit 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
LBBP, DMA FIFO output bit 31 to bit 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
LBBP, DMA FIFO output bit15 to bit 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
RGB mode data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Palette data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
GPIO signal interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
I2S signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
I2S interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
C3 device summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Channel ID Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
DES ECB start instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
DES ECB bit ‘a’ encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
DES ECB bit ‘b’ encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
DES CBC START Instruction Bit Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
DES ECB APPEND Instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
DES CBC Append Instruction Bit Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
AES ECB START instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
AES ECB Bit ‘a’ encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
AES CBC START instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
AES CTR START instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Doc ID 022640 Rev 3
17/368
List of tables
Table 101.
Table 102.
Table 103.
Table 104.
Table 105.
Table 106.
Table 107.
Table 108.
Table 109.
Table 110.
Table 111.
Table 112.
Table 113.
Table 114.
Table 115.
Table 116.
Table 117.
Table 118.
Table 119.
Table 120.
Table 121.
Table 122.
Table 123.
Table 124.
Table 125.
Table 126.
Table 127.
Table 128.
18/368
RM0319
AES ECB APPEND instruction bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
AES CBC APPEND instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
AES CTR APPEND instruction bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
HASH INIT Instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
HASH INIT Bit ‘aa’ encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
HASH APPEND Instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
HASH END Instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
HASH CONTEXT SAVE Instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
HASH CONTEXT RESTORE Instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
HMAC INIT Instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
HMAC APPEND Instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
HMAC END Instruction bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
HMAC CONTEXT SAVE Instruction bit encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
HMAC CONTEXT RESTORE instruction bit encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Power state for synchronous DRAM system (DRAM clocked by PLL1) . . . . . . . . . . . . . . 322
Power state for asynchronous DRAM system (DRAM clocked by PLL2) . . . . . . . . . . . . . 322
Techniques applicable in NORMAL state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Modules supporting DCS technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
System source control selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
DDR_CLK source selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
RAS Interrupt assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Interrupt latency for different types of interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Watchdog module counter decremented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
DMAC signal interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Interrupt requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Doc ID 022640 Rev 3
RM0319
List of figures
List of figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Figure 8.
Figure 9.
Figure 10.
Figure 11.
Figure 12.
Figure 13.
Figure 14.
Figure 15.
Figure 16.
Figure 17.
Figure 18.
Figure 19.
Figure 20.
Figure 21.
Figure 22.
Figure 23.
Figure 24.
Figure 25.
Figure 26.
Figure 27.
Figure 28.
Figure 29.
Figure 30.
Figure 31.
Figure 32.
Figure 33.
Figure 34.
Figure 35.
Figure 36.
Figure 37.
Figure 38.
Figure 39.
Figure 40.
Figure 41.
Figure 42.
Figure 43.
Figure 44.
Figure 45.
Figure 46.
Figure 47.
Figure 48.
SPEAr320S simplified block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ARM926EJ-S block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
SPEAr320S block diagram with BUSMATRIX topology details . . . . . . . . . . . . . . . . . . . 31
ICM block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Boot stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Hardware memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Usage of memory by BootROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Boot flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Serial boot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Serial NOR Flash boot & BootROM bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
NAND Flash boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
USB boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Parallel NOR Flash boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Ethernet boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
MPMC block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Memory controller architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
WRAPx effective transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Weighted round-robin priority group structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Memory map: Maximum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Alternate memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
SMI block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
External SPI memory map in AHB address space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
FSMC block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
AHB-EMI interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
EMI write cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
EMI read cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
EMI write (without ACK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
EMI write (with ACK). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
EMI read (without ACK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
EMI read (with ACK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
UHC block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
USB Host controller (UHOSTC) block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
UDC-AHB subsystem block diagram within the USB 2.0 device . . . . . . . . . . . . . . . . . . . 118
UDC_Device block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
RxFIFO implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Linked-list memory structure in DMA mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
In transaction flow in DMA mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Out transaction flow in DMA mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
In transaction flow in slave-only mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Out transaction flow in slave-only mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
SETUP data memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Out data memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
In data memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
MII0 system-level block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
DMA descriptor list: ring structure (left) and chain structure (right). . . . . . . . . . . . . . . . . . 145
DMA descriptor format (Transmit Descriptor, 32 bit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
DMA descriptor format (Receive Descriptor, 32 bit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Clocking scheme for MAC-AHB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Doc ID 022640 Rev 3
19/368
List of figures
Figure 49.
Figure 50.
Figure 51.
Figure 52.
Figure 53.
Figure 54.
Figure 55.
Figure 56.
Figure 57.
Figure 58.
Figure 59.
Figure 60.
Figure 61.
Figure 62.
Figure 63.
Figure 64.
Figure 65.
Figure 66.
Figure 67.
Figure 68.
Figure 69.
Figure 70.
Figure 71.
Figure 72.
Figure 73.
Figure 74.
Figure 75.
Figure 76.
Figure 77.
Figure 78.
Figure 79.
Figure 80.
Figure 81.
Figure 82.
Figure 83.
Figure 84.
Figure 85.
Figure 86.
Figure 87.
Figure 88.
Figure 89.
Figure 90.
Figure 91.
Figure 92.
Figure 93.
Figure 94.
Figure 95.
Figure 96.
Figure 97.
Figure 98.
Figure 99.
Figure 100.
20/368
RM0319
Interrupt management: sbd_intr_o and pmt_intr_o generation. . . . . . . . . . . . . . . . . . . . . 152
MACB simplified block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
MII configuration in SPEAr320S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
RMII configuration in SPEAr320S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
MACB detailed block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Receive buffer list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Transmit buffer list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
SD/SDIO/MMC controller pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
MMC-SD/SDIO controller block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
SD card detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
SD clock supply sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Command issue sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Command completion sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Data transaction sequence without DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Data transaction sequence with SDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Data transaction sequence with ADMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Abort transaction sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
CAN controller block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Data transfer between IFx registers and message RAM . . . . . . . . . . . . . . . . . . . . . . . . . 195
CAN core in silent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
CAN Core in loop back mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
CAN core in loop back combined with silent mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Message identifier formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Data frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
CPU handling of a FIFO buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Bit timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Propagation time segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Synchronisation on “late” and “early” Edges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Filtering of short dominant spikes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Structure of the CAN Core protocol controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
UART block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Hardware flow control between two similar devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
I2C controller functional block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
START and STOP conditions [from I2C-bus specification] . . . . . . . . . . . . . . . . . . . . . . . . 227
START byte procedure [from I2C-bus specification] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Multiple master arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Clock synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
SSP block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Dataflow block diagram of the FIrDA controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Tx signal generation at 4 Mbps in FIR mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
SPP interface block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Data transfer timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
ADC block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
GPIO block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
GPIO signal interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
GPIO interrupt triggering logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
GPIO block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
CLCD block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
CLCD clock muxing scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Powering up and down sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Top level diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Doc ID 022640 Rev 3
RM0319
Figure 101.
Figure 102.
Figure 103.
Figure 104.
Figure 105.
Figure 106.
Figure 107.
Figure 108.
Figure 109.
Figure 110.
Figure 111.
Figure 112.
Figure 113.
Figure 114.
Figure 115.
Figure 116.
Figure 117.
Figure 118.
Figure 119.
List of figures
JPGC signal interfaces diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
JPGC block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
I2S block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
I2S clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
C3 block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
System controller block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
System mode control state machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
System operation states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
System control state machine transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Main clock sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
DDR_CLK, HCLK and PCLK clock distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Clock schematic of RAS subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
MISC block top view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
VIC block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Watchdog module block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
DMAC block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
DMAC signal interface diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
DMAC-to-interrupt controller connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
GPT block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Doc ID 022640 Rev 3
21/368
Preface
RM0319
1
Preface
1.1
Terms and conditions
The following terms are used in this document:
●
Reserved: All reserved or unused bits of registers must be written as zero, and ignored
on read unless otherwise stated in the relevant text.
1.2
Conventions
1.2.1
Numbering conventions
The following convention of stating constant numbers is used:
●
[<size in bits>]’<base><number>
where:
●
<size in bits>: (optional) width of bits field associated to <number>
●
<base>: “b” for binary, ‘h” for hexadecimal, “o” for octal, “d” for decimal
●
<number>: value of constant number, according to <base>
Examples:
‘d19
unsized decimal value
8’h2C
8-bit wide hexadecimal value of 0x2C, corresponding to b00101100
8’b011001
8-bit wide binary value of b00011001
32’hFFFF
1.2.2
32-bit wide hexa decimal value of 0xFFFF, corresponding to
b00000000000000001111111111111111
Bits description
The conventions below apply to the description of both bit and registry fields:
1.2.3
●
a bit is defined as “set” when its value is set to ‘b1.
●
a bit is defined as “cleared” when its value is set to ‘b0.
Typographical conventions
Table 1.
22/368
Typographical conventions
Typographic format
Meaning
italic
Highlights notes.
bold
Highlights important terms, definitions and names of registry
field.
MONOSPACE CAPITAL BOLD
Indicates signal names.
Doc ID 022640 Rev 3
RM0319
2
Device overview
Device overview
The SPEAr320S is a member of the SPEAr family of embedded MPUs, optimized for
industrial automation and consumer applications. It is based on the powerful ARM926EJ-S
processor (up to 333 MHz), widely used in applications where high computation
performance is required.
In addition, SPEAr320S has an MMU that allows virtual memory management - making the
system compliant with Linux operating system. It also offers 16 KB of data cache, 16 KB of
instruction cache, JTAG and ETM (Embedded Trace MacrocellTM) for debug operations.
A full set of peripherals allows the system to be used in many applications, some typical
applications being factory automation, printer and consumer applications.
Figure 1 is the internal connectivity block diagram of SPEAr320S.
Table 2 lists the device IP groups and their constituent IPs.
Doc ID 022640 Rev 3
23/368
Simplified block diagram
Figure 1.
SPEAr320S simplified block diagram
JTAG
Trace
Highspeedconnectivity
Memory
BootROM
Device overview
24/368
2.1
USB2.0Host(2x)
ARM926EJS
Subsystem
DebugI/F
StaticRAM
ETMI/F
USB2.0Device
DDR2/LPDDR
Ctrl
EthernetMAC
(2x)
ARM9EJSCore
StaticMemoryCtrl
MMU
Lowspeedconnectivity
SerialFlashI/F
Doc ID 022640 Rev 3
ExternalMemory
I/F
16KB
ICache
UART(7x)
16KB
DCache
UART/RS485
SDIO/MMC
I/F
I2C(3x)
AHBBus
Interfaces
SSP(3x)
CANCtrl(2x)
Graphics,video,audio
DisplayCtrl
Reset&clock
Generator
VectoredInterrupt
Controller
SPP
IrDA
JPEGCodec
System
Controller
Watchdog
ConfigRegs
Timers(6x)
DMACtrl
Security
Coprocessor
I2SAudioI/F
GPIO
XGPIO
Touchscreen
PWM(4x)
ADC
BUSMATRIXInterconnect
RTC
Opt.
Battery
RM0319
RM0319
2.2
Device overview
IP groups
Table 2.
SPEAr320S IP groups
IP group
Constituent IPs
Processors, &
busses
ARM926EJ-S
Multilayer interconnect matrix (BUSMATRIX)
Vectored interrupt controller (VIC)
General device
resources
BootROM
DMA controller (DMAC)
General purpose timers (GPT)
Power, reset and clock control
Real-time clock (RTC)
System controller (SYSCTR)
Watchdog timer (WDT)
Security co-processor (C3)
System configuration registers (MISC)
Memory
interfaces
Multiport DDR controller (MPMC)
MMC-SD card/SDIO controller
Serial NOR Flash controller (SMI)
Parallel NAND Flash controller (FSMC)
External memory interface (EMI)
Graphics, video,
& audio
LCD display controller (CLCD)
JPEG codec accelerator (JPGC)
Digital audio port (I2S)
High-speed
connectivity
Fast Ethernet port (MII0)
Fast Ethernet ports (RMII0/RMII1/MII1)
USB 2.0 Host ports (UHC)
USB 2.0 Device ports (UDC)
Other
connectivity
Analog-to-digital converter (ADC)
Asynchronous serial ports (UART)
Extended general purpose I/O (PL_GPIO)
Basic general purpose I/Os (basGPIO)
I2C bus ports (I2C)
Pulse width modulators (PWM)
Legacy IEEE 1284 parallel port (SPP)
Fast infrared port (IRDA)
Reconfigurable array subsystem (RASCFG)
Controller area network ports (CAN)
Synchronous serial ports (SSP)
Touchscreen interface (TOUCHSCREEN)
Doc ID 022640 Rev 3
25/368
ARM926EJ-S
3
RM0319
ARM926EJ-S
This chapter focuses on ARM926EJ-S functionality and operation.
For technical details about the programmable registers related to the ARM926EJ-S, refer to
the system configuration registers (MISC) in the following companion document:
●
3.1
RM0321: SPEAr320S address map and registers
Overview
The ARM926EJ-S is a powerful processor, targeted for multitasking applications. Belonging
to the ARM9 general purpose family of microprocessors, its main outstanding feature is the
memory management unit, which provides virtual memory features, making it also
compliant with advanced operating systems, like Linux.
The ARM926EJ-S supports the 32-bit ARM and the 16-bit Thumb instruction sets, enabling
the user to trade off between high performance and high code density. It includes features
for efficient execution of byte code Java mode. Additionally, it has the ARM debug
architecture and includes logic to assist in software debug.
3.2
26/368
Main features
●
Max CPU frequency 333 MHz (downward scalable)
●
MMU
●
16 Kbyte of instruction cache + 16 Kbyte of data cache
●
AMBA bus interface
●
JTAG and ETM9 (embedded Trace macro-cell) for debug, Medium+ version
Doc ID 022640 Rev 3
RM0319
3.3
ARM926EJ-S
Functional description
Figure 2.
ARM926EJ-S block diagram
DRDATA
IRDATA
DRWDATA
External Coprocessor
Interface
CPUOUT CPUIN CPUINSTR
ETM
interface
e
Coprocessor
interface
TCM
interface
DEXT
Write buffer
DROUTE
DCACHE
Cache
Data
AHB
Interface
PA
Write back
TAGRAM Write buffer
MMU
WDATA RDATA
ARM9EJ-S
FCSE
TLB
Bus
Interface
unit
INSTR
ICACHE
Intruction
AHB
Interface
IROUTE
IEXT
Note:
The co-processor interface and the TCM interface are not used.
3.3.1
Memory management unit (MMU)
A single set of two-level page tables stored in main memory is used to control the address
translation, permission checks, and memory region attributes for both data and instruction
accesses.
The memory management unit uses a single unified translation look aside buffer (TLB) to
cache the information held in the page tables. To support both sections and pages, there are
two levels of address translation, and the MMU puts the translated physical addresses into
the MMU TLB.
The MMU TLB consists of two parts:
●
The main TLB, which is a two-way, set-associative cache for page table information. It
has 32 entries per way for a total of 64 entries.
●
The lockdown TLB, which is an eight-entry fully-associative cache that contains locked
TLB entries. Locking TLB entries can ensure that a memory access to a given region
never incurs the penalty of a page table walk.
Doc ID 022640 Rev 3
27/368
ARM926EJ-S
RM0319
The MMU features are:
3.3.2
●
Standard ARM architecture v4 and v5 MMU mapping sizes, domains, and access
protection scheme
●
Mapping sizes are 1 MB (sections), 64 KB (large pages), 4 KB (small pages), and 1 KB
(tiny pages)
●
Access permissions for large pages and small pages can be specified separately for
each quarter of the page (subpage permissions).
●
Hardware page table walks
●
Invalidate entire TLB using CP15 c8
●
Invalidate TLB entry selected by MVA, using CP15 c8
●
Lockdown of TLB entries using CP15 c10
Caches and write buffer
The ARM926EJ-S processor includes:
●
a 16-KB instruction cache (ICache)
●
a 16-KB data cache (DCache)
●
a 16-KB write buffer
The caches have the following features:
●
Virtual index, virtual tag, addressed using the Modified Virtual Address (MVA)
●
Four-way set associative, with a cache line length of 32 bytes per line, and with two
dirty bits in the DCache.
●
DCache supports write-through and write-back (or copyback) cache operations,
●
Allocate on read-miss is supported. The caches perform critical-word first cache
refilling.
●
Pseudo-random or round-robin replacement selectable
●
Cache lockdown registers enable control over which cache ways are used for allocation
on a linefill, providing a mechanism for both lockdown and controlling cache pollution.
●
The DCache stores the physical address (PA) tag.
●
PLD data preload instruction does not cause data cache linefills.
●
Maintenance operations to provide efficient invalidation of the entire DCache or
ICache, regions of the two caches or region of virtual memory.
●
Provide operations for efficient cleaning and invalidation of entire DCache, regions of it
and regions of virtual memory.
The latter enables DCache coherency to be efficiently maintained when small code changes
occur, for example for self-modifying code and changes to exception vectors.
28/368
Doc ID 022640 Rev 3
RM0319
3.3.3
ARM926EJ-S
Bus interface unit
The ARM926EJ-S bus interface unit (BIU) arbitrates and schedules the AHB requests.
The BIU contains separate masters for both instruction and data access, enabling multilayer
AHB and multi-AHB systems to be implemented, giving the benefit of increased overall bus
bandwidth and a more flexible system architecture.
To increase system performance, write buffers are used to prevent AHB writes from stalling
the ARM926EJ-S system.
Note:
For a detailed description of the interfaces of ARM926EJ-S, please refer to ARM926EJ-S
Technical Reference Manual.
Doc ID 022640 Rev 3
29/368
Multilayer interconnect matrix (BUSMATRIX)
4
RM0319
Multilayer interconnect matrix (BUSMATRIX)
This chapter focuses on BUSMATRIX functionality and operation.
For technical details about the programmable registers related to the BUSMATRIX, refer to
the system configuration registers (MISC) in the following companion document:
●
4.1
RM0321: SPEAr320S address map and registers
Overview
The internal architecture is based on several shared subsystem logics interconnected
through a multilayer interconnection matrix, shown in Figure 3.
The BUSMATRIX has 7 master inputs: two DMA inputs, and one input each for the CPU,
Reconfigurable Array Subsystem (RAS) block, Ethernet controller, USB controllers and C3.
There are 10 slave outputs connected to almost all the system blocks: low speed
subsystem, application subsystem, basic subsystem, high speed subsystem, RAS and
MPMC DDR memory controller ports.
30/368
Doc ID 022640 Rev 3
RM0319
Figure 3.
Multilayer interconnect matrix (BUSMATRIX)
SPEAr320S block diagram with BUSMATRIX topology details
CPU subsystem
12
Debug
Timer
ARM926EJS
Basic subsystem
Master
clock 2
Master 1
reset
5
0÷6
2
Oscillator
0÷8
16KB
Instr Cache
B
SMI
32KB
ROM
RTC
cfg
MISC
3 4 3-12
0÷6
10
DDR memory interface
1
5-23
Watchdog
timer
Multilayer AHB interconnect matrix
Timer
1-123
8-5 2 7-34 6-67
IrDA
I2C0
SSP0
2-12(4)
6 7
D
M2
M3 M1 M4
4-12 5
A
P
M
I
H
G
F
E
L
High speed
subsystem
4
Reconfigurable array subsystem
74.5 KB RAM
Cuts:
Half Dual Port
(AHB wired):
2048 *32 *1
Dual Port:
96 *128 *1
1024 *32 *4
128 *8 *8
Single Port:
2048 *32 *2
1024 *32 *2
512 *32 *4
2048 *8 *8
56
DDR
9-4
10-6
JPEG
Codec
Multiport memory
controller
M0
GPIO
8KB
SRAM
0÷7
GPIO
8-channel
DMA
Q
0÷2
16KB
Data Cache
Int.Ctrl
System
controller
Low speed
subsystem
0÷2
SPEAr320S
JTAG/ETM9
MII
UART1
to UART6
CLCD
USB 2.0
Host
PWM
I2S
USB 2.0
Device
3
RMII0/1
FSMC/
EMI
CAN0/1
RS485
Ethernet
MAC
0/18 MII
to PHY
SSP1/2
Touchscreen
SPP
SDIO
C
UART0
Application
subsystem
C3
I2C1/2
ADC
8 chan.
RI-O
102
98 GPIO, 4clk
The switch matrix structure allows different subsystem dataflows to be executed in parallel
improving the core platform efficiency.
High performance master agents are directly interconnected with the memory controller
reducing the memory access latency. Three different memory paths (two of them shared
with other masters) are reserved for the programmable logic to enhance the user application
throughput. The overall memory bandwidth assigned to each master port can be
programmed and optimized through an internal efficient weighted round-robin arbitration
mechanism.
Table 3 shows the connectivity matrix.
Doc ID 022640 Rev 3
31/368
Multilayer interconnect matrix (BUSMATRIX)
RAS H
DMAC port 2
DMAC port 1
Processor
RAS L
RAS _E
C3
USB (Host and Device)
Connectivity matrix
Ethernet MAC
Table 3.
RM0319
Targets
MemCtr#0
REQ
MemCtr#1
REQ
MemCtr#2
ICM5
MemCtr#3
ICM7
MemCtr#4
ICM8
REQ1
REQ1
REQ3
REQ2
REQ1
REQ2
REQ4
REQ2
RAS_I
REQ
RAS_M
REQ
RAS_G1
REQ
RAS_G2
REQ
RAS_F
ICM6
Sbs_LowSpeed
ICM1
REQ1
Sbs_High Speed ICM4
REQ1
REQ2
Sbs_Basic
ICM3
REQ1
REQ2
Sbs_Application
LCM2
REQ1
Table 4.
Note:
REQ1
REQ2
REQ2
REQ3
REQ3
REQ2
Connectivity matrix table definition
Format
Definition
Grey box
No connection exists between target and initiator
White box
A connection exists between target and initiator
‘Req’
A connection that is required between target and initiator
EMI or FSMC memory are interconnected with DMA port #1.
SSP1, SSP2, UART1, UART2, I2C1, I2C2, I2S, RS485 peripherals interconnected with
DMA port #2
4.2
Interconnection matrices (ICMs)
The AMBA system has eight programmable multilayer interconnection matrices (ICMs). The
ICM allows multiple master layers to access a slave (see Figure 4).
32/368
Doc ID 022640 Rev 3
RM0319
Multilayer interconnect matrix (BUSMATRIX)
Figure 4.
ICM block diagram
AHB MASTER
(Layer 0)
AHB SLAVE
ICM
AHB MASTER
(Layer N)
priority
Arbiter
A layer is referred to as one or more masters that compete with one master to win ownership
of the slave.
When there is more that one layer looking for access to the slave at the same time, this is
referred to as a clash of requests. Whenever a clash is detected, only one layer can gain
access to the slave. The layer that does not gain access to the slave needs to have its
address and control signals stored into their input stage. When address and control signals
are stored into an input stage, then the stored transfer controls the request and lock
generation circuitry. When a lower priority layer is in the middle of a burst transfer and a
higher priority layer issues a transfer, the higher priority layer is stored and then held off until
the lower priority layer completes the transfer.
Table 5 shows the master layer on each ICM input stages while Table 6 lists the ICM slaves.
Table 5.
ICM master layers (Initiators)
ICM
L0
L1
L2
1
Processor
RAS_H
DMAC Master 1
2
Processor
RAS_H
DMAC Master 2
3
Processor
RAS_H
4
Processor
RAS_H
5
RAS_H
DMA Master 1
6
Ethernet MAC
USB (Hosts - Device)
7
Ras_E
DMAC Master 2
8
C3
USB (Hosts - Device)
Table 6.
Ethernet MAC
L3
C3
ICM slaves (targets)
ICM
M1
1
Sbs_LowSpeed
2
Sbs_Application
Doc ID 022640 Rev 3
33/368
Multilayer interconnect matrix (BUSMATRIX)
Table 6.
RM0319
ICM slaves (targets) (continued)
ICM
M1
3
Sbs_Basic
4
Sbs_Highspeed
5
MemCtr#2 (MPMC)
6
Ras_F
7
MemCtr#3 (MPMC)
8
MemCtr#4 (MPMC)
In the miscellaneous register bank, eight registers are allocated (ICM_x_ARB_CFG), one
for each ICM.
These registers have all the same layout:
34/368
●
The 31st bit is in charge of choosing the arbitration scheme: fixed priority or round robin
●
Bits [30:28] specify the priority starting level in case of round robin arbitration protocol
●
Then 3 bits are allocated to each layer to set the priority level in case of fixed priority
scheme: bits [2:0] for Layer0, [5:3] for Layer1 and so on.
Doc ID 022640 Rev 3
RM0319
5
BootROM
BootROM
This chapter focuses on Boot ROM functionality and operation; BootROM is a small piece of
code that starts its execution just after the SoC exits from reset.
5.1
Boot modes
●
Boot from NOR serial Flash
●
Boot from NAND Flash
●
Boot from NOR parallel Flash
●
Boot / Upgrade from USB
●
Boot from UART0
●
Boot from Ethernet (MII0)
●
Boot ROM Bypass
The first three modes are the normal ways of booting the software and require a secondlevel boot software (X-Loader) in NOR/NAND Flash.
USB Boot is meant to boot without Flash memories. It is used to upgrade 1st to 3rd level
boot in Flash memories.
.
Table 7.
Booting types
Booting using Flash memories
Upgrading the Flash memories
Serial NOR
USB
Parallel NOR
Ethernet I2C boot mode
Parallel NAND
Ethernet SPI boot mode
UART0
BootROM Bypass
5.2
Boot stages
Figure 5 describes boot stages on SPEAr320S in more details. There are 4 stages of
booting:
●
Boot stage 1 (BootROM)
●
Boot stage 2 (X-Loader)
●
Boot stage 3 (Bootloader e.g. U-Boot)
●
OS
Doc ID 022640 Rev 3
35/368
BootROM
RM0319
Figure 5.
Boot stages
After exiting the reset state, the ARM runs the
BootROM code.
BootROM
1. In the case of Flash booting it copies a second
level boot code from Flash to the internal SRAM
(shadow memory) and jumps to it. This mechanism
is called ‘Code Shadowing’
2. In case of non-Flash booting, it receives the
second level boot code, executes it and then
receives third level boot code and jumps to it.
3. Upgrade the Flash through USB.
This is the second level boot code. It should be very
small to fit into the internal SRAM (8 KB) and know
the timing details of the external SDRAM. It enables
SDRAM and:
X-Loader
1. In the case of Flash booting, it copies the third
level boot code and jumps to it.
2. In case of non-Flash booting, it jumps back to
BootROM.
5.3
Bootloader
This is the third level boot code. It copies the primary OS
into the SDRAM and jumps to it.
OS
This is the primary OS
Booting pins
Refer to the datasheet for the table of Boot pin values used to select each boot mode. The
values of the pins are latched at startup and are readable from the Boot_Strap_Reg
described in the RAS configuration (RASCFG) chapter in RM0321: SPEAr320S address
map and registers.
36/368
Doc ID 022640 Rev 3
RM0319
5.4
BootROM
Hardware overview
Figure 6.
Hardware memory
SPEAr320S
D2800000h
Shadow
Memory
NAND/
NOR
FLASHES
eSRAM
Power On Reset
ARM
FF00.0000h
Boot ROM
SDRAM
(DDR2)
High Vectors
eROM
5.4.1
eROM (Embedded ROM)
eROM is the 32KB of area starting from 0xFFFF_0000. The ARM processor is mapped to
HIGH vectors and starts executing instructions from 0xFFFF_0000.
5.4.2
Shadow memory
Shadow memory is the area where BootROM copies the X-Loader after reading/receiving
from any of the booting processes. Address where X-Loader is copied in the shadow
memory is specified in the X-Loader header.
5.4.3
System controller
The system controller is used to program/control the system clock mode and frequency.
After reset, the system is set to DOZE mode.
BootROM configures the system in different modes depending on different booting types:
●
For serial NOR, parallel NOR, 8/16-bit NAND, UART0 and BootROM bypass booting:
SLOW mode (CPU 24 MHz - AHB 24 MHz)
●
For Ethernet and USB booting: NORMAL mode (CPU 333 MHz - AHB 166 MHz)
Doc ID 022640 Rev 3
37/368
BootROM
5.5
RM0319
Software overview
This section describes the BootROM software for the device.
5.5.1
ARM processor modes
SPEAr BootROM runs in supervisor mode during the entire execution.
5.5.2
SoC peripheral interrupts
SPEAr BootROM runs with all interrupts disabled, except in the particular case of
boot/upgrade through USB, in which case it enables the USB interrupt.
5.5.3
Memory overview
BootROM in SPEAr is located at 0xFFFF_0000. It has two sections:
●
Code section
●
Table section
Code section
Code section starts from 0xFFFF_0000 and ends at 0xFFFF_7EFF. This section contains all
the routines required to boot on SPEAr device.
Table section
Table section starts from 0xFFFF_7F00 and ends at 0xFFFF_7FFF. In the table section, a
table is maintained keeping the information usable by the second level boot, for instance
addresses of NAND routines. These routines of BootROM are used by X-Loader. This helps
reducing code length of X-Loader.
The table consists of one structure having the following two variables:
●
Table version (data type: unsigned integer)
●
Version specific structure
The following figure shows the memory used by BootROM:
Figure 7.
Usage of memory by BootROM
0xFFFF_7FFF
Unused Section
0xFFFF_7FXX
Table Section
0xFFFF_7F00
Unused Section
0xFFFF_XXXX
Code Section
0xFFFF_0000
38/368
Doc ID 022640 Rev 3
RM0319
5.5.4
BootROM
X-Loader and U-Boot header
typedef struct image_header
{
uint32_t ih_magic; /* Image Header Magic Number */
uint32_t ih_hcrc; /* Image Header CRC Checksum */
uint32_t ih_time; /* Image Creation Timestamp */
uint32_t ih_size; /* Image Data Size */
uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
uint32_t ih_dcrc; /* Image Data CRC Checksum */
uint8_t ih_os; /* Operating System */
uint8_t ih_arch; /* CPU architecture */
uint8_t ih_type; /* Image Type */
uint8_t ih_comp; /* Compression Type */
uint8_t ih_name[IH_NMLEN]; /* Image Name */
} image_header_t;
5.5.5
X-Loader and U-Boot authentication
At the next phase, X-Loader and U-Boot authentication is done by:
5.6
●
Comparing the value of the Boot_Strap_Reg (address 0xB3000000) to select the boot
mode
●
Comparing the magic number in received header with 0x27051956.
●
Checking the CRC of the image header and image received with the CRCs present in
the header.
Boot flows
A diagrammatic representation of the boot flow is given below. A detailed explanation of
each boot flow is explained in further sections:
●
Serial NOR Flash
●
UART0
●
BootROM Bypass
●
Parallel NAND Flash
●
USB upgrade
●
Parallel NOR Flash
●
Ethernet
Doc ID 022640 Rev 3
39/368
BootROM
RM0319
Figure 8.
Boot flow
Start
Initialize
interrupts
SMI initialization
Test boot type
Proceed to
specific boot
Boot
successful?
Yes
Jump to X-loader/ U_Boot
No
Infinite loop
5.6.1
Serial NOR Flash boot
In NOR Boot, BootROM tries to authenticate X-Loader in the first sector of Flash. The load
address of X-Loader (ih_load) is specified in the 64-byte X-Loader header.
Authentication is performed in 3 steps:
1.
The value of bits 3:0 in the Boot_Strap_Reg (address 0xB3000000) is compared with
0x3
2.
ih_magic is compared with 0x27051956
3.
ih_hcrc is compared with the calculated CRC of the header
If the authentication is successful, then BootROM copies X-Loader from Flash to ‘shadow
memory’ area (address pointed to by ih_load) and jumps to it.
If X-Loader authentication fails, or any other error occurs during serial NOR boot, BootROM
shifts to USB boot.
5.6.2
Serial (UART0) boot
Serial boot initializes the UART0 IP and uses the X-modem protocol to receive the X-Loader
image at a fixed baud rate of 11250 bits per second (bps). It then runs the X-Loader image
which initializes the PLLs and DDR and then returns back the control to the boot code. After
this, X-modem protocol is again used to download the U-Boot image into DDR and then the
image is run from there. To be noted that this booting mode does not require any nonvolatile memory to be present on the board.
40/368
Doc ID 022640 Rev 3
RM0319
BootROM
Figure 9.
Serial boot
Initialize UART
Receive X - Loader
through X - modem
protocol
Authenticate
X - Loader?
Failed
Passed
Run X - Loader from
eSRAM area
Return to BootROM
Receive U - boot through
X - modem protocol
Authenticate
Failed
U - boot?
Passed
Run U - boot from DDR
Doc ID 022640 Rev 3
41/368
BootROM
5.6.3
RM0319
BootROM Bypass
BootROM bypass mode uses the serial NOR device in XIP (execute in place) mode. The
image header is authenticated and the code directly jumps to an address pointed to by the
image load address (ih_load) found in the image header. When using BootROM bypass
mode, no validation or authentication is performed on the image data, it is the sole
responsibility of the user to ensure that the image being executed comes from a trusted
source
Header authentication is performed in 3 steps:
1.
The value of bits 3:0 in the Boot_Strap_Reg (address 0xB3000000) is compared with
0xB
2.
ih_magic is compared with 0x27051956
3.
ih_hcrc is compared with the calculated CRC of the header
If the authentication is successful, then BootROM jumps to address ih_load
If authentication fails, or any other error occurs, BootROM shifts to USB boot.
Figure 10. Serial NOR Flash boot & BootROM bypass
BootROM
YES
bypass
Bypass mode
Jump to
authenticated?
ih_load
NO
Failed
Authenticate X - Loader?
USB boot
Passed
Copy X - Loader from Flash to shadow memory
Jump (at ih_load) to X - Loader in shadow memory
5.6.4
NAND Flash boot
1.
42/368
To detect NAND devices, initialize the FSMC controller with the relaxed timing values:
–
Thiz
= 0x01
–
Thold = 0x04
–
Twait = 0x06
–
Tset
= 0x00
Doc ID 022640 Rev 3
RM0319
BootROM
BootROM code reads the device ID code and looks for it in a table which contains all
supported device codes. Then, it fills a device description structure for page_size,
block_size, memory size and spare command according to this ID code.
After that, it searches for X-Loader in the first page of every block of the Flash starting from
the 1st block to the 4th block. Before reading the block, it checks the sanity by reading the
1st word of the spare area of each block which should be 0xFF. If it not 0xFF, it skips to the
next block.
2.
Read the whole page in a buffer (buffer size equals page size) and search for X-Loader.
If found, return to the start address.
3.
Find the transfer size from the header. Calculate the number of pages and start reading
the pages from the Flash copying them into the shadow memory.
4.
Authenticate X-Loader. If authenticated, jump to the start address, otherwise jump to
USB boot.
5.
While reading, check ECC for every page, read ECC from the NAND memory spare
area and from the FSMC controller. If there is an error of 1 bit, fix it, otherwise you will
get a “Boot failed” message.
Doc ID 022640 Rev 3
43/368
BootROM
RM0319
Figure 11. NAND Flash boot
Notes:
Initialize FSMC controller for NAND
1) Check device id, if it is
8 bit, then proceed
2) Else jump back to FSMC
Read device ID code
initialize and try for 16
bit NAND boot
Notes:
Compare ID and fill device descriptor
1) Check in first four blocks of
NAND, starting from first
block.
Search X - Loader in NAND
2) Before reading block, its
st
sanity is checked by reading 1
word of spare area on first page.
It should be 0xFF. (0xFF
represents sanity)
No
X - Loader Found
USB boot
YES
Copy X - Loader to shadow memory
Failed
Authenticate X - Loader?
Passed
Jump to X - Loader in shadow memory
44/368
Doc ID 022640 Rev 3
USB boot
RM0319
5.6.5
BootROM
USB boot
USB boot refers to upgrading of Flash memories (NAND and NOR) via USB. In USB boot,
BootROM programs PLL1 to 333 MHz and system to Normal mode, for instance ARM
frequency at 333 MHz, initializes the USB Device Controller (UDC) and initializes USB state
machine to GET_CMD phase.
UDC supports 2 modes of operation, Slave mode and DMA mode, in SPEAr BootROM UDC
is configured in slave mode.
After initializing, BootROM waits for a 12 byte command on BULK Out End point 2 from the
USB Host, the format for 12 byte command is as follows:
Table 8.
Command format
Byte 0
Type of Data
Byte 1 - 3
RESERVED
Byte 4 - 7
Size of Data
Byte 8 - 11
Load Address in RAM
After receiving 12 bytes, BootROM decodes 12 byte command, changes the USB state
machine to GET_DATA phase and waits for the expected number of bytes from the Host.
BootROM receives the data and stores it into the load address specified in the command,
once all the data is received, BootROM changes the USB state machine to EXEC phase
and decodes the type of data. If the received data is DDR Driver, then BootROM jumps to
load address, executes the DDR driver and jumps back to BootROM. Now that the DDR is
initialized, BootROM changes the USB state machine again to GET_CMD phase. Now
same process is repeated again, but this time type of data received is FIRMWARE, the
FIRMWARE is capable of receiving data from Host, Flash upgrade capable etc. After
receiving the FIRMWARE, BootROM jumps to it in DDR.
The current version of BootROM uses the slave mode, because of limitation of SPEAr
architecture i.e. there is no Path from UDC DMA to access descriptors present in eRAM.
Doc ID 022640 Rev 3
45/368
BootROM
RM0319
USB descriptors
As part of the process, several descriptors are exchanged. A detailed description is provided
below:
1.
Device Descriptors: Each gadget has one device descriptor.
Table 9.
Offset
Field
Size
Value
0
bLength
Byte
0x12
1
bDescriptorType
Byte
0x01
2
bcdUSB
Word
0x200
4
bDeviceClass
Byte
0x00
5
bDeviceSubClass
Byte
0x00
6
bDeviceProtocol
Byte
0x00
7
wMaxPacketSize0
Byte
0x40
8
idVendor
Word
0x0483
10
iProduct
Word
0x3801
12
bcdDevice
Word
0x100
14
iManufacturer
Byte
0x01
15
iProduct
Byte
0x02
16
iSerial Number
Byte
0x03
17
bNumConfigurations
Byte
0x01
2.
Configuration descriptors: Each device has one default configuration descriptor
which supports at least one interface.
Table 10.
46/368
Device descriptor
Configuration descriptor
Offset
Field
Size
Value
0
bLength
Byte
0x09
1
bDescriptorType
Byte
0x02
2
bTotalLength
Word
0x0020
4
bNumInterfaces
Byte
0x01
5
bConfigurationValue
Byte
0x01
6
iConfiguration
Byte
0x00
7
bmAttributes
Byte
0xE0
8
MaxPower
Byte
0x00
Doc ID 022640 Rev 3
RM0319
BootROM
3.
Interface descriptors: Each device has a single data interface with no possible
alternates.
.
Table 11.
Interface descriptor
Offset
Field
Size
Value
0
bLength
Byte
0x09
1
bDescriptorType
Byte
0x04
2
bInterfaceNumber
Byte
0x00
3
bAlternateSetting
Byte
0x00
4
bNumEndpoints
Byte
0x02
5
bInterfaceClass
Byte
0x00
6
interfaceSubClass
Byte
0x00
7
bInterfaceProtocol
Byte
0x02
8
iInterface
Byte
0x01
4.
Endpoint descriptors: A device supports the following endpoints.
a)
.
Table 12.
Bulk OUT endpoint. Used for transfer of data from host to device.
Bulk OUT endpoint descriptor
Offset
Field
Size
Value
0
bLength
Byte
0x07
1
bDescriptorType
Byte
0x05
2
bEndpointAddress
Byte
0x02
3
bmAttributes
Byte
0x02
4
wMaxPacketSize
Word
0x040
6
bInterval
Byte
0x00
b)
Table 13.
Bulk IN endpoint. Used for transfer of data from device to host.
Bulk IN endpoint descriptor
Offset
Field
Size
Value
0
bLength
Byte
0x07
1
bDescriptorType
Byte
0x05
2
bEndpointAddress
Byte
0x81
3
bmAttributes
Byte
0x02
4
wMaxPacketSize
Word
0x040
6
bInterval
Byte
0x00
Doc ID 022640 Rev 3
47/368
BootROM
RM0319
5.
String descriptors
Table 14.
48/368
String descriptor
Offset
Field
Size
Value
0
bLength
Byte
0x04
1
bDescriptorType
Byte
0x03
2
bEndpointAddress
Byte
0x0409
Doc ID 022640 Rev 3
RM0319
BootROM
Figure 12. USB boot
System initialization to Normal mode
Initialize UDC controller
Initialize USB state machine (GET_CMD)
Wait for command on BULK out End point 2
from USB host
Decode the command
Change state machine (GET_DATA)
Receiving
DDR driver
Wait for expected number of bytes from Host.
Receive DDR driver and change state to Exec
Execute DDR driver and jump back to
BootROM
Change state machine (GET_CMD)
Wait for command on BULK out End point 2
from USB host
Decode the command
Change s tate machine (GET_DATA)
Receiving
Firmware
Wait for expected number of bytes from Host.
Receive firmware and jump to firmware in
DDR
Doc ID 022640 Rev 3
49/368
BootROM
5.6.6
RM0319
Parallel NOR Flash boot
Parallel NOR on reset is always in read mode. Using this feature, we program the EMI
controller with appropriate values tested in simulations.
BootROM searches for X-Loader in Parallel NOR sector 0 and copies X-Loader to eSRAM.
If any error occurs during parallel NOR boot, BootROM shifts to USB boot.
Figure 13. Parallel NOR Flash boot
Note : Boot type specification tells if it
Initialize EMI controller for NOR
is 8-bit NOR or 16-bit NOR
Search X - Loader in NOR
NO
X -Loader Found?
USB boot
YES
Copy X -Loader to eSRAM
Authenticate
Failed
X- Loader?
Passed
Jump to X - Loader in eSRAM
50/368
Doc ID 022640 Rev 3
USB boot
RM0319
5.6.7
BootROM
Ethernet boot
Ethernet boot mode is supported via the MII0 interface of the SPEAR320S.
There are two different Ethernet boot modes:
●
Ethernet I2C boot mode
●
Ethernet SPI boot mode
The only difference between these two modes is the underlying protocol used to read the
MAC address from EEPROM. The modes are selected by setting the booting pins (see
Section 5.3).
●
In Ethernet I2C boot mode, the device tries to read the MAC address from the
EEPROM using the I2C protocol. The EEPROM is assumed to be present at I2C
address 0x50.
●
In Ethernet SPI boot mode, the device tries to read the MAC address from the
EEPROM using the SPI protocol. EEPROM is assumed to be on CS 0.
For both types of EEPROMs, BootROM first tries to see if it contains a valid MAC address or
not. This is determined by reading two bytes from offset 0 (in both cases). For a MAC
address to be valid, the first byte should be 0x55 and the subsequent byte should be 0xAA.
Otherwise, it considers the MAC address stored in EEPROM as valid and reads it. So, the
next 6 bytes (from offset 0x2 in the EEPROM) are considered as the MAC address and the
booting proceeds further.
Pictorially, for EEPROM to have a valid MAC address its contents should be:
Note:
Address
offset
0x0
0x1
0x2
0x3
0x4
0x5
0x6
0x7
Contents
0x55
0xAA
MAC01
MAC02
MAC03
MAC04
MAC05
MAC06
If there is no EEPROM present on the board or the MAC address is invalid, the device uses
the default MAC address 00:80:E1:00:55:01
Additionally, Ethernet boot mode uses the following two protocols:
●
DHCP: To acquire configuration information, such as IP address, default route and
TFTP server IP address
●
TFTP: To receive X-Loader and U-Boot images
Once the device has its own IP, it can communicate with the TFTP server to download the
images and execute them. The first image which is downloaded is X-Loader. It is
responsible for initializing the PLLs and DDR memory. The U-Boot image is downloaded
and run after X-Loader has completely run.
The boot mode flow is described below. (see also Figure 14):
1.
Once the SPEAr device gets the MAC address, it initiates the DHCP protocol and
broadcasts a DHCP DISCOVER message.
2.
The DHCP server (in the network) must be configured to recognize the MAC address
that the device uses so that it can respond with appropriate network parameters (IP
address, default Gateway, subnet mask and TFTP SERVER IP). So, in response to
Doc ID 022640 Rev 3
51/368
BootROM
RM0319
DHCP_DISCOVER, the dhcp server sends the network parameters in a
DHCP_OFFER message.
52/368
3.
The SPEAr device then shows its willingness to accept the network parameters
received from the DHCP server by responding with DHCP REQUEST message.
4.
The DHCP server responds with DHCP_ACKNOWLEDGE message and completes
the DHCP protocol.
5.
Next, the device initiates the TFTP protocol and sends a request for the "xloader.bin"
file. The TFTP server running over the network whose address was provided in step 2
must have the xloader.bin file in it's TFTP boot directory.
Doc ID 022640 Rev 3
RM0319
BootROM
Figure 14. Ethernet boot
Initialize Ethernet
Note : DHCP timeout is 5 seconds. If a
timeout occurs, BootROM starts this
operation again.
Take IP through DHCP
IP Received
Note : TFTP timeout is 5 seconds. If a
Receive X - Loader
timeout occurs, BootROM starts this
operation again.
through TFTP
Failed
Authenticate
X - Loader?
BootROM enters
infinite loop
Passed
Note : TFTP timeout is 5 seconds. If a
Run X - Loader and return
timeout occurs, BootROM starts this
operation again.
to BootROM
Receive U - boot through
TFTP
Authenticate
U - boot
Failed
BootROM enters
infinite loop
Passed
Run U - boot
Doc ID 022640 Rev 3
53/368
Multiport DDR controller (MPMC)
6
RM0319
Multiport DDR controller (MPMC)
This chapter focuses on MPMC functionality and operation.
For technical details about the programmable registers related to the MPMC, refer to the
MPMC registers in the following companion document:
●
6.1
RM0321: SPEAr320S address map and registers
Overview
MPMC is a high performance multiport memory controller able to support Mobile DDR and
DDR2 double data rate memory devices. The multiport architecture ensures memory is
shared efficiently among different high-bandwidth client modules.
It offers 6 internal ports. One of them is reserved to register access during the controller
initialization while the other five are used to access the external memory.
It also includes the physical layer (PHY) and some DLL that allow a fine tuning of all the
timing parameter to maximize the data valid windows at every frequency in the allowed
range.
54/368
Doc ID 022640 Rev 3
RM0319
6.2
Multiport DDR controller (MPMC)
Main features
●
Multichannel AHB interfaces:
–
Five independent AHB ports
–
Separate AHB memory controller programming interface
–
Supports all AHB burst types
–
Lock transactions are not supported
–
Port queue post multiple AHB transactions
●
Internal efficient port arbitration scheme to ensure high memory bandwidth utilization.
●
Fully pipelined read - write commands
●
Advanced bank look-ahead features for high memory throughput
●
Programmable register interface to control memory device parameters and protocols
including the following main functionalities:
–
Auto pre-charge
–
Read/write grouping
–
Bank splitting
–
Bank grouping
–
Swapping
–
Aging
●
Full initialization of memory on memory controller reset
●
DRAM controller supports both DDR-Mobile and DDR2 memory devices:
–
DDR Mobile up to 166 MHz (333 MT/sec)
–
DDR2 up to 333 MHz (666 MT/sec)
●
Memory frequency with DLL enable configured within range from 100 MHz to 333 MHz.
●
Controller supports:
–
Wide range of memory device: 128 MBit, 256 MBit, 512 MBit, 1 MBit, 2 MBit
–
Two chip selects
–
Memory data with 8 or 16 bits
Doc ID 022640 Rev 3
55/368
Multiport DDR controller (MPMC)
●
6.3
RM0319
Configurable memory parameters:
–
Row address from 8 to 15 bits
–
Column address from 7 to 14 bits
–
Memory internal banks 4 or 8
●
Programmable DQS0/1 signals per byte configurable single ended and differential
mode
●
Built-in adjustable delay compensation circuitry (DCC) for reliable data sends and
captures timing
●
Dynamic memory self refresh power reduction automatically activated from SoC power
management unit
Functional description
Figure 15. MPMC block diagram
AHB-CFG
AHB0
AHB1
CORE
Controller
PHY
Ext.Memory I/F
AHB2
AHB3
AHB4
Multi port Memory Controller
The multiport memory controller supports high memory bandwidth and an efficient
arbitration scheme for high priority agent requests.
The memory controller architecture consists of the following main sub-blocks:
●
AHB port interfaces
●
Arbiter
●
Command queue with placement logic
●
Write data queue
●
DRAM command processing
The core controller interfaces with standard AHB ports through the interface blocks. All
requests are processed through the internal arbiter which feeds single commands to the
command queue of the core controller. Write and read data is routed independently of the
arbiter through the data interfaces. There are multiple write data interfaces to the write data
56/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
queue of the core controller, and a single read data interface back from the core controller to
the port interface blocks. The architecture of the multiport system is shown in Figure 16.
Figure 16. Memory controller architecture
AHB0
Port queue
AHB1
Port queue
AHB2
Port queue
AHB3
Port queue
AHB4
Port queue
Write data
queue
Command
queue
Placement
Logic
Arbiter
Read data
queue
AHB Port I/
F
AHB-CFG
DRAM
Command
Logic
PHY
CORE Controller
CFG
REG
The interface blocks contain FIFOs for commands, READ and WRITE data, handling any
clock domain crossings as required. From the port interface blocks, commands are
processed by an arbiter which feeds single commands to the command queue of the
memory controller core. WRITE and READ data are routed directly to the WRITE and
READ data queues of the memory controller core, arbiter independently.
Each port has a distinct WRITE data interface to the WRITE data queue of the memory
controller core. However, for READ data, all ports share a single READ data interface back
to the port interface blocks.
6.3.1
AHB memory controller interfaces
The memory controller core interfaces with 5 AHB data ports and 1 AHB register port. The
AHB data ports function as AHB slaves to external AHB masters such as CPUs, DMAs and
other peripherals. The port implementation is restricted to support the AHB-lite protocol and
is designed for multilayer AHB architectures. This implies that an AHB slave port will never
respond with a SPLIT or a RETRY response type. Early termination of AHB bursts is fully
supported.
Note:
An AHB slave port can be used in a system with masters that support the full AHB protocol
as long as the system is multilayer AHB.
The AHB memory controller interfaces handle all communication between the AHB bus and
the memory controller core. An incoming AHB transaction is first synchronized from the
AHB clock domain to the core clock domain, then mapped into a core-level transaction, and
finally stored in the AHB port FIFOs. From the AHB FIFOs, the transaction is presented to
the arbiter which arbitrates requests from all ports and forwards a single transaction to the
core.
Doc ID 022640 Rev 3
57/368
Multiport DDR controller (MPMC)
RM0319
Configured options
Each AHB port in the memory controller has been defined for the requirements of the
intended system. The configured options are:
Type of interface
All ports of the MPMC are clock domain programmable relative to the main core clock.
These ports initialize in asynchronous operation, but can be changed by programming the
associated ahbY_fifo_type_reg parameter. For more information on setting this parameter,
refer to Port clocking.
Asynchronous FIFOs handle the clock domain crossing when operating in any of the non
synchronous modes. Refer to Table 15: Configured AHB settings, for the clock relativity for
each port.
Note:
When switching between asynchronous and synchronous mode of operation, ensure that
there are no outstanding transactions on the port whose behaviour is being changed. If
transactions are waiting, there may be unexpected loss of data or a lockout condition on that
AHB port.
Datapath width
Each port has a data interface width of 32 bits.
READ and WRITE command Lengths for INCR Operations
AHB ports handle sequential requests of unspecified length (INCR) by issuing block data
requests of the size programmed in the associated ahbX_wrcnt or ahbX_rdcnt parameter
(where X is the port number). If the request is larger than the value programmed in that
parameter, the request will be divided into multiple requests. Subsequent read commands
will be issued when the last word of data has been delivered back to the requesting AHB
port. Subsequent WRITE commands will be issued after the last data word of the previous
request has been transferred from the AHB interface to the memory controller core. The
value defined in each parameter should be a multiple of the number of bytes in the AHB bus
width. For this memory controller, since the AHB bus width is 32 bits, these parameters
should be programmed to 4, 8, 12, 16, etc. up to 1024 bytes.
Port FIFO depths
Each data port contains a read, a write and a command FIFO. The depth of each buffer in
each port is listed in Table 15: Configured AHB settings.
Error detection
When an illegal operational condition is detected on a new AHB transaction entering the
port, the port responds with an ERROR.
Port clocking
There are four user-selectable modes of operation for each of the AHB memory controller
port interfaces.
The mode is set by programming the corresponding ahbY_fifo_type_reg parameter. The
four settings are:
●
58/368
Synchronous ('b11)
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
The AHB port clock and the MPMC core clock must be aligned in frequency in phase. The
AHB-memory controller port interface block will not be required to perform any clock
synchronization in any of the FIFOs.
●
2:1 Port: Core Pseudo-Synchronous ('b10)
The port operates at half of the frequency of the core frequency, with clocks that are
aligned in phase. One stage of the two-stage synchronization logic of the FIFOs will be
utilized to synchronize commands, WRITE data and READ data to the appropriate
clock domain.
●
1:2 Port: Core Pseudo-Synchronous ('b01)
The port frequency is twice the core frequency, although the clocks are aligned in
phase. One stage of the two-stage synchronization logic of the FIFOs will be utilized to
synchronize commands, WRITE data and READ data to the appropriate clock domain.
●
Asynchronous ('b00)
The AHB bus and the memory controller core operate on clocks that are mismatched in
frequency and phase. The AHB port FIFOs use two stages of synchronization logic to
synchronize commands, WRITE data and READ data to the appropriate clock domain.
AHB Port FIFOs
Incoming transactions on the AHB bus are processed by the interface logic and mapped into
equivalent transactions on the memory controller core bus. These transactions are queued
in the port FIFOs.
There are three separate AHB port FIFOs for commands, READ data and WRITE data. The
depths of the FIFOs are configured by the user and generally dependent on system
requirements.
Command FIFO
The command FIFO holds the AHB command address, burst type and size. Typically, the
command FIFO is fairly small in depth due to the single-threaded, pipelined nature of the
AHB protocol. The protocol does not allow more than one outstanding transaction on any
AHB port. A deeper command FIFO is only useful in situations when the master issues
several very short WRITE bursts.
In this case, the commands and the associated data will be completely captured in the
command and write FIFOs and the bus will be free to start other operations.
Read FIFO
The read FIFO holds the ahbX_HRDATA signals sent back from the memory controller.
There is only one streaming READ data interface out from the memory for all AHB ports.
The memory controller steers this data stream to the port that requested the data. As a
result, the AHB ports must be ready to accept the READ data as soon as it is available on
the internal memory controller core bus to avoid stalling the memory controller itself.
Write FIFO
The write FIFO holds the ahbX_HWDATA signals sent into the memory controller. The depth
of the write FIFO depends on the typical length of a burst write transaction.
Note:
There is a WRITE data queue inside the memory controller core as well. Therefore, the
write FIFOs allow the AHB bus to off load its WRITE command completely before it is fully
transferred to the memory controller core buffers.
Doc ID 022640 Rev 3
59/368
Multiport DDR controller (MPMC)
Table 15.
6.3.2
RM0319
Configured AHB settings
Port
number
Data
width
Clock domain type
Command
FIFO depth
Write FIFO
depth
Read FIFO
depth
0
32
Async or Sync
8
8
8
1
32
Async or Sync
8
8
8
2
32
Async or Sync
8
16
16
3
32
Async or Sync
8
8
8
4
32
Async or Sync
8
8
8
AHB register port
The AHB memory controller interface contains a special register port for converting AHB
register addresses to the core register addresses. This port operates asynchronously.
However, unlike the data ports, the register port has no allocated storage in the form of
FIFOs.
The register port only supports the AHB SINGLE transaction burst types for all transactions
with a bytes-per-beat (2ahbX_HSIZE) equal to or less than the width of the AHB register
bus. There is no support for WRAP transactions or early burst termination for the register
port. BUSY cycles can be inserted between the incrementing burst operations.
Similar to the data ports, the AHB register port responds to illegal conditions with the
ERROR response. However, a register port ERROR will only occur when the transaction
address is not aligned to the size of the transaction.
All parameters related to the AHB port operation are located in the MPMC core register
map.
These parameters are programmed during the MPMC initialization sequence along with all
of the other device parameters. A typical boot-up sequence includes a reset of the AHB
ports as well as of the MPMC core, followed by core setting for AHB operation by AHB
register port.
6.3.3
AHB transactions
The AHB memory controller supports the complete set of AHB transactions. The list
includes: SINGLE, INCR4, INCR8, INCR16, WRAP4, WRAP8, WRAP16 and INCR.
For documentation purposes, INCRx will refer to INCR4, INCR8 or INCR16 commands.
WRAPx will refer to WRAP4, WRAP8 or WRAP16 commands. Command handling is
defined for full-size transfers, in which the bytes-per-beat is equal to the bus width, or narrow
transfers, where the bytes-per-beat is less than the bus width.
Full-Size SINGLE, INCRx or WRAPx transactions
SINGLE and INCRx transactions with a bytes-per-beat value (2ahbX_HSIZE) equal to the
width of the AHB bus are issued as single memory controller commands to the core. The
starting address of the transaction is the same as the address specified during the first
NONSEQ beat of the corresponding AHB transaction. The MPMC core accepts these
commands in a pipelined fashion such that, for read transactions, the READ data can be
delivered in contiguous data words back to the AHB interface. These words may not be
contiguous if other AHB requests with higher priority get placed ahead of some of these
commands, or if the read queue inside the core is not deep enough to absorb a full burst.
60/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
WRAPx transactions with a starting address that is not aligned to the total number of bytes
in the burst (bytes-per-beat times the number of beats) are issued as two separate memory
controller core transactions as shown in Figure 17. The first transaction has a starting
address which is the same as the WRAP transaction starting address and its byte count is
the number of bytes from the starting address to the wrap boundary. The second transaction
has a starting address which is aligned to the byte count in the WRAPx transfer and its byte
count is the number of bytes from the wrapped address back to the starting address. This
means that an AHB WRAP instruction is divided into two core transactions, one for the nonwrapped portion of the transaction and one for the wrapped portion. The starting address
determines whether the WRAP transaction will actually wrap or not. A wrap transaction with
an aligned address is equivalent to an INCRx command and is treated as such by the AHB
port.
Figure 17. WRAPx effective transaction
Memory Page Containing Starting Address
Starting
Address
Wrap
Address
WRAPx Command
Length = X*ahbX_HSIZE
Transaction #1
Transaction #2
The command wraps at address:
(Starting Address+X)-Modules(Starting Address/X)
Where X is the Wrap Size in WARPx
Starting Address-Modules (Starting Address/X)
Where X is the Wrap Size in WARPx
Full-Size INCR transactions
Since the MPMC core bus protocol does not support transactions of an unspecified length,
AHB INCR transactions require special handling by the AHB port logic. Each AHB port
contains a pair of programmable parameters for determining the length of a command that
will be issued to the MPMC core when an INCR command is issued to the AHB port. These
parameters are ahbX_wrcnt and ahbX_rdcnt and they hold the programmed size used for
an unspecified length WRITE and a READ command length in bytes for port X when this
type of command is issued to the core.
The value defined in these parameters should be a multiple of the number of bytes in a data
word for the core. If that is not the case, the parameter values will automatically be truncated
to the data word boundary. Clearing these parameters will cause the port to issue
commands of 0 length to the core, which the core interprets as the pre-configured value of
1024.
The values for the ahbX_wrcnt and ahbX_rdcnt parameters should be chosen carefully and
should be based on the average length of an INCR transaction expected from the AHB
master. If the values are programmed too low, the AHB port must issue a large number of
small core transactions that may fill up the command queue and reduce system
performance. A full queue may also inhibit higher priority requests from meeting their
latency requirements. On the other hand, if the values for the parameters are programmed
Doc ID 022640 Rev 3
61/368
Multiport DDR controller (MPMC)
RM0319
too high, then write transactions may force the AHB port to issue masked WRITE
commands (WRITE commands that do not alter the contents of memory) to the core to
complete the transactions. Similarly, for READ transactions, programming the length too
large will cause extraneous data to be gathered, wasting cycles. An optimal value for the
READ and WRITE length is important.
Note:
The values in the ahbX_wrcnt and ahbX_rdcnt parameters should never exceed 1024.
The first command is issued when the AHB request is decoded. Subsequent read
commands are issued when the last word of data has been delivered from the core to the
AHB port.
Subsequent WRITE commands are issued after the last WRITE data word of the last
command has been transferred from the AHB bus to the core.
Narrow SINGLE or INCRx transactions
For INCRx transactions with a bytes-per-beat less than the width of the AHB data bus, the
port gathers data from the AHB master until it collects all the data needed to form a
complete data word, or until the completion of the transaction.
The data is then issued to the core as multiples of the complete data word. If the start or end
of a WRITE transaction is not aligned to the data word boundary, the appropriate bytes are
masked off when the data is sent to the core. This provides a significant optimization in the
port, preventing the core's Write Data Queue from filling with a large number of small data
chunks. Performance is also improved significantly by allowing the core to write a complete
word of data in a single burst instead of small sections of the word in several bursts. The
reverse operation is done for INCRx READ transactions. The AHB port issues a READ of
the complete word and then divides the READ data into smaller components depending on
the size specified with the READ request. The alignment of data bytes within the AHB bus
for transaction with a size less than the bus data width depends on the address of the
written or read bytes. The AHB master is responsible for aligning the WRITE data bytes in
the appropriate byte lanes of the AHB bus for these transactions. Similarly, the AHB master
should mask out any data that is not in the appropriate byte lanes for the READ transaction
as don't-care bytes.
Narrow WRAPx or INCR transactions
This optimization is NOT performed for WRAPx transactions with a bytes-per-beat less than
width or INCR transactions of unspecified lengths. Each beat of these kinds of transactions
is issued to the core as a separate transaction, thereby occupying a separate queue entry.
Therefore, these transactions are inefficient and should only be used if necessary.
Data Alignment for Narrow transactions
Examples of the alignment of READ/WRITE data for a 64 bit wide AHB bus with BYTE,
HALFWORD and WORD transactions at different addresses is shown in Table 16 and
Table 17.
Table 16.
62/368
READ/WRITE data alignment - Little Endian
Transaction type
Address
Data alignment - little endian
BYTE
0x0
0x--------------Aa
BYTE
0x1
0x------------Aa--
BYTE
0x2
0x----------Aa----
BYTE
0x3
0x--------Aa------
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
Table 16.
READ/WRITE data alignment - Little Endian (continued)
Transaction type
Address
Data alignment - little endian
BYTE
0x4
0x------Aa--------
BYTE
0x5
0x----Aa----------
BYTE
0x6
0x--Aa------------
BYTE
0x7
0xAa--------------
HALF WORD
0x0
0x------------BbAa
HALF WORD
0x2
0x--------BbAa----
HALF WORD
0x4
0x----BbAa--------
HALF WORD
0x6
0xBbAa------------
WORD
0x0
0x--------DdCcBbAa
WORD
0x4
0xDdCcBbAa--------
Table 17.
READ/WRITE data alignment - Big Endian
Transaction type
Address
Data alignment - big endian
BYTE
0x0
0xAa--------------
BYTE
0x1
0x--Aa------------
BYTE
0x2
0x----Aa----------
BYTE
0x3
0x------Aa--------
BYTE
0x4
0x--------Aa------
BYTE
0x5
0x----------Aa----
BYTE
0x6
0x------------Aa--
BYTE
0x7
0x--------------Aa
HALF WORD
0x0
0xAaBb------------
HALF WORD
0x2
0x----AaBb--------
HALF WORD
0x4
0x--------AaBb----
HALF WORD
0x6
0x------------AaBb
WORD
0x0
0xAaBbCcDd--------
WORD
0x4
0x--------AaBbCcDd
AHB memory controller transaction mapping equations
For AHB ports, a WORD is defined as 32 bits (4 bytes) and is the maximum size supported
for a 32 bit AHB port. Table 18 shows examples of the mapping of various AHB transaction
bursts and sizes to the corresponding core transaction lengths for a 32 bit wide AHB port
interface.
Doc ID 022640 Rev 3
63/368
Multiport DDR controller (MPMC)
Table 18.
RM0319
AHB-Memory controller translation example
AHBx transaction
Burst size
Address
Memory controller transaction
Bytes per beat
Address
Length
Byte, half-word or
word
AHBx Address
1 x (AHBx HSIZE)
INCR4
Byte, half-word or
word
AHBx Address
4 x (AHBx HSIZE)
AHBx
Address
INCR8
Byte, half-word or
word
AHBx Address
8 x (AHBx HSIZE)
AHBx
Address
INCR16
Byte, half-word or
word
AHBx Address
16 x (AHBx HSIZE)
AHBx
HBURST
(AHBx HSIZE)
AHBx
Address
SINGLE
AHBx
Address
WRAP4
Byte, half-word or
(offset n= 0-3) word
Transaction #1:
Transaction#1:
(4 - n) x (AHBx
AHBx Address
HSIZE)
Transaction #2:
Transaction #2:
Wrapped AHBx Address
n x (AHBx HSIZE)
AHBx
Address
WRAP8
Byte, half-word or
(offset n= 0-7) word
Transaction #1:
Transaction#1:
(8 - n) x (AHBx
AHBx Address
HSIZE)
Transaction #2:
Transaction #2:
Wrapped AHBx Address
n x (AHBx HSIZE)
AHBx
Address
WRAP16
(offset n= 015)
Byte, half-word or
word
Transaction #1:
Transaction#1:
(16 - n) x (AHBx
AHBx Address
HSIZE)
Transaction #2:
Transaction #2:
Wrapped AHBx Address
n x (AHBx HSIZE)
AHBx
Address
INCR
(for each
beat)
Byte or half-word
AHBx Address
1 x (AHBx HSIZE)
Word
Transaction 1:
AHBx HADDR
Transaction 2:
AHBx HADDR+blk size
Transaction 3:
2 x (AHBx HADDR+blk
size)(1)
(AHBx read_cnt)
or
(AHBx write_cnt)(2)
AHBx
Address
AHBx
Address
INCR
1. blk size is the value in ahbX_rdnct or abhX_wrcnt.
2. Programmable value
Early burst termination
Unlike the AHB bus protocol, the MPMC core bus protocol does not allow early burst
termination. As a result, the core requires the master to complete the whole READ/WRITE
64/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
transaction of the length specified to the core. The length is a defined quantity that is
specified at the beginning of the transaction. For WRITE transactions, the AHB port
forwards the data from the AHBx HWDATA signals provided by the AHB master to the core.
If the WRITE transaction is early burst-terminated, the port will continue the data stream, but
issue masked WRITE data for the duration of the transaction instead. This allows the whole
transaction to be completed without corrupting data in memory.
For READ transactions, the AHB port returns the expected number of bytes of data to the
AHB master. If a READ transaction is early burst-terminated, the MPMC continues to send
the READ data from the core, but the data is not forwarded back to the AHB master.
Errors
●
Error types
When an illegal operational condition is detected on a new AHB transaction entering the
port (i.e. during a NONSEQ burst), the port responds with an ERROR. The ERROR is a twocycle response as dictated by the AHB protocol. In the first cycle, the ahbX_HREADY signal
is low and in the second cycle, the ahbX_HREADY signal is high. The illegal conditions
which generate this error are:
1.
Transactions with a bytes-per-beat greater than the width of the AHB bus.
2.
The transaction address is not aligned to the size of the transaction. This is a
requirement of the AHB protocol.
●
Error handling
Once a port error is detected in the MPMC core, the following actions occur:
1.
The internal interrupt signal controller_int is asserted.
2.
A bit in the status parameter int_status will be set to 1'b1 to indicate the type of error.
The interrupt is cleared by writing to the interrupt acknowledge parameter int_ack. Setting
1'b1 a bit in the int_ack parameter will trigger the same bit in the int_status parameter to be
cleared to 1'b0. Please refer to Section 6.5 for more information on the interrupt parameters.
6.3.4
Arbiter
From the port interface blocks, commands are presented to the arbiter, which is responsible
for arbitrating between the port requests and sending a single command to the MPMC core.
6.3.5
Write data queue
The WRITE data queue is a WRITE data storage array for transactions. The queue consists
of multiple buffers holding WRITE data for the write requests of a particular port. Write data
is stored in these buffers for commands in the command queue until the command is
processed in the placement logic and needed by the DRAM command arbitration logic. The
buffers can accept data until space is no longer available. The buffers are defined to hold 16
entries.
The size of the WRITE data buffers and the burst length programmed into the memory
devices affect the overall performance of a single port during the WRITE operation. Each
buffer must have a depth of at least twice the number of data words for a memory burst to
ensure that the memory controller can continuously burst WRITE data for a port. The buffer
should also be so large to hold enough words to consume data for a single write transaction
related to the bus. The data may actually be written into the buffers from the bus at a later
time, depending on the priority of the request and the number of transactions in the
Command Queue.
Doc ID 022640 Rev 3
65/368
Multiport DDR controller (MPMC)
6.3.6
RM0319
DRAM command processing
The DRAM command processing logic is used to process the commands in the Command
Queue.
The logic organizes the commands to the memory devices in such a way that data
throughput is maximized. Bank opening and closing cycles are used for data transfers.
The logic uses a variety of factors to determine when to issue bank open and close
commands. The logic reviews the entire Command Queue to look-ahead which banks are to
be accessed in the future. The timing is then set to meet the trc and tras_min timing
parameters of the memory devices, values which were programmed into the MPMC on
initialization. This flexibility allows the MPMC to be tuned to extract the maximum
performance out of memory devices. The parameters that relate to DRAM device protocol
are listed in Chapter “Register Interface”.
6.3.7
Latency
By using the placement logic of the command queue in the core, a new request by any port
can be immediately placed at the top of the command queue or can interrupt an ongoing
request. This scheme allows a high priority request to be processed in the shortest possible
time.
However, since there are many factors that determine the placement into the command
queue, there are also many factors that affect the actual latency of the command. These
factors include:
The coherency status of the transactions already in the command queue: If there is a data
coherency conflict with a transaction already in the command queue, the new transaction
will be placed after the transaction that produced the conflict. The position of the conflicting
transaction determines the latency of the high priority READ or WRITE command.
●
The priority status of the transactions already in the command queue: If the new
command has a higher priority than those already in the command queue, the new
request will be serviced ahead of the lower priority command. As a result, the latency of
the new command will be lower than the latency of the older command.
●
The READ, WRITE, and bank information of the transactions already in the command
queue: In general, READs will be placed ahead of WRITEs when both are of the same
priority level. READ commands are grouped with other READ commands of similar
priorities and WRITE commands are grouped with other WRITE commands of similar
priorities. Among these groupings, transactions with similar bank and different row
destinations are separated as much as possible.
If every placement conditions are met, a new command would be placed at the top of the
command queue. However, if the new command is of a higher priority than the transaction
executing, the current command will be interrupted and the new command will be processed
first. The interruption will occur at a natural burst boundary of the DRAMs. The interrupted
transaction will be placed at the top of the placement queue and it will be recovered after the
new request is completed. The page status of the new transaction determines when the
current transaction is interrupted.
If the page for the new transaction is already open, the current transaction will be interrupted
at the next natural burst boundary of the DRAM device. If the page is not currently open
instead, the new request will be placed at the top of the command queue while its page is
prepared.
66/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
There are a fixed number of latency cycles in the memory controller, based on the pipeline
through the memory controller logic. These steps are:
●
Command passing through the port interface. (fixed)
●
Arbitration through the arbiter. (fixed)
●
Placement into the Command Queue. (fixed)
●
Memory Command Generation. (variable)
●
Sending of control signals from the core logic to flip-flops near the I/O drivers. (fixed)
●
Flight time to the DRAM device. (variable)
●
Flight time from the DRAM device. (variable)
●
For READs, synchronization of READ data from the data strobe domain. (fixed)
●
For READs, data pass through the port interface. (fixed)
For asynchronous AHB interfaces, additional 4-5 cycles are included for the round-trip
transaction to synchronize to the Database core clock. Some typical scenarios for a
multiport AHB interface and their effects on latency are:
●
Read latency with a page hit and empty queue.
●
(9) + Cas Latency
●
Read latency with a page miss to a closed page and an empty queue.
●
Trcd + Cas latency + (9)
●
Read latency with a page miss to an open page and an empty queue.
●
Trp+Trcd+Cas latency+9
●
Read latency with a page hit and a currently executing transaction.
●
TBurst end+Cas Latency+9
●
Read latency with a page miss to a closed bank and a currently executing transaction.
The page open command will be executed while the current burst is completing if
possible.
●
MAX(Trcd, TBurst end)+ Cas Latency + 9
●
Read latency with a page miss to an open page and an empty queue. The page close
command will be executed while the current burst is completing if possible.
●
MAX(Trp+Trcd,TBurst end)+Cas latency+9
TBurst end equals the time to complete the current burst in progress. The maximum value
here is 3 for a READ command and 3 + twr for a WRITE command if the burst count is
configured to 8 for DDR DRAM devices. The minimum value is 0.
6.3.8
Multiport arbiter
The arbiter manages arbitrating requests from the ports and sending requests to the core.
Each transaction received by the arbiter logic has an associated priority, which works with
each port's arbitration logic to determine how ports issue requests to the core. The MPMC
supports the weighted round-robin arbitration scheme.
The arbiter logic routes READ data from the core to the appropriate port. The requesting
port is assumed to be able to receive the data. WRITE data from each port is connected
directly to its own WRITE data interface inside the core, allowing the ports to independently
pass them to the core buffers.
Arbitration overview
Doc ID 022640 Rev 3
67/368
Multiport DDR controller (MPMC)
RM0319
The weighted round-robin arbitration scheme is a three-step arbitration system. All
commands are routed into priority groups based on the priority of the requests. Inside each
priority group, requests are processed according to the “weight” (relative priority) of each
port. Finally, each priority group sends a single command to the priority select module,
which passes the highest priority command on to the memory controller core.
This arbitration scheme also supports two additional features. First, for situations where the
priority (port and relative) for multiple commands are identical, a port ordering system
whereby the user may adjust the order in which the ports are considered is provided.
Beside, for situations where two ports may be linked, a mechanism allowing the pair of ports
to share arbitration bandwidth for a better bandwidth efficiency, is also supplied.
Weighted round-robin arbitration is a complex arbitration scheme. To understand the
operation, each concept must be first understood individually. This will be matter of the
following Sections.
Understanding round-robin operation
Round-robin operation is the simplest form of arbitration and is the best one for systems not
requiring requests to be treated preferentially to maintain bandwidth or minimize latency.
This scheme uses a counter that rotates through the port numbers, incrementing every time
a port request is granted.
If the port that the counter is checking has an active request and the core command queue
is not full, the request will be sent to the core.
If there is not an active request for that port, the port itself will be skipped and the next port
will be checked.
In any case, the counter is incremented one-by-one as any request has been processed,
regardless of which port's request was arbitrated.
Round-robin arbitration guarantees that each port's requests can be successfully arbitrated
into the core every N cycles, where N is the number of ports in the component itself.
No port will ever be locked out, and any port can have its requests processed on every cycle
as long as all other ports are idle and the command queue is not full.
An example of the round-robin scheme is shown in Table 19.
Cycles 0, 2 and 6 show the system behaviour when the command queue is full. Cycle 8
shows the system behaviour when the port addressed by the arbitration counter does not
have an active request.
All other cycles show normal behaviour.
Table 19.
68/368
Round-Robin operation example
Port addressed Port requesting
Cycle by an arbitration
P0
P1
P2
counter
P3
0
0
Y
Y
Y
Y
Yes
None
0
1
0
Y
Y
Y
Y
No
P0
1
2
1
Y
Y
Y
Yes
None
1
3
1
Y
Y
Y
Y
No
P1
2
4
2
Y
Y
Y
No
P2
3
Command Winner of Value of counter
queue full? arbitration at the next cycle
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
Table 19.
Round-Robin operation example
Port addressed Port requesting
Cycle by an arbitration
P0
P1
P2
counter
P3
5
3
Y
Y
6
0
Y
7
0
Y
8
Command Winner of Value of counter
queue full? arbitration at the next cycle
No
P3
0
Y
Yes
None
0
Y
No
P0
1
1
Y
No
P2
2
9
2
Y
Y
No
P2
3
10
3
Y
No
P3
0
Y
Understanding port priority
For AHB ports, the priority is associated with a port and each port has separate priority
parameter for READ and WRITE operations. These values are stored into the
programmable parameters ahbX_r_priority and ahbX_w_priority (where X is the port
number) at startup. Internally, the ports are organized into priority groups based on their
priority setting.
The priority value is also used by the placement logic inside the core when filling the
command queue, with “0” meaning highest priority and “7” as lowest priority.
Even if the user is allowed to set a “0” priority level, it would be better to avoid this specific
value so the placement queue can reach this level by aging.
Understanding relative priority
Inside each priority group, the relative priority is used to set arbitration. The MPMC contains
8 identical priority groups with control logic selecting among the requests from all ports at
that given priority level. The relative priority parameters ahbX_priorityY_relative_priority
(where X being the port number and Y the priority group) “weight” the ports for each level
and determine how the priority group will be arbitrated.
Figure 18 shows this type of arbitration system.
Doc ID 022640 Rev 3
69/368
Multiport DDR controller (MPMC)
RM0319
Figure 18. Weighted round-robin priority group structure
Ports
0-X
Priority Sorting
Priority 1
Commands
Priority 2
Commands
Priority Z
Commands
Priority Group 1
ahb0_priority1_relative_priority
…
ahbX_priority1_relative_priority
Priority Group 2
ahb0_priority2_relative_priority
…
ahbX_priority2_relative_priority
Command Queue of the Databahn Core
Commands
Priority Select Module
Priority 0
Priority Group 0
ahb0_priority0_relative_priority
ahb1_priority0_relative_priority
ahb2_priority0_relative_priority
…
abhX_priority0_relative_priority
Priority Group Z
ahb0_priorityZ_relative_priority
…
ahbX_priorityZ_relative_priority
Programmable Register Settings
Using relative priority concept, the arbitration is skewed in favor of certain ports following
user setting.
Note:
The relative priority parameters have a minimum acceptable value of 1 to prevent port
lockout: A 0 value triggers an error condition.
If the relative priorities are all programmed to the same value within any priority group, the
arbitration will mimic a version of simple round-robin scheme within that specific priority
group. Instead of incrementing as any request is processed, the simple round-robin counter
will only increment to the next port after the ahbX_priorityY_relative_priority number of
requests are processed.
To each port X owning priority level Y, it will be allocated resources corresponding to the
ratio of that port's relative priority (ahbX_priorityY_relative_priority) to the sum of all
requesting port's relative priority values. If a particular port is not requesting, it will be not
included in the sum calculation, i.e. the arbitration will be proportionately split among the
requesting ports.
For instance, let us consider a system with 4 ports where all requests have priority 0. This
system is described in Table 20.
70/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
Table 20.
Relative priority example
Parameter
System A
ahb0_priority0_relative_priority
1
ahb1_priority0_relative_priority
2
ahb2_priority0_relative_priority
3
ahb3_priority0_relative_priority
4
For this system, port 0 will be processed 1/(1+2+3+4) = 1/10 of the time and Port 3 will be
processed 4/ (1+2+3+4) = 4/10 of the time. However, if Port 2 is not actively requesting, then
port 0 will be processed 1/(1+2+4) = 1/7 of the time and port 3 will be processed 4/(1+2+4)
= 4/7 of the time.
In order to warrant that relative priorities are maintained, there is a weight counter for each
port within each priority group. These counters track the number of transactions accepted
for that port in that priority group. When any counter value reaches the programmed relative
port priority, the scan order for that priority group will be internally modified. The port
matching its relative priority will be dynamically positioned to the bottom of the scan order
and its counter reset, allowing other ports to get a preferential position.
For ports that are not expected to issue requests at a given priority level, the associated
relative priority parameter should be programmed to 0x1. This allows to minimum allocation
avoiding the risk of lock out in case a command appears.
Understanding port ordering
With simple round-robin arbitration, the ports are scanned following their port number in
incrementing order inside the system. Assuming that the command queue is not full, the
port referenced by the counter is examined for valid incoming transactions. If there is an
active request, it will be accepted. Otherwise, the next port in the scan order will be checked.
For memory controller performing weighted round-robin arbitration, the user can sort the
order in which the ports are scanned. This is a useful feature either requests from some
ports are more critical or specific order could reduce contention among ports.
The three bit ahbX_port_ordering parameters are used to set this new scan order. A value
of 3'b000 sets the highest listing in the scan order as a value of 3'b111 is the lowest as well.
If the 5 ahbX_port_ordering parameters are set with unique values, the scan order will be
modified to proceed sequentially following this new order.
If any of the port ordering parameters have the same value, those ports will still be equal in
the arbitration test. In this case, the port number will select between these ports, with the
lower-numbered port automatically being selected first.
For instance, let us consider a system with 8 ports and two port orders as shown in
Table 21.
For System B, the port ordering parameters contain different values, so the resulting order is
entirely based on the values of the parameters.
For System C, three ports have the same value set as port order. For these three ports, the
port number settles the order. Remaining ports follow the port ordering parameters.
Doc ID 022640 Rev 3
71/368
Multiport DDR controller (MPMC)
Table 21.
RM0319
Port ordering example
Parameter
System B
System C
ahb0_port_ordering
3
3
ahb1_port_ordering
4
0
ahb2_port_ordering
5
5
ahb3_port_ordering
6
6
ahb4_port_ordering
7
7
ahb5_port_ordering
0
1
ahb6_port_ordering
2
0
ahb7_port_ordering
1
0
Port Scan Order
P5-P7-P6-P0-P1-P2-P3-P4
P1-P6-P7-P5-P0-P2-P3-P4
If every port ordering parameters are set to the same value, the scan order will default to the
numbered port order.
Weighted round-robin arbitration summary
The MPMC weighted round-robin arbitration system merges the concepts of round-robin
operation, priority, relative priority and port ordering. The incoming commands are
separated into priority groups based on the priority of the associated port for that type of
command. Inside each priority group, the relative priority values are examined to settle the
arbitration winner. If relative priority values are the same and no individual command can be
selected, the scan order is used to select among the requests.
Finally the highest priority command incoming from the highest relative priority port, having
the highest location in the scan order, will be selected and sent to the core.
For instance, let us consider the system described in Table 22. The counters refer to the
ones inside each port priority group to guarantee that relative priorities are maintained. To
simplify, on assumes the command queue never be full and commands are only received at
priority level 0.
Table 22.
System D specifications
Parameter
Port 0
Port 1
Port 2
Port 3
ahbX_priority0_relative_priority
4
3
2
1
ahbX_port_ordering
0
1
2
3
The behaviour is shown inTable 23. The highest requesting port in the scan order always
wins arbitration and the scan order is dynamically modified whenever any port counter
reaches its allocated relative priority value.
Note:
72/368
If the command queue was considered, cycles where the command queue was full would
not have any arbitration winner and therefore the counter values and scan order would not
change on that cycle.
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
Table 23.
System D operation
Ports requesting
Cycle
P0
P1
P2
P3
Arbitration
winner
Next counter
Next scan order
P0
P1
P2
P3
P0-P1-P2-P3
0
Y
Y
Y
P0
1
0
0
0
P0-P1-P2-P3
1
Y
Y
Y
P0
2
0
0
0
P0-P1-P2-P3
2
Y
Y
Y
Y
P0
3
0
0
0
P0-P1-P2-P3
3
Y
Y
Y
Y
P0
4
0
0
0
P1-P2-P3-P0
4
Y
Y
Y
Y
P1
0
1
0
0
P1-P2-P3-P0
5
Y
Y
Y
Y
P1
0
2
0
0
P1-P2-P3-P0
6
Y
Y
Y
Y
P1
0
3
0
0
P2-P3-P0-P1
7
Y
Y
Y
P2
0
0
1
0
P2-P3-P0-P1
8
Y
Y
Y
P2
0
0
2
0
P3-P0-P1-P2
9
Y
Y
P3
0
0
0
1
P0-P1-P2-P3
10
Y
Y
Y
P0
1
0
0
0
P0-P1-P2-P3
11
Y
Y
P2
1
0
1
0
P0-P1-P2-P3
12
Y
Y
P2
1
0
2
0
P0-P1-P3-P2
If the same system also contains two ports that only can request at priority level 1, the
system behavior will be slightly altered. Adding these 2 ports leads to the second priority
group structure increasing the arbitration depth. Table 24 describes this system. The text in
bold-italic (grey background) highlights the priority level changes for P4 and P5.
Table 24.
System E specifications
Parameter
Port 0
Port 1
Port 2
Port 3
Port 4
Port 5
ahbX_priority0_relative_priority
4
3
2
1
1
1
ahbX_priority1_relative_priority
1
1
1
1
3
2
ahbX_port_ordering
0
1
2
3
4
5
To simplify, the command queue is again considered to never be full and it is assumed that
commands from ports 0, 1, 2 and 3 are only received at priority level 0. The behavior is
shown in Table 25.
Note:
If any priority 0 port (P0, P1, P2, P3) is requesting, the system will behave as one only
priority group is acting as shown in Table 23. Ports 4 and 5 can only win arbitration when no
higher-priority commands exist.
Doc ID 022640 Rev 3
73/368
Multiport DDR controller (MPMC)
Table 25.
RM0319
System E operation
Port Requesting
Cycle
P0 P1 P2 P3 P4 P5
Arbitration
Winner
Next Counter
Next Scan Order
P0 P1 P2 P3 P4 P5
Priority 0: P0-P1-P2-P3
Priority 1: P4-P5
0
1
Y
2
3
Y
Y
Y
P2
0
0
1
0
0
0
P0-P1-P2-P3-P4-P5
Y
Y
P0
1
0
1
0
0
0
P0-P1-P2-P3-P4-P5
Y
Y
P2
1
0
2
0
0
0
P0-P1-P3-P2-P4-P5
Y
Y
Y
P0
2
0
0
0
0
0
P0-P1-P3-P2-P4-P5
Y
Y
Y
P2
2
0
1
0
0
0
P0-P1-P3-P2-P4-P5
Y
Y
P4
2
0
1
0
1
0
P0-P1-P3-P2-P4-P5
Y
Y
P1
2
1
1
0
1
0
P0-P1-P3-P2-P4-P5
7
Y
Y
P4
2
1
1
0
2
0
P0-P1-P3-P2-P4-P5
8
Y
Y
P4
2
1
1
0
3
0
P0-P1-P3-P2-P5-P4
9
Y
Y
P5
2
1
1
0
0
1
P0-P1-P3-P2-P5-P4
10
Y
P4
2
0
1
0
1
1
P0-P1-P3-P2-P5-P4
4
5
6
Y
Priority relaxing
With reference to Table 25, it is evident that ports at lower priority levels will not win
arbitration in weighted round-robin arbitration unless there are no higher priority requests.
This could mean that, in a situation where high priority requests are being received
continuously, lower priority requests could be locked out indefinitely. To avoid this scenario
and control the arbitration latency for lower-priority ports, it is possible to disable priority
groups temporarily. This is known as priority relaxing, and it is a time-controlled function.
Each higher priority group will be temporarily disabled when the pre-set counter value for the
lower priority group has been reached and a request is waiting. The ahbX_priority_relax
parameters set the counter value for port X at which the priority relax condition will be
triggered.
The timing counters inside each port are controlled by the
weighted_round_robin_latency_control parameter. When the latency control bit is set to
1'b1, the timing counters are free-running. Any timing counter may hit its
ahbX_priority_relax value at any point. Whenever this happens, higher-priority groups are
disabled to allow a waiting request for this port to be processed. This brings a random
latency for each port, but the maximum latency is fixed at the ahbX_priority_relax value.
If the current port does not have any commands waiting when the timing counter hits the
relax value, the counter will be reset and the arbiter will works normally.
When the weighted_round_robin_latency_control parameter is cleared to 1'b0, the timing
counters only count while that port has a waiting request that is not being processed. In this
case, when the port's ahbX_priority_relax parameter value is reached, all priority groups at
priority levels higher than the waiting request are disabled. This port's command is granted
arbitration and is moved through to the core. Since the priority relax parameters and
counters are associated with individual ports, it is possible that multiple priority relax
counters could reach their specified value simultaneously. In this case, the lower priority
74/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
command will be arbitrated first and the higher priority command afterward. This situation
could modify the arbitration latency slightly, causing it to be longer than the expected value
in the priority relax parameter.
Consider the System F as described in Table 26. The same conditions apply as for the
previous example. The command queue is considered to never be full, commands from
ports 0, 1, 2 and 3 are only received at priority level 0, and commands from ports 4 and 5
are only received at priority 1.
Table 26.
System F specifications
Parameter
Port 0
Port 1
Port 2
Port 3
Port 4
Port 5
ahbX_priority0_relative_priority
4
3
2
1
1
1
ahbX_priority1_relative_priority
1
1
1
1
2
1
ahbX_port_ordering
0
1
2
3
5
4
Table 27 shows the system behavior. The exact settings of the latency control and priority
relax parameters are not displayed. Relaxed Ports column indicates instead which ports, if
any, have hit their priority relax values. The following cycles are important to observe:
●
Cycles 1 and 7: A port relaxes while a higher priority request and a higher scan order
request are both present. The relaxed port still wins arbitration.
●
Cycle 4: Two ports of the same priority relax. The higher scan order request wins
arbitration.
●
Cycle 5: Two ports of different priorities relax. The lower priority port that relaxed wins
arbitration. The higher priority port that relaxed will maintain its relax condition, and win
arbitration in the next cycle.
Table 27.
System F operation with priority relaxing
Ports Requesting
Cycle
P
0
P
1
P
2
P
3
P
4
P
5
Next Counter
Relaxed Arbitration
P P P P P
Ports
Winner
0 1 2 3 4
P
5
Next Scan Order
Priority 0: P0-P1-P2P3
Priority 1: P5-P4
0
Y
Y
Y
P2
0
0
1
0
0
0
P0-P1-P2-P3
P5-P4
1
Y
Y
Y P5
P5
0
0
1
0
0
1
P0-P1-P2-P3
P5-P4
2
Y
Y
Y
P2
0
0
2
0
0
0
P0-P1-P3-P2
P4-P5
Y
Y
P1
0
1
0
0
0
0
P0-P1-P3-P2
P4-P5
3
Y
4
Y
Y
Y P4, P5
P4
0
1
0
0
1
0
P0-P1-P3-P2
P4-P5
5
Y
Y
Y P0, P5
P5
0
1
0
0
1
1
P0-P1-P3-P2
P4-P5
Doc ID 022640 Rev 3
75/368
Multiport DDR controller (MPMC)
Table 27.
RM0319
System F operation with priority relaxing (continued)
Ports Requesting
Cycle
P
0
P
1
P
2
P
3
P
4
P
5
Next Counter
Relaxed Arbitration
P P P P P
Ports
Winner
0 1 2 3 4
P
5
Next Scan Order
6
Y
Y
P0
P0
1
1
0
0
1
0
P0-P1-P3-P2
P4-P5
7
Y
Y
Y P4
P4
1
1
0
0
2
0
P0-P1-P3-P2
P5-P4
8
Y
Y
P0
2
1
0
0
0
0
P0-P1-P3-P2
P5-P4
Y
Y
9
Y
Y
Y
Y
P1
2
2
0
0
0
0
P0-P1-P3-P2
P5-P4
10
Y
Y
Y
Y P2
P2
2
2
1
0
0
0
P0-P1-P3-P2
P5-P4
Priority relaxing allows low priority commands to be able to move through the arbiter to the
core. This will ensure that the system can meet maximum latency requirements.
Port pairing
The memory controller arbiter embeds a feature which allows adjacent ports to be grouped
together and considered jointly for arbitration. The weighted_round_robin_weight_sharing
parameter controls this function, with one bit per pair of ports in the memory controller. Bit 0
handles ports 0 and 1, Bit 1 handles ports 2 and 3 and so on. Where memory controller
interfaces to an odd number of ports, the highest numbered port is excluded from the port
pairing system.
Since the ports are grouped together, their relative priorities are not considered separately.
Referring to Section , the general formula for port priority allocation is the ratio of that port's
relative priority (ahbX_priorityY_relative_priority) to the sum of all requesting port's relative
priority values. In this case, the relative priority value of only one of the paired ports is used
for the sum calculation. This means that the bandwidth will be divided differently among the
ports.
Let us consider the port pair at the top of the scan order: if one only port is requesting it will
win arbitration. If both are requesting, port ordering is used to determine which port wins
arbitration.
When the ports are paired, their scan order can never be altered and they will always remain
together in the scan order. Their counters increment together, so when they reach their
relative priority value, the port pair will dynamically be placed at the bottom of the scan order
for that priority group.
In order for port weight sharing to be used, the relative priority parameters for the port pair
must be programmed to the same value and the port order of the paired ports should be
sequential. If either condition is not followed, an error bit will be set to1'b1.
Let us consider System G as described inTable 28. Again, to simplify the command queue is
considered to never be full, commands from ports 0, 1, 2 and 3 are only received at priority
level 0 and commands from ports 4 and 5 are always at priority 1.
However, now ports P0 - P1, and ports P4 - P5 are paired.
76/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
Table 28.
System G specifications
Parameter
Port 0
Port 1
Port 2
Port 3
Port 4
Port 5
ahbX_priority0_relative_priority
3
3
2
2
1
1
ahbX_priority1_relative_priority
1
1
1
1
2
2
ahbX_port_ordering
0
1
2
3
5
4
weighted_round_robin_weight_sharing
1 (Paired)
0 (Not Paired)
1 (Paired)
Table 29 shows the system behavior with port pairing. Since ports P4 - P5 are still at a lower
priority, they will be ignored unless none of the higher priority ports (i.e. P0, P1, P2 or P3)
are requesting. Note the following points:
Note:
●
When either port of a port pair wins arbitration, the counters for both ports of the pair
increment.
●
In Cycle 3, the port pair P0/P1 reaches its allocated relative priority.
The port pair dynamically moves to the bottom of the scan order.
●
In Cycle 8, the port pair P4/P5 reaches its allocated relative priority. However, since
these are the only requests at priority 1, the scan order does not change.
Table 29.
System G operation
Ports Requesting
Cycle
P0 P1 P2 P3 P4 P5
Arbitration
Winner
Next Counter
Next Scan Order
P0 P1 P2 P3 P4 P5
Priority 0: P0-P1-P2-P3
Priority 1: P4-P5
0
1
Y
P0
1
1
0
0
0
0
P0-P1-P2-P3
P5-P4
Y
Y P0
2
2
0
0
0
0
P0-P1-P2-P3
P5-P4
Y
Y P2
2
2
1
0
0
0
P0-P1-P2-P3
P5-P4
Y
Y
2
Y
Y
Y P0
3
3
1
0
0
0
P2-P3-P0-P1
P5-P4
4
Y
Y
Y P3
0
0
1
1
0
0
P2-P3-P0-P1
P5-P4
5
Y
Y
Y P3
0
0
1
2
0
0
P2-P0-P1-P3
P5-P4
6
Y
Y P1
1
1
1
0
0
0
P2-P0-P1-P3
P5-P4
Y P5
1
1
1
0
1
1
P2-P0-P1-P3
P5-P4
P4
1
1
1
0
2
2
P2-P0-P1-P3
P5-P4
3
Y
7
8
Y
Doc ID 022640 Rev 3
77/368
Multiport DDR controller (MPMC)
Table 29.
RM0319
System G operation (continued)
Ports Requesting
Cycle
P0 P1 P2 P3 P4 P5
9
10
Y
11
Y
Y
Arbitration
Winner
Next Counter
Next Scan Order
P0 P1 P2 P3 P4 P5
Y
Y P5
1
1
1
0
1
1
P2-P0-P1-P3
P5-P4
Y
Y P2
1
1
2
0
1
1
P0-P1-P3-P2
P5-P4
Y
Y P1
2
2
0
0
1
1
P0-P1-P3-P2
P5-P4
Error conditions
Because of the programming difficulties of the weighted round-robin arbitration scheme, an
error reporting mechanism is included to notify users of illegal programming scenarios.
These error conditions generate a MPMC core interrupt and set a bit in the
wrr_param_value_err parameter to 1'b1. The potential error conditions are:
●
Bit 0 = The 5 ahbX_port_ordering parameters do not contain unique values.
●
Bit 1 = Any of the ahbX_priorityY_relative_priority parameters have been set to 10
value. A 0 value leads to unknown behavior. The minimum accepted value is 1.
●
Bit 2 = Any port, whose related bit of the weighted_round_robin_weight_sharing
parameter is set to 1'b1, do not have the same values in its
ahbX_priorityY_relative_priority parameter.
●
Bit 3 = For ports whose related bit of the weighted_round_robin_weight_sharing
parameter is set to 1'b1, the values of the ahbX_port_ordering parameters are not
sequential.
If bits 0, 2 or 3 are set to 1'b1 in the wrr_param_value_err parameter, and any of the ports
are paired in the weighted_round_robin_weight_sharing parameter, all weight sharing data
will be ignored during MPMC initialization and the ports will be prioritized by port number. If
port pairing is not being used, but the bit 0 error condition is set to 1'b1, then ports with a
non-unique port ordering are prioritized by port number.
Note:
The user is strongly cautioned against modifying the values of the port ordering or relative
priority parameters during active port usage.
Command queue with placement logic
From the arbiter, commands are routed to the command queue of the core. The command
queue is fed using a placement algorithm. For more information on this algorithm, refer to
below Chapter “Core Command Queue with Placement Logic”.
Core command queue with placement logic
The MPMC core contains a command queue that accepts commands from the arbiter. This
command queue uses a placement algorithm to determine the order in which commands
will be executed in the core. The placement logic follows many rules to determine where
new commands should be inserted into the queue, relative to the contents of the command
queue at the time.
Placement is determined by considering address collisions, source collisions, data
collisions, command types and priorities. In addition, the placement logic attempts to
78/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
maximize efficiency of the core through command grouping and bank splitting. Once placed
into the command queue, the relative order of commands is constant.
Many of the rules used in placement may be individually enabled/disabled. In addition, the
queue may be programmed by the placement_en parameter to disable the placement logic
entirely, resulting in an in-line queue that attends requests in the order they are received. If
the placement_en parameter is cleared to 1'b0, the placement algorithm will be ignored.
Rules of the placement algorithm
The factors affecting command placement together work to identify where a new command
fits into the execution order. They are listed in order of importance.
●
Address collision/Data coherency violation
The order in which READ and WRITE commands are processed inside MPMC is critical to
proper system behavior. While READs and WRITEs to different addresses are independent
and may be re-ordered without affecting system performance, READs and WRITEs that
access the same address are significantly related. If the port requests a READ after a
WRITE to the same address, then repositioning the READ before the WRITE would return
the original data, not the changed data. Similarly, if the READ was requested ahead of the
WRITE but accidentally positioned after the WRITE, the READ would return the new data,
not the original data prior to being overwritten. These are significant data coherency
mistakes.
To avoid address collisions, READs or WRITEs that access the same chip select, bank and
row as a command already in the command queue will be inserted into the command queue
after the original command, even if the new command is of a higher priority.
This factor may be enabled/disabled through the addr_cmp_en parameter and should only
be disabled if the system can guarantee coherency of READs and WRITEs.
●
Source ID collision
Each port is assigned a specific source ID that identifies the source uniquely. This allows the
memory controller to map data from/to the correct source/destination.
Note:
A source ID does contain port identification information which means that the rules for
placement are dependent on the requesting port. There will not be source ID collisions
between ports.
In general, commands of the same type from the same source ID will be placed in the
command queue in order. Therefore, a READ/WRITE command with the same source ID of
a READ/WRITE command being already in the command queue will be processed
afterward.
The behavior of commands of different types from the same source ID is dependent on the
user configuration. For MPMC, the placement of new READ/WRITE commands that collide
in terms of source ID with existing entries in the command queue will only depend on other
commands of the same type, not on different types. This means that, if there are no address
conflicts, a READ command could be executed ahead of a WRITE command with the same
source ID, as a WRITE command could be executed ahead of a READ command with the
same source ID as well.
This feature is always enabled.
●
Write buffer collision
Incoming WRITE requests in the command queue are allocated to one of the 8 WRITE
buffers of the core automatically based on availability. New WRITE commands will be
Doc ID 022640 Rev 3
79/368
Multiport DDR controller (MPMC)
RM0319
designated to any available buffer. However, back-to-back write requests from a particular
source ID will be allocated to the same WRITE buffer as the previous command.
Since the core must pull data out of the buffers in the order it was stored, if a WRITE
command is linked to a buffer associated with another command in the queue, the new
command will be placed in the command queue after that command, regardless of priority.
This feature is always enabled.
●
Priority
Priorities are used to distinguish important commands from less important commands. Each
command is given a priority based on the command type through the programmable
parameters ahbX_r_priority and ahbX_w_priority (X is the x-th port), where '0' value is the
highest priority and '7' is the lowest.
The placement algorithm will attempt to place higher priority commands ahead lower priority
commands, as long as they have no source ID, WRITE buffer or address collisions.
Higher priority commands will be placed lower in the command queue in case:
●
They access the same address and
●
They are from the same requestor or
●
They use the same buffer used by lower priority commands being in the command
queue already.
This feature is enabled through the priorities parameter.
●
Bank splitting
Before accesses to two different rows within the same bank could be performed, first active
row must be closed (pre-charged) and the new row must be opened (activated). Therefore,
the both activities require some timing overhead for optimization, the placement queue will
attempt to insert the new command into the command queue such that commands to other
banks may execute during this timing overhead.
Still the placement of the new commands will follow priority, source ID, WRITE buffer and
address collision rules. The placement logic will also attempt to optimize the core, by
inserting a command to the same bank of any existing command in the command queue,
immediately after the original command. This reduces the overall timing overhead by
potentially eliminating one pre-charge/activate cycle. This placement will only be possible if
there are no priority, source ID, WRITE buffer or address collisions or conflicts with other
commands in the command queue.
Every bank splitting feature could be enabled through the bank_split_en parameter.
●
Read/Write grouping
The memory suffers a small timing overhead when switching from READ to WRITE mode.
For efficiency, the placement queue will attempt to place a new read command sequentially
with other read commands in the command queue, or a new WRITE command sequentially
with other WRITE commands in the command queue. Grouping will only be possible if no
priority, source ID, WRITE buffer or address collision rules are violated.
This feature is enabled through the rw_same_en parameter.
Command execution order after placement
Once a command has been placed in the command queue, its order relative to the other
commands in the queue at that time is fixed. Even if this simplifies the algorithm there are
80/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
some drawbacks. For this reason, MPMC offers two options that affect commands once they
have been placed in the command queue.
High-Priority command swapping
Commands are assigned priority values to ensure that critical commands are executed
before less important commands. Therefore, it is desirable that high-priority commands
cross the core as sooner as possible. The placement algorithm sorts commands by priority
though it cannot avoid a scenario such as a high-priority command waiting at the top of the
command queue while another command, possibly of a lower priority, is in process.
The high-priority command swapping feature allows this new high-priority command to be
executed quite sooner. If the user has enabled the swapping function by the swap_en
parameter, the entry at the top of the command queue will be compared with the current
command in progress. If the command queue's top entry is of a higher priority (not the same
priority), and it does not have an address, source ID or WRITE buffer conflict with the
current command being executed, the original command will be interrupted.
If the command has to be interrupted, it will be halted after completing the current burst,
stacked and placed at the top of the queue, while the new command will be executed. As
long as the command queue is not full, new commands may continue to be inserted into the
command queue based on the placement rules, even at the head of the queue ahead of the
interrupted command. The top entry in the command queue will be executed next.
Whenever the interrupted command is resumed, it will start from the point at which it was
interrupted.
Note:
Priority 0 commands could never be interrupted, so the user should set any commands that
should not be interrupted to priority 0.
Command ageing
Since commands can be inserted ahead of existing commands in the command queue, it
could happen a low priority command remains at the bottom of the queue indefinitely. To
avoid such a lockout condition, aging counters have been included in the placement logic
that measure the number of cycles that each command has been waiting. If command aging
is enabled through the active_ageing parameter and an aging counter hits its maximum, the
priority of the associated command will be decremented by one (lower priority commands
are executed first). This increases the likelihood that this command will move to the top of
the command queue and be executed.
Note:
This command does not move relative positions in the command queue when it ages; the
new priority will be considered when placing new commands into the command queue.
Aging is controlled by a master aging-rate counter and command aging counters associated
with each command in the command queue. The age_count and command_age_count
parameters hold the initial values for each of these counters, respectively. When the master
counter counts down the age_count value, a signal is sent to the command aging counters
to decrement. When the command aging counters have completely decremented, the
priority of the associated command is decremented by one and the counter is reset.
Therefore, a command does not age by a priority level until the total elapsed cycles has
reached the product of the age_count and command_age_count values. The maximum
number of cycles that any command can wait in the command queue until reaching the top
priority level is the product of the age_count value, the command_age_count value, and the
number of priority levels in the system.
Doc ID 022640 Rev 3
81/368
Multiport DDR controller (MPMC)
6.4
RM0319
Operation
In many applications, it is highly desirable to minimize power consumption. The MPMC
provides various user configurable low power options to manage power savings. In addition,
a partial-array self-refresh option is included for mobile memory devices.
6.4.1
Low power modes
Five low power modes are available in the memory controller. The low power modes are
listed from least to most power saving.
Note:
It is not possible to exit one low power mode and enter another low power mode
simultaneously. The user should plan for a minimum delay between exit and entry between
the two low power modes of 15 cycles in which the MPMC must remain stable.
1.
Memory Power-Down
The memory controller sets the memory devices into power-down which reduces the
overall power consumption of the system. This is the low power modes having the least
effect: The memory controller and memory clocks are fully operational, but the CKE
input bit toward the memory devices is de-asserted.
The memory controller will continue to monitor memory refresh needs and will
automatically bring the memory out of power-down to perform these refreshes.
Whenever a refresh is required, the CKE bit will be turned enabled. This action drives
memory devices out power-down. Once the refresh has been completed, the memory
devices will be returned to power-down by de-asserting the CKE input bit.
2.
Memory Power-Down with Memory Clock Gating
The memory controller sets the memory devices into power-down and gates off the
clock to the memory devices. Refresh operations will be handled as seen above for the
Memory Power-Down mode (Mode 1), but the gating on the memory clock will be now
removed before asserting the CKE pin. After the refresh has been completed, the
memory devices will be returned to power-down with the clock gated. Before the
memory devices are removed from power-down, the clock will be gated on again.
Although this mode is supported in both mobile and non-mobile memory devices, clock
gating while in power-down is only allowed for mobile memory devices. Therefore, the
MPMC will only attempt to gate the clock if it is configured for mobile device operation.
For non-mobile memory devices in this low power mode, the MPMC will operate
identically to the Memory Power-Down mode without the clock gating (Mode 1).
3.
Memory Self-Refresh
The MPMC sets the memory devices into self-refresh. In this mode, the MPMC and
memory clocks are fully operational and the CKE input bit to the memory devices is deasserted. Since the memory automatically refreshes its contents, the MPMC does not
need to send explicit refreshes to the memory.
4.
Memory Self-Refresh with Memory Clock Gating
The MPMC sets the memory devices into self-refresh and gates off the clock to the
memory devices. Before the memory devices are removed from self-refresh, the clock
will be gated on again.
5.
Memory Self-Refresh with Memory and Controller Clock Gating
This is the most effective low power mode of the memory controller: The memory
controller sets the memory devices self-refreshing and gates off the clock toward them.
In addition, the clock toward the MPMC and the programming parameters will be gated
off, except to a small portion of the DLL, which must remain active to maintain the lock.
82/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
Before the memory devices are removed from self-refresh, the MPMC and memory
clocks will be gated on.
6.4.2
Low power mode control
The memory controller may enter and exit the various low power modes in the following
ways:
●
Automatic Entry: When the memory controller is idle, 4 different timing counters begin
counting the cycles of inactivity. If any of the counters expires, the memory controller
enters the low power mode associated with that counter.
●
Manual Entry: The user may set any low power mode by setting the bit of the
lowpower_control parameter associated with the desired mode. The memory controller
will enter the selected low power mode when it is has completed its current burst.
Automatic and Manual entry methods are both controlled by two parameters:
lowpower_control and lowpower_auto_enable. The lowpower_control parameter contains
individual enable/disable bits for each low power mode, and the lowpower_auto_enable
parameter controls whether each mode will be entered automatically or manually.
Automatic entry
Automatic Entry will occur as all the following conditions are matched:
●
The mode is programmed for automatic entry by setting the relevant bit in the
lowpower_auto_enable parameter to 1'b1.
●
The particular mode is enabled in the lowpower_control parameter.
●
The memory controller is idle.
●
The counter associated with this mode expires.
There are 4 counters to full cover the 5 low power modes. There are separate counters for
each of the three memory self-refresh low power modes (Modes 3, 4 and 5). Memory
Power-Down mode (Mode 1) and Memory Power-Down with Memory Clock Gating mode
(Mode 2) share the same counter.
The counters determine the number of idle cycles before entering into the associated low
power mode. Every counter is re-initialized each time there is a new READ or WRITE
transaction entering or executing in the memory controller. This guarantees that the MPMC
will not enter any of the low power modes when active.
Each low power mode can be entered through automatic entry, and will be exited
automatically whenever any of the following conditions occur:
Note:
●
A new READ or WRITE transaction appears at the MPMC interface.
●
The MPMC must refresh the memory when in either of the power-down modes (Modes
1 or 2). After completing the memory refresh, the MPMC re-enters power-down.
●
The counter for a deeper low power mode expires. The MPMC must exit the current low
power mode in order to enter the deeper low power mode. A minimum of 15 cycles
occur between exit from one low power mode before entering into the next low power
mode, even if the counters expire within 15 cycles of each other.
The memory controller will not enter a less deep low power mode, regardless of which
counter expires.
Doc ID 022640 Rev 3
83/368
Multiport DDR controller (MPMC)
RM0319
Manual “On-Demand” entry
Manual Entry occurs when the 2 following conditions are matched:
●
The mode is programmed for manual entry by clearing the relevant bit in the
lowpower_auto_enable parameter to 1'b0.
●
The particular mode is set to 1'b1 in the lowpower_control parameter.
For manual entry, the lowpower_control parameter triggers the entry into the low power
modes. The MPMC does not need to be idle when the low power mode bit is enabled. When
a particular mode that is programmed for manual entry is enabled, the MPMC will complete
the current memory burst access, and then, regardless of the activity inside the MPMC or at
the memory interface, it will enter the selected low power mode.
If any new transaction would involve the MPMC while it is in any of the low power modes, the
transaction itself will be stacked inside the MPMC's command queue until the queue is
completely full.
The way to exit from a manually-entered low power mode is manual too. Clearing the
lowpower_control parameter bits to 1'b0 will trigger the memory controller to pull the
memory devices out of powerdown or self-refresh, and command processing will resume.
Note:
In the deepest low power mode (Mode 5), the clock toward the programming registers
module is gated off. However, manual low power mode exit requires the user to clear the
lowpower_control parameter to 1'b0, which is not possible when the clock is off. As a result,
the user should not manually activate the deepest low power mode. If Memory Self-Refresh
with Memory and Controller Clock Gating Mode (Mode 5) was entered manually, the device
would not be able to be brought out of low power mode again.
If a different lowpower_control bit is set to 1'b1 while in one of the low power modes, or on
clearing of the original bit to 1'b0, the memory controller will exit the current low power
mode. There will be at least a 15 cycle delay before the component being either fully
operational or enters the new low power mode.
6.4.3
Low power control programming
The low power modes of the memory controller are controlled by the lowpower_control and
lowpower_auto_enable parameters. These 5-bit parameters contain each one bit to control
each low power mode. The lowpower_control parameter enables the associated low power
mode, and the lowpower_auto_enable parameter sets the entry method into that mode as
manual or automatic. Table 30 displays the relationship between the 5 bits of the
lowpower_control and lowpower_auto_enable parameters and the various low power
modes.
Table 30.
84/368
Low power mode parameters
Low Power Mode
Enable
Memory Power-Down (Mode 1)
lowpower_auto_enable [4]:
lowpower_control [4] =1'b1 1'b0 = Manual
1'b1 = Automatic
Memory Power-Down with Memory
Clock Gating (Mode 2)
lowpower_auto_enable [3]:
lowpower_control [3] =1'b1 1'b0 = Manual
1'b1 = Automatic
Doc ID 022640 Rev 3
Entry
RM0319
Multiport DDR controller (MPMC)
Table 30.
Low power mode parameters (continued)
Low Power Mode
Enable
Entry
Memory Self-Refresh (Mode 3)
lowpower_auto_enable [2]:
lowpower_control [2] =1'b1 1'b0 = Manual
1'b1 = Automatic
lowpower_auto_enable [1]:
Memory Self-Refresh with Memory Clock
lowpower_control [1] =1'b1 1'b0 = Manual
Gating (Mode 4)
1'b1 = Automatic
Memory Self-Refresh with Memory and
Controller Clock Gating (Mode 5)
lowpower_auto_enable [0]:
lowpower_control [0] =1'b1 1'b0 = Manual
1'b1 = Automatic
When a lowpower_control parameter bit is set to 1'b1 by the user, the memory controller
checks the lowpower_auto_enable parameter.
●
If the associated bit in the lowpower_auto_enable parameter is set to 1'b1, the memory
controller will watch the associated counter for expiration and then enter that low power
mode.
●
Table 31 shows the correlation between the low power modes and the counters that
control each mode's automatic entry.
●
If the associated bit in the lowpower_auto_enable parameter is cleared to 1'b0, the
memory controller will complete its current memory burst access and then enter the
specified low power mode.
Table 31.
Note:
Low power mode controls
Low Power Mode
Counter
Memory Power-Down (Mode 1)
lowpower_power_down_cnt
Memory Power-Down with Memory Clock Gating (Mode 2)
lowpower_power_down_cnt
Memory Self-Refresh (Mode 3)
lowpower_self_refresh_cnt
Memory Self-Refresh with Memory Clock Gating (Mode 4)
lowpower_external_cnt
Memory Self-Refresh with Memory and Controller Clock Gating
(Mode 5)
lowpower_internal_cnt
The values in lowpower_auto_enable parameter are only relevant when the associated
lowpower_control bit is set to 1'b1.
Multiple bits of the lowpower_control and lowpower_auto_enable parameters can be set to
1'b1 at the same time. When this happens, the memory controller always enters the deepest
low power mode of all the modes that are enabled.
If the memory controller is already in one low power mode when a deeper low power mode
is automatically or manually requested, first it exits the current low power mode and then
enters the deeper low power mode. A minimum 15 cycle delay occurs before the second
entry occurs.
The timing for automatic entry into any of the low power modes is based on the number of
idle cycles that have elapsed in the memory controller. There are 4 counters related to the 5
low power modes to determine when any particular low power mode will be entered if the
Doc ID 022640 Rev 3
85/368
Multiport DDR controller (MPMC)
RM0319
automatic entry option is chosen. The counters are also shown in Table 30. Since the two
power-down modes share one counter, wishing the user automatically enter Memory PowerDown mode (Mode 1), the Memory Power-Down with Memory Clock Gating mode (Mode 2)
must not be enabled.
Controller clock gating and re-locking
When the memory controller is in its deepest low power modes, the clock to the memory
controller is gated off, except for a small portion of the DLL to maintain the current
frequency. Since the voltage and temperature differences of the chip can change and the
DLL would not adjust to these changes, it is possible that the memory controller DLL shifts
out of range of the controller clock.
The DLL can respond to slight variations of the frequency very quickly, but it requires a long
time to manage large shifts. Therefore, it is better the memory controller to be periodically
awoken from controller clock gating, so it can resynchronize to the controller clock and then
resume controller clock gating.
The interval among synchronizations is user-defined by the lowpoxer_rfsh_hold parameter.
This value directly feeds a counter and sets the number of cycles that the memory controller
will wait before attempting to re-lock the DLL.
Note:
This is only relevant when the controller clock is gated (Mode 5).
When this counter expires, the DLL will be un-gated and the DLL will attempt to re-lock. The
clock will be kept un-gated for at least 16 cycles, even if the DLL locks during that time. Once
the DLL has re-locked and the 16 cycles have elapsed, the DLL controller clock will be gated
again and the counter will restart countdown at the value in the lowpoxer_rfsh_hold
parameter.
Refresh masking
Regular refresh commands will be issued at the same intervals as the memory controller is
operating normally, is idle, or is in any of the low power modes. However, for memory arrays
with multiple chip selects, the memory controller can mask refreshes during any of the low
power modes. By setting bits of the lowpower_refresh_enable parameter to 1'b1, autorefreshes will be masked for the associated chip selects.
The user should ensure that refreshes are not constantly masked, and that each chip select
is refreshed periodically.
6.4.4
Low power and clock forwarding
The memory controller implements a clock forwarding scheme, which eliminates the need
for a de-skew PLL and reduces the overall power consumption of the device. Controllers that
are configured for low power should also be configured for clock forwarding.
6.4.5
Mobile DDR/SDRAM devices
Enabling mobile usage
When the device is used inside a mobile device, the parameter en_lowpower_mode must be
set to 1'b1. This enables the memory controller to use the initialization sequence and EMRS
addressing suitable for mobile equipments. When the en_lowpower_mode parameter is
cleared to 1'b0, a standard DDR SDRAM or SDRAM device may be used.
86/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
Partial array self-refresh
For mobile applications, the memory controller is able to support refresh operations to
subsections of the memory array. To simplify this duty, separate parameters are provided to
supply the EMRS data for each chip select. These are the emrs_data_X parameters, where
X represents the chip select.
Having separate control parameters for the EMRS data allows the individual chips to set
their own masked refresh. The write_modereg parameter controls the writing of this EMRS
data into the registers. When write_modereg is set to 1'b1 initially, the EMRS register of chip
select 0 will be written. Each subsequent setting of the write_modereg parameter to 1'b1 will
write the EMRS register of the next chip select (1, 2, then 3).
Note:
The memory controller does not check if operations attempt to access addresses outside
the refresh ranges set by the EMRS registers, so any access to these addresses may result
in corrupt or lost data.
6.4.6
Out-of-range address checking
It is possible that the master attempts to write to an invalid address. For this reason, all
incoming addresses are always checked against the addressable physical memory space. If
a transaction is addressed to an out-of-range memory location, bit 0 of the int_status
parameter will be set to 1'b1 to alert the user of this condition. The memory controller will
record the address, source ID, length and type of transaction that caused the out-of-range
interrupt in the out_of_range_addr, out_of_range_source_id, out_of_range_length and
out_of_range_type parameters.
Reading the out-of-range parameters will trigger the memory controller to empty these
parameters and allow them to store out-of-range access information for future errors. The
interrupt should be acknowledged by setting bit 0 of the int_ack parameter to 1'b1, which will
in turn cause bit 0 of the int_status parameter to be cleared to 1'b0.
If a second out-of-range access occurs before the first out-of-range interrupt is
acknowledged, bit 1 of the int_status parameter will be set to 1'b1 to indicate that multiple
out-of-range accesses have occurred. If the out-of-range parameters have been read when
the second out-of-range error occurs, the details for this transaction will be stored in the outof-range parameters. If they have not been read, the details of the second error will be lost.
Even though the address has been identified as erroneous, the memory controller will still
process the READ or WRITE transaction. A READ transaction will return random data
which the user must receive to avoid stalling the memory controller. A WRITE transaction
will write the associated data to an unknown location in the memory array, potentially overwriting other stored data. The command can not be aborted once accepted into the memory
controller.
6.4.7
Mobile devices DQS
For Mobile applications the user must add pull-down resistors on the DRAM boundary to the
DQS and DQS_n pins. These resistors enable the system to open the gate early without
receiving bad data. Both the resistors are very important and the system can not function
accurately without them.
Doc ID 022640 Rev 3
87/368
Multiport DDR controller (MPMC)
6.4.8
RM0319
Half datapath option
The memory controller can also reduce the usable size of the bus between the memory
controller itself and memory devices. This feature is very useful when a different memory
part, having a smaller data width, is utilized. To use a memory device with a smaller
datapath, the half datapath option could be enabled setting the programmable reduc
parameter to 1'b1. The memory interface consists of the data signal (DQ) [15:0], data strobe
(DQS) [1:0] and data mask (DM) [1:0]. When the reduc parameter is set to 1'b1, only the
lower half of the memory interface is used. In this setting, the upper half bits of the
dm_disable, dqs_disable and data_disable signals are driven high, causing the upper half of
the data and data strobe buses to be driven low. The upper half of the data mask bus is
driven high.
If the reduc parameter is cleared to 1'b0, the memory controller will ignore the half datapath
option and work normally. In this case, the entire memory interface will be used. Table 32
displays the effect of the Half Datapath option on the memory interface buses.
Table 32.
Memory interface buses with Half Datapath option
Reduc parameter is set (1‘b1)
Reduc parameter is cleared(1‘b0)
Bus size
Relevant bit
Bus size
Relevant bit
Data DQ
[15:00]
[07:00]
[15:00]
[15:00]
Data DQS
[01:00]
[00:00]
[01:00]
[01:00]
Data DM
[01:00]
[00:00]
[01:00]
[01:00]
Signal
6.4.9
User-defined registers
The memory controller contains two user-defined parameters. These register-width size
parameters hold user-defined values that will be available as output signals
param_user_def_reg_X (X is 0 or 1) at the core (stp_memcd) level. These parameters have
no effect on the memory controller except that utilizing addresses in the register map.
Only a single bit of the user-defined registers is used in this configuration. All other bits of
user_def_reg_0 and user_def_reg_1 are available if customer hookup is required.
Bit 0 of user_def_reg_0 controls the READ data retime function. This function provides the
user with a choice in clock synchronization paths in the PHY.
An alternative path has been created allowing the PHY to synchronize the READ data to the
core clock domain and then pass the data to the read FIFO synchronously, i.e. in 1one clock
cycle. This constrains the 1/4 cycle path for clock synchronization within the PHY between
two flip-flops which are easily co-located, however it adds a cycle of latency to the path.
Bit 0 of user_def_reg_0 allows the user to select the desired path. If the bit is cleared to
1'b0, the alternative path is used and synchronization occurs in the PHY, incurring the extra
cycle of latency. If the bit is set to 1'b1, the standard path is used.
6.4.10
Address mapping
The memory controller automatically maps user addresses to the DRAM memory in a
contiguous block. Address map begins at user address 0 and finishes at the highest
available address according to the size and number of DRAM devices present. This
mapping is dependent on how the memory controller is configured and how the parameters
88/368
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
in the internal memory controller registers are programmed (Section 6.5). The exact number
and values of these parameters depends on the configuration and the type of memory for
which the memory controller was designed.
The mapping of the address space to the internal data storage structure of the DRAM
devices is based on the actual size of the DRAM devices available. The size is stored in
user-programmable parameters that must be initialized at power up. Certain DRAM devices
allow for different mapping options to be chosen, while other DRAM devices depend on the
burst length chosen.
DDR SDRAM address mapping options
The address structure of DDR SDRAM devices contains five fields. Each of these fields can
be individually addressed when accessing the DRAM. The address map for this memory
controller is ordered as follows:
“Chip Select - Row - Bank - Column - Datapath”
The maximum widths of the fields are based on the configuration settings. The actual widths
of the fields may be smaller if the device address width parameters (addr_pins,
eight_bank_mode and column_size) are programmed differently.
Maximum address space
The maximum user address range is determined by the width of the memory datapath, the
number of chip select pins, and the address space of the DRAM device. The maximum
amount of memory can be calculated by the following formula:
Max Memory Bytes = ChipSelects x 2Address x NumBanks x DPWidthBytes
For this memory controller, the maximum values for these fields are as follows:
●
Chip Selects = 2
●
Device Address = 15+14 (Row+Column)
●
Number of Banks = 8
●
Datapath Width in Bytes = 2 bytes
As a result, the maximum addressable memory area is 16 GB. The maximum memory
capacity is 1GB, which can be implemented with different combinations of these
parameters.
Memory mapping to address space
The maximum allowable address space and mapping into the DRAM devices for the
memory controller is shown in Figure 19. This map corresponds to a memory device with 15
row bits and 14 column bits.
Figure 19. Memory map: Maximum
33
Chip Select
33 32
18 17
Row
15
Bank
14
1 0
Column
0
Data Path
The addr_pins and column_size parameters can range from the maximum configured for
the memory controller to seven bits smaller than the maximum configured. This allows the
memory controller to work with a wide variety of memory device sizes.
Doc ID 022640 Rev 3
89/368
Multiport DDR controller (MPMC)
RM0319
The settings for the addr_pins and column_size parameters control how the address map is
used to decode the user address to the DRAM chip selects and row and column addresses.
The eight_bank_mode parameters control the address in DDR2 mode. It is assumed that
the values in these parameters never exceed the maximum values configured.
Using the example shown in Figure 19, if the memory controller is wired to devices with 12
row pins and 12 column bits, the maximum accessible memory space would be reduced.
The accessible memory space for this configuration is 512 MB.
The address map for this configuration is shown in Figure 20.
Note:
Address bits 29 through 33 are not used. These bits are ignored when generating the
address to the DRAM devices
Figure 20. Alternate memory map
33
29 28
Don’t care
28 27
Chip Select
16 15
Row
13 12
Bank
Column
1 0
0
Data Path
Note:
The Chip Select, Row, Bank, and Column fields are used to address an entire memory
word, and the Datapath bits are used to address individual bytes within that user word. For
example, for a read starting at byte address 0x2, the Datapath bits must be defined as
3'b010 in order to address this byte directly. READs and WRITEs are memory word-aligned
if all the Datapath bits are 0.
6.4.11
DCC tuning timing
The command and address for the transaction are sent from the memory controller
coincident with the falling edge of the memory controller clock. Since the clock, command,
and address signals will all have roughly the same pad and flight delays to travel to the
memory, the rising edge of the clock at the memory will be centered with the command and
address signals, allowing reliable capture. To ensure proper memory read write sequences
the DDR memory controller contains a delay compensation circuit that, in conjunction with
I/O cell circuitry, can be used to meet the memory target timing requirements. The delay
compensation circuit offers the following features:
1.
Programmable read clock delay specified as a percentage of a clock cycle:
The Read transfer path, should also take into account the memory flight paths. There is a
certain time lag from when the clock is sent from the memory controller to when the data
and DQS signals are received at the memory controller from the memory. Since the DQS
from the memory will be sent coincident with the data, and the data must be captured
reliably, the DQS signal is delayed through the register field dll_dqs_delay_X so that it is
centered in the data valid window (nominally approximately 1/4 cycle).
2.
Programmable write clock and write DQS delays specified as percentages of a
clock cycle:
The Write transfer path is controlled from the dqs_out_shift and wr_dqs_shift register
parameters which set the delay for the DQS signal for dll_wr_dqs_slice and for the clk_wr
signal, respectively. These parameters should be programmed such that clk_dqs_out is in
phase with clk and that clk_wr is 1/4 cycle ahead of clk_dqs_out.
3.
90/368
Delay compensation circuit re-sync circuitry activated during refresh cycles to
compensate for temperature and voltage drift:
Doc ID 022640 Rev 3
RM0319
Multiport DDR controller (MPMC)
The delay compensation circuitry relies on a master/slave approach. There is a master
delay line which is used to determine how many delay elements constitute a complete cycle.
This count is used, along with the programmable fractional delay settings, to determine the
actual number of delay elements to program into the slave delay lines. The master and slave
delay lines are identical. This approach allows the memory controller to observe a clock and
then delay other signals a fixed percentage of that clock. The DCC logic does not actively
generate clock signals.
The delay parameters are listed in Table 33. The total delay can be determined based on
the following equation, where param is one of the parameters in the table:
delay = #delays in one cycle × (param[6:0]) /128
Table 33.
Delay parameters
Operation
Parameter
Clock
wr_dqs_shift
Read
dll_dqs_delay_X
Write
dqs_out_shift
1.
Separate delay chains for each DQS signal from the DRAM devices.
2.
Support for multiple DQ:DQS ratios
The DQS bus is a bidirectional bus that is driven by the memory controller on writes and the
memory on reads. When neither device is driving the bus, DQS will remain in a highimpedance state. However, DQS is only relevant to the memory controller during reads in
order to capture valid data. For this reason, the DQS signal from memory must be gated so
that it is ignored at all other times. Gating of the DQS signal is shown in Figure 4, DQS
gating.
The timing of when to start gating the DQS depends on the design itself, the flight time of
the clock to memory, and the flight time of the data/DQS to the memory controller, as
follows:
●
If the round trip time is between ½ cycle and 1½ cycles, program the caslat_lin
parameter equal to the caslat parameter.
●
If the round trip time is less than ½ cycle, program the caslat_lin parameter one value
less (which translates to ½ cycle) than the caslat parameter to open the gate ½ cycle
sooner.
●
lf the round trip time is longer than 1½ cycles, program the caslat_lin parameter one
value more (which translates to ½ cycle) than the caslat parameter to open the gate ½
cycle later.
In addition, the caslat_lin_gate parameter controls the opening of the gating signal.
Nominally, caslat_lin_gate should have the same value as the caslat_lin parameter.
However, to accommodate the skew of the memory devices, it may be necessary to open
the gate a 1/2-cycle sooner or later. Adjusting the value of caslat_lin_gate modifies the gate
opening by this factor.
6.5
Reset
There are two sets of reset logic inside the memory controller: the reset for the memory
controller core and the reset for the AHB ports.
Doc ID 022640 Rev 3
91/368
Multiport DDR controller (MPMC)
RM0319
The reset signal for the memory controller core is the asynchronous active-low reset rst_n
signal that resets all critical flip-flops in the system to ensure the memory controller core
exits from reset in a known state.
When the memory controller core is reset all parameters are reset too, so any commands
inside the memory controller core are lost. Resetting the core does not automatically reset
the AHB ports: resetting the memory controller core without AHB port reset will generate
unknown behavior.
The AHB port reset is the active-low asynchronous signal ahbX_HRESETn. When this reset
is asserted, the associated AHB port will be reset. The port FIFOs will be cleared and the
pointers will be reset. To prevent corruption within the memory controller, AHB ports should
only be reset at initialization and while the port is idle at the interface and with no commands
within the memory controller core.
During initialization, it is recommended that both resets be asserted simultaneously. The
memory controller core reset should be removed first, followed by the port reset. The reset
should be asserted for at least 5 cycles.
6.6
Programming examples
6.6.1
Initializing the MPMC controller
After power on, once the power supply to memory devices and the device itself is stable, the
memory controller must be initialized: afterward it will automatically initialize the memory
devices.
The procedure to initialize the memory controller is as follows:
1.
Clear the rst_n signal by driving it to 1'b0. All programmable registers will be cleared.
2.
Set the rst_n signal synchronously with the memory controller clock by driving the
signal to 1'b1.
3.
Issue write register commands to configure the DRAM protocols and the settings for
the DCC. Keep the start parameter de-asserted during this initialization step.
4.
Assert the start parameter. This triggers the memory controller to execute the
initialization sequence using the parameters written into the registers.
The memory controller will automatically initialize the DRAM memory devices and lock the
internal DCC. The DLL will process and send a signal to the initialization block when it has
locked.
For more information on register configuration, please refer to the Application note
(AN3100): Configuring the SPEAr3xx multiport memory controller (MPMC) for external DDR
SDRAM, present on www.st.com.
92/368
Doc ID 022640 Rev 3
RM0319
7
Serial NOR Flash controller (SMI)
Serial NOR Flash controller (SMI)
This chapter focuses on SMI functionality and operation.
For technical details about the programmable registers related to the SMI, refer to the SMI
registers in the following companion document:
●
7.1
RM0321: SPEAr320S address map and registers
Overview
SPEAr320S provides a serial memory interface (SMI), acting as an AHB slave interface
(32-, 16- or 8-bit) to SPI-compatible off-chip memories. SMI allows the CPU to use these
serial memories for both data storage and code execution.
7.2
Main features
●
Supports a group of SPI-compatible Flash and EEPROM devices:
–
Micron M25Pxxx, M45Pxxx
–
STMicroelectronics M95xxx, except M95040, M95020 and M95010
–
ATMEL AT25Fxx
–
YMC Y25Fxx
–
SST SST25LFxx
●
Acts always as a SPI master and up to 2 SPI slave memory devices are supported
(through as many chip select signals), with up to 16 MB address space each.
●
The SMI clock signal (SMI CLK) is generated by SMI and inputs to all slaves. It can be
up to 50 MHz in fast read mode (or 20 MHz in normal mode), and it can be controlled
by a programmable 7-bit prescaler allowing 127 different clock frequencies.
Doc ID 022640 Rev 3
93/368
Serial NOR Flash controller (SMI)
7.3
RM0319
Functional description
Figure 21 shows the block diagram of SMI.
SMI consists of two main interfaces:
●
The clock prescaler (Section 7.3.1)
●
The data processing and control (Section 7.3.2)
Figure 21. SMI block diagram
SMI Clock
Prescaler
(1 to 127)
AMBA AHB Bus
SMI Data processing
and Control
Data,
command
Bank select
SPICompatible
Memories
Transmit Register
AHB Slave
Interface
Control and
Status Register
Receive Register/
Status Regsiter
7.3.1
Clock
Data,
Status
Clock prescaler
The SMI clock prescaler block allows to set up the memory clock SMI_CLK using the AHB
clock HCLK, as detailed in Section 7.4.
7.3.2
Data processing and control
The SMI data processing and control block represents the logic controlling the transfer of
data between SPI-compatible off-chip memory and AHB bus. Transfer rules through both
AHB-to-SMI and SMI-to-memory interfaces. The different data transfer modes between SPIcompatible off-chip memory and AHB bus are detailed in Section 7.3.4.
94/368
Doc ID 022640 Rev 3
RM0319
Serial NOR Flash controller (SMI)
AHB-to-SMI interface
Acting as an AHB slave interface, the SMI is accessed by the AHB master through the AHB
bus. The following rules apply to this interface:
Note:
●
Endianness is fixed to little-endian.
●
SPLIT / RETRY responses from AHB slave (that is., the SMI) are not supported.
●
Size of data transfers to external serial memories can be byte, half-word or word (8-/16or 32-bit).
●
Size of data transfers to SMI registers must be 32 bits.
●
Read requests: all types of BURST defined by AHB protocol are supported (single,
wrapping and incrementing). Please note that wrapping bursts take more time than
incrementing bursts, because there is a break in the address increment.
If EEPROMs are used instead of Flash memories, the read request address should be
(ADDRESS + 1), where ADDRESS should be the actual target address to be read.
●
Write requests: wrapping bursts are not supported, causing an ERROR response on
HRESP sent back by SMI to AHB master.
●
Bursts must not cross bank boundaries.
●
In case of BUSY transfers, the SMI is held until BUSY is inactive.
SMI-to-MEMORY interface
Acting as a SPI master, the SMI supports a synchronous full-duplex data link with its up to 2
SPI slaves (the serial memory devices).
Each SPI slave must agree with the communication protocol fixed by SMI in terms of clock
polarity (CPOL) and clock phase (CPHA), specifically CPOL = 1 and CPHA = 1 (where clock
idles high and data is shifted in and out on the rising edge of the clock).
Prior to any operation involving a SPI-compatible off-chip memory device, the related SPI
slave must be selected by SMI (through chip select), then an 1-byte instruction must be sent
by SMI to the selected memory. The set of instructions supported by SMI is given in
Table 34.
Table 34.
7.3.3
SMI supported instruction
Opcode
Description
8’h03
Read data bytes.
8’h0B
Read data bytes at high speed.
8’h05
Read status register.
8’h06
Write enable.
8’h02
Page program.
8’hAB
Release from deep power-down.
Operation modes
SMI can run in two operation modes:
●
Hardware mode, by clearing the SW bit in the SMI_CR1 register.
●
Software mode, by setting the SW bit in the SMI_CR1 register.
Doc ID 022640 Rev 3
95/368
Serial NOR Flash controller (SMI)
RM0319
In both operation modes, SMI can work:
●
In normal mode, by clearing the FAST bit in the SMI_CR1 register, with a frequency up
to 20 MHz (19 MHz at power-on).
●
In fast mode, by setting the FAST bit in the SMI_CR1 register, with a frequency ranging
from 20 MHz to 50 MHz.
Hardware mode
Hardware mode allows SMI to perform read/write requests from any AHB master which can
directly access the external serial memory.
In particular, external serial memory is mapped in AHB address space as shown in
Figure 22,
Figure 22. External SPI memory map in AHB address space
0xF9FF_FFFF
CS1
0xF9FF_FFFF
0xF900_0000
External Serial
M em ory Space
0xF800_0000
0xF8FF_FFFF
CS0
0xF800_0000
In this mode, both the transmit register SMI_TR and the receive register SMI_RR must not
be accessed. They are actually in charge of the SMI state machine to communicate with the
selected external memory device, whenever an AHB master reads or writes an address into
the memory.
At power-on reset, the SMI operates in hardware mode (allowing to boot from external
memory, as explained in Section 7.5.1).
Software mode
Software mode is intended to allow any AHB master to access external serial memory by
programming the internal SMI registers and reading them for memory replies. In this mode,
a direct transfer to/from external memory – that is, bypassing SMI registers - is not permitted
to an AHB master.
In particular, software mode is used both to transfer any data or commands from transmit
register (SMI_TR to external serial memory, and to read data directly in the receive register
(SMI_RR). The transfer actually starts setting the dedicated SEND bit in the SMI_CR2
register.
Besides, in software mode the application code being executed by the CPU cannot be
fetched from external memory, because of the incompatibility between software and
hardware mode. The code must be either hosted by internal memory or previously loaded
from external memory while SMI is in hardware mode.
For example, software mode is used to erase Flash memories before writing. Indeed,
memory erasing cannot be performed in hardware mode due to the incompatibility of Flash
devices from different vendors.
96/368
Doc ID 022640 Rev 3
RM0319
7.3.4
Serial NOR Flash controller (SMI)
Data transfers
Read request
A read request from an AHB master to external SPI memory is served only if SMI is in
hardware mode, and write burst mode is not enabled. Otherwise, an error flag is set (ERF1
flag in the SMI_SR register, and an ERROR response is sent back to the AHB master.
When a read request occurs in normal mode (that is, frequency up to 20 MHz), the SMI
sends the following data sequence to the bank selected by the AHB address bits [24.25].
●
Read data bytes instruction opcode (8’h03)
●
3- or 2-byte address (depending on the ADD_LENGTH bit of SMI_CR1 register, from
the MSB to the LSB,
●
Then, clock is sent to the memory until the end of burst requested by the AHB master.
In contrast, when a read request occurs in fast mode (that is, frequency ranging from
20 MHz to 50 MHz), the following sequence is sent:
●
Read data bytes at high speed instruction opcode (8’h0B),
●
3- or 2-byte address (depending on the ADD_LENGTH bit of SMI_CR1 register, from
the MSB to the LSB,
●
1 dummy byte (8’h00),
●
The clock is sent to the memory until the end of burst requested by the AHB master.
The external memory bank remains selected as long as
Note:
●
There is no external memory address jump,
●
No new commands are sent to the SMI (such as write enable request, read status
register command set, software mode or write burst mode, write request, bank disable,
prescaler configuration change),
●
No memory access error occurs.
The memory bank also remains selected when the address rolls over from 0x00FF_FFFF to
0x0000.0000 within the same bank.
Write request
A write request from the AHB master to external SPI memory is served only if SMI is in
hardware mode, otherwise an error flag is set (ERF1 flag in the SMI_SR register). Wrapping
bursts is not allowed as long as external SPI memories do not support them, and an
ERROR response is sent back to the AHB master.
When a write request occurs, this request is forwarded to external memory only if both
following conditions are fulfilled:
●
Note:
First, the selected bank should be in write mode (the corresponding bit in WM field of
SMI_SR register is flagged). Otherwise, a dedicated error flag is set (the ERF2 flag in
the SMI_SR register) and an ERROR response is sent back to the AHB master.
To enable write mode, select the memory bank using the BS bits in the SMI_CR2 register,
and then set the WEN bit in the SMI_CR1 register.
●
Second, no write should be in progress. The WIP bit of external memory status register
in the SMI_SR register (bit [0]) must be cleared. If this condition is not met, AHB is
stalled until WIP = 1‘b0.
Doc ID 022640 Rev 3
97/368
Serial NOR Flash controller (SMI)
RM0319
When the 2 conditions above are met, the following data sequence is sent to the bank
selected by AHB address bits [24-25]:
●
Page program instruction opcode (8’h02,Table 34),
●
3- or 2-byte address (depending on the ADD_LENGTH bit of SMI_CR1 register from
the MSB to the LSB,
●
All data bytes (from bit 7 to bit 0) are transferred, starting with the address given in the
previous step and incrementing it to the last depending on the size of the write request.
After a write request has been sent, the WM bit in SMI_SR register is cleared and the read
status register instruction (opcode 8’h05, Table 34) is automatically sent to this bank until no
write in progress (WIP =1‘b0).
Note:
1
The write capability must be used only if there is a write in progress, which means that a
busy bit of the external memory status register is located in bit 0. Otherwise, the system will
become locked.
2
When the memory programming is finished, the WCF bit in the SMI_SR register is set and
an interrupt is generated if the enabling WCIE bit in the SMI_CR1 register is set.
3
In order to send a write request to a bank other than the one under programming, the
software must wait for WIP = 1‘b1, otherwise the error ERF2 would be generated due to non
incrementing address. The bank under programming phase must not be disabled in order to
write to another one.
Write burst mode
Write burst mode (WBM bit set in SMI_CR1 register) enables to keep selected the external
SPI memory after an AHB write request (see above). In this case, the next AHB write
request should point to the next incremented address and should have the same size (byte,
half-word or word). Otherwise, an error flag is set (ERF2 flag in the SMI_SR register, and an
ERROR response is sent back to the AHB master.
Note:
A memory access error (ERF1 or ERF2) results in both release of chip select and start of
the external memory page program.
Disabling the write burst mode (that is, clearing the WBM bit in SMI_CR1 register), the next
incrementing AHB write request should be sent to external memory if it occurs before the
end of the previous serial transfer. Otherwise, an error flag is set (ERF2 flag in the SMI_SR
register) and an ERROR response is sent back to the AHB master.
Consequently, it is mandatory to enable the write burst mode in order to perform several
write requests which are not sent in the same AHB incrementing burst. If WBM is cleared
and no other write request occurs, the external memory selection is released after sending
the data and the external memory page program cycle starts.
Note:
Read requests to external memory are not allowed in write burst mode, otherwise an error
flag is set (ERF1 flag in the SMI_SR register) and an ERROR response is sent back to the
AHB master.
The external SPI memory is released by either disabling write burst mode (clearing WBM
bit) or disabling the bank, and the external memory page program cycle starts. If bank is
enabled, read status register instruction is automatically sent to this bank until WIP = 1‘b0.
98/368
Doc ID 022640 Rev 3
RM0319
Serial NOR Flash controller (SMI)
Read while write mode
If a read request occurs for the bank which is in programming phase, the AHB bus is stalled
until no write in progress (WIP = 1‘b0). (please refer to SMI_SR register description for
details on WIP bit).
If a read request occurs for another bank, the read status register sequence is stopped, then
the read request is served and, finally, the read status register sequence is sent again to the
memory bank being programmed.
It follows that during a read while write, the selected external SPI memory is released after
the read command, in order to send the read status register sequence.
Erase and write status register
In case of serial Flash, an erase may be necessary before writing. Due to incompatibility
between different serial Flash vendors, erase and write status register can be done only in
software mode.
It is mandatory to send previously the write enable instruction through Software mode only
(that is, setting the WEN bit in SMI_CR2 register, in order to avoid corruption of the WM bit
in the SMI_SR register. Indeed, the end of either internal Flash erase or write status register
cannot be checked by hardware mode, preventing generation of write complete interrupt. On
the other hand, WIP bit can be checked by continuously sending a read status register
command.
7.4
Clocks
The memory clock (SMI_CLK) is generated by SMI through its programmable prescaler unit
(Section 7.3.1), as depicted in Figure 21.
The incoming AHB bus frequency fAHB (HCLK signal) is divided by the value stored in the
PRESC field of SMI_CR1 register, resulting in the SMI clock frequency fSMI_CLK:
●
fSMI_CLK = fAHB / 2*(PRESC value)
that is,
●
tSMI_CLK = tAHB · 2*(PRESC value)
being tSMI_CLK and tAHB the clock period of the SMI clock and the AHB bus, respectively.
Note:
If PRESC is an even value, high time and low time of SMI clock are both equal to half a
tSMI_CLK. In contrast, in case PRESC is an odd value:
tSMI_CLK, high= [(PRESC - 1) / 2]
tSMI_CLK, low = [(PRESC + 1) / 2]
7.4.1
Latencies
Assuming that SMI is not busy by now, the nominal latency for a 32 bit single read to a nonincrementing serial Flash address, is:
●
●
73 tAHB maximum, if PRESC = 1 (that is, tAHB = tSMI_CLK).
(68 tSMI_CLK + 5 tAHB) maximum, if PRESC > 1 (that is, tAHB ≠ tSMI_CLK, and specifically
tSMI_CLK > tAHB),
Doc ID 022640 Rev 3
99/368
Serial NOR Flash controller (SMI)
RM0319
taking into account up to 9 clock periods in addition to 64 clock periods required to both
send command to serial Flash memory (1-byte opcode + 3-bytes address) and receive back
32 bits.
●
Besides, under the same assumption, the nominal latency for a 32 bit single write to a
non-incrementing serial Flash address is:
●
5 tAHB maximum, if PRESC = 1 (that is, tAHB = tSMI_CLK).
●
(2 tSMI_CLK + 3 tAHB) maximum, if PRESC > 1 (that is, tAHB ≠ tSMI_CLK, and specifically
tSMI_CLK > tAHB).
In case of AHB read burst transfers, the maximum latency for all transfers after the first is the
same as data size, that is (32 tSMI_CLK) for a word transfer, (16 tSMI_CLK) for a half-word and
(8 tSMI_CLK) for a byte, because of no mandatory extra commands (instruction opcode and
address).
Moreover, for AHB write burst transfers, the maximum latency for the 2nd transfer is (data
size + opcode + address bytes) whereas it is the same as data size for following transfers.
However, nominal latency can be increased by:
●
Ongoing SMI transfer (read, write, read status register command or write enable
command)
●
Deselect time programming (field TCS in SMI_CR1 register), which adds (TCS + 1) ·
SMI_CLK periods
●
Busy / Idle transfer on AHB bus
●
Fast read which adds 1 dummy byte
●
Hold programming (field HOLD in SMI_CR1 register)
●
Boot delay time (Section 7.5.1)
●
Frequency change
●
Programming on-going
7.5
Programming examples
7.5.1
Booting from external memory
The device allows an external boot from a serial Flash only located at Bank0 (which is
enabled after power-on reset). During the boot phase, the following instructions sequence is
automatically sent to bank0:
Note:
100/368
●
Release from deep power-down (opcode 8’hAB, Table 34), in order to be able to boot
on this bank even if it was in deep power-down mode.
●
29 µs delay to ensure Bank0 is successfully released.
●
Read status register (opcode 8’h05), in order to check that bank0 is neither in write nor
in erase cycle.
●
Read data bytes (opcode 8’h03) at memory start location (that is, 32’h0) with a 19 MHz
clock frequency.
1
All memory banks other than Bank0 are disabled at reset and they must be enabled by
setting dedicated BE bits in SMI_CR1 register before they can be accessed.
2
If an AHB request occurs while either the WEN bit or the RSR bit (both in SMI_CR2 register,
is set, the on-going command is first finished before the request from AHB is sent to the
memory.
Doc ID 022640 Rev 3
RM0319
8
Parallel NAND Flash controller (FSMC)
Parallel NAND Flash controller (FSMC)
This chapter focuses on FSMC functionality and operation.
For technical details about the programmable registers related to the FSMC, refer to the
FSMC registers in the following companion document:
●
8.1
RM0321: SPEAr320S address map and registers
Overview
SPEAr320S provides a Flexible Static Memory Controller (FSMC) which is intended to
interface an AHB bus to external parallel NAND Flash memories (8/16 bit).
Note:
The 16-bit NAND interface is available when the in SPEAr320S is configured in automation
expansion mode (see Section 32: Reconfigurable array subsystem (RASCFG) and the pin
description section of the SPEAr320S datasheet).
The controller translates the AHB protocol into external parallel NAND Flash protocol. It
meets the timings of the external devices, slowing down and counting an appropriate
number of HCLK (AHB clock) cycles to complete the transaction to the external device.
Note:
The external storage device cannot be faster than one AHB cycle.
8.2
Main features
●
AHB slave interface
●
Interfaces AHB with parallel NAND Flash devices
●
Performs only one access at a time;
●
Provides programmable timings to support a wide range of devices:
–
programmable wait states (up to 31),
–
programmable bus turn around cycles (up to 15),
–
programmable output enable and write enable delays (up to 15).
●
Can be interfaced with four external devices (four chip select pins available);
●
Offers an external asynchronous wait control;
●
Offers configurable size at reset for boot memory bank using SPEAr320S configuration
registers
Doc ID 022640 Rev 3
101/368
Parallel NAND Flash controller (FSMC)
8.3
RM0319
Functional description
Configuration
Registers
NAND Flash
Driver
AHB
AHB
Interface
8.3.1
External memory/pccard
Figure 23. FSMC block diagram
AHB interface
The AHB interface block provides the FSMC interface to the AHB bus. It decomposes the
system bus transfers into external accesses supported by the selected external device.
The RW control register values are accessed through the AHB, and their values are passed
to the rest of the peripherals
The following conditions cause an ERROR response:
●
If a disabled external device is accessed.
●
If a Flash memory is accessed when its Reset Powerdown bit (GenMemCtrl_PC(i)
registers) has been set to 0.
●
If HSIZE is greater than 2, which means a transfer size larger than 32 bits. In other
cases, OKAY response is returned.
The AHB interface does not support the following AHB features:
8.3.2
●
It does not generate SPLIT or RETRY responses.
●
Protection control is not implemented, which means that HPROT is not connected.
NAND Flash controller
This block interfaces the AHB interface block to the external NAND Flash. For NAND Flash,
the following types of accesses are supported:
Common memory space access
It is the normal way of accessing the NAND Flash. The data size is specified in the
DevWidth field of configuration register (GenMemCtrl_PC register), and the corresponding
timings must be specified in the GenMemCtrl_Comm register. The data used while
accessing this region is passed to D(7:0) bits (or D(15:0) according to the Flash memory
bus width). The FSMC_ADDR_LE or FSMC_CMD_LE pins are used to drive directly ALE
and CLE, respectively. Therefore, by accessing particular regions of the common memory
space, we can send to the NAND Flash a command (CLE high) or an address (ALE high).
102/368
Doc ID 022640 Rev 3
RM0319
Parallel NAND Flash controller (FSMC)
Attribute memory space access
The only difference with respect to common memory space access mode is that the timings
used are specified in the register GenMemCtrl_Attrib. In practice, this secondary access
works exactly the same as common memory space accesses, but this can be used to
implement a functionality that is needed in some (but not all) NAND Flash memories.
Some Flash memories require that after writing the last part of the address, the controller
has to wait and check that R/B (the wait signal from the Flash) goes low. This pre-wait time
can be up to 100ns, then if there is such event the controller has to wait again until R/B goes
high. During all this period CE must be held low.
Other NAND Flash memories (such as the Samsung 1Gbit) do not require the pre-wait time;
they just require that when the memory is being accessed and R/B is low, the controller
should wait until R/B goes high.
Doc ID 022640 Rev 3
103/368
External memory interface (EMI)
9
RM0319
External memory interface (EMI)
This chapter focuses on EMI functionality and operation.
For technical details about the programmable registers related to the EMI, refer to the EMI
registers in the following companion document:
●
9.1
RM0321: SPEAr320S address map and registers
Overview
The EMI Controller provides a simple external memory interface that can be used to
connect to SRAM, NOR Flash memory or FPGA devices. The protocol uses quite a few
signals. This block is designed to perform simple read-write operations and does not
support any kind of burst operation (neither on the AHB nor on the EMI interface). The data
exchange flow of the attached device must be broken down into simple operations and
should be performed in accordance with the EMI cycles
9.2
9.3
Main features
●
AHB slave interface
●
Non-multiplexed address and data bus
●
EMI is always master on the EMI bus
●
Performs 16-/8-bit transfers
●
Can access 4 different peripherals using CS#, one at a time
●
Support single transfer with acknowlegement signal expected which is used to
terminate the transfer
●
Supports peripherals which use the byte lane procedure
Functional description
The EMI block is an AHB slave module which can interface an external FPGA,SRAM or
NOR Flash through the EMI interface. The following figure shows the AHB and EMI
interfaces of the EMI module.
104/368
Doc ID 022640 Rev 3
RM0319
External memory interface (EMI)
Figure 24. AHB-EMI interface
HCLK
HRESETn
P L_G P I O s
EMI_BYTEN (1:0)
HSEL
HADDR(31:0)
EMI_D (15:0)
HTRANS(1:0)
EMI_A (23:0)
HWRITE
EMI_CE (3:0)
HSIZE(2:0)
EMI_WE
EMI_OE
HBURST(2:0)
EMI
HWDATA(31:0)
HREADYIn
EMI_WAIT
HRDATA(31:0)
HREADYout
PERIPHERAL BUS
9.3.1
HRESP(1:0)
EMI cycles definition
The following figure shows the typical write cycle.
Figure 25. EMI write cycle
EMI_ADB
BE#[3:0]
ADDR[28:0]
WRITE DATA
EMI_ADDLE
EMI_CE#
EMI_WE#
EMI_WAIT#
Note:
EMI_WAIT# can be used to increase the cycle time (slow peripherals).
The following figure shows the typical read cycle.
Doc ID 022640 Rev 3
105/368
External memory interface (EMI)
RM0319
Figure 26. EMI read cycle
BE#[3:0]
ADDR[28:0]
EMI_ADB
READ DATA
EMI_ADDLE
EMI_CE#
EMI_OE#
EMI_WAIT#
Note:
EMI_WAIT# can be used to increase the cycle time (slow peripherals).
9.3.2
Data flow
The data transfer protocol will be based on the timing diagrams shown in EMI cycle
definition. Prior to any read/write operation, the timing and control registers should be
programmed. The timing registers will be used to time the EMI-interface signals in respect to
the HCLK cycles. There are different registers for EMI-interface signals for extending them
to a specified number of HCLK cycles. The Control register provides information about the
peripheral connected.
If a write operation is desired on the peripheral, then an AHB write operation is initiated.
Similarly, for a read operation AHB read is done. The EMI supports 8 bit and 16 bit
peripherals. The following table lists the transactions supported by EMI:
Table 35.
EMI data flow
Peripheral Connected
AHB Access
Support
16 bit
32 bit
No (AHB Error, Interrupt)
16 bit
16 bit
Yes
16 bit
8 bit
Yes
8 bit
32 bit
No (AHB Error, Interrupt)
8 bit
16 bit
No (AHB Error, Interrupt)
8 bit
8 bit
Yes
For transactions not supported, AHB Error is generated on the bus and an interrupt is
raised. Interrupt can be checked in the IRQ register.
The data phase (i.e. the data bus along with the control signals) will be extended until the
EMI_WAIT# is asserted low by the external peripheral. If this feature is not used, as
mentioned in the Ack_reg, this signal is ignored.
Following timing diagrams details the timing and flow of different signals and also indicates
which registers corresponds to what timings.
106/368
Doc ID 022640 Rev 3
RM0319
External memory interface (EMI)
EMI write without acknowledgement signal (EMI_WAIT#)
Figure 27. EMI write (without ACK)
a
tAP
c
b
e
WRITE DATA
BE ADDR
EMI_ADB
d
tDPw
EMI_ADDLE
tSDP
tDCS
EMI_CE#
EMI_WE#
This timing diagram indicates a typical EMI write cycle. Acknowledgement signal
(EMI_WAIT#) is ignored in this case. It also indicates the registers which affect the timing
duration of the different interface signals.
EMI write with acknowledgement signal (EMI_WAIT#)
Figure 28. EMI write (with ACK)
a
b
d
c
e
f
g
tAP
EMI_ADB
WRITE DATA
BE ADDR
EMI_ADDLE
tSDP
tDPw
EMI_CE#
tDCS
EMI_WE#
EMI_WAIT#
This timing diagram indicates a typical EMI write cycle in which the Acknowledgement signal
(EMI_WAIT#) is considered. It also indicates the registers which affect the timing duration of
the different interface signals.
Doc ID 022640 Rev 3
107/368
External memory interface (EMI)
RM0319
EMI read without acknowledgement signal (EMI_WAIT#)
Figure 29. EMI read (without ACK)
c
b
a
d
e
tAP
READ DATA
BE ADDR
EMI_ADB
tDPr
EMI_ADDLE
tSDP
tDCS
EMI_CE#
EMI_OE#
This timing diagram indicates a typical EMI read cycle. Acknowledgement signal
(EMI_WAIT#) is ignored in this case. It also indicates the registers which affect the timing
duration of the different interface signals.
EMI read with acknowledgement signal (EMI_WAIT#)
Figure 30. EMI read (with ACK)
a
EMI_ADB
tAP
b
c
d
e
f
g
READ DATA
BE ADDR
EMI_ADDLE
tSDP
tDPr
EMI_CE#
EMI_OE#
tDCS
EMI_WAIT#
This timing diagram indicates a typical EMI read cycle in which the Acknowledgement signal
(EMI_WAIT#) is considered. It also indicates the registers which affect the timing duration of
the different interface signals.
9.4
Programming examples
Example 1: A 16-bit peripheral which does not use byte lane procedure is connected with
EMI. The peripheral does not provide the acknowledgement signal. We want to perform
read and write to it. The peripheral is connected to CS0.
108/368
Doc ID 022640 Rev 3
RM0319
External memory interface (EMI)
Control Register (control_0_reg, as it is connected to CS0) contents would be: 0x1
(Bit [1:0] = 01 indicates 16 bit, Bit 2 = 0 indicates that unequal bus size access is not
supported, Bit 3 = 0 indicates that the data available on the lower byte of peripheral bus.)
No Acknowledgement, so Ack_reg content would be: 0x1.
(As it is connected to CS0, Bit 0 of Ack_reg should be 1 indicating ACK behavior not used.)
Timing registers to be programmed are tSCS_0_reg, tSE_0_reg, tENw_0_reg, tENr_0_reg
and tDCS_0_reg. The timing mentioned in these registers should be expressed in number
of AHB cycles.
As a 16 bit peripheral is connected, only 16 bit accesses are supported from AHB. If not so,
an AHB Error is indicated. An interrupt is also raised.
Example 2: An 8-bit peripheral following byte lane procedure during read and write is
connected on CS3.
Control Register: control_3_reg = 0x0C.
(Bit [1:0] = 00 indicates 8 bits, Bit 2 = 1 indicates byte lane procedure used, Bit 3 = 1
indicates data available in corresponding lanes and Bit 4 = 0 indicates little endian data.
Ack_Reg: 0x0. Bit 3= 0 indicating ACK behaviour is used.
Timeout_reg = 0xABC. As ACK behavior is used, the timeout register should be
programmed accordingly. Here a random value is given as an example. It should be
replaced with an appropriate value. The default value is 0xFF. If timeout occurs, an AHB
error and its associated interrupt are generated.
The timing registers to be programmed are tSCS_3_reg, tSE_3_reg, tENw_3_reg,
tENr_3_reg and tDCS_3_reg. The timing mentioned in these registers should be expressed
in number of AHB cycles.
As 8-bit peripheral is connected, only 8-bit accesses are allowed.
Doc ID 022640 Rev 3
109/368
USB 2.0 Host ports (UHC)
10
RM0319
USB 2.0 Host ports (UHC)
This chapter focuses on USB Host functionality and operation.
For technical details about the programmable registers related to the USB Host, refer to the
USB Host registers in the following companion document:
●
10.1
RM0321: SPEAr320S address map and registers
Overview
SPEAr320S provides a USB 2.0 Host with 2 physical ports which are fully compliant with the
Universal Serial Bus specification (version 2.0), offering an interface to the industrystandard AHB bus.
10.2
Main features
●
A PHY interface implementing a USB 2.0 Transceiver Macro-cell Interface plus
(UTMI+) fully compliant with UTMI+ specification (revision 1.0), to execute serialization
and de-serialization of transmissions over the USB line.
●
Either 30 MHz clock for 16-bit interface or 60 MHz for 8-bit interface are supported by
the UTMI+ PHY interface.
●
A USB 2.0 Host Controller (UHC) which is connected to the AHB bus and generates
the commands for the UTMI+ PHY.
●
The UHC complies with both the Enhanced Host Controller Interface (EHCI)
specification (version 1.0) and the Open Host Controller Interface (OHCI) specification
(version 1.0a).
●
The UHC supports the 480 Mbps high-speed (HS) for USB 2.0 through an embedded
EHCI Host Controller, The EHCI controller is able to sustain HS communications over
the 2 ports in parallel.
●
The UHC supports the 12 Mbps full-speed (FS) and the 1.5 Mbps low-speed (LS) for
USB 1.1 through two integrated OHCI Host Controllers.
●
All clock synchronization is handled within the UHC.
●
An AHB slave for each controller (1 EHCI and 2 OHCI), acting as programming
interface to access to control and status registers.
●
An AHB master for each controller (1 EHCI and 2 OHCI) for data transfer to system
memory, supporting 8, 16, and 32 bit wide data transactions on the AHB bus.
●
32-bit AHB bus addressing
The Host controller is capable of managing two different devices at a time (each one in
EHCI or OHCI mode) over the two PHY interfaces.
The Host subsystem can manage an external power switch, providing a control line to
enable or disable the power, and an input line to sense any over-current condition detected
by the external switch.
110/368
Doc ID 022640 Rev 3
RM0319
10.3
USB 2.0 Host ports (UHC)
Functional description
Figure 31. UHC block diagram.
EHCI
Operation
AHB BIU
AMBA AHB
Port1
UTMI+PHY
List
Processor
Root Hub
EHCI
Port0
To External PAD
SOF
Generator
Packet Buffer
USB2.0 EHCI Controller
OHCI
USB1.1 OHCI
Controller
OHCI
USB1.1 OHCI
Controller
UHC
10.3.1
AHB bus interface unit (BIU)
USB 2.0 Host access to the AHB bus is granted by the AHB Bus Interface Unit (BIU), which
consists of a master module and a slave module.
The AHB BIU Slave module acts a slave on the AHB and responds to all EHCI/OHCI
operational registers (see Operational registers on page 112) accesses from an AHB
master. In particular, this module allows RW access to its operational registers through the
AHB bus.
Note:
There is only a single AHB slave port in AHB BIU Slave module for both EHCI and OHCI
host controller registers access.
The AHB BIU Master module, acting as a master on the AHB, receives requests from the
List Processor block (see List processor on page 112) within the EHCI Host Controller, and
transfers data with system memory through the AHB bus. The AHB BIU Master supports 8-,
16-, and 32 bit data transfers, and 32 bit address transfers.
10.3.2
EHCI host controller
An EHCI Host Controller compliant with the EHCI specification (version 1.0) is embedded
within the UHC to support the 480 Mbps high-speed (HS) transaction of USB 2.0. HS
devices connected to the two downstream ports.
The main blocks of the EHCI host controller are described below.
Doc ID 022640 Rev 3
111/368
USB 2.0 Host ports (UHC)
RM0319
List processor
The List Processor is the main block of the EHCI Host Controller. The List Processor is
implemented with multiple state machines to perform the list service flow, which is set up by
the Host Controller Driver (HCD) according to the priority set in the Operational registers
Section : Operational registers
In addition, the List Processor consists of a controller that interfaces with all the other EHCI
Host Controller blocks, such as the AHB BIU (Master module), the Packet Buffer, the EHCI
Operational registers, the SOF Generators and the Root Hub.
Operational registers
This block exposes the implemented EHCI Capability and Operational registers as defined
in the USB EHCI specification. In addition, certain IP-specific extended registers are also
implemented, in order to configure features like Packet Buffer depth, break memory transfer,
frame length.
The Operational registers block interfaces with the AHB BIU (Slave module), the List
Processor and the Root Hub.
Start-Of-Frame (SOF) generator
The SOF Generator block implements the counter which generates the Start-Of-Frame
(SOF) packets to supply micro-SOFs for each microframe. The SOF counter runs in the
PHY clock domain.
Microframe duration is derived from the EHCI Frame Length Adjustment (FLADJ) register
value. This ensures that the Host microframe duration and per-port microframe duration
remain the same.
This block interfaces with the List Processor only.
Packet buffer
The Packet Buffer (PBUF) block provides storage and control for IN/OUT data transaction,
with a configured size of 1024 bytes (256 x 32 = 1024 bytes).
According to its functionality, the PBUF block interface with both the List Processor and the
Root Hub. Specifically, during an OUT transaction, the List Processor fetches data from the
system memory and writes them in the PBUF. Besides, during an IN transaction, the data
are written to PBUF by the Root Hub Section : Root hub.
The Packet Buffer size depends on the system latency and bandwidth allocated to the EHCI
Host Controller. For example, in case PBUF size is programmed to 64 bytes, a 1024-bytes
IN transfer would get 1024/64 = 16 data transfer on the AHB bus. If the system is not able to
ensure EHCI access to AHB bus for these 16 transfers with no breaks, then a buffer overrun
occurs. In this case, to avoid buffer overrun or under-run, PBUF size could be set to 1024
bytes.
Root hub
The Root Hub (RH) block interfaces between the List Processor and the USB PHY. It
propagates reset and resume signals to downstream ports, and handles port connections
and disconnections.
The RH operates both on the local PHY clock (a free-running 30/60 MHz clock) and on the
clock source from each physical port (30 MHz with a 16 bit interface).
112/368
Doc ID 022640 Rev 3
RM0319
OHCI host controller
Two OHCI Host Controllers compliant with the OHCI specification (version 1.0a) are also
integrated in the UHC to support the 12 Mbps full-speed (FS) and the 1.5 Mbps low-speed
(LS) operation of USB 1.1. FS/LS device connected to port0 is managed by OHCI0 and
port1 is managed by OHCI1.
The USB Open Host Controller is designed to be independent of the Bus Interface Unit
(BIU) as in Figure 32. The host bus is assumed to be at least 32 bits wide with adequate
performance to support the data rate of the particular implementation (100Mbit/sec or
higher plus overhead for DMA structures) as well as bounded latency so that the FIFO’s can
have a reasonable size.
The main blocks of the OHCI host controller are described below.
Figure 32. USB Host controller (UHOSTC) block diagram
OHCI
Regs
RCFG_RegData(32)
APB_SADR(6)
HCI
Slave
block
HCI_Data(32)
Control
OHCI
Regs
HCM_ADR/
Data(32)
Control
Ctrl
1
X
V
R
USB
2
TxDpls
Root Hub
&
Host SIE
Ctrl
TxDmns
Port
S/M
X
V
R
USB
Cntl
List
Processor
Block
ED/TD_Data(32)
APP_MData(32)
Port
S/M
TxEnL
USB
State
Control
Ctrl
APB_SData(32)
HCI Bus
Ctrl
Ctrl
ED/TD_Status(32)
ED &TD
Regs
HCI
Master
block
DF_Data(8)
Clock
MUX
12/1_5
RH_Data(8)
64 x 8
FIFO
Ctrl
Root
Hub
Config
Block
HSIE
S/M
RcvData
Status
HC_Data(8)
DPLL
RcvDpls
-
RcvDmns
DF_Data(8)
FIFO_Data (8)
Addr (6)
15
Ext.FIFO Status
HCF_Data(8)
10.3.3
USB 2.0 Host ports (UHC)
Port
S/M
X
V
R
USB
FIFO
64 x 8
HCI master block
The HCI master block is the interface between HCI master interface logic block and the HCI
bus. It converts all the cycles initiated by different blocks of the list processor through HCI
master inteface logic block into HCI bus cycles according to the protocol defined for HCI
bus. In addition to that it implements a state machine to read/ write from/to DFIFO. When it
is transferring the data returned by endpoint, it reads the data from DFIFO and merges into
DWORD and then send it to the application’s internal FIFO. Similarly when reading the
Doc ID 022640 Rev 3
113/368
USB 2.0 Host ports (UHC)
RM0319
endpoint data from the system memory, after reading every DWORD from the application’s
FIFO it splits the DWORD into 4 individual bytes and then sends it to the DFIFO. It also
implements byte-alignment logic, that is when a write cycle is initiated by FML block at the
odd boundary (not the DWORD boundary), it reads only the lower 2 bit of the address (ties
them to 0), so that the application always writes at DWORD boundary, and manipulates the
byte-enables accordingly.
HCI slave block
The HCI slave block is the slave on HCI bus. This is basically an interface between OHCI
operational register internal to the Host Controller and the application. It updates the
registers on writes and provides the register data on reads. All the slave accesses should be
DWORD aligned. Therefore, byte enables are not used in slave accesses.
List processor block
The list processor block acts as a main controller of the entire controller. It has multiple state
machines to implement List Service Flow, List Priority, USB-States, ED, TD Service,
StatusWriteBack, TD Retirement, and so on as per the OHCI specification. Additionally, this
block implements a controller which interfaces with HCI_master and hsie, helping them in
the data transfer from system memory to USB and USB to system memory.
The following submodules are included:
●
USB states
●
List service flow
●
ED-TD block
●
HCI master interface logic
●
Data read write logic
RootHub and HSIE blocks
Since implementation varies, most of the functionality of the RootHub is implemented in the
Port Configuration Block. This logic is common to any user configuration. The logic in this
block acts as a wrapper around HSIE and interface with Host Controller’s List Processor,
FIFO and OHCI registers. This block also implements the control logic to synchronize the
interface between HSIE and port S/M.
This block implements the following submodules:
●
Reset_Resume
●
DPLL
●
HSIE
Digital PLL block (DPLL)
The function of the DPLL Block is to extract the clock and data information from the USB
Data received from the different transceiver. The Digital PLL runs on a 48 MHz userprovided clock to extract the clock information from the USB for both Full-Speed and Lowspeed data. The two signals D+ and D- of the USB lines are passed through a differential
receiver (external to the UHOSTC controller) and a NRZI formatted data is obtained from
the output of the differential receivers. The output of the differential receiver is then used by
the Digital PLL to extract clock information. The PLL Block also has a SE0 Detect Logic to
detect the Single Ended Zero (SE0) in the data stream. The circuit in this module extracts
114/368
Doc ID 022640 Rev 3
RM0319
USB 2.0 Host ports (UHC)
clock from either high-speed data or low-speed data indicated by SIE_Switch HCLK input
from SIETx State Machine.
HSIE functionality
The functionality of the Host Serial Interface Engine (HSIE) is to receive and transmit the
USB data over D+ and D- lines in accordance with the USB protocol. During the reception of
USB data, the D+ and D- signals are passed through the differential receiver (which is
external to the UHOSTC controller) to get a single ended bit stream that is passed through
the PLL Block to extract the clock and data information. The Clock and data are passed to
the SIE Block to identify the Sync Pattern and for NRZI-NRZ conversion. This NRZ data is
then passed through the Bit Stripper which strips off the excessive zeros inserted, The data
stream is initially passed through the PID Decode and checker to identify different PIDs.
Depending upon the type of PID, the HSIE block handles the protocol accordingly.
RootHub port configuration
The port configuration block implements part of the RootHub logic. This block is separated
from the main RootHub block to distinguish the logic that varies with design requirements. In
short, this block implements part of the OHCI registers that are specific to RootHub and a
state machine for every DownStreamPort to control the port functional states.
This block has the following submodules:
10.4
●
RootHub port registers
●
Port S/M
●
Port receive
●
Port resume
●
Port MUX
Interrupts
EHCI block generates one interrupt when the following conditions are occurred:
●
Interrupt on Async Address
●
Host System Error
●
Frame List Rollover
●
Port Change
●
USB Error
●
USB Interrupt
This interrupt is generated only when the corresponding bits of USBINTR register are
enabled. This interrupt is connected to IRQ26 of the CPU (Table 125: Interrupt requests).
Doc ID 022640 Rev 3
115/368
USB 2.0 Host ports (UHC)
RM0319
The OHCI block generates one interrupt when any of the following conditions occurs:
●
OwnershipChange
●
RootHubStatusChange
●
FrameNumberOverflow
●
UnrecoverableError
●
ResumeDetected
●
StartofFrame
●
WritebackDoneHead
●
SchedulingOverrun
This interrupt is generated only when the corresponding bits of the HcInterruptEnable
register are enabled. This interrupt is connected with IRQ25 for OHCI1 and IRQ27 for
OHCI2 respectively (Table 125: Interrupt requests)
116/368
Doc ID 022640 Rev 3
RM0319
11
USB 2.0 Device ports (UDC)
USB 2.0 Device ports (UDC)
This chapter focuses on USB Device functionality and operation.
For technical details about the programmable registers related to the USB Device, refer to
the USB Device registers in the following companion document:
●
11.1
RM0321: SPEAr320S address map and registers
Overview
In addition to single independent USB 2.0 Hosts, SPEAr320S provides a USB 2.0 Device
which is fully compliant with the Universal Serial Bus Specification (version 2.0), offering an
interface to the industry-standard AHB bus.
11.2
Main features
●
A PHY interface implementing a USB 2.0 transceiver macrocell interface (UTMI) fully
compliant with UTMI specification (version 1.05), to execute serialization and
deserialization of transmissions over the USB line.
●
Unidirectional/bidirectional 8-/16 bit UTMI data bus interfaces are supported.
●
A USB plug detect (UPD) which detects the connection of a device (detailed in
Section 11.4.7).
●
A USB Device controller (UDC) which is connected to the AHB bus and generates the
commands for the UTMI PHY. Hereafter the UDC along with AHB interface is referred
to UDC-AHB subsystem.
●
The UDC-AHB supports the 480 Mbps high-speed (HS) for USB 2.0, as well as the 12
Mbps full-speed (FS) for USB 1.1.
●
The UDC-AHB supports 16 physical endpoints (listed in Table 36), and proper
configurations to achieve logical endpoints.
●
Both DMA mode and slave-only mode supported (detailed in Section 11.4).
●
In DMA mode, the UDC-AHB supports descriptor-based memory structures in
application memory.
●
In both modes, an AHB slave is provided by UDC-AHB, acting as programming
interface to access to memory-mapped control and status registers (CSRs).
●
An AHB master for data transfer to system memory, supporting 8, 16, and 32 bit wide
data transactions on the AHB bus.
Doc ID 022640 Rev 3
117/368
USB 2.0 Device ports (UDC)
11.3
RM0319
Functional description
Figure 33 shows the block diagram of the UDC-AHB subsystem.
Figure 33. UDC-AHB subsystem block diagram within the USB 2.0 device
External RAM (IN Endpoints)
EP FIFO
CNTRL 1
WRITE Port
EP FIFO
CNTRL 2
AHB
Slave-only
Interface
EP FIFO
CNTRL N
SOF
Tracker
USB 2.0
UTMI
UDC
UTU
DMA
USB 1.1
Transceiver
Control &
Status
Registers
Interrupt
Manage
r
CSR Slave
Access
AMBA High Performance Bus(AHB)
READ Port
Receive FIFO
Controller(s)
Interrupt
WRITE Port
READ Port
External RAM (OUT Endpoints)
Figure 34. UDC_Device block diagram
USB_DEVICE
UDC_AHB
USB_PLUG_DETECT
IRQ24
to VIC
118/368
Doc ID 022640 Rev 3
System
Memory
AHB
Master
(ARM)
RM0319
11.3.1
USB 2.0 Device ports (UDC)
USB transaction layer interface (UTLI)
The USB transaction layer interface (UTLI) of the UDC-AHB subsystem interfaces with the
UDC and the FIFOs to handle data reception/transmission with a USB Host.
The main tasks of UTLI are:
●
Interfaces to the UDC,
●
Interfaces to endpoint-specific TxFIFOs (Section 11.3.6: Endpoint FIFO controller
(Transmit FIFO controller)) when transmitting data in response to in requests from USB
Host,
●
Interfaces to the common RxFIFO (Section 11.3.4: Receive FIFO controller) when
receiving out data from the USB Host,
●
Works with the CSRs block (Section 11.3.7: Control and status registers) to maintain
correct status and control,
●
Works with the interrupt manager block (Section 11.3.2: Interrupt manager) to generate
proper interrupts to the application,
●
Interfaces to the SOF tracker (Section 11.3.3: SOF tracker) to ensure that isochronous
data is transmitted in intended frame.
In particular, during data reception from a USB Host (that is, an out transaction), the UTLI
directly read incoming data from the UDC and writes them to the receive FIFO
(Section 11.3.4: Receive FIFO controller). Besides, for data transmission to a USB Host
(that is, an in transaction), the UTLI reads data to be transmitted from relevant endpoint
FIFO (Section 11.3.6: Endpoint FIFO controller (Transmit FIFO controller)) and provides
them to UDC.
11.3.2
Interrupt manager
The interrupt manager block controls the generation of interrupts to the application. In
particular, exchanging information with the UTLI, an interrupt is issued by the interrupt
manager when any of the following device-level events occurs:
●
Reception of a SOF token from the USB Host,
●
Detection of a USB suspend,
●
Detection of a USB reset,
●
Completion of speed enumeration,
●
Reception of a Set Interface command (defined in USB specification),
●
Reception of a Set Configuration command (defined in USB specification).
In addition, the interrupt manager also triggers an interrupt when any of the following
endpoint-specific events occurs:
●
Reception of a request for in data,
●
Reception of an out data packet,
●
Reception of 8 bytes of SETUP data packet,
●
An application error resulting in an AHB error response.
The interrupt manager block maintains the device interrupt register and the device interrupt
mask register, which are mapped into the address space of the global control and status
registers (CSRs, Section 11.3.7: Control and status registers).
Interrupt (IRQ24) issued will be the OR of all active events defined above, plus the plug
detect interrupt.
Doc ID 022640 Rev 3
119/368
USB 2.0 Device ports (UDC)
11.3.3
RM0319
SOF tracker
The USB Host sends start-of-frame (SOF) packets to USB 2.0 device every 1 ms for fullspeed (FS) operation, and every 125 µs for high-speed (HS) operation. Each SOF token
represents the start of every frame (for FS) or micro-frame (for HS) respectively, in case of
isochronous (ISO) data synchronization.
The start-of-frame (SOF) tracker block within the UDC-AHB subsystem is intended to track
any incoming SOF packets from the USB Host. With this aim, the SOF tracker runs internal
frame counters according to the operation rate (that is, 1 ms for FS and 125 µs for HS).
When a SOF packet is received from the USB Host, the UDC gets the 11 bit frame number
from the packet, and gives it to the back end within a single clock pulse, indicating the
reception of a SOF token.
In contrast, if a missing SOF packet is detected, the SOF tracker generates an event that is
used by the ISO in FIFOs to clear residual data from the previous frame, whereas UDC-AHB
subsystem moves to the next frame to provide synchronization.
In order to provide backward-compatibility with the FS 1 ms frame of USB 1.1, in HS mode
the frame number is incremented by UDC once every eight 125 µs micro-frames only. As a
consequence, the SOF tracker module generates the correct 14 bit micro-frame number by
adding a 3 bit micro-frame counter (operated by the SOF tracker itself) to the 11 bit frame
number provided by the UDC.
11.3.4
Receive FIFO controller
All out endpoints (dedicated to transactions coming from the USB Host) share a common
receive FIFO (RxFIFO), which is managed by multiple receive FIFO controller. In particular,
the RxFIFO provides the UTLI with enough space to either accept the incoming packet from
the USB Host or send a NYET (UDC20 only) or a NAK handshake packet.
In particular, the RxFIFO consists of two individual FIFOs, one for the data and one for the
addresses. As depicted in Figure 35, the data FIFO is implemented as RAM, whereas the
address FIFO is implemented using registers. Each 32 bit wide entry in the address FIFO
corresponds to a received out packet, and it is associated to both the destination endpoint
number and a flag to distinguish regular data from the 8 bytes of SETUP data.
Note:
120/368
The total data FIFO size is 4KB. Out of the 37-bit wide data 32 bits are OUT/IN data and the
remaining 5 bits are status information. The maximum depth of the address RxFIFO is 4,
hence at a given time a maximum of 4 OUT packets can be accommodated simultaneously.
The depth of the data RXFIFO is limited to 2KB. So during simultaneous storing of 4 OUT
packets, each packet can not be more than 512 bytes. But if OUT packets are 1024 bytes in
size (maximum size) then only two OUT packets can be accommodated. Hence number of
OUT packets that can be accommodated is limited by the size of the OUT packets. The rest
of the data FIFO, for instance 2 KB (out of total of 4KB data FIFO) is used for TxFIFO.
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
Figure 35. RxFIFO implementation
37 bits wide
Addrss FIFO
(Implemented in Regiters)
Data
Packet 3
Address
Packet 2
Packet 1
32 bits wide
Data FIFO
(Implemented in RAM)
Upon receiving an out packet, UTLI strobes this data into the data FIFO (37 bit wide), and
the UDC sends a status bit indicating whether or not the data was received without errors. If
data reception was error-free, the UTLI confirms the data in the RxFIFO by writing the
relevant endpoint number and associated flag into the address FIFO. In contrast, if data was
received with errors, the receive FIFO controller rolls back the data FIFO pointers as if
nothing had been received.
Then, when an external AHB master tries to access the packet received for a particular out
endpoint, at first it must read the relevant endpoint status register to determine the number
of bytes to be transferred, before to start the appropriate AHB transfers with an appropriate
HSIZE (for instance, 32, 16 or 8).
Note:
Any attempt to write the RxFIFO via the AHB interface results in an AHB error.
The RxFIFO also requires a confirming signal when a packet is written to or read from it.
This confirmation is used by the receive FIFO controller to propagate pointer information
from one domain to another and to calculate different RxFIFO status signals.
Doc ID 022640 Rev 3
121/368
USB 2.0 Device ports (UDC)
11.3.5
Endpoints
Table 36.
Endpoints assignment
Endpoint number
Endpoint direction
Transfer type
0
IN/OUT
Control.
IN
Software configurable to:
Bulk
Interrupt
Isochronous.
OUT
Software configurable to:
Bulk
Interrupt
Isochronous.
1-3-5-7-9-11-13-15
2-4-6-8-10-12-14
11.3.6
RM0319
Endpoint FIFO controller (Transmit FIFO controller)
An endpoint FIFO controller block manages the FIFO of a specific in endpoint (dedicated to
transactions to the USB Host) supported by the UDC-AHB subsystem. In particular, each in
endpoint is associated to a Transmit FIFO (TxFIFO) which is mapped in external RAM, and
each TxFIFO is in charge of an endpoint FIFO controller.
Each endpoint FIFO controller maintains the write and read pointers to access the memory
where relevant TxFIFO is located. Besides, these controllers need both the base address
and the buffer size of each endpoint TxFIFO to implement adaptive buffer management.
This feature allows to tailor the size of each TxFIFO depending on specific buffering
requirements.
In particular, the base address of each TxFIFO results from the upper limit of the previous
TxFIFO which, in turn, depends on the buffer size set by the CSRs for this endpoint
(Endpoint buffer size and received packet frame number register). That is, the base address
of the TxFIFO associated to nth in endoint added to the size of the TxFIFO of the same nth in
endpoint represents the base address for the TxFIFO associated to the (n+1)th in endpoint.
Note:
Any attempt to read from TxFIFO via the AHB interface results in an AHB error.
Like receive FIFO controller, the transmit endpoint FIFO controller also requires a
confirmation signal indicating a successful transfer to TxFIFO. This confirmation signal
allows the controller to export the FIFO pointers to other domains.
11.3.7
Control and status registers
The control and status registers (CSRs) allow to exchange control information with the
application, as well as provide a means for the application to control the UDC-AHB
subsystem.
11.3.8
AHB slave-only interface
The AHB slave-only interface block is active only when the UDC-AHB subsystem is
configured as a slave on the AHB.
122/368
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
In this scenario, all endpoint TxFIFOs are mapped to the system memory, and the
application writes the data directly to the endpoint TxFIFOs. Similarly, the RxFIFO is also
mapped to the system memory, and the application reads directly from the RxFIFO.
11.3.9
DMA (AHB master interface)
Enabling the UDC-AHB Subsystem to become an AHB master (that is, entering the DMA
mode, Section 11.4.1: DMA mode), the DMA block receives the required data pointers from
the values programmed in the CSRs (Section 11.3.7: Control and status registers), and it
can transfer data with the system memory.
In particular, the DMA supports a true scatter/gather memory distribution, where each
endpoint memory structure is implemented as a linked-list (as detailed in Section 11.4.1:
DMA mode).
The DMA block (which is inactive in slave-only mode) consists of three basic components:
11.3.10
●
The DMA transfer engine, which moves the actual data,
●
The DMA controller, which controls the movement of the data,
●
The AHB interface, which manages the flow of data between the DMA and AHB for
both data transfer and CSRs accesses.
DMA transfer engine
The DMA transfer engine is a slave to the DMA by the DMA controller for the actual data
transfer to and from system memory.
In case of a memory access, the DMA transfer engine interfaces with the FIFOs and the
AHB interface module of DMA, and indicates to the DMA whether or not the transfer was
successful. If the data transfer was unsuccessful, the DMA transfer engine also indicates
how many bytes were successfully transferred to the destination, so that the DMA can
decide whether to retry the transaction.
In case of data transfer from the FIFOs to system memory, the DMA transfer engine
depends on status signals from the FIFOs’ respective FIFO controllers. In case of
transferring the data to system memory, the DMA transfer engine registers the data, then
waits for the request from the DMA controller and decides on the direction of the transfer. It
completes the transfer whether the transaction is completed successfully or if there is an
error during the data transfer.
11.3.11
DMA controller
The DMA controller is in charge of all data exchange between FIFOs and system memory.
Specifically, the DMA controller actually consists of two distinct controllers with the aim to
manage both in (transmit) and out (receive) transactions simultaneously, although transmit
and receive functions cannot be performed simultaneously.
From a functional perspective, the DMA controller parses the descriptor structures and then
commands the other subsystem blocks to perform data transfers accordingly. The
descriptors fetched from memory are stored by the DMA controller in a proper descriptors
buffer.
Doc ID 022640 Rev 3
123/368
USB 2.0 Device ports (UDC)
11.3.12
RM0319
AHB interface
This block contains all the subsystem’s AHB protocol logic. In particular, the AHB interface
has two functional states where it is able to act:
●
As an AHB slave, when the application programs the CSRs of either the UDC-AHB
Subsystem or the UDC (Section 11.3.8),
●
As an AHB master, when the DMA performs data transfers.
Acting as AHB master, the UDC-AHB subsystem accesses the application memory for
descriptors and data buffers. When the subsystem is in slave-only mode, the AHB interface
also acts as a slave. In this mode, all the FIFOs are memory-mapped, and the application
writes directly to the FIFOs.
11.3.13
CSRs slave access
The CSRs slave access block is active in DMA mode only (Section 11.4.1: DMA mode) and,
acting as an AHB slave, it responds to any CSRs access from the application (which acts as
an AHB master).
In DMA mode CSR registers are accessible through CSR slave access block as this time
AHB slave only block is de-activated. This AHB slave only block is activated only in slave
mode.
11.4
Operation
The UDC-AHB Subsystem supports two distinct operation modes:
●
DMA mode (detailed in Section 11.4.1), a DMA-based implementation where the UDCAHB Subsystem acts as an AHB master for data transfers.
●
Slave-only mode (detailed in Section 11.4.2), where the UDC-AHB Subsystem is
slaved to the application and any application AHB master reads data from, or writes
data to the memory-mapped FIFOs provided by the device.
In both modes, all data transfers are interrupt-driven.
11.4.1
DMA mode
In general, a major advantage of DMA-based implementations is that they spare the main
processor’s computing power from involvement in data transfer tasks. Moreover, use of a
scatter-gather DMA helps applications to make efficient and optimal use of system memory,
which is indeed a major design constraint on portable systems.
Specifically, in DMA mode, the UDC-AHB subsystem implements a true scatter-gather
memory distribution, in which memory structures are scattered over the system memory. As
illustrated in Figure 36, each in/out endpoint memory structure is implemented as a linkedlist, where each element of the list is a data buffer of a predefined size.
In addition to data (both in and out), each buffer also has a status quadlet and a pointer to
the next buffer. The last element of such a linked list can point either to a null pointer or, if
the linked list is implemented as a ring buffer, to the first element of the list. Data buffer
structure for both in and out endpoint is described in RM0321: SPEAr320S address map
and registers reference manual.
124/368
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
Besides, all control endpoints implement an additional 16-byte buffer to store SETUP data.
The SETUP data structure (detailed in RM0321: SPEAr320S address map and registers)
does not implement a linked-list structure.
Figure 36. Linked-list memory structure in DMA mode
Setup Buffer
Pointer
Setup buffer Status Quadlet
R
Data
Data
IN Data Descriptor
Pointer
In buffer Status Quadlet
R
Next Pointer
OUT Data
Descriptor Pointer
Buffer
OUT buffer Status Quadlet
R
Next Pointer
Buffer
In buffer Status Quadlet
R
Next Pointer
Next Pointer
Buffer
In buffer Status Quadlet
R
Next Pointer
OUT buffer Status Quadlet
R
Buffer
OUT buffer Status Quadlet
R
Buffer
Next Pointer
Buffer
In DMA mode, before starting any action, the application must both initialize the buffer
descriptor chains in the DMA data memory structure for all active endpoints of the UDCAHB subsystem, and configure the required CSRs during the USB reset.
A brief description of both in and out operation in DMA mode.
11.4.2
In operation (Data transfer To USB Host)
If the UDC-AHB subsystem receives an in token from a USB Host for a non-isochronous
endpoint (such as, bulk, interrupt or control), it checks the corresponding TxFIFO for data
availability. If data is available, the TxFIFO is read and the data is provided to the UDC for
transfer to USB Host. In contrast, if the TxFIFO is empty (no data), the UDC-AHB
subsystem sends an interrupt to the application and the UDC sends a NAK handshake to
the USB Host connected to that endpoint.
On receiving the interrupt, at first the application probes the endpoint interrupt register, to
determine which endpoint has requested the interrupt. Having determined this endpoint,
then the application probes the endpoint status register, to determine the interrupt’s cause.
Upon notification that this is an in token for a particular endpoint, the application updates the
addressed endpoint’s system memory buffer with data. Besides, the application reports to
the DMA the availability of such data by setting the poll demand bit in the subsystem’s
CSRs.
Note:
Each endpoint has a dedicated poll demand bit within CSRs, specifically in the endpointspecific endpoint control register.
Doc ID 022640 Rev 3
125/368
USB 2.0 Device ports (UDC)
RM0319
Now the DMA transfers the data from the system memory to the relevant endpoint FIFO. As
shown in Figure 36, these endpoint buffers are RAM-based implementations with
programmable sizes. When the USB Host retries with another in token, the UDC-AHB
subsystem provides the data to the UDC reading the endpoint buffers for transmission to
USB Host. When the transmission is complete, the status is written back into the buffer
descriptor’s status quadlet. Then, the subsystem clears the endpoint-specific poll demand
bit once the descriptor chain reaches the last descriptor.
Note:
The application can read the poll demand bit to determine if the descriptor chain is serviced
or not.
In transfers with ISO, endpoints are handled similarly. In this case, the transfer of in data
from the application memory to the endpoint FIFO is not initiated by request tokens from the
USB Host, but the application sets the poll demand bit of CSR as soon as data is available.
At the following bit setting, the UDC-AHB subsystem tags data for isochronous endpoints
with a frame number. The UDC, which maintains the frame counter, sends the isochronous
data in the intended frame, whereas the SOF tracker module (SOF tracker on page 120)
tracks the incoming SOFs and their frame numbers. Three distinct scenarios can be raised
up:
●
if the incoming frame number matches the frame number in the buffer, the UDC is
allowed to transfer the frame from the appropriate data buffer.
●
if the frame number in the SOF is greater than the frame number in the frame counter
of UDC, the DMA module skips the buffers to align to the correct frame number.
●
if the frame number in the SOF is less than the subsystem’s frame number, the DMA
waits for a few frames to align to the correct frame number.
Hooks are provided for the application to flush the subsystem’s FIFOs in case of missing
SOFs. The transaction flow of in data from the USB Host to the application memory is given
in Figure 37.
126/368
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
Figure 37. In transaction flow in DMA mode
Idle
Idle
IN
Transaction
Poll demand
Data
available?
No
Generate INTR
and NAK
Transfer data
From memory to
TxFIFO
Yes
TxFIFO
Availabe?
Yes
No
Read the
TxFIFO &Provide
IN data
Packet
Completely
Transferred?
Transfer done
Yes
No
Service other IN
requests and
return when done
Update Descriptor
Status
Wait for Status
from USB host
Got ACK
Status?
Yes
No
Rewined
READ pointer
11.4.3
Out operation (Data transfer from USB Host)
In the out direction, as soon as the UDC-AHB subsystem receives an out (or SETUP) data
from the USB Host (that is, when a packet of data is completed or - if thresholding is enabled
- a threshold is reached), it transfers the data to the buffers allocated to the endpoint in
application memory. Once the data is transferred, the subsystem updates the status of the
received data to the buffer’s status quadlet.
SETUP data is transferred to a 16-byte SETUP buffer. The pointer for this buffer is indicated
in the Endpoint setup buffer pointer register). Out data is transferred to the buffers indicated
by the descriptor, and the pointer for these descriptors is programmed in the CSRs.
Note:
The SETUP data directly addresses the buffers, while regular out data addresses the out
data buffers indirectly.
The transaction flow for all out endpoints is similar. The only difference is that isochronous
(iso-out) data is tagged with the frame number when the packet is received.
The transaction flow of out data from the USB Host to the application memory is given in
Figure 38.
Doc ID 022640 Rev 3
127/368
USB 2.0 Device ports (UDC)
RM0319
Figure 38. Out transaction flow in DMA mode
Idle
Ye
s
OUT
Transaction
RxFIFO
available?
No
ISO
Transfer?
No
Send
NAK
Yes
Write the OUT
Data in the
RxFIFO
Update
descriptor
status and
generate INTR
Wait for
Status
No
DMA
Enabled?
Got Status
Flush the
data
No
Success
or ISO
Yes
Yes
Confirm
data
Get
Descriptor
Generate
BNA INTR
Transfer
done
No
Buffer
Initialized?
Yes
Transfer
OUT data To
host memory
High-bandwidth isochronous (ISO) transfers
In case of out packets (that is, coming from USB Host), each descriptor stores one
maximum packet size of data. The data PID associated with the packet is available in the
PID field, bits [15:14], of the out data memory buffer status (OUT data memory structure on
page 133). If the microframe contains three packets, data and the corresponding data PID
are stored in three descriptors.
In case of in packets (transmitted to the USB Host), the application creates data of one
maximum packet size per descriptor. If the application must send three packets in the
microframe, the application must then create three descriptors. Data PID information must
be provided in the PID field, bits [15:14], of the in data memory buffer (IN data memory
structure on page 135).
11.4.4
Slave-only mode
In slave-only implementation, the application acts as an AHB master to read data from or to
write data to the memory-mapped subsystem FIFOs, and the UDC-AHB subsystem
operates as an AHB slave for both data and CSRs transfers.
The USB Host initiates USB traffic and the application responds to all the USB Host’s
commands. In this mode, the UDC-AHB subsystem can only be used in device-type
applications, and before any operation the application must completely configure the
necessary CSRs. All data transfers are interrupt-driven, except iso-in and interrupt-in
transfers, which are periodic.
The slave-only mode is typically implemented either in applications with limited complexity
software, or when the subsystem has a dedicated master for data processing.
128/368
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
In operation (Data transfer to USB Host)
If the UDC-AHB subsystem receives an in token from a USB Host for a non-isochronous
endpoint (such as, bulk, interrupt or control), it checks the associated TxFIFO (Endpoint
FIFO controller (Transmit FIFO controller) on page 122) for data availability. If data is
available, the UDC reads the data from the TxFIFO, otherwise if the TxFIFO does not
contain data, the UDC sends an interrupt to the application, and the USB Host retries the in
token.
Upon receiving the interrupt, at first the application reads the endpoint interrupt register to
determine which endpoint requested the interrupt, and then probes the endpoint status
register to determine the interrupt’s cause.
Once the application determines that an in token for the endpoint requested the interrupt, it
writes the packet directly to the address where the associated TxFIFO is mapped. As soon
as the packet data has been completely written into the FIFO, the application performs then
a single write to a predefined address (pointed by the write confirmation register, of the
relevant in endpoint) indicating to the subsystem that the packet transfer is done.
When the USB Host retries the in token, the subsystem provides the associated endpoint
TxFIFO data to the UDC for transmission to the USB Host. The sequence of these events
for a non-isochronous (interrupt, bulk, or control) endpoint is shown in Figure 39.
Note:
The application does not receive status update regarding the packet, because the
subsystem must transmit this data. However, the application may flush the packet from the
relevant TxFIFO by setting the F bit in the endpoint control register.
Doc ID 022640 Rev 3
129/368
USB 2.0 Device ports (UDC)
RM0319
Figure 39. In transaction flow in slave-only mode
Idle
Idle
IN
Transaction
TxFIFO write
Data
available?
No
Generate INTR
and NAK
TxFIFO
available?
No
Retry
Yes
Yes
Read the
TxFIFO &Provide
IN data
Write data
To TxFIFO
Yes
TxFIFO full?
Transfer done
No
Confirm Packet
in TxFIFO
Wait for Status
Yes
Status = ACK?
No
Rewined READ
pointer
Isochronous-in endpoints are handled similarly. In this case, the transfer of in data from the
application memory to the endpoint FIFO is not initiated by USB Host request tokens, but by
the application filling the TxFIFOs as soon as data is available. Isochronous endpoint data
must be filled in the TxFIFO only if the buffer is set for the current frame, which the
application can determine by reading the current active frame number from the CSR.
Out operation (Data transfer from USB Host)
When the UDC-AHB subsystem receives out data from the USB Host, it transfers the data
to the receive FIFO (RxFIFO) within the subsystem - if it has space available for the packet . If no space is available, the packet is retried. SETUP out packets are stored in a temporary
subsystem register before being loaded to the receive FIFO.
Once the packet is transferred to the RxFIFO, the subsystem sends an interrupt to the
application for the received packet. Then, the application reads the addressed endpoint’s
interrupt and status registers and the endpoint status register) and it is able to determine the
number of bytes received by the UDC-AHB Subsystem in the packet. After that, the
application reads from the RxFIFO this number of bytes.
Note:
130/368
The application reads from the address where the RxFIFO is mapped. The transaction flow
of out data from the USB Host to the application is shown in Figure 40.
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
Figure 40. Out transaction flow in slave-only mode
Idle
Idle
OUT
Transaction
Read data from
RxFIFO
No
RxFIFO
available?
Send NAK
(for non-ISO)
Yes
Excess
read?
Yes
Assert error
No
Write the OUT
Data in the
RxFIFO
Transfer done
Wait for Status
Got Status
No
Flush data
Yes
Status=Success
or ISO?
Confirm data &
Generate INTR
High-bandwidth isochronous (ISO) transfers
In outcase of out packets (that is, coming from USB Host), the data PID received for a highbandwidth transaction is available in the Endpoint buffer size (in) and received packet frame
number register (out), specifically in the ISO PID field (bit [17:16]).
This 2 bit field indicates the data PID for the current packet available in the receive FIFO. For
example, if the USB Host sends three packets with a PID sequence of MDATA and DATA2,
when the application receives the interrupt for the first packet, the ISO PID field of the
register indicates an MDATA PID (2‘b11). After the application reads out the first two
maximum-size packets, this register will indicate DATA2 (2‘b10).
In case of in packets (that is, transmitted to the USB Host), the transfer is described by the
following example flow:
●
At first, write the initial data PID (bit [17:16]) in the endpoint buffer size in the Endpoint
buffer size and received packet frame number register. For example, to send three
packets in a microframe, write 2’b11 to the ISO PID field (in).
●
Write the data one maximum-size packet at a time. After writing one maximum-size
packet, perform a confirm cycle.
●
Wait for the UDC-AHB subsystem to send the iso in done interrupt, setting the iso in
done (bit [23]) field in the endpoint status register after the entire high-bandwidth
transaction is completed on the USB.
●
To change the packet number to be sent in the next microframe, the application can
now modify the iso pid (in) field in the endpoint buffer size in the Endpoint buffer size
and received packet frame number register.
Doc ID 022640 Rev 3
131/368
USB 2.0 Device ports (UDC)
11.4.5
RM0319
Data memory structure in DMA mode
SETUP data memory structure
The memory structure for SETUP data is given in Figure 41. The 16-byte buffer consists of 4
fields of 32 bits each: the status quadlet (its bit assignments are given in Table 37), a
reserved one and the 2 last fields for the 8 bytes of SETUP data.
Figure 41. SETUP data memory
31
0
Status Quadlet
Setup Buffer Pointer
Reserved
First 4 Bytes of Setup Data
Second 4 Bytes of Setup Data
Status Quadlet
31:30
BS
Table 37.
Bit
Rx Sts
27:16
15:0
Config Sts
R
SETUP data memory: status quadlet bit assignments
Name
Description
BS
Buffer status.
This 2 bit field reports the status of the SETUP data buffer, according to
encoding:
– 2‘b00 Host ready. = The descriptor is available to be processed by DMA.
– 2‘b01 DMA busy. = The DMA is still processing the descriptor.
– 2‘b10 DMA done. = Buffer data transfer completed by DMA.
– 2‘b11 Host busy. = The application is processing the descriptor.
[29:28]
Rx Sts
Receive status.
This 2 bit field reports the status of the received SETUP data (according to
encoding), reflecting whether the SETUP data has been correctly received or
some errors occurred:
– 2‘b00 = Success.
– 2‘b01 = DESERR (descriptor transfer error).
– 2‘b10 = Reserved.
– 2‘b11 = BUFFER (data transfer error).
[27:16]
Configuration status.
This 12 bit field echoes the status of the current configuration associated
with the SETUP packet for a control endpoint. Bits assignments for this field
Config Sts are given:
– [27:24] = Configuration number.
– [23:20] = Interface number.
– [19:16] = Alternate setting number.
[15:00]
Reserved
[31:30]
132/368
29:28
Read: undefined. Write: should be zero.
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
OUT data memory structure
All endpoints that support out direction transactions (that is, endpoints receiving data from
the USB Host) must implement a memory structure according to the following
characteristics:
●
Each data buffer must have an associated descriptor which provides the status of the
buffer. Indeed, the buffer itself contains only raw data.
●
Each buffer descriptor is 4-quadlet length.
The out data memory structure is given in Figure 42. Table 38 reports the bits assignments
for out buffer status quadlet.
If the buffer status of the first descriptor is set to host ready (see BS field in Table 38), the
DMA fetches and processes its data buffer. Otherwise, the DMA skips to the next descriptor
until it reaches the end of the descriptor chain.
Figure 42. Out data memory
31
0
OUT Buffer Status Quadlet
Data Descriptor Pointer
Reserved
Buffer Pointer
Next Descriptor Pointer
Status Quadlet for
Non Iso-chronous OUT
31:30
BS
29:28
27
Rx Sts
L
29:28
27
Rx Sts
L
26:16
15:0
RxBytes
R
Status Quadlet for
Iso-chronous OUT
31:30
BS
26:16
Frame Number
Doc ID 022640 Rev 3
15:14
PID
13:0
RxBytes
133/368
USB 2.0 Device ports (UDC)
Table 38.
Bit
Out data memory: buffer status quadlet bit assignments (for NonIsochronous OUT)
Name
Description
BS
Buffer status.
This 2 bit field reports the status of the out buffer, according to encoding:
– 2'b00 Host ready. = The descriptor is available to be processed by DMA.
– 2'b01 DMA busy. = The DMA is still processing the descriptor.
– 2'b10 DMA done. = Buffer data transfer completed by DMA.
– 2'b11 Host busy. = The application is processing the descriptor.
[29:28]
Rx Sts
Receive status.
This 2 bit field reports the status of the received out data (according to
encoding), reflecting whether the out data has been correctly received or
some errors occurred:
– 2'b00 = Success.
– 2'b01 = DESERR (descriptor transfer error).
– 2'b10 = Reserved.
– 2'b11 = BUFFER (data transfer error).
Note: In particular, a DESERR receive status indicates that the out buffer
status is something other than Host ready (that is, BS not equal to 2’b00)
during descriptor fetch.
[27]
L
If set, it indicates that this descriptor is the last one of the chain.
[26:16]
Reserved
(Non ISO)
Read: undefined. Write: should be zero.
[15:00]
Rx Bytes
(Non ISO)
Received number of bytes.
Its 16 bit width allows values ranging from 0 to 64 kbytes, depending on
the packet size of data received from the USB Host.
[31:30]
134/368
RM0319
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
Table 39.
Bit
Out data memory: buffer status quadlet bit assignments (for Isochronous
OUT)
Name
Description
BS
Buffer status.
This 2 bit field reports the status of the out buffer, according to encoding:
– 2'b00 Host ready. = The descriptor is available to be processed by DMA.
– 2’b01 DMA busy. = The DMA is still processing the descriptor.
– 2'b10 DMA done. = Buffer data transfer completed by DMA.
– 2’b11 Host busy. = The application is processing the descriptor.
[29:28]
Rx Sts
Receive status.
This 2 bit field reports the status of the received out data (according to
encoding), reflecting whether the out data has been correctly received or
some errors occurred:
– 2'b00 = Success.
– 2’b01 = DESERR (descriptor transfer error).
– 2'b10 = Reserved.
– 2’b11 = BUFFER (data transfer error).
Note: In particular, a DESERR receive status indicates that the out buffer
status is something other than Host ready (that is, BS not equal to 'b00)
during descriptor fetch.
[27]
L
If set, it indicates that this descriptor is the last one of the chain.
[26:16]
Frame
Number
11 bit frame number in which the current iso-out packet is received.
[15:14]
PID
ISO received data PID.
This 2 bit field indicates the data PID (according to encoding) for the
received ISO packet which is contained in the descriptor:
– 2’b00 = DATA0
– 2'b01 = DATA1
– 2'b10 = DATA2
– 2'b11 = MDATA
Note: The PID field is for HS ISO transactions only. For FS ISO transactions,
this field is don't care.
[13:00]
Rx Bytes
Received number of bytes.
The value of this field gives the received number of bytes.
[31:30]
IN data memory structure
All endpoints that support in direction transactions (that is, endpoints transmitting data to the
USB Host) must implement the memory structure given in Figure 43, where each in buffer
must be associated to a descriptor. Table 40 reports the bits assignments for in buffer status
quadlet.
The application fills the data buffer, then updates its status in the descriptor, and sets the
poll demand bit. Besides, the DMA fetches this descriptor and processes it, moving on in
this fashion until it reaches the end of the descriptor chain.
Doc ID 022640 Rev 3
135/368
USB 2.0 Device ports (UDC)
RM0319
Figure 43. In data memory
31
0
IN Buffer Status Quadlet
Data Descriptor Pointer
Reserved
Buffer Pointer
Next Descriptor Pointer
Status Quadlet for
Non Iso-chronous IN
31:30
BS
29:28
27
Tx Sts
L
29:28
27
Tx Sts
L
26:16
15:0
TxBytes
R
Status Quadlet for
Iso-chronous IN
31:30
BS
Table 40.
Bit
Frame Number
15:14
PID
13:0
TxBytes
In data memory: buffer status quadlet bit assignments (for nonisochronous IN)
Name
Description
BS
Buffer status.
This 2 bit field reports the status of the in buffer, according to encoding:
– 2’b00, Host ready. The descriptor is available to be processed by DMA.
– 2'b01, DMA busy. The DMA is still processing the descriptor.
– 2'b10, DMA done. Buffer data transfer completed by DMA.
– 2'b11, Host busy. The application is processing the descriptor.
[29:28]
Tx Sts
Transmit status.
This 2 bit field reports the status of the transmitted in data (according to
encoding), reflecting whether the in data has been correctly transmitted or
some errors occurred:
– 2'b00 = Success.
– 2'b01 = DESERR (descriptor transfer error).
– 2'b10 = Reserved.
– 2'b11 = BUFFER (data transfer error).
[27]
L
If set, it indicates that this descriptor is the last one of the chain.
[26:16]
Reserved
Read: undefined. Write: should be zero.
Tx Bytes
Number of bytes to be transmitted.
Its 16 bit width allows values ranging from 0 to 64 kbytes. for iso in
transactions, a maximum value of 16 kbytes is allowed by the 14 bit length
of the Tx bytes field.
[31:30]
[15:00]
136/368
26:16
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
Table 41.
Bit
In data memory:buffer status quadlet bit assignments (for isochronous)
Name
Description
BS
Buffer status.
This 2 bit field reports the status of the in buffer, according to encoding:
– 2‘b00, Host ready. The descriptor is available to be processed by DMA.
– 2‘b01, DMA busy. The DMA is still processing the descriptor.
– 2‘b10, DMA done. Buffer data transfer completed by DMA.
– 2‘b11, Host busy. The application is processing the descriptor.
[29:28]
Tx Sts
Transmit status.
This 2 bit field reports the status of the transmitted in data (according to
encoding), reflecting whether the in data has been correctly transmitted
or some errors occurred:
– 2‘b00 = Success.
– 2‘b01 = DESERR (descriptor transfer error).
– 2‘b10 = Reserved.
– 2‘b11 = BUFFER (data transfer error).
[27]
L
If set, it indicates that this descriptor is the last one of the chain.
[26:16]
11-bsit frame number in which the current iso-out packet is transmitted.
This 11 bit field gives the frame number in which the current iso-in packet
Frame
is transmitted, according to the following bits assignments:
Number (ISO)
[26:19] = Millisecond frame number.
[18:16] = Micro-frame number.
[31:30]
[15:14]
[13:00]
PID
Number of packets per microframe.
This 2 bit field indicates the number of packets per microframe for
isochronous (iso) in transfers during high-speed (hs) operation. The
application must program these bits in the descriptor (and they must be
the same for all descriptors of the same microframe) according to
encoding, such that the subsystem core returns an isochronous packet
with an appropriate data PID per frame:
– 2‘b00 = 1
– 2‘b01 = 1
– 2‘b10 = 2
– 2‘b11 = 3
Note: The PID field is for HS ISO transactions only. For FS ISO
transactions, this field is reserved.
Tx Bytes
(ISO)
Number of bytes to be transmitted.
The value of this field gives the number of bytes to be transmitted to USB
Host. In case of non-iso in, its 16 bit length allows values ranging from 0
to 64 kbytes. for iso in transactions, a maximum value of 16 kbytes is
allowed by the 14 bit length of the Tx bytes field.
Doc ID 022640 Rev 3
137/368
USB 2.0 Device ports (UDC)
11.4.6
RM0319
Operation modes in DMA mode
Packet-per-buffer mode
In packet-per-buffer mode (alternate to buffer fill mode, Buffer fill mode (OUT) on page 138),
the DMA transfers packet by packet to various addresses as indicated by the descriptor,
implementing then a true scatter-gather mechanism.
A descriptor update can happen either at the end of each packet transfer or at the end of the
descriptor chain only. As a results, the application may be interrupted either after processing
each descriptor or at the end of a descriptor chain, respectively. In particular, setting to 1‘b1
the DU bit of the global CSRs Device control register, it enables descriptor updating and
application interrupt to the software at the end of each packet.
Buffer fill mode (OUT)
Enabling the buffer fill mode (setting the bit BF in the global CSRs Device control register,
the DMA transfers all packets to the large buffer whose address is indicated by the single
out data memory structure descriptor. This DMA mode of operation requires fewer memory
accesses than packet-per-buffer with descriptor update mode Packet-per-buffer mode on
page 138 above, increasing the throughput.
The DMA controller updates buffer status when a short packet is received, and
simultaneously sends an interrupt to the application.
Buffer fill mode (IN)
In case of in transactions, the DMA buffer fill mode can be entered by using the packet-perbuffer mode with only one descriptor indicating:
●
The system memory starting address,
●
The number of bytes to be transferred to the USB Host (the tx bytes can be greater
than one packet),
●
The L bit set in the status quadlet.
The DMA controller updates buffer status after all data has been transferred to the TxFIFO.
The UDC-AHB subsystem then sends an interrupt to the application.
Threshold enable
The threshold enable feature is used for transferring packets in the out direction for DMA
operation only. There is no threshold enable for the in direction.
Note:
In this context, thresholding means emptying the out RxFIFO as soon as it receives a
certain number (the threshold value) of 32 bit words.
Thresholding is enabled by setting to 1‘b1 the THE bit in the global CSRs Device control
register. Moreover, the threshold value is programmed by setting the THLEN 8 bit in the
same device control register. As mentioned, the threshold value is the number of 32 bit
words (quadlets) that must be received by the RxFIFO before the DMA can start the
transfer.
When thresholding is disabled (bit THE set to 1‘b0), then the DMA waits for the complete
packet before starting the data transfer. In contrast, if thresholding is enabled, the transfer of
the packet to host memory starts before the validity of the packet is assessed. If the packet
is found to be corrupt at the end of the transfer, the descriptor is not updated and the next
138/368
Doc ID 022640 Rev 3
RM0319
USB 2.0 Device ports (UDC)
clean packet overwrites the previous corrupted one. This conceals the USB error from the
application.
Burst split enable
When burst split is enabled, all AHB transfers (from the DMA to system memory and from
system memory to the TxFIFO) are splitted into bursts of a specified length.
The burst split is enabled by setting to 1‘b1 the BREN bit in the global CSRs’ Device control
register. Moreover, the burst length value is programmed by setting the BRLEN 8 bit in the
same device control register. As mentioned, this value indicates the number of 32 bit
transfers that should happen in a single burst.
Note:
When thresholding and burst splitting are both enabled, the threshold length (THLEN)
should be either greater than multiples of burst length (BRLEN) or equal to BRLEN.
11.4.7
USB plug detect
The USB plug detect block (UPD) allows to detect when a USB Host is either connected or
disconnected to the USB 2.0 device. This is done through the VBUS pad which is driven
high when the USB Host is attached. In particular, a plug interrupt is raised by the UPD
block when the USB Host is attached/detached. This interrupt is putted in OR with the
output of the Interrupt Manager block and the output of he OR logic goes to the VIC block.
Two 32 bit RW registers are associated to the UPD block, namely the plug status register
and the plug pending register, whose bit assignments are given in Table 42 and Table 43,
respectively. These registers can be accessed at the base address 0xE1200000
As soon as the USB Host is connected to the device, the VBUS signal goes high enabling
the UPD internal counter, which generates an interrupt 10 ms after the connection. The
software routine handling the interrupt reads as 1‘b1 the intpend field of the plug pending
register (Table 43), and as 1‘b1 the state field of the plug status register (Table 42): the USB
2.0 PHY reset is then released (phy_rst set to 1‘b0 in plug status register) and the USB 2.0
PHY is placed in normal mode (phy_mode set to 1‘b0 in plug status register).
In contrast, when the USB Host is detached, the VBUS signal goes low and after 10 ms an
interrupt is generated by the UPD block (intpend field set to 1‘b1 in plug pending register).
Then, the interrupt handler reads as 1‘b0 the state field of the plug status register, so the
reset is asserted (phy_rst set to 1‘b1 in Plug Status register) and the USB 2.0 PHY is placed
in non-driving state (phy_mode set to 1‘b1 in plug status register).
Table 42.
Plug status register bit assignments
Bit
Name
Reset value Description
[31:04]
Reserved
-
Read: undefined. Write: should be zero.
1’h1
USB PHY mode.
This bit allows to set the physical terminations of PHY,
according to encoding:
1‘b0 = Normal (UDC is allowed to drive the USB 2.0
PHY).
1‘b1 = Tri-state (the USB 2.0 PHY is in non-driving
mode).
[03]
phy_mode
Doc ID 022640 Rev 3
139/368
USB 2.0 Device ports (UDC)
Table 42.
Plug status register bit assignments (continued)
Bit
Name
Reset value Description
[02]
phy_rst
1’h1
USB PHY reset.
If set, this bit indicates that the USB PHY is in reset
mode, otherwise it is in normal mode.
[01]
state
1’h0
USB Host connection state.
This RO bit reports the connection status of the USB
Host, according to encoding:
1‘b0 = Disconnected.
1‘b1 = Connection detected.
[00]
enable
1’h0
Plug interrupt.
If set, this bit enables an interrupt to be raised when
the USB Host is attached/detached.
Table 43.
140/368
RM0319
Plug pending register bit assignments
Bit
Name
Reset value Description
[31:01]
Reserved
-
Read: undefined. Write: should be zero.
[00]
intpend
1’h0
Plug interrupt.
This bit is set when the UPD block generates a plug
interrupt. It is cleared when the CPU reads it.
Doc ID 022640 Rev 3
RM0319
12
Fast Ethernet port (MII0)
Fast Ethernet port (MII0)
This chapter focuses on MII0 functionality and operation.
For technical details about the programmable registers related to the MII, refer to the MII
registers in the following companion document:
●
12.1
RM0321: SPEAr320S address map and registers
Overview
The MII0 controller is an Ethernet MAC 10/100 able to transmit and receive data over
Ethernet in compliance with the IEEE 802.3-2002 standard.
MII0 is configured to offer an AHB-interfaced native DMA (also referred as MAC-AHB) over
a MAC core. The MAC-AHB allows data transfer by DMA with system memory through the
AHB interface.
12.2
Main features
●
Supports the default Media Independent Interface (MII) defined in the IEEE 802.3
specifications.
●
Supports 10/100 Mbps data transfer rates with the PHY interfaces above.
●
Supports both half-duplex and full-duplex operation. In half-duplex operation,
CSMA/CD protocol is provided.
●
Programmable frame length to support both standard and Jumbo Ethernet frames with
size up to 16 Kbytes
●
A variety of flexible address filtering modes supported
●
A set of control and status registers (CSRs) to control MAC Core operation
●
Complete network statistics with RMON Counters (MMC, MAC Management Counters)
MAC-AHB main features
●
DMA implements dual-buffer (ring) or linked-list (chained) descriptor chaining.
●
A set of CSRs to control DMA operation
●
An AHB slave acting as programming interface to access all CSRs, for both DMA and
MAC Core subsystems
●
An AHB master for data transfer to system memory
●
It support both big-endian and little-endian
●
Power management module (PMT) with remote wake-up and magic packet frame
processing options
Doc ID 022640 Rev 3
141/368
Fast Ethernet port (MII0)
12.3
RM0319
Functional description
Figure 44 shows the system-level block diagram of MII0.
Figure 44. MII0 system-level block diagram
AHB
Master
Interface
DMA
TxFIFO
(Mem)
RxFIFO
(Mem)
TxFC
RxFC
MAC
DMA
CSR
AHB
Slave
Interface
MAC-DMA
OMR
Register
MAC-MTL
MAC
CSR
MAC-CORE
MAC-AHB
12.3.1
AHB slave interface
The AHB Slave Interface block allows the host CPU to access all the DMA and MAC control
and status registers (CSRs).
32-/16- and 8-bit write/read transfers to CSRs are all supported by AHB Slave Interface, but
32-bit access to CSRs are recommended to avoid any software synchronization problems.
12.3.2
AHB master interface
The MII0 transfers data by DMA to system memory through the AHB master interface.
In particular, the AHB master interfaces with the DMA controller and converts the internal
DMA request cycles into AHB cycles. Both fixed burst length (SINGLE, INCR4, INCR8,
INCR16) and unspecified burst length (SINGLE, INCR) transfer types are supported.
Note:
142/368
1
The DMA controller should request an AHB Burst Read transfer only when it has the
capability of accepting the received burst data completely. Indeed, data read from AHB is
always pushed into the DMA without any delay.
2
The DMA controller should request an AHB Burst Write transfer only when it has the
sufficient data to transfer the burst completely. Indeed, the AHB interface assumes that it
always has data available to push into the AHB bus.
Doc ID 022640 Rev 3
RM0319
12.3.3
Fast Ethernet port (MII0)
DMA controller
The native DMA controller interfaces both with the host through the AHB interface and with
the MAC core (Section 12.2).
The DMA controller has Independent Transmit and Receive engines. The Transmit Engine
transfers data from system memory (through the AHB master interface) to MAC core, while
the Receive Engine transfers data from the MAC core to the system memory (through AHB
master interface).
Apart from DMA CSRs, the DMA controller communicates with the host using both
descriptor lists and data buffers.
The descriptor lists are used by the DMA Controller to efficiently move data from source to
destination with minimal host CPU involvement. The descriptor lists (detailed in
Section 12.3.7) reside in the host physical memory space, and they act as pointers to the
data buffer (each descriptor can point to two buffers maximum).
A data buffer consists of an entire frame or part of a frame, but cannot exceed a single
frame. Data buffers reside in the host physical memory space, and they are used by the
DMA Controller to write to (Receive Buffer) and read from (Transmit Buffer) frames which
have been received or have to be transmitted, respectively.
Note:
Only data are contained in data buffer, whereas buffer status is maintained in the relevant
descriptor.
12.3.4
Transmit and receive FIFO
The Transmit FIFO (TxFIFO) buffers data read from system memory by the DMA, before
transmission by the MAC core.
Similarly, the receive FIFO (RxFIFO) is intended to store the frames received from the
ethernet until they are transferred to system memory by the DMA.
These are asynchronous FIFOs, as they transfer data between the application clock domain
and the MAC line clock.
12.3.5
MAC management counters
The MMC (MAC Management Counters) module provides a mechanism compliant with the
standard RMON (Remote Networking Monitoring) specification. This standard defines a set
of statistics and functions that can be exchanged between RMON-compliant console
systems and network probes.
The counters in the MMC module can be viewed as an extension of the register address
space of the CSR module. The MMC module maintains a set of registers (see MAC_UNIV
MAC global registers) for gathering statistics on the received and transmitted frames. These
include a control register for controlling the behaviour of the registers, two 32-bit registers
containing interrupts generated (receive and transmit) and two 32-bit registers containing
mask for the interrupt register (receive and transmit).
The MMC registers are accessed using transactions, in the same way the CSR address
space is accessed.
Doc ID 022640 Rev 3
143/368
Fast Ethernet port (MII0)
12.3.6
RM0319
Power management module (PMT)
This section describes the power management (PMT) mechanism as supported by the
MAC. PMT supports the reception of network (remote) wake-up frames and Magic Packet
frames. PMT does not perform the clock gate function, but generates interrupts for wake-up
frames and Magic Packets received by the MAC. The PMT block sits on the receiver path of
the MAC and is enabled with remote wake-up frame enable and Magic Packet enable.
These enables are in the PMT Control and Status Register (Register11, MAC) and are
programmed by the Application.
12.3.7
DMA descriptors
The DMA Controller operates two descriptor lists, one for transmission and one for
reception. The base address of each list is written into DMA Register3 (Receive Descriptor
List Address) and Register4 (Transmit Descriptor List Address), respectively.
Each descriptor list (both for transmission and for reception) consists of a set of descriptor,
and each descriptor is provided with the following fields:
●
The status of the received/transmitted frames together with descriptor ownership
information
●
A set of control bits
●
The byte-count of the two pointed data buffers
●
The address pointers of the two data buffers
Depending on the contents of the 2nd data buffer of the last descriptor in the list, two
different lists can result (as depicted in Figure 45.)
144/368
●
A ring structure: the list is implicitly forward linked, each descriptor points to two data
buffers, and the last descriptor points back to the first entry of the list;
●
A chain structure: the list is explicitly forward linked by using the 2nd address pointer
of each descriptor to point the next descriptor in the list.
Doc ID 022640 Rev 3
RM0319
Fast Ethernet port (MII0)
Figure 45. DMA descriptor list: ring structure (left) and chain structure (right).
Buffer 1
Descriptor 0
Buffer 1
Descriptor 0
Buffer 2
Buffer 1
Descriptor 1
Buffer 2
Buffer 1
Descriptor 1
Buffer 1
Descriptor 2
Buffer 2
Buffer 1
Descriptor 2
Buffer 1
Descriptor n
Buffer 2
Next Descriptor
Note:
The descriptor addresses must be aligned to the bus-width used (32/64/128 bit buses).
Transmit descriptors
As shown in Figure 46, there are four different transmit descriptors:
●
Transmit Descriptor 0, TDES0 (Table 44): it contains the status of the transmitted frame
and the descriptor ownership information along with control bits for controlling the
descriptor structure and the frame being transferred.
●
Transmit Descriptor 1, TDES1 (Table 45): it contains the data buffer sizes.
●
Transmit Descriptor 2, TDES2 (Table 46): it contains the address pointer to the first
data buffer in the descriptor.
●
Transmit Descriptor 3, TDES3 (Table 47): it contains the address pointer to the second
data buffer in the descriptor or the next descriptor (in case of chained structure).
Doc ID 022640 Rev 3
145/368
Fast Ethernet port (MII0)
RM0319
Figure 46. DMA descriptor format (Transmit Descriptor, 32 bit)
31
TDES0
O
W
N
TDES1
0
Ctrl
[30:26]
Reserved
[25:24]
Reserved
[31:29]
Buffer 2 Byte Count
[28:16]
Reserved
[15:13]
Status [16:0]
Buffer 1 Byte Count
[12:0]
Buffer 2 Address [31:0] or Next Descriptor Address [31:0]
TDES3
146/368
Reserved
[19:17]
Buffer 1 Address [31:0]
TDES2
Table 44.
Ctrl
[23:20]
Transmit descriptor 0 (TDES0)
Bit
Name
Description
[31]
OWN
Own Bit. If set, indicates that the descriptor is owned by the DMA of MAC. If
cleared, the descriptor is owned by the host.
[30]
IC
Interrupt on Completion. Setting this bit, the TI bit of the Status register (DMA
Register5) is set after the present frame has been transmitted.
[29]
LS
Last Segment. If set, it indicates that the buffer contains the last segment of
the frame.
[28]
FS
First Segment. If set, it indicates that the buffer contains the first segment of
the frame.
[27]
DC
Disable CRC. Setting this bit, the MAC does not automatically add padding
to a framer shorter than 64 bytes.
[26]
DP
Disable Padding. Setting this bit, the MAC does not automatically add
padding to a frame shorter than 64 bytes.
If cleared, the DMA automatically adds padding and CRC to a frame shorter
that 64 bytes and the CRC field is added despite the state if the DC bit
(TDES0[27]). Valid only if (TDES0[28]) is set.
[25]
TTSE
Reserved
[24]
Reserved
-
[23:22]
CIC
Checksum Insertion Control. These bits control the checksum calculation
and insertion. Bit encodings are as shown below.
2’b00: Checksum Insertion Disabled.
2’b01: Only IP header checksum calculation and insertion are enabled.
2’b10: IP Header checksum and payload checksum calculation and insertion
are enabled, but pseudo-header checksum is calculated in hardware.
2’b11: IP Header checksum and payload checksum calculation and insertion
are enabled, and pseudo-header checksum is calculated in hardware.
[21]
TER
Transmit End of Ring. If set, it indicates that the descriptor list reached its
final descriptor. The DMA returns to the base address of the list, creating a
descriptor ring structure.
Doc ID 022640 Rev 3
RM0319
Fast Ethernet port (MII0)
Table 44.
Bit
Transmit descriptor 0 (TDES0) (continued)
Name
Description
[20]
TCH
When set, this bit indicates that the second address in the descriptor is the
Next Descriptor address rather than the second buffer address. When
TDES0[20] is set, TBS2 (TDES1[28:16]) is a "don't care" value.
TDES0[21] takes precedence over TDES0[20].
[19:18]
Reserved
-
TTSS
Transmit Time Stamp Status. This field is used as a status bit to indicated
that a time stamp was captured for the described transmit frame. When this
bit is set, TDES2 and TDES3 have a time stamp value captured for the
transmit frame. This field is only valid when the descriptor’s Last Segment
Control bit (TDES0[29]) is set.
[16]
IHE
IP Header Error. When set, this bit indicates that the MAC transmitter
detected an error in the IP datagram header. The transmitter checks the
header length in the IPv4 packet against the number of header bytes
received from the application and indicates an error status if there is a
mismatch. For IPV6 frames, a header error is reported if the main header
length is not 40 bytes. Furthermore, the Ethernet Length/Type field value for
an IPv4 or IPv6 frame must match the IP header version received with the
packet. For IP4 frames, an error status is also indicated if the Header Length
field has a value less than 0x5.
[15]
ES
Error Summary. It is the logical OR of the following bits of this descriptor. [1],
[2], [8], [9], [10], [11], [13] and [14].
[14]
JT
Jabber Timeout. If set, it indicates that the MAC transmitter has experienced
a jabber timeout.
[13]
FF
Frame Flushed. If set, it indicates that the DMA flushed the frame due to a
software flush command given by the CPU.
[12]
IPE
IP Payload Error When set, this bit indicates that MAC transmitter detected
[11]
LC
Loss of Carrier. If set, it indicates that loss of carrier occured during frame
transmission. This is valid only for the frames transmitted without collision
when the MAC operates in Half-Duplex mode.
[10]
NC
No Carrier. If set, it indicates that the carrier sense signal
[09]
LC
Late Collision. If set, it indicates that the frame transmission was aborted due
to a collision after the collision window. This bit is not valid if the UnderFlow
Error bit is set.
[08]
EC
Excessive Collision. If set, it indicates that the frame transmission was
aborted after 16 successive collisions while attempting to transmit the
current frame.
Note: if the DR (Disable Retry) bit in the MAC Configuration register
(Register 0) is set, the EC bit is set after the first collision and the
transmission is aborted.
[07]
VF
VLAN Frame. If set, it indicates that the transmitted frame was a VLAN-type
frame.
[06:03]
CC
Collision Count. This 4 bit counter value reports the number of collisions
occuring before the frame was transmitted.
Note: The count is not valid when the EC bit (TDES0[8]) is set.
[17]
Doc ID 022640 Rev 3
147/368
Fast Ethernet port (MII0)
Table 44.
Bit
Transmit descriptor 0 (TDES0) (continued)
Name
Description
[02]
ED
Excessive Deferral. If set, it indicates that the transmission has ended
because of excessive deferral of over 24288 bit times (155680 bit times in
Jumbo Frame Enabled Mode), if the DC (Deferral Check) bit in the MAC
Configuration register (Register 0) is set.
[01]
UF
Underflow Error. If set, it indicates that the transmission has ended because
data arrived late from the host memory. This means that DMA encountered
an empty Transmit Buffer while transmitting the frame.
[00]
DB
Deferred Bit. If set, it indicates that the MAC defers before transmission
because of the presence of carrier. Valid in half-duplex mode only.
Table 45.
Transmit descriptor 1 (TEDS1)
Bit
Name
Description
[31:29]
Reserved
-
[28:16]
TBS2
Transmit Buffer 2 Size. These 13 bit field reports the size (in bytes) of the
second data buffer.
Note: This field is not valid if TDES0[20] is set.
[15:13]
Reserved
-
TBS1
Transmit Buffer 1 Size. These 13 bit field reports the size (in bytes) of the first
data buffer.
Note: If TBS1 value is 13h’0, then the DMA ignores this buffer and uses the
2nd buffer or next descriptor (depending on TCH bit value).
[12:00]
Table 46.
Transmit descriptor 2 (TDES2)
Bit
Name
Description
[31:00]
Buffer 1
Address
Pointer
This field indicates the physical address of the 1st data buffer
pointed to by this descriptor.
Table 47.
148/368
RM0319
Transmit descriptor 3 (TDES3)
Bit
Name
Description
[31:00]
Buffer 2
Address
Pointer
This field indicates the physical address of the 2nd data buffer pointed to
by this descriptor, if descriptor chaining is used.
If TDES1[24] bit is set, then this field contains the pointer to the physical
memory when the next descriptor is present.
Doc ID 022640 Rev 3
RM0319
Fast Ethernet port (MII0)
Receive descriptors
There are four different receive descriptors:
●
Receive descriptor 0, RDES0 (Table 48): it contains the status of the received frame,
the frame length and the descriptor ownership information.
●
Receive descriptor 1, RDES1 (Table 49): it contains the data buffer sizes and other bits
which controls the descriptor structure (chain/ring).
●
Receive descriptor 2, RDES2 (Table 50): it contains the address pointer to the first data
buffer in the descriptor.
●
Receive descriptor 3, RDES3 (Table 51): it contains the address pointer to the second
data buffer in the descriptor or the next descriptor (in case of chained structure).
Figure 47. DMA descriptor format (Receive Descriptor, 32 bit)
31
0
O
W
N
RDES0
C
T
R
L
RDES1
Status [30:0]
Reserved Buffer 2 Byte Count
[31:29]
[28:16]
Reserved
Buffer 1 Byte Count
[12:0]
Buffer 1 Address [31:0]
RDES2
Buffer 2 Address [31:0] or Next Descriptor Address [31:0]
RDES3
Table 48.
Ctrl
[15:14]
Receive descriptor 0 (RDES0)
Bit
Name
Description
[31]
OWN
Own Bit. If set, it indicates that the descriptor is owned by the DMA of MAC.
If cleared, the descriptor is owned by the host.
[30]
AFM
Destination Address Filter Fail. If set, it indicates a frame that failed in the
DA filter in the MAC core.
[29:16] FL
Frame Length. These 14 bit field reports the byte length of the received
frame (including CRC and the 2 bytes appended to the frame when IP
checksum calculation is enabled and the received frame is not a MAC control
frame).
[15]
ES
Error Summary. It is the logical OR of the following bits of this descriptor: [1],
[3], [4], [6], [10], [11] and [14].
[14]
DE
Descriptor Error. If set, it indicates a frame truncation caused by a frame
that does not fit within the current descriptor buffers, and that the DMA does
not own the next descriptor.
[13]
SAF
Source Address Filter Fail. If set, it indicates a frame that failed in the SA
filter in the MAC core.
[12]
LE
Length Error. If set, it states that the actual length of the frame received and
that the length/type field does not match.
Doc ID 022640 Rev 3
149/368
Fast Ethernet port (MII0)
Table 48.
Receive descriptor 0 (RDES0) (continued)
Bit
Name
Description
[11]
OE
Overflow Error. If set, it indicates that received frame was damaged due to
buffer overflow in MAC core.
[10]
VLAN
Van Tag. If set, it indicates that the frame pointed to by this descriptor is a
VLAN frame tagged by the MAC core.
[09]
FS
First Descriptor. If set, this descriptor contains the first buffer of the frame.
[08]
LS
Last Descriptor. If set, it indicates that the buffers pointed to by this
descriptor are the last buffers of the frame.
[07]
IPC
checksum
error
If set, it indicates that the 16 bit IP header checksum calculated by the MAC
core did not match the received checksum bytes.
[06]
LC
Late Collision. If set, it indicates that late collision has occurred while
receiving the frame in half-duplex mode.
[05]
FT
Frame type. If set, it indicates that the received frame is an Ethernet-type
frame, whereas the received frame is an IEEE802.3 frame.
[04]
RWT
Receive watchdog timeout. If set, it indicates that the receive watchdog timer
has expired while receiving the current frame and the current frame is
truncated after the watchdog timeout.
[03]
RE
Receive Error.
[02]
DE
Dribble Bit Error. If set, it indicates that the received frame has a noninteger multiple of bytes (odd nibbles). Valid only in MII mode.
[01]
CE
CRC Error.
[00]
Rx MAC
address
If set, it indicates that the Rx MAC address value (register1 to register15)
matched the DA field of the frame. If cleared, it indicates that Rx MAC
Address0 matched the DA field.
Table 49.
Bit
[31]
Receive descriptor 1 (RDES1)
Name
Description
DIC
Disable Interrupt on Completion Setting this bit will prevent the setting of the
RI bit of the Status register for the received frame that ends in the buffer
pointer to by this descriptor. This, in turn, will disable the assertion of the
interrupt to the host due to RI.
[30:29] Reserved
-
[28:16] RBS2
Receive Buffer 2 Size. These 13 bit field reports the size (in bytes) of the
second data buffer.
Note: The RBS2 value must be a multiple of 4/8/16 depending on the width
of the bus otherwise the resulting behaviour is undefined.
[15]
RER
Receive End of Ring When set, this bit indicates that the descriptor list
reached its final descriptor. The DMA returns to the base address of the list,
creating a descriptor ring.
RCH
Second Address Chained When set, this bit indicates that the second
address in the descriptor is the Next Descriptor address rather than the
second buffer address. When this bit is set, RBS2 (RDES1[28:16]) is a "don't
care" value. RDES1[15] takes precedence over RDES1[14].
[14]
150/368
RM0319
Doc ID 022640 Rev 3
RM0319
Fast Ethernet port (MII0)
Table 49.
Receive descriptor 1 (RDES1) (continued)
Bit
Name
Description
[13]
Reserved
-
[12:00] RBS1
Table 50.
Receive descriptor 2 (RDES2)
Bit
Name
[31:00]
Buffer 1 Address This field indicates the physical address of the 1st data buffer pointed to
Pointer
by this descriptor.
Table 51.
12.4
Receive Buffer 1 Size. This 13-bit field reports the size (in bytes) of the first
data buffer.
Note: The RBS1 value must be a multiple of 4/8/16 depending on the bus
width otherwise the resulting behaviour is undefined.
Note: If RBS1 value is 13'h0, then the DMA ignores this buffer and uses the
2nd buffer or next descriptor (depending on RCH bit value).
Description
Receive descriptor 3 (RDES3)
Bit
Name
Description
[31:00]
Buffer 2 Address
Pointer
(Next Descriptor
Address)
This field indicates the physical address of the 2nd data buffer pointed
to by this descriptor, if descriptor chaining is used.
If RDES1[24] bit is set, then this field contains the pointer to the
physical memory when the next descriptor is present.
Clocks
The clocking scheme for the MAC-AHB is shown in Figure 48. The MAC-AHB uses three
clock inputs for normal operation with the MII interface:
●
One clock (clk_tx_i) for transmission functions
●
One clock (clk_rx_i) for reception functions
●
One application clock (hclk_i)
All clocks except for the application clock are generated from an external PHY. The
application clock is used for the control interface of the MAC-AHB. The transmit clock
clk_tx_i is used for the transmission function of the MAC-AHB. Similarly, the receive clock
clk_rx_i is used for the receive function of the MAC-AHB. The transfer of data from/to the
application clock domain to the transmit and receive clock domains is performed in the MTL
module.
The clk_tx_ i clock gets input from an external PHY (MII mode).
The external PHY outputs a 25 MHz or 2.5 MHz transmit clock on MII_CLK when it operates
at 100 Mbps or 10 Mbps, respectively. The frequency of clock clk_rx_i is the same as for
receive clock MII_RX_CLK generated by the external PHY. The PHY outputs a 25 MHz or
2.5 MHz receive clock on MII_RX_CLK when it operates at 100 Mbps, or 10 Mbps,
respectively.
Doc ID 022640 Rev 3
151/368
Fast Ethernet port (MII0)
RM0319
Figure 48. Clocking scheme for MAC-AHB
12.5
Interrupts
Figure 49. Interrupt management: sbd_intr_o and pmt_intr_o generation
PMT_INTR
~PMT_INTR_MASK
pmt_intr_o
AND
To VIC IRQ 55
MMC_INTR
GPI
TI
TIE
AND
GMI
OR
NIS
ERI
AND
ERE
AND
NIE
OR
sbd_intr_o
To VIC IRQ 56
TPS
AND
TSE
AIS
OR
FBI
AND
FBE
AIE
AND
Note:Signals NIS and AIS are registered
The Ethernet MAC provides two interrupt lines to VIC (Vectored Interrupt Controller):
152/368
●
sbd_intr_o: general interrupt signal connected to the VIC IRQ 56 line;
●
pmt_intr_o: interrupt signal generated from PMT (Power Management) module
connected to VIC IRQ 55 line;
Doc ID 022640 Rev 3
RM0319
Fast Ethernet port (MII0)
The signal pmt_intr_o reflects the combination of the value PMT_INTR in the MAC interrupt
status register (Interrupt Status Register (Register14, MAC), bit 3) and the value
PMT_INTR_MASK in the MAC interrupt mask register (Interrupt Mask Register (Register
15,MAC), bit 3).
Interrupts can be generated from the MAC Core as a result of various events in the optional
modules in it (for example MMC and PMT modules). These interrupt events are combined
with events in the DMA on the sbd_intr_o signal. Infact the signal pmt_intr_o is also used to
drive the signal sbd_intr_o (GPI in the figure above).
In the same way the MMC block through MMC_INTR (controlled by Interrupt Status Register
(Register14, MAC), bit 4) drives the sbd_intr_o signal (GMI in the figure above).
The other events in the DMA that drive the sbd_intr_o signal are produced by the
combinations of status register bits and interrupt mask bits (listed correspondingly in the
Status Register (Register5, DMA) and Interrupt Enable Register (Register7, DMA)).
12.6
Programming examples
How to initialize DMA
1.
Write to DMA register0 (Bus Mode) to set the host bus access parameters.
2.
Write to DMA register7 (Interrupt Enable) to mask needless interrupt causes.
3.
Create the Transmit And Receive descriptor lists into the host physical memory space.
4.
Write to both DMA register3 (Receive Descriptor List Address) and register4 (Transmit
Descriptor List Address) providing the DMA with the starting address of each descriptor
list.
5.
Write to MAC register1 (MAC Frame Filter), register2 (Hash Table High) and register3
(Hash Table Low) for described filtering options.
6.
Write to MAC register0 (MAC configuration) to configure and enable the Transmit And
Receive operating modes. The PS and DM bits are set based on the auto-negotiation
result (read from the PHY).
7.
Write to DMA register6 () setting bits [1] SR and [13] ST to start reception and
transmission, respectively.
Doc ID 022640 Rev 3
153/368
Fast Ethernet ports (RMII0/RMII1/MII1)
13
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
This chapter focuses on the functional and operational aspects of the MACB Ethernet
controller.
For technical details about the programmable registers related to the MACB, refer to the
MACB registers in the following companion document:
●
13.1
RM0321: SPEAr320S address map and registers
Overview
SPEAr320S features MACB modules capable of supporting the following PHY interfaces:
●
Media Independent Interface (MII)
●
Reduced Media Independent Interface (RMII)
Figure 50. MACB simplified block diagram
Status &
Statistic
Register
CPU I/F
Register
interface
MDIO
Control
Register
DMA I/F
FIFO
Interface
154/368
MAC Transmitter
AHB DMA
Interface
MAC Receiver
External
FIFO
interface
Doc ID 022640 Rev 3
Frame Filtering
MII/RMII
RM0319
13.2
Fast Ethernet ports (RMII0/RMII1/MII1)
Main features
●
Compatible with IEEE Standard 802.3
●
UNH tested
●
10 and 100 Mbit/s operation
●
Full and half duplex operation
●
Statistics counter registers for RMON/MIB
●
MII/RMII interface to the physical layer
●
Interrupt generation to signal receive and transmit completion
●
Transmit and receive FIFOs having a depth of 8 each
●
Automatic pad and CRC generation on transmitted frames
●
Automatic discard of frames received with errors
●
Address checking logic supports up to four specific 48 bit addresses
●
Supports promiscuous mode where all valid received frames are copied to memory
●
Hash matching of unicast and multicast destination addresses
●
External address matching of received frames
●
Physical layer management through MDIO interface
●
Supports serial network interface operation
●
Half duplex flow control by forcing collisions on incoming frames
●
Full duplex flow control with recognition of incoming pause frames and hardware
generation of transmitted pause frames
●
Support for 802.1Q VLAN tagging with recognition of incoming VLAN and priority
tagged frames
●
Multiple buffers per receive and transmit frame
●
Wake on LAN support
●
Jumbo frames of up to 10240 bytes supported
Doc ID 022640 Rev 3
155/368
Fast Ethernet ports (RMII0/RMII1/MII1)
13.3
Pins
13.3.1
MII configuration
RM0319
Figure 51. MII configuration in SPEAr320S
SPEAr320S
MII1_TXCLK
MII1_TXD0
MII1_TXD1
MII1_TXD2
MII1_TXD3
MII1_TXEN
MII1_TXER
MII1_RXCLK
MII
MII1_RXD0
MII 1
PHY
MII1_RXD1
MII1_RXD2
MII1_RXD3
MII1_RXER
MII1_RXDV
MII1_COL
MII1_CRS
MII1_MDIO
MII1_MDC
Table 52.
156/368
Pin configuration in MII mode
Pin
Direction
Function
MII1_TXCLK
In
Transmit clock from MII PHY to MII1
MII1_TXD0
Out
Transmit data to MII PHY from MII1
MII1_TXD1
Out
Transmit data to MII PHY from MII1
MII1_TXD2
Out
Transmit data to MII PHY MII1
MII1_TXD3
Out
Transmit data to MII PHY from MII1
MII1_TXEN
Out
Transmit enable to MII PHY from MII1
MII1_TXER
Out
Transmit error signal to MII PHY from MII1
MII1_RXCLK
In
Receive clock from MII PHY to MII1
MII1_RXDV
In
Receive data valid signal from MII PHY to MII1
MII1_RXER
Out
Receive error signal from MII PHY from MII1
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
Table 52.
Pin configuration in MII mode (continued)
Pin
Direction
Function
MII1_RXD0
In
Receive data from MII PHY to MII1
MII1_RXD1
In
Receive data from MII PHY to MII1
MII1_RXD2
In
Receive data from MII PHY to MII1
MII1_RXD3
In
Receive data from MII PHY to MII1
MII1_COL
In
Collision detect from MII PHY to MII1
MII1_CRS
In
Carrier sense from MII PHY to MII1
MII1_MDIO
In/Out
MII1_MDC
Out
MII PHY Management data in/out to/from MII1
Management data clock to the MII PHY from MII1
Doc ID 022640 Rev 3
157/368
Fast Ethernet ports (RMII0/RMII1/MII1)
13.3.2
RM0319
RMII configuration
Figure 52. RMII configuration in SPEAr320S
SPEAr320S
RMII0_TXD0
RMII0_TXD1
RMII0_RXD0
RMII0_RXD1
RMII 0
RMII0_TX_EN
RMII0_CRS_DV
RMII0_RX_ER
RMII1_TXD0
RMII1_TXD1
RMII1_RXD0
RMII 1
2 x RMII
PHY
RMII1_RXD1
RMII1_TX_EN
RMII1_CRS_DV
RMII1_RX_ER
RMII_MDIO
RMII_MDC
50 MHz
crystal
Table 53.
158/368
Pin configuration in RMII mode
Pin
Direction
Function
RMII0_TXD0
Out
Transmit data to RMII PHY from RMII0
RMII0_TXD1
Out
Transmit data to RMII PHY from RMII0
RMII0_RXD0
In
Receive data from RMII PHY to RMII0
RMII0_RXD1
In
Receive data from RMII PHY to RMII0
RMII0_TX_EN
Out
RMII0_CRS_DV
In
RMII0_RX_ER
Out
Receive error signal from RMII PHY from RMII0
RMII1_TXD0
Out
Transmit data to RMII PHY from RMII1
RMII1_TXD1
Out
Transmit data to RMII PHY from RMII1
RMII1_RXD0
In
Receive data from RMII PHY to RMII1
RMII1_RXD1
In
Receive data from RMII PHY to RMII1
RMII1_TX_EN
Out
RMII1_CRS_DV
In
Transmit enable to RMII PHY from RMII0
Carrier sense/receive data valid from RMII PHY to RMII0
Transmit enable to RMII PHY from RMII1
Carrier sense/receive data valid from RMII PHY to RMII1
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
Table 53.
Pin configuration in RMII mode (continued)
Pin
Direction
RMII1_RX_ER
Out
RMII_REF_CLK
In
RMII_MDIO
In/Out
RMII_MDC
Out
Function
Receive error signal from RMII PHY from RMII1
50 Mhz reference clock required for RMII0/RMII1 operation
RMII PHY Management data in/out
Management data clock to the RMII PHY
Doc ID 022640 Rev 3
159/368
Fast Ethernet ports (RMII0/RMII1/MII1)
13.4
RM0319
Functional description
The MACB module implements a 10/100 Ethernet MAC compatible with the IEEE 802.3
standard using an address checker, statistics and control registers, receive and transmit
blocks, and a DMA interface.
Figure 53. MACB detailed block diagram
CPU I/F
MDIO
DMA I/F
pclk_syncs
Statistics
Register
D
Control
Registe
r
SET
CLR
DMA Interface
Tx
Rx
FIFO
FIFO
Q
D
Q
SET
CLR
Q
Q
Ethernet
Receive
Ethernet
Transmit
Tx-State
Machine
MII/RMII
MII/RMII
hclk_syncs
D
SET
CLR
Q
D
Q
SET
CLR
Q
Q
Address
Checker
External FIFO interface
13.4.1
FIFO
Interface
Address checker
The address checker recognizes four specific 48-bit addresses and contains a 64-bit hash
register for matching multicast and unicast addresses. It can recognize the broadcast
address of all ones, copy all frames, and act on an external address match signal.
13.4.2
Statistics register block
The statistics register block contains registers for counting various types of event associated
with transmit and receive operations. These registers, along with the status words stored in
the receive buffer list, enable software to generate network management statistics
compatible with IEEE 802.3 Clause 30.
13.4.3
Control registers
The control registers drive the MDIO interface, setup up DMA activity, start frame
transmission and select modes of operation such as full or half duplex.
13.4.4
Receive block
The receive block checks for valid preamble, FCS, alignment and length, and presents
received frames to the address checking block and DMA interface. The transmit block takes
data from the DMA interface adds preamble and, if necessary, pad and FCS, and transmits
160/368
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
data according to the CSMA/CD (carrier sense multiple access with collision detect)
protocol. The start of transmission is deferred if CRS (carrier sense) is active. If COL
(collision) becomes active during transmission, a jam sequence is asserted and the
transmission is retired after a random back off. CRS and COL have no effect in full duplex
mode.
13.4.5
DMA interface
The DMA interface contains receive and transmit FIFOs for buffering frame data. It loads the
transmit FIFO and empties the receive FIFO using AHB bus master operations. Receive
data is not sent to memory until the address checking logic has determined that the frame
should be copied.
Receive or transmit frames are stored in one or more buffers. Receive buffers have a fixed
length of 128 bytes. Transmit buffers range in length between 0 and 2047 bytes, and up to
128 buffers are permitted per frame. The DMA block manages transmit and receive framebuffer queues. These queues can hold multiple frames.
All transfers are 32-bit words and may be single accesses or bursts of 2, 3 or 4 words. Burst
accesses do not cross sixteen byte boundaries. Bursts of 4 words are the default data
transfer, single accesses or bursts of less than four words may be used to transfer data at
the beginning or the end of a buffer.
The DMA controller performs six types of operation on the AHB bus. In order of priority
these are:
●
Receive buffer manager write
●
Receive buffer manager read
●
Transmit data
●
DMA read
●
Receive data DMA write
●
Transmit buffer manager read
●
Transmit buffer manager write
FIFOs
The receive and transmit FIFO depths are both set to eight words (32 bytes). Data is
typically transferred into and out of the FIFOs in bursts of four words. For receive, a bus
request is asserted when the FIFO contains four words and has space for three more.
For transmit, a bus request is generated when there is space for four words, or when there is
space for two words if the next transfer is to be only one or two words.
Transmit buffers are permitted to be any length between zero and 2047 bytes. For short
lengths adequate bandwidth must be allowed for buffer management overhead. It is
recommended to perform simulations to ensure the system has adequate bandwidth if
transmit frames are likely to contain a number of very short buffers. If the DMA block cannot
access transmit data from memory in time “transmit underrun" status will be reported and an
interrupt asserted.
Receive buffer
Received frames, optionally including CRC/FCS, are written to receive buffers stored in
memory. Each receive buffer is 128 bytes long, this number is parameterizable. The start
location for each receive buffer is stored in memory in a list of receive buffer descriptors at a
Doc ID 022640 Rev 3
161/368
Fast Ethernet ports (RMII0/RMII1/MII1)
RM0319
location pointed to by the receive buffer queue pointer register. The receive buffer start
location is a word address. For the first buffer of a frame, the start location can be offset by
up to three bytes depending on the value written to bits 14 and 15 of the network
configuration register. If the start location of the buffer is offset the available length of the first
buffer of a frame is reduced by the corresponding number of bytes.
Each list entry consists of two words. The first being the address of the receive buffer and
the second being the receive status. If the length of a receive frame exceeds the buffer
length the status word for the used buffer is written with zeroes except for the start of frame
bit and the offset bits if appropriate. Bit zero of the address field is written to one to show the
buffer has been used. The receive buffer manager then reads the location of the next
receive buffer and fills that with receive frame data. The final buffer descriptor status word
contains the complete frame status. The received frame length is only available in the status
word of the final buffer descriptor. Refer to the following table for details of the receive buffer
descriptor list.
Table 54.
Bit
Receive buffer descriptor entry
Function
Word 0
[31:02]
Address of beginning of buffer
[01]
Wrap - marks last descriptor in receive buffer descriptor list.
[00]
Ownership - needs to be zero for the MACB to write data to the receive buffer. The
MACB sets this to one once it has successfully written a buffer to memory. Software
has to clear this bit before the buffer can be used again.
Word 1
162/368
[31]
Global all ones broadcast address detected
[30]
Multicast hash match
[29]
Unicast hash match
[28]
External address match
[27]
Unknown source address (reserved for future use)
[26]
Specific address register 1 match
[25]
Specific address register 2 match
[24]
Specific address register 3 match
[23]
Specific address register 4 match
[22]
Type ID match
[21]
VLAN tag detected (that is. type ID of 0x8100)
[20]
Priority tag detected (that is. type ID of 0x8100 and null VLAN identifier)
[19:17]
VLAN priority (only valid if bit 21 is set)
[16]
Concatenation format indicator (CFI) bit (only valid if bit 21 is set)
[15]
End of frame - when set the buffer contains the end of a frame. If end of frame is not
set then the only other valid status are bits 12, 13 and 14.
[14]
Start of frame - when set the buffer contains the start of a frame. If both bits 15 and
14 are set then the buffer contains a whole frame.
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
Table 54.
Receive buffer descriptor entry (continued)
Bit
Function
[13:12]
Receive buffer offset - indicates the number of bytes by which the data in the first
buffer is offset from the word address. Updated with the current values of the
network configuration register. If jumbo frame mode is enabled through bit 3 of the
network configuration register, then bits 13:12 of the receive buffer descriptor entry
are used to indicate bits 13:12 of the frame length.
[11:00]
Length of frame including FCS (if selected). Bits 13:12 are also used if jumbo frame
mode is selected.
To receive frames, the buffer descriptors must be initialized by writing an appropriate
address to bits 31 to 2 in the first word of each list entry. Bit zero must be written with zero.
Bit one is the wrap bit and indicates the last entry in the list.
The start location of the receive buffer descriptor list must be written to the receive buffer
queue pointer register before setting the receive enable bit in the network control register to
enable receive. As soon as the receive block starts writing the received frame data to the
receive FIFO, the receive buffer manager reads the first receive buffer location pointed to by
the receive buffer queue pointer register.
If the filter block indicates that the frame should be copied to memory, the receive data DMA
operation starts writing data into the receive buffer. If an error occurs, the buffer is
recovered.
If the current buffer pointer has its wrap bit set or is the 1024th descriptor, the next receive
buffer location is read from the beginning of the receive descriptor list. Otherwise, the next
receive buffer location is read from the next word in memory.
There is an 11 bit counter to count out the 2048 word locations of a maximum length,
receive buffer descriptor list. This is added with the value originally written to the receive
buffer queue pointer register to produce a pointer into the list. A read of the receive buffer
queue pointer register returns the pointer value, which is the queue entry currently being
accessed.
The counter is reset after receive status is written to a descriptor that has its wrap bit set or
rolls over to zero after 1024 descriptors have been accessed. The value written to the
receive buffer pointer register may be any word-aligned address, provided that there are at
least 2048 word locations available between the pointer and the top of the memory.
As receive buffer manager writes are bursts of two words, to ensure that this does not occur
it is best to write the pointer register with the least three significant bits set to zero.
As receive buffers are used, the receive buffer manager sets bit zero of the first word of the
descriptor to indicate used. If a receive error is detected the receive buffer currently being
written will be recovered. Previous buffers will not be recovered.
Software should search through the used bits in the buffer descriptors to find out how many
frames have been received. It should be checking the start-of-frame and end-of-frame bits,
and not rely on the value returned by the receive buffer queue pointer register which
changes continuously as more buffers are used.
For CRC errored frames, excessive length frames or length field mismatched frames, all of
which are counted in the statistics registers, it is possible that a frame fragment might be
stored in a sequence of receive buffers. Software can detect this by looking for start of frame
bit set in a buffer following a buffer with no end of frame bit set.
Doc ID 022640 Rev 3
163/368
Fast Ethernet ports (RMII0/RMII1/MII1)
RM0319
For a properly working Ethernet system there should be no excessive length frames or
frames greater than 128 bytes with CRC/FCS errors. Collision fragments will be less than
128 bytes long. Therefore it will be a rare occurrence to find a frame fragment in a receive
buffer.
If bit zero is set when the receive buffer manager reads the location of the receive buffer,
then the buffer has already been used and cannot be used again until software has
processed the frame and cleared bit zero. In this case, the DMA block will set the buffer not
available bit in the receive status register and trigger an interrupt.
If bit zero is set when the receive buffer manager reads the location of the receive buffer and
a frame is being received, the frame will be discarded and the receive resource error
statistics register will be incremented.
A receive overrun condition occurs when either the AHB or ASB bus was not granted in time
or because HRESP was not OK. In a receive overrun condition, the receive overrun interrupt
is asserted and the buffer currently being written is recovered. The next frame that is
received whose address is recognized reuses the buffer.
If bit 17 of the network configuration register is set, the FCS of received frames shall not be
copied to memory. The frame length indicated in the receive status field shall be reduced by
four bytes in this case.
Transmit buffer
Frames to be transmitted are stored in one or more transmit buffers. Transmit buffers can be
between 0 and 2047 bytes long, so it is possible to transmit frames longer than the
maximum length specified in IEEE std 802.3. Zero length buffers are allowed. The maximum
number of buffers permitted for each transmit frame is 128.
The start location for each transmit buffer is stored in memory in a list of transmit buffer
descriptors at a location pointed to by the transmit buffer queue pointer register. Each list
entry consists of two words. The first being the byte address of the transmit buffer and the
second containing the transmit control and status. Frames can be transmitted with or without
automatic CRC generation. If CRC is automatically generated, the pad will also be
automatically generated to take frames to a minimum length of 64 bytes.
Table 55: Transmit buffer descriptor entry defines an entry in the transmit buffer descriptor
list.
To transmit frames, the buffer descriptors must be initialized by writing an appropriate byte
address to bits 31 to 0 in the first word of each list entry. The second transmit buffer
descriptor is initialized with control information that indicates the length of the buffer,
whether or not it is to be transmitted with CRC and whether the buffer is the last buffer in the
frame.
After transmission the control bits are written back to the second word of the first buffer
along with the used bit and other status information. Bit 31 is the used bit which must be
zero when the control word is read if transmission is to happen. It is written to one when a
frame has been transmitted. Bits 27, 28 and 29 indicate various transmit error conditions. Bit
30 is the wrap bit which can be set for any buffer within a frame. If no wrap bit is encountered
after 1024 descriptors the queue pointers rolls over to the start in a similar fashion to the
receive queue.
The transmit buffer queue pointer register must not be written while transmit is active. If a
new value is written to the transmit buffer queue pointer register the queue pointer resets
itself to point to the beginning of the new queue. If transmit is disabled by writing to bit 3 of
164/368
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
the network control, the transmit buffer queue pointer register resets to point to the
beginning of the transmit queue.
Note:
Disabling receive does not have the same effect on the receive queue pointer.
Once the transmit queue is initialized transmit is activated by writing to bit 9, the Transmit
Start bit of the network control register. Transmit is halted when a buffer descriptor with its
used bit set is read or if a transmit error occurs or by writing to the transmit halt bit of the
network control register. Transmission is suspended if a pause frame is received while the
pause enable bit is set in the network configuration register. Rewriting the start bit while
transmission is active is allowed.
Transmission control is implemented with a tx_go variable which is readable in the transmit
status register at bit location 3. The tx_go variable is reset when:
●
Transmit is disabled
●
A buffer descriptor with its ownership bit set is read
●
A new value is written to the transmit buffer queue pointer register
●
Bit 10, tx_halt, of the network control register is written
●
There is a transmit error such as too many retries or a transmit underrun.
To set tx_go write to bit 9, tx_start, of the network control register. Transmit halt does not
take effect until any ongoing transmit finishes. If a collision occurs during transmission of a
multibuffer frame, transmission will automatically restart from the first buffer of the frame.
If a used bit is read mid way through transmission of a multibuffer frame this is treated as a
transmit error. Transmission stops, tx_er is asserted and the FCS will be bad.
If transmission stops due to a transmit error (that is. used bit read mid frame, transmit underrun or too many retries), the transmit queue pointer resets to point to the beginning of the
transmit queue. Software needs to re-initialize the transmit queue after a transmit error.
If transmission stops due to a used bit being read at the start of the frame, the transmission
queue pointer is not reset and transmit starts from the same transmit buffer descriptor when
the transmit start bit is written.
Table 55.
Bit
Transmit buffer descriptor entry
Function
Word 0
[31:00]
Byte address of buffer
Word 1
[31]
Used - needs to be zero for the MACB to read data from the transmit buffer.
The MACB sets this to one for the first buffer of a frame once it has been successfully
transmitted. Software has to clear this bit before the buffer can be used again. (Note
this bit is only set for the first buffer in a frame - unlike receive where all buffers have
the Used bit set once used.)
[30]
Wrap - marks last descriptor in transmit buffer descriptor list.
[29]
Retry limit exceeded - transmit error detected
[28]
Transmit underrun - occurs either when hresp is not OK or the transmit data could not
be fetched in time or when buffers are exhausted in mid frame.
[27]
Buffers exhausted in mid frame
Doc ID 022640 Rev 3
165/368
Fast Ethernet ports (RMII0/RMII1/MII1)
Table 55.
RM0319
Transmit buffer descriptor entry
Bit
Function
[26:17]
Reserved
[16]
No CRC - when set no CRC will be appended to the current frame. This bit only
needs to be set for the last buffer of a frame.
[15]
Last buffer - when set this bit will indicate the last buffer in the current frame has been
reached
[14:11]
Reserved
[10:00]
Length of buffer
Transmit block
This block transmits frames in accordance with the Ethernet IEEE 802.3 CSMA/CD
protocol.
Frame assembly starts by adding preamble and the start frame delimiter. Data is taken from
the transmit FIFO a word at a time. Data is transmitted least significant nibble first. If bit rate
is selected, the data is serialized and transmitted least significant bit first.
If necessary, padding is added to take the frame length to 60 bytes. CRC is calculated as a
32 bit polynomial. This is inverted and appended to the end of the frame taking the frame
length to a minimum of 64 bytes. If the No CRC bit is set in the second word of the last buffer
descriptor of a transmit frame neither pad nor CRC are appended.
In full duplex mode frames are transmitted immediately. Back to back frames are transmitted
at least 96 bit times apart to guarantee the interframe gap.
In half duplex mode, the transmitter checks carrier sense. If asserted, it waits for it to
deassert and then starts transmission after the interframe gap of 96 bit times. If the collision
signal is asserted during transmission, the transmitter will transmit a jam sequence of 32
bits taken from the data register and then retry transmission after the back off time has
elapsed.
The back off time is based on an XOR of the 10 least significant bits of the data coming from
the transmit FIFO and a 10 bit pseudo random number generator. The number of bits used
depends on the number of collisions seen. After the first collision 1 bit is used, the second 2,
and so on up to 10. Above 10, all 10 bits are used. An error will be indicated and no further
attempts will be made if 16 attempts cause collisions. This complies with the description in
Clause 4.2.3.2.5 of the IEEE 802.3 standard of the truncated binary exponential back off
algorithm.
If transmit DMA underruns or tx_r_err is asserted on the FIFO interface, bad CRC is
automatically appended using the same mechanism as jam insertion and the tx_er signal is
asserted. For a properly configured system this should never happen.
If the back pressure bit is set in the network control register in half duplex mode, the transmit
block transmits 64 bits of data, which can consist of 16 nibbles of 1011 or in bit rate mode 64
1s, whenever it sees an incoming frame to force a collision. This provides a way of
implementing flow control in half duplex mode.
166/368
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
Pause Frame Support
Note:
See Clause 31, Annex 31A and 31B of IEEE standard 802.3 for a full specification of the
pause operation.
The start of an 802.3 pause frame looks like this:
Table 56.
Pause frame support
Destination
Address
Source Address
Type (MAC
Control Frame)
Pause opcode
Pause Time
0x0180C2000001
6 bytes
0x8808
0x0001
2 bytes
The network configuration register contains a receive pause enable bit (13). If a valid pause
frame is received the pause time register is updated with the frame's pause time regardless
of its current contents and regardless of the state of the configuration register bit 13. An
interrupt (12) is triggered when a pause frame is received, assuming it is enabled in the
interrupt mask register. If bit 13 is set in the network configuration register and the value of
the pause time register is non-zero, no new frame is transmitted until the pause time register
has decremented to zero.
The loading of a new pause time, and hence the pausing of transmission, only occurs when
the MACB is configured for full duplex operation. If the MACB is configured for half duplex
there will be no transmission pause, but the pause frame received interrupt will still be
triggered.
A valid pause frame is defined as having a destination address that matches either the
address stored in specific address register 1 or matches 0x0180C2000001 and has the
MAC control frame type ID of 0x8808 and has the pause opcode of 0x0001. Pause frames
that have FCS or other errors will be treated as invalid and will be discarded. Valid pause
frames received will increment the pause frame received statistic register.
The pause time register decrements every 512 bit times (that is. 128 rx_clks in nibble mode)
once transmission has stopped. For test purposes the register decrements every rx_clk
cycle once transmission has stopped if bit 12 (retry test) is set in the network configuration
register. If the pause enable bit (13) is not set in the network configuration register then the
decrementing will happen regardless of whether transmission has stopped or not.
An interrupt (13) is asserted whenever the pause time register decrements to zero
(assuming it is enabled in the interrupt mask register).
Automatic transmission of pause frames is supported through the transmit pause frame bits
of the network control register and the tx_pause and tx_pause_zero inputs.
If either bit 11 or bit 12 of the network control register is written to with a 1, or if the input
signal tx_pause is toggled, a pause frame will be transmitted only if full duplex is selected in
the network configuration register and transmit is enabled in the network control register.
Doc ID 022640 Rev 3
167/368
Fast Ethernet ports (RMII0/RMII1/MII1)
RM0319
Pause frame transmission will happen immediately if transmit is inactive or if transmit is
active between the current frame and the next frame due to be transmitted. The transmitted
pause frame will comprise the items in the following list:
●
A destination address of 01-80-C2-00-00-01
●
A source address taken from the specific address 1 register
●
A type ID of 88-08 (MAC control frame)
●
A pause opcode of 00-01
●
A pause quantum
●
Fill of 00 to take the frame to minimum frame length
●
Valid FCS.
The pause quantum used in the generated frame will depend on the trigger source for the
frame as follows:
1.
If bit 11 is written with a one, the pause quantum will come from the transmit pause
quantum register. The transmit pause quantum register resets to a value of 0xFFFF
giving a maximum pause quantum as a default.
2.
If bit 12 is written with a one, the pause quantum will be zero.
3.
If the tx_pause input is toggled and the tx_pause_zero input is held low until the next
toggle, the pause quantum will come from the transmit pause quantum register.
4.
If the tx_pause input is toggled and the tx_pause_zero input is held high until the next
toggle, the pause quantum will be zero.
After transmission, no interrupts will be generated and the only statistics register that will be
incremented will be the pause frames transmitted register.
Receive block
The receive block checks for valid preamble, FCS, alignment and length, presents received
frames to the DMA block or FIFO interface and stores the frames destination address for
use by the address checking block.
If, during frame reception, the frame is found to be too long or rx_er is asserted, a bad frame
indication is sent to the DMA block. The DMA block then ceases sending data to memory,
but the FIFO interface, if present, continues sending data until the end of the frame is
reached when it asserts rx_w_err with rx_w_eop.
At the end of frame reception the receive block indicates to the DMA block whether the
frame is good or bad. The DMA block recovers the current receive buffer if the frame was
bad.
The receive block signals the register block to increment the alignment error, the CRC (FCS)
error, the short frame, long frame, jabber error, the receive symbol error statistics and the
length field mismatch statistics.
The enable bit for jumbo frames in the network configuration register allows the MACB to
receive jumbo frames of up to 10,240 bytes in size. This operation does not form part of the
IEEE 802.3 specification and is disabled by default. When jumbo frames are enabled,
frames received with a frame size greater than 10,240 bytes are discarded.
Address checking block
The address checking (or filter) block indicates to the DMA block which receive frames
should be copied to memory. The DMA block only copies frames that are addressed
168/368
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
recognized to memory. The FIFO interface outputs all frames and asserts rx_w_err with
rx_w_eop if the frame is not addressed matched to indicate that the frame should be
discarded.
Whether a frame is copied depends on what is enabled in the network configuration register,
the state of the external match pin, the contents of the specific address and hash registers
and the frame's destination address. In this implementation of the MACB, the frame's source
address is not checked. Provided that bit 18 of the network configuration register is not set,
a frame will not be copied to memory if the MACB is transmitting in half duplex mode at the
time a destination address is received. If bit 18 of the network configuration register is set,
frames can be received while transmitting in half-duplex mode.
Ethernet frames are transmitted a byte at a time least significant bit first. The first six bytes
(48 bits) of an Ethernet frame make up the destination address. The first bit of the
destination address, the LSB of the first byte of the frame, is the group/individual bit: this is
One for multicast addresses and Zero for unicast. The All Ones address is the broadcast
address, and a special case of multicast.
This implementation of the MACB supports recognition of four specific addresses. Each
specific address requires two registers, specific address register bottom and specific
address register top. Specific address register bottom stores the first four bytes of the
destination address and specific address register top contains the last two bytes. The
addresses stored can be specific, group, local or universal.
The destination address of received frames is compared against the data stored in the
specific address registers once they have been activated. The addresses are deactivated at
reset or when their corresponding specific address register bottom is written. They are
activated when specific address register top is written. If a receive frame address matches
an active address, the frame is copied to memory.
The following example illustrates the use of the address match registers for a MAC address
of 21:43:65:87:A9:CB.
Table 57.
Address match register
Preamble
55
SFD
D5
DA(Octet0 - LSB)
21
DA(Octet 1)
43
DA (Octet 2)
65
DA (Octet 3)
87
DA (Octet 4)
A9
DA(Octet5 - MSB)
CB
SA (LSB)
00
SA
00
SA
00
SA
00
SA
00
Doc ID 022640 Rev 3
169/368
Fast Ethernet ports (RMII0/RMII1/MII1)
Table 57.
RM0319
Address match register (continued)
SA (MSB)
43
SA (LSB)
21
The sequence above shows the beginning of an Ethernet frame. Byte order of transmission
is from top to bottom as shown. For a successful match to specific address 1, the following
address matching registers must be set up:
Base address + 0x98 0x87654321 (Bottom)
Base address + 0x9C 0x0000CBA9 (Top)
And for a successful match to the Type ID register the following should be set up:
Base address + 0xB8 0x00004321
See IEEE Standard 802-2001, Clause 9 for a detailed description of 802 addressing.
Broadcast address
The broadcast address of 0xFFFFFFFFFFFF is recognised if the no broadcast bit in the
network configuration register is zero.
Hash addressing
The hash address register is 64 bits long and takes up two locations in the memory map.
The least significant bits are stored in hash register bottom and the most significant bits in
hash register top.
The unicast hash enable and the multicast hash enable bits in the network configuration
register enable the reception of hash matched frames. The destination address is reduced
to a 6 bit index into the 64 bit hash register using the following hash function. The hash
function is an XOR of every sixth bit of the destination address.
hash_index[5] = da[5] ^ da[11] ^ da[17] ^ da[23] ^ da[29] ^ da[35] ^ da[41] ^ da[47]
hash_index[4] = da[4] ^ da[10] ^ da[16] ^ da[22] ^ da[28] ^ da[34] ^ da[40] ^ da[46]
hash_index[3] = da[3] ^ da[09] ^ da[15] ^ da[21] ^ da[27] ^ da[33] ^ da[39] ^ da[45]
hash_index[2] = da[2] ^ da[08] ^ da[14] ^ da[20] ^ da[26] ^ da[32] ^ da[38] ^ da[44]
hash_index[1] = da[1] ^ da[07] ^ da[13] ^ da[19] ^ da[25] ^ da[31] ^ da[37] ^ da[43]
hash_index[0] = da[0] ^ da[06] ^ da[12] ^ da[18] ^ da[24] ^ da[30] ^ da[36] ^ da[42]
da[0] represents the least significant bit of the first byte received, that is, the
multicast/unicast indicator, and da[47] represents the most significant bit of the last byte
received.
If the hash index points to a bit that is set in the hash register then the frame will be matched
according to whether the frame is multicast or unicast.
A multicast match will be signalled if the multicast hash enable bit is set. da[0] is 1 and the
hash index points to a bit set in the hash register.
A unicast match will be signalled if the unicast hash enable bit is set. da[0] is 0 and the hash
index points to a bit set in the hash register.
170/368
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
To receive all multicast frames, the hash register should be set with all ones and the
multicast hash enable bit should be set in the network configuration register.
External address matching
As an alternative to using the built in frame filtering functionality, a user may implement their
own external frame filtering block.The external address input signal (eam) is provided for
this purpose and enabled by bit 9 in the network configuration register.
If the eam signal is asserted before 16 bytes have been received the frame will be copied to
memory.
Copy all frames (or Promiscuous Mode)
If the copy all frames bit is set in the network configuration register then all non-errored
frames will be copied to memory. For example, frames that are too long, too short, have FCS
errors or have rx_er asserted during reception will be discarded and all others will be
received. Frames with FCS errors are copied to memory if bit 19 in the network
configuration register is set.
Type ID checking
The contents of the type_id register are compared against the length/type ID of received
frames (that is. bytes 13 and 14). Bit 22 in the receive buffer descriptor status is set if there
is a match. The reset state of this register is zero which is unlikely to match the length/type
ID of any valid Ethernet frame.
Note:
A type ID match does not affect whether a frame is copied to memory.
VLAN support
An Ethernet encoded 802.1Q VLAN tag looks like this.
:
TPID (Tag Protocol Identifier) 16 bits
TCI (Tag Control Information) 16 bits
0x8100
First 3 bits priority, then CFI bit, last 12 bits VID
The VLAN tag is inserted at the 13th byte of the frame adding an extra four bytes to the
frame.
If the VID (VLAN identifier) is null (0x000) this indicates a priority-tagged frame.
The MAC can support frame lengths up to 1536 bytes, 18 bytes more than the original.
Ethernet has a maximum frame length of 1518 bytes. This is achieved by setting bit 8 in the
network configuration register.
The following bits in the receive buffer descriptor status word give information about VLAN
tagged frames:●
Bit 21 set if receive frame is VLAN tagged (that is. type id of 0x8100)
●
Bit 20 set if receive frame is priority tagged (that is. type id of 0x8100 and null VID). (If
bit 20 is set bit 21 will be set also.)
●
Bit 19, 18 and 17 set to priority if bit 21 is set
●
Bit 16 set to CFI if bit 21 is set
Doc ID 022640 Rev 3
171/368
Fast Ethernet ports (RMII0/RMII1/MII1)
RM0319
Wake-on LAN support
The receive block supports wake-on LAN by detecting the following events on incoming
receive frames:
●
Magic packet
●
ARP request to the device IP address
●
Specific address 1 filter match
●
Multicast hash filter match
If one of these events occurs wake-on LAN detection is indicated by asserting the wol output
pin for 64 rx_clk cycles. These events can be individually enabled through bits[19:16] of the
wake-on LAN register. Also, for wake-on LAN detection to occur receive enable must be set
in the network control register, however a receive buffer does not have to be available.
wol assertion due to ARP request, specific address 1 or multicast filter events will occur
even if the frame is errored. For magic packet events, the frame must be correctly formed
and error free.
A magic packet event is detected if all of the following are true:
●
Magic packet events are enabled through bit 16 of the wake-on LAN register
●
The frame is correctly formed with no errors
●
The frame contains at least 6 bytes of 0xFF for synchronisation
●
There are 16 repetitions of the contents of specific address 1 register immediately
following the synchronisation.
An ARP request event is detected if all of the following are true:
●
ARP request events are enabled through bit 17 of the wake-on LAN register
●
Broadcasts are allowed by bit 5 in the network configuration register
●
The frame has a broadcast destination address (bytes 1 to 6)
●
The frame has a typeID field of 0x0806 (bytes 13 and 14)
●
The frame has an ARP operation field of 0x0001 (bytes 21 and 22)
●
The least significant 16 bits of the frame ARP target protocol address (bytes 41 and 42)
match the value programmed in bits[15:0] of the wake-on LAN register.
The decoding of the ARP fields adjusts automatically if a VLAN tag is detected within the
frame. The reserved value of 0x0000 for the Wake on LAN target address value will not
cause an ARP request event, even if matched by the frame.
A specific address 1 filter match event will occur if all of the following are true:
●
Specific address 1 events are enabled through bit 18 of the wake-on LAN register
●
The frame destination address matches the value programmed in the specific address
1 registers
A multicast filter match event will occur if all of the following are true:
172/368
●
Multicast hash events are enabled through bit 19 of the wake-on LAN register
●
Multicast hash filtering is enabled through bit 6 of the network configuration register
●
The frame destination address matches against the multicast hash filter
●
The frame destination address is not a broadcast
Doc ID 022640 Rev 3
RM0319
13.5
Fast Ethernet ports (RMII0/RMII1/MII1)
Interrupts
There are 14 interrupt conditions that are detected within the MACB. The common interrupt
(which is an ORed version of the 14 interrupts) and the Wake-Up on LAN (won) interrupt
from the two MACBs are all ORed and connected to line 1 of the Vectored Interrupt
Controller (VIC). For the source of interrupt on line 1 of the VIC, you can refer to the Interrupt
status register (0xB300_0004) description which is external to the MACB blocks. This a
read-only register and as soon as the interrupt is cleared at its source, the status is updated
in this register.
This single interrupt is passed through a further level of interrupt collection (Common
Interrupt Status Register). On receipt of the interrupt signal, the CPU enters the interrupt
handler. To ascertain which interrupt has been generated, read the external Common
Interrupt Status Register and then the internal Interrupt Status Register.
Note:
The Interrupt Status Register internal to the MAC will clear itself when read.
At reset all interrupts are disabled. To enable an interrupt, write to interrupt enable register
with the pertinent interrupt bit set to 1. To disable an interrupt, write to interrupt disable
register with the pertinent interrupt bit set to 1. To check whether an interrupt is enabled or
disabled, read interrupt mask Register: if the bit is set to 1, the interrupt is disabled.
13.6
Programming examples
Prior to configuring and initializing the MACB, the interface signals must be enabled on the
external pins. The procedure for enabling the interface depends on the configuration mode
of the shared PL_GPIO pins.
Refer to the datasheet for a description of the related configuration modes (Automation
Networking mode, Automation expansion mode, Extended mode and Small Printer mode).
13.6.1
Enabling the MII interface
1.
To enable MII:
In “Mode 2 MII Automation Networking" mode:
a)
Check bit [0] in the RASCFG Extended Control Register (0xB3000018) is set to '0'
b)
Write 0x1 to bits [2:0] in the RASCFG Control Register (0xB3000010)
In “Extended" mode”
a)
Write 0x1 to bit [0] in the RASCFG Extended Control Register (0xB3000018)
b)
Check bit [19:18] is set to '00' in RASCFG Extended Control Register
(0xB3000018)
c)
Configure "IP Port select for GPIO_x to GPIO_y in the RASCFG Extended Mode
Register" (0xB30000A4 - 0xB30000CC)
2. Go to Initializing and configuring MACB on page 174
Doc ID 022640 Rev 3
173/368
Fast Ethernet ports (RMII0/RMII1/MII1)
13.6.2
RM0319
Enabling the RMII interface
1.
Enable RMII in "Extended" mode
a)
write 0x1 to bit [0] in the RASCFG Extended Control Register (0xB3000018)
For RMII0: write 0x1 to bits [17:16] in the RASCFG Extended Control Register
(0xB3000018)
For RMII1: write 0x1 to bits [19:18] in the RASCFG Extended Control Register
(0xB3000018)
b)
2.
13.6.3
Configure the RASCFG "IP Port select for GPIO_x to GPIO_y in Extended Mode”
registers (0xB30000A4 - 0xB30000CC)
Go to Initializing and configuring MACB on page 174
Initializing and configuring MACB
The initialization of the MACB configuration (for example. loop-back mode, frequency ratios)
must be done while transmit and receive circuits are disabled. See the description of the
network control register and network configuration register earlier in this document.
The size of the system memory is 1GB and the address range is from (0x0000_0000 0x3FFF_FFFF). The DMA interface (AHB Master) can access this space to store the
transmit and receive buffers and queues.
To change loop-back mode, follow these steps:
1.
Write to network control register to disable transmit and receive circuits.
2.
Write to network control register to change loop-back mode.
3.
Write to network control register to re-enable transmit or receive circuits.
Note:
These writes to network control register cannot be combined in any way.
13.6.4
Creating a receive buffer list
Receive data is written to areas of data (buffers) in the system memory. These buffers are
listed in another data structure that also resides in the main memory. This data structure
(receive buffer queue) is a sequence of descriptor entries as defined in receive buffer
descriptor entry. It points to this data structure:
174/368
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
Figure 54. Receive buffer list
Receive buffer queue pointer
(MAC Register)
Receive Buffer 0
Receive Buffer 1
Receive Buffer N
Receive Buffer descriptor list
(In memory)
Doc ID 022640 Rev 3
(In memory)
175/368
Fast Ethernet ports (RMII0/RMII1/MII1)
RM0319
To create this list of buffers:
13.6.5
1.
Allocate a number (n) of buffers of 128 bytes in system memory.
2.
Allocate an area of 2n words for the receive buffer descriptor entry in system memory
and create n entries in this list. Mark all entries in this list as owned by MACB, which
means that the bit 0 of word 0 should be set to 0.
3.
If less than 1024 buffers are defined, the last descriptor must be marked with the wrap
bit (bit 1 in word 0 set to 1).
4.
Write address of receive buffer descriptor entry to MACB register receive_buffer queue
pointer.
5.
The receive circuits can then be enabled by writing to the address recognition registers
and then to the network control register.
Creating a transmit buffer list
Transmit data is read from areas of data (buffers) in the system memory. These buffers are
listed in another data structure that also resides in the main memory. This data structure
(transmit buffer queue) is a sequence of descriptor entries as defined in the transmit buffer
descriptor entry. It points to this data structure.
To create this list of buffers:
1.
Allocate a number (n) of buffers of between 1 and 2047 bytes of data to be transmitted
in system memory. Up to 128 buffers per frame are allowed.
2.
Allocate an area 2n words for the transmit buffer descriptor entry in system memory
and create N entries in this list. Mark all entries in this list as owned by MACB, i.e. bit 31
of word 1 set to 0.
3.
If fewer than 1024 buffers are defined, the last descriptor must be marked with the wrap
bit (bit 30 in word 1) set to 1.
4.
Write address of transmit buffer descriptor entry to MACB register transmit_buffer
queue pointer.
5.
The transmit circuits can then be enabled by writing to the network control register.
The MACB register-pair hash address and the four specific address register pairs must be
written with the required values. Each register pair comprises of a bottom register and top
register with the bottom register being written first. The address matching is disabled for a
particular register pair after the bottom-register has been written and re-enabled when the
top register is written. See the Address checking block for details of address matching. Each
register pair may be written at any time, regardless of whether the receive circuits are
enabled or disabled.
176/368
Doc ID 022640 Rev 3
RM0319
Fast Ethernet ports (RMII0/RMII1/MII1)
Figure 55. Transmit buffer list
Destination Address
(In frame)
Hash Address Reg(MAC)
#
Specific Address 1
0
match 1
Specific Address 2
0
match 2
Specific Address 3
0
match 3
0
match 4
Specific Address 4
13.6.6
match hash
Using the PHY maintenance register
The PHY maintenance register enables the MACB to communicate with a PHY by means of
the MDIO interface. It is used during auto-negotiation to ensure that the MACB and the PHY
are configured for the same speed and duplex configuration.
The PHY maintenance register is implemented as a shift register. Writing to the register
starts a shift operation which is signalled as complete when bit two is set in the network
status register (about 2000 pclk cycles later when bits ten and eleven are set to 10 in the
network configuration register). An interrupt is generated as this bit is set. During this time,
the MSB of the PHY maintenance register is output on the mdio_out pin and the LSB
updated from the mdio_in pin with each mdc cycle. This causes the transmission of a PHY
management frame on MDIO. See Section 22.2.4.5 of the IEEE 802.3 Standard.
Reading during the shift operation will return the current contents of the shift register. At the
end of the management operation the bits will have shifted back to their original locations.
For a read operation the data bits will be updated with data read from the PHY. It is
important to write the correct values to the register to ensure a valid PHY management
frame is produced. mdc should not toggle faster than 2.5 MHz (minimum period of 400 ns).
mdc is generated by dividing down pclk. Three bits in the network configuration register
determine by how much pclk should be divided to produce mdc. The default is 32 which is
acceptable for pclk running up to 80 MHz.
At the chip level mdio_out, mdio_en and mdio_in connect to a single tri-state I/O buffer
called MDIO. Alternatively MDIO may be implemented as a pull-down. In this case the
enable to the pull-down should be driven with ~mdio_out and mdio_en.
Doc ID 022640 Rev 3
177/368
Fast Ethernet ports (RMII0/RMII1/MII1)
13.6.7
RM0319
Transmitting frames in MII/RMII mode
To set up a frame for transmission:
13.6.8
1.
Enable transmit in the network control register.
2.
Allocate an area of system memory for transmit data. This does not have to be
contiguous, varying byte lengths can be used as long as they conclude on byte
borders.
3.
Set-up the transmit buffer list.
4.
Set the network control register to enable transmission and enable interrupts.
5.
Write data for transmission into these buffers.
6.
Write the address to transmit buffer descriptor queue pointer.
7.
Write control and length to word one of the transmit buffer descriptor entry.
8.
Write to the transmit start bit in the network control register.
Receiving frames in MII/RMII mode
When a frame is received and the receive circuits are enabled, the MACB checks the
address and, in the following cases, the frame is written to system memory:
1.
If it matches one of the four specific address registers.
2.
If it matches the hash address function.
3.
If it is a broadcast address (0xFFFFFFFFFFFF) and broadcasts are allowed.
4.
If the MACB is configured to copy all frames.
5.
If the EAM is asserted before four words have been loaded into the receive FIFO.
The register receive buffer queue pointer points to the next descriptor entry (see Receive
Buffer Descriptor Entry) and the MACB uses this as the address in system memory to write
the frame to. Once the frame has been completely and successfully received and written to
system memory, the MACB then updates the receive buffer descriptor entry with the reason
for the address match and marks the area as being owned by software. Once this is
complete an interrupt receive complete is set. Software is then responsible for handling the
data in the buffer and then releasing the buffer by writing the ownership bit back to 0. If the
MACB is unable to write the data at a rate to match the incoming frame, then an interrupt
receive overrun is set. If there is no receive buffer available, that is. the next buffer is still
owned by software, the interrupt receive buffer not available is set. If the frame is not
successfully received, a statistic register is incremented and the frame is discarded without
informing software.
178/368
Doc ID 022640 Rev 3
RM0319
14
MMC-SD card/SDIO controller
MMC-SD card/SDIO controller
This chapter describes the features of the MMC/SD/SDIO host controller and provides
programming information.
For technical details about the programmable registers, refer to the MMC/SD/SDIO
controller registers in the following companion document:
●
14.1
RM0321: SPEAr320S address map and registers
Overview
The MMC/SD/SDIO host controller conforms to the SD host controller standard specification
version 2.0. It handles SDIO/SD protocol at transmission level, packing data, adding cyclic
redundancy check (CRC), start/end bit and checking for transaction format correctness. The
host controller provides programmed IO and DMA data transfer method.
14.2
Main features
●
Meets SD Host Controller Standard Specification Version 2.0
●
Meets SDIO card specification version 2.0
●
Meets SD Memory Card Specification Draft version 2.0
●
Meets SD Memory Card Security Specification version 1.01
●
Meets MMC Specification version 3.31 and 4.2
●
Supports both DMA and Non-DMA mode of operation
●
Supports MMC Plus and MMC Mobile
●
Card Detection (Insertion / Removal)
●
Password protection of Cards
●
Host clock rate variable between 0 and 48 MHz
●
Supports 1-/4-/8-bit SD modes and SPI mode
●
Supports multimedia card interrupt mode
●
Allows card to interrupt host in 1bit, 4 bit, 8 bit SD modes and SPI mode.
●
Up to 100 Mbits per second data rate using 4 parallel data lines (SD4 bit mode)
●
Up to 416 Mbits per second data rate using 8 bit parallel data lines (SD8 bit mode)
●
Cyclic redundancy check CRC7 for command and CRC16 for data integrity
●
Designed to work with I/O cards, read-only cards and read/write cards
●
Error correction code (ECC) support for MMC4.2 cards
●
Supports read wait control, suspend/resume operation
●
Supports FIFO overrun and underrun condition by stopping SD clock
●
Conforms to AMBA specification AHB (2.0)
Doc ID 022640 Rev 3
179/368
MMC-SD card/SDIO controller
14.3
RM0319
Pins
Figure 56. SD/SDIO/MMC controller pins
SD_CLK
AHB SLAVE
DATA[7:0]
RAS_CFG
control register
AHB MASTER
SD_CMD
MMC_SD/SDIO
Controller
RAS_CLK_SYNT4
CLK48MHz
SD_CD
SD_LED
Interrupt to VIC (IRQ29)
Table 58.
Signal description
Group
Card interface
14.4
Signal name
Direction
Size
Description
SD_CLK
Out
1
Clock to external card
DATA[7:0]
In/Out
8
SD1/SD4/SD8: Data line
SD_CMD
In/Out
1
SD1/SD4/SD8: Command line
SD_WP
In
1
Active high. SD card write protect
SD_CD
In
1
Active low. Card detection for single
slot
SD_LED
Out
1
Cautions the user not to remove the
card while the SD card is being
accessed.
Functional overview
This section gives a functional overview of the host controller.
180/368
SD_WP
Doc ID 022640 Rev 3
RM0319
MMC-SD card/SDIO controller
Figure 57. MMC-SD/SDIO controller block diagram
AHB
Interface
SD
Registers
Bus Monitor
Synchronizer
AHB BUS
Power
Management
Data
FIFO
SD Protocol
Unit
Command
Control
Unit
SDIO2.0/
SDIO2.0 Mem
MMC 3.31/4.2
Data
Control
Unit
Clock
Control
The host controller can be used to control an external memory card via command protocol.
Data transfer can be performed either directly by the CPU (without using DMA) or using the
dedicated DMA unit of the memory card controller. Interrupts are generated to the ARM
Processor based on the values set in the interrupt status register and interrupt enable
registers. The clock generation block will generate the SD clock depending on the value
programmed by software in the clock control register. The CRC7 and CRC16 generators
calculate the CRC for command and data respectively to send the CRC to the SD card. The
CRC7 and CRC16 checker checks for any CRC error in the response and data sent by the
SD/SDIO card.
The host controller alternatively uses two dual-port 4KB FIFOs for read (data transferred
from card to processor) and write (data transferred from processor to card) transactions.
The SD_DATA[7:0] control logic block transmits data in the data lines during write
transaction and receives data in the data lines during read transaction.
The Command control logic block sends the command in the CMD line and receives the
response coming from the SD2.0/SDIO2.0/MMC4.2 card.
Doc ID 022640 Rev 3
181/368
MMC-SD card/SDIO controller
14.5
RM0319
Programming examples
This section explains some basic sequence flows of initialization and data transfer using the
memory card controller.
14.5.1
Detecting the SD card
Figure 58. SD card detection
Start
(1)
Enable Int of Card Detect
Card Detect Int occur
(2)
Clr Card Detect Int Status
(3)
Check
Card Inserted
Card Inserted is 0b,
then recognize as removal
Card Inserted is 1b,
then recognize as insertion
End
1.
182/368
To enable interrupt for card detection, write 1 to the following bits:
–
Card Insertion Status Enable in the Normal Interrupt Status Enable register
–
Card Insertion Signal Enable in the Normal Interrupt Signal Enable register
–
Card Removal Status Enable in the Normal Interrupt Status Enable register
–
Card Removal Signal Enable in the Normal Interrupt Signal Enable register
2.
When the host driver detects the card insertion or removal, clear its interrupt statuses.
If the card insertion interrupt is generated, write logic ‘1’ to card insertion in the normal
interrupt status register. If the card removal interrupt is generated, write logic ‘1’ to card
removal in the normal interrupt status register.
3.
Check the card inserted in the present state register. If the card inserted is logic ‘1’, the
host driver can supply the power and the clock to the SD card. If the card inserted is
logic ‘0’, the other executing processes of the host driver must be immediately closed.
Doc ID 022640 Rev 3
RM0319
14.5.2
MMC-SD card/SDIO controller
Supplying the SD clock
Figure 59. SD clock supply sequence
Start
(1)
Calculate a divisor for SD
clock frequency
(2)
Set SDCLK Frequency Select
and Internal Clock Enable
(3)
Internal Clock Stable = 0b
Check
Internal Clock Stable
Internal Clock Stable = 1b
(4)
Set SD Clock On
Supply SD Clock
End
1.
Calculate a divisor to determine the frequency of the SD clock.
2.
Set Internal Clock Enable and SDCLK Frequency Select in the Clock Control register.
3.
Check Internal Clock Stable in the Clock Control register. Repeat this step until Clock
Stable is logic ‘1’.
4.
Set SD Clock Enable in the Clock Control register to logic ‘1’.
The Host Controller starts to supply the SD Clock.
Doc ID 022640 Rev 3
183/368
MMC-SD card/SDIO controller
14.5.3
RM0319
Issuing a command
Figure 60. Command issue sequence
Start
CMD Line used
(1)
Check Command
Inhibit (CMD)
CMD Line free
(2)
Issue the command
with the busy?
Yes
Yes
(3)
Issue Abort
Command?
No
No
(4)
DAT Lone used
Check Command
Inhibit(DAT)
DAT Lone free
New command can be issued
(5)
Set Argument Reg
(6)
Set Command Reg
(7)
Command Complete Sequence
End
184/368
1.
Check Command Inhibit (CMD) in the Present State register. Repeat this step until
Command Inhibit (CMD) is logic ‘0’.
2.
If the Host Driver issues a SD Command with busy signal, go to step (3). If there is no
busy signal, go to step (5).
3.
If the Host Driver issues an abort command, go to step (5). In the case of no abort
command, go to step (4).
4.
Check Command Inhibit (DAT) in the Present State register. Repeat this step until
Command Inhibit (DAT) is set to logic ‘0’.
5.
Set the value of the command argument to the Argument register.
6.
Set the Command register.
7.
Perform the Command Completion Sequence (see Section 14.5.4 below).
Doc ID 022640 Rev 3
RM0319
14.5.4
MMC-SD card/SDIO controller
Completing a command
Figure 61. Command completion sequence
Start
(1)
Wait for
Command Complete Int
Command Complete Int occur
(2)
Clr Command Complete Status
(3)
Get Response Data
(4)
Command with
Transfer Complete Int?
(5)
Wait for
Transfer Complete Int
(6)
No
Transfer Complete Int occur
Clr Transfer Complete Status
(7)
Check
Response Data
(8)
No Error
Return Status
(No Error)
Error
(9)
Return Status
(Response Content Error)
End
Doc ID 022640 Rev 3
185/368
MMC-SD card/SDIO controller
186/368
RM0319
1.
Wait for the Command Complete Interrupt. If the Command Complete Interrupt has
occurred, go to step (2).
2.
Write logic ‘1’ to Command Complete in the Normal Interrupt Status register to clear
this bit.
3.
Read the Response register and get necessary information of the issued command.
4.
Judge whether the command uses the Transfer Complete Interrupt or not. If it uses
Transfer Complete, go to step (5). If not, go to step (7).
5.
Wait for the Transfer Complete Interrupt. If the Transfer Complete Interrupt has
occurred, go to step (6).
6.
Write logic ‘1’ to Transfer Complete in the Normal Interrupt Status register to clear this
bit.
7.
Check for errors in Response Data. If there is no error, go to step (8). If there is an
error, go to step (9).
8.
Return Status of “No Error”.
9.
Return Status of “Response Contents Error”.
Doc ID 022640 Rev 3
RM0319
14.5.5
MMC-SD card/SDIO controller
Transferring data without DMA
Figure 62. Data transaction sequence without DMA
Start
(1)
(5)
Set Command Reg
Set Block Size Reg
(6)
(2)
Wait for
Command Complete Int
Set Block Count Reg
Command Complete Int occur
(7)
(3)
Set Argument Reg
Clr Command Complete Status
(4)
(8)
Set Transfer Mode Reg
Write
Get Response Data
(9)
Read
Write or read ?
(10)
(14)
Wait for
Buffer Write Ready Int
Buffer Write Ready
(11)
occur
Wait for
Buffer Read Ready Int
(15)
Buffer Read Ready occur
Clr Buffer Write Ready Status
Clr Buffer Read Ready Status
(12)
(16)
Set Block Data
Get Block Data
Yes
(13)
Yes (17)
More Blocks?
More Blocks?
No
No
(18)
Single or Multi
Block Transfer
(19)
(21)
Wait for
Transfer Complete Int
(20)
Infinite Block Transfer
Single/Multi/
Infinite Block
Transfer?
Abort Transaction
Transfer Complete Int occur
Clr Transfer Complete Status
End
Doc ID 022640 Rev 3
187/368
MMC-SD card/SDIO controller
RM0319
1.
Set the value to Block Size register.
2.
Set the value to Block Count register.
3.
Set the argument value to Argument register.
4.
Set the value to the Transfer Mode register. The host driver determines Multi/Single
Block Select, Block Count Enable, Data Transfer Direction, Auto CMD12 Enable and
DMA Enable.
5.
Set the value to Command register.
6.
Wait for the Command Complete Interrupt.
7.
Write logic ‘1’ to the Command Complete in the Normal Interrupt Status register for
clearing this bit.
8.
Read Response register and get necessary information of the issued command.
9.
In the case where this sequence is for write to a card, go to step (10). In case it is for
read from a card, go to step (14).
10. Wait for Buffer Write Ready Interrupt.
11. Write logic ‘1’ to the Buffer Write Ready in the Normal Interrupt Status register for
clearing this bit.
12. Write block data to Buffer Data Port register.
13. Repeat until all blocks are sent and then go to step (18).
14. Wait for the Buffer Read Ready Interrupt.
15. Write logic ‘1’ to the Buffer Read Ready in the Normal Interrupt Status register for
clearing this bit.
16. Read block data from the Buffer Data Port register.
17. Repeat until all blocks are received and then go to step (18).
18. If this sequence is for Single or Multiple Block Transfer, go to step (19). In case of
Infinite Block Transfer, go to step (21).
19. Wait for Transfer Complete Interrupt.
20. Write logic ‘1’ to the Transfer Complete in the Normal Interrupt Status register for
clearing this bit.
21. Perform the sequence for Abort Transaction
14.5.6
Transferring data with SDMA
Note:
When using DMA transfer care must be taken to ensure the system memory addresses are
not protected by the MMU, and that cache coherency with the CPU core is managed by
software.
188/368
Doc ID 022640 Rev 3
RM0319
MMC-SD card/SDIO controller
Figure 63. Data transaction sequence with SDMA
Start
(1)
Set System Address Reg
(2)
(10)
Wait for
Transfer Complete Int
and DMA Int
Set Block Size Reg
(3)
(11)
Set Block Count Reg
Check Interrupt
Status
(4)
(12)
Set Argument Reg
Transfer
Complete Int
occur
DMA Int occur
Clr DMA Interrupt Status
(5)
Set Transfer Mode Reg
(13)
Set System Address Reg
(6)
(14)
Set Command Mode Reg
Clr Transfer Complete Status
Clr DMA Interrupt Status
(7)
Wait for
Command Complete Int
(8)
Command
Complete Int occur
End
Clr Command Complete Status
(9)
Get Response Data
1.
Set the SDMA System Address register which contains the system memory address.
2.
Set the value to the Block Size register.
3.
Set the value to the Block Count register.
4.
Set the argument value to the Argument register.
5.
Set the value to the Transfer Mode register. The host driver determines Multi/Single
Block Select, Block Count Enable, Data Transfer Direction, Auto CMD12 Enable and
DMA Enable.
6.
Set the value to the Command register.
7.
Then wait for the Command Complete Interrupt.
8.
Write logic ‘1’ to the Command Complete in the Normal Interrupt Status register to
clear bit.
Doc ID 022640 Rev 3
189/368
MMC-SD card/SDIO controller
9.
RM0319
Read Response register and get necessary information of the issued command.
10. Wait for the Transfer Complete Interrupt and DMA Interrupt.
11. If Transfer Complete is set to logic ‘1’, go to Step (14) else if DMA Interrupt is set to
logic ‘1’, go to Step 12. Transfer Complete is higher priority than DMA Interrupt.
12. Write logic ‘1’ to the DMA Interrupt in the Normal Interrupt Status register to clear this
bit.
13. Set the next system address of the next data position to the System Address register
and go to Step (10).
14. Write logic ‘1’ to the Transfer Complete and DMA Interrupt in the Normal Interrupt
Status register to clear this bit.
14.5.7
Transferring data with ADMA
Figure 64. Data transaction sequence with ADMA
Start
(1)
Create Discriptor table
(2)
(11)
Wait for
Transfer Complete Int
and ADMA Error Int
Set ADMA System Address Reg
(3)
(12)
Set Block Size Reg
ADMA Error Int occurs
Check Interrupt
Status
(4)
(13)
Set Block Count Reg
(5)
Transfer Complete Int occurs
(14)
Clr Transfer Complete
Clr ADMA Error
Interrupt Status
Interrupt Status
Set Argument Reg
(15)
Abort ADMA
Operation
(6)
Set Transfer Mode Reg
(7)
End
Set Command Reg
(8)
Wait for
Command Complete Int
(9)
Command
Complete Int occur
Clr Command Complete Status
(10)
Get Response Data
190/368
Doc ID 022640 Rev 3
RM0319
MMC-SD card/SDIO controller
1.
Create Descriptor table for ADMA in the system memory
2.
Set the Descriptor address for ADMA in the ADMA System Address register.
3.
Set the value corresponding to the Block Size register.
4.
Set the value corresponding to the Block Count register. If the Block Count Enable in
the Transfer Mode register is set to logic ‘1’, the total data length can be designated by
the Block Count register and the Descriptor Table. These two parameters must indicate
the same data length. However, the transfer length is limited by the 16-bit Block Count
register. If the Block Count Enable in the Transfer Mode register is set to logic ‘0’, the
total data length is designated not by the Block Count register, but by the Descriptor
Table. In this case, ADMA reads more data than the length programmed in the
descriptor from the SD card. The read operation of extra data is aborted
asynchronously and the extra read data is discarded when the ADMA is completed.
5.
Set the argument value to the Argument register.
6.
Set the value to the Transfer Mode register. The host driver determines Multi/Single
Block Select, Block Count Enable, Data Transfer Direction, Auto CMD12 Enable and
DMA Enable.
7.
Set the value to the Command register.
8.
Wait for the Command Complete Interrupt.
9.
Write logic ‘1’ to the Command Complete in the Normal Interrupt Status register to
clear this bit.
10. Read the Response register and get necessary information about the issued
command.
11. Wait for the Transfer Complete Interrupt and ADMA Error Interrupt.
12. If Transfer Complete is set to logic ‘1’, go to Step (13), else if ADMA Error Interrupt is
set to logic ‘1’, so go to Step (14).
13. Write logic ‘1’ to the Transfer Complete Status in the Normal Interrupt Status register to
clear this bit.
14. Write logic ‘1’ to the ADMA Error Interrupt Status in the Error Interrupt Status register to
clear this bit.
15. Abort ADMA operation. SD card operation should be stopped by issuing abort
command.
Doc ID 022640 Rev 3
191/368
MMC-SD card/SDIO controller
14.5.8
RM0319
Aborting the transaction
Figure 65. Abort transaction sequence
Start
Start
(1)
(1)
Issue Abort Command
(2)
Set Software Reset For
DAT Line(DR) and CMD
Line(CR)
(3)
Check
DR and
CR
CR=1 or
DR=1
(5)
Set Stop at Block Gap
Request
(2)
Set Software Reset For
DAT Line(DR) and CMD
Line(CR)
Wait for
Transfer Complete Int
(3)
Transfer
Complete Int occur
Clr Transfer Complete
Status
(6)
Check
DR and
CR
CR=0 and
DR=0
(4)
CR=0 and
DR=0
Issue Abort
Command
CR=1 or
DR=1
End
End
Asynchronous Abort
Sequence
Synchronous Abort
Sequence
An abort transaction is performed by issuing CMD12 for a SD memory card and CMD52 for
a SDIO card. The host controller can do an abort transaction to stop infinite block transfers
or stop transfers while a multiple block transfer is executing.
In an asynchronous abort sequence, the host controller can issue an abort command at
anytime unless Command Inhibit (CMD) in the Present State register is set to logic ‘1’. In a
synchronous abort, the host controller must issue an Abort Command after the data transfer
stopped by using Stop At Block Gap Request in the Block Gap Control register.
192/368
Doc ID 022640 Rev 3
RM0319
15
Controller area network ports (CAN)
Controller area network ports (CAN)
This chapter focuses on CAN functionality and operation.
For technical details about the programmable registers related to the CAN, refer to the CAN
registers in the following companion document:
●
15.1
RM0321: SPEAr320S address map and registers
Overview
SPEAr320S provides two independent CAN Controllers that have an AMBA compatible
interface and conform to CAN protocol version 2.0 (both part A and B).
15.2
15.3
Main features
●
Supports CAN protocol version 2.0 part A and B
●
Bit rates up to 1 MBit/s
●
32 message objects(136x32 message RAM)
●
Each message object has its own identifier mask
●
Maskable interrupt (level sensitive, edge sensitive)
●
Programmable loop-back mode for self-test operation
●
Disabled automatic retransmission mode for time triggered CAN applications
●
Interfaces to the AMBA APB bus from ARM
Functional description
Figure 66. CAN controller block diagram
APB
Interface
Module
Interface
Registers
Message
RAM
CAN
CORE
TX
RX
Interrupt
Message Handler
CAN
The CAN core performs communication according to the CAN protocol version 2.0, part A
and B. The bit rate can be programmed to values up to 1MBit/s depending on the used
technology. For the connection to the physical layer, additional transceiver hardware is
Doc ID 022640 Rev 3
193/368
Controller area network ports (CAN)
RM0319
required. For communication on a CAN network, individual message objects are configured.
The message objects and identifier masks for acceptance filtering of received messages are
stored in the Message RAM. All functions concerning the handling of messages are
implemented in the Message Handler. Those functions are the acceptance filtering, the
transfer of messages between the CAN core and the message RAM, and the handling of
transmission requests as well as the generation of the module interrupt. The register set of
the CAN can be accessed directly by an external CPU via the module interface. These
registers are used to control/configure the CAN Core and the message handler and to
access the message RAM.
As shown in Figure 66: CAN controller block diagram, these are the main CAN core
interfaces:
15.3.1
●
CAN core: this is a CAN Protocol Controller and Rx/Tx Shift register for serial/parallel
conversion of messages.
●
Message RAM: Stores message objects and Identifier Masks.
●
Registers: All registers used to control and configure the CAN module
●
Message handler state machine: this is the state machine that controls the data
transfer between the Rx/Tx Shift register of the CAN core and the Message RAM as
well as the generation of interrupts as programmed in the control and configuration
registers. See also: Section 15.3.1.
●
Module interface: Interfaces to the AMBA APB bus from ARM
Message handler state machine
The message handler controls the data transfer between the Rx/Tx Shift register of the CAN
Core, the Message RAM and the IFx registers.
The Message Handler FSM controls the following functions:
●
Data transfer from IFx register to the message RAM
●
Data transfer from message RAM to the IFx registers
●
Data transfer from Shift register to the message RAM
●
Data transfer from message RAM to Shift register
●
Data transfer from Shift register to the acceptance filtering unit
●
Scanning of message RAM for a matching message object
●
Handling of TxRqst flags
●
Handling of interrupts
Data transfer from/to message RAM
When the CPU initiates a data transfer between the IFx registers and the message RAM,
the message handler sets the Busy bit in the respective Command register to ‘1’. After the
transfer has been completed, the Busy bit is set back to ‘0’ (see Figure 67).
The respective Command Mask register specifies whether a complete message object or
only parts of it will be transferred. Due to the structure of the message RAM it is not possible
to write single bits/bytes of one message object, it is always necessary to write a complete
message object into the message RAM. Therefore, the data transfer from the IFx registers
to the message RAM requires a read-modify-write cycle. First, the parts of the message
object that are not to be changed are read from the Message RAM, and then the complete
contents of the Message Buffer registers are into the message object.
194/368
Doc ID 022640 Rev 3
RM0319
Controller area network ports (CAN)
Figure 67. Data transfer between IFx registers and message RAM
Start
No
Write Command Request Register
Yes
Busy = 1
CAN_WAIT_B = 0
Yes
No
WR/RD = 1
Read Message Object to IFx
Read Message Object to IFx
Write IFx to Message RAM
Busy = 0
CAN_WAIT_B = 1
After the partial write of a message object, that Message Buffer registers that are not
selected in the Command Mask register will set to the actual contents of the selected
message object.
After the partial read of a message object, those Message Buffer registers that are not
selected in the Command Mask register will be left unchanged.
Transmission of messages
If the shift register of the CAN core cell is ready for loading and there is no data transfer
between the IFx registers and the message RAM, the MsgVal bits in the Message Valid
register and the TxRqst bits in the Transmission Request register are evaluated. The valid
message object with the highest priority pending transmission request is loaded into the
Shift register by the message handler and the transmission is started. The message object
NewDat bit is reset.
After a successful transmission and if no new data has been written to the message object
(NewDat = ‘0’) since the start of the transmission, the TxRqst bit resets. If TxIE is set, IntPnd
Doc ID 022640 Rev 3
195/368
Controller area network ports (CAN)
RM0319
will be set after a successful transmission. If the CAN has lost the arbitration or if an error
occurred during the transmission, the message will be retransmitted as soon as the CAN
bus is free again. If meanwhile the transmission of a message with higher priority has been
requested, the messages will be transmitted in the order of their priority.
Acceptance filtering of received messages
When the arbitration and control field (Identifier + IDE + RTR + DLC) of an incoming
message is completely shifted into the Rx/Tx Shift register of the CAN Core, the message
handler FSM starts the scanning of the message RAM for a matching valid message object.
To scan the message RAM for a matching message object, the acceptance filtering unit is
loaded with the arbitration bits from the CAN core shift register. Then, the arbitration and
mask fields (including MsgVal, UMask, NewDat, and EoB) of message object 1 are loaded
into the acceptance filtering unit and compared with the arbitration field from the shift
register. This is repeated with each following message object until a matching message
object is found or until the end of the message RAM is reached.
If a match occurs, the scanning is stopped and the message handler FSM proceeds
depending on the type of frame (data frame or remote frame) received.
Reception of data frame
The message handler FSM stores the message from the CAN core Shift register into the
respective message object in the message RAM. Not only the data bytes, but all arbitration
bits and the data length code are stored into the corresponding message object. This is
implemented to keep the data bytes connected with the identifier even if arbitration mask
registers are used.
The NewDat bit is set to indicate that new data (not yet seen by the CPU) has been
received. The CPU should reset NewDat when it reads the message object. If at the time of
the reception the NewDat bit was already set, MsgLst is set to indicate that the previous
data (supposedly not seen by the CPU) is lost. If the RxIE bit is set, the IntPnd bit is set,
causing the Interrupt register to point to this message object.
The TxRqst bit of this message object is reset to prevent the transmission of a remote
frame, while the requested data frame has just been received.
Reception of remote frame
When a remote frame is received, three different configurations of the matching message
object have to be considered:
1.
Dir = ‘1’ (direction = transmit), RmtEn = ‘1’, UMask = ‘1’ or ’0’
At the reception of a matching remote frame, the TxRqst bit of this message object is
set. The rest of the message object remains unchanged.
2.
Dir = ‘1’ (direction = transmit), RmtEn = ‘0’, UMask = ’0’
At the reception of a matching remote frame, the TxRqst bit of this message object
remains unchanged. The remote frame is ignored.
3.
Dir = ‘1’ (direction = transmit), RmtEn = ‘0’, UMask = ’1’
At the reception of a matching remote frame, the TxRqst bit of this message object is
reset. The arbitration and control field (Identifier + IDE + RTR + DLC) from the shift
register is stored into the message object in the message RAM and the NewDat bit of
this message object is set. The data field of the message object remains unchanged;
the remote frame is treated similar to a received data frame.
196/368
Doc ID 022640 Rev 3
RM0319
Controller area network ports (CAN)
Receive/Transmit Priority
The receive/transmit priority of the message object is attached to the message number.
Message object 1 has the highest priority, while message object 32 has the lowest priority. If
more than one transmission requests are pending, they are serviced due to the priority of
the corresponding message object.
15.4
Operation
15.4.1
Initializing the software
The software initialization is started by setting the bit Init in the CAN Control register, either
by software or by a hardware reset, or by going Bus_Off.
While Init is set, any message transfer from and to the CAN bus is stopped, the status of the
CAN bus output CAN_TX is recessive (HIGH). The counters of the EML are unchanged.
Setting Init does not change any configuration register.
To initialize the CAN Controller, the CPU has to set up the Bit Timing register and each
message object. If a message object is not needed, it is sufficient to set its MsgVal bit to “not
valid”. Otherwise,the whole message object has to be initialized.
To enable access to the Bit Timing register and to the BRP Extension register for the
configuration of the bit timing, you must set both Init and CCE bits in the CAN Control
register.
Resetting Init (by CPU only) finishes the software initialization. Afterwards, the Bit Stream
Processor BSP synchronizes itself to the data transfer on the CAN bus by waiting for the
occurence of a sequence of 11 consecutive recessive bits (= Bus Idle) before it can take
part in bus activities, and then starts the message transfer.
The initialization of the message objects is independent of the Init and can be done on the
fly, but the message objects should all be configured to particular identifiers or set to “not
valid” before the BSP starts the message transfer.
To change the configuration of a message object during normal operation, the CPU has to
start by setting MsgVal to “not valid”. When the configuration is completed, MsgVal is set to
valid again.
15.4.2
Transferring messages
Once the CAN controller is initialized and Init is reset to zero, the CAN core synchronizes
itself to the CAN bus and starts the message transfer.
Received messages are stored into their appropriate message objects if they pass the
message handler’s acceptance filtering. The whole message including all arbitration bits,
DLC and eight data bytes is stored into the message object. If the identifier mask is used,
the arbitration bits which are masked to “don’t care” may be overwritten in the message
object.
The CPU may read or write each message any time via the interface registers, the message
handler guarantees data consistency in case of concurrent accesses.
Messages to be transmitted are updated by the CPU. If a permanent message object
(arbitration and control bits set up during configuration) exists for the message, only the data
bytes are updated and then TxRqst bit with NewDat bit are set to start the transmission. If
Doc ID 022640 Rev 3
197/368
Controller area network ports (CAN)
RM0319
several transmit messages are assigned to the same Message object (when the number of
message object is not sufficient), the whole message object has to be configured before the
transmission of this message is requested.
The transmission of any number of message objects may be requested at the same time,
they are transmitted subsequently according to their internal priority. Messages may be
updated or set to not valid any time, even when their requested transmission is still pending.
The old data will be discarded when a message is updated before its pending transmission
has started.
Depending on the configuration of the message object, the transmission of a message may
be requested autonomously by the reception of a remote frame with a matching identifier.
15.4.3
Using the disabled automatic retransmission mode
According to the CAN Specification (see ISO11898, Recovery Management section), the
CAN controller provides means for automatic retransmission of frames that have lost
artbitration or that have been disturbed by errors during transmission. The frame
transmission service will not be confirmed to the user before the transmission is
successfully completed. By default, the means for automatic retransmission is enabled. It
can be disabled in order to allow CAN to work within a time triggered CAN environment
(TTCAN, see ISO11898-1).
The disabled automatic retransmission mode is enabled by programming the DAR bit in the
CAN Control register to one. In this operation mode, the programmer has to consider the
different behaviour of TxRqst and NewDat bits in the control register of the message buffers:
●
When a transmission starts, the TxRqst bit of the respective message buffer is reset,
while the NewDat bit remains set.
●
When the transmission completed successfully, the NewDat bit is reset.
When a transmission has failed (lost arbitration or error), the NewDat bit remains set. To
restart the transmission, the CPU has to set TxRqst back to one.
15.4.4
Using the test mode
To enter the test mode, the Test bit of the CAN Control register should be set to one. In test
mode, the bits Tx1, Tx0, LBack, Silent and Basic in the test register are writable. Bit Rx
monitors the state of CAN_RX pin and therefore is only readable. All test register functions
are disabled when the Test bit is reset to zero.
15.4.5
Using the silent mode
The CAN core can be set in silent mode by programming the Silent bit of Test register to
one. In silent mode, the CAN is able to receive valid data frames and valid remote frames,
but it sends only recessive bits on the CAN bus and it cannot start a transmission. If the
CAN Core is required to send a dominant bit (ACK bit, overload flag, active error flag), the bit
is rerouted internally so that the CAN core monitors the dominant bit, although the CAN bus
may remain in recessive state. The silent mode can be used to analyse the traffic on a CAN
bus without affecting it by the transmission of dominant bits (Acknowledge Bits, Error
Frames). The following figure shows the connection of signals CAN_TX and CAN_RX to the
CAN core in silent mode.
198/368
Doc ID 022640 Rev 3
RM0319
Controller area network ports (CAN)
Figure 68. CAN core in silent mode
CAN_TX
CAN_RX
=1
C_CAN
Tx
Rx
CAN Core
In ISO 11898-1, the silent mode is called bus monitoring mode.
15.4.6
Using the loop back mode
The CAN core can be set in loop back mode by programming the LBack bit of Test register
to one. In loop back mode, the CAN core treats its own transmitted messages as received
messages and stores them (if they pass acceptance filtering) into a receive buffer. The
following figure shows the connection of signals CAN_TX and CAN_RX to the CAN core in
loop back mode.
Figure 69. CAN Core in loop back mode
CAN_TX
CAN_RX
C_CAN
Tx
Rx
CAN Core
This mode is provided for self-test functions. To be independent from external stimulation,
the CAN core ignores acknowledge errors (recessive bit sampled in the acknowledge slot of
a data / remote frame) in loop back mode. In this mode, the CAN core performs an internal
Doc ID 022640 Rev 3
199/368
Controller area network ports (CAN)
RM0319
feedback from its Tx output to its Rx input. The actual value of the CAN_RX input pin is
disregarded by the CAN core. The transmitted messages can be monitored at the CAN_TX
pin.
15.4.7
Using the loop back mode combined with silent mode
It is also possible to combine loop back mode and silent mode by programming LBack and
Silent bits to one at the same time. This mode can be used for a “Hot Selftest”, which means
that the CAN can be tested without affecting a running CAN system connected to the pins
CAN_TX and CAN_RX. In this mode, the CAN _RX pin is disconnected from the CAN core
and the CAN_TX pin is held rescessive. The following figure shows the connection of
signals CAN_TX and CAN_RX to the CAN core in case of the combination of loop back
mode with silent mode.
Figure 70. CAN core in loop back combined with silent mode
CAN_TX
C_CAN
CAN_RX
=1
Tx
Rx
CAN Core
15.4.8
Managing message objects
Figure 71. Message identifier formats
11-bit Identifier
RTR
IDE
r0
Bus
idle
SOF
Standard format: 11-bit message identifier
Control field
Arbitration field
DLC
Extended format: 29-bit message identifier
200/368
18-bit Identifier
Doc ID 022640 Rev 3
Control field
RTR
r1
r0
11-bit Identifier
SRR
IDE
Bus
idle
SOF
Arbitration field
DLC
RM0319
Controller area network ports (CAN)
Figure 72. Data frame format
11
Delimiter bits
Control
field
CRC
seq.
Data field
1
0…..64
15
Arbitration field
1
1
7
3
1
Bus
idle
Intermission field
CRC field
Bit stuffing
EOF
IFS
1
CRC sequence
r1
ACK
RTR
Message
identifier
RTR
Bus
idle
SOF
Start of frame
Remote
transmission
request
End of
frame field
Acknowledgement
field
CAN data frame
The configuration of the message objects in the message RAM (with the exception of the
bits MsgVal, NewDat, IntPnd and TxRqst) will not be affected by resetting the chip. All the
message objects must be initialized by the CPU or they must be “not valid” (MsgVal =’0’),
and the bit timing must be configured before the CPU clears the Init bit in the CAN Control
register.
The configuration of a message object is done by programming the mask, arbitration,
control and data fields of one of the two interface register sets to the desired values. By
writing to the corresponding IFx Command Request register, the IFx Message Buffer
registers are loaded into the addressed message object in the message RAM.
When the Init bit in the CAN Control register is cleared, the CAN Protocol Controller state
machine of the CAN Core and the message handler state machine control the CAN internal
data flow. Received messages that pass the acceptance filtering are stored into the
Message RAM, messages with pending transmission request are loaded into the CAN core
Shift register and are transmitted via the CAN bus.
The CPU reads received messages and updates messages to be transmitted via the IFx
Interface registers. Depending on the configuration, the CPU is interrupted on certain CAN
message and CAN error events.
15.4.9
Configuring a transmit object
Table 59 shows how a Transmit Object should be initialized.
Table 59.
Initialization of a transmit object
MsgVal
Arb
Data
Mask
EoB
Dir
NewDat
MsgLst
RxIE
TxIE
IntPnd
RmtEn
TxRqst
1
appl.
appl.
appl.
1
1
0
0
0
appl.
0
appl.
0
The Arbitration registers (ID28-0 and Xtd bit) are given by the application. They define the
identifier and type of the outgoing message. If an 11-bit Identifier (“Standard Frame”) is
used, it is programmed to ID28-ID18. ID17-ID0 can then be disregarded.
If the TxIE bit is set, the IntPnd bit will be set after a successful transmission of the message
object.
Doc ID 022640 Rev 3
201/368
Controller area network ports (CAN)
RM0319
If the RmtEn bit is set, a matching received remote frame will cause the TxRqst bit to be set;
the remote frame will autonomously be answered by a data frame.
The Data registers (DLC3-0, Data0-7) are given by the application, TxRqst and RmtEn may
not be set before the data is valid.
The Mask registers (Msk28-0, UMask, MXtd and MDir bits) may be used (UMask=’1’) to
allow groups of remote frames with similar identifiers to set the TxRqst bit. For details, see
Receive/Transmit Priority. The Dir bit should not be masked.
15.4.10
Updating a transmit object
The CPU may update the data bytes of a Transmit Object any time via the IFx Interface
registers, neither MsgVal nor TxRqst have to be reset before the update.
Even if only a part of the data bytes are to be updated, all four bytes of the corresponding
IFx Data A register or IFx Data B register have to be valid before the content of that register
is transferred to the message object. Either the CPU has to write all four bytes into the IFx
Data register or the message object is transferred to the IFx Data register before the CPU
writes the new data bytes.
When only the (eight) data bytes are updated, first 0x0087 is written to the Command Mask
register and then the number of the message object is written to the Command Request
register, concurrently updating the data bytes and setting TxRqst.
To prevent the reset of TxRqst at the end of a transmission that may already be in progress
while the data is updated, NewDat has to be set together with TxRqst. For details, see
Transmission of messages.
When NewDat is set together with TxRqst, NewDat will be reset as soon as the new
transmission has started.
15.4.11
Configuring a receive object
Table 60 shows how a transmit object should be initialized.
Table 60.
Initialization of a receive object
MsgVal
Arb
Data
Mask
EoB
Dir
NewDat
MsgLst
RxIE
TxIE
IntPnd
RmtEn
TxRqst
1
appl.
appl.
appl.
1
0
0
0
appl.
0
0
0.
0
The Arbitration registers (ID28-0 and Xtd bit) are given by the application. They define the
identifier and type of accepted received messages. If an 11-bit Identifier (“Standard Frame”)
is used, it is programmed to ID28 - ID18. ID17 - ID0 can then be disregarded. When a Data
Frame with an 11-bit Identifier is received, ID17 - ID0 will be set to ‘0’.
If the RxIE bit is set, the IntPnd bit will be set when a received Data Frame is accepted and
stored in the message object.
The data length code (DLC3-0) is given by the application. When the message handler
stores a data frame in the message object, it will store the received data length code and
eight data bytes. If the data length code is less than 8, the remaining bytes of the message
object will be overwritten by non specified values.
202/368
Doc ID 022640 Rev 3
RM0319
Controller area network ports (CAN)
The Mask registers (Msk28-0, UMask, MXtd, and MDir bits) may be used (UMask=’1’) to
allow groups of Data Frames with similar identifiers to be accepted. For details, see
Reception of data frame. The Dir bit should not be masked in typical applications.
15.4.12
Updating a transmit object
The CPU may update the data bytes of a transmit object any time via the IFx Interface
registers. Neither MsgVal nor TxRqst have to be reset before the update.
Even if only a part of the data bytes are to be updated, all four bytes of the corresponding
IFx Data A register or IFx Data B register have to be valid before the content of that register
is transferred to the message object. Either the CPU has to write all four bytes into the IFx
Data register or the message object is transferred to the IFx Data register before the CPU
writes the new data bytes.
When only the (eight) data bytes are updated, first 0x0087 is written to the Command Mask
register and then the number of the message object is written to the Command Request
register, concurrently updating the data bytes and setting TxRqst.
To prevent the reset of TxRqst at the end of a transmission that may already be in progress
while the data is updated, NewDat has to be set together with TxRqst. For details, see
Transmission of messages.
When NewDat is set together with TxRqst, NewDat will be reset as soon as the new
transmission has started.
Doc ID 022640 Rev 3
203/368
Controller area network ports (CAN)
15.4.13
RM0319
Configuring a receive object
Table 61 shows how a receive object should be initialized.
Table 61.
Initialization of a receive object
MsgVal
Arb
Data
Mask
EoB
Dir
NewDat
MsgLst
RxIE
TxIE
IntPnd
RmtEn
TxRqst
1
appl.
appl.
appl.
1
1
0
0
0
appl.
0
appl.
0
The Arbitration registers (ID28-0 and Xtd bit) are given by the application. They define the
identifier and type of accepted received messages. If an 11-bit Identifier (“Standard Frame”)
is used, it is programmed to ID28 - ID18. ID17 - ID0 can then be disregarded. When a data
frame with an 11-bit Identifier is received, ID17 - ID0 will be set to ‘0’.
If the RxIE bit is set, the IntPnd bit will be set when a received data frame is accepted and
stored in the message object.
The data length code (DLC3-0) is given by the application. When the message handler
stores a data frame in the message object, it will store the received data length code and
eight data bytes. If the data length code is less than 8, the remaining bytes of the message
object will be overwritten by non specified values.
The Mask registers (Msk28-0, UMask, MXtd, and MDir bits) may be used (UMask=’1’) to
allow groups of data frames with similar identifiers to be accepted. For details, see
Reception of data frame. The Dir bit should not be masked in typical applications.
15.4.14
Handling received messages
The CPU may read a received message any time via the IFx Interface registers, the data
consistency is guaranteed by the message handler state machine.
Typically, the CPU will write first 0x007F to the Command Mask register and then the
number of the message object to the Command Request register. That combination will
transfer the whole received message from the message RAM into the message buffer
register. Additionally, the bits NewDat and IntPnd are cleared in the message RAM (not in
the message buffer).
If the message object uses masks for acceptance filtering, the arbitration bits show which of
the matching messages has been received.
The actual value of NewDat shows whether a new message has been received since last
time this message object was read. The actual value of MsgLst shows whether more than
one message has been received since last time this message object was read. MsgLst will
not be automatically reset.
By means of a remote frame, the CPU may request another CAN node to provide new data
for a receive object. Setting the TxRqst bit of a receive object will cause the transmission of
a remote frame with the identifier of the receive object. this remote frame triggers the other
CAN node to start the transmission of the matching data frame. if the matching data frame is
received before the remote frame could be transmitted, the TxRqst bit is automatically reset.
204/368
Doc ID 022640 Rev 3
RM0319
15.4.15
Controller area network ports (CAN)
Configuring a FIFO buffer
With the exception of the EoB bit, the configuration of receive objects belonging to a FIFO
Buffer is the same as the configuration of a (single) receive object, see Section 15.4.13
To concatenate two or more message objects into a FIFO buffer, the identifiers and masks
of these message objects (if used) have to be programmed to matching values. Due to the
implicit priority of the message objects, the message object with the lowest number will be
the first message object of the FIFO Buffer. The EoB bit of all message objects of a FIFO
Buffer except the last have to be programmed to zero. The EoB bits of the last message
object of a FIFO Buffer is set to one, configuring it as the end of the block.
15.4.16
Receiving messages with FIFO buffers
Received messages with identifiers matching to a FIFO buffer are stored into a message
object of this FIFO buffer starting with the message object with the lowest message number.
When a message is stored into a message object of a FIFO buffer the NewDat bit of this
message object is set. By setting NewDat while EoB is zero the message object is locked for
further write accesses by the message handler until the CPU has written the NewDat bit
back to zero.
Messages are stored into a FIFO buffer until the last message object of this FIFO buffer is
reached. If none of the preceding message objects is released by writing NewDat to zero, all
further messages for this FIFO buffer will be written into the last message object of the FIFO
Buffer and therefore overwrite previous message.
15.4.17
Reading from a FIFO buffer
When the CPU transfers the contents of message object to the IFx Message Bugger
registers by writing its number to the IFx Command Request register, the corresponding
Command Mask register should be programmed the way that bits NewDat and IntPnd are
reset to zero (TxRqst/NewDat = ‘1’ and ClrIntPnd = ‘1’). The values of these bits in the
Message Control register always reflect the status before resetting the bits.
To assure the correct function of a FIFO Buffer, the CPU should read out the message
objects starting at the FIFO Object with the lowest message number.
Figure 73 shows how a set of message objects which are concatenated to a FIFO Buffer
can be handled by the CPU.
Doc ID 022640 Rev 3
205/368
Controller area network ports (CAN)
RM0319
Figure 73. CPU handling of a FIFO buffer
START
Message Interrupt
Read Interrupt Pointer
0x8000h
Case Interrput Pointer
else
0x0000h
Status Change
Interrupt Handling
END
MessageNum = Interrupt Pointer
Write MessageNum to IFx Command Request
(Read Message to IFx Registers,
Reset NewDat = 0, Reset IntPnd =0)
Read IFx Message Control
No
NewDat =1
Yes
Read Data From IFx Data A,B
Yes
EoB =1
No
MessageNum = MessageNum + 1
206/368
Doc ID 022640 Rev 3
RM0319
15.4.18
Controller area network ports (CAN)
Handling interrupts
If several interrupts are pending, the CAN Interrupt register will point to the pending interrupt
with the highest priority, disregarding their chronological order. An interrupt remains pending
until the CPU has cleared it.
The Status Interrupt has the highest priority. Among the message interrupts, the interrupt
priority of the message object decreases as the message number increases.
A message interrupt is cleared by clearing the message object IntPnd bit. The Status
Interrupt is cleared by reading the Status register.
The interrupt identifier IntId in the Interrupt register indicates the cause of the interrupt.
When no interrupt is pending, the register will hold the value zero. If the value of the
Interrupt register is different from zero, then there is an interrupt pending and, if IE is set, the
interrupt line to the CPU, IRQ_B, is active. The interrupt line remains active until the
Interrupt register is back to value zero (the cause of the interrupt is reset) or until IE is reset.
The value 0x8000 indicates that an interrupt is pending because the CAN Core has updated
(not necessarily changed) the Status register (Error Interrupt or Status Interrupt). This
interrupt has the highest priority. The CPU can update (reset) the status bits RxOk, TxOk
and LEC, but a write access of the CPU to the Status register can never generate or reset
an interrupt.
All other values indicate that the source of the interrupt is one of the message objects, IntId
points to the pending message interrupt with the highest interrupt priority.
The CPU controls whether a change of the Status register may cause an interrupt (bits EIE
and SIE in the CAN Control register) and whether the interrupt line becomes active when
the Interrupt register is different from zero (bit IE in the CAN Control register). The Interrupt
register will be updated even when IE is reset.
The CPU has two possibilities to follow the source of a message interrupt. First, it can follow
the IntId in the Interrupt register and, second, it can poll the Interrupt Pending register.
An interrupt service routine reading the message that is the source of the interrupt may read
the message and reset the message object’s IntPnd at the same time (bit ClrIntPnd in the
Command Mask register). When IntPnd is cleared, the Interrupt register will point to the next
message object with a pending interrupt.
15.4.19
Configuring the bit timing
Even if minor errors in the configuration of the CAN bit timing do not result in immediate
failure, the performance of a CAN network can be reduced significantly.
In many cases, the CAN bit synchronisation will amend a faulty configuration of the CAN bit
timing to such a degree that only occasionally an error frame is generated. In the case of
arbitration, however, when two or more CAN nodes simultaneously try to transmit a frame, a
misplaced sample point may cause one of the transmitters to become error passive.
The analysis of such sporadic errors requires a detailed knowledge of the CAN bit
synchronisation inside a CAN node and the interaction of the CAN nodes on the CAN bus.
Bit time and time rate
CAN supports bit rates in the range of lower than 1 kBit/s up to 1000 kBit/s. Each member of
the CAN network has its own clock generator, usually a quartz oscillator. The timing
parameter of the bit time (for instance, the reciprocal of the bit rate) can be configured
Doc ID 022640 Rev 3
207/368
Controller area network ports (CAN)
RM0319
individually for each CAN node, creating a common bit rate even though the CAN nodes
oscillator periods (fosc) may be different.
The frequencies of these oscillators are not absolutely stable, small variations are caused
by changes in temperature or voltage and by deteriorating components. As long as the
variations remain inside a specific oscillator tolerance range (df), the CAN nodes are able to
compensate for the different bit rates by resynchronising to the bit stream.
According to the CAN specification, the bit time is divided into four segments (see
Figure 74):
●
the synchronisation segment (Sync_Seg)
●
the propagation time segment (Prop_Seg)
●
the phase buffer segment 1 (Phase_Seg1)
●
the phase buffer segment 2 (Phase_Seg2)
Each segment consists of a specific, programmable number of time quanta (see Table 62).
The length of the time quantum (tq), which is the basic time unit of the bit time, is defined by
the CAN controller’s system clock fsys and the Baud Rate Prescaler (BRP): tq = BRP / fsys.
The CAN system clock fsys is the frequency of its CAN_CLK input.
The synchronisation segment is that part of the bit time where edges of the CAN bus level
are expected to occur; the distance between an edge that occurs outside of Sync_Seg and
the Sync_Seg is called the phase error of that edge. The propagation time segment is
intended to compensate for the physical delay times within the CAN network. The phase
buffer segments Phase_Seg1 and Phase_Seg2 surround the sample point. The (re-)
synchronisation jump width (SJW) defines how far a resynchronisation may move the
sample point inside the limits defined by the phase buffer segments to compensate for edge
phase errors.
Figure 74. Bit timing
Nominal CAN Bit Timing
Sync_seg
Prop_Seg
Phase_Seg1
1 Time Quantum (Tq)
Table 62.
208/368
Phase_Seg2
Sample Point
Parameters of the CAN Bit Time
Parameter
Range
Remark
BRP
[1...32]
Define the length of the time quantum tq
Sync_Seg
1 tq
Fixed length, synchronisation of bus input to system clock
Prop_Seg
[1..8] tq
Compensates for the physical delay times
Doc ID 022640 Rev 3
RM0319
Controller area network ports (CAN)
Table 62.
Parameters of the CAN Bit Time (continued)
Parameter
Range
Remark
Phrase_Seg1
[1..8] tq
May be lengthened temporarily by synchronisation
Phase_Seg2
[1..8] tq
May be shortened temporarily by synchronisation
SJW
[1..4] tq
May not be longer than either Phase Buffer Segment
This table describes the minimum programmable ranges required by the CAN protocol
A given bit rate may be met by different bit time configurations, but for the proper function of
the CAN network the physical delay times and the oscillator’s tolerance range have to be
considered.
Propagation time segment
This part of the bit time is used to compensate physical delay times within the network.
These delay times consist of the signal propagation time on the bus and the internal delay
time of the CAN nodes.
Any CAN node synchronised to the bit stream on the CAN bus will be out of phase with the
transmitter of that bit stream, caused by the signal propagation time between the two nodes.
The CAN protocol’s non-destructive bitwise arbitration and the dominant acknowledge bit
provided by receivers of CAN messages require that a CAN node transmitting a bit stream
must also be able to receive dominant bits transmitted by other CAN nodes that are
synchronised to that bit stream. The example in Figure 75 shows the phase shift and
propagation times between two CAN nodes.
Figure 75. Propagation time segment
Prop_Seg
Sync_Seg
Phase_Seg1
Phase_Seg2
Node B
Delay A_to_B
Delay B_to_A
Node A
Delay A_to_B >= node output delay(A) + bus line delay(A -> B) + node input delay(B)
Prop_Seg >= Delay A_to_B + Delay B_to_A
Prop_Seg >= 2 • [max(node output delay+ bus line delay + node input delay)]
In this example, both nodes A and B are transmitters performing an arbitration for the CAN
bus. The node A has sent its Start of Frame bit less than one bit time earlier than node B,
therefore node B has synchronised itself to the received edge from recessive to dominant.
Since node B has received this edge delay(A_to_B) after it has been transmitted, B’s bit
Doc ID 022640 Rev 3
209/368
Controller area network ports (CAN)
RM0319
timing segments are shifted with regard to A. Node B sends an identifier with higher priority
and so it will win the arbitration at a specific identifier bit when it transmits a dominant bit
while node A transmits a recessive bit. The dominant bit transmitted by node B will arrive at
node A after the delay(B_to_A).
Due to oscillator tolerances, the actual position of node A’s sample point can be anywhere
inside the nominal range of node A’s phase buffer segments, so the bit transmitted by node
B must arrive at node A before the start of Phase_Seg1. This condition defines the length of
Prop_Seg.
If the edge from recessive to dominant transmitted by node B would arrive at node A after
the start of Phase_Seg1, it could happen that node A samples a recessive bit instead of a
dominant bit, resulting in a bit error and the destruction of the current frame by an error flag.
The error occurs only when two nodes arbitrate for the CAN bus that have oscillators of
opposite ends of the tolerance range and that are separated by a long bus line; this is an
example of a minor error in the bit timing configuration (Prop_Seg to short) that causes
sporadic bus errors.
Some CAN implementations provide an optional 3 Sample Mode The CAN does not. In this
mode, the CAN bus input signal passes a digital low-pass filter, using three samples and a
majority logic to determine the valid bit value. This results in an additional input delay of 1 tq,
requiring a longer Prop_Seg.
Phase buffer segments and synchronisation
The phase buffer segments (Phase_Seg1 and Phase_Seg2) and the synchronisation jump
width (SJW) are used to compensate for the oscillator tolerance. The phase buffer segments
may be lengthened or shortened by synchronisation.
Synchronisations occur on edges from recessive to dominant, their purpose is to control the
distance between edges and sample points.
Edges are detected by sampling the actual bus level in each time quantum and comparing it
with the bus level at the previous Sample Point. A synchronisation may be done only if a
recessive bit was sampled at the previous Sample Point and if the actual time quantum’s bus
level is dominant.
An edge is synchronous if it occurs inside of Sync_Seg, otherwise the distance between
edge and the end of Sync_Seg is the edge phase error, measured in time quanta. If the
edge occurs before Sync_Seg, the phase error is negative, else it is positive.
Two types of synchronisation exist: hard synchronisation and resynchronisation.
A hard synchronisation is done once at the start of a frame; inside a frame only
resynchronisations occur.
●
Hard synchronisation
After a hard synchronisation, the bit time is restarted with the end of Sync_Seg, regardless
of the edge phase error. Thus hard synchronisation forces the edge which has caused the
hard synchronisation to lie within the synchronisation segment of the restarted bit time.
●
Bit resynchronisation
Resynchronisation leads to a shortening or lengthening of the bit time such that the position
of the sample point is shifted with regard to the edge.
When the phase error of the edge which causes resynchronisation is positive, Phase_Seg1
is lengthened. If the magnitude of the phase error is less than SJW, Phase_Seg1 is
lengthened by the magnitude of the phase error, else it is lengthened by SJW.
210/368
Doc ID 022640 Rev 3
RM0319
Controller area network ports (CAN)
When the phase error of the edge which causes resynchronisation is negative, Phase_Seg2
is shortened. If the magnitude of the phase error is less than SJW, Phase_Seg2 is
shortened by the magnitude of the phase error, else it is shortened by SJW.
When the magnitude of the phase error of the edge is less than or equal to the programmed
value of SJW, the results of hard synchronisation and resynchronisation are the same. If the
magnitude of the phase error is larger than SJW, the resynchronisation cannot compensate
the phase error completely, an error of (phase error - SJW) remains.
Only one synchronisation may be done between two sample points. the synchronisations
maintain a minimum distance between edges and sample points, giving the bus level time to
stabilize and filtering out spikes that are shorter than (Prop_Seg + Phase_Seg1).
Apart from noise spikes, most synchronisations are caused by arbitration. All nodes
synchronise “hard” on the edge transmitted by the “leading” transceiver that started
transmitting first, but due to propagation delay times, they cannot become ideally
synchronised. The “leading” transmitter does not necessarily win the arbitration, therefore
the receivers have to synchronise themselves to different transmitters that subsequently
“take the lead” and that are differently synchronised to the previously “leading” transmitter.
The same happens at the acknowledge field, where the transmitter and some of the
receivers will have to synchronise to the receiver that “takes the lead” in the transmission of
the dominant acknowledge bit.
Synchronisations after the end of the arbitration will be caused by oscillator tolerance, when
the differences in the oscillator’s clock periods of transmitter and receivers sum up during
the time between synchronisations (at most ten bits). These summarized differences may
not be longer than the SJW, limiting the oscillator’s tolerance range.
The examples in Figure 76 show how the phase buffer segments are used to compensate
for phase errors. There are three drawings of each two consecutive bit timings. The upper
drawing shows the synchronisation on a “late” edge, the lower drawing shows the
synchronisation on an “early” edge, and the middle drawing is the reference without
synchronisation.
Figure 76. Synchronisation on “late” and “early” Edges
Recessive
dominant
“Late” edge
Rx-Input
Sample Point
Sample Point
Sample Point
Sample Point
Sample Point
Sample Point
“Early” edge
Rx-Input
Sync_Seg
Prop_Seg
Recessive
dominant
Phase_Seg1
Phase_Seg2
In the first example, an edge from recessive to dominant occurs at the end of Prop_Seg.
The edge is “late” since it occurs after the Sync_Seg. Reacting to the “late” edge,
Phase_Seg1 is lengthened so that the distance from the edge to the sample point is the
Doc ID 022640 Rev 3
211/368
Controller area network ports (CAN)
RM0319
same as it would have been from the Sync_Seg to the sample point if no edge had
occurred. The phase error of this “late” edge is less than SJW, so it is fully compensated and
the edge from dominant to recessive at the end of the bit, which is one nominal bit time long,
occurs in the Sync_Seg.
In the second example, an edge from recessive to dominant occurs during Phase_Seg2.
The edge is “early” since it occurs before a Sync_Seg. Reacting to the “early” edge,
Phase_Seg2 is shortened and Sync_Seg is omitted, so that the distance from the edge to
the Sample Point is the same as it would have been from an Sync_Seg to the Sample Point
if no edge had occurred. As in the previous example, the magnitude of this “early” edge
phase error is less than SJW, so it is fully compensated.
The phase buffer segments are lengthened or shortened temporarily only; at the next bit
time, the segments return to their nominal programmed values.
In these examples, the bit timing is seen from the point of view of the CAN implementation’s
state machine, where the bit time starts and ends at the sample points. The state machine
omits Sync_Seg when synchronising on an “early” edge because it cannot subsequently
redefine that time quantum of Phase_Seg2 where the edge occurs to be the Sync_Seg.
The examples in Figure 77 show how short dominant noise spikes are filtered by
synchronisations. In both examples, the spike starts at the end of Prop_Seg and has the
length of (Prop_Seg + Phase_Seg1).
In the first example, the synchronisation jump width is greater than or equal to the phase
error of the spike edge from recessive to dominant. Therefore, the sample point is shifted
after the end of the spike; a recessive bus level is sampled.
In the second example, SJW is shorter than the phase error, so the sample point cannot be
shifted far enough; the dominant spike is sampled as actual bus level.
Figure 77. Filtering of short dominant spikes
Spike
Rx-Input
Recessive
dominant
Sample Point
SJW > Phase Error
Sample Point
Spike
Recessive
dominant
Rx-Input
Sample Point
SJW < Phase Error
Sync_Seg
212/368
Prop_Seg
Doc ID 022640 Rev 3
Sample Point
Phase_Seg1
Phase_Seg2
RM0319
Controller area network ports (CAN)
Oscillator tolerance range
The oscillator tolerance range was increased when the CAN protocol was developed from
version 1.1 to version 1.2 (version 1.0 was never implemented in silicon). The option to
synchronise on edges from dominant to recessive became obsolete, only edges from
recessive to dominant are considered for synchronisation. The only CAN controllers to
implement protocol version 1.1 have been Intel 82526 and Philips 82C200, both are
superseded by successor products. The protocol update to version 2.0 (A and B) had no
influence on the oscillator tolerance.
The tolerance range df for an oscillator frequency fosc around the nominal frequency fnom
with depends on the proportions of Phase_Seg1, Phase_Seg2, SJW, and the bit time. The
maximum tolerance df is the defined by two conditions (both shall be met):
min ( PhaseSeg1, PhaseSeg2 )
2x ( 13xbittime – PhaseSeg2 )
I: df ≤ -------------------------------------------------------------------------------------SJW
20xbittime
II: df ≤ ------------------------------
It has to be considered that SJW may not be larger than the smaller of the phase buffer
segments and that the propagation time segment limits that part of the bit time that may be
used for the phase buffer segments.
The combination Prop_Seg = 1 and Phase_Seg1 = Phase_Seg2 = SJW = 4 allows the
largest possible oscillator tolerance of 1.58%. This combination with a propagation time
segment of only 10% of the bit time is not suitable for short bit times; it can be used for bit
rates of up to 125 kBit/s (bit time = 8 ms) with a bus length of 40 m.
15.4.20
Configuring the CAN protocol controller
In most CAN implementations, as in the current implementation in SPEAr320S, the bit
timing configuration is programmed in two register bytes. The sum of Prop_Seg and
Phase_Seg1 (as TSEG1) is combined with Phase_Seg2 (as TSEG2) in one byte, SJW and
BRP are combined in the other byte (see Figure 78).
In these bit timing registers, the four components TSEG1, TSEG2, SJW, and BRP have to
be programmed to a numerical value that is one less than its functional value; so instead of
values in the range of [1..n], values in the range of [0..n-1] are programmed. In that way, for
instance SJW (functional range of [1..4]) is represented by only two bits.
Therefore the length of the bit time is (programmed values) [TSEG1 + TSEG2 + 3] tq or
(functional values) [Sync_Seg + Prop_Seg + Phase_Seg1 + Phase_Seg2] tq.
Doc ID 022640 Rev 3
213/368
Controller area network ports (CAN)
RM0319
Figure 78. Structure of the CAN Core protocol controller
Configuration (BRP)
System_Clock
Baudrate
Prescaler
Scaled_Clock (Tq)
Control
Status
Sample_Point
Receive_Data
Sampled_Bit
Bit
Timing
Logic
Sync_Mode
Bit
Stream
Processor
Bit_2_Send
Received_Data_Bit
Bus_Off
Transmit_Data
Send Message
Control
Next_Data_Bit
Shift-Register
Received_Message
Configuration (TSEG1, TSEG2, SJW)
The data in the bit timing registers are the configuration input of the CAN protocol controller.
The Baud Rate Prescaler (configured by BRP) defines the length of the time quantum, the
basic time unit of the bit time; the Bit Timing Logic (configured by TSEG1, TSEG2, and
SJW) defines the number of time quanta in the bit time.
The processing of the bit time, the calculation of the position of the Sample Point, and
occasional synchronisations are controlled by the BTL state machine, which is evaluated
once each time quantum. The rest of the CAN protocol controller, the Bit Stream Processor
(BSP) state machine is evaluated once each bit time, at the Sample Point.
The Shift register serializes the messages to be sent and parallelizes received messages.
Its loading and shifting is controlled by the BSP.
The BSP translates messages into frames and vice versa. It generates and discards the
enclosing fixed format bits, inserts and extracts stuff bits, calculates and checks the CRC
code, performs the error management, and decides which type of synchronisation is to be
used. It is evaluated at the Sample Point and processes the sampled bus input bit. The time
after the Sample point that is needed to calculate the next bit to be sent (e.g. data bit, CRC
bit, stuff bit, error flag, or idle) is called the Information Processing Time (IPT).
The IPT is application specific but may not be longer than 2 tq; the CAN IPT is 0 tq. Its
length is the lower limit of the programmed length of Phase_Seg2. In case of a
synchronisation, Phase_Seg2 may be shortened to a value less than IPT, which does not
affect bus timing.
Calculating the bit timing parameters
Usually, the calculation of the bit timing configuration starts with a desired bit rate or bit time.
The resulting bit time (1/bit rate) must be an integer multiple of the system clock period.
214/368
Doc ID 022640 Rev 3
RM0319
Controller area network ports (CAN)
The bit time may consist of 4 to 25 time quanta, the length of the time quantum tq is defined
by the baud rate prescaler with tq = (Baud Rate Prescaler)/fsys. Several combinations may
lead to the desired bit time, allowing iterations of the following steps.
First part of the bit time to be defined is the Prop_Seg. Its length depends on the delay times
measured in the system. A maximum bus length as well as a maximum node delay has to
be defined for expandible CAN bus systems. The resulting time for Prop_Seg is converted
into time quanta (rounded up to the nearest integer multiple of tq).
The Sync_Seg is 1 tq long (fixed), leaving (bit time – Prop_Seg – 1) tq for the two Phase
Buffer Segments. If the number of remaining tq is even, the Phase Buffer Segments have
the same length, Phase_Seg2 = Phase_Seg1, else Phase_Seg2 = Phase_Seg1 + 1.
The minimum nominal length of Phase_Seg2 has to be regarded as well. Phase_Seg2 may
not be shorter than the CAN controller’s information processing time, which is, depending on
the actual implementation, in the range of [0..2] tq.
The length of the synchronisation jump width is set to its maximum value, which is the
minimum of 4 and Phase_Seg1.
The oscillator tolerance range necessary for the resulting configuration is calculated by the
formulas given in Oscillator tolerance range section.
If more than one configuration is possible, that configuration allowing the highest oscillator
tolerance range should be chosen.
CAN nodes with different system clocks require different configurations to come to the same
bit rate. The calculation of the propagation time in the CAN network, based on the nodes
with the longest delay times, is done once for the whole network.
The CAN system’s oscillator tolerance range is limited by that node with the lowest tolerance
range.
The calculation may show that bus length or bit rate have to be decreased or that the
oscillator frequencies’ stability has to be increased in order to find a protocol compliant
configuration of the CAN bit timing.
The resulting configuration is written into the Bit Timing register:
(Phase_Seg2-1)&(Phase_Seg1+Prop_Seg-1)&(SynchronisationJumpWidth-1)&(Prescaler1)
Example for Bit Timing at high Baudrate
In this example, the frequency of CAN_CLK is 10 MHz, BRP is 0, the bit rate is 1 MBit/s.
tq
100
ns
=
tCAN_CLK
delay of bus driver
50
ns
=
delay of receiver circuit
30
ns
delay of bus line (40m)
220
ns
tProp
600
ns
=
6 * tq
tSJW
100
ns
=
1 * tq
tTSeg1
700
ns
=
tProp + tSJW
tTSeg2
200
ns
=
Information Processing Time + 1 * tq
Doc ID 022640 Rev 3
215/368
Controller area network ports (CAN)
RM0319
tSync-Seg
100
ns
=
1 * tq
bit time
1000
ns
=
tSync-Seg + tTSeg1 + tTSeg2
tolerance for CAN_CLK 0.39
%
=
min ( PB1, PB2 ) ----------------------------------------------------------2x ( 13xbittime – PB2 )
=
0.1μs
----------------------------------------------------2x ( 13x1μs – 0.2μs )
In this example, the concatenated bit time parameters are (2-1)3&(7-1)4&(1-1)2&(1-1)6, the
Bit Timing register is programmed to= 0x1600.
Example for Bit Timing at low Baudrate
In this example, the frequency of CAN_CLK is 2 MHz, BRP is 1, the bit rate is 100 KBits/s.
tq
1
µs
=
2 * tCAN_CLK
delay of bus driver
200
ns
delay of receiver circuit
80
ns
delay of bus line (40m)
220
ns
tProp
1
µs
=
1 * tq
tSJW
4
µs
=
4 * tq
tTSeg1
5
µs
=
tProp + tSJW
tTSeg2
4
µs
=
Information Processing Time + 3 * tq
tSync-Seg
1
µs
=
1 * tq
bit time
10
µs
=
tSync-Seg + tTSeg1 + tTSeg2
%
=
min ( PB1, PB2 ) ----------------------------------------------------------2x ( 13xbittime – PB2 )
=
4μs
--------------------------------------------------2x ( 13x10μs – 4μs )
tolerance for CAN_CLK 1.58
In this example, the concatenated bit time parameters are (4-1)3&(5-1)4&(4-1)2&(2-1)6, the
Bit Timing register is programmed to= 0x34C1.
216/368
Doc ID 022640 Rev 3
RM0319
16
Asynchronous serial ports (UART)
Asynchronous serial ports (UART)
This chapter focuses on UART functionality and operation.
For technical details about the programmable registers related to the UART, refer to the
UART registers in the following companion document:
●
16.1
RM0321: SPEAr320S address map and registers
Overview
Asynchronous serial ports (commonly referred as UARTs) perform the main task in
computer serial communication by converting incoming parallel information into serial data
and incoming serial information into parallel data that can be sent on a communication line
connected to an external peripheral device.
SPEAr320S integrates 7 instances of UART and an extra UART interface with output enable
for a RS485 transceiver.
16.2
Main features
●
Separate 16 x 8 (16 location deep x 8-bit wide) transmit and 16 x 12 receive FIFOs to
reduce CPU interrupts
●
Provides programmable FIFO disabling for 1-byte depth
●
Programmable baud rate generator that enables division of the reference clock by
(1 x 16) to (65535 x 16) and generates an internal x16 clock. The divisor can be a
fractional number.
●
Provides standard asynchronous communication bits (start, stop and parity) which are
added prior transmission and removed on reception
●
Supplies independent masking of transmit or receive FIFOs, receive timeout, and error
condition interrupts. According to the configuration mode selected, hardware and
software flow control as well as a modem interface is available.
●
Supports DMA
●
Detects false start bit
●
Generates and detects line break
●
Fully-programmable serial interface characteristics:
–
data can be 5, 6, 7, or 8 bits
–
even, odd, stick, or no-parity bit generation and detection
–
1 or 2 stop bit generation
Doc ID 022640 Rev 3
217/368
Asynchronous serial ports (UART)
●
Programmable hardware flow control which uses the CTS input and the RTS output to
automatically control the serial data flow
●
Support modem status which uses:
●
218/368
RM0319
–
input signals: Clear To Send (CTS), Data Carrier Detect (DCD), Data Set Ready
(DSR), and Ring Indicator (RI)
–
output modem control lines: Request To Send (RTS), and Data Terminal Ready
(DTR)
Provides some programmable parameters, such as:
–
communication baud rate, integer and fractional parts
–
number of data bits
–
parity mode
–
FIFO enable (16 deep) or disable (1 deep)
–
FIFO trigger levels selectable between 1/8, 1/4, 1/2, 3/4 and 7/8
Doc ID 022640 Rev 3
RM0319
16.3
Asynchronous serial ports (UART)
Functional description
This chapter describes the main interfaces of the UART block.
Figure 79 shows the UART block diagram.
Figure 79. UART block diagram
Read data[11:0]
rxd[11:0]
Write data[7:0]
nUARTRST
16x8
Transmit
FIFO
16x12
Receive
FIFO
txd[7:0]
PCLK
PRESETn
PSEL
PENABLE
PWRITE
Control and status
APB interface
and register
block
PADDR[11:2]
Baud rate divisor
Transmitter
UARTTXD
Baud16
Baud rate
generator
PWDATA[15:0]
Receiver
UARTRXD
PRDATA[15:0]
UARTCLK
FIFO
flags
UARTRXDMACLR
Transmit
FIFO
status
Receiv
FIFO
status
nUARTRI
UARTTXDMACLR
UARTRXDMASREQ
UARTRXDMABREQ
UARTTXDMASREQ
UARTTXDMABREQ
nUARTCTS
DMA
Interface
UARTTXINTR
UARTRXINTR
UARTMSINTR
UARTRTINTR
nUARTDSR
FIFO status
and interrupt
generation
UARTEINTR
UARTINTR
Note:
Applicable for UART0 - UART1 (only for two modes)
16.3.1
APB Interface
nUARTDCD
nUARTDTR
Note 1
nUARTRTS
nUARTOUT1
nUARTOUT2
The APB Interface block generates read and write decodes for accesses to control and
status registers (CSRs) as well as to transmit/receive FIFO memories.
16.3.2
Register Block
The Register Block allows to store data written, or to be read across the APB Interface.
Doc ID 022640 Rev 3
219/368
Asynchronous serial ports (UART)
16.3.3
RM0319
Baud Rate Generator
The Baud Rate Generator contains free-running counters that generate the internal x16
clocks, and Baud16 signal.
Baud16 provides timing information for UART transmit and receive control. It consists of a
stream of pulses with a width of one UARTCLK clock period and a frequency of 16 times the
baud rate.
16.3.4
Transmit FIFO
The transmit FIFO consists of an 8-bit wide, 16 location deep, and FIFO memory buffer.
CPU data written across the APB interface is stored in this FIFO until read out by the
Transmit LogicThe Receive FIFO block can be disabled to act like a one-byte holding
register.).
Note:
The Transmit FIFO block can be disabled to act like a one-byte holding register.
16.3.5
Receive FIFO
The receive FIFO consists of a 12-bit wide, 16 locations deep FIFO memory buffer.
Received data and corresponding error bits are stored in the Receive FIFO by the Receive
Logic until read out by the CPU across the APB interface. This block can be disabled to act
like a one-byte holding register.
Note:
The Receive FIFO block can be disabled to act like a one-byte holding register.
16.3.6
Transmit Logic
The transmit logic performs parallel-to-serial conversion on the data read from the Transmit
FIFO. The control logic outputs the serial bit stream beginning with a start bit followed by
data bits, with the LSB first and ended by parity bit and stop bit according to the
programmed configuration in control registers.
16.3.7
Receive logic
The receive logic performs serial-to-parallel conversion on the received serial bit stream
after a valid pulse has been detected. The Receive Logic also performs detection of
overrun, parity, frame error checking and line break, and their status accompanies the data
that is written to the Receive FIFO.
16.3.8
DMA interface
The UART provides a DMA Interface to connect to a DMA controller. The DMA operation of
the UART is controlled through the UART DMA control register.
The burst transfer and single transfer request signals are not mutually exclusive, so they can
both be asserted at the same time. When the UART is in the FIFO disabled mode (where
both FIFO’s act like a one-byte holding register), only the DMA single transfer mode can
operate, since only one character can be transferred to or from the FIFO at any time.
16.3.9
Synchronization registers and logic
Since the UART supports both asynchronous and synchronous operation of the clocks
PCLK and UARTCLK, Synchronization Registers and Handshaking Logic have been
220/368
Doc ID 022640 Rev 3
RM0319
Asynchronous serial ports (UART)
implemented and are active at all times. Synchronization of control signal is performed on
both directions of data flow.
16.3.10
RS485 interface
In addition to the 7 UART interfaces, SPEAr320S provides an extra UART interface with an
output enable pin (UART_RS485_OE) for an RS485 transceiver. The output status can be
used as valid or invalid, depending on the configuration of the output enable pin.
For example:
UART_RS485_OE = 1’b1 (output is valid)
UART_RS485_OE = 1’b0 (output is invalid)
16.4
Interrupts
Table 63 shows a summary of the 11 maskable interrupts generated within the UART. These
interrupts are combined to form four individual interrupt outputs and one which is the logical
OR of the individual outputs.
The interrupts from UART1 to UART2 are further combined to generate a single interrupt at
the RAS interface. The individual interrupt source can be determined from RAS interrupt
status register.
Any individual interrupt can be enabled or disabled by changing the corresponding mask bit
in the UARTIMSC register. The status of the individual interrupt sources can be read either
from the UARTRIS register for raw status or from the UARTMIS register for the masked
status.
Table 63.
UART interrupt summary together with combined outputs
Name
Source
Combined Outputs
UARTRXINTR
Receive FIFO
UARTRXINTR
UARTTXINTR
Transmit FIFO
UARTTXINTR
UARTRTINTR
Receive time-out in
Receive FIFO
UARTRTINTR
NA
NA
UARTMSINTR
UARTCTSINTR
UARTDCDINTR
UARTINTR
UARTDCSRINTR
UARTOEINTR
Overrun error.
UARTBEINTR
Break error
(in reception)
UARTPEINTR
Parity error in the
received character
UARTFEINTR
Framing error in the
received character
UARTEINTR
Doc ID 022640 Rev 3
221/368
Asynchronous serial ports (UART)
RM0319
UARTRXINTR
This interrupt is asserted when one of the following events occurs:
●
If the FIFOs are enabled and the Receive FIFO reaches the programmed trigger level.
The interrupt is then cleared by reading data from the Receive FIFO until it becomes
less than the trigger level, or by clearing the interrupt.
●
If the FIFOs are disabled and data is received, thereby filling the location.
The interrupt is then cleared by performing a single read of the Receive FIFO, or by
clearing the interrupt (writing a 1‘b1 to the corresponding bit of the UARTICR register).
UARTTXINTR
This interrupt is asserted when one of the following events occurs:
●
If the FIFOs are enabled (FEN bit set to 1‘b1 in UARTLCR_H register) and the Transmit
FIFO reaches the programmed trigger level (TXIFLSEL in UARTIFLS register). The
interrupt is then cleared by writing data to the Transmit FIFO until it becomes greater
than the trigger level, or by clearing the interrupt (writing a 1‘b1 to the corresponding bit
of the UARTICR register);
●
If the FIFOs are disabled and there is no data in the transmitter single location. The
interrupt is then cleared by performing a single write to the Transmit FIFO, or by
clearing the interrupt (writing a 1‘b1 to the corresponding bit of the UARTICR register).
UARTRTINTR
This interrupt is asserted when the Receive FIFO is not empty, and no further data is
received over a 32-bit period. The interrupt is then cleared either when the Receive FIFO
becomes empty through reading all the data (or by reading the holding register), or by
clearing the interrupt (writing a 1‘b1 to the corresponding bit of the UARTICR register).
UARTMSINTR
This interrupt feature is available in UART0 only. It represents the modem status interrupt,
that is a combined interrupt of the four individual modem status lines (nUARTRI,
nUARTCTS, nUARTDCS and nUARTDSR). This interrupt is then asserted if any of the
modem status lines change.
UARTEINTR
This error interrupt is triggered when there is an error in the reception of the data. The
interrupt can be caused by a number of different error conditions, such as overrun, break,
parity and framing.
UARTINTR
It is the OR logical function of all the individual masked interrupt sources. That is, this
interrupt is asserted if any of the individual interrupts are asserted and enabled.
222/368
Doc ID 022640 Rev 3
RM0319
Asynchronous serial ports (UART)
16.5
Operation
16.5.1
UART hardware flow control
The hardware flow control feature is fully selectable, and enables you to control the serial
data flow by using the nUARTRTS output and nUARTCTS input signals. Figure 80 shows an
example of how two devices can communicate using hardware flow control.
Figure 80. Hardware flow control between two similar devices
RX FIFO
and
flow control
TX FIFO
and
flow control
nUARTRTS
UARTRTS
nUARTRTS
UARTRTS
nUARTCTS
nUARTCTS
UART 1
RX FIFO
and
flow control
TX FIFO
and
flow control
UART 2
When the RTS flow control is enabled, the nUARTRTS signal is asserted until the receive
FIFO is filled up to the programmed watermark level. When the CTS flow control is enabled,
the transmitter can only transmit data when the nUARTCTS signal is asserted.
The hardware flow control is selectable through bits 14 (RTSEn) and 15 (CTSEn) of the
UART control register (UARTCR). Table 64 lists how bits must be set to enable RTS and
CTS flow control both simultaneously, and independently.
When RTS flow control is enabled, the software cannot control the nUARTRTS line through
bit 11 of the UART control register.
Table 64.
Control bits to enable and disable hardware flow control
UARTCR bit 15
(CTSEn)
UARTCR bit 14
(RTSEn)
1
1
Both RTS and CTS flow control enabled
1
0
Only CTS flow control enabled
0
1
Only RTS flow control enabled
0
0
Both RTS and CTS flow control disabled
Description
RTS flow control
The RTS flow control logic is linked to the programmable receive FIFO watermark levels.
When RTS flow control is enabled, the nUARTRTS is asserted until the receive FIFO is filled
up to the watermark level. When the receive FIFO watermark level is reached, the
nUARTRTS signal is deasserted, indicating that there is no more room to receive any more
data. The transmission of data is expected to cease after the current character has been
transmitted.
Doc ID 022640 Rev 3
223/368
Asynchronous serial ports (UART)
RM0319
The nUARTRTS signal is reasserted when data has been read out of the receive FIFO so
that it is filled to less than the watermark level. If RTS flow control is disabled and the UART
is still enabled, then data is received until the receive FIFO is full, or no more data is
transmitted to it.
CTS flow control
If CTS flow control is enabled, the transmitter checks the nUARTCTS signal before
transmitting the next byte. If the nUARTCTS signal is asserted, the byte is transmitted,
otherwise transmission does not occur. Data continues to be transmitted while nUARTCTS
is asserted and the transmit FIFO is not empty. If the transmit FIFO is empty and the
nUARTCTS signal is asserted, no data is transmitted.
If the nUARTCTS signal is deasserted and CTS flow control is enabled, the current
character transmission is completed before stopping. If CTS flow control is disabled and the
UART is enabled, the data continues to be transmitted until the transmit FIFO is empty.
16.5.2
Modem operation
This section describes the modem operation for UART0 and UART1.
UART0 and UART1 (expanded automation and small printer modes) are allowed to support
both data terminal equipment (DTE) and data communication equipment (DCE) modes of
operation. Table 65 shows the meaning of DTE and DCE signals.
Table 65.
Meaning of UART0/1 modem input/output in DTE and DCE modes
Meaning
Signal
224/368
DTE
DCE
nUARTCTS
Clear to send
Request to send
nUARTDSR
Data set ready
Data terminal ready
nUARTDCD
Data carrier detect
-
nUARTRI
Ring indicator
-
nUARTRTS
Request to send
Clear to send
nUARTDTR
Data terminal ready
Data set ready
nUARTOUT1
-
Data carrier detect
nUARTOUT2
-
Ring indicator
Doc ID 022640 Rev 3
RM0319
17
I2C bus ports (I2C)
I2C bus ports (I2C)
This chapter focuses on I2C functionality and operation.
For technical details about the programmable registers related to the I2C, refer to the I2C
registers in the following companion document:
●
17.1
RM0321: SPEAr320S address map and registers
Overview
The I2C controller provides an APB interface to the processor to access the two-wire serial
I2C bus. It can be used to connect any device which conforms to the I2C-Bus Specification
from Philips.
17.2
Main features
●
Compliance to the I2C-bus specification from Phillips
●
Operates in three different modes:
–
Standard-speed mode (data rates up to 100 Kb/s)
–
Fast-speed mode (data rates up to 400 Kb/s)
–
High-speed mode (data rates up to 3.4 Mb/s)
●
Provides clock synchronization.
●
Supports either master (only in a single master environment) or slave I2C operation
mode.
●
Supports only slave operation in multimaster environment;
●
Provides 7-bit or 10-bit addressing both in master and slave mode;
●
Supports 7-bit or 10-bit combined format transfers.
●
Provides slave bulk transfer mode.
●
Ignores CBUS addresses (an older ancestor of I2C that used to share the I2C bus).
●
Transmits and receives buffers.
●
Provides interrupt or polled-mode operation.
●
Handles bit and byte waiting at all bus speeds.
●
Provides digital filter for the received SDA and SCL lines.
●
Provides a DMA handshaking interface compatible with SPEArTM Basic DMA controller
handshaking interface.
●
Provides 8-bit or 16-bit wide transaction on the APB bus.
Doc ID 022640 Rev 3
225/368
I2C bus ports (I2C)
17.3
RM0319
Functional description
Figure 81 shows the functional block diagram of the I2C controller.
Figure 81. I2C controller functional block diagram
I2C Controller
APB Slave
Interface
I2C Master/
Slave
Interrupts
TX -FIFO
RX Filter
RX -FIFO
Clock
Generator
I2C Debug
DMA
Interface
17.3.1
APB interface
The host processor accesses data, control and status information on the I2C controller
through the APB Slave Interface. The I2C controller has 16 bit APB data bus width.
17.3.2
I2C protocols
According to the I2C-bus specification, the I2C controller implements the following protocols:
●
START and STOP Condition Protocol,
●
Addressing Slave Protocol,
●
Transmitting and Receiving Protocol,
●
START Byte Transfer Protocol.
START and STOP condition protocol
When the bus is IDLE, both the SCL (serial clock) and SDA (serial data) signals are pulled
high through external pull-up resistors on the bus.
When the I2C master wants to start a transmission on the bus, it issues a START condition
which is defined as a high-to-low transition of the SDA signal while SCL is high (see
Figure 82).
When the I2C master wants to terminate the transmission, it issues a STOP condition which
is defined as a low-to-high transition of the SDA signal while SCL is high.
When data is being transmitted on the bus, the SDA line must be stable when SCL is high.
226/368
Doc ID 022640 Rev 3
RM0319
I2C bus ports (I2C)
Figure 82. START and STOP conditions [from I2C-bus specification]
SDA
SCL
S
P
STOP Condition
START Condition
Addressing slave protocol
Two address formats are supported: the 7-bit address format and the 10-bit address format.
In case of the 7-bit address format, the first seven bits (bits 7 to 1) of the first byte sent on
the bus after the START condition set the slave address, while the LSB is the data direction
bit. In particular, if LSB is set to ‘b0, the master writes to the slave (WRITE operation),
otherwise (LSB set to ‘b1) the master reads from the slave (READ operation). Data is
transmitted from the MSB.
In case of 10-bit addressing, two bytes are transferred following a START condition to set
the 10-bit address. The first five bits (7 to 3) notify the slaves that this is a 10-bit transfer,
followed by the next two bits (2 to 1) which set the bits 9 and 8 of the 10-bit slave address.
The LSB of the first byte is the RW bit. Table 66 lists the special purpose and reserved first
byte addresses. The second byte transferred sets bits 7 to 0 of the 10-bit slave address.
Table 66.
First byte assignment in addressing slave protocol
First byte sent
Description
BIT [7:1]
RW BIT [0]
7’b0000 000
1‘h0
General call address. The I2C controller places the data in
the receive buffer and issues a general call interrupt
(Section 17.6).
7’b0000 000
1‘h1
START byte (see START byte transfer protocol section).
7’h0000 001
1’hX
CBUS address. The I2C controller ignores these accesses.
7’h0000 010
1’hX
Reserved
7’h0000 011
1’hX
Reserved
7’h0000 1XX
1’hX
High-speed master code
7’h1111 1XX
1’hX
Reserved
7’h1111 0XX
1’hX
10-bit slave addressing
Doc ID 022640 Rev 3
227/368
I2C bus ports (I2C)
RM0319
Transmitting and receiving protocol
All data is transmitted in byte format, with no limits on the number of bytes transferred per
data transfer. After the master sends the slave address and the data direction bit, or the
master transmits a byte of data to the slave, the slave-receiver must respond with the
acknowledge signal after every byte of data is received. When a slave-receiver does not
respond with an acknowledge pulse, the master aborts the transfer by issuing a STOP
condition. The slave shall leave the SDA line high so the master can abort the transfer.
If the master is receiving data, then the master-receiver responds to the slave-transmitter
with an acknowledge pulse after a byte of data has been received, except for the last byte.
This is the way the master-receiver notifies the slave-transmitter that this is the last byte.
The slave-transmitter relinquishes the SDA line after detecting the no acknowledge so that
the master-receiver can issue a STOP condition.
When the master does not want to relinquish the bus with a STOP condition, the master can
issue a repeated start condition. This is identical to a START condition except it occurs after
the acknowledge pulse. The master can then communicate with the same slave or with a
different slave.
START byte transfer protocol
The START byte transfer protocol is set up for systems that do not have an on-board
dedicated I2C hardware module. In this case, the systems can not be interrupted only by
requests from the I2C bus, but they must constantly monitor the bus (software polling).
When the I2C controller is addressed as a slave, it always samples the I2C bus at the
highest speed supported, so that it never requires START byte transfer. However, when the
I2C controller is a master, it supports the generation of START byte transfer at the beginning
of every transfer in case a slave device requires it.
As depicted in Figure 83 below, the start procedure is as follows:
●
Master generates a start condition (as explained above).
●
Master transmits the start byte (constant 8’b0000 0001).
●
Master transmits an acknowledge clock pulse.
●
No slave sets the acknowledge signal to 1‘b0.
●
Master generates a repeated START (Sr) condition.
Figure 83. START byte procedure [from I2C-bus specification]
SDA
Dummy
Acknowledge HIGH
SCL
S
1
2
7
8
9
ACK
Sr
Start byte 00000001
The START byte protocol consists of seven zeros being transmitted followed by a ‘b1 (the
start byte). This allows the system processor that is polling the bus to under-sample the
address phase until ‘b0 (low level on SDA) is detected. Once the system processor detects
a low level on SDA, it switches to a higher sampling rate to find the Sr condition of the
master (which is the one used for synchronization).
228/368
Doc ID 022640 Rev 3
RM0319
I2C bus ports (I2C)
A hardware receiver does not respond to the START byte because it is a reserved address
and it resets after the Sr (restart condition) is generated.
17.3.3
DMA controller Interface
The I2C controller has a handshaking interface to request and control transfers from the
DMA controller of the SPEArTM device. The APB bus is used to perform the data transfer to
or from the DMA.
Note:
When the DMA controller of the SPEArTM device is used for data transfers to/from the I2C
controller, the DMA controller must always be programmed as the flow controller; that is, the
DMA controller controls the block size.
Enabling the DMA controller Interface
To enable the DMA controller interface on the I2C, the DMA Control Register (IC_DMA_CR)
has to be set. Writing a 'b1 into the TDMAE bit field of IC_DMA_CR register, it enables the
I2C controller transmit handshaking interface. Besides, writing a 'b1 into the RDMAE bit field
of the IC_DMA_CR register, the I2C controller receive handshaking interface is enabled.
Transmit Watermark Level and Transmit FIFO Underflow
During I2C controller serial transfers, transmit FIFO requests are made to the DMA
controller whenever the number of entries in the transmit FIFO is less than or equal to the
DMA Transmit Data Level Register (IC_DMA_TDLR) value, this is known as the "watermark
level".
The DMA controller responds by writing a burst of data to the transmit FIFO buffer. Data
should be written by the DMA often enough for the transmit FIFO to perform serial transfers
continuously; that is, when the FIFO begins to empty another DMA request should be
triggered. Otherwise, the FIFO will run out of data (underflow). To prevent this condition, the
user must set the watermark level correctly.
Choosing the Transmit Watermark Level
Choosing a watermark level can minimize the number of transactions per block, keeping the
probability of an underflow condition to an acceptable level.
In practice, this is a function of the ratio of the rate at which the I2C transmits data to the rate
at which the DMA can respond to destination burst requests. For example, promoting the
channel to the highest priority channel in the DMA, and promoting the DMA master interface
to the highest priority master in the AMBA layer, increases the rate at which the DMA
controller can respond to burst transaction requests. This in turn allows the user to decrease
the watermark level, which improves bus utilization without compromising the probability of
an underflow occurring.
Receive Watermark Level and Receive FIFO Overflow
During I2C controller serial transfers, receive FIFO requests are made to the DMA controller
whenever the number of entries in the receive FIFO is at or above the DMA Receive Data
Level Register (IC_DMA_RDLR), that is DMARDLR + 1, which is known as the "watermark
level".
The DMA controller responds by fetching a burst of data from the receive FIFO buffer. Data
should be fetched by the DMA often enough for the receive FIFO to accept serial transfers
continuously; that is, when the FIFO begins to fill, another DMA transfer is requested.
Doc ID 022640 Rev 3
229/368
I2C bus ports (I2C)
RM0319
Otherwise, the FIFO will fill with data (overflow). To prevent this condition, the user must
correctly set the watermark level.”
Choosing the Receive Watermark Level
Similar to choosing the transmit watermark level described earlier, the receive watermark
level should be set to minimize the probability of overflow. It is a trade-off between the
number of DMA burst transactions required per block versus the probability of an overflow
occurring.
17.4
Operation modes
The I2C interface protocol is setup with a master and a slave. The master is responsible for
generating the clock and controlling the transfer of data. The slave is responsible for either
transmitting or receiving data to/from the master. The acknowledgement of data is sent by
the device that is receiving data, which can be either the master or the slave. The protocol
also allows multiple masters to reside on the I2C bus, which requires the masters to arbitrate
for ownership.
According to this specification, the I2C controller provided by the device supports three
distinct operation modes, specifically:
17.4.1
●
Slave mode (Section 17.4.1)
●
Master mode (Section 17.4.2)
●
Multimaster mode (Section 17.4.3)
Slave mode
This section provides information on the slave mode of operation.
Initial configuration
To use the I2C controller as a slave, you must perform the following steps:
230/368
1.
Disable the I2C controller by writing a ‘b0 to the IC_ENABLE register.
2.
Write to the IC_SAR register to set the slave address (only required if the slave address
to be programmed is other than 0x0055). This is the address to which the I2C controller
responds.
3.
Write to the IC_CON register to specify whether 10 bit addressing is supported
(through IC_10BITADDR_SLAVE bit) and whether the I2C controller is in slave-only or
master-slave mode. The master-only mode is not valid in slave mode.
4.
Enable the I2C controller setting the IC_ENABLE register.
Doc ID 022640 Rev 3
RM0319
I2C bus ports (I2C)
Slave-transmitter operation
When another master addresses the I2C controller to requests data, the I2C controller acts
as a slave-transmitter, and the following steps occur:
●
The other master initiates an I2C transfer with an address that matches the slave
address in the IC_SAR register of the slave I2C controller (programmed during initial
configuration),
●
The I2C controller acknowledges the sent address and recognizes the direction of
transfer to indicate that it is acting as a slave-transmitter,
●
The I2C controller asserts the RD_REQ interrupt, (and relevant bit in
IC_RAW_INTR_STAT register is set) and holds the SCL line low, placing in a wait state
until software responds,
●
If there is any data remaining in the Transmit FIFO before receiving the read request,
then the I2C controller asserts a TX_ABRT interrupt, section, (and relevant bit in
IC_RAW_INTR_STAT register is set) to flush the old data from the Transmit FIFO,
●
Software then writes the IC_DATA_CMD register with the data to be written, setting to
1‘b0 the CMD bit (meaning a write operation),
●
Software should clear the RD_REQ and the TX_ABRT interrupts before proceeding,
●
The I2C controller releases the SCL and transmits the byte,
●
Finally, the master may hold the I2C bus by issuing a restart condition or release the
bus by issuing a stop condition.
Slave-receiver operation
When another master addresses the I2C controller to send its data, the I2C controller acts
as a slave-receiver and the following steps occur:
●
The other master initiates an I2C transfer with an address that matches the I2C
controller slave address in the IC_SAR register, programmed during initial
configuration,
●
The I2C controller acknowledges the sent address and recognizes the direction of
transfer to indicate that it is acting as a slave-receiver,
●
The I2C controller receives the transmitted byte from the master and place it in the
receive buffer, assuming there is room for this incoming data,
●
The status and interrupt bits corresponding to the receive buffer are updated,
●
Software may read the received byte from the IC_DATA_CMD register, setting to 1‘b1
the CMD bit (meaning a read operation),
●
Finally, the other master may hold the I2C bus by issuing a restart condition or release
the bus by issuing a stop condition.
Slave bulk transfer mode
In the standard I2C protocol, all transaction are single byte transactions and a remote
master read request is replied by writing one byte into the transmit FIFO.
In the mode named slave bulk transfer, if the remote master acknowledged the sent byte to
request more data, then the slave must hold the I2C SCL line low and request another byte
from the processor side. If it is known in advance that the remote master is requesting a
packet of n bytes, then when another master addresses the I2C controller and request data,
the Transmit FIFO could be written with 16 number of bytes and the remote master will
receive it as a continuous stream of data.
Doc ID 022640 Rev 3
231/368
I2C bus ports (I2C)
RM0319
If the remote master is to receive n bytes from the I2C controller, but a number of bytes
larger than n is written to the Transmit FIFO then, when the slave finishes sending the
requested n bytes, it will clear the Transmit FIFO and ignore any excess bytes.
17.4.2
Master mode
Initial configuration
To use the I2C controller as a master, you must perform the following steps:
1.
Disable the I2C controller by writing a 1‘b0 to the IC_ENABLE register.
2.
Write to the IC_CON register to set the maximum speed mode supported and the
desired speed of the I2C controller master-initiated transfers, 7- or 1-0 bit addressing.
3.
Write to the IC_TAR register the address of the I2C device to be addressed by the I2C
controller as a master (10-bit field IC_TAR). It also indicates whether adding a START
BYTE or issuing a general call is going to occur (through the GC_OR_START bit on the
same register), The desired speed of the I2C controller master-initiated transfer is
controlled by the IC_10BITADDR_MASTER bit in the IC_TAR register,
4.
For high-speed mode transfer only: the desired master code for I2C controller must be
written to the IC_HS_MADDR register (3-bit IC_HS_MAR field),
5.
Enable again the I2C controller setting the IC_ENABLE register,
6.
Command and data to be sent may be written now to the IC_DATA_CMD register. If this
register is written before I2C controller is enabled, the data and commands are lost as
the buffers are kept cleared when I2C controller is not enabled.
Dynamic IC_TAR or IC_10BITADDR_MASTER update
The I2C controller supports a dynamic IC_TAR or IC_10BITADDR_MASTER update.
Even if the slave part of the DW_apb_i2c is involved in an I2C transfer, both of the following
must occur:
Note:
●
MST_ACTIVITY must be IDLE, that is, IC_STATUS[5] = ‘b0,
●
Transmit FIFO completely empty must occurs, that is, IC_STATUS[2] = ‘b0.
If a bulk read is performed on the slave part of the DW_apb_i2c over the I2C bus, then only
MST_ACTIVITY must be IDLE, that is, the Transmit FIFO does not need to be completely
empty. This is a very specific case and should be monitored in software.
To write to the IC_TAR register, dynamically write the IC_TAR and
IC_10BITADDR_MASTER using the following requirements:
232/368
●
IC_TAR[12] = IC_10BITADDR_MASTER. Master uses 7 or 10 bit addressing and is
writable when the conditions in step 1 are met and if I2C_DYNAMIC_TAR_UPDATE is
set to ‘b1,
●
IC_TAR[11:10] = Only writable when DW_apb_i2c interface is disabled, which
corresponds to the IC_ENABLE register being set to ‘b0. otherwise writes have no
effects,
●
IC_TAR[9:0] = IC_TAR. Master’s 10 bit target address is writable at any time when the
conditions in step 1 are met and if I2C_DYNAMIC_TAR_UPDATE is set to ‘b1.
Doc ID 022640 Rev 3
RM0319
I2C bus ports (I2C)
Master transmit and master receive
The I2C controller supports switching back and forward between reading and writing
dynamically. To transmit data, write the data to be written to the lower byte of the
IC_DATA_CMD register. The CMD bit in the same register should be written to ‘b0 meaning
a write operation. Subsequently, a read command may be issued by writing “don’t care” to
the lower byte of the IC_DATA_CMD register, and a ‘b1 should be written to the CMD bit.
As data is transmitted and received, transmit and receive buffer status bits and interrupts
change accordingly.
17.4.3
Multimaster mode
In a multiple master I2C bus system, the I2C controller should not be programmed as a
master device. For multiple master systems, the I2C controller can only be operated as a
slave (set IC_CON.MASTER_MODE to 0 (master disabled).
The I2C controller bus protocol allows multiple masters to reside on the same bus. When
two or more masters try to transfer information on the bus at the same time, they must
arbitrate and synchronize the SCL clock.
Master arbitration
Arbitration takes place on the SDA line, while the SCL line is ‘b1. The master, which
transmits a ‘b1 while the other master transmits ‘b0, loses arbitration and turns off its data
output. The master that lost arbitration can continue to generate clocks until the end of the
byte transfer. If both masters are addressing the same slave device, the arbitration could go
into the data phase.
For high-speed mode, the arbitration can not go into the data phase, because each master
is programmed with a different high-speed master code. Because the codes are unique,
only one master can win arbitration, which occurs by the end of the transmission of the highspeed master code.
Figure 84. Multiple master arbitration
‘1’
MSB
DATA1
DATA1 loses arbitration
matching data
DATA2
MSB
‘0’
SDA mirrors DATA2
SDA
MSB
SCL
SDA lines up with
DATA1 START
condition
Doc ID 022640 Rev 3
233/368
I2C bus ports (I2C)
17.5
RM0319
Clocks
All masters generate their own clock to transfer messages, and data is valid only during the
high period of SCL clock.
Clock synchronization is performed using the wired-AND connection to the SCL signal.
When the master transitions the SCL clock to ‘b0, the master starts counting the low time of
the SCL clock and transitions the SCL clock signal to ‘b1 at the beginning of the next clock
period. However, if another master is holding the SCL line to ‘b0, then the master goes into
a high wait state until the SCL clock line transitions to ‘b1.
All masters then count off their high time, and the master with the shortest high time
transitions the SCL line to ‘b0. The masters counts out their low time and the one with the
longest low time forces the other master into a high wait state. Therefore, a synchronized
SCL clock is generated.
Note:
Optionally, slaves may hold the SCL line low to slow down the timing on the I2C bus.
Figure 85. Clock synchronization
Wait
State
Start counting HIGH
period
CLKA
CLKB
SCL
SCL LOW Transition Resets all CLKs
to start
counting their LOW periods
17.6
SCL Transitions HIGH
when all CLKs are in HIGH state
Interrupts
The following table lists the interrupt generated within the I2C controller. These interrupt
sources could be masked using the IC_INTR_MASK register.
Interrupts status (after masking) and raw interrupts status (before masking) are available
through IC_INTR_STAT and IC_RAW_INTR_STAT register, respectively.
234/368
Doc ID 022640 Rev 3
RM0319
I2C bus ports (I2C)
Table 67.
I2C controller interrupt sources
Name
Source
GEN_CALL
General call request received.
Indicates that a general call request was received (refer to Section 17.3.2:
I2C protocols on page 226). The I2C controller stores the received data in
the Receive buffer.
START_DET
START condition occurred.
Indicates that a START condition has occurred on the I2C interface (refer to
Section 17.3.2: I2C protocols on page 226).
STOP_DET
STOP condition occurred.
Indicates that a STOP condition has occurred on the I2C interface (refer to
Section 17.3.2: I2C protocols on page 226).
ACTIVITY
Capture system activity.
This bit captures I2C controller activity and it remains set until it is cleared,
regardless of the I2C controller going idle.
RX_DONE
Indicates transmission done.
This bit is set to 1‘b1 if the master does not acknowledge a transmitted
byte, while I2C controller is acting as a slave-transmitter. This occurs on the
last byte of the transmission, indicating that the transmission is done.
TX_ABRT
Indicates transmission abort.
This bit is set to ‘b1 when the I2C controller, acting as a master, is unable to
complete a command that the processor has sent. Several conditions could
cause this interrupt to be issued:
– no slave acknowledge after the address is sent,
– the address slave does not acknowledge a byte of data,
– arbitration is lost,
– attempting to send a master command when configured only to be slave,
– IC_RESTART_EN bit in the IC_CON register is set to ‘b0 (restart
condition disabled), and the processor attempts to issue an I2C function
that is impossible to perform without using restart conditions,
– high-speed master code is acknowledged,
– start byte is acknowledged,
– general call address is not acknowledged,
– when a read request interrupt occurs and the processor has previously
placed the data in transmit buffer that has not been transmitted yet. This
data could have been intended to service a multibyte RD_REQ that
ended up having fewer numbers of byte requested. Or, if
IC_RESTART_EN is disabled and the I2C loses control of the bus
between transfers and is then accessed as a slave-transmitter,
– if a read command is issued after a general call command has been
issued. Disabling the I2C reverts it back to normal operation,
– if the processor attempts to issue read command before a RD_REQ is
serviced.
Anytime this bit is set, the contents of both transmit and receive buffers are
flushed.
Doc ID 022640 Rev 3
235/368
I2C bus ports (I2C)
Table 67.
236/368
RM0319
I2C controller interrupt sources (continued)
Name
Source
RD_REQ
Read request.
This bit is set to ‘b1 when the I2C controller is acting as a slave and another
I2C master is attempting to read data from our module. The I2C controller
holds the I2C bus in waiting state (SCL tied to low) until this interrupt is
serviced. The processor must acknowledge this interrupt and then write
the request data to the IC_DATA_CMD register.
TX_EMPTY
Transmit buffer at threshold value.
This bit is set to ‘b1 when the transmit buffer is at or below the threshold
value set in the IC_TX_TL register. It is automatically cleared by hardware
when buffer level goes above the threshold.
TX_OVER
Transmit buffer filled to IC_TX_BUFFER_DEPTH.
This bit is set during transmit if the transmit buffer is filled to
IC_TX_BUFFER_DEPTH and the processor attempts to issue another I2C
command by writing to the IC_DATA_CMD register.
RX_FULL
Transmit buffer reach RX_TL threshold.
This bit is set when the transmit buffer reaches or goes above the threshold
set in the IC_RX_TL register. It is automatically cleared by hardware when
buffer level goes below the threshold.
RX_OVER
Receive buffer filled to IC_RX_BUFFER_DEPTH.
This bit is set when the receive buffer was completely filled to
IC_RX_BUFFER_DEPTH and more data arrived. The data is lost.
RX_UNDER
Receive buffer empty.
This bit is set when the processor attempts to read the receive buffer when
it is empty by reading from the IC_DATA_CMD register.
Doc ID 022640 Rev 3
RM0319
18
Synchronous serial ports (SSP)
Synchronous serial ports (SSP)
This chapter focuses on SSP functionality and operation.
For technical details about the programmable registers related to the SSP, refer to the SSP
registers in the following companion document:
●
18.1
RM0321: SPEAr320S address map and registers
Overview
The synchronous serial port (SSP) block includes a master or slave interface to enable
synchronous serial communication with slave or master peripherals.
18.2
18.3
Main features
●
Master or slave operation
●
Programmable clock bit rate and prescale
●
Separate transmit and receive first-in, first-out memory buffers, 16 bits wide, 8 locations
deep
●
Programmable choice of interface operation, SPI, Microwire, or TI synchronous serial
●
Programmable data frame size from 4 to 16 bits
●
Independent masking of transmit FIFO, receive FIFO, and receive overrun interrupts
●
Internal loopback test mode available
●
Support for direct memory access (DMA)
Pins
Table 68.
SSP pin description
SSP in master mode
SSP in slave mode
SSP Port
Function
Direction
Function
Direction
SSP0_MOSI
Transmit Data
Out
Receive Data
In
SSP0_MISO
Receive Data
In
Transmit Data
Out
SSP0_CLK
Clock
Out
Clock
In
SSP0_SS0
Slave select (chip-select)
Out
Slave select (chip-select)
In
SSP0_CS2
Slave select (chip-select)
Out
Not Used
-
SSP0_CS3
Slave select (chip-select)
Out
Not Used
-
SSP0_CS4
Slave select (chip-select)
Out
Not Used
-
SSP1_MOSI
Transmit Data
Out
Receive Data
In
SSP1_MISO
Receive Data
In
Transmit Data
Out
SSP1_CLK
Clock
Out
Clock
In
Doc ID 022640 Rev 3
237/368
Synchronous serial ports (SSP)
Table 68.
RM0319
SSP pin description
SSP in master mode
SSP in slave mode
SSP Port
18.4
Function
Direction
Function
Direction
SSP1_SS0
Slave select (chip-select)
Out
Slave select (chip-select)
In
SSP2_MOSI
Transmit Data
Out
Receive Data
In
SSP2_MISO
Receive Data
In
Transmit Data
Out
SSP2_CLK
Clock
Out
Clock
In
SSP2_SS0
Slave select (chip-select)
Out
Slave select (chip-select)
In
Functional description
Figure 86 shows the block diagram of the SSP controller.
Figure 86. SSP block diagram
Tx FIFO
(8x16)
AMBA APB
I/F
FIFO Status
And
Interrupt
Generation
IRQ
Transmit/
Receive
logic
SPI BUS
Rx FIFO
(8x16)
PCLK
Register
Block
Clock
Prescaler
DMA
interface
18.4.1
APB slave interface
The AMBA APB interface generates read and write decodes for accesses to status and
control registers, and transmit and receive FIFO memories.
18.4.2
Register block
The register block stores data written or to be read across the AMBA APB interface.
238/368
Doc ID 022640 Rev 3
RM0319
18.4.3
Synchronous serial ports (SSP)
Clock prescaler
When configured as a master, an internal prescaler, comprising two free-running reloadable serially linked counters, is used to provide the serial output clock SSPx_CLK (x is
either 0, 1 or 2).
You can program the clock prescaler, through the SSPCPSR register, to divide input clock
(PCLK, which is internal to the device) by a factor of 2 to 254 in steps of two. By not utilizing
the least significant bit of the SSPCPSR register, division by an odd number is not possible
and this ensures a symmetrical (equal mark space ratio) clock is generated.
The output of the prescaler is further divided by a factor of 1 to 256, through the
programming of the SSPCR0 control register, to give the final master output clock
SSPx_CLK.
18.4.4
Transmit FIFO
The common transmit FIFO is a 16-bit wide, 8-location deep, first-in, first-out memory buffer.
CPU data written across the AMBA APB interface are stored in the buffer until read out by
the transmit logic.
When configured as a master or a slave parallel data is written into the transmit FIFO prior
to serial conversion and transmission to the attached slave or master respectively, through
the SSPx_MOSI or SSPx_MISO pin (based on the master or slave mode of operation
respectively).
18.4.5
Receive FIFO
The common receive FIFO is a 16-bit wide, 8-location deep, first-in, first-out memory buffer.
Received data from the serial interface are stored in the buffer until read out by the CPU
across the AMBA APB interface.
When configured as a master or slave, serial data received through the SSPx_MISO or
SSPx_MOSI pin (based on the master or slave mode of operation respectively) is registered
prior to parallel loading into the attached slave or master receive FIFO respectively.
18.4.6
Transmit and receive logic
When configured as a master, the clock to the attached slaves is derived from a divided
down version of PCLK through the prescaler operations described previously. The master
transmit logic successively reads a value from its transmit FIFO and performs parallel to
serial conversion on it. Then the serial data stream and frame control signal, synchronized
to SSPx_CLK, are output through the SSPx_MOSI pin to the attached slaves. The master
receive logic performs serial to parallel conversion on the incoming synchronous
SSPx_MISO data stream, extracting and storing values into its receive FIFO, for subsequent
reading through the APB interface.
When configured as a slave, the SSPx_CLK clock is provided by an attached master and
used to time its transmission and reception sequences. The slave transmit logic, under
control of the master clock, successively reads a value from its transmit FIFO, performs
parallel to serial conversion, then output the serial data stream and frame control signal
through the slave SSPx_MISO pin. The slave receive logic performs serial to parallel
conversion on the incoming SSPx_MOSI data stream, extracting and storing values into its
receive FIFO, for subsequent reading through the APB interface.
Doc ID 022640 Rev 3
239/368
Synchronous serial ports (SSP)
18.4.7
RM0319
DMA interface
This block manages the DMA interface. It can work in single transfer mode or in burst
transfer mode.
Refer to the Chapter 36: DMA controller (DMAC) for more details on this interface.
18.4.8
Interrupt generation
The SSP generates four individual maskable, active HIGH interrupts.
A combined interrupt output is also generated as an OR function of the individual interrupt
requests.
You can use the single combined interrupt with a system interrupt controller that provides
another level of masking on a per-peripheral basis. This allows use of modular device
drivers that always know where to find the interrupt source control register bits.
The individual interrupt requests could also be used with a system interrupt controller that
provides masking for the outputs of each peripheral. In this way, a global interrupt controller
service routine would be able to read the entire set of sources from one wide register in the
system interrupt controller. This is attractive where the time to read from the peripheral
registers is significant compared to the CPU clock speed in a real-time system.
The peripheral supports both the above methods.
The transmit and receive dynamic data-flow interrupts are separated from the status
interrupts so that data can be read or written in response to the FIFO trigger levels.
See also: Section 18.6: Interrupts.
18.5
Operation
18.5.1
Configuring the SSP
After reset, the SSP logic is disabled and must be configured. The control registers
SSPCR0 and SSPCR1 need to be programmed to configure the peripheral as a master or
slave operating under one of the following protocols:
●
Motorola SPI
●
Texas Instruments SSI
●
National Semiconductor
The bit rate, derived from the APB clock (PCLK), requires the programming of the clock
prescale register SSPCPSR. (Refer to the miscellaneous registers description for the PCLK
frequency).
Chip select for SSP0 - only in master mode of operation
In the master mode of operation, SSP0 can select between four slaves connected externally.
This is achieved through a separate chip select (CS) generation logic using the basGPIO
module.
GPIODATA[7] and [6] are used to route the single CS generated by the SSP0 block to four
external pins.
The external CS is generated as per the following table:
240/368
Doc ID 022640 Rev 3
RM0319
Synchronous serial ports (SSP)
Table 69.
External CS selection
GPIODATA register bit [7]
output value
GPIODATA register bit [6]
output value
0
0
SSP0_SS0
0
1
SSP0_CS2
1
0
SSP0_CS3
1
1
SSP0_CS4
External slave select pin
Programming sequence for generating chip select (SSP0_CS2, SSP0_CS3, SSP0_CS4 not required for SSP0_SS0);
1.
Program control bits [12:11] in the RAS Select Register to enable SPI_enhanced
mode.
2.
Program the GPIODATA register bits [7:6] with the above values from Table 69 to select
one of the SSP0_CSx pins.
3.
Program SSP0 in master mode.
4.
Enable transmit-receive
Follow steps 2-4 if a different slave is to be selected.
Note:
18.5.2
1
All current transmission/reception must end before enabling CS for a different slave.
2
Enabling "Enhanced mode for SSP0" will disable any other functionality on PL_GPIO[36],
PL_GPIO[35], PL_GPIO[34] EXCEPT SSP0_CSx.
Enabling SSP operation
To enable SSP, you can either:
●
prime the transmit FIFO, by writing up to eight 16-bit values when the SSP is disabled,
-or-
●
allow the transmit FIFO service request to interrupt the CPU.
Once enabled, transmission or reception of data begins on the SSPx MOSI and
SSPx_MISO pins.
Clock ratios
There is a constraint on the ratio of the frequencies of PCLK to SSPCLK. The frequency of
SSPCLK must be less than or equal to that of PCLK. This ensures that control signals from
the SSPCLK domain to the PCLK domain are certain to get synchronized before one frame
duration:
FSSPCLK <= FPCLK.
In the slave operation, the SSPCLKIN signal from the external master is double
synchronized and then delayed to detect an edge. It takes three SSPCLKs to detect an edge
on SSPCLKIN. SSPTXD has less setup time to the falling edge of SSPCLKIN on which the
master is sampling the line. The setup and hold times on SSPRXD with reference to
SSPCLKIN must be more conservative to ensure that it is at the right value when the actual
sampling occurs within the SSPMS. To ensure correct device operation, SSPCLK must be at
least 12 times faster than the maximum expected frequency of SSPCLKIN.
Doc ID 022640 Rev 3
241/368
Synchronous serial ports (SSP)
RM0319
The frequency selected for SSPCLK must accommodate the desired range of bit clock
rates. The ratio of minimum SSPCLK frequency to SSPCLKOUT maximum frequency in the
case of the slave mode is 12 and for the master mode it is two.
To generate a maximum bit rate of 1.8432 Mbps in the master mode, the frequency of
SSPCLK must be at least 3.6864 MHz. With an SSPCLK frequency of 3.6864 MHz, the
SSPCPSR register must be programmed with a value of two and the SCR[7:0] field in the
SSPCR0 register needs to be programmed as zero.
To work with a maximum bit rate of 1.8432 Mbps in the slave mode, the frequency of
SSPCLK must be at least 22.12 MHz. With an SSPCLK frequency of 22.12 MHz, the
SSPCPSR register can be programmed with a value of 12 and the SCR[7:0] field in the
SSPCR0 register can be programmed as zero. Similarly the ratio of SSPCLK maximum
frequency to SSPCLKOUT minimum frequency is 254 x 256.
The minimum frequency of SSPCLK is governed by the following equations, both of which
have to be satisfied:
FSSPCLK(min) => 2 x FSSPCLKOUT(max) [for master mode]
FSSPCLK(min) => 12 x FSSPCLKIN(max) [for slave mode]
The maximum frequency of SSPCLK is governed by the following equations, both of which
have to be satisfied:
FSSPCLK(max) <= 254 x 256 x FSSPCLKOUT(min) [for master mode]
FSSPCLK(max) <= 254 x 256 x FSSPCLKIN(min) [for slave mode]
18.5.3
Programming the SSPCR0 control register
The SSPCR0 register is used to:
●
Program the serial clock rate
●
Select one of the three protocols
●
Select the data word size (where applicable).
The Serial Clock Rate (SCR) value, in conjunction with the SSPCPSR clock prescale divisor
value (CPSDVSR), is used to derive the SSP transmit and receive bit rate from PCLK.
The frame format is programmed through the FRF bits and the data word size through the
DSS bits.
Bit phase and polarity, applicable to Motorola SPI format only, are programmed through the
SPH and SPO bits.
18.5.4
Programming the SSPCR1 control register
The SSPCR1 register is used to:
●
Select master or slave mode
●
Enable a loop back test feature
●
Enable the SSP peripheral.
To configure the SSP as a master, clear the SSPCR1 register master or slave selection bit
(MS) to 0, which is the default value on reset.
Setting the SSPCR1 register MS bit to 1 configures the SSP as a slave. When configured as
a slave, enabling or disabling of the transmit signal is provided through the slave mode
242/368
Doc ID 022640 Rev 3
RM0319
Synchronous serial ports (SSP)
transmit output disable bit (SOD). This can be used in some multislave environments where
masters might parallel broadcast.
To enable the operation of the SSP set the Synchronous Serial Port Enable (SSE) bit to 1.
Bit rate generation
Dividing down the PCLK derives the serial bit rate. The clock is first divided by an even
prescale value CPSDVSR from 2 to 254, which is programmed in SSPCPSR. The clock is
further divided by a value from 1 to 256, which is 1 + SCR, where SCR is the value
programmed in SSPCR0.
The frequency of the output signal bit clock SSPx_CLK is:
f PCLK
f SSPxCLK = -------------------------------------------------------------CPSDVSR ⋅ ( 1 + SCR )
For example, if PCLK is 3.6864 MHz, and CPSDVSR = 2, then SSPx_CLK has a frequency
range from 7.2 kHz to 1.8432 MHz.
18.5.5
Frame format
Each data frame is between 4 and 16 bits long depending on the size of data programmed,
and is transmitted starting with the MSB. There are three basic frame types that can be
selected:
●
Texas Instruments synchronous serial
●
Motorola SPI
●
National semiconductor microwire.
For all three formats, the serial clock (SSPx_CLK) is held inactive while the SSP is idle, and
transitions at the programmed frequency only during active transmission or reception of
data. The idle state of SSPx_CLK is utilized to provide a receive timeout indication that
occurs when the receive FIFO still contains data after a timeout period.
For Motorola SPI and National Semiconductor Microwire frame formats, the serial frame
(SSPx_SS) pin is active LOW, and is asserted (pulled down) during the entire transmission
of the frame.
For Texas Instruments synchronous serial frame format, the SSPx_SS pin is pulsed for one
serial clock period starting at its rising edge, prior to the transmission of each frame. For this
frame format, both the SSP and the off-chip slave device drive their output data on the rising
edge of SSPx_CLK, and latch data from the other device on the falling edge.
Unlike the full-duplex transmission of the other two frame formats, the National
Semiconductor Microwire format uses a special master-slave messaging technique, which
operates at half-duplex. In this mode, when a frame begins, an 8 bit control message is
transmitted to the off-chip slave. During this transmission no incoming data is received by
the SSP. After the message has been sent, the off-chip slave decodes it and, after waiting
one serial clock after the last bit of the 8 bit control message has been sent, responds with
the requested data. The returned data can be 4 to 16 bits in length, making the total frame
length anywhere from 13 to 25 bits.
Doc ID 022640 Rev 3
243/368
Synchronous serial ports (SSP)
18.6
RM0319
Interrupts
There are five interrupts generated by the SSP. Four of these are individual, maskable,
active HIGH interrupts:
●
SSP receive FIFO service interrupt request.
●
SSP transmit FIFO service interrupt request.
●
SSP receive overrun interrupt request
●
SSP time out interrupt request.
The fifth is a combined single interrupt.
You can mask each of the four individual maskable interrupts by setting the appropriate bits
in the SSPIMSC register. Setting the appropriate mask bit HIGH enables the interrupt.
Provision of the individual outputs as well as a combined interrupt output, allows use of
either a global interrupt service routine, or modular device drivers to handle interrupts.
The transmit and receive dynamic dataflow interrupts have been separated from the status
interrupts, so that data can be read or written in response to just the FIFO trigger levels.
The status of the individual interrupt sources can be read from SSPRIS and SSPMIS
registers.
18.6.1
Receive interrupt
This interrupt is asserted when there is four or more valid entries in the receive FIFO.
18.6.2
Transmit interrupt
This interrupt is asserted when there are four or less valid entries in the transmit FIFO. The
transmitter interrupt is not qualified with the SSP enable signal, which allows operation in
one of two ways. Data can be written to the transmit FIFO prior to enabling the SSP and the
interrupts. Alternatively, the SSP and interrupts can be enabled so that data can be written
to the transmit FIFO by an interrupt service routine.
18.6.3
Receive overrun interrupt
This interrupt is asserted when the FIFO is already full and an additional data frame is
received, causing an overrun of the FIFO. Data is over-written in the receive shift register,
but not the FIFO.
18.6.4
Receive timeout interrupt
This interrupt is asserted when the receive FIFO is not empty and the SSP has remained
idle for a fixed 32 bit period. This mechanism ensures that the user is aware that data is still
present in the receive FIFO and requires servicing. This interrupt is deasserted if the receive
FIFO becomes empty by subsequent reads, or if new data is received. It can also be cleared
by writing to the RTIC bit in the SSPICR register.
18.6.5
Combined interrupt
This interrupt is an OR function of the individual masked sources. You can connect this
output to the system interrupt controller to provide another level of masking on an individual
244/368
Doc ID 022640 Rev 3
RM0319
Synchronous serial ports (SSP)
per-peripheral basis. The combined SSP interrupt is asserted if any of the four individual
interrupts above are asserted and enabled.
Doc ID 022640 Rev 3
245/368
Fast infrared port (IRDA)
19
RM0319
Fast infrared port (IRDA)
This chapter focuses on FirDA functionality and operation.
For technical details about the programmable registers related to the FirDA, refer to the
FirDA registers in the following companion document:
●
19.1
RM0321: SPEAr320S address map and registers
Overview
SPEAr320S provides a fast IrDA Controller modeled according to the standard of the
infrared data association (IrDA).
It is a programmable infrared controller that acts as an interface between the on-chip AHB
bus and infrared transceiver. This controller is able to perform the modulation and the
demodulation of the infrared signals and the wrapping of the IrDA link access protocol
(IrLAP) frames.
19.2
Main features
●
●
246/368
Supports different standards:
–
IrDA serial infrared physical layer specification (IrPHY), version 1.3
–
IrDA link access protocol (IrLAP), version 1.1
Supports different infrared modes and baud rates:
–
Serial infrared (SIR), with rates 9.6 Kbps, 19.2 Kbps, 38.4 Kbps, 57.6 Kbps and
115.2 Kbps
–
Medium infrared (MIR), with rates 576 Kbps and 1.152 Mbps
–
Fast infrared (FIR), with rate 4 Mbps.
●
Provides a transceiver interface compliant to all IrDA transceivers with configurable
polarity of TX and RX signals.
●
Integrates half-duplex infrared frame transmission and reception.
●
Integrates 16 bit CRC algorithm for SIR and MIR, and 32 bit CRC algorithm for FIR.
●
Generates preamble, start and stop flag.
●
Uses the RZI (return-to-zero inverted) modulation/demodulation scheme for SIR and
MIR, and the 4PPM (4 pulse position modulation) modulation/demodulation scheme for
FIR.
●
Provides synchronization by means of a DPLL in FIR mode.
●
Implements a payload data transfer controllable by either CPU or DMA controller.
●
Presents two clock domains:
–
a dedicated clock (irda_clk signal) for an accurate signal generation (48 MHz, see
for more details the Miscellaneous register PRPH_CLK_CFG[bit 6:5] and PLL
programming sequence description.
–
an independent and variable clock for the bus interface (13 MHz).
Doc ID 022640 Rev 3
RM0319
19.3
Fast infrared port (IRDA)
Functional description
Figure 87 shows the dataflow block diagram of the FIrDA controller.
Figure 87. Dataflow block diagram of the FIrDA controller
TX Signal
RX Signal
Fast IRDA Interface
Synchronization Unit
Modulation Unit
Demodulation Unit
RX Frame
TX Frame
Wrapper Unit
En_symb
En_pulse
Baud
Generation
Unit
Irda_clk
Synchronization
bus_clk
FIFO Unit
Bus interface
Status & Control
Registers
Data Registers
Interrupt & DMA
Registers
Internal Bus
19.3.1
Synchronization unit
The synchronization unit block allows to synchronize the RX signal of the off-chip IrDA
transceiver. The RX signal is sampled by the rising edge of the irda_clk clock signal for
synchronization.
If the synchronization unit detects an activity of the RX signal in the listening state, the FIrDA
controller switches to the reception state and sets the RXS bit of the IrDA_STAT register,
then a signal detected interrupt (SD_INT, Section 19.4) is generated.
Doc ID 022640 Rev 3
247/368
Fast infrared port (IRDA)
RM0319
Besides, if the synchronization unit detects no activity of the RX signal for more than 10 ms
when in reception state, the FIrDA controller switches back to the listening state and resets
the bit RXS of the IrDA_STAT register. At last, a frame invalid interrupt (FI_INT, Section 19.4)
is generated. This behaviour allows to handle the case of a frame abort.
Note:
The used reception abort timer has to be programmed via the field RATV of the
configuration register IrDA_CONF.
19.3.2
Demodulation unit
The demodulation unit is active in the reception state only, and it is responsible for the
demodulation of the synchronized active high RX signal from the synchronization unit in
order to obtain the RX frame. The actual demodulation performed by this unit depends on
the infrared mode (SIR, MIR or FIR).
Note:
The POLRX bit in the IrDA_CONF register must be set according to the polarity of the RX
signal.
SIR and MIR (RZI demodulation)
In SIR mode, RZI (Return-to-Zero-Inverted) modulation is used. This means that for a "0" bit
in the TX (RX) frame a high pulse is generated and for a "1" bit in the TX (RX) frame no
pulse is generated.
For example, the byte to be transmitted is 0x6C, then 01101100 is shifted into the
Modulation Unit, LSB first.
MIR mode also uses RZI modulation, but the pulse length is 1/4 of a bit.
At first, the demodulation unit extends the pulse of the synchronized active high RX signal in
order to avoid jitter influences. Then the obtained signal is then sampled by the en_symb
signal (from the baud rate generation unit, Section 19.3.5: Baud rate generation unit on
page 250) to get the RX frame for wrapper unit.
The en_symb signal has a phase determined by the first rising edge of the incoming RX
signal and is checked (re-adjusted, if needed) every following rising edge.
FIR (4PPM demodulation)
In FIR mode, Four Pulse Position Modulation (4PPM) is used to modulate the TX frame.
Additionally a preamble PA, a start flag STA and a stop flag STO are added as shown in
Figure 88.
248/368
Doc ID 022640 Rev 3
RM0319
Fast infrared port (IRDA)
Figure 88. Tx signal generation at 4 Mbps in FIR mode
IrLAP Frame + CRC32
Tx Frame
Preamble
Start flag
4PPM modulated Tx Frame
Stop flag
The preamble field PA of the synchronized RX signal is used by the receiver to establish
phase lock by means of a DPLL (digital phase locked loop). Then the incoming signal is
sampled with the recovered enable signal en_pulse. To establish symbol synchronization
the receiver, during PA, begins to search for the start flag STA. When it is received correctly
the received starts to demodulate the RX frame and generates a frame detected interrupt
(FD_INT, Section 19.4) until the stop flag STOP, which indicates the end of the frame, is
recognized.
4PPM encoding is achieved by defining a data symbol duration (tFIRsymb) and subsequently
subdividing tFIRsymb into four equal time slices tFIRpw.
tFIRpw marks the time space when an infrared pulse can be sent. Within a data symbol only
one pulse is allowed, thus there exist four different data symbols, which represent the four
possible combinations of two bits. The used data symbols are listed in Table 70 with the
corresponding data bit pairs.
Table 70.
19.3.3
4PPM encoding scheme
Data bit pair
MSB LSB
4PPM data symbol
sent first…last
00
1000
01
0100
10
0010
11
0001
Wrapper unit
The wrapper unit is active in transmission and reception states only.
Reception state
The wrapper unit retrieves the IrLAP frame and the CRC bytes out of the RX frame from
demodulation unit. The decoding mode depends on the used infrared mode, which is
determined by the 2-bit field MODE of the parameter register IrDA_PARA.
After decoding, the IrLAP and CRC bytes are shifted into the FIFO unit. If an error is
detected either in the demodulation unit or in FIFO Unit, the decoding process is aborted.
Doc ID 022640 Rev 3
249/368
Fast infrared port (IRDA)
RM0319
Transmission state
The wrapper unit builds the TX frame out of IrLAP frame which should be transmitted. The
TX frame is then sent (LSB first) to the modulation unit. The encoding mode depends on the
used infrared mode, which is determined by the 2-bit field MODE of the parameter register
IrDA_PARA.
19.3.4
Modulation unit
The modulation unit is active in the transmission state only, and it is responsible for the
modulation of the TX frames from the wrapper unit in order to generate the TX signal for the
off-chip IrDA transceiver. The actual modulation performed by this unit depends on the
infrared mode (SIR, MIR or FIR).
Note:
The POLTX bit in the IrDA_CONF register determines the polarity of the TX signal.
The TX signal is generated by means of the en_symb and en_pulse signals from the baud
rate generation unit (Section 19.3.5: Baud rate generation unit on page 250). If a frame is
completely transmitted, a frame transmitted interrupt (FT_INT, Section 19.4) is generated
and the FIrDA controller changes back to the listening state.
In case of FIR mode a 4PPM modulation is used. Additional preamble (PA), start flag (STA)
and stop flag (STO) are added. With a bit rate of 4 Mbps the resulting data symbol duration
is 500 ns and the chip duration is then 125 ns.
19.3.5
Baud rate generation unit
The baud rate generation unit creates the two enable signals which are used throughout the
FIrDA controller, namely:
●
en_symb, which determines the symbol rate at which the synchronized inverted RX
signal from synchronization unit (Section 19.3.1) is sampled by the demodulation unit
(Section 19.3.2) in the reception state of SIR and MIR modes.
●
en_pulse, which creates the pulses of the TX signal during transmission.
The two signals are obtained from the same irda_clk clock signal by using cascaded clock
dividers, so the resulting frequencies are:
fen_pulse = firda_clk · K/L
fen_symb = fen_pulse / (N+1),
where the values of K, L and N parameters are determined by software setting the 8-bit field
INC, the 11-bit field DEC, and the 8-bit field N, respectively, of the divider register IrDA_DV.
Note:
The fractional divider causes jitter with a maximum of 1/(2·firda_clk), that is 10.417 ns at SIR
and MIR (being firda_clk = 48 MHz), which meets the IrPHY specification.
In case of SIR, for each SIR symbol one bit is transmitted, then the bit rate and the symbol
rate are equal. It follows that the baud rate generation unit has to create the following symbol
rates: fen_symb = 9.6 kHz, 19.2 kHz, 38.4 kHz, 57.6 kHz and 115.2 kHz. Besides, since a
pulse duration of 1.736 µs is used in SIR transmission, the baud rate generation unit has to
create a pulse rate of fen_pulse = 576 kHz.
Like SIR, for each MIR symbol one bit is transmitted only, then the bit rate and the symbol
rate are equal. The baud rate generation unit has to create the following symbol rates,
fen_symb = 576 kHz and 1.152 MHz. Moreover, since a pulse duration of a quarter of the
symbol duration is used for MIR transmission, the baud rate generation unit has to create a
pulse rate of fen_pulse = 4* fen_symb.
250/368
Doc ID 022640 Rev 3
RM0319
Fast infrared port (IRDA)
At last, for each FIR symbol two bits are transmitted: the symbol rate is then one half of the
bit rate, and the baud rate generation unit has to create a unique symbol rate of fen_symb = 2
MHz (being a bit rate of 4 Mbps). Since the pulse duration is a quarter of the symbol
duration for FIR transmission (like MIR), the baud rate generation unit has to create a pulse
rate of fen_pulse = 4* fen_symb.
Table 71 provides a list of the settings of K, L and (N+1) parameters in case of SIR, MIR and
FIR (and with firda_clk = 48 MHz).
Table 71.
SIR
Settings of K,L and (N+1) parameters for SIR,MIR and FIR in baud rate
generation unit
Bit rate [Kbps]
fen_pulse [kHz]
fen_symb [kHz]
K
L
N+1
9.6
576
9.6
3
250
60
19.2
576
19.2
3
250
30
38.4
576
38.4
3
250
15
57.6
576
57.6
3
250
10
115.2
576
115.2
3
250
5
576
2304
576
6
125
4
1152
4608
1152
12
125
4
4000
8000
2000
1
6
4
MIR
FIR
19.3.6
FIFO unit
The FIFO unit allows to control the data transfer between peripheral and system memory,
and to buffer the reception and the transmission data.
In particular, data can be transmitted by writing to the transmission buffer register
(IrDA_TXB), which represent the head of the FIFO, and can be read out from the reception
buffer register (IrDA_RXB, which is the tail of the FIFO.
An 8-stage 32-bit shift register is used as buffer. This allows that data can be transferred at
full speed using DMA burst transfers.
Note:
Since IrDA supports only half-duplex communication, one buffer is used for both
transmission and reception.
The FIrDA controller generates the following request signals to control the data transfer to
and from memory.
:
Table 72.
Request signals
Signal
Description
BREQ_INT
Burst request signal. Request a transfer of a programmed burst of words.
LBREQ_INT
Last burst request signal. Request a last burst transfer.
SREQ_INT
Single request signal. Request a transfer of a single word.
LSREQ_INT
Last single request signal. Request a last single transfer.
Doc ID 022640 Rev 3
251/368
Fast infrared port (IRDA)
RM0319
These signals can either be used as either interrupt requests (Section 19.4) or DMA
requests, and they are reset on the occurrence of the request clear signal (REQCLR) which
is either set by software via IrDA_ICR register or generated by a DMA controller,
respectively. The burst size is programmable by the field BS of IrDA_CONF register.
Transmission state
In order to start to transmit data, the software writes the frame size to the 12 bit field TFS of
transmission frame size register (IrDA_TFS). Then, the FIrDA controller changes to the
transmission state and the FIFO unit asserts burst requests (BREQ_INT) until the amount of
data to be transferred is equal or less than BS.
If the remaining data is equal to BS, a last burst request is issued using LBREQ_INT,
otherwise single requests are issued using SREQ_INT until the last data item is ready, when
LSREQ_INT is used.
Note:
The size of the frame to be transmitted is not necessarily a multiple of 4, so the last word
could be filled up with dummy bytes. The hardware transmits only the valid bytes of the last
word by means of the bit field TFS of IrDA_TFS register.
The data is buffered in an 8-stage 32 bit shift register before it is processed by the FIrDA
controller. If a FIFO underflow occurs before all bytes of a frame has been shifted into the
FIFO, a frame invalid interrupt (FI_INT, Section 19.3.6) is generated, the transmission is
aborted and all pending bytes in the peripheral are discarded.
The next frame to be transmitted can be copied into the buffer only when all bytes of the
current frame are completely transferred to the wrapper unit. The software can write the size
of the next frame into TFS immediately after the last word of the current frame has been
written to the IrDA_TXB register.
Reception state
The received bytes of the frame are shifted from the wrapper unit to the FIFO where the
data is buffered. The received bytes are counted by a 12 bit counter and that value can be
read by software in the received frame size register (IrDA_RFS). If this number is greater
than the maximum number of received bytes (MNRB field in the IrDA_PARA register) the
currently received frame becomes invalid, a buffer overflow occurs and a frame invalid
interrupt (FI_INT, Section 19.4) is generated.
The signal frame complete indicates that the whole data of the current received frame has
been moved to the buffer. The bytes of this frame have to be moved out of the buffer by
software before the next received frame will be shifted into the buffer, if not the next received
frame will be completely discarded.
The buffered data is moved out at full speed bus using DMA burst transfers: the FIFO unit
asserts burst requests (BREQ_INT) until the amount of data to be transferred is equal or
less than BS. If the remaining data is equal to BS, a last burst request is issued using
LBREQ_INT, otherwise single requests are issued using SREQ_INT until the last data item
is ready, when a LSREQ_INT is used.
Note:
252/368
1
The size of the frame to be received is not necessarily a multiple of 4, so the upper bytes of
the last word could be invalid. The SW has to check for invalid bytes of the last word by
means of the bit field RFS of the IrDA_RFS register.
2
Along with the IrLAP bytes, the CRC bytes are also transferred to the memory. The CRC
bytes can be double-checked by the software for the purpose of testing.
Doc ID 022640 Rev 3
RM0319
Fast infrared port (IRDA)
The occurrence of a frame invalid interrupt (FI_INT, Section 19.4) due to any reason during
the reception indicates that the received data has become invalid and then the buffer
content is cleared without sending further requests.
When the received frame has been completely read out of the buffer, the FIrDA controller
changes back to the listening stage.
19.4
Interrupts
Table 73 shows a summary of the interrupts of the FIrDA controller. A brief description of
each interrupt follows after the table.
Table 73.
FIrDA controller interrupt summary
Name
Description
FD_INT
Frame detected.
This type of interrupt indicates that a frame has been detected during the Reception
State (see Section 19.3.3).
FI_INT
Frame invalid.
When it occurs in reception state, it means that the currently received frame is
invalid. This can be due to a CRC error, the reception of an invalid flag (see
Section 19.3.3), a frame abort (see Section 19.3.1), the reception of an invalid
symbol (see Section 19.3.2), the reception of a too long frame or a FIFO overflow
(see Section 19.3.6), or an abort by software. In the interrupt service routine the
software should discard the bytes of the current frame, which have already been
transferred to the memory.
When it occurs in transmission state, it indicates that the current frame has not been
sent completely. This can be due to either a FIFO underflow (see Section 19.3.6), or
an abort by software.
Note: FD_INT must have a lower priority than FI_INT.
SD_INT
Signal detected.
This kind of interrupt indicates that a signal has been detected by the
Synchronization Unit during the Listening State (Section 19.3.1).
FT_INT
Frame transmitted.
This kind of interrupt occurs when a frame has been completely transmitted by the
Modulation Unit (see Section 19.3.4).
BREQ_INT
Burst request.
This interrupt occurs when a transfer of a programmed burst number of words
from/to the memory is requested. This request can either be used as interrupt or
DMA requests (see Section 19.3.6).
LBREQ_INT
Last burst request.
This interrupt indicates that a last burst transfer from/to the memory is requested.
This request can either be used as interrupt or DMA requests (see Section 19.3.6).
Doc ID 022640 Rev 3
253/368
Fast infrared port (IRDA)
Table 73.
254/368
RM0319
FIrDA controller interrupt summary
Name
Description
SREQ_INT
Single request.
This interrupt indicates that a transfer of a single word from/to the memory is
requested. This request can either be used as interrupt or DMA requests (see
Section 19.3.6).
LSREQ_INT
Last single request.
This interrupt occurs when a last single transfer from/to the memory is requested.
This request can either be used as interrupt or DMA requests (see Section 19.3.6).
Doc ID 022640 Rev 3
RM0319
20
Legacy IEEE 1284 parallel port (SPP)
Legacy IEEE 1284 parallel port (SPP)
This chapter focuses on SPP functionality and operation.
For technical details about the programmable registers related to the SPP, refer to the SPP
registers in the following companion document:
●
20.1
RM0321: SPEAr320S address map and registers
Overview
The standard parallel port (SPP) interface is an AMBA-APB slave interface to the SPP bus.
It is used to receive data over this bus from an external host and transfer it to a processor.
20.2
20.3
Main features
●
Slave mode device interface for Standard parallel port Host
●
IEEE 1284 Compatible device
●
Supports unidirectional 8 bit data transfer from host to slave
●
Supports 9th bit for parity/ data/ command etc.
●
Maskable Interrupts for data, device reset, Auto Linefeed
●
APB input clock frequency required is 83 MHz for acknowledgement timings
●
Conforms to AMBA-APB specifications
Functional description
The SPP interface enables data transfer from an external host over a parallel 8 bit bus to the
SoC. One of the potential applications is preprocessing of printer data by a processor in the
SoC before the data is sent to the print head.
Figure 89 shows a block diagram of the SPP interface.
Figure 89. SPP interface block diagram
DATA[7:0]
STRBn
INITn
AUTOFDn
SELINn
ACKn
SPP
INTERFACE
APB Salve
Interaface
Interrupt
BUSY
PERROR
FAULTn
SELECT
Each time a data is received from an external host, it is latched, the appropriate
acknowledgement sent to the host and an interrupt generated for the processor to transfer
Doc ID 022640 Rev 3
255/368
Legacy IEEE 1284 parallel port (SPP)
RM0319
this data to the print head or any buffer memory. It is also possible for the processor to
communicate to the external host if paper error or any other fault occurs.
20.4
Clocks
The timing diagram for one cycle of data transfer is shown in Figure 90. The acknowledge
signal ACKn goes low for 0.5µs (minimum). This timing is derived from an input clock (APB
clock) of 83 MHz. The busy signal goes back low only when the processor stores this
latched data and sends the appropriate control signal (see Control Register).
Figure 90. Data transfer timing diagram
DATA
STROBEn
BUSY
ACKn
SELINn
0.5us
256/368
Doc ID 022640 Rev 3
RM0319
21
Analog-to-digital converter (ADC)
Analog-to-digital converter (ADC)
This chapter focuses on ADC functionality and operation.
For technical details about the programmable registers related to the ADC, refer to the ADC
registers in the following companion document:
●
21.1
RM0321: SPEAr320S address map and registers
Overview
SPEAr320S includes an analog-to-digital converter (ADC), which is connected to the APB
bus.
21.2
Main features
●
Successive approximation conversion method
●
10 bit resolution
●
1 MSPS
●
8 analog input (AIN) channels, ranging from 0 to 2.5V
●
For each input, the number of samples to be collected for average calculation can be 1
(no average) or up to 128 as in steps of powers of 2 (2, 4, 8...).
●
INL ± 1 LSB, DNL ± 1 LSB
●
Programmable conversion speed, from a minimum conversion time of 1 µs
●
Normal or enhanced mode. In normal mode the conversion starts upon CPU request,
while in enhanced mode the ADC converts continuously the selected channels
inserting a selectable amount of time between two conversions.
●
DC internal reference voltage is 1.95 (Min), 2.0 (Typ), 2.05 (Max)
Note:
Positive and negative reference voltages can be supplied by dedicated pins to select
different range (Default 0 - 2.5V).
21.3
Functional description
Figure 91 shows the functional block diagram of the ADC.
Doc ID 022640 Rev 3
257/368
Analog-to-digital converter (ADC)
RM0319
Figure 91. ADC block diagram
ADC
Configuration Regisers
10 bit conversion data
APB Bus
258/368
8 Analog Inputs
Doc ID 022640 Rev 3
RM0319
21.3.1
Analog-to-digital converter (ADC)
Operation modes
Normal mode
As long as POWER DOWN bit in ADC_STATUS_REG register is set to logic ’0’, the ADC is
inactive (disabled) and the output latches contain the last conversion.
When the POWER DOWN bit is set by software, the ADC enters its functional mode after 50
µs, when a conversion can be then initiated by setting the ENABLE bit in
ADC_STATUS_REG register.
At first, the 10-bit conversion data field of the AVERAGE_REG register is reset to the value
10'b1000000000 and the acquisition from the selected analog input channel occurs. After
that, the conversion phase takes place. 13 clock cycles are required for one complete
conversion.
At the end of conversion, the CONVERSION READY bit in ADC_STATUS_REG is set, and
the conversion data reading can begin. When the reading finishes, two different scenarios
could occur:
21.3.2
●
POWER DOWN bit is set (1'b1): the ENABLE bit is kept to 1'b1 (conversion enabled),
and next conversion can takes place without waiting for the start up time (50 us).
●
POWER DOWN bit is cleared (1'b0): the ADC is switched-off and next conversion
requires again a start up time (after setting the ENABLE bit in the ADC_STATUS_REG
register).
Enhanced mode
In this mode (ENHANCED MODE bit = 1), it is possible to perform conversions on selected
channels in a continuous way. To start conversions it is necessary to configure the
SCAN_RATE register to set the number of APB Clock cycles between the start of two scan
conversions.
To read conversion results you need to read the CHx_DATA registers. CHx_DATA[17] is the
VALID_DATA bit. It is logic ‘1’ when the read data is valid. It is logic ‘0’ in the following cases:
●
ENHANCED MODE bit = 0
●
CHANNEL ENABLE of the related channel = 0
●
The controller is writing a result in it.
On channel 0 it is possible to select a request to DMA (DMA_EN bit = 1) when conversion is
finished. In this case at the end of conversion on this channel, the controller will perform a
single request to DMA. At the next conversion on channel 0, the controller will check for the
end of last DMA transfer continuing with a new conversion on this channel only if the first
one is finished. Otherwise, the scan will continue with the other enabled channels.
21.3.3
High-resolution mode
The resolution of the ADC analog cell is 10 bits, but resolution can be extended in high
resolution mode. High resolution mode is enabled by setting the HIGHRESOLUTION bit in
the ADC_CTRL_STATUS _REG register.
In high resolution mode, the ADC performs oversampling. The number of samples is
programmable via the NSAMPLES bits (bits 7:5) in the ADC_CTRL_STATUS _REG
register.
The sum of the converted results can be read from the AVERAGE register.
Doc ID 022640 Rev 3
259/368
Analog-to-digital converter (ADC)
RM0319
By reading the sum of the conversion results, software can use decimation or interpolation
averaging methods to obtain higher resolution (> 10-bits).
By oversampling 4 times, the resolution can be increased by 1 bit, by oversampling 16 times
resolution can be increased by 2 bits and so on. Instead of dividing the sum of the converted
results by NSAMPLES as in normal averaging, the sum of the samples read from the
AVERAGE register should be right shifted n bits, where n is the desired number of bits of
resolution.
In enhanced mode (ENM=1) and if High resolution mode is enabled
(HIGHRESOLUTION=1), the number of samples can be defined individually for each
channel in the CHx_CTRL registers and the sum of the converted results can be read from
the CHx_DATA registers.
260/368
Doc ID 022640 Rev 3
RM0319
22
Basic general purpose I/Os (basGPIO)
Basic general purpose I/Os (basGPIO)
This chapter focuses on GPIO functionality and operation.
For technical details about the programmable registers related to the GPIO, refer to the
GPIO registers in the following companion document:
●
22.1
RM0321: SPEAr320S address map and registers
Overview
The general purpose input/output block provides 6 programmable inputs or outputs. Each
input/output can be controlled through an APB interface.
22.2
22.3
Main features
●
Six individually programmable input/output pins (default to input at reset)
●
Two additional GPIOs dedicated for SPI chip select
●
An APB slave acting as control interface
●
Programmable interrupt generation capability on any number of pins.
●
Bit masking in both read and write operation through address lines.
Functional description
Figure 92 shows the block diagram of GPIO.
Figure 92. GPIO block diagram
Enable lines
Input/
Output
Multiplexor
Output Data
Input Data
AMBA APB Interface
Interrupt Detection
logic
22.3.1
Pins
The GPIO directly interfaces with the signals summarized in Table 74: GPIO signal
interface. A functional diagram of these signal interfaces is given in Figure 93.
Doc ID 022640 Rev 3
261/368
Basic general purpose I/Os (basGPIO)
Table 74.
RM0319
GPIO signal interface
Group
External
(to chip pads)
Signal name
Direction
Size
(bit)
Description
nGPEN
Output
6
Output pad enable signal (active low)
GPOUT
Output
6
Output pad data signal driver
GPIN
Input
6
Input data from chip pad
GPIOMIS
Output
6
Masked interrupt signals, to interrupt
controller
GPIOINTR
Output
1
Combined OR version of GPIOMIS, to
interrupt controller
Interrupt
(on-chip)
AMBA APB Bus
Figure 93. GPIO signal interfaces
22.3.2
SPI CS Selector
APB Slave
GPIO
External(To Chip PAD)
Interrupt (On chip)
Interrupt detection logic
The interrupt detection logic of the GPIO block which allows to generate maskprogrammable interrupts based on either the signal level or the transitional value (edge) of
any of the basGPIO lines.
As depicted in Figure 92, this block interfaces with both the interrupt control registers hosted
by the APB slave and the input signals from pad (GPIN[5:0]). Depending on registers
configuration (see Section 22.4.2: Control interrupt generation for details) and actual input
signals features, a GPIO interrupt signal (GPIOINTR) is generated by the Interrupt
Detection Logic block as the OR combination of all the GPIO masked interrupt lines.
The resulting combined GPIOINTR signal can be then used to indicate to an external
interrupt controller that an interrupt occurred in one or more of the basGPIO lines. Additional
output signals (GPIOMIS[5:0]) are also generated by the interrupt detection logic block,
reflecting the status of each single masked interrupt lines. Provisional of individual outputs
as well as combined interrupt output allows to use either a global interrupt service routine
(trapping the GPIOINTR signal) or modular device drivers (looking at GPIOMIS[5:0]) to
handle GPIO interrupts.
262/368
Doc ID 022640 Rev 3
RM0319
22.3.3
Basic general purpose I/Os (basGPIO)
Mode control
Each GPIO line can be controlled by software.
The data direction is controlled by the data direction register (GPIODIR). Data writing and
reading operations are detailed in the next section.
22.4
Programming examples
22.4.1
How to read from and write to input/output lines
To allow independent software drivers to set their GPIO bits without affecting any other pins
in a single write operation, the APB address bus (PADDR) is used as a mask on read/write
operations.
The GPIO data register (GPIODATA) effectively covers 64 locations in the address space,
that is the same register appears at 64 different locations (with offset ranging from 0x00 to
0xFC with respect to base address). To access these locations, the 6 bit subset of the APB
address bus is used, according to the following rules:
22.4.2
●
During a write operation to GPIODATA register: a data bit of the GPIODATA register is
altered only if the associated address bit in PADDR[9:2] is set, otherwise it is left
unchanged.
●
During a read operation from GPIODATA register: a data bit of the GPIODATA register
is read only if the associated address bit in PADDR[9:2] is set, otherwise a zero is
returned regardless of its state.
Control interrupt generation
The GPIO interrupt generation capability is fully controlled by a set of seven registers
located in the APB slave interface.
These registers allow to select, for each single pin, the interrupt source (the edge or the
level of signal on that pin), the event (rising/falling edge or high/low signal level) which
triggers the interrupt and any interrupt masking.
Figure 94 shows how the three main interrupt control registers (namely GPIOIS, GPIOIBE
and GPIOIEV) should be set to select an interrupt source event for a single pin.
Doc ID 022640 Rev 3
263/368
Basic general purpose I/Os (basGPIO)
RM0319
Figure 94. GPIO interrupt triggering logic
Start
GPIOIE
Masked?
No
Interrupt
masked
Yes
GPIOIS
Edge/level?
No
GPIOIBE
both edges?
Yes
Yes
No
Yes
Note:
264/368
GPIOIEV
Rising/falling?
No
Yes
GPIOIEV
HIGH/LOW?
No
1
For level detection case, it is assumed that an external source holds the level constant for
the interrupt to be recognized by the processor.
2
Interrupt control registers must be programmed when corresponding interrupts are not
enabled, in order to avoid spurious interrupts to be generated.
Doc ID 022640 Rev 3
RM0319
23
Extended general purpose I/O (PL_GPIO)
Extended general purpose I/O (PL_GPIO)
This chapter focuses on PL_GPIO functionality and operation.
For technical details about the programmable registers related to the PL_GPIO, refer to the
RAS registers in the following companion document:
●
23.1
RM0321: SPEAr320S address map and registers
Overview
Extended general purpose I/Os are software programmable input/output pins through an
AHB slave interface. They configure all PL_GPIO and PL_CLK signals of SPEAr320S,
writing data to external interfaces or receiving data/interrupts from external interfaces.
Interrupt trigger polarity is programmable as rising or falling edge.
Figure 95.GPIO block diagram
GPIO IN
GPIO OUT
AHB
Interface
GPIO Block
GPIO EN
23.2
Configuration
To use PL_GPIO pins for general purpose I/O, the pins must be configured as follows:
1.
Check that RAS function is selected for the corresponding set of PL_GPIO pins in the
RAS_Select_Register
2.
Configure the corresponding bit for the PL_GPIO pin in the GPIO select register x.
3.
Enable the PLGPIO pin in input or output mode by programming the corresponding bit
in the GPIO enable register.
In input mode:
The value of the pin can be read from the GPIO input register
In output mode:
Data can be output on the pin by writing to the GPIO output register.
Doc ID 022640 Rev 3
265/368
Extended general purpose I/O (PL_GPIO)
RM0319
The GPIO functionality is independent of any of the functional modes listed in Section 32.2:
I/O multiplexing scheme configuration (whether legacy or extended).
When a pin is enabled as GPIO (through GPIO_SELECTx register), it can be used it as
GPIO_out, GPIO_in or interrupt with programmable edge detection.
●
The status of each of the edge-programmable GPIO interrupts can be read from the
GPIO_IRQx registers. The combined status is indicated by NGPIO_INTR (bit 6 of the
IrqStatus_Reg.
●
For backward compatibility with legacy designs, the interrupt status of each of the
“rising-edge only” GPIO interrupts can be read from the GPIO_MASKED_INTx
registers. Their combined status is indicated by the GPIO_INTR (bit 0 of the
IrqStatus_Reg).
In both of the above cases, GPIO interrupts are available when the I/O is selected as GPIO,
independent of any functional mode. The GPIO_IRQ_MASKx registers mask GPIO
interrupts in all modes.
When using Extended mode, you can also configure some pins as GPIO input by
programming the RAS_iosel_reg registers. This is possible in those cases where the pin
multiplexing is not fully used for other signals.
23.2.1
PL_GPIO external interrupts
In GPIO input mode, interrupts can be enabled by clearing the corresponding mask bit in the
GPIO interrupt mask registers.
Interrupt polarity can be selected as rising edge or falling edge in the GPIO edge polarity
registers.
When a interrupt event occurs on one of the PL_GPIO pins an interrupt status flag is set in
the corresponding bit of the GPIO interrupt status registers.
All the GPIO interrupts are ORed into a single interrupt request (IRQ30) sent to the vectored
interrupt controller (VIC).
The interrupt flags can be cleared by writing 0 in the corresponding bit of the GPIO interrupt
status register
Example:
To enable GPIO_43 for edge interrupt detection, the following registers need to be
programmed:
1. Enable RAS_GPIOs (select RAS functionality)
RAS_Select_REG &= 0xFFFFFFFE;
2. Enable pin as GPIO
GPIO_SELECT1 |= 0x800;
3. Enable GPIO as input
GPIO_EN1 |= 0x800;
4. Edge programming for interrupts
GPIO_IRQ_EDGE1 |= 0x800;
-> rising edge detection
GPIO_IRQ_EDGE1 &= 0xFFFFF7FF;
266/368
-> falling edge detection
Doc ID 022640 Rev 3
RM0319
Extended general purpose I/O (PL_GPIO)
5. Unmask the interrupt
GPIO_IRQ_MASK1 &= 0xFFFFF7FF;
Doc ID 022640 Rev 3
267/368
LCD display controller (CLCD)
24
RM0319
LCD display controller (CLCD)
This chapter focuses on CLCD functionality and operation.
For technical details about the programmable registers related to the CLCD, refer to the
CLCD registers in the following companion document:
●
24.1
RM0321: SPEAr320S address map and registers
Overview
SPEAr320S features a color liquid crystal display controller (CLCD) that provides all the
necessary control signals to interface directly to a variety of color and monochrome LCD
panels.
24.2
268/368
Main features
●
Compliance to the AMBA specification (Rev 2.0) onwards for easy integration into SoC
implementation
●
Dual 16-deep programmable 32-bit wide FIFOs for buffering incoming display data
●
Supports single and dual panel mono super twisted nematic (STN) displays with 4- or
8-bit interfaces
●
Supports single and dual panel color and monochrome STN displays
●
Supports thin film transistor (TFT) color displays
●
Resolution programmable up to 1024 x 768
●
15 gray-level mono, 3375 color STN, and 32K color TFT support
●
1, 2, or 4 bits-per-pixel (bpp) palettized displays for mono STN
●
1, 2, 4 or 8 bpp palettized color displays for color STN and TFT
●
16 bits-per-pixel (bpp) true-color non-palettized, for color STN and TFT
●
24 bpp true-color non-palettized, for color TFT
●
Programmable timing for different display panels
●
256-entry, 16-bit palette RAM, arranged as a 128 x 32-bit RAM physically frame, line
and pixel clock signals
●
AC bias signal for STN and data enable signal for TFT panels
●
Patented gray scale algorithm
●
Supports little endian, big endian and WindowsCE data formats
Doc ID 022640 Rev 3
RM0319
LCD display controller (CLCD)
Programmable parameters:
●
Horizontal front and back porch
●
Horizontal synchronization pulse width
●
Number of pixels per line
●
Vertical front and back porch
●
Vertical synchronization pulse width
●
Number of lines per panel
●
Number of panel clocks per line.
●
Signal polarity, active HIGH or LOW
●
AC panel bias
●
Panel clock frequency
●
Bits per pixel (Bpp)
●
Display type, STN mono/color or TFT
Doc ID 022640 Rev 3
269/368
LCD display controller (CLCD)
RM0319
●
STN 4- or 8-bit interface mode
●
STN dual or single panel mode
●
Little-endian, big-endian, or WinCE mode
●
Interrupt generation event
LCD Panel resolutions programmed to values:
●
320x200, 320x240
●
640x200, 640x240, 640x480
●
800x600
●
1024x768
Types of LCD panel supported:
●
Active matrix TFT panels with up to 24 bit bus interface
●
Single-panel monochrome STN panels (4 bit and 8 bit bus interface)
●
Dual-panel monochrome STN panels (4 bit and 8 bit bus interface per panel)
●
Single-panel color STN panels, 8 bit bus interface
●
Dual-panel color STN panels, 8 bit bus interface per panel
Number of colors supported for TFT panels:
●
1 bpp, palettized, 2 colors selected from available colors.
●
2 bpp, palettized, 4 colors selected from available colors.
●
4 bpp, palettized, 16 colors selected from available colors.
●
8 bpp, palettized, 256 colors selected from available colors
●
16 bpp, direct 5:5:5 RGB, with one bpp not normally being used. This pixel is still
output, and can be used as a bright bit to connect to the least significant bit (LSB) of R,
G and B components of a 6:6:6 TFT panel.
●
24 bpp, direct 8:8:8 RGB, providing over 16 million colors.
●
Each 16-bit palette entry is composed of five bpp (RGB) plus a common intensity bit.
This gives better memory utilization and performance compared to a full six bpp
structure. The total amount of colors supported can be doubled from 32 K to 64 K if the
intensity bit is used and applied to all three color components simultaneously. Refer to
Section 24.3 for more information on signals.
Number of colors supported for color STN panels are:
270/368
●
1 bpp, palettized, 2 colors selected from 3375
●
2 bpp, palettized, 4 colors selected from 3375
●
4 bpp, palettized, 16 colors selected from 3375
●
8 bpp, palettized, 256 colors selected from 3375
●
16 bpp, direct 4:4:4 RGB, with 4 bpp not being used
Doc ID 022640 Rev 3
RM0319
LCD display controller (CLCD)
Number of colors supported for mono STN panels are:
●
1 bpp, palettized, 2 gray scales selected from 15
●
2 bpp, palettized, 4 gray scales selected from 15
●
4 bpp, palettized, 16 gray scales selected from 15
You can program greater than four bpp for mono panels but using these modes does not
make sense because the maximum number of gray scales supported on the display is 15.
24.3
Pins
The CLCD directly interfaces with the signals summarized in Table 75.
Table 75.
CLCD signal interface
Signal name
Direction
Size
(bit)
Description
CLAC
Output
1
STN AC bias drive or TFT data enable
output
CLCP
Output
1
LCD panel clock
CLD[23:0]
Output
24
LCD panel data
CLFP
Output
1
Frame pulse (STN)/vertical synchronization
pulse (TFT)
CLLE
Output
1
Line end signal
CLLP
Output
1
Line synchronization pulse (STN)/horizontal
synchronization pulse (TFT)
CLPOWER
Output
1
LCD panel power enable
Control signal
CLCD_INTR
Output
1
Combined OR version CLCD interrupt
requests, to interrupt controller.
AHB slave
-
Input/Output -
See AMBA specification.
AHB master
-
Input/Output -
See AMBA specification.
Group
External
(to chip pads)
The CLLP, CLAC, CLFP, CLCP and CLLE signals are common, but the CLD[23:0] bus has
eight modes of operation:
●
TFT 24-bit interface
●
TFT 18-bit interface
●
color STN single panel
●
color STN dual panel
●
4-bit mono STN single panel
●
4-bit mono STN dual panel
●
8-bit mono STN single panel
●
8-bit mono STN dual panel
Doc ID 022640 Rev 3
271/368
LCD display controller (CLCD)
RM0319
Table 76 shows which CLD[23:0] pins are used to supply the pixel data to the STN panel for
each of the above modes of operation.
The following acronyms are used:
●
CUSTN = Color upper panel STN, dual and/or single panel
●
CLSTN = Color lower panel STN, single
●
MUSTN = Mono upper panel STN, dual and/or single panel
●
MLSTN = Mono lower panel STN, single.
Table 76.
External
pin
272/368
LCD STN panel signal multiplexing
Color STN
single panel
Color STN
dual panel
4-bit mono
STN single
panel
4-bit mono
STN dual
panel
8-bit mono
STN single
panel
8-bit mono
STN dual
panel
CLD23
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
CLD22
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
CLD21
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
CLD20
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
CLD19
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
CLD18
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
CLD17
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
CLD16
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
CLD15
Reserved
CLSTN[0]
Reserved
Reserved
Reserved
MLSTN[0]
CLD14
Reserved
CLSTN[1]
Reserved
Reserved
Reserved
MLSTN[1]
CLD13
Reserved
CLSTN[2]
Reserved
Reserved
Reserved
MLSTN[2]
CLD12
Reserved
CLSTN[3]
Reserved
Reserved
Reserved
MLSTN[3]
CLD11
Reserved
CLSTN[4]
Reserved
MLSTN[0]
Reserved
MLSTN[4]
CLD10
Reserved
CLSTN[5]
Reserved
MLSTN[1]
Reserved
MLSTN[5]
CLD9
Reserved
CLSTN[6]
Reserved
MLSTN[2]
Reserved
MLSTN[6]
CLD8
Reserved
CLSTN[7]
Reserved
MLSTN[3]
Reserved
MLSTN[7]
CLD7
CUSTN[0]
CUSTN[0]
Reserved
Reserved
MUSTN[0]
MUSTN[0]
CLD6
CUSTN[1]
CUSTN[1]
Reserved
Reserved
MUSTN[1]
MUSTN[1]
CLD5
CUSTN[2]
CUSTN[2]
Reserved
Reserved
MUSTN[2]
MUSTN[2]
CLD4
CUSTN[3]
CUSTN[3]
Reserved
Reserved
MUSTN[3]
MUSTN[3]
CLD3
CUSTN[4]
CUSTN[4]
MUSTN[0]
MUSTN[0]
MUSTN[4]
MUSTN[4]
CLD2
CUSTN[5]
CUSTN[5]
MUSTN[1]
MUSTN[1]
MUSTN[5]
MUSTN[5]
CLD1
CUSTN[6]
CUSTN[6]
MUSTN[2]
MUSTN[2]
MUSTN[6]
MUSTN[6]
CLD0
CUSTN[7]
CUSTN[7]
MUSTN[3]
MUSTN[3]
MUSTN[7]
MUSTN[7]
Doc ID 022640 Rev 3
RM0319
LCD display controller (CLCD)
Table 77 shows which CLD[23:0] pins are used to supply the pixel data to the TFT panel for
each of the above modes of operation.
Table 77.
LCD TFT panel signal multiplexing
External pin
TFT 24 bit
TFT 18 bit
CLD23
BLUE[7]
Reserved
CLD22
BLUE[6]
Reserved
CLD21
BLUE[5]
Reserved
CLD20
BLUE[4]
Reserved
CLD19
BLUE[3]
Reserved
CLD18
BLUE[2]
Reserved
CLD17
BLUE[1]
BLUE[4]
CLD16
BLUE[0]
BLUE[3]
CLD15
GREEN[7]
BLUE[2]
CLD14
GREEN[6]
BLUE[1]
CLD13
GREEN[5]
BLUE[0]
CLD12
GREEN[4]
Intensity Bit
CLD11
GREEN[3]
GREEN[4]
CLD10
GREEN[2]
GREEN[3]
CLD9
GREEN[1]
GREEN[2]
CLD8
GREEN[0]
GREEN[1]
CLD7
RED[7]
GREEN[0]
CLD6
RED[6]
Intensity Bit
CLD5
RED[5]
RED[4]
CLD4
RED[4]
RED[3]
CLD3
RED[3]
RED[2]
CLD2
RED[2]
RED[1]
CLD1
RED[1]
RED[0]
CLD0
RED[0]
Intensity Bit
Doc ID 022640 Rev 3
273/368
LCD display controller (CLCD)
24.4
RM0319
Functional description
Figure 96 shows the block diagram of CLCD.
Figure 96. CLCD block diagram
Panel
Clock
generator
LCD
panel
clock
Timing
Controller
LCD
panel
control
Control
And
Status
Register
AHB
Slave
Interfac
e
AHB
BUS
Upper
Panel
DMA FIFO
AHB
Master
Interface
Input
FIFO
Control
Upper
Panel
Formatter
Pixel
Serializer
Palette
(128x32)
Gray
Scaler
Lower
Panel
Formatter
Lower
Panel
DMA FIFO
Upper
Panel
Output FIFO
LCD
STN/ panel
TFT
data
data
select
Lower
Panel
Output FIFO
TFT
FIFO Underflow
AHB
errors
24.4.1
Interrupt
generation
Interrupts
AHB slave interface
The AMBA AHB slave interface connects the CLCD to the AMBA AHB bus and provides
CPU accesses to the registers and palette RAM. For more information on AMBA AHB slave
interfaces, refer to the AMBA specification (Rev 2.0).
The following features are supported by the CLCD AMBA AHB slave interface:
24.4.2
●
Standard write and read AMBA AHB accesses
●
INCR4, INCR8, and undefined length WORD bursts only
●
OKAY response only.
AHB master interface
The AMBA AHB master interface transfers display data from a memory to the CLCD DMA
FIFOs.
The inherent AMBA AHB master interface state machine performs the following functions:
274/368
●
Loads the upper panel base address into the AMBA AHB address incrementor on
recognition of a new frame.
●
Monitors both the upper and lower DMA FIFO levels and asserts HBUSREQM to
request display data from memory, filling them to above the programmed water mark.
Doc ID 022640 Rev 3
RM0319
LCD display controller (CLCD)
HBUSREQM is re-asserted when there are at least four locations available within either
FIFO (dual panel mode).
24.4.3
●
Checks for 1KB boundaries during fixed-length bursts and appropriately adjusts the
address in such occurrences.
●
Generates the address sequences for fixed-length and undefined bursts.
●
Controls the handshaking between the memory and DMA FIFOs. It inserts busy cycles
if the FIFOs have not completed their synchronization and updating sequence.
●
Fills up the DMA FIFOs, in dual panel mode, in an alternating fashion from a single
HBUSREQM request and subsequent HGRANTM.
●
Asserts the CLCDMBEINTR interrupt if an error occurs during an active burst.
●
Responds to retry commands by restarting the failed access.
Dual DMA FIFOs and associated control logic
The pixel data accessed from memory is buffered by two DMA FIFOs that can be
independently controlled to cover single and dual-panel LCD types. Each FIFO is 16 words
deep by 32 bits wide and can be cascaded to form an effective 32-word deep FIFO in singlepanel mode. The input ports of the FIFOs are connected to the AMBA AHB interface and the
output port feeds the pixel serializer.
Synchronization logic is used to transfer the pixel data from the AMBA AHB HCLK domain to
the CLCDCLK clock domain, the DMA FIFOs being clocked by the former.
The water level marks within each FIFO are set so that each FIFO requests data when at
least four locations become available.
An interrupt signal is asserted if an attempt is made to read either of the two DMA FIFOs
when they are empty, in other words an underflow condition has occurred.
24.4.4
Pixel serializer
This block reads the 32-bit wide LCD data from output port of the DMA FIFO and extracts
24, 16, 8, 4, 2, or 1 bpp data, depending on the current mode of operation. The CLCD
supports big-endian, little-endian, and WinCE data formats. In dual panel mode, data is
alternately read from the upper and lower DMA FIFOs. Depending upon the mode of
operation, you can use the extracted data to point to a color/gray scale value in the palette
RAM or it can be a true color value that you can apply directly to an LCD panel input.
The following tables show the structure of the data in each DMA FIFO word corresponding
to the endianness and bpp combinations. For each of the three supported data formats, the
required data for each panel display pixel must be extracted from the data word.
The nomenclature used in the following tables is:
●
Little endian byte, little endian pixel (LBLP) order (Table 78 and Table 79)
●
Big endian byte, big endian pixel (BBBP) order (Table 80 and Table 81)
●
Little endian byte, big endian pixel (LBBP) order (this is the WinCE format, for powering
up and down sequences) (Table 82 and Table 83)
Doc ID 022640 Rev 3
275/368
LCD display controller (CLCD)
Table 78.
bpp
1
2
4
8
16
24
1
2
4
8
16
24
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
p31 p30 p29 p28 p27 p26 p25 p24 p23 p22 p21 p20 p19 p18 p17 p16
p15
p14
p13
p12
p11
p10
p9
p8
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
p7
p6
p5
p4
3
2
1
0
3
2
1
0
3
2
1
0
3
2
1
0
p3
p2
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
p1
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
p0
23
22
21
20
19
18
17
16
1
2
4
8
16
24
15
14
13
12
11
10
09
08
p15 p14 p13 p12 p11 p10 p9
p8
0
0
0
0
0
0
0
0
p7
p6
p5
p4
1
0
1
0
1
0
1
0
p3
p2
3
2
1
0
3
2
1
0
p1
7
6
5
4
3
2
1
0
1
2
4
276/368
07
p7
0
06
p6
0
p3
1
0
05
p5
0
04
p4
0
p2
1
0
03
p3
0
02
p2
0
p1
1
0
p1
3
2
01
p1
0
00
p0
0
p0
1
0
p0
1
0
3
2
1
0
p0
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
p0
15
14
13
12
11
10
9
8
p0
15
14
13
12
11
10
9
8
BBBP, DMA FIFO output bit 31 to bit 16
DMA FIFO Output Bits
31
p0
30
p1
p0
1
0
29
p2
28
p3
p1
1
0
27
p4
26
p5
p2
1
0
p0
3
2
25
p6
24
p7
p3
1
0
23
p8
22
p9
p4
1
0
7
21
20
19
18
17
16
p10 p11 p12 p13 p14 p15
p5
p6
p7
1
0
1
0
1
0
p2
p3
2
1
0
3
2
1
0
p1
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
23
22
21
20
19
18
17
16
p1
1
0
3
2
1
0
3
2
1
0
3
p0
7
6
5
4
p0
15
14
13
12
11
10
9
8
p0
-
Table 81.
bpp
LBLP, DMA FIFO output bit 15 to bit 0
DMA FIFO Output Bits
Table 80.
bpp
LBLP, DMA FIFO output bit 31 to bit 16
DMA FIFO Output Bits
Table 79.
bpp
RM0319
-
-
-
-
-
-
-
BBBP, DMA FIFO output bit15 to bit 0
DMA FIFO Output Bits
15
14
13
12
11
10
09
08
07
06
05
04
03
02
01
00
p16 p17 p18 p19 p20 p21 p22 p23 p24 p25 p26 p27 p28 p29 p30 31
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
p8
p9
p10
p11
p12
p13
p14
p15
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
p4
p5
p6
p7
3
2
1
0
3
2
1
0
3
2
1
0
3
2
1
0
Doc ID 022640 Rev 3
RM0319
LCD display controller (CLCD)
Table 81.
bpp
8
16
24
DMA FIFO Output Bits
15
14
13
7
6
5
1
2
4
8
16
24
15
1
2
4
8
16
24
11
p2
4
3
10
09
08
2
1
0
07
06
05
04
7
6
5
03
p3
4
3
02
01
00
2
1
0
14
13
12
11
10
9
7
6
5
4
7
6
5
4
8
3
2
1
0
3
2
1
0
p0
15
14
13
12
11
10
9
8
LBBP, DMA FIFO output bit 31 to bit 16
DMA FIFO Output Bits
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
p24 p25 p26 p27 p28 p29 p30 p31 p16 p17 p18 p19 p20 p21 p22 p23
p12
p13
p14
p15
p8
p9
p10
p11
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
p6
p7
p4
p5
3
2
1
0
3
2
1
0
3
2
1
0
3
2
1
0
p3
p2
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
p1
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
p0
23
22
21
20
19
18
17
16
Table 83.
bpp
12
p1
Table 82.
bpp
BBBP, DMA FIFO output bit15 to bit 0 (continued)
LBBP, DMA FIFO output bit15 to bit 0
DMA FIFO Output Bits
15
p8
0
14
p9
0
p4
1
0
3
7
15
15
Table 84.
13
12
11
10
09
08
07
06
05
04
03
02
01
00
p10 p11 p12 p13 p14 p15 p0
p1
p2
p3
p4
p5
p6
p7
0
0
0
0
0
0
0
0
0
0
0
0
0
0
p5
p6
p7
p0
p1
p2
p3
1
0
1
0
1
0
1
0
1
0
1
0
1
0
p2
p3
p0
p1
2
1
0
3
2
1
0
3
2
1
0
3
2
1
0
p1
p0
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
p0
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
p0
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
RGB mode data format
DMA FIFO output bit
24-bit RGB
16-bit 1:5:5:5 RGB
16-bit 4:4:4 RGB
[31]
0
p1- Intensity bit
0
[30]
0
p1 - Blue4
0
[29]
0
p1 - Blue3
0
[28]
0
p1 - Blue2
0
[27]
0
p1 - Blue1
p1 - Blue3
[26]
0
p1 - Blue0
p1 - Blue2
[25]
0
p1 - Green4
p1 - Blue1
Doc ID 022640 Rev 3
277/368
LCD display controller (CLCD)
Table 84.
RM0319
RGB mode data format (continued)
DMA FIFO output bit
24.4.5
24-bit RGB
16-bit 1:5:5:5 RGB
16-bit 4:4:4 RGB
[24]
0
p1 - Green3
p1 - Blue0
[23]
p0 - Blue7
p1 - Green2
p1 - Green3
[22]
p0 - Blue6
p1 - Green1
p1 - Green2
[21]
p0 - Blue5
p1 - Green0
p1 - Green1
[20]
p0 - Blue4
p1 - Red4
p1 - Green0
[19]
p0 - Blue3
p1 - Red3
p1 - Red3
[18]
p0 - Blue2
p1 - Red2
p1 - Red2
[17]
p0 - Blue1
p1 - Red1
p1 - Red1
[16]
p0 - Blue0
p1 - Red0
p1 - Red0
[15]
p0 - Green7
p0- Intensity bit
0
[14]
p0 - Green6
p0 - Blue4
0
[13]
p0 - Green5
p0 - Blue3
0
[12]
p0 - Green4
p0 - Blue2
0
[11]
p0 - Green3
p0 - Blue1
p0 - Blue3
[10]
p0 - Green2
p0 - Blue0
p0 - Blue2
[09]
p0 - Green1
p0 - Green4
p0 - Blue1
[08]
p0 - Green0
p0 - Green3
p0 - Blue0
[07]
p0 - Red7
p0 - Green2
p0 - Green3
[06]
p0 - Red6
p0 - Green1
p0 - Green2
[05]
p0 - Red5
p0 - Green0
p0 - Green1
[04]
p0 - Red4
p0 - Red4
p0 - Green0
[03]
p0 - Red3
p0 - Red3
p0 - Red3
[02]
p0 - Red2
p0 - Red2
p0 - Red2
[01]
p0 - Red1
p0 - Red1
p0 - Red1
[00]
p0 - Red0
p0 - Red0
p0 - Red0
RAM palette
The RAM-based palette is a 256 x 16-bit dual-port RAM physically structured as
128 x 32 bit. This allows two entries to be written into the palette from a single word write
access. The least significant bit of the serialized pixel data is used to select between upper
and lower halves of the palette RAM. Which half is selected depends on the bytes ordering
mode. In little-endian mode, the LSB being set selects the upper half, but in big-endian, the
lower half of the palette is selected. WinCE byte ordering is little-endian, so the former case
applies.
Pixel data values can be written and verified through the AMBA AHB slave interface.
For information on the numbers of colors supported, refer to Section 24.2: Main features.
278/368
Doc ID 022640 Rev 3
RM0319
LCD display controller (CLCD)
The palette RAM is a dual port RAM with independent controls and addresses for each port.
Port1 is used as a read/write port and is connected to the AMBA AHB slave interface. The
palette entries can be written and verified through this port. Port2 is used as a read-only port
and is connected to the unpacker and gray scaler.
Table 85 shows the bit representation of each word in the palette.
Table 85.
Palette data storage
Bit
Name
Description
[31]
I
Intensity/unused
[30:26]
B[4:0]
Blue palette data
[25:21]
G[4:0]
Green palette data
[20:16]
R[4:0]
Red palette data
[15]
I
Intensity/unused
[14:10]
B[4:0]
Blue palette data
[09:05]
G[4:0]
Green palette data
[04:00]
R[4:0]
Red palette data
For mono STN mode only the red palette field bits [4:1] are used. However, in STN color
mode, the green and blue [4:1] are also used.
The red and blue pixel data can be swapped to support BGR data format using a control
register bit.
In 16 and 24 bpp TFT mode, the palette is bypassed and the output of the pixel serializer is
used as the TFT panel data.
24.4.6
Gray scaler
A patented gray scale algorithm drives mono and color STN panels. This provides 15 gray
scales for mono displays. In the case of STN color displays, the three color components
(red, green, and blue) are gray scaled simultaneously which results in 3 375 (15x15x15)
colors being available. The gray scaler transforms each 4 bit gray value into a sequence of
activity-per-pixel over several frames, relying to some degree on the display characteristics,
to give the representation of gray scales and color.
24.4.7
Upper and lower panel formatters
Each formatter consists of three 3-bit (red, green, and blue) shift left registers. Red, green
and blue pixel data bit values from the gray scaler are concurrently shifted into the
respective registers. When enough data is available, a byte is constructed by multiplexing
the registered data to the correct bit position to satisfy the RGB data pattern of LCD panel.
The byte is transferred to the three-byte FIFO which has enough space to store eight color
pixels.
Doc ID 022640 Rev 3
279/368
LCD display controller (CLCD)
24.4.8
RM0319
Panel clock generator
The output of the panel clock generator block is the panel clock. This is a divided down
version of CLCDCLK. It can be programmed in the range CLCDCLK/2 to CLCDCLK/33 to
match the bpp data rate of the LCD panel.
24.4.9
Timing controller
The primary function of the timing controller block is to generate the horizontal and vertical
timing panel signals. It also provides panel bias/enable signal. These timings are all register
programmable through the AMBA AHB slave interface.
24.4.10
Interrupt generation
The CLCD provides four individually maskable interrupts and a single combined interrupt.
The single combined interrupt is asserted if any of the combined interrupts are asserted and
unmasked. The Interrupts are generated for the following events:
●
Master bus error
●
Vertical compare
●
LCD next base address update
●
FIFO underflow
See also: Section 24.6: Interrupts.
Master bus error interrupt
The master bus error interrupt is asserted when an ERROR response is received by the
master interface during a transaction with a slave. When such an error is encountered, the
master interface enters an error state and remains in this state until clearance of the error
has been signaled to it.
Vertical compare interrupt
The vertical compare interrupt asserts when one of four vertical display regions, selected
using the LCD Control Register, is reached.
●
vertical synchronization
●
back porch
●
active video
●
front porch
LCD Next base address update interrupt
The LCD next base address update interrupt asserts when either the LCDUPBASE or
LCDLPBASE values have been transferred to the LCDUPCURR or LCDLPCURR
incrementers respectively. This signals to the system that it is safe to update the
LCDUPBASE or the LCDLPBASE Registers with new frame base addresses if required.
FIFO underflow interrupt
The FIFO underflow interrupt asserts when internal data is requested from an empty DMA
FIFO. Internally, individual upper and lower panel DMA FIFO underflow interrupt signals are
generated and CLCDFUFINTR is the single combined version of these.
280/368
Doc ID 022640 Rev 3
RM0319
24.4.11
LCD display controller (CLCD)
Bus architecture
The CLCD incorporates a master and a slave interface.
The master interface is directly connected to a memory controller with an AMBA AHB slave
interface, while the slave interface is connected to the AMBA AHB bus.
AMBA AHB supports a wide range of on-chip bus sizes, from eight bits up to 1 024 bits. The
CLCD master and slave interfaces are implemented as 32 bit data bus devices only.
24.5
Clocks
The CLCDCLK for the CLCD IP can be input from 2 sources. LCD Timing Register2 selects
between HCLK and 48MHz clock.
Figure 97. CLCD clock muxing scheme
CLCD Controller
AHB Slave only Interface bus for
Controller programming
CLCDCLKSEL
Register Block
DMA FIFO
AHB Master only
Interface bus for DMA
LCD Panel
System Frame
Buffer Memory
LCD Control
HCLK
48 MHz
24.6
Palete RAM
CLCDCLK
Interrupts
There are five interrupts generated by the CLCD. The following are individual maskable
active HIGH interrupts:
●
CLCDMBEINTR
●
CLCDVCOMPINTR
●
CLCDLNBUINTR
●
CLCDFUFINTR
The output is a single combined interrupt: CLCDINTR. Each of the four individual maskable
interrupts is enabled or disabled by changing the mask bits in the LCDIMSC Register. The
status of the individual interrupt sources can be read from the LCDRIS Register.
Doc ID 022640 Rev 3
281/368
LCD display controller (CLCD)
24.6.1
RM0319
CLCDMBEINTR
The master bus error interrupt is asserted when an ERROR response is received by the
master interface during a transaction with a slave. When such an error is encountered, the
master interface enters an error state and remains in this state until clearance of the error
has been signalled to it. On completion of the respective interrupt service routine, the
master bus error interrupt can be cleared by writing a logic ‘1’ to the MBERROR bit within
the LCDICR Register. This action releases the master interface from its ERROR state to the
start of FRAME state, enabling a fresh frame of data display to be initiated.
24.6.2
LCDVCOMPINTR
The vertical compare interrupt is asserted when one of four vertical display regions,
selected using the Control Register, is reached. The interrupt can occur at the start of:
●
vertical synchronization
●
back porch
●
active video
●
front porch
It is possible to clear the interrupt by writing a logic ‘1’ to the VComp bit in the LCDICR
Register.
24.6.3
CLCDLNBUINTR
The LCD next base address update interrupt is asserted when either the LCDUPBASE or
the LCDLPBASE values are transferred to the LCDUPCURR or LCDLPCURR incrementors
respectively. This signals to the system that it is safe to update the LCDUPBASE or the
LCDLPBASE Registers with new frame base addresses if required.
It is possible to clear the interrupt by writing a logic ‘1’ to the LNBU bit in the LCDICR
register.
24.6.4
CLCDFUFINTR
The FIFO underflow interrupt is asserted when internal data is requested from an empty
DMA FIFO. Internally, individual upper and lower panel DMA FIFO underflow interrupt
signals are generated and CLCDFUFINTR is the single combined version of these ones.
It is possible to clear the interrupt by writing a logic ‘1’ to the FUF bit in the LCDICR register.
282/368
Doc ID 022640 Rev 3
RM0319
24.7
LCD display controller (CLCD)
Programming examples
LCD powering up and down
The CLCD requires the following power up sequence to be performed:
●
●
Vdd is simultaneously applied to the SoC that contains the CLCD peripheral and panel
display driver logic. The following signals are held LOW:
–
CLLP
–
CLCP
–
CLFP
–
CLAC
–
CLD[23:0]
–
CLLE
When Vdd is stabilized, a logic ‘1’ is written to the LcdEn bit in the LCDControl
Register. This enables the following signals into their active states:
–
CLLP
–
CLCP
–
CLFP
–
CLAC
–
CLLE
The CLD[23:0] signals remain low.
●
When the signals in step 2 have stabilized, where appropriate, the contrast voltage Vee
(not controlled or supplied by the CLCD) is then applied.
●
If required, you can use a software timer routine to provide the minimum display
specific delay time between application of the control signals and power to the panel
display. On completion of the software timer routine, power is applied to the panel by
writing a logic ‘1’ to the LcdPwr bit in the LcdControl Register that, in turn, sets the
CLPOWER signal HIGH and enables the CLD[23:0] signals into their active states.
Normally, CLPOWER is used to gate the power to the LCD panel.
The power-down sequence is the reverse of the above four stages and you must follow it
strictly, this time, writing the respective register bits with logic ‘0’.
The power up and power down sequences are shown in Figure 98: Powering up and down
sequences
Doc ID 022640 Rev 3
283/368
LCD display controller (CLCD)
RM0319
Figure 98. Powering up and down sequences
LCD On
Sequence
Minimum 0 ms
VDD
Min 0 ms
LCD Off Sequence
Minimum 0 ms
Min 0 ms
CLLP,CLCP,CL
FP,CLAC,CLLE
VEE
CLPOWER,
CLD[23:0]
284/368
Mn(display
specific)mSec
(Provided through SW)
Doc ID 022640 Rev 3
Mn(display
specific)mSec
(Provided through SW)
RM0319
25
Touchscreen interface (TOUCHSCREEN)
Touchscreen interface (TOUCHSCREEN)
This chapter describes the features and provides programming information on touchscreen
the block.
For technical details about the programmable registers related to the touchscreen, refer to
the RAS configuration (RASCFG) registers in the following companion document:
●
25.1
RM0321: SPEAr320S address map and registers
Overview
The touchscreen IP provides a toggling signal (TOUCHSCREEN_X) connected to the
touchscreen panel present outside SPEAr.
Figure 99. Top level diagram
TouchscreenIP
IP
Touchscreen
OUT_X
TOUCHSCREEN_X
Touchscreen
Touchscreen
Panel
Panel
During the end of high period (of TOUCHSCREEN_X signal), software can read one
coordinate and at the end of low period, the other coordinate can be read directly from the
ADC.
Figure 100. Waveform
TOUCHSCREEN_X
25.2
duration
duration
Programming examples
The registers used for the operation of the touchscreen IP are:
●
Touchscreen_duration, which stores the value (duration) for which TOUCHSCREEN_X
should remain high or should remain low. The value present in this register should be
expressed in HCLK cycles.
●
control_reg (Control register). To start the toggling of TOUCHSCREEN_X signal, bit7
should be set to '1'.
To enable the toggling operation:
Doc ID 022640 Rev 3
285/368
Touchscreen interface (TOUCHSCREEN)
286/368
RM0319
1.
Write the Ras_select register (address: 0xB300000C) to enable RAS outputs.
2.
Write the touchscreen duration in Touchscreen_duration register (address:
0xB3000014). This value is the number of HCLK cycles. The out port touchscreen_X
(gpio_36) will toggle according to clock cycles.
3.
Write '1' in the touchscreen enable bit (Bit 7) in the control_reg (address:0xB3000010)
to enable the toggling operation.
Doc ID 022640 Rev 3
RM0319
26
JPEG codec accelerator (JPGC)
JPEG codec accelerator (JPGC)
This chapter focuses on JPEG functionality and operation.
For technical details about the programmable registers related to the JPEG, refer to the
JPEG registers in the following companion document:
●
26.1
RM0321: SPEAr320S address map and registers
Overview
The JPEG Codec present in SPEAr320S is built around the existing JPEG ECS CODEC
and extends its functionality by providing additional support for JPEG header parsing and
generation. The encoding process compresses 8x8 pixel blocks (data units) into either a
complete JPEG encoded output stream or only ECS data depending on whether the header
processing functionality of the core is enabled. The decoding process can either decode a
complete JPEG encoded data stream or an input data stream with only ECSs. In either
case, the core decodes the ECS data into valid 8 x 8 pixel blocks (data units).
26.2
26.3
Main features
●
Compliance with the baseline JPEG standard (ISO/IEC 10918-1)
●
Single-clock per pixel encoding/decoding
●
Support for up to four channels of component color
●
8 bit/channel pixel depths
●
Programmable quantization tables (up to four)
●
Programmable Huffman tables (two AC and two DC)
●
Programmable Minimum Coded Unit (MCU)
●
Configurable JPEG headers processing
●
Support for restart marker insertion
●
Use of two DMA channels (from the basic subsystem) and of two 8 x 32-bit FIFO’s
(local to the JPGC) for efficient transferring and buffering of encoded/decoded data
from/to the Codec Core.
Pins
The JPGC directly interfaces with the signals summarized in Table 86. The JPGC is
connected as a slave on the AHB bus, and has two DMA channels asserted to itself. A
functional diagram of these signal interfaces is given in Figure 101.
Table 86.
GPIO signal interface
Size
(bit)
Group
Signal name
Direction
AHB Slave
-
Input/Output -
See AMBA specification.
DMAC
-
Input/Output -
See Chapter 36: DMA controller (DMAC)
Doc ID 022640 Rev 3
Description
287/368
JPEG codec accelerator (JPGC)
RM0319
Figure 101. JPGC signal interfaces diagram
AHB Slave
JPEG Codec
AHB Master
DMAC
26.4
Functional description
The JPGC block diagram is shown in Figure 102.
Figure 102. JPGC block diagram
A H B M a s te r
A H B S la v e
DMAC
CODEC
C o n tro lle r
A H B S la v e
F IF O
In
A H B S la v e
F IF O
O ut
In te rn a l m e m o rie s
A H B S la v e
AHB Bus
288/368
CODEC
C o re
Doc ID 022640 Rev 3
RM0319
JPEG codec accelerator (JPGC)
The main building blocks of the JPGC are five:
26.4.1
●
The Codec Core
●
The Codec Controller
●
The DMA controller (DMAC)
●
The FIFO buffers (FIFO in and FIFO out)
●
The internal memories
Codec core
The Codec core implements all the steps necessary to encode and decode image data
according to the JPEG baseline algorithm as specified in ISO/IEC 10918-1. It is specifically
designed to accelerate entropy-coded segment (ECS) encoding and decoding, because this
forms the most computing-intensive part of the baseline JPEG algorithm.
The Codec Core can enable/disable header processing. If disabled, only the ECS data is
generated/decoded. Support for restart markers is also provided: the Codec core
recognizes them in the encoded stream when decoding, and can optionally insert them
when encoding.
JPEG encoded data streams decoded by the Codec core must be compliant with the
interchange format syntax specified in the ISO/IEC 10918-1. Also JFIF images, the de facto
standard used to encoded JPEG images, is supported.
Before any coding process can start, the Codec core, together with the dmac and the
internal memories, must be programmed by writing to the corresponding registers.
The Codec Core receives from the FIFO in buffer its input data, which can be either a
sequence of Minimum Coded Units (MCU) (if the JPGC is used as an encoder from YUV
MCUs to JPEG) or a stream of Entropy Coded Segments (ECS) (if the JPGC is used as a
decoder from JPEG to YUV MCUs). Conversely, output data from the codec core are sent to
the FIFO Out buffer as an ECS stream (resp. MCU sequence), whenever the JPGC is
working as an encoder (resp. decoder).
26.4.2
Codec controller
The codec controller manages the data flow between the codec core and the FIFO buffers
between the FIFO buffers and the external RAM. In order to accomplish the latter task, it
uses the DMAC to perform fast data transfers.
Due to area optimization of the JPGC block, encoding and decoding operations performed
by the Codec Core cannot be simultaneous. Thus the Codec Controller is in charge to
assure that only a given data path (JPEG data from RAM -> JPGC -> YUV MCU data to
RAM, or the opposite) is active at a certain time.
26.4.3
DMAC
The DMA controller is used by the codec controller to perform fast data transfers from/to
external RAM to/from the internal FIFO buffers. The DMAC has to be programmed with the
correct transfer parameters, before any coding process can start. See also Chapter 36:
DMA controller (DMAC), for an in-depth description of the direct memory access block.
Doc ID 022640 Rev 3
289/368
JPEG codec accelerator (JPGC)
26.4.4
RM0319
FIFO buffers
These two First-in First-out buffers have a word width of 32 bits, and a depth of 8 words.
FIFOs are used by the Codec Controller to bufferize the flow of data incoming to (FIFO In)
and outcoming from (FIFO out) the Codec Core. Each FIFO is accessed by reading/writing
always from/to the same address.
26.4.5
Internal memories
These memories have to be programmed, before the encoding process can start, with the
tables needed by the baseline JPEG algorithm (see ISO/IEC 10918-1).
Up to four quantization tables are used for both encoding and decoding. DHTMem and
HuffEnc memories are used for encoding. HuffMin, HuffBase and HuffSymb memories are
used for decoding.
290/368
Doc ID 022640 Rev 3
RM0319
27
Digital audio port (I2S)
Digital audio port (I2S)
This chapter focuses on I2S functionality and operation.
For technical details about the programmable registers related to the I2S, refer to the I2S
registers in the following companion document:
●
27.1
RM0321: SPEAr320S address map and registers
Overview
Highly configurable, the I2S controller is for use in audio applications, providing a simple
interface to standard audio components.
27.2
27.3
Main features
●
Compliant to Philips I2S serial bus specifications
●
I2S Master for input/output operations
●
Supports 2.0 (Stereo) Audio Tx/Rx
●
Supports 12/16/20/24/32 bit audio data interface
●
Supports standard sampling rates (8, 16, 32, 44.1, 48, 96, 192 kHz). The input clock to
the PLL is 24 MHz, so the rate precision depends on the chosen rate and divider.
●
Programmable FIFO thresholds
●
Supports data exchange to the system memory through DMA interface
External pins
Table 87.
I2S signals
Signal name
Description
I/O
audio_over_samp_clk
Reference clock (Tx)
O
I2S_CLK
Serial interface clock (Tx)
O
I2S_LR
Word select line (Tx; active high)
O
I2S_RX
Serial data input for receive channel
I
I2S_TX
Serial data output for transmit channel
O
Doc ID 022640 Rev 3
291/368
Digital audio port (I2S)
27.4
RM0319
Functional description
Figure 103. I2S block diagram
DMAC REQ/CLR
APB interface
Interrupts
audio_over_samp_clk
I2S Master
I2S_CLK
I2S_TX
Transmit channel 0
Left
FIFO
Right
FIFO
I2S_LR
Receive channel 0
Left
FIFO
27.4.1
Right
FIFO
I2S_RX
Transmit channels
I2S has one stereo I2S transmit (TX) channel. This channel operates in master mode.
Stereo data pairs (such as, left and right audio data) written to a TX channel register are
shifted out serially on the serial data out line I2S_TX. The shifting is timed with respect to
the serial clock I2S_CLK and the word select line I2S_LR.
Note:
The clock generation block must be disabled prior to any changes to I2S_CLK gating value.
(refer to RM0321: SPEAr320S address map and registers)
27.4.2
Receive channels
I2S has one stereo I2S receive (RX) channel. This channel operates in master mode.
Stereo data pairs (such as, left and right audio data) are received serially from a data input
line I2S_RX. These data words are stored in RX FIFOs until they are read by software. The
receiving is timed with respect to the serial clock (I2S_CLK) and the word select line
(I2S_LR).
See also: Section 27.7.2: Using the I2S receiver (Rx mode)
292/368
Doc ID 022640 Rev 3
RM0319
27.4.3
Digital audio port (I2S)
Audio data interface
The default value of audio data for the TX/RX Channel is 32 bits. It can be reprogrammed
during operation to any supported audio data resolution that is less than 32 bits.
Valid values: 12, 16, 20, 24, or 32 bits.
Changes to the resolution are programmed my means of the word length (WLEN) bits of the
transmitter/receive configuration registers (TCR0[2:0]/RCR0[2:0]. The channel must be
disabled prior to any resolution changes.
27.4.4
External I2S_CLK gating and enable signal
When the audio data resolution of the receive and transmit channels is less than the current
word select size, the I2S_CLK can be gated off for the remainder of the left/right cycle. This
can be programmed during operation of the component by setting the I2S_CLK Gating
(SCLKG) bits [2:0] in the Clock Configuration Register (CCR).
The clock generation block must be disabled prior to any changes to I2S_CLK gating value.
27.5
Clocks
Figure 104. I2S clocks
PLL2
audio_over_samp_clk
RAS_CLK_SYNT3
DIV4
I2S_CLK
sclk
I2S
Clksel
(from configuration
registers)
Doc ID 022640 Rev 3
I2S_LR
I2S_TX
I2S_RX
293/368
Digital audio port (I2S)
27.6
RM0319
Interrupts
The four I2S interrupt sources are ORed to a single global interrupt request. The I2S global
interrupt is mapped on the same interrupt request line (IRQ30) as the PL_GPIO interrupt
request.
Note:
PL_GPIO interrupts must be disabled if I2S interrupts are used and vice versa.
See also: Interrupt request table on page 361
Table 88.
I2S interrupts
Name
Interrupt
Description
Tx block empty
This interrupt is asserted when the empty trigger threshold level for the TX
FIFO is reached. A TX FIFO Empty interrupt is cleared by writing data to the
TX FIFO to bring its level above the empty trigger threshold level for the
channel
intr_or_tx
Tx block overrun
This interrupt is asserted when an attempt is made to write to a full TX. A
Data Overrun interrupt is cleared by reading the Transmit Channel Overrun
(TXCHO) bit [0] of the Transmit Overrun Register (TOR0). FIFO (any data
being written is lost while data in the FIFO is preserved).
intr_da_rx
This interrupt is asserted when the trigger level for the RX FIFO is reached.
Rx block data available This interrupt is cleared by reading data from the RX FIFO until its level
drops below the data available trigger level for the channel.
intr_or_rx
This interrupt is asserted when an attempt is made to write received data to
a full RX FIFO (any data being written is lost while data in the FIFO is
preserved). This interrupt is cleared by reading the Receive Channel
Overrun (RXCHO) bit [0] of the Receive Overrun Register (ROR0).
intr_emp_tx
Rx block overrun
27.7
Programming examples
27.7.1
Using the I2S transmitter (Tx mode)
Note:
Before executing the following steps, enable the I2S block clocks.
27.7.2
1.
Enable I2S: write IER[0] = 1
2.
Fill TX FIFOs: write data to LTHR and RTHR until filled.
Alternately, use the TXDMA registers to write data into the TX FIFOs.
3.
Enable the transmitter block: write ITER[0] = 1
4.
Enable clock generation: write CER[0] = 1
Using the I2S receiver (Rx mode)
1.
294/368
Enable I2S: write IER[0] = 1
2.
Enable the receive block: write IRER[0] = 1
3.
Read data through the LRBR and RRBR/RXDMA registers.
Doc ID 022640 Rev 3
RM0319
27.7.3
Digital audio port (I2S)
Programming FIFO thresholds
The I2S controller has programmable thresholds for the transmit and the receive FIFOs.
Changing the thresholds changes the frequency of the interrupts received. To reprogram
levels during operation, write to:
27.7.4
●
The transmit channel empty trigger (TXCHET) bits of the transmit FIFO configuration
register (TFCR0[3:0])
●
The receive channel data trigger (RXCHDT) bits of the receive FIFO configuration
register (RFCR0[3:0])
Exchanging data with system memory
System DMAC can also be used to transfer data to and from the I2S IP; DMA request and
clear lines perform the handshake with DMAC.
The internal interrupt mechanism implements DMAC handshaking.
●
Tx: interrupt intr_emp_tx is generated upon reaching the threshold value. This interrupt
also results in the generation of a DMA request to DMAC.
●
Rx: a DMA request is generated at the assertion of interrupt intr_da_rx.
The DMAC clears the request lines.
Doc ID 022640 Rev 3
295/368
Security co-processor (C3)
28
RM0319
Security co-processor (C3)
This chapter focuses on C3 functionality and operation.
For technical details about the programmable registers related to the C3, refer to the C3
registers in the following companion document:
●
28.1
RM0321: SPEAr320S address map and registers
Overview
C3 is a DMA-based co-processor enabling the acceleration of data-driven computationally
expensive functions, such as: cryptography, pattern matching, signal processing, security
and network security applications. It can be used for other types of data intensive
applications as well.
It executes instruction flows generated by the host processor. After it has been set up by the
host, it runs in a completely autonomous way (DMA data in, data processing, DMA data
out), until the completion of all the requested operations.
28.2
Main features
●
C3 Hardware ID base address 0xFFFF_1000
●
Four instruction dispatchers
●
Four hardware accelerator channels with in/out FIFO inside
●
64 KB of internal RAM for low latency accesses
●
Coupling/Chaining Module (internal cross-bar) for interchannel direct high-speed
communications, up to 8 paths
●
Highly programmable (instruction-driven) controller
●
AMBA AHB 2.0 Master and Slave Interfaces
●
Scatter and Gather DMA engine
C3 has 8 slots for including channels (hardware accelerators). The channel configuration is
as follows:
Channel 0 - Empty
Channel 1 - Data Encryption Standard (DES and TripleDES)
296/368
Doc ID 022640 Rev 3
RM0319
Security co-processor (C3)
Supported algorithms:
●
DES (56 bit keys, no parity)
●
DES ECB encryption + decryption
●
DES CBC encryption + decryption
●
TripleDES (168 bit keys EncDecEnc)
●
3DES ECB encryption + decryption
●
3DES CBC encryption + decryption
●
FIFO Size
–
Input FIFO: 16x32 bits
–
Output FIFO: 16x32 bits
Doc ID 022640 Rev 3
297/368
Security co-processor (C3)
RM0319
Channel 2 - Advanced Encryption Standard (AES)
Channel ID: 0x0000_3000
Supported algorithms
●
AES (128, 192, 256 bit keys)
●
AES ECB encryption + decryption
●
AES CBC encryption + decryption
●
AES Counter Mode encryption + decryption
●
FIFO Size
–
Input FIFO: 16x32 bits
–
Output FIFO: 16x32 bits
Channel 3 - Unified Hash with HMAC
Channel ID: 0x0000_4002
Supported algorithms
●
●
●
MD5
–
Hash with 128 bit digest
–
HMAC
SHA1
–
Hash with 160 bit digest
–
HMAC
FIFO Size
–
Input FIFO: 16x32 bits
–
Output FIFO: 8x32 bits
Channel 4 - Empty
Channel 5 - Empty
Channel 6 - Empty
Channel 7 - Empty
●
●
298/368
Number of Instruction Dispatchers is 4. The configuration is as follows:
–
ID0 - Available
–
ID1 - Empty
–
ID2 - Empty
–
ID3 - Empty
Number Coupling / Chaining Module (internal cross-bar) for inter channel direct highspeed communications is 1.
Doc ID 022640 Rev 3
RM0319
Functional description
Table 89.
C3 device summary
Features
C3 version 3
Interfaces
AMBA AHB 2.0 Master Interface
AMBA AHB 2.0 Slave Interface
Instruction Dispatchers (IDS) Available
1
Channels Available
3
Coupling/Chaining Paths Available
1
Figure 105. C3 block diagram
Buffer
(RAM)
Reset
SYS
IDS (Inst.Disp.Subsys)
IRQ
Channel #0
Channel #1
Channel #2
CCM (Coupling and chaining)
AMBA
AHB 2.0
HIF(AHB Master Iinterface)
28.3
Security co-processor (C3)
Channel #7
SIF(AHB Slave Interface)
C3 is a highly programmable DMA based hardware co-processor that executes some
instructions flows (programs) written in memory by the host processor. These programs
specify which operations must be performed and where to locate data buffers (input, output,
parameters) in memory.
After being set-up C3 is completely autonomous and can perform an unlimited number of
operations, until it hits an end of program instruction in which case it can signal the end of
processing by the means of an interrupt request (if programmed to do so).
Doc ID 022640 Rev 3
299/368
Security co-processor (C3)
RM0319
C3 has two interfaces:
●
AHB Master Interface: it is used to fetch instruction flows, to access input data,
parameters and to store output data to system memory.
●
AHB Slave Interface: it is used to set-up the device and to access all the registers.
C3 has been designed to perform acceleration of data-intensive applications where
computationally expensive algorithms must operate on medium to large memory buffers.
Such applications can be found in the fields of security (data encryption, integrity check,
etc.) and networking.
There are many other fields of application for C3, such as signal processing, image
processing and in general applications that require complex mathematical computations
28.3.1
HIF (High speed bus interface)
This block implements an AMBA AHB 2.0 compliant Master interface. It receives internal
requests from all the C3 internal initiator blocks and it translates them into AHB bus
requests. The HIF is a master only and will not allow access to the C3 internal.
28.3.2
SIF (Slave bus interface)
This block implements an AMBA AHB 2.0 compliant Slave interface. This interface is used to
set-up the device and access all the memory mapped internal registers. Each channel is
allocated a 1K byte address space and the major blocks of the C3 are also allocated space
in the map.
28.3.3
IDS (Instruction dispatchers sub-system)
This block contains the instruction dispatchers (up to 4) that are in charge of fetching the
programs from memory and dispatch the instructions to the requested channels. Since the
instruction dispatchers operate in parallel up to 4 instruction flows can be executed
concurrently.
If programmed to do so the instruction dispatcher signal the end of processing to the host
processor by raising an interrupt signal.
Each Instruction Dispatchers (ID) can handle two types of instructions:
28.3.4
●
Flow Type Instructions: these are C3 control instructions and are executed by the ID
itself
●
Application Specific Instructions: these are processing instructions that are directly
dispatched by the ID to the right channel that will perform decoding and execution.
Channel
A Channel is a specific function or set of similar functions and a wrapper to provide data flow
management, instruction handling and interface to the various parts of C3. Channels
implement the data processing. Total number of channels available in this version of C3 is 3.
Channels operate in parallel and contend the access to the system bus through the HIF
arbitration mechanism. Channels are designed to efficiently support the data-flow model of
computation.
300/368
Doc ID 022640 Rev 3
RM0319
Security co-processor (C3)
The channel main features are the following:
28.3.5
●
Decoding of the instructions received from the dispatcher sub-system.
●
DMA engine with support of scatter and gather operations.
●
Internal input / output data-flows buffering by the means of FIFO in order to
accommodate for the system bus latency.
●
I/O multiplexing, so that data can be directly received from/sent to other channels
without going through memory.
●
Support for multiple algorithms in the Core block. The Core block implementation is
application specific.
CCM (Coupling/Chaining module)
This block implements a cross-bar allowing direct connection of channels Input/Outputs
between them. Typical use cases of the CCM are for:
●
Sending the output data generated by a channel to the input of another channel, also
known as “chaining”.
●
Sending the input data received by a channel from the system bus to the input of
another channel, also known as “coupling”.
Doc ID 022640 Rev 3
301/368
Security co-processor (C3)
28.4
RM0319
Operation
This section outlines the main steps involved in setting up C3 for processing.
28.4.1
●
The host processor creates a program and stores it in memory.
●
The program contains C3 instructions and their arguments (usually pointers to data
buffers in system memory).
●
The host processor writes the base address of the program in the Instruction Pointer
Register of one of the Instruction Dispatcher (ID).
●
Instruction Dispatchers (IDs) work independently from each other and each ID can
handle a C3 instruction flow.
●
From the system/software standpoint, each logical device (associated to an Instruction
Dispatcher) can be managed by an independent software task, which is to say that a
C3 with 4 dispatchers is equivalent to 4 logical co-processors.
●
The selected Instruction Dispatcher starts fetching the program from system memory
and fills its instruction queue. It then process the instruction flow sequentially, one
instruction at a time.
●
The ID either executes the instruction itself (in case of Flow Type instruction) or it
dispatches the instruction to the specified channel (in case of application specific
instruction).
●
The channel executes the instruction
●
The channel generally performs DMA access request for reading input data and
parameters from system memory, but it may be set-up to receive data from another
channel.
●
The channel Core block (CB) performs the actual data processing, which is specific to
the implemented algorithm.
●
The channel generally then performs DMA access request for writing the output data to
system memory, but it may be set-up to send data to another channel too.
●
When the ID hits the end of program it signals completion by rising an interrupt
●
Interrupt generation may be disabled, in which case polling by the host processor of the
C3 status register can be used to determine the end of processing.
Channel ID
Each Channel/Version is assigned a unique 32 bit Identifier that can be read in the Channel
ID register of each channel.
The upper 8 bit of the Channel ID are reserved for specific organizations. In order to
manage the situation in which different versions of the same channel are developed by
different company organizations the organization specific bit indicates which organization is
in charge of maintaining the corresponding version of the channel. In the device, the bit
mask to be used for retrieving this ID is 0x8000_0000.
Table 90.
302/368
Channel ID Table
Channel
No.
Channel Name Function
Type
Channel ID
0
EMPTY_CNL
No channel
-
-
1
DES_CNL
DES/3DES algorithm (ECB,
CBC modes)
Cryptography
0x00002000
Doc ID 022640 Rev 3
RM0319
Security co-processor (C3)
Table 90.
28.4.2
Channel ID Table (continued)
Channel
No.
Channel Name Function
2
AES_CNL
AES algorithm (ECB, CBC, CTR
Cryptography
modes)
0x00003000
3
UH_CNL
SHA-1/MD5 + HMAC algorithms Cryptography
0x00004002
4
EMPTY_CNL
No Channel
-
-
5
EMPTY_CNL
No Channel
-
-
6
EMPTY_CNL
No Channel
-
-
7
EMPTY_CNL
No Channel
-
-
Type
Channel ID
DES channel
This Channel can compute DES and 3DES encryption and decryption in ECB and CBC
mode; executing C3 Flow type DES [START/APPEND] instruction.
Instruction set
The DES Channel executes DES [START/APPEND] ENCRYPT and DES [START/APPEND]
DECRYPT instructions. Instructions that do not conform to the following bit encodings are
unknown to the DES Channel that will go in error state.
DES instructions
There are 2 different DES instructions:
●
DES START
●
DES APPEND
The first instruction is used for setting the operation parameters, such as the key and the
initialization vector. The second one is used for passing the data to encrypt or decrypt.
DES START instruction
The DES START instruction can be applied with 2 different modes of operation:
●
ECB
●
CBC
ECB
The DES START ECB instruction is 2 words long. This instruction is used to set the key for
the following operations. The length of the key is encoded in the first instruction word, while
the second word represents the Source Address for the key.
Table 91.
DES ECB start instruction bit encoding
W#
Bit Encoding
1
xxxx01ab 000x xxxx cccc cccc cccc cccc
2
(32 bit Source Address for the key)
Doc ID 022640 Rev 3
303/368
Security co-processor (C3)
RM0319
Bit ‘a’ in the above table is used to set the algorithm to use:
Table 92.
DES ECB bit ‘a’ encoding
Bit 25
a
Operation
0
DES
1
3DES
Bit ‘b’ in the above table is used to set the operation to perform:
Table 93.
DES ECB bit ‘b’ encoding
Bit 24
b
Operation
0
Encryption
1
Decryption
Bits 15 to 0 in the first instruction word (cccc in the above table) represent the length in
Bytes of the key.
CBC
The DES START CBC instruction is 3 words long. This instruction is used to set the key and
the initialization vector for the following operations. The length of the key is encoded in the
first instruction word, the second word represents the Source Address for the key and the
third word represents the Source Address for the Initialization Vector.
Table 94.
DES CBC START Instruction Bit Encoding
W#
Bit Encoding
1
xxxx 10ab 001x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the key
3
32 bit Source Address for the IV
Bits ‘a’ and ‘b’ in the above table are used to set the algorithm and the operation to perform
and have the same encoding as in the ECB instruction. Bits 15 to 0 in the first instruction
word (cccc in the above table) represent the length in Bytes of the key.
DES APPEND instruction
The DES APPEND instruction can be applied with 2 different modes of operation:
●
ECB
●
CBC
ECB
The DES APPEND ECB instruction is 3 words long. This instruction is used for passing the
data to process (encrypt or decrypt). The length of the data to process is encoded in the first
304/368
Doc ID 022640 Rev 3
RM0319
Security co-processor (C3)
instruction word, the second word represents the Source Address and the third word
represents the Destination Address.
Table 95.
DES ECB APPEND Instruction bit encoding
W#
Bit Encoding
1
xxxx 10ab 100x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the data
3
32 bit Destination Address for the data
Bit a in the above table is used to set the algorithm to use:
Bit 25
a
Operation
0
DES
1
3DES
Bit b in the above table is used to set the operation to perform:
Bit 24
b
Operation
0
Encryption
1
Decryption
Bits 15 to 0 in the first instruction word (cccc in the above table) represent the length in
Bytes of the data to be processed.
CBC
The DES APPEND CBC instruction is 3 words long. This instruction is used for passing the
data to process (encrypt or decrypt). The length of the data to process is encoded in the first
instruction word, the second word represents the Source Address and the third word
represents the Destination Address.
Table 96.
DES CBC Append Instruction Bit Encoding
W#
Bit Encoding
1
xxxx 10ab 101x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the data
3
32 bit Destination Address for the data
Bits ‘a’ and ‘b’ in the above table are used to set the algorithm and the operation to perform
and have the same encoding as in the ECB instruction (Table 92. and Table 93.). Bits 15 to 0
in the first instruction word (cccc in Table 96.) represent the length in Bytes of the key.
Doc ID 022640 Rev 3
305/368
Security co-processor (C3)
28.4.3
RM0319
AES channel
This channel computes AES encryption and decryption in ECB, CTR and CBC mode;
executing C3 Flow type instruction set.
Instruction set
The AES Channel executes AES [START/APPEND] ENCRYPT and AES [START/APPEND]
DECRYPT instructions specified in the C3v3 flow type instruction set v2.1 document
[ISv2.1]. Instructions that do not conform to the following bit encodings or to [ISv2.1] are
unknown to the AES Channel that will go in error state.
AES instructions
There are 2 different AES instructions:
●
AES START
●
AES APPEND
The first instruction is used for setting the operation parameters, such as the key and the
initialization vector. The second one is used for passing the data to encrypt or decrypt.
AES START instruction
The AES START instruction can be applied with 3 different modes of operation:
●
ECB
●
CBC
●
CTR
ECB
The AES START ECB instruction is 2 words long. This instruction is used to set the key for
the following operations. The length of the key is encoded in the first instruction word, while
the second word represents the Source Address for the key.
Table 97.
AES ECB START instruction bit encoding
W#
Bit Encoding
1
xxxx 01xa 000x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the key
Bit ‘a’ in the above table is used to set the operation to perform:
Table 98.
AES ECB Bit ‘a’ encoding
Bit #24 - a
Operation
0
DES
1
3DES
Bits 15 to 0 in the first instruction word (cccc in Table 96.) represent the length in Bytes of
the key.
306/368
Doc ID 022640 Rev 3
RM0319
Security co-processor (C3)
CBC
The AES START CBC instruction is 3 words long. This instruction is used to set the key and
the initialization vector for the following operations. The length of the key is encoded in the
first instruction word, the second word represents the Source Address for the key and the
third word represents the Source Address for the Initialization Vector.
Table 99.
AES CBC START instruction bit encoding
W#
Bit Encoding
1
xxxx 10xa 001x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the key
3
32 bit Source Address for the IV
Bit ‘a’ in the above table is used to set the operation to perform and has the same encoding
as in the ECB instruction (Table 97). Bits 15 to 0 in the first instruction word (cccc in
Table 99) represent the length in Bytes of the key.
CTR
The AES START CTR instruction is 3 words long. This instruction is used to set the key and
the initialization vector for the following operations. The length of the key is encoded in the
first instruction word, while the second word represents the Source Address for the key.
Table 100. AES CTR START instruction bit encoding
W#
Bit Encoding
1
xxxx 10xa 010x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the key
3
32 bit Source Address for the IV
Bit ‘a’ in the above table is used to set the operation to perform and has the same encoding
as in the ECB instruction (Table 98). Bits 15 to 0 in the first instruction word (cccc in
Table 100) represent the length in Bytes of the key.
AES APPEND instruction
The AES APPEND instruction can be applied with 3 different modes of operation:
●
ECB
●
CBC
●
CTR
ECB
The AES APPEND ECB instruction is 3 words long. This instruction is used for passing the
data to process (encrypt or decrypt). The length of the data to process is encoded in the first
instruction word, the second word represents the Source Address and the third word
represents the Destination Address.
Doc ID 022640 Rev 3
307/368
Security co-processor (C3)
RM0319
Table 101. AES ECB APPEND instruction bit encoding
W#
Bit Encoding
1
xxxx 10xa 100x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the data
3
32 bit Destination Address for the data
Bit ‘a’ in the above table is used to set the operation to perform.
Bit 24
Description
a
Operation
0
Encryption
1
Decryption
Bits 15 to 0 in the first instruction word (cccc in Table 101) represent the length in Bytes of
the data to be processed.
CBC
The AES APPEND CBC instruction is 3 words long. This instruction is used for passing the
data to process (encrypt or decrypt). The length of the data to process is encoded in the first
instruction word, the second word represents the Source Address and the third word
represents the Destination Address.
Table 102. AES CBC APPEND instruction bit encoding
W#
Bit Encoding
1
xxxx 10xa 101x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the data
3
32 bit Destination Address for the data
Bit ‘a’ in the above table is used to set the operation to perform and has the same encoding
as in the ECB instruction (Table 101). Bits 15 to 0 in the first instruction word (cccc in
Table 102) represent the length in Bytes of the key.
CTR
The AES APPEND CTR instruction is 3 words long. This instruction is used for passing the
data to process (encrypt or decrypt). The length of the data to process is encoded in the first
instruction word, the second word represents the Source Address and the third word
represents the Destination Address.Address.
Table 103. AES CTR APPEND instruction bit encoding
308/368
W#
Bit Encoding
1
xxxx 10xa 110x xxxx cccc cccc cccc cccc
Doc ID 022640 Rev 3
RM0319
Security co-processor (C3)
Table 103. AES CTR APPEND instruction bit encoding (continued)
W#
Bit Encoding
2
32 bit Source Address for the data
3
32 bit Destination Address for the data
Bit ‘a’ in the above table is used to set the operation to perform and has the same encoding
as in the ECB instruction (Table 101). Bits 15 to 0 in the first instruction word (cccc in Table
103.) represent the length in Bytes of the key.
28.4.4
Unified hash with HMAC channel
Unified HASH channel can compute MD5 and SHA-1 digests of a message, executing C3
Flow type instruction set's HASH [MD5/SHA1] instruction.
It can compute the HMAC of a message with MD5 and SHA-1, executing C3 Flow type
instruction set's HMAC [MD5/SHA1] instruction.
It can save and restore the internal context in order to allow the stop and the resume of the
computation, executing C3 Flow type instruction set's HASH [CONTEXT] and HMAC
[CONTEXT] instructions.
Instruction set
The UH Channel executes HASH [MD5/SHA1/CONTEXT] and HMAC
[MD5/SHA1/CONTEXT] instructions specified in the C3v3 flow type instruction set.
Instructions that do not conform to the following bit encodings are unknown to the UH
Channel that will go in error state.
HASH instruction
There are 3 different HASH instructions:
●
HASH MD5
●
HASH SHA1
●
HASH CONTEXT
The first 2 instructions are used for computing the digest of a message and work in the
same way. The last one is used for saving and restoring the context.
HASH [MD5/SHA1] instructions
Each HASH [MD5/SHA1] instruction is composed of 3 sub-instructions:
●
INIT
●
APPEND
●
END
INIT
The HASH [MD5/SHA1] INIT instruction is 1 word long. This instruction is used to set the
Function.
Doc ID 022640 Rev 3
309/368
Security co-processor (C3)
RM0319
Table 104. HASH INIT Instruction bit encoding
W#
Bit Encoding
1
xxxx 000a a00x xxxx cccc cccc cccc cccc
Bits ‘aa’ in the above table are used to set the algorithm to use:
Table 105. HASH INIT Bit ‘aa’ encoding
Bit 24 to 23
aa
Algorithm
2’b00
MD5
2’b01
SHA-1
2’b10
Not Used
2’b11
Context (See CONTEXT instruction)
APPEND
The HASH [MD5/SHA1] APPEND instruction is 2 words long. This instruction is used to set
the Source Address Register for the message and to start the computation of the digest.
The length of the message is encoded in the first instruction word, while the second word
represents the Source Address for the message.
Table 106. HASH APPEND Instruction bit encoding
W#
Bit Encoding
1
xxxx 010a a01x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the message
Bits aa in the above table are used to set the algorithm to use and have the same encoding
as in the INIT instruction (Table 105.). Bits 15 to 0 in the first instruction word (cccc in Table
106.) represent the Count in Bytes of the input message.
END
The HASH [MD5/SHA1] END instruction is 2 words long. This instruction is used to set the
Destination Address Register for the message and to end the computation of the digest.
The second word represents the Destination Address for the digest.
Table 107. HASH END Instruction bit encoding
310/368
W#
Bit Encoding
1
xxxx 010a a01t xxxx cccc cccc cccc cccc
2
32 bit Destination Address for the message
Doc ID 022640 Rev 3
RM0319
Security co-processor (C3)
Bits ‘aa’ in the above table are used to set the algorithm to use and have the same encoding
as in the INIT instruction (Table 105.).
Bit ‘t’ in the above table is used to truncate the result to 96 bits:
Bit 20
t
Truncate
1’b0
Full digest
1’b1
Truncated 96 bit digest
HASH CONTEXT instruction
The HASH CONTEXT instruction is composed by 2 sub-instructions:
●
SAVE
●
RESTORE
SAVE
The HASH CONTEXT SAVE instruction is 2 words long. This instruction is used to set the
Destination address Register for the context and to save the full context.
The second word represents the Destination Address for the context.
Table 108. HASH CONTEXT SAVE Instruction bit encoding
W#
Bit Encoding
1
xxxx 0101 10xx xxxx cccc cccc cccc cccc
2
32 bit Destination Address for the context
RESTORE
The HASH CONTEXT RESTORE instruction is 2 words long. This instruction is used to set
the Source Address Register for the context and to restore the full context.
The second word represents the Source Address for the context.
Table 109. HASH CONTEXT RESTORE Instruction bit encoding
W#
Bit Encoding
1
xxxx 0101 11xx xxxx cccc cccc cccc cccc
2
32 bit Source Address for the context
HMAC instruction
There are 3 different HMAC instructions:
●
HMAC MD5
●
HMAC SHA1
●
HMAC CONTEXT
Doc ID 022640 Rev 3
311/368
Security co-processor (C3)
RM0319
The first 3 instructions are used for computing the HMAC of a message and work in the
same way. The last one is used for saving and restoring the context.
HMAC [MD5/SHA1] instructions
Each HMAC [MD5/SHA1] instruction is composed by 3 sub-instructions:
●
INIT
●
APPEND
●
END
INIT
The HMAC [MD5/SHA1] INIT instruction is 2 words long. This instruction is used to set the
Function and the Source Address Register for the HMAC key.
Table 110. HMAC INIT Instruction bit encoding
W#
Bit Encoding
1
xxxx 011a a00x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the key
Bits ‘aa’ in the above table are used to set the algorithm to use and have the same encoding
as in the HASH INIT instruction (Table 105.).
Bits 15 to 0 in the first instruction word (cccc in Table 110.) represent the length in Bytes of
the key.
APPEND
The HMAC [MD5/SHA1] APPEND instruction is 2 words long. This instruction is used to set
the Source Address Register for the message and to start the computation of the HMAC.
The length of the message is encoded in the first instruction word, while the second word
represents the Source Address for the message.
Table 111. HMAC APPEND Instruction bit encoding
W#
Bit Encoding
1
xxxx 011a a01x xxxx cccc cccc cccc cccc
2
32 bit Source Address for the message
Bits ‘aa’ in the above table are used to set the algorithm to use and have the same encoding
as in the INIT instruction (Table 110.).
Bits 15 to 0 in the first instruction word (cccc in Table 111) represent the Count in Bytes of
the input message.
Note:
312/368
The state of the HASH channel should be saved after an HMAC-APPEND instruction, if a
consecutive HMAC-APPEND instruction is to be executed. The consecutive APPEND
instruction should be executed after restoring the previously saved state of the channel. If
this process is not followed, the HASH channel will not respond to any further instructions as
it will become non-operational.
Doc ID 022640 Rev 3
RM0319
Security co-processor (C3)
END
The HMAC [MD5/SHA1] END instruction is 3 words long. This instruction is used to set the
Source Address Register for the HMAC key and the Destination Address Register for the
HMAC and to end the computation of the HMAC.
The second word represents the Source Address for the key, while the third word represents
the Destination Address for the HMAC.
Table 112. HMAC END Instruction bit encoding
W#
Bit Encoding
1
xxxx 101a a10tx xxxx cccc cccc cccc cccc
2
32 bit Source Address for the key
3
32 bit Destination Address for the message
Bits ‘aa’ in the above table are used to set the algorithm to use and have the same encoding
as in the INIT instruction (Table 110.).
Bits 15 to 0 in the first instruction word (cccc in Table 112.) represent the length in Bytes of
the key.
Bit ‘t’ in the above table is used to truncate the result to 96 bits.
Bit 20
t
Truncate
1’b0
Full HMAC
1’b1
Truncated 96 bit HMAC
HMAC CONTEXT instruction
The HMAC CONTEXT instruction is composed by 2 sub-instructions:
●
SAVE
●
RESTORE
SAVE
The HMAC CONTEXT SAVE instruction is 2 words long. This instruction is used to set the
Destination Address Register for the context and to save the full context.
The second word represents the Destination Address for the context.
Table 113. HMAC CONTEXT SAVE Instruction bit encoding
W#
Bit Encoding
1
xxxx 0111 10xx xxxx cccc cccc cccc cccc
2
32 bit Destination Address for the context
Doc ID 022640 Rev 3
313/368
Security co-processor (C3)
RM0319
RESTORE
The HMAC CONTEXT RESTORE instruction is 2 words long. This instruction is used to set
the Source Address Register for the context and to restore the full context.
The second word represents the Source Address for the context.
Table 114. HMAC CONTEXT RESTORE instruction bit encoding
314/368
W#
Bit Encoding
1
xxxx 0111 11xx xxxx cccc cccc cccc cccc
2
32 bit Source Address for the context
Doc ID 022640 Rev 3
RM0319
29
System controller (SYSCTR)
System controller (SYSCTR)
This chapter focuses on the system controller functionality and operation.
For technical details about the programmable registers related to the system controller, refer
to the system controller registers in the following companion document:
●
29.1
RM0321: SPEAr320S address map and registers
Overview
The system controller provides an interface for controlling the operation of the overall
system.
29.2
Main features
●
System mode control state machine
●
Integrates crystal and PLL control
●
Defines the system response to interrupts
●
Implements soft reset generation
●
Generates watchdog module clock enable
Doc ID 022640 Rev 3
315/368
System controller (SYSCTR)
29.3
RM0319
Functional description
Figure 106. System controller block diagram
nPOR
SCLK
Clock and reset
inputs
PRESETn
PENABLE
PSEL
PWRITE
APB interface
PRDATA[31:0]
PWDATA[31:0]
PADDR[11:2]
PLLON
PLLSW
PLL oscillator
control and status
PLLTIMEEN
XTALON
XTALSW
Crystal oscillator
control and status
PLLEN
PLLRQSW
PLLFREQCTRL[31:0]
XTALEN
XTALRQSW
XTALTIMEEN
PERIPHCLKEN[31:0]
Clock control and
status
HCLKDIVSEL[2:0]
PERIPHCTRL0[31:0]
PERIPHCTRL1[31:0]
PERIPHCLKSTAT[31:0]
REDCLK
SLEEPMODE
TIMCLK
WDEN
TIMERCLKEN0
TIMERCLKEN1
TIMERCLKEN2
TIMERCLKEN3
WDCLKEN
SYSSTAT[31:0]
REMAPSTAT
nIRQ
STANDBYWFI
System control
and status
nFIQ
REMAPCLEAR
SOFTRESREQ
SYSMODE[3:0]
SYSID[31:0]
SCANENABLE
SCANINSCLK
316/368
Scan test interface
Doc ID 022640 Rev 3
SCANOUTSCLK
RM0319
29.3.1
System controller (SYSCTR)
System modes control
Here there is a description of how the system controller changes between modes: DOZE,
SLEEP, SLOW and NORMAL.
The state machine is controlled using three mode control bits (ModeCtrl[2:0]) in the system
control register (SCCTRL), which define the required system operating mode. The mode
control bits control the modes:
●
1xx If the most significant bit (MSB) is set then the system moves into NORMAL mode.
●
01x If the MSB is not set and the next MSB is set then the system moves into SLOW
mode.
●
001 If only the least significant bit (LSB) is set then the system moves into DOZE mode.
●
000 If none of the mode control bits are set the system moves into SLEEP mode.
When the required operating mode has been defined in the system mode control register
the system mode control state machine moves to the required operating mode without
further software interaction.
The current system mode can read by software from the ModeStatus[3:0] bits in the
SCCTRL register.
If the nPOR input is activated, the state machine and the required operating mode in the
system control register are set to DOZE. If the PRESETn input is activated, the system
mode control state machine does not change mode but the required operating mode is set
to DOZE in the system control register.
SLEEP mode
During this mode the system clocks, HCLK and CLK, are disabled and the system controller
clock SCLK is driven from a low speed oscillator (nominally 32 768 Hz). When either a FIQ
or an IRQ interrupt is activated (through the VIC) the system moves into the DOZE mode.
Additionally, the required operating mode in the system control register automatically
changes from SLEEP to DOZE.
DOZE mode
During this mode the system clocks, HCLK and CLK, and the system controller clock SCLK
are driven from the output of crystal oscillator (24 MHz) or low frequency oscillator (32 kHz).
The system controller moves into SLEEP mode from DOZE mode only when none of the
mode control bits are set and the processor is in Wait-for-interrupt state. If SLOW mode or
NORMAL mode is required the system moves into the XTAL control transition state to
initialize the crystal oscillator.
SLOW mode
During this mode, both the system clocks and the system controller clock are driven from
the output of the crystal oscillator.
If NORMAL mode is required, the system moves into the “PLL control” transition state. If
neither the SLOW nor the NORMAL mode control bits are set, the system moves into the
“Switch from XTAL” transition state.
NORMAL mode
In NORMAL mode, both the system clocks and the system controller clock are driven from
the output of PLL.
Doc ID 022640 Rev 3
317/368
System controller (SYSCTR)
RM0319
If the NORMAL mode control bit is not set, then the system moves into the “Switch from
PLL” transition state.
XTAL control transition state, XTAL CTL
XTAL control transition state is used to initialize the crystal oscillator. While in this state, both
the system clocks and the system controller clock are driven from a low-frequency oscillator.
The system moves into the Switch to XTAL transition state when the crystal oscillator output
is stable. This is indicated when either the XTAL timeout defined in the XTAL control register
expires (when the XTALTIMEEN input is valid) or by the XTALON input being set to logic ‘1’.
Switch to XTAL transition state, SW TO XTAL
Switch to XTAL transition state is used to initiate the switching of the system clock source
from the slow speed oscillator to the crystal oscillator. The system moves into the SLOW
mode when the XTALSW input is set to logic ‘1’, to indicate that the clock switching is
complete.
Switch from XTAL transition state (SW from XTAL)
The “Switch from XTAL” transition state is entered when moving from SLOW to DOZE mode.
It is used to initiate the switching of the system clock source from the crystal oscillator to the
low speed oscillator. The system moves into the DOZE mode when the XTALSW input is set
to PLL control transition state (PLL CTL)
PLL control transition state, PLL CTL
The “PLL control” transition state is used to initialize the PLL. While in this state, both the
system clocks and the system controller clock are driven by the output of the crystal
oscillator.
The system moves then into the “Switch to PLL” transition state when the PLL timeout
defined in the PLL control register (SCPLLCTRL register) expires (when the PLLTIMEEN
input is invalid) and if the PLLON input is set to logic1.
Switch to PLL transition state (SW to PLL)
The “Switch to PLL” transition state is used to initiate the switching of the system clock
source from the crystal oscillator to the PLL output.
The system moves then into the NORMAL mode when the PLLSW input is set to logic ‘1’ to
indicate that the clock switching is complete.
Switch from PLL transition state (SW from PLL)
The “Switch from PLL” transition state is entered when moving from NORMAL to SLOW
mode. It is used to initiate the switching of the clock sources from the PLL to the crystal
oscillator output.
The system moves then into the SLOW mode when the PLLSW input is set to logic ‘0’ to
indicate that the clock switching is complete.
318/368
Doc ID 022640 Rev 3
RM0319
29.3.2
System controller (SYSCTR)
System control state machine
Figure 107. System mode control state machine
PLLSW
NORMAL
NORMAL
SW to
PLL
PLLON ||(PLLTIMEEN && PLL Timeout)
SW From
PLL
PLL
CTL
PLL SW
NORMAL
SLOW
XTAL SW
SLOW&NORMAL
SW to
XTAL
XTALON ||(XTALTIMEEN && XTAL Timeout)
XTAL
CTL
nPOR
SLOW |
NORMAL
SW From
XTAL
XTALSW
DOZE
DOZE&SLOW&NORMAL
&STANDBYWFI
IRQ | FIQ
SLEEP
Crystal oscillator and PLL control
The system control state machine (Section 29.3.2: System control state machine) can also
be used to control the crystal oscillator and the PLL.
Nevertheless, software can be used to override control of the crystal and PLL by using the
crystal control register (SCXTALCTRL) and the PLL control register (SCPLLCTRL).
PLL frequency control
To define the frequency of the clock generated from the PLL, the system controller provides
a PLL frequency control register (SCPLLFCTRL, Section 29.3.5).
Doc ID 022640 Rev 3
319/368
System controller (SYSCTR)
29.3.3
RM0319
Interrupt response mode
To enable the best possible response to interrupts, the current mode bits can be modified by
hardware in the system control register after an interrupt has been generated. This enables,
for example, the state machine to move from DOZE mode to NORMAL mode after an
interrupt.
The interrupt response functionality is controlled by the interrupt mode control register
(SCIMCTRL), which defines if the functionality has been enabled, the mode of operation
that is required following an interrupt, what type of interrupt is permitted to enable the
interrupt response mode, an interrupt mode status bit and clear mechanism.
Note:
It is not possible for the interrupt response mode to slow the system operating speed, for
example, changing mode from NORMAL to SLOW.
The interrupt response mode is cleared by writing a 1‘b0 to the interrupt mode control
register SCIMCTRL. Following a power-on reset, the interrupt response mode is disabled.
29.3.4
Reset control
The reset control is used to request a soft reset to be generated by asserting the
SOFTRESREQ output for a single SCLK cycle when any value is written to the reset status
register.
29.3.5
Core clock control
To enable the software to control the relative frequency of the core clock (CLK) and the bus
clock (HCLK), the system controller provides access to the HCLKDIVSEL[2:0] output
through the system control register (namely the 3 bit field HCLKDivSel of the SCCTRL
register).
These output signals are intended for use by the clock generation logic to control the
generation of the CLK/HCLK clock source and the HCLKEN input. To prevent spurious
change of the CLK/HCLK clock ratio, the HCLKDIVSEL output is only allowed to change
when the system mode control state machine is in a stable state, that is, the actual system
mode matches the required system mode.
29.3.6
Watchdog module clock enable generation
Enable signals are generated by the system controller to allow the watchdog module to be
clocked at a rate that is independent of the system clock PCLK. In particular, the enable
signals are generated by sampling a free-running, constant frequency input clock (REFCLK)
and generating an active high pulse for a single PCLK clock cycle on each rising edge of the
input clock (REFCLK). Since PCLK is used to sample REFCLK the frequency of PCLK must
be at least double.
The supported module enable signals are:
●
WDCLKEN for the watchdog module clock enable.
The enable signal for the watchdog module is generated from the REFCLK input (24 MHz
crystal clock), as defined in the system control register (SCCTRL).
Additionally, to enable the watchdog module to be clocked directly at the system clock rate, it
is also possible to selectively force the enable outputs high setting to 1 SSCTRL[23]
(WDogEnOv). The watchdog clock enable output can be forced inactive by de-asserting the
WDEN input. The WDEN input is driven low when the processor is in debug state.
320/368
Doc ID 022640 Rev 3
RM0319
30
Power, reset and clock control
Power, reset and clock control
This chapter provides a functional description of the system power, reset and clock control
features.
For details on programming the related registers, refer to the System Controller (SC) and
System Configuration registers (MISC) sections of the following companion document:
●
30.1
RM0321: SPEAr320S address map and registers
System control state machine
The system control state machine manages power consumption by controlling the clock
sources of the system clock (SYS_CLK). It has four system operation states:
●
SLEEP
●
DOZE (reset state)
●
SLOW
●
NORMAL
Switching between system operation states is software-controlled except for SLEEP to
DOZE which is activated only by a hardware event.
Three selections are mainly available:
●
Main oscillator: directly 24 MHz or its ratio (1:2, 1:4, 1:16 or 1:32)
●
RTC oscillator: if present it is 32.768 kHz
●
PLL1 Frequency: generated from the main oscillator
The state machine is controlled using three mode control bits (ModeCtrl[2:0]) in the system
control register (SCCTRL), which define the required system operating mode. The mode
control bits control the modes:
●
1xx If the most significant bit (MSB) is set then the system moves into NORMAL mode.
●
01x If the MSB is not set and the next MSB is set then the system moves into SLOW
mode.
●
001 If only the least significant bit (LSB) is set then the system moves into DOZE mode.
●
000 If none of the mode control bits are set the system moves into SLEEP mode.
When the required operating mode has been defined by software writing to the
ModeCtrl[2:0] bits in the system control register(SCCTRL) the state machine moves to the
required operating mode without further software interaction.
The current system mode can read by software from the ModeStatus[3:0] bits in the
SCCTRL register.
If the nPOR input is activated, the state machine and the required operating mode in the
system control register are set to DOZE. If the PRESETn input is activated, the system
mode control state machine does not change mode but the required operating mode is set
to DOZE in the system control register.
Doc ID 022640 Rev 3
321/368
Power, reset and clock control
RM0319
Figure 108. System operation states
Consumption
NORMAL
IRQ, FIQ
and
RESET
SLOW
Dynamic
Frequency
DOZE
Scaling
SLEEP
Performance
Table 115. Power state for synchronous DRAM system (DRAM clocked by PLL1)
State
ARM
ARM clock
DRAM
Possible code
execution memory
SLEEP
Hibernate
Off
Self refresh
None
DOZE
Running
Running
RTC Osc
MAIN Osc(PLL off)
Self refresh
Self refresh
Internal memory
Internal memory
SLOW
Running
MAIN Osc.(PLLoff)
Self refresh
Internal memory
NORMAL
Running
PLL1 (Up to 333 MHz)
Active
Internal memory and
external DRAM
Table 116. Power state for asynchronous DRAM system (DRAM clocked by PLL2)
State
ARM
ARM clock
DRAM
Possible code
execution memory
SLEEP
Hibernate
Hibernate
off
off
Self refresh
Active
None
None
Running
RTC Osc.
Self refresh
Internal memory
Running
RTC Osc
Active
Internal memory and
external DRAM
Running
MAIN Osc. (PLL off)
Self refresh
Internal memory
Running
MAIN Osc.(PLL off)
Active
Internal memory and
external DRAM
DOZE
322/368
Doc ID 022640 Rev 3
RM0319
Power, reset and clock control
Table 116. Power state for asynchronous DRAM system (DRAM clocked by PLL2)
State
SLOW
NORMAL
30.1.1
ARM
ARM clock
DRAM
Possible code
execution memory
MAIN Osc. (PLL off)
Self refresh
Internal memory
MAIN Osc.(PLL off)
Active
Internal memory and
external DRAM
PLL1 (Up to 333 MHz)
Active
Internal memory and
exernal DRAM
Running
Running
SLEEP
During this mode the system clocks, HCLK and CLK, are disabled and the system controller
clock SCLK is driven from a low speed oscillator (nominally 32 768 Hz). When either a FIQ
or an IRQ interrupt is activated (through the VIC) the system moves into the DOZE mode.
Additionally, the required operating mode in the system control register automatically
changes from SLEEP to DOZE.
In SLEEP state, the clock is not provided to CPU. This state maximizes power saving.
The system controller clock is driven by the last selected source in DOZE mode, it could be
RTC or main oscillator.
On interrupt request, normal (IRQ) or fast (FIQ) request, the CPU wakes up and goes in
DOZE. Few clock cycles (less than five) are required for this transition.
To reduce power consumption, it is recommended to switch off all clocks to modules which
are not used for wake-up purpose (see Section 30.4: Reset).
Interrupts enabling wake-up from SLEEP state are:
●
Ethernet MAC: It is possible to disable the clock to Ethernet MAC
(PERIP1_CLK_ENB.gmac_clkenb) using the external clock provided by PHY MAC.
●
USB Device: In this case, the clock to USB Device cannot be switched off
(PERIP1_CLK_ENB.usbdev_clkenb) and AHB since the resume interrupt is registered
by HCLK.
●
RTC: All clocks to internal modules can be switched off (except for RTC).
●
GPIO: All clocks to internal modules can be switched off (except for GPIO).
●
TIMER: All timers if timer clock is not switched off (see PERIP1_CLK_ENB register for
timer clock sources)
Note:
Sleep state is only activated if SCCTRL Mode Ctrl is set to zero and processor is in Wait-forInterrupt state.
30.1.2
DOZE (reset state)
DOZE is the first state activated after reset.
During this mode the system clocks, HCLK and CLK, and the system controller clock SCLK
are driven from the output of crystal oscillator (24 MHz) or low frequency oscillator (32 kHz).
The system controller moves into SLEEP mode from DOZE mode only when none of the
mode control bits are set and the processor is in Wait-for-interrupt state. If SLOW mode or
NORMAL mode is required the system moves into the XTAL control transition state to
initialize the crystal oscillator.
Doc ID 022640 Rev 3
323/368
Power, reset and clock control
RM0319
In this state, the CPU is running with the RTC or the main oscillator, according to the bit set
in PRPH_CLK_CFG.rtc_disable. After reset, the main oscillator is selected (which allows to
have systems without RTC oscillator).
You can select a division of main oscillator frequency through
CORE_CLK_CFG.osci24_div_en to enable and CORE_CLK_CFG.osci24_div_ratio bits to
select ratio.
Using the RTC oscillator, you can achieve better results in terms of power consumption.
Code execution
In DOZE state, the code has to run from internal memory (Boot ROM, internal RAM, Cache
and TCM if present) or from external memory Serial Flash or DRAM. To run from DRAM,
you must use PLL2 for the SDRAM controller (asynchronous DRAM mode) with a frequency
higher than the minimum supported by used DRAM.
It is also recommended, if wake-up response allows it, to put DDR in self refresh mode.
The transition to another state is software-controlled through SCCTRL ModeCtrl bits. It
allows to program directly in NORMAL state, in this case the hardware will execute
transitioning as several steps. Less than five clock cycles are required to change from one
state to another.
30.1.3
SLOW
In SLOW mode, both the system clocks and the system controller clock are driven from the
output of the crystal oscillator.
If NORMAL mode is required, the system moves into the “PLL control” transition state. If
neither the SLOW nor the NORMAL mode control bits are set, the system moves into the
“Switch from XTAL” transition state.
You can select a division of the main oscillator frequency through
CORE_CLK_CFG.osci24_div_en to enable and CORE_CLK_CFG.osci24_div_ratio bits to
select ratio.
In SLOW state, there are the same constrains of DOZE state for code execution.
The transition to another state is software-controlled through SCCTRL Mode Ctrl bits.
It is allowed to program DOZE state and nothing else is required.
To go in NORMAL state, you must program PLL1 at the desired frequency. PLL has to be
stable before switching to NORMAL. To achieve this, two ways are possible:
30.1.4
●
By software, verifying PLL1_CTR.pll_lock bit, applicable if Dither is disabled
(PLL1_CTR.pll_control1.DitherMode).
●
By hardware. An intermediate hardware state waits for PLL stabilization using a preprogrammed delay, use SCPLLCTRL.PllTime for time delay with SCPLLCTRL PllOver
disabled. See formula in Section 30.4: Reset to calculate the proper delay.
NORMAL
In NORMAL mode, both the system clocks and the system controller clock are driven from
the output of PLL.
If the NORMAL mode control bit is not set, then the system moves into the “Switch from
PLL” transition state.
324/368
Doc ID 022640 Rev 3
RM0319
Power, reset and clock control
In NORMAL state, you can apply the power management techniques described below.
Table 117. Techniques applicable in NORMAL state
Technique
Synchronous DRAM
Asynchronous DRAM
Dynamic Frequency Scalling (DFS)
Denied
Allowed
Dynamic Clock Switching (DCS)
Allowed
Allowed
Combining DFC+DCS
Denied
Allowed
Statically Frequency Selection and Clock
Allowed
Switching OFF
Doc ID 022640 Rev 3
Allowed
325/368
Power, reset and clock control
30.2
RM0319
Transition states
When switching from one system operation state to another the system passes through
certain transition states as shwon in Figure 109
Figure 109. System control state machine transitions
PLLSW
NORMAL
NORMAL
SW to
PLL
SW From
PLL
PLLON ||(PLLTIMEEN && PLL Timeout)
PLL
CTL
PLL SW
NORMAL
SLOW
XTAL SW
SLOW&NORMAL
SW to
XTAL
XTALON ||(XTALTIMEEN && XTAL Timeout)
XTAL
CTL
SW From
XTAL
nPOR
SLOW |
NORMAL
XTALSW
DOZE
DOZE&SLOW&NORMAL
&STANDBYWFI
IRQ | FIQ
SLEEP
30.2.1
XTAL control transition state, XTAL CTL
XTAL control transition state is used to initialize the crystal oscillator. While in this state, both
the system clocks and the system controller clock are driven from a low-frequency oscillator.
The system moves into the Switch to XTAL transition state when the crystal oscillator output
is stable. This is indicated when either the XTAL timeout defined in the XTAL control register
expires (when the XTALTIMEEN input is valid) or by the XTALON input being set to logic ‘1’.
30.2.2
Switch to XTAL transition state, SW TO XTAL
Switch to XTAL transition state is used to initiate the switching of the system clock source
from the slow speed oscillator to the crystal oscillator. The system moves into the SLOW
326/368
Doc ID 022640 Rev 3
RM0319
Power, reset and clock control
mode when the XTALSW input is set to logic ‘1’, to indicate that the clock switching is
complete.
30.2.3
Switch from XTAL transition state (SW from XTAL)
The “Switch from XTAL” transition state is entered when moving from SLOW to DOZE mode.
It is used to initiate the switching of the system clock source from the crystal oscillator to the
low speed oscillator. The system moves into the DOZE mode when the XTALSW input is set
to PLL control transition state (PLL CTL)
The “PLL control” transition state is used to initialize the PLL. While in this state, both the
system clocks and the system controller clock are driven by the output of the crystal
oscillator.
The system moves then into the “Switch to PLL” transition state when the PLL timeout
defined in the PLL control register (SCPLLCTRL register) expires (when the PLLTIMEEN
input is invalid) and if the PLLON input is set to logic1.
30.2.4
Switch to PLL transition state (SW to PLL)
The “Switch to PLL” transition state is used to initiate the switching of the system clock
source from the crystal oscillator to the PLL output.
The system moves then into the NORMAL mode when the PLLSW input is set to logic ‘1’ to
indicate that the clock switching is complete.
30.2.5
Switch from PLL transition state (SW from PLL)
The “Switch from PLL” transition state is entered when moving from NORMAL to SLOW
mode. It is used to initiate the switching of the clock sources from the PLL to the crystal
oscillator output.
The system moves then into the SLOW mode when the PLLSW input is set to logic ‘0’ to
indicate that the clock switching is complete.
Doc ID 022640 Rev 3
327/368
Power, reset and clock control
30.3
RM0319
Power management techniques
Power consumption is an important design aspect of any modern system. Power
management techniques allow power consumption to be reduced by ensuring that system
performance is adapted dynamically to the application requirements.
30.3.1
Dynamic Frequency Scaling (applicable in NORMAL state)
This technique uses dynamic selection of the optimal frequency to allow a task to be
performed in the required amount of time.
As described in Section 30.5: Clock control, PLL1 (Sys) provides frequency to the system.
By default, DRAM is driven by PLL1, this mode is called synchronous DRAM. It is also
possible to use PLL2 to drive DRAM, this mode is called asynchronous DRAM.
In asynchronous DRAM mode, you can change the system frequency (PLL1) without
affecting DRAM operations. For this reason, to apply the Dynamic Frequency Scaling
System, the asynchronous DRAM mode must be used.
Frequency changes are applied with a small delay, due to the PLL lock time.
Changing the PLL frequency in NORMAL state generates undesirable frequency
overshoot/undershoot. To avoid this, it is better to switch to Slow state, change PLL
frequency, disable Dithering (if enabled), wait for the PLLlock signal, switch again to Normal
mode and enable Dithering again (if it was originally enabled).
There are two ways to wait PLL stabilization, by software and by hardware, see
Section 30.1.3: SLOW for details.
30.3.2
Dynamic clock switching
Like DFS, Dynamic Clock Switching (DCS) is a power-management technique aimed at
reducing active power consumption of a device, whereas DFS change frequency of all
modules using CLK_Pll1 signal. DCS could switch OFF completely the clock of an unused
modules and quickly switch ON when its use is required.
With this technique the processor, or system, could run at maximum frequency maintained
highest performances.
To have maximum flexibility DCS is fully software controlled through PERIP1_CLK_ENB
register.
DCS is useful when a real-time application is waiting for an event. The system can switch
OFF clock of modules not used and enable them, with a low latency, when needed.
Modules that support this feature are shown in Table 118
Table 118. Modules supporting DCS technique
328/368
Module
Module
Module
C3
GPIO
SPI
SDRAM
RTC
UART
USB 2.0 host
ADC
ARM subsystem
USB 2.0 device
Timer 2
ARM
Ethernet
Timer 3
Doc ID 022640 Rev 3
RM0319
Power, reset and clock control
Table 118. Modules supporting DCS technique
30.3.3
Module
Module
Module
Flash serial (SMI)
IrDA
PLL1
Internal ROM
JPEG codec
PLL2
DMA
I2C
PLL3
Combining frequency scalling and clock techniques
In NORMAL state, the best active power saving is obtained by combining the power
management techniques previously described.
These techniques reduce the power consumption of a device allowing a fast response to a
critical task (that can be performed always at maximum frequency, if needed).
30.3.4
Statically frequency selection and clock switching OFF
With this technique, you can define statically, based on performance defined in the
manufacturing process, the frequency and activate only the modules requested by the
application.
This technique is easier from the designer’s point of view for software development and
offers a well known consumption. It is recommended that when the performance required is
without critical task, it is sufficient to guarantee an average power computation.
This technique should be applied when a constant consumption is requested by the system.
It is useful when USB ports are not requested switch of USB PLL (PLL3) and peripheral
clock could be attached to PLL1, with the right prescaler.
Also PLL2 should be OFF in synchronous mode.
Doc ID 022640 Rev 3
329/368
Power, reset and clock control
30.4
Reset
30.4.1
Main reset (MRESET)
RM0319
To ensure the system starts correctly after power on, the external reset pin MRESET must
be held low by hardware until the power supply is stable.
30.4.2
Software reset control
A system reset can be generated by writing any value to the system status register
(SCSYSSTAT).
The on-chip peripherals can be reset individually by writing to the corresponding control bits
in the MISC PERIP1_SOF_RST and MISC RAS_SOF_RST registers.
30.4.3
Watchdog reset
Refer to Section 34: Watchdog timer (WDT).
30.5
Clock control
The clock control system block generates all the internal clock signals and controls the
system reset. Several synthesizers provide different frequencies for the various IPs. It
provides fully programmable control of clock and reset signals for all the slave blocks
allowing sophisticated power management
30.5.1
Main clocks
The main clocks, at default operating frequency, are:
●
SYS_CLK and CPU_CLK @ up to 333 MHz for the system and CPU
●
HCLK @ 166 MHz for the AHB Bus and AHB peripherals
●
PCLK @ 83 MHz for the APB Bus and APB peripherals
●
DDR_CLK @ 100-333 MHz for DDR memory interface
●
CLK12MHz, CLK30MHz and CLK48MHz for the USB controllers
The above frequencies are the maximum allowed values. All these clocks are generated by
three PLLs as shown in Figure 110 and Figure 111.
See also Section 30.5.2: PLL programming.
330/368
Doc ID 022640 Rev 3
RM0319
Power, reset and clock control
Figure 110. Main clock sources
System controller
system state control
logic
CPU_CLK
RTC_XI
up to 32.768 kHz
32 KHz
OSC
RTC_XO
up to 333 MHz
up to 24 MHz
M2
MISC PLL1_CTR register (0x08)
MISC PLL1_FREQ register(0x0C)
MISC PLL1_MOD register (0x10)
MISC PLL_CLK _CFG
register (0x20)
SYS_CLK
(input to prescalers
for HCLK and PCLK)
PL_CLK4
M1
PLL1
MISC CORE_CLK_CFG register (0x24)
MCLK_XI
24 MHz
OSC
MCLK_XO
Divider /2, /4, /16, /32
CLK12 MHz
CLK30 MHz
CLK48 MHz
PLL3
MISC PLL_CLK _CFG
register (0x20)
MISC PLL2_CTR register (0x14)
MISC PLL2_FREQ register(0x18)
MISC PLL2_MOD register (0x1C)
M3
PLL2
PL_CLK3
100- 333 MHz
PLL2_CLKOUT
(input to multiplexer
for DDR_CLK)
The following registers in the MISC register block are used to configure and control the
clocks:
●
PLL1_CTR, PLL1_FRQ, PLL1_MOD,
●
PLL2_CTR, PLL2_FRQ, PLL2_MOD,
●
PLL_CLK_CFG, CORE_CLK_CFG,
●
PRPH_CLK_CFG, PERIP1_CLK_ENB, RAS_CLK_ENB,
●
PRSC1_CLK_CFG, PRSC2_CLK_CFG, PRSC3_CLK_CFG, AMEM_CFG_CTRL,
●
IRDA_CLK_SYNT_CFG, UART0_CLK_CFG, MAC_CLK_SYNT_CFG,
RAS_CLK_SYNT1_CFG, RAS_CLK_SYNT2_CFG, RAS_CLK_SYNT3_CFG,
RAS_CLK_SYNT4_CFG
The following registers in the system controller register block are also used to configure and
control the clocks (see also Chapter 29: System controller (SYSCTR)):
●
SCCTRL SCXTALCTRL, SCPLLCTRL
Doc ID 022640 Rev 3
331/368
Power, reset and clock control
30.5.2
RM0319
PLL programming
The system clocks are generated by three PLLs:
●
PLL1: fully programmable; it generates the clock for the CPU and AMBA system.
●
PLL2: fully programmable; it generates the clock for the RAS block and the DDR
multiport controller (MPMC).
Both PLL1 and PLL2 offer an EMI reduction mode (dithering mode) than can replace all
traditional drop methods for electro-magnetic interference.
●
PLL3: it generates the clock for USB controllers. Unlike PLL2 and PLL2, PLL3 is not
programmable.
PLL clock source selection
The clock sources for the PLLs are:
●
PLL1: 24 MHz oscillator or PL_CLK4 pin
●
PLL2: 24 MHz oscillator or PL_CLK3 pin
The clock sources for PLL1 and PLL2 can be selected by software. At reset the 24 MHz
source is selected.
●
PLL3: 24 MHz oscillator. Since PLL3 is not programmable, if the USB functionality is
required in the application, then the external oscillator frequency must be 24 MHz.
PLL operating modes (normal, dithered, fractional-N synthesis)
PLL1 and PLL2 can work in three operating modes:
●
Normal mode (Dither-off mode): the PLL behaves as a normal PLL.
●
Fractional-N synthesis mode: with this mode it is possible to select VCO frequencies
that are not integer multiples of the reference frequency.
●
Dither-on mode:
–
Double side modulation: a triangular wave is added to the VCO frequency.
–
Single side modulation: similar to double side modulation, with the difference that
the modulation is only subtracting from the main frequency.
To reduce the electromagnetic emission both PLL1 and PLL2 can be programmed to work in
dithered mode.
When the dithered mode is enabled, the PLL output clock is modulated and the frequency
assumes a triangular shape. In this way the clock power spectrum is spread on a small
range (programmable) of frequencies decreasing the emission power peak.
This method replaces the other traditional methods of EMI reduction, as filtering, ferrite
beads, chokes, adding power layers and ground planes to PCBs, metal shielding, allowing
sensible cost saving for customers.
30.5.3
Clock distribution scheme
Core clock control
To enable the software to control the relative frequency of the core clock (SYS_CLK) and the
bus clock (HCLK), the software can program the HCLKDivSel bits in the SCCTRL register).
332/368
Doc ID 022640 Rev 3
RM0319
Power, reset and clock control
Figure 111. DDR_CLK, HCLK and PCLK clock distribution
CORE_CLK_CFG register
hclk_divsel bits
SYS_CLK
Divider /1, /2, /3, /4
CORE_CLK_CFG register
pclk_ratio_lwsp bits
HCLK
Divider /1, /2, /3, /4
CORE_CLK_CFG register
pclk_ratio_basc bits
Divider /1, /2, /3, /4
CORE_CLK_CFG register
pclk_ratio_arm1 bits
Divider /1, /2, /3, /4
PCLK for low
speed subsystem
PCLK for basic
subsystem
PCLK for ARM
subsystem
PLL_CLK_CFG register
mctr_clk_sel bits
HCLK
2x HCLK
M4
DDR_CLK
PLL2_CLKOUT
Doc ID 022640 Rev 3
333/368
Power, reset and clock control
●
RM0319
SYS_CLK and CLK_CPU clock sources
When the system switches from NORMAL, SLOW, DOZE or SLEEP mode, the system clock
source is selected automatically (multiplexer M2 in Figure 110 on page 331.).
Depending on the state machine (see Chapter 29: System controller (SYSCTR) for full
details) the system clock (SYS_CLK) and the CPU clock (CPU_CLK) can be derived from
the following sources:
●
External oscillator (24 MHz) (divided by 2, 4, 16 or 32)
●
PLL1 (up to 333 MHz)
●
RTC crystal (32.768 kHz)
The selection depends also on the value programmed in the rtc_disable bit in the MISC
PRPH_CLK_CFG register.
By programming the miscellaneous registers, you can define:
●
the output frequency of PLL1 (used in NORMAL mode)
●
the divider for 24 MHz oscillator (used in SLOW and DOZE mode).
Table 119. System source control selection
Mode
30.5.4
rtc_disable
System clock source (output of M2 multiplexer (see Figure 110
bit
on page 331)
NORMAL
x
PLL1
SLOW
x
24 MHz oscillator clock divided by 2, 4, 16 or 32
DOZE
0
CLK32KHz
DOZE
1
24 MHz oscillator clock divided by 2, 4, 16 or 32
SLEEP
0
CLK32KHz
SLEEP
1
24 MHz oscillator clock divided by 2, 4, 16 or 32
DDR memory controller clock
The multiport memory controller (MPMC) uses the HCLK to synchronize the internal bus
access and uses another clock source, which can be chosen between PLL1 or PLL2
(setting the MISC registers), for the external DDR memory interface.
The two clock domains can be synchronous or asynchronous. Having the two clock domains
asynchronous offers more flexibility in the system definition, but also adds more latency due
to the resynchronization stages.
Synchronous mode
In synchronous mode we can configure both the CPU and the external DDR memory to run
at 333 MHz. In this case, the SYS_CLK provides the clock to all the internal blocks (CPU
and system bus) and to the DDR external memory.
Asynchronous mode
We can configure the CPU to run at 333 MHz and the HCLK bus to run at 166 MHz, but
have the external DDR memory running at 266 MHz to reduce the board cost. In this
example, PLL1 provides the clock to all the internal blocks (CPU and system bus) while
PLL2 provides the frequency to the external memory.
334/368
Doc ID 022640 Rev 3
RM0319
Power, reset and clock control
Refer to the description of the AMEM_CFG_CTRL register and the ahbX_fifo_type_reg
parameter in the MPMC chapter for configuration details.
de
Table 120. DDR_CLK source selection
System clock source
(output of M4 multiplexer (see Figure 111)
mctr_clk_sel bits
30.5.5
000
HCLK
001
2x HCLK
010
Reserved
011
PLL2
1xx
Reserved
Bus clocks
Through the miscellaneous CORE_CLK_CFG and PRPH_CLK_CFG registers, you can
define:
●
the ratio between the CPU clock and its HCLK
●
the ratio between the AHB and the APB clock
●
the source for the peripheral clock
By default, this is derived from the fixed frequency of 48 MHz avoiding problems in case that
the bus clock changes value because of different system states or because of different PLL
settings.
Peripheral clock gating
The miscellaneous PERIP1_CLK_ENB register provides control bits allowing the software
to enable or disable the clock for each peripheral for sophisticated power management.
30.5.6
Watchdog module clock enable generation
Enable signals are generated by the system controller to allow the watchdog module to be
clocked at a rate that is independent of the system clock SYS_CLK. In particular, the enable
signals are generated by sampling a free-running, constant frequency input clock and
generating an active high pulse for a single SYS_CLK clock cycle on each rising edge of the
input clock.
The supported module enable signals are:
●
WDCLKEN for the watchdog module clock enable.
The enable signal for the watchdog module is generated from the REFCLK input, as defined
by the WDogEnOv bit in the system control register (SCCTRL).
30.5.7
RAS clock
The CLCD, SDIO and FSMC IPs, present in the RAS subsystem, operate at HCLK clock
frequency. While SPP, SSP, CAN, PWM and UART operate at PCLK clock frequency. Other
clock frequencies are shown in the diagram below.
Doc ID 022640 Rev 3
335/368
Power, reset and clock control
RM0319
Figure 112. Clock schematic of RAS subsystem
RAS_CLK_SYNT3
PLL2_CLKOUT
I2S
SPP
CLCD
SSP1,2
MMCSD/
SDIO
CAN0,1
FSMC
PWM
CLK48MHz
RAS_CLK_SYNT4
CLK48MHz
HCLK
PL_GPIO97/MII_TXCLK
PL_GPIO90/MII_RXCLK
MACB
RAS_CLK_SYNT1
UART2/3/4/
5/6
UART_RS485
PLL2_CLKOUT
336/368
Doc ID 022640 Rev 3
PCLK
RAS_CLK_SYNT2
RM0319
30.5.8
Power, reset and clock control
Clock synthesizer
The clock synthesizer is a digital signal generator. It is used to perform a fractional clock
divider.
Note:
Refer to “Auxiliary clock synthesizer register bit assignments” table in RM0321: SPEAr320S
address map and registers, for the register fields mentioned in this section.
Giving an input clock with frequency Fin and two integers X (synt_xdiv field of programming
register) and Y (synt_xdiv field), the clock synthesizer generates a new clock with frequency:
X⎞
⎛
Fout 1 = ⎜ Fin ∗ ⎟ / 2
Y ⎠
⎝
with X<Y/2 if the post divider is enabled (synt_clkout_sel field is cleared); while:
X⎞
⎛
Fout 2 = ⎜ Fin ∗ ⎟
Y ⎠
⎝
with X <Y/2, if post divider is disabled (synt_clkout_sel field is set).
The clock synthesizer is based on Y-modulo counter incremented by X. After reset the
counter value is zero and it increments of X every input clock cycle. If N is the number of
input clock cycle the output is high when:
N ∗X ≥Y
The counter loads the value Y-NX a clock cycle after that it is verified the previous condition,
the output become low and the process iterates again. If Y is a multiple of X:
N=
Y
X
is a constant and the output period is
Tout = Tin ∗ N = Tin ∗
Y
X
The output frequency is given by the Fout formula above.
When Y/X is not an integer value, the output period swings between N and N+1 times the
input clock period, with N the integer part of Y/X.
This means that the maximum period drift is of one input clock period.
For example:
With Fout= 40 MHz, Fin= 333 MHz the synthesizer parameters are:
X=40 and Y=333
This means that the output clock period is on average: Tout = 8.325 * Tin.
The output period will be 8 or 9 times the input clock period:
Tout = 8 * 3 = 24 ns and Tout = 9 * 3 = 27 ns
The maximum output period drift is 27-24 =3 ns.
Doc ID 022640 Rev 3
337/368
Power, reset and clock control
RM0319
Since the output clock is high for one input clock cycle, the duty cycle is:
⎛X⎞
DC (%) = ⎜ ⎟ ⋅100
⎝Y ⎠
If the post divider by two is enabled, the DC is 50%; in this case the output frequency is
given by the Fout formula above.
It can be shown that the period drift in this case is twice the input clock period.
338/368
Doc ID 022640 Rev 3
RM0319
31
System configuration registers (MISC)
System configuration registers (MISC)
This document focuses on MISC generic information.
For technical details about the programmable registers related to the MISC, refer to the
MISC registers in the following companion document:
●
31.1
RM0321: SPEAr320S address map and registers
Overview
The miscellaneous block is an array of registers which manages the SoC main configuration
schemes and controls all basic device functionalities. The figure below shows the top view
of the MISC block.
SPEAr320S registers are described in detail in the manual RM0321: SPEAr320S address
map and registers.
Figure 113. MISC block top view
Reg #0
Reg #1
APB
Status
APB I/F
Control
Commands
Reg #n
Miscellaneous Registers
Doc ID 022640 Rev 3
339/368
Reconfigurable array subsystem (RASCFG)
32
RM0319
Reconfigurable array subsystem (RASCFG)
This chapter provides a general introduction the RAS subsystem and programming the RAS
registers.
For further technical details about the RASCFG registers, refer the following companion
document:
●
32.1
RM0321: SPEAr320S address map and registers
Overview
The SPEAr320S reconfigurable array subsystem includes the following interfaces:
32.2
●
FSMC: NAND Flash interface (8/16 bits, 4 chip selects) (see Section 8: Parallel NAND
Flash controller (FSMC))
●
EMI: External memory interface (16 data bits, 24 address bits and 4 chip selects) (see
Section 9: External memory interface (EMI))
●
CAN0, CAN1: 2 x CAN2.0 interfaces (see Section 15: Controller area network ports
(CAN))
●
MACB: 2 x Ethernet MAC modules with 1 MII or 2 RMII interfaces (see Section 13: Fast
Ethernet ports (RMII0/RMII1/MII1))
●
UART1, 2, 3, 4, 5, 6: 6 x UARTs with SW flow control (baud rate up to 7 Mbps) (see
Section 16: Asynchronous serial ports (UART))
●
UART_RS485: UART/RS485 interface (see Section 16: Asynchronous serial ports
(UART))
●
CLCD: LCD interface (up to 1024x768, 24 bits LCD controller, TFT and STN panels)
(see Section 24: LCD display controller (CLCD)
●
TOUCHSCREEN: Touchscreen block (see Section 25: Touchscreen interface
(TOUCHSCREEN)))
●
SSP1,2: 2 x independent SPI ports (see Section 18: Synchronous serial ports (SSP))
●
PL-GPIO: PL_GPIOs with interrupt capabilities (see Section 23: Extended general
purpose I/O (PL_GPIO)
●
Memory Card Controller: SD/SDIO/MMC interface supporting SPI, SD1, SD4 and
SD8 mode (see Section 14: MMC-SD card/SDIO controller)
●
SPP: Standard parallel port (SPP device implementation) (see Section 20: Legacy
IEEE 1284 parallel port (SPP))
●
PWM: Up to 4 PWM outputs (see Section 38: Pulse width modulators (PWM)
●
I2C1,2: 2 x I2C interfaces (see Section 17: I2C bus ports (I2C))
●
I2S: I2S input-output for voice or modem interfaces (see Section 27: Digital audio port
(I2S)
I/O multiplexing scheme configuration
The RASCFG registers are used to select the I/O multiplexing scheme as described in the
datasheet pin description tables.
340/368
Doc ID 022640 Rev 3
RM0319
Reconfigurable array subsystem (RASCFG)
There are four legacy configuration modes that select a specific group of IPs and I/O
functions. These are:
●
Mode 1: HMI automation mode
●
Mode 2: MII automation networking mode
●
Mode 3: Expanded automation mode
●
Mode 4: Printer mode
Alternatively you can configure Extended mode which allows you to flexibly choose the
available functions of each IP individually.
The configuration mode is selected as follows:
To use any of four legacy mode:
1.
Clear bit 0 in the RASCFG Extended Control register
2.
Select configuration mode by writing the corresponding value in Mode_Sel bits [2:0] for
the RASCFG Control Register
To use Extended mode:
1.
Set bit 1 in the RAS Extended Control register.
Select the functions for each pin individually by programming the RAS_iosel_regx registers.
32.2.1
Alternate functions
The I/O functions of other IPs can be enable by setting the corresponding bits of the
RAS_Select_Reg register
These alternate function IPs are:
32.3
●
IrDA
●
I2C0
●
UART0
●
MII0 Ethernet
●
GPT1, GPT2 timers
●
6 basGPIOs.
Bootstrap register configuration
The bootstrap register allows you to read the values latched on the H[7:0] and B[3:0] boot
pins. Refer to the boot pins description table in the datasheet for meaning of the B[3:0]
values. The H[7:0] pins are user definable strapping options.
32.4
RAS interrupts
Table 121. RAS Interrupt assignment
Generic RAS interrupt
VIC IRQ
IPs
3
1
CAN, UART, RS485, SSP, MACB, I2C
2
30
PL_GPIO, I2S
Doc ID 022640 Rev 3
341/368
Reconfigurable array subsystem (RASCFG)
RM0319
Table 121. RAS Interrupt assignment (continued)
Generic RAS interrupt
VIC IRQ
IPs
1
29
SDIO
0
28
CLCD, SPP, EMI
For a decription of how to use the PL_GPIO interrupts, refer to Section 23: Extended
general purpose I/O (PL_GPIO) on page 265
342/368
Doc ID 022640 Rev 3
RM0319
33
Vectored interrupt controller (VIC)
Vectored interrupt controller (VIC)
This chapter focuses on VIC functionality and operation.
For technical details about the programmable registers related to the VIC, refer to the VIC
registers in the following companion document:
●
33.1
RM0321: SPEAr320S address map and registers
Overview
Acting as an interrupt controller, the VIC determines the source that is requesting service
and where its interrupt service routine (ISR) is loaded, doing that in hardware. In particular,
the VIC supplies the starting address, or vector address, of the ISR corresponding to the
highest priority requesting interrupt source.
Note:
Refer to Appendix A: Interrupt request table for a complete list of SPEAr320S external
interrupts.
33.2
Main features
●
Support for 32 standard interrupt sources
●
Generation of both fast interrupt request (FIQ) and interrupt request (IRQ), according to
ARM system operation. IRQ is used for general interrupts, whereas FIQ is intended for
fast, low-latency interrupt handling. In particular, using a single FIQ source at a time in
the system provides interrupt latency reduction, because the ISR can be directly
executed without determining the source of the interrupt.
●
Support for 16 vectored interrupts (IRQ only)
●
Hardware interrupt priority, where FIQ interrupt has the highest priority, followed by
vectored IRQ interrupts (from vector 0 to vector 15), and then non-vectored IRQ
interrupts with the lowest priority.
●
Interrupt masking
●
Interrupts request status and raw interrupt status (prior to masking)
●
Software interrupt generation
●
An AHB slave to connect to the CPU
The interrupt inputs must be level sensitive, active HIGH, and held asserted until the
interrupt service routine clears the interrupt. Edge-triggered interrupts are not compatible.
The interrupt inputs do not have to be synchronous to HCLK.
Note:
The VIC does not handle interrupt sources with transient behaviour.
Doc ID 022640 Rev 3
343/368
Vectored interrupt controller (VIC)
33.3
RM0319
Functional description
Figure 114 shows the block diagram of VIC.
Figure 114. VIC block diagram
Non-vectored FIQ
interrupt logic
FIQSTATUS
[31:0]
Non-vectored IRQ
interrupt logic
IRQSTATUS
[31:0]
VICINTSOURCE[31:0]
Interrupt
request
logic
IRQ0
Vector interrupt 0
VectAddr0
IRQ1
Vector interrupt 1
VectAddr1
IRQn
VectAddrn
Vector interrupt 15
nVICRQIN
VICVECTADDRIN
VICVECTADDROUT
nVICFIQIN
nVICFIQ
IRQ15
VectAddr15
IRQ
vector
address
and
priority
logic
nVICIRQ
IRQ
Daisy
Chain
VectAddrIn
VectAddrOut
HCLK
HSELVIC
HRESETn
HTRANS
AHB slave
interface
HWRITE
HREADYIN
HREADYOUT
HRESP[1:0]
HADDR[11:2]
HRDATA[31:0]
HWDATA[31:0]
HSIZE[2:0]
HPROT
Control logic
33.3.1
Interrupt request logic
The interrupt request logic block receives the interrupt requests from peripherals and
combines them with the software interrupt requests (see Section 33.3.6). After that, it masks
out the requests that are not enabled (through the VICINTENABLE register) and routes the
others to either IRQSTATUS or FIQSTATUS depending on VICINTSELECT.
FIQ interrupts have the highest priority, followed by vectored interrupts (0-15) and, finally,
non vectored interrupts.
33.3.2
Non-vectored FIQ interrupt logic
The non-vectored FIQ interrupt logic block generates the FIQ interrupt signal by combining
the FIQ interrupt requests coming from the interrupt request logic and any requests from
daisy-chained interrupt controllers.
344/368
Doc ID 022640 Rev 3
RM0319
33.3.3
Vectored interrupt controller (VIC)
Non-vectored IRQ interrupt logic
The non-vectored IRQ interrupt logic block generates the non-vectored IRQ interrupt signal
by combining the non-vectored IRQ interrupt requests coming from the interrupt request
logic. This signal is then sent to the IRQ vector address and priority logic.
33.3.4
Vectored interrupts
As depicted in Figure 114, there are 16 vectored interrupt blocks within the VIC. Each
vectored interrupt block receives the IRQ interrupt requests from the interrupt request logic
block and generates a vectored IRQ interrupt.
In particular, a vectored IRQ interrupt is generated only if:
●
It is enabled in the VICINTENABLE register.
●
It is set to generate an IRQ interrupt in the VICINTSELECT register.
●
It is enabled in the relevant VICVECTCNTL register.
●
It is currently the highest requesting interrupt (vector 0 to vector 15, highest to lowest).
Besides, each vectored interrupt block is associated to the 32-bit address of the ISR to be
executed. These ISR addresses are mapped in the VICVECTADDRi (with i = 0...15)
registers. The VICVECTADDR register contains the ISR address for the currently active IRQ
interrupt.
33.3.5
Interrupt priority logic
The interrupt priority logic block organizes the following requests according to their priority:
●
Non-vectored interrupt requests
●
Vectored interrupt requests
●
External interrupt requests
If the interrupt is not currently being serviced, the highest priority request generates an IRQ
interrupt.
Note:
External interrupt is not being used in SPEAr320S.
33.3.6
Software interrupts
The software can control the source interrupt lines to generate software interrupts
(VICSOFTINT register). These interrupts are generated before interrupt masking within the
interrupt request logic block, in the same way as external source interrupts.
It is possible to clear software interrupts by writing to the VICSOFTINTCLEAR register. This
is normally done at the end of the ISR.
33.3.7
AHB slave interface
The AHB slave interface block connects the VIC to the CPU through the AHB bus.
Doc ID 022640 Rev 3
345/368
Vectored interrupt controller (VIC)
RM0319
33.4
Interrupts
33.4.1
Reducing interrupt latency
The interrupt latency depends on the type of interrupt, see Table 122.
Table 122. Interrupt latency for different types of interrupts
Worst case (cycles)
Event
FIQ
IRQ
IRQ (reduced latency)
Interrupt synchronization
3
3
3
Worst case interrupt disable period
7
10
10
Entry to first instruction
2
2
2
Nesting, assuming single-state AHB
-
10
-
Load IRQ vector to PC
-
-
5
Total
12
25
20
To reduce interrupt latency, you can re-enable the IRQ interrupts in the processor after the
ISR is entered, so the current ISR is interrupted, and the higher priority ISR is executed. The
VIC then only enables a higher priority interrupt than the interrupt currently being serviced. If
a higher priority interrupt goes active, the current ISR is interrupted and the higher-priority
ISR is executed. Before the interrupt enable bits in the processor can be re-enabled, the LR
and SPSR must be saved, preferably on a software stack. When the ISR is exited, you must
disable the interrupts, reload the LR and SPSR, and write to the vector address register,
VICVECTADDR.
346/368
Doc ID 022640 Rev 3
RM0319
34
Watchdog timer (WDT)
Watchdog timer (WDT)
This chapter describes the functionality and operation of the watchdog timer.
For technical details about the programmable registers related to the watchdog timer, refer
to the watchdog timer registers in the following companion document:
●
34.1
RM0321: SPEAr320S address map and registers
Overview
Within its basic subsystem, the device provides an ARM watchdog module. It consists of a
32-bit down counter with a programmable time-out interval that has the capability to
generate an interrupt and a reset signal on timing out. The watchdog module is intended to
be used to apply a reset to a system in the event of a software failure.
34.2
34.3
Main features
●
32-bit down counter with a programmable time-out interval
●
Separate watchdog clock with its clock enable for flexible control of the time-out interval
●
Interrupt output generation on time-out
●
Reset signal generation on time-out, if the interrupt from the previous time-out remains
unserviced by software
●
Lock register to protect registers from being altered by runaway software
●
Identification registers that uniquely identify the watchdog module. These can be used
by software to automatically configure itself.
●
An APB slave allowing access to all registers
Functional description
Figure 115 shows a simplified block diagram of the watchdog module.
Doc ID 022640 Rev 3
347/368
Watchdog timer (WDT)
RM0319
Figure 115. Watchdog module block diagram
Free Running
Counter
AMBA APB Interface
AMBA APB
Signals
ID Registers
Lock Register
Integration Test Register
Load Register Control Register
32-bit down counter
WDOGCLK
Value Register
WDOGCLKEN
Interrupt and
Reset generation
WDOGINT
WDOGRES
WDOGRESn
Raw Interrupt Status Register
Masked Interrupt Status Register
Interrupt Clear Register
34.3.1
AMBA APB interface
The AMBA APB interface block provides an APB slave which allows to accesses to all
registers in the watchdog module.
In particular, the lock register (WdogLock) controls the enabling of write accesses to all the
other registers in order to ensure software cannot unintentionally disable the watchdog
module operation.
34.3.2
Free running counter
The free running counter block contains the 32-bit down counter functionality (including
related registers), and the logic to generate the interrupt and reset signal outputs.
The counter and the interrupt/reset logic are clocked independently, as detailed in
Section 34.4 on page 348.
34.4
Clocks
The watchdog module uses two different input clocks:
●
The clock of the APB bus (PCLK signal), which is used to clock the Watchdog module
registers through APB bus.
●
The external WDOGCLK signal which, in conjunction with its clock enable,
WGDOGCLKEN, is used to clock the Watchdog module counter and its associated
interrupt and reset generation logic. In particular, the watchdog counter only
decrements on a rising edge of WDOGCLK when WDOGCLKEN is HIGH.
The following constraints must be observed in the relationship between the two clocks:
●
The rising edge of WDOGCLK must be synchronous and balanced with the rising edge
of PCLK,
●
The WDOGCLK frequency cannot be greater than the PCLK frequency.
From the constraints above and depending on the relationship between WDOGCLK and
WDOGCLKEN, the watchdog module counter is decremented on different ways
summarized in Table 123.
348/368
Doc ID 022640 Rev 3
RM0319
Watchdog timer (WDT)
Table 123. Watchdog module counter decremented
Clocks
WDOGCLKEN
Behaviour
HIGH
The counter is decremented on every WDOGCLK edge
Pulsed
The counter is decremented on every WDGCLKEN rising edge.
HIGH
The counter is decremented on every WDOGCLK rising edge
Pulsed
The counter is decremented on every WDGCLKEN rising edge.
WDOGCLK equals PCLK
WDOGCLK less than PCLK
Doc ID 022640 Rev 3
349/368
Real-time clock (RTC)
35
RM0319
Real-time clock (RTC)
This chapter focuses on RTC functionality and operation.
For technical details about the programmable registers related to the RTC, refer to the RTC
registers in the following companion document:
●
35.1
RM0321: SPEAr320S address map and registers
Overview
The RTC is an APB slave block that keeps track of the real time of day. It also functions as
an alarm and a calendar. The time is displayed in 24-hour format, and time/calendar values
are stored in binary-coded decimal format.
35.2
350/368
Main features
●
Time-of-day clock in 24-hour mode
●
Calendar
●
Alarm capability
●
Two general purpose registers
●
Supports self-isolation mode, which allows RTC to work even if power is not supplied to
the rest of the device.
Doc ID 022640 Rev 3
RM0319
36
DMA controller (DMAC)
DMA controller (DMAC)
This chapter focuses on DMAC functionality and operation.
For technical details about the programmable registers related to the DMAC, refer to the
DMAC registers in the following companion document:
●
36.1
RM0321: SPEAr320S address map and registers
Overview
The DMA controller is able to service up to 8 independent DMA channels for sequential data
transfers between single source and destination (memory-to-memory, memory-toperipheral, peripheral-to-memory, and peripheral-to-peripheral).
36.2
Main features
●
Each DMA channel can support a unidirectional transfer, with internal 16-words FIFO
per channel.
●
16 peripheral DMA request lines, where each peripheral connected to the DMAC can
assert either a single DMA request or a Burst DMA request (with programmable size to
increase data transfer effectiveness).
●
Hardware priority (0 the highest to 7 the lowest) for each DMA channel to manage
requests from more than 1 channel at the same time.
●
Scatter or gather DMA support through the use of linked lists.
●
An AHB slave acting as programming interface to access to DMA control registers
●
Two AHB masters for data transfer following a DMA request
●
32-bit AHB master bus width, supporting 8-/16-/32-bit wide transactions
●
Support both big-endian and little-endian (little endian is the default mode on DMAC
reset)
●
Separate and combined DMA error and DMA count interrupt requests, with three
interrupt request signals (DMACINTTC, DMACINTERR and DMACINTR)
●
Interrupt masking and raw interrupt status (prior to masking)
Doc ID 022640 Rev 3
351/368
DMA controller (DMAC)
36.3
RM0319
Functional description
Figure 116. DMAC block diagram
CHANNEL 0
A
R
B
I
T
E
R
AHB
MAST
I/F
CHANNEL 1
A
R
B
I
T
E
R
AHB AHB MASTER 2
MAST
I/F
DMACCLR[15:0]
DMACTC[15:0]
DMA
REQUEST
AND
RESPONSE
BLOCK
DMACSREQ[15:0]
DMACBREQ[15:0]
DMACLSREQ[15:0]
DMACLBREQ[15:0]
AHB
BUS
AHB MASTER
1
AHB SLAVE
INTERFACE
CHANNEL 7
For the DMA channel assignment, please refer to the DMA_CHN_CFG register description
in the System configuration registers (MISC) section of RM0321: SPEAr320S address map
and registers.
36.3.1
Signal interfaces
The DMAC directly interfaces with the signals summarized in Table 124. A functional
diagram of these signal interfaces is given in Figure 117.
Figure 117. DMAC signal interface diagram
AMBA AHB BUS
AHB master #1
DMA response
AHB master #2
DMAC
DMA request
AHB slave
Interrupt request
(to interrupt controller)
352/368
Doc ID 022640 Rev 3
RM0319
DMA controller (DMAC)
Table 124. DMAC signal interface
Group
Signal name
Direction
Size
(bit)
Description
DMACBREQ
Input
16
DMA burst transfer request
DMACLBREQ
Input
16
DMA last burst transfer request
DMACSREQ
Input
16
DMA single transfer request
DMACLSREQ
Input
16
DMA last single transfer request
DMACCLR
Output
16
DMA request clear
DMACTC
Output
16
DMA terminal count (transaction complete)
DMACINTERR
Output
1
DMA error interrupt request
DMACINTTC
Output
1
DMA terminal count interrupt request
DMACINTR
Output
1
DMA interrupt request. This signal
combines the DMACINTERR and
DMACINTTC requests.
DMA request
DMA response
Interrupt
request
36.3.2
AHB Master #1 -
Input/Output -
See AMBA specification
AHB Master #2 -
Input/Output -
See AMBA specification
AHB Slave
Input/Output -
See AMBA specification
-
AHB slave interface
The AHB slave interface block allows to connect the DMAC to the AMBA AHB bus.
In particular, the AHB slave interface properly decodes read and write commands on the
AHB bus providing access to DMAC memory-mapped registers for configuration purposes.
It is worth mentioning that the AHB slave and the two AHB masters use the same clock,
HCLK, which means that they are all synchronous.
36.3.3
AHB master interfaces
The DMAC contains two full independent AHB masters for data transfer. This feature allows,
for example, DMAC to transfer data directly from the memory connected to AHB port #1 to
any AHB peripheral connected to AHB port #2. Besides, it enables transactions between the
DMAC and any APB peripheral to occur independently of transactions on AHB bus 1.
Each AHB master is capable of dealing with all types of AHB transactions, including:
●
Split, retry and error responses from AHB slaves. If a peripheral performs a split or
retry, the DMAC stalls and waits until the transaction can complete.
●
Locked transfers for source and destination of each stream.
●
Setting of protection bits for transfers on each stream.
The two AHB masters are connected to buses of the same width (the default is a 32-bit bus).
However, source and destination transfers can be with different widths, and can be the same
width or narrower than the physical bus width. In this case, the DMAC packs or unpacks
data as appropriate.
Doc ID 022640 Rev 3
353/368
DMA controller (DMAC)
RM0319
Note:
The DMAC uses HSIZE1 or HSIZE2 to indicate the width of a transfer, and if this fails to
match the width expected by the peripheral, then the peripheral can assert an error on
HRESP1 or HRESP2, respectively.
36.3.4
DMA interface
The DMA interface provides the set of signals (listed in Table 124) to be used by a generic
peripheral. Over this interface the connected peripheral is allowed to request a data transfer
(through DMA request signals), and DMA is able to reply to peripheral both acknowledging
the request and stating whether the data transfer has been completed (through DMA
response signals).
Each DMA request/response signal is 16-bit wide, allowing then DMAC connectivity with up
to 16 peripherals.
Note:
Some peripherals do not use all the signals provided by the DMA interface. In this case,
response signals that are not required can be left unconnected, and request signals that are
not required can be tied to low.
Because of DMA interface, the DMAC enables four different data transfer types:
●
Memory-to-memory
●
Memory-to-peripheral
●
Peripheral-to-memory
●
Peripheral-to-peripheral,
where each transfer can have either the peripheral or the DMAC as the flow controller,
resulting then in eight different scenarios (see FlowCntrl field in DMAC configuration
register).
36.3.5
Scatter/gather
As mentioned before, the DMAC provides for scatter/gather DMA through the use of a series
of linked lists, allowing then source and destination of any DMA transfer to occupy noncontiguous areas in memory.
Each item of a linked list, referred to as Linked List Item (LLI), controls the transfer of one
block of data (the packet) over a DMA channel, and then optionally loads another LLI to
continue the DMA operation (in case of more than a packet transfer), or stops the DMA
stream.
An LLI consists of four words:
●
the source address of the data to be transferred over a DMA channel,
●
the destination address of the data to be transferred over a DMA channel,
●
the pointer to next LLI (set to 0 in case current LLI is the last in its linked list),
●
a control word containing information about the corresponding DMA channel.
The first LLI of each linked list is programmed into the DMAC using the DMA channel
registers, namely DMACCnSrcAddr, DMACCnDestAddr, DMACCnLLI and DMACCnControl.
Then, these registers are updated as soon as a complete packet has been transferred over
the DMA channel by following the linked list.
Note:
354/368
The DMAC configuration is not part of the LLI description, but allows to configure the
relevant DMA channel.
Doc ID 022640 Rev 3
RM0319
36.3.6
36.4
DMA controller (DMAC)
How to program the DMAC for scatter/gather DMA
1.
Write to memory all the LLIs for the complete DMA transfer (source address,
destination address, pointer to next LLI and control word for each LLI).
2.
Choose a free DMA channel with the required priority (0 the highest to 7 the lowest).
3.
Write the first LLI, previously written to memory (step 1), to the relevant DMA channel
in the DMAC, setting the corresponding registers (DMACCnSrcAddr,
DMACCnDestAddr, DMACCnLLI and DMACCnControl).
4.
Write the DMA channel configuration information to the DMAC Configuration and set its
channel enable bit (E, bit [0]).
5.
An interrupt can be generated at the end of each LLI setting the terminal count bit (I, bit
[31]) in the DMACCnControl register. Then, the interrupt request must be serviced and
the relevant bit of the IntTCClear field in the DMACIntTCClear register must be set to
clear the interrupt.
Interrupts
The DMAC allows to generate an interrupt to the ARM processor:
●
In case of a DMA error (assertion of an error response on the AHB during data transfer)
●
At the end of DMA transfer (terminal count reached 0)
The corresponding interrupt request signals are listed in Table 124. The combined
DMACINTR signal (generated as an OR function of the individual request signals,
DMACINTERR and DMACINTTC) can be useful in low performance system with a few
interrupt controller request inputs. As depicted in Figure 118, in this case only the
DMACINTR request signal coming from DMAC is directly connected to the interrupt
controller, but both the DMACIntErrStatus and the DMACIntTCStatus registers, in
conjunction with the DMACIntStatus register, must be read to find the actual source of the
interrupt.
Figure 118. DMAC-to-interrupt controller connection
DMAC
DMACINTR
Interrupt
controller
nIRQ
nFIQ
ARM
Processor
In any case the error and terminal count interrupts can be masked at the DMAC-level by
programming the relevant bits (IE and ITC, respectively) on the relevant
DMACCnConfiguration channel register. In order to get interrupt status prior to masking, the
DMACRawIntErrStatus and the DMACRawIntTCStatus registers are provided by the DMAC.
Doc ID 022640 Rev 3
355/368
DMA controller (DMAC)
36.4.1
356/368
RM0319
How to operate single combined DMACINTR interrupt request signal
1.
Wait until the combined interrupt request from the DMAC (DMACINTR) goes active.
2.
Read the interrupt controller status register and determine whether the source of the
request was the DMAC.
3.
Read the DMACIntStatus register to determine the DMA channel that generated the
interrupt. If more than one request is active (that is, more than one bit are set in the
IntStatus field), it is recommended to check the highest priority channels first (0, 1, 2
and so on).
4.
Read the DMACIntTCStatus register to determine whether the interrupt was generated
because of the end of the transfer or because an error occurred. If the bit
corresponding to the DMA channel (from step #3) in the field IntTCStatus is set, the
data transfer has been completed › step #6.
5.
Read the DMACIntErrStatus register to determine whether the interrupt was generated
because of the end of the transfer or because an error occurred. If the bit
corresponding to the DMA channel (from step #3) in the field IntErrorStatus is set, an
error occurred › step #6
6.
Set the relevant bit in the DMACIntTCClear register or in the DMACIntErrClr register,
respectively, to clear the interrupt request.
Doc ID 022640 Rev 3
RM0319
37
General purpose timers (GPT)
General purpose timers (GPT)
This chapter focuses on GPT functionality and operation.
For technical details about the programmable registers related to the GPT, refer to the GPT
registers in the following companion document:
●
37.1
RM0321: SPEAr320S address map and registers
Overview
General purpose timers can be used for precise timing measurement and for measurement
of frequency of any input signal. They are essentially counters that increment based on the
clock cycle and the timer prescaler. An application can monitor these counters to determine
how much time has elapsed. GPT can have timer and capture mode capabilities.
SPEAr320S provides six general purpose timers (GPTs) grouped in three timer pairs GPT0,
GPT1 and GPT2.
37.2
Main features
●
Each timer pair consists of 2 channels, each channel consists of a programmable 16-bit
counter and a dedicated 8-bit timer clock prescaler.
●
The programmable prescaler performs a clock division by 1 up to 256, and different
input frequencies can be chosen through SPEAr320S configuration registers (so we
can synthesize, for instance, a frequency range from 3.96 Hz to 48 MHz).
●
Three modes of operation are available for each timer channel:
–
Auto-reload mode
–
Single-shot mode
–
Capture mode
Doc ID 022640 Rev 3
357/368
General purpose timers (GPT)
37.3
RM0319
Functional description
Figure 119. GPT block diagram
From MISC
PRPH_CLK_CFG
register
Timer0_1 Prescaler
/1 ../256
Timer0 clock
(up to 48 MHz)
Timer0_1
16-bit counter
Timer0_1
16-bit compare
register
Timer0_2 Prescaler
/1 ../256
Timer0_2
16-bit counter
GPT timer 1_2 interrupt (IRQ3)
(IRQ3 to VIC interrupt controller)
Timer0_2
16-bit compare
register
GPT0
From MISC
PRPH_CLK_CFG
register
GPT timer 0_1 interrupt (IRQ2)
(IRQ2 to VIC interrupt controller)
Control
Timer1_1 Prescaler
/1 ../256
Timer1 clock
(up to 48 MHz)
Timer1_1
16-bit counter
TMR_CLK1 pin
GPT timer 1_1 interrupt (IRQ4)
(IRQ4 to VIC interrupt controller)
Timer1_1
16-bit compare
register
Timer1_2 Prescaler
Timer1_1
16-bit capture
register
TMR_CPTR1 pin
Control
/1 ../256
Timer1_2
16-bit counter
TMR_CLK2 pin
GPT timer 1_2 interrupt
(IRQ5 to VIC interrupt controller)
Timer1_2
16-bit compare
register
Timer1_2
16-bit capture
register
GPT1
From MISC
PRPH_CLK_CFG
register
TMR_CPTR2 pin
Timer2_1 Prescaler
/1 ../256
Timer2 clock
(up to 48 MHz)
Timer2_1
16-bit counter
TMR_CLK3 pin
GPT timer 2_1 interrupt
(IRQ6 to VIC interrupt controller)
Timer2_1
16-bit compare
register
Timer2_2 Prescaler
/1 ../256
Timer2_1
16-bit capture
register
TMR_CPTR3 pin
Control
Timer2_2
16-bit counter
TMR_CLK4 pin
Timer2_2
16-bit compare
register
Timer2_2
16-bit capture
register
GPT2
37.3.1
GPT timer 2_2 interrupt
(IRQ7 to VIC interrupt controller)
TMR_CPTR4 pin
External pin connection
Subsystem
Timer pair
Base address Signals
Ball
Usage
Note
CPU
GPT0
0xF000_0000
-
-
Not available
358/368
-
Doc ID 022640 Rev 3
RM0319
Subsystem
General purpose timers (GPT)
Timer pair
GPT1
Base address Signals
Ball
Usage
TMR_CLK1
E9
TMR_CLK2
A10
Output signal which toggles
when TIMER generates an
interrupt. (OUTPUT
generated for both
TIMER/CAPTURE MODE)
TMR_CPTR1
C10
TMR_CPTR2
B11
TMR_CLK3
B10
TMR_CLK4
A11
TMR_CPTR3
C11
TMR_CPTR4
A12
0xFC80_0000
Basic
GPT2
37.4
Note
These Input pins are used
to receive the signals for
which the measurement of
timing is done. (Used only
in CAPTURE MODE)
See
PL_GPIO
Multiplexing
scheme in
Output signal which toggles datasheet to
when TIMER generates an verify the
interrupt. (OUTPUT
availability
generated for both
TIMER/CAPTURE MODE)
0xFCB0_0000
These Input pins are used
to receive the signals for
which the measurement of
timing is done. (Used only
in CAPTURE MODE)
Operation
When the ENABLE bit in TIMER_CONTROL register is set, the GPT is enabled. Its counter
is cleared and then starts incrementing. When the counter reaches a pre-set compare value
(in TIMER_COMPARE register), two different modes of operation are available (selected by
the MODE bit in the TIMER_CONTROL register):
●
Auto-reload mode: when the counter reaches the compare register value, an interrupt
source is activated, the counter is automatically cleared and restarts incrementing. The
process is repeated until the timer is disabled.
●
Single-shot mode: when the counter reaches the compare register value, an interrupt
source is activated, the counter is stopped and the GPT is disabled.
Capture mode
This function is used for the measurement of input timing signals. When a rising transition
occurs on the TMR_CPTRx pins, the current counter value is stored in the rising edge
capture register (TIMER_REDG_CAPTx) and a dedicated interrupt source is activated.
In the same way, when a falling edge transition occurs on the TMR_CPTRx input pins the
current counter value is stored in the falling edge capture register and another interrupt
source is also activated. Software can then read the value stored in the two capture
registers and compute the time interval from the rising to falling edge (or vice versa).
Doc ID 022640 Rev 3
359/368
Pulse width modulators (PWM)
38
RM0319
Pulse width modulators (PWM)
This chapter focuses on PWM functionality and operation.
For technical details about the programmable registers related to the PWM, refer to the
PWM registers in the following companion document:
●
38.1
RM0321: SPEAr320S address map and registers
Overview
The PWM is a pulse-width modulation (PWM) timer module with four independent channels
(PWM1, PWM2, PWM3, and PWM4). All four channels are functionally identical. Using a
16-bit counter, each PWM channel generates a rectangular output pulse with programmable
duty factor (0 to 100%) and frequency.
38.2
360/368
Main features
●
Four independent PWM channels
●
Prescaler (see Control_Reg_x register) to define the input clock frequency to each
timer.
●
Programmable duty factor from 0 to 100% ( through Duty_Reg_x register)
●
Programmable pulse frequency (through Period_Reg_x register)
●
APB slave interface for programming register
●
APB clock (PCLK ~ 83 MHz) as the source clock for prescaler
Doc ID 022640 Rev 3
RM0319
Interrupt request table
Appendix A
Interrupt request table
Table 125. Interrupt requests
Interrupt sources
IRQ #
Reserved
0
CAN0/1, UART1/2/3/4/5/6, RS485, SSP1/2,
MACB, I2C1/2 (Generic Interrupt #3 from RAS)
1
GPT Timer 0_1
2
GPT Timer 0_2
3
GPT Timer 1_1
4
GPT Timer 1_2
5
GPT Timer 2_1
6
GPT Timer 2_2
7
DMA
8
SMI
9
RTC
10
GPIO
11
WD
12
DDR Controller
13
System Error
14
RCG
15
JPEG
16
IrDA
17
ADC
18
UART0
19
SSP0
20
2
I C0
21
MII0 Ethernet MAC / Power Management Event
22
MII0 Ethernet MAC
23
USB Device
24
USB Host 1 OHCI
25
USB Host EHCI
26
USB Host 2 OHCI
27
CLCD, SPP, EMI (Generic Interrupt #0 from RAS) 28
MMC-SD/SDIO (Generic Interrupt #1 from RAS)
29
Doc ID 022640 Rev 3
361/368
Interrupt request table
RM0319
Table 125. Interrupt requests (continued)
Interrupt sources
IRQ #
PL_GPIO, I2S (Generic Interrupt #2 from RAS)
(1)
30
C3
31
1. PL_GPIO interrupts must be disabled if I2S interrupts are used and vice versa.
362/368
Doc ID 022640 Rev 3
RM0319
Acronyms
Appendix B
Acronyms
The table below contains the acronyms and abbreviations used in this document.
Table 126. Acronyms
Acronym
Definition
ADC
Analog to digital convertor
AFE
Analog front end
ALU
Arithmetic logic unit
ASIC
Application specific integrated circuit
AS
Application subsystem
AMBA
Advanced microcontroller bus architecture
AHB
AMBA high speed bus
APB
Advanced peripheral bus
AES
Advanced encryption standard
BIST
Built-In self test
BS
Basic subsystem
CMOS
Complimentary metal-oxide semiconductor
CRC
Cyclic redundancy check
CBC
Cipher block chaining
CTR
Counter
DAC
Digital to analog convertor
DLL
Data link layer
DMA
Direct memory access
DDR
Double data rate
DES
Data encryption standard
EMI
Extended memory interface
ECB
Electronic code book
FIFO
First-in-first-out
FPGA
Field programmable gate array
FSMC
Flexible static memory controller
GPIO
General purpose input output
HMI
Human-machine interface
HS
High speed subsystem
IEEE
Institute of electrical and electronics engineers
ISO
Isochronous; International organization for standardization
JPEG
Joint photographic experts group
Doc ID 022640 Rev 3
363/368
Acronyms
RM0319
Table 126. Acronyms (continued)
364/368
Acronym
Definition
JTAG
Joint test action group
LIFO
Last-in-first-out
LS
Low speed subsystem
LSB
Least significant bit
MAC
Media access control
MCU
Microcontroller unit
MII
Media independent interface
MMC
MultiMedia card
MMU
Memory management unit
MSB
Most significant bit
MD5
Message digest 5
PHY
Physical layer
PWM
Pulse width modulator
RAM
Random access memory
RAS
Reconfigurable array subsystem
RF
Radio frequency
RFU
Reserved for future use
RISC
Reduced instruction set computing
RMII
Reduced media independent interface
ROM
Read only memory
RTC
Real time clock
RX
Receive
SD
Secure digital
SDIO
Secure digital input/output
SoC
System-on-chip
SPEAr
Structured processor enhanced architecture
SMI
Serial memory interface
SSP
Synchronous serial port
SPP
Standard parallel port
SHA-1
Secure hash algorithm
TCM
Tightly coupled memory
TX
Transmit
UART
Universal asynchronous receiver transmitter
USB
Universal serial bus
Doc ID 022640 Rev 3
RM0319
Acronyms
Table 126. Acronyms (continued)
Acronym
Definition
VIC
Vectored interrupt controller
WDT
Watchdog timer
Doc ID 022640 Rev 3
365/368
Reference documentation
Appendix C
366/368
RM0319
Reference documentation
●
ARM926EJ-S – Technical reference manual
●
AMBA specification (ARM IHI 0011A), rev. 2.0
●
USB 2.0 specification
●
OHCI specification
●
EHCI specification
●
ISO/IEC 10918-1 (International Organization for Standardization)
Doc ID 022640 Rev 3
RM0319
Document revision history
Document revision history
Table 128. Document revision history
Date
10-Apr-2012
Revision
Changes
1
Initial release
07-Sep-2012
2
Section 4: Multilayer interconnect matrix (BUSMATRIX):
Updated Table 28 and Table 29 on page 77
Added note on DMA port connections
Section 5: BootROM added UART0 and Ethernet boot modes. Updated
description of bypass mode.
Section 15: Controller area network ports (CAN) added Figure 71 and
Figure 72
Section 17: I2C bus ports (I2C):
Updated Section 17.4.2 DMA and Section 17.3.3 Master mode
REFCLK specified as crystal clock in Section 29.3.6: Watchdog module
clock enable generation
Section 10.3.2: EHCI host controller: updated description for 2
downstream ports
Added Section 21.3.3: High-resolution mode
19-Oct-2012
3
Updated FIRDA Section 19.3.2: Demodulation unit
Updated BootROM Section 5.6.7: Ethernet boot
4
Changed references to EMI_ACK signal to EMI_WAIT# Section 9:
External memory interface (EMI) and updated Example 2 in Section 9.4:
Programming examples.
Updated Table 123: Watchdog module counter decremented: changed
the two lines “The counter is decremented on every second WDOGCLK
rising edge” with “The counter is decremented on every WDGCLKEN
rising edge”.
Updated Section 29.3.6: Watchdog module clock enable generation.
23-Nov-2012
Doc ID 022640 Rev 4
367/368
RM0319
Please Read Carefully:
Information in this document is provided solely in connection with ST products. STMicroelectronics NV and its subsidiaries (“ST”) reserve the
right to make changes, corrections, modifications or improvements, to this document, and the products and services described herein at any
time, without notice.
All ST products are sold pursuant to ST’s terms and conditions of sale.
Purchasers are solely responsible for the choice, selection and use of the ST products and services described herein, and ST assumes no
liability whatsoever relating to the choice, selection or use of the ST products and services described herein.
No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. If any part of this
document refers to any third party products or services it shall not be deemed a license grant by ST for the use of such third party products
or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoever of such
third party products or services or any intellectual property contained therein.
UNLESS OTHERWISE SET FORTH IN ST’S TERMS AND CONDITIONS OF SALE ST DISCLAIMS ANY EXPRESS OR IMPLIED
WARRANTY WITH RESPECT TO THE USE AND/OR SALE OF ST PRODUCTS INCLUDING WITHOUT LIMITATION IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS
OF ANY JURISDICTION), OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
UNLESS EXPRESSLY APPROVED IN WRITING BY TWO AUTHORIZED ST REPRESENTATIVES, ST PRODUCTS ARE NOT
RECOMMENDED, AUTHORIZED OR WARRANTED FOR USE IN MILITARY, AIR CRAFT, SPACE, LIFE SAVING, OR LIFE SUSTAINING
APPLICATIONS, NOR IN PRODUCTS OR SYSTEMS WHERE FAILURE OR MALFUNCTION MAY RESULT IN PERSONAL INJURY,
DEATH, OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE. ST PRODUCTS WHICH ARE NOT SPECIFIED AS "AUTOMOTIVE
GRADE" MAY ONLY BE USED IN AUTOMOTIVE APPLICATIONS AT USER’S OWN RISK.
Resale of ST products with provisions different from the statements and/or technical features set forth in this document shall immediately void
any warranty granted by ST for the ST product or service described herein and shall not create or extend in any manner whatsoever, any
liability of ST.
ST and the ST logo are trademarks or registered trademarks of ST in various countries.
Information in this document supersedes and replaces all information previously supplied.
The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners.
© 2012 STMicroelectronics - All rights reserved
STMicroelectronics group of companies
Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan Malaysia - Malta - Morocco - Philippines - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States of America
www.st.com
368/368
Doc ID 022640 Rev 3