TN104_Rutenberg_Sinai_090805

Freescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product
or service names are the property of their respective owners. © Freescale Semiconductor, Inc. 2005
Tel Aviv
PowerQuicc™
Software Drivers and
Configuration Tools
Orna Zadok Rutenberg - Software Chief Architect
Shlomo Sinai - Marketing Product Manager

2
Orna Zadok Rutenberg - Software Chief Architect,
Agenda
• MPC836x Drivers
• Hardware - MPC8360 Board Design
• Configuration Tool – QUICC Engine Utility
 Short marketing overview
 Configuration method

3
MPC836x Software
• Complete driver package consists of
 Platform drivers
 QE drivers

4
MPC836x DriversMPC836x Drivers
MCCMCCMCCMCC
TDMTDMTDMTDM
SS7SS7SS7SS7
HDLCHDLCHDLCHDLC
SEC 2.0 EncryptionSEC 2.0 EncryptionSEC 2.0 EncryptionSEC 2.0 Encryption
3-DES3-DES3-DES3-DES
DESDESDESDES
AESAESAESAES
HMACHMACHMACHMAC
SHA1SHA1SHA1SHA1
SHA256SHA256SHA256SHA256
ARC4ARC4ARC4ARC4
IPSECIPSECIPSECIPSEC
RNDRNDRNDRND
CryptoAPICryptoAPICryptoAPICryptoAPI
TRNSTRNSTRNSTRNS
UCCUCCUCCUCC PCIPCIPCIPCI
BareUSB1.1HostStackBareUSB1.1HostStackBareUSB1.1HostStackBareUSB1.1HostStack
BareUSB1.1DeviceStackBareUSB1.1DeviceStackBareUSB1.1DeviceStackBareUSB1.1DeviceStack
ATMATMATMATM
ATM (MSP) SwitchingATM (MSP) SwitchingATM (MSP) SwitchingATM (MSP) Switching
AAL2AAL2AAL2AAL2 AAL1AAL1
CESCES
AAL1AAL1
CESCES
IMAIMAIMAIMA
AAL5AAL5AAL5AAL5
IMAStackIMAStackIMAStackIMAStack
GETHGETHGETHGETH
POSPOSPOSPOS PPP/ML-PPPPPP/ML-PPPPPP/ML-PPPPPP/ML-PPP
BarePPPStackBarePPPStackBarePPPStackBarePPPStack
UARTUARTUARTUART
QMCQMCQMCQMC
L2L2
SwitchSwitch
L2L2
SwitchSwitch
PCIPCI
DriverDriver
PCIPCI
DriverDriver
MTCMTCMTCMTC
SPISPISPISPI
SPISPI
DriverDriver
SPISPI
DriverDriver
I2CI2CI2CI2C
I2CI2C
DriverDriver
I2CI2C
DriverDriver
HDLCHDLCHDLCHDLC
TRNSTRNSTRNSTRNS
USBUSBUSBUSB
Control ApplicationsControl Applications
RTOS Driven / RTOS IndependentRTOS Driven / RTOS Independent
Control ApplicationsControl Applications
RTOS Driven / RTOS IndependentRTOS Driven / RTOS Independent

5
MPC836x Drivers – Cont.MPC836x Drivers – Cont.
• DDR Memory Controller
• Local Bus controller
• Local Access Window
• IPIC
• e300 MMU
• e300 Caches
• QE Interrupt Controller
• Parallel I/O

6
Drivers Package Features
• Fully modular system drivers and peripheral drivers
• Each driver consists of a complete set of API routines,
supporting the majority of device functionality
• Simple/minimal configuration for quick start
• Preset default configuration values for easy set and run
• Detailed low-level configuration allows for parametric changes
to peripheral functionality
• Interrupt and polling modes for communication peripherals

7
Drivers Package Features – Cont.
• Statistics gathering
• Complete memory management for MPC836x parameters,
tables and BD’s.
• Multiple type memory management supporting MURAM and
external memories.
• Object Oriented design and coding in ‘C’
• OS agnostic
 Provides hooks to ease integration with OS
• Portable
• External hardware independent
• Highly documented API

8
Driver Units
• Initialization – initialization of registers, parameter RAM,
and data structures required by the hardware/firmware
and software modules.
• Runtime – data path – Tx/Rx and related time critical
routines.
• Runtime Control – non data path routines such as on-the-
fly adjustment of controllers and features.
• Exceptions – errors and special events.

9
Application  Driver  Part Initialization and Data Path
ApplicationPartDriver
Rx
Bd
Ring
Create
Frame
Rx
Routines
Rx
Interrupt
Handling
Interrupt
Generation
Rx
Process
Pass
Frame
Delete
Frame
Data Buffers
Management
Tx
Bd
Ring
Init
Routines
Memory
Map
UCC
MCC
SI
IPIC
Initialize
Chip &
Modules
Initialize
Chip &
Modules
Initialize
Chip &
Modules
Initialize
Chip &
Modules
Tx
Routines
Tx
Tx
ConfirmTx
Process
Create
Frame
Delete
Frame

10
Initialization Routines
• Each module has an initialization sequence that typically
consists of the following:
 Configuration routine(s) –
t_Handle MODULE_Config(t_ParamStruct params, uint32 baseAddr);
> Affects driver software only
> Must be called before any other routine for this module.
> The application passes a structure of parameters for the initialization
of a module.
> The driver saves the user defined parameters and returns a handle
(descriptor) for this module.
e_Err MODULE_ConfigAttribute (t_Handle p_Id, type newVal)
> Optional.
> Affects driver software only.
> Called to change driver’s default value

11
Initialization Routines – Cont.
 Initialization routine –
e_Err MODULE_Init(t_Handle p_Id);
called once for each module, for initializing chip registers,
parameters etc.
 Enable routine –
void MODULE_Enable(t_Handle p_Id, e_COMM_MODE_RXTX dir);
when applicable, must be called to activate module.

12
Initialization Routines – cont.
• Some modules have a common routine –
t_Handle MODULE_ConfigAndInit(t_ParamStruct params,
uint32_t baseAddr);
• replacing the sequence of:
 MODULE_Config
 MODULE_ConfigAttribute
 MODULE_Init

13
Sample Usage Flow
Config()Start Init()
Config_
Attribute()
Optional
Enable() ContinueStart
Start ContinueEnable()ConfigAndInit()

14
Runtime Routines – data modes
• Framed Data Mode
 Uses the general frame object
 Typically supported for framed data protocols
 Multi-buffered frames supported
 Full error BD’s support

15
Runtime Routines – data modes – cont.
• Raw Data Mode
 May be used for any protocol if application provides its own
frame implementation
 Accepts a ‘last’ boolean parameter to enable framing in a higher
level
 Better performance when data framing is not required
 Easier integration with RTOS
 Typically used for character based drivers (UART, SPI, etc) and
non-framed protocols (Transparent)

16
Runtime Routines – Transmission
• Framed - User calls Tx routine, passing a formatted data
frame
• Raw - User calls TxData routine, passing a data pointer,
length, and the ‘last buffer in frame’ indication
• User’s callback f_TxConf is either triggered by the driver (at
an un-guaranteed time), or by an explicit user’s call to
ForceTxConf
• Transmit routines are typically non-blocking (with the
exception of some protocols), and not interrupt safe.

17
Runtime Routines – Reception
• Rx routine may be called
 By the driver from within the interrupt handler
 By the user, after indication provided by interrupt handler
 By the user, if polling mode is selected
• User’s callback f_Store is called by the driver for each received
frame (Frame mode) or buffer (Raw mode)
• Driver passes to user all data received so far
• After each frame, user can inform the driver to stop passing
data
• RxData routine, is provided for character drivers such as
UART or SPI

18
Sample Usage Flow
Rx()Rx Signal f_Store()ISR Process
Application Rx() f_Store()
XX_Call()ISR ProcessRx Signal

19
Application to Driver Interface
• Each driver exports a separate set of API routines for
functional manipulation.
• Initialization requires a set of calls including
 Configuration routine(s)
 Initialization routine
 Enable routine
• Runtime, control and exception routines may be called at any
time (after initialization).

20
Driver  Application Interface
• Callback Routines
 Supplied by the application at initialization time as parameters for
initialization routine
 Called by the driver to indicate an event or to pass data
• XX Routines
 Hooks to the RTOS
 Supplied by the application at build time, and called directly by
the drivers
 For example: XX_Malloc, XX_Freeze, etc.

21
Driver Application Communication
ApplicationApplication
DriverDriver
p_Module =Module_Config(p_Param)
(p_Param contains appId)
XX_Routine(appId)
f_Callback(appId)
Module_Routine(p_Module)

22
Primitive application driver interaction
Ethernet ApplicationEthernet Application
Drivers PackageDrivers Package
IPIC LBIUDDRQE-IC MMU PAR-
IO
LAW G-Eth
UCC
HDLC
UCC
HDLC
MCC
HDLC
QMC
ATM
UCC
TRNS
QMC
TRNS
MCC
SS7
MCC
PCI

23
System Layer Driver
• The system driver uses the API of the platform drivers, and
“general” QE driver. It may include initialization of any of:
 MMU
 Caches
 Interrupt controller
 General chip SW
 Local access windows
 Memory controllers extra configuration
 Parallel IO
 General SW modules

24
System Layer Driver
• Optional initialization layer, unique per chip-board-OS
combination
• Creates an additional abstraction layer
• Application may use a specific set of system routines for a
specific system to save the configuration
• A different OS requires a new system driver
• A different Board requires a new system driver

25
Primitive application driver interaction,
now with system layer driver
Ethernet ApplicationEthernet Application
IPIC LBIUDDRQE-IC MMU PAR-
IO
LAW G-Eth
UCC
HDLC
UCC
HDLC
MCC
HDLC
QMC
ATM
UCC
TRNS
QMC
TRNS
MCC
SS7
MCC
PCI
System layer driver

26
Application Responsibilities
• Apart from calling API routines, the user must supply:
 Callback functions, as required by each of the drivers used
 XX routines implementation for all prototypes found in
xx_ext.h
 Interrupt linking enum (e_IntrSrc) to identify each interrupt
source in the system
 Optional – a system layer set of routines
• Fully functional example versions supplied

27
Simple Example
Application
(C file/s containing: API Calls
Callback imp.
XX Routines)
Application
(C file/s containing: API Calls
Callback imp.
XX Routines) xx_intr_ext.hxx_intr_ext.h
intr_map.hintr_map.h
includeAPIXX /
Callbacks
main.cmain.c
xx.cxx.c
XX /
Callbacks
XX Prototypes and interrupt
mapping
XX Prototypes and interrupt
mappingxx_ext.hxx_ext.h
include

28
Object Oriented Approach
• API Objects
 Each “object” in the API is represented by a data structure which
holds the members of the ‘class’
 The methods of a class are API routines which take as first
argument the object’s handle.
• Initialization Routines
 The object configuration routine functions as a constructor
 It returns a handle to the newly created instantiation of the object.
 The object free routine functions as a destructor

29
General Objects – Building Blocks
• The following objects are used by the driver but they are not an
integral part of it. A whole object can be replaced by the user,
providing that the new object has the same interface.
• These objects provide an API that may also be freely used by
the application
 Frame
 Buffer
 Linked list
 Circular queue
 Memory managers
>Slab allocator
>Varied size allocator

30
Memory Mapping
• To comply with the modularity requirement, each module has
its own memory mapped registers structure.
• There is no complete memory map in the drivers package!
• To acquire the memory mapping of a module, an MPC836x
module routine must be called:
• MPC836x_GetModuleBase(t_Handle p_MPC836x, e_ModuleId id);
• e_ModuleId is defined in MPC836x_ext.h and holds enumerations for all modules.

31
Drivers Support In CodeWarrior Environment
• Each module compiles by itself to a linkable library
• Environments contains:
> .mcp files (CW projects)
> .lcf files (link files)
> DFLAGS files
> .cfg (initialization files)
> .a (linkable libraries)
> executables

Tel Aviv
MPC8360 Board Design
Shlomo Sinai
Marketing Product Manager

33
MPC8360E Modular Development System (MDS)
• Power QUICC Platform I/O Board (PIB)
– Advanced TCA form factor
– 4 PMC slots
– Supports MPC8360E and
MPC8349E processor boards
• MPC8360E Processor Board
- PCI add-in standard card form
factor
- Can be used as a standalone
development system
• PCI Module (PCI host)
• Quad OC-3 ATM Module
• T1/E1 Module
• ADSL Module
PQ Platform I/O Board (PIB)
PMC 1 PMC 2 PMC 3 PMC 4
MPC8360E Processor Board
•The MPC8360E Modular Development System consists of the following:

34
Quad OC3 PMC Card
• Quad ATM OC3 PHY’s
• Each PHY supports single/multi PHY
• Each PHY supports 16 bits UTOPIA/POS Level-2
• Signals are sourced from the PMC connectors
(PMC0 or PMC1 IN PIB)
• Standard PMC form factor
• ADTECH connector for protocol testing
Optics
ATM
PHY
Optics
ATM
PHY
Optics
ATM
PHY
Optics
ATM
PHY
ADTECH Connector
PMC0 PMC1
PQ-MDS-QOC3

35
SLIC/SLAC PMC Card
E1/T1 E1/T1 E1/T1 E1/T1
QUAD E1/T1
FRAMER
PMC
E1/T1E1/T1
SLIC/SLAC
PMC
TDM TDM
• PMC mezzanine card form-factor
• 4 E1/T1 channels
• Legerity Line Module Adapter (LMA) interconnection
• PDK (Packet Telephony Development Kit) existing board interconnection
• Full board programmable control
• Over-voltage and Over-current protection

Tel Aviv
QUICC Engine Utility
Marketing Overview
Shlomo Sinai

37
QUICC Engine Utility Goals
• Significantly accelerate time to market, and result in better
performance
• It speed and simplify initialization and configuration of the
QUICC Engine module included with MPC8360E Family
offerings
• Unlock full value of QUICC Engine technology

38
QUICC Engine Utility Features
• Configures of QUICC Engine, supported protocols, microcode &
peripherals drivers API via a user – friendly GUI interface
• Requires only minimal knowledge of hardware, microcode
registers and driver API
• Provides 3 levels of configuration granularity for maximum
flexibility and performance
• Enables configuration of a multi protocol system
• Provides online assistance, generating a collision-free system
configuration
• Provides direct links to pertinent documentation in the User’s
Manual
• Provides automatic alarms, warning and explanation for device
conflicts

39
System Level Overview
C Compiler/LinkerC Compiler/Linker
User applicationUser applicationDevice driver
Library
Device driver
Library
Source code
Legend
ExecutableExecutable DebuggerDebugger
Object
code
Alarm/Warning/Explanation
Register settings
Driver Init (Init calls to
device drivers)
Driver Init (Init calls to
device drivers)
User
3 levels
of Inputs
GUI
Target platform

40
Top down design
• Application
• Protocols
• Pin allocation
• Configuration tool

41
MPC8360E Application Example Configurations
Application UCC1 UCC2 UCC3 UCC4 UCC5 -8 MCC SPI
Node B
Network
Interface Card
ATM
155Mbps
8bit UL2
1000 Base
T on
RGMII or
ATM
155Mbps
8bit UL2
100
Base-T
on MII
Not
Available
UCC5-7
Not
Available
UART on
UCC8
Only
8 x E1s on
TDM A-H
Yes
DSLAM
ATM 16bit
UL2 for
multiple
ADSL port
1000 Base
T on GMII/
RGMII
Not
Available
Not
Available
UCC5-7
Not
Available
UART on
UCC8
Only
4 TDMs
ports
available
but not
used
Yes
SME Router
1000
Base T on
GMII/
RGMII
ATM
155Mbps
8bit UL2
Not
Available
100 Base-
T on MII
4 x RMII
for 4 port
Ethernet
switch
8 x E1s on
TDM A-H
Yes
The QUICC engine pin mux tool has been enhanced from the CPM version
to provide much more flexible pin mux allocation

Tel Aviv
Configuration Method
Shlomo Sinai

43
HW Setup
• Defines HW constrains
• Family dependency

44
Full Screen GUI

45
Registers view
• Details the registers and memory
view (bd’s)
• Designers can access the calculated
values of the driver API
• Screen is viewable any time during
configuration setup
• Designers can force a proprietary
setup on registers

46
QUICC Engine Utility – GUI hierarchy
• Provides 3 levels of configuration:
1) Standard protocol level
2) Hardware & microcode implementation level
3) Driver level API
• Each level provides more granularity of configuration.

47
Level 1 - Standard-level protocol GUI
• Mainly for designers who
understand the protocol but
don’t want to invest time on
setting detailed features
• Lets you consider the protocol
standard basic definition
• Set default values

48
Level 2 - HW & Ucode implementation GUI
• Supports device-specific HW
and uCode implementations
• Provides device parameters to
improve application
implementation

49
Level 3 - Driver API level GUI
• Provides specific driver
features and benefits
• Allows designers to take full
advantage of driver API
strength

50
QUICC Engine Utility feature –
Providing Alarms, warnings and explanation
• A warning—detailing problematic
configuration
- Appears if a defined task causes
an issue, but the device can still
run the application
• A collision alarm—detailing
problematic configuration
- Appears if a defined task causes
an issue that prevents device
setup
• Collisions are checked across different protocols. A comparison is then made
against the device’s available internal resources (e.g., clocks, timers, MURAM etc.)

51
Configuration
Packaging &
Support
Enablement Across the Development Process
Comprehensive Services, Software & Tools
Code
Analysis &
Test
Application
Development
Kernel &
Driver
Development
Board
Bring-up
Hardware
Designs &
Products
• Driver
development
and debug
before silicon
availability
Silicon &
Pre-Silicon
Emulation &
Simulation
• Code quality
assurance
• Coverage testing
• Tracing
• Profiling
• Memory
utilization
monitoring / leak
detection
• Project based
code Mgmt &
build
• User land multi-
tasking/multi-
threaded
debugging
• Ethernet debug
agent
• UI design
• Kernel, package & tool
chain import
• Kernel & rootfs
configuration and build
• Linux OS deployment
and packaging
• Software license
verification
• BSP and driver
implementation
and debugging
• Board HW
diagnostics
• Flash firmware
programming
• Cache memory
• Boot loader
development
CodeTEST
• Silicon
evaluation
• Prototype
development
Abatron BDI2000 / USB TAP / Ethernet TAP
PCS PCS
CodeWarrior Development Studio
ADS/Eval BoardsCW Integrated
Simulators
Technical Support and Services

52
Question & Answer Session
• Q & A

53

TN104_Rutenberg_Sinai_090805

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (15)

Similar to TN104_Rutenberg_Sinai_090805

Similar to TN104_Rutenberg_Sinai_090805 (20)

TN104_Rutenberg_Sinai_090805

Editor's Notes