Introduction to OMAP

Contents What’s OMAP? Roadmap of OMAP OMAP Device Overview HW Architecture of OMAP SW Architecture of OMAP Applications Introduction to DSP/BIOS Bridge Advantage of OMAP platform (summary) 2018/11/20

What’s OMAP? OMAPTM (Open Mobile Application Processor) Platform is comprised of high-performance, power efficient processors, a robust software infrastructure and comprehensive support network for the rapid development of differentiated internet appliances, 2.5G and 3G wireless handsets and PDAs, and other multimedia-enhanced devices OMAP -- Open Mobile Application Processor 2018/11/20

What’s OMAP? ARM core C55 core DSP/BIOS Symbian, WinCE, etc 2018/11/20 OMAP -- Open Mobile Application Processor ARM core C55 core DSP/BIOS Symbian, WinCE, etc 2018/11/20

Roadmap of OMAP 2018/11/20

OMAP Device Overview 2018/11/20

OMAP Device Overview 2018/11/20

OMAP Device Overview 2018/11/20

OMAP Device Overview 2018/11/20

HW Architecture of OMAP (OMAP5910) Contents of this module Overview MPU Subsystem DSP Subsystem Traffic Controller System DMA Controller Interprocessor Communication Similar with OMAP1510, but target for embedded applications. 2018/11/20

HW Architecture of OMAP (OMAP5910) Overview Similar with OMAP1510, but target for embedded applications. 2018/11/20

HW Architecture of OMAP (OMAP5910) Overview MPU (MicroProcessor Unit) Subsystem DSP Subsystem Traffic Controller System DMA Controller Peripherals MPU public peripherals MPU private peripherals DSP public peripherals DSP private peripherals MPU/DSP shared peripherals Since no open documents for OMAP1510 and OMAP161x, we cannot get detail HW architecture of these chips.  Fortunately, there are some reference documents for OMAP5910. Therefore, we use HW architecture of OMAP5910 as a reference to other OMAP chips.  2018/11/20

HW Architecture of OMAP (OMAP5910) Overview MPU Interface DSP MMU Since no open documents for OMAP1510 and OMAP161x, we cannot get detail HW architecture of these chips.  Fortunately, there are some reference documents for OMAP5910. Therefore, we use HW architecture of OMAP5910 as a reference to other OMAP chips.  2018/11/20

HW Architecture of OMAP (OMAP5910) MPU Subsystem The MPU (TI925T) of the OMAP5910 device controls the memory management units (MMUs), the system direct memory access (DMA) controller, the MPU TI peripheral bus (TIPB) bridge, and peripherals. The MPU is the master of the platform, and it has access to the entire 16M bytes of memory space and to the 128K bytes of I/O space of the DSP subsystem. Additionally, the MPU and DSP share access to the internal SRAM and external memory interfaces. Since no open documents for OMAP1510 and OMAP161x, we cannot get detail HW architecture of these chips.  Fortunately, there are some reference documents for OMAP5910. Therefore, we use HW architecture of OMAP5910 as a reference to other OMAP chips.  2018/11/20

HW Architecture of OMAP (OMAP5910) MPU Subsystem The MPU (TI925T) core incorporate with: A coprocessor 15 (CP15) and protection module MPU MMU (Memory Management Unit) A 16K-byte instruction cache A 8K-byte data cache A 17-word write buffer (WB) A local bus interface Since no open documents for OMAP1510 and OMAP161x, we cannot get detail HW architecture of these chips.  Fortunately, there are some reference documents for OMAP5910. Therefore, we use HW architecture of OMAP5910 as a reference to other OMAP chips.  2018/11/20

HW Architecture of OMAP (OMAP5910) MPU Subsystem The following units are controlled by MPU subsystem: MPU Memory Management Unit DSP Memory Management Unit MPU Interface MPU TI Peripheral Bus Bridges The endianism conversion is done in hardware and transparent to users. (The MPU is little endian) MPU subsystem includes embedded trace macrocell (ETM) to provide instruction and data trace capabilities of the TI925T processor. Since no open documents for OMAP1510 and OMAP161x, we cannot get detail HW architecture of these chips.  Fortunately, there are some reference documents for OMAP5910. Therefore, we use HW architecture of OMAP5910 as a reference to other OMAP chips.  2018/11/20

HW architecture of OMAP (OMAP5910) DSP Subsystem The digital signal processor (DSP) subsystem is built around a core processor and peripherals that interface with: The TI925T via the microprocessor unit interface (MPUI) Various standard memories via the external memory interface (EMIF) Various system peripherals via the TI peripheral bus (TIPB) bridge Since no open documents for OMAP1510 and OMAP161x, we cannot get detail HW architecture of these chips.  Fortunately, there are some reference documents for OMAP5910. Therefore, we use HW architecture of OMAP5910 as a reference to other OMAP chips.  Note:The core processor of DSP subsystem is a C55 core. 2018/11/20

HW Architecture of OMAP (OMAP5910) DSP Subsystem Since no open documents for OMAP1510 and OMAP161x, we cannot get detail HW architecture of these chips.  Fortunately, there are some reference documents for OMAP5910. Therefore, we use HW architecture of OMAP5910 as a reference to other OMAP chips.  2018/11/20

HW Architecture of OMAP (OMAP5910) DSP Subsystem DSP Memory Tightly Couple Memory: (Same as C55) Dual-access RAM (DARAM) Single-access RAM (SARAM) Programmable dynamic ROM (PDROM) Configurable instruction cache structure Since no open documents for OMAP1510 and OMAP161x, we cannot get detail HW architecture of these chips.  Fortunately, there are some reference documents for OMAP5910. Therefore, we use HW architecture of OMAP5910 as a reference to other OMAP chips.  2018/11/20

HW Architecture of OMAP (OMAP5910) DSP Subsystem DSP Memory External Memory Range: 0x50000 – 0xff8000 (PDROM Enable) 0x50000 – 0xffffff (PDROM Disable) Two ways to access external memory: DSP EMIF -> DSP MMU -> TC -> External Memory DSP EMIF -> TC -> External Memory Note: DSP EMIF is controlled by DSP. DSP MMU is controlled by MPU. If DSP MMU is not used, the DSP virtual addresses are mapped to the first 16M bytes of CS0 of the system memory. External memory interface on TC includes IMIF, EMIFS, EMIFF. 2018/11/20

HW Architecture of OMAP (OMAP5910) DSP Subsystem DSP DMA Controller Transfer data among internal memory, external memory, and peripherals residing on the DSP public peripheral bus Transfer data between the MPUI and internal memory. Note: Transfers between the MPU and DSP peripherals are supported by a direct connection that does not involve the DSP DMA controller. 2018/11/20

HW Architecture of OMAP (OMAP5910) DSP Subsystem DSP TIPB Bridge Private TIPB: peripherals connected here (timers, interrupt handler) cannot be accessed by the MPU via the MPUI. Public TIPB: peripherals connected here (McBSP1, McBSP2, MCSI1,MCSI2, Mailbox, GPIO UART1-3) can be accessed by the MPU via the MPUI port.. Note: Control Mode Register (CMR) – Value at Reset is 0xFE4D is used as control / status reg of the TIPB bridge: Mode, Bus error, CPU priority, Wait state(strobe 1), Wait state(strobe 2), Time-out. Note: TIPB - Texas Instruments Peripheral Bus 2018/11/20

HW Architecture of OMAP (OMAP5910) DSP Subsystem MPU Interface MPUI on OMAP5910 is similar with EHPI on DSP55x. MPU domain always masters the transfer operation on MPUI. Four modes: Single-access mode, peripheral (SAM_P) Single-access mode, memory (SAM_M) Host-only mode, peripheral (HOM_P) Host-only mode, memory (HOM_M) – SARAM only Single-access mode, memory (SAM_M): SARAM, DARAM and, external memory interface are shared between the DSP domain and the MPU domain. Single-access mode, peripheral (SAM_P): DSP public peripheral bus is shared between the DSP domain and the MPU domain. Host-only mode, memory (HOM_M): MPU has exclusive access to DSP SARAM, but it cannot access other DSP memory resources. Host-only mode, peripheral (HOM_P): MPU has exclusive access to the DSP public peripheral bus. Only DSP can change mode after reset: HOM_P (bit 8) and HOM_R (bit 9) in ST3. 2018/11/20

HW Architecture of OMAP (OMAP5910) DSP Subsystem EMIF EMIF (external memory interface) is a DSP subsystem module that gives the DSP access to the shared system memory managed by the traffic controller. MMU MMU (memory management unit) maps 16M bytes of the DSP virtual external memory address to anyplace in the 4G-byte address space of the OMAP5910 device. 2018/11/20

HW Architecture of OMAP (OMAP5910) DSP Subsystem Boot Mode Bootloader in DSP subsystem ROM Boot from EMIF Boot from MPUI Controlled by DSP_BOOT_CONFIG (read only for DSP, r/w for MPU). Note: Boot mode of DSP is controlled by MPU 2018/11/20

HW Architecture of OMAP (OMAP5910) Traffic Controller External Memory: EMIFF for SDRAM EMIFS for flash, ROM, RAM Internal Memory: SRAM: 192 KB Host of TC: MPU, C55 DSP core, System DMA, Internal local bus I/F (USB controller). EMIFF: External Memory Interface, Fast EMIFS: External Memory Interface, Slow 2018/11/20

HW Architecture of OMAP (OMAP5910) Traffic Controller Services provided by TC: 32-bit single/burst access to memory; Size adaption for 8-, 16-, or 32-bit words; Access duration management for slow memory; Memory control signal generation; Single access for 8-bit or 16-bit words (LCD 16-bit burst supported). Priority scheme: Least recently used (round-robin) Dynamic priority EMIFF: External Memory Interface, Fast EMIFS: External Memory Interface, Slow 2018/11/20

HW Architecture of OMAP (OMAP5910) System DMA Controller General Information System DMA controller is controlled by MPU via TIPB. Six general-purpose ports + One LCD ports Nine generic DMA channels. One dedicate channel for IMIF <-> LCD or EMIFF <-> LCD Support burst except TIPB port (4x32 burst for general-purpose DMA channel, 8x16 burst for LCD DMA channel) One port can serve several channels. One DMA request can trigger several channels at the same time. One channel connects a pair of ports. Six general-purpose ports External memory interface fast (EMIFF) port External memory interface slow (EMIFS) port Internal memory interface (IMIF) port Local bus interface (Local) port MPU interface (MPUI) port TIPB interface (TIPB) port 2018/11/20

HW Architecture of OMAP (OMAP5910) System DMA Controller Transfer mode Single transfer. Auto-initialization Continuous operation Repetitive operation Single transfer mode:In this mode, a channel stops when the current transfer finishes. Autoinitialization mode: In this mode, a channel loads a new configuration and automatically restarts a new transfer when the current one finishes. Continuous operation You can change the programming registers while the current configuration is executed. The next transfer is transferred with a new context but without stopping the DMA. Repetitive operation You never modify the programming registers. The same context is always used. 2018/11/20

HW Architecture of OMAP (OMAP5910) System DMA Controller Transfer source and destination Each DMA channel can be configured independently from other channels. This implies that a port can be shared by several channel requests. Therefore, these requests are time-multiplexed by the port. Transfer start / suspend Software start. Hardware start A synchronized channel enters a suspended state when a DMA request is served, and it waits for a new DMA request. 2018/11/20

HW Architecture of OMAP (OMAP5910) System DMA Controller Transfer control 2018/11/20

HW Architecture of OMAP (OMAP5910) System DMA Controller Addressing Mode Constant Post-incremented Indexed Double-indexed Data/Address Alignment Depend on the data type if not in the burst mode Alignment to four-word burst boundary (128 bits) in the burst mode Block Frame Element Block_size = Frame_number * Element_number * Element_size 2018/11/20

HW Architecture of OMAP (OMAP5910) Interprocessor Communication The MPU and DSP processors communicate with each other via a mailbox-interrupt mechanism. This mechanism provides a very flexible software protocol between the processors. Four mailboxes in system: Two for DSP to MPU Two for MPU to DSP Two registers and a flag bit correspond to each mailbox: Data register Command register Flag bit Whenever writing to command register, an interrupt will be generated on the other processor. 2018/11/20

HW Architecture of OMAP (OMAP5910) Interprocessor Communication Software setup procedure System software initializes all four of the mailboxes. System software enables the interrupt mask in the respective interrupt handler associated with each processor. The interrupting processor writes to the mailbox data location with the data word information when it must alert to the word for the other processor The interrupting processor writes to the mailbox command word a predefined command (predefined and understood by both processors). This write issues the interrupt to the other processor. 2018/11/20

HW Architecture of OMAP (OMAP5910) Interprocessor Communication Software setup procedure In response to the interrupt, the interrupted processor acknowledges the interrupt by reading the mailbox registers. Reading the two locations is performed by the software protocol; the system software must read the data first and then read the command register (the associated interrupt and 1-bit flag register are cleared upon read).. System software examines the data and command words to determine what to do. System software calls an interrupt service routine (ISR), to do whatever processing is necessary. System software returns to normal processing. 2018/11/20

SW Architecture for OMAP application Architecture Requirement: Support application development for a heterogeneous multiprocessor system design Easy adaptation and expansion for future technology Goals of the Architecture: Standardization Reuse of existing APIs and application software Benefits of the Architecture: Extensive reuse of previously developed software Accelerating time-to-market for new software products 2018/11/20

SW Architecture for OMAP application Three Parts in SW architecture Host (MPU subsystem): GPP (General-Purpose Programming) Environment DSP (DSP subsystem): DSP/BIOS Interaction between Host and DSP: DSP/BIOS Bridge GPP is the system master. The DSP/BIOS bridge provides communication that enables GPP applications and devices drivers to: Initiate and control DSP tasks Exchange messages with the DSP Stream data to and from the DSP Perform status inquiries 2018/11/20

SW Architecture for OMAP application 2018/11/20

SW Architecture for OMAP application Components on ARM core • OS – The OS that runs on the TI-enhanced ARM925, such as Linux®, Nucleus™, Palm OS®, SymbianOS™, Windows® CE. • Link Driver – The low-level communications driver. • DSP Resource Manager – The DSP node management module that controls the low-level instantiation of DSP Nodes. • DSP/BIOS™ Bridge API – The set of exported APIs that are used by the gateway components to interact with the DSP/BIOS bridge. These include DSP node management APIs as well as data transfer APIs. • Gateway Components – These abstract the functionality provided by the DSP nodes into a simple set of APIs available to the application developer. • Applications – The applications that are available to the end user, such as e-mail, media player, etc. 2018/11/20

SW Architecture for OMAP application Components on C55 core • DSP/BIOSII – The real-time OS for the DSP. • Link Driver – The low-level communications driver. • DSP Resource Manager Server – The module that invokes, activates and destroys DSP nodes. • DSP Nodes – DSP nodes control the processing needed on the DSP to perform the function of the core software technology. 2018/11/20

SW Architecture for OMAP application General SW Model ARM core C55 core For more information, see DSP/BIOS Bridge Introduction. 2018/11/20

SW Architecture for OMAP application How to Develop OMAP Application? Software Tools DSP(ARM?): Code Composer Studio, which integrated all host and target tools in a unified environment to simplify DSP (ARM?) configuration, optimization and debugging. ARM: Depend on OS used??? Hardware Tools Innovator Development Kit for OMAP XDS510 emulator XDS560 emulator “Code Composer Studio” and “Innovator” are trademarks of TI. 2018/11/20

SW Architecture for OMAP application How to Develop OMAP Application? Develop ARM Application (on Symbian OS) 2018/11/20

SW Architecture for OMAP application How to Develop OMAP Application? Develop DSP Algorithm Note: For information about how to debug the DSP base image, see slide #65 2018/11/20

DSP/BIOS Bridge Introduction Contents of this module What is DSP/BIOS Bridge? (Overview) Architecture of DSP/BIOS Bridge Host Software DSP Software DSP Task Model 2018/11/20

DSP/BIOS Bridge Introduction What is DSP/BIOS Bridge? DSP/BIOS Bridge is a combination of software for both the GPP Operating System (OS) and DSP OS that links the two operating systems together. 2018/11/20

DSP/BIOS Bridge Introduction GPP OS applications can use the DSP/BIOS bridge API to: initiate signal processing tasks on the DSP, exchange messages with DSP tasks, stream data buffers to and from DSP tasks, pause, resume, and delete DSP tasks, and perform resource status queries. DSP/BIOS Bridge enables GPP application developers to utilize the DSP as a processing resource. 2018/11/20

DSP/BIOS Bridge Introduction DSP side DSP/BIOS bridge API enables message exchange between the DSP and GPP as well as streaming of large blocks of data. DSP/BIOS Bridge also defines a DSP node abstraction that groups blocks of related code and data together into functional blocks called nodes. Nodes can be used for signal processing purposes as well as general control processing. 2018/11/20

DSP/BIOS Bridge Introduction Architecture of DSP/BIOS: Relationship Between GPP Client and DSP Task 2018/11/20

DSP/BIOS Bridge Introduction Architecture of DSP/BIOS: Host side architecture DSP/BIOS bridge API -> DSP subsystem driver One DSP subsystem driver --- One DSP subsystem hardware instance Function of DSP subsystem drivers: Booting the DSP, Loading the DSP RTOS and application code, Starting the DSP running. Moves messages and data buffers between the GPP and the DSP after DSP is initialized and the DSP RTOS is running. 2018/11/20

DSP/BIOS Bridge Introduction Architecture of DSP/BIOS: DSP side architecture device-independent streaming I/O (STRM) interface, messaging interface (NODE), Resource Manager (RM) Server --task of the DSP RTOS and is subservient to commands and queries from the GPP. Tasks started by the RM Server communicate using the STRM and NODE interfaces and act as servers for their corresponding GPP clients, 2018/11/20

DSP/BIOS Bridge Introduction Architecture of DSP/BIOS Functional Components of DSP/BIOS bridge 2018/11/20

DSP/BIOS Bridge Introduction Host Software DSP Manager Module (Highest Level) DSP Processor Module DSP Node Module (Lowest Level) 2018/11/20

DSP/BIOS Bridge Introduction Host Software 2018/11/20

DSP/BIOS Bridge Introduction Host Software DSP Manager Module (Highest Level) Controlling Nodes DSP Processor Module RHwaDevice (or derived RHwaOmap) Device Driver Initialization Select and Attach to a DSP Create Nodes on the DSP Detach from DSP Terminate and Delete DSP Nodes DSP Node Module (Lowest Level) RHwaTask Allocate and Connect DSP Nodes Launch DSP Tasks Stream Data to/from DSP Tasks Exchange Messages with DSP Nodes 2018/11/20

DSP/BIOS Bridge Introduction DSP Software STRM Module The STRM module is used to manipulate stream objects, which represent logical channels for streaming data between nodes on the DSP and other nodes the same DSP, other nodes on different DSPs, or applications running on the GPP. NODE Module The NODE module is used by a node running on the DSP to exchange messages with another node or with applications running on the GPP. 2018/11/20

DSP/BIOS Bridge Introduction DSP Software Resource Manager Server It runs as a task of the DSP RTOS and is subservient to commands and queries from Resource Manager running on the GPP. As GPP programs make requests through the (GPP-side) DSP/BIOS Bridge APIs, the Resource Manager will send commands to the RM Server on the DSP to implement the corresponding action. When it creates a node it also creates an “environment” for the node, which includes default resources for the node, such as an RTOS task for the node, a message queue and notification semaphore, etc., which the node will use during its execute phase. 2018/11/20

DSP/BIOS Bridge Introduction DSP Task Model a node is an abstraction of a block of related program code and data. A node is not an individual hardware processing element, but one of probably many software processing elements running on a single DSP. Nodes can be used for signal processing purposes as well as general control processing. Task Node XDAIS Socket Node Device Node Task Node – This is the basic processing element used in DSP/BIOS Bridge. A task node exists as an independent execution thread in the DSP’s RTOS. Task nodes can exchange messages with other nodes on the DSP or with the GPP. Task nodes can also stream large data blocks to/from other nodes and the GPP using a device-independent I/O interface. XDAIS Socket Node – An XDAIS socket node is an enhanced task node that provides a framework, or housing, for a TMS320 DSP Algorithm Standard (hereafter referred to as XDAIS) compliant algorithm. The socket node facilitates data transfer from the algorithm to other nodes, or to the GPP. Device Node – A device node manages either a DSP peripheral device or a communication path between two Task nodes or implements a software device. Device nodes that manage a peripheral device encapsulate low-level hardware and communication details. 2018/11/20

DSP/BIOS Bridge Introduction DSP Task Model DSP task nodes vs. normal DSP/BIOS tasks 1. The following three nodes functions are included with prefix <NODE_NAME>_<VENDOR>_ Create – all DSP resources needed by the node are allocated, Execute – node’s real-time processing is performed, Delete – all resources allocated for the node are freed 2. Only “Execute” function runs in a independent thread; the other two run in RM server task. 3. Have pre-defined task environment established by the RM Server. 2018/11/20

Advantage of OMAP Platform (Summary) Hardware Advantage over Traditional Platform Dual core processor vs. Separate two processors Easier communication between MPU and DSP via Shared Memory and MPUI Easier synchronization between MPU and DSP via Hardware mailboxes Better balance of High performance and Low-power consumption 2018/11/20

Advantage of OMAP Platform (Summary) Software Advantage over Traditional Platform Architecture of software on OMAP is well defined and fits for many applications Many DSP algorithms can be easily ported to OMAP platform with little modification provided they obey IT’s algorithm standard. Application developers can use functionality of DSP without knowledge of DSP. Highly integrated tools provided for developing and debugging. Support many high-level Operation Systems. 2018/11/20

Advantage of OMAP Platform (Summary) Overall Advantage Shorter time-to-market Lower system price OMAP5910: $32 for 10,000 units 2018/11/20

Game Over! Questions??? 2018/11/20

DSP/BIOS Bridge Introduction (BK) Contents of Backup Slides The Mechanics of Building DSP/BIOS Bridge App. Debugging the DSP base Image DSP/BIOS Bridge Exception Handling Task Node XDAIS Socket Node Device Node DSP/BIOS Bridge Node Database 2018/11/20

DSP/BIOS Bridge Introduction (BK) The Mechanics of Building DSP/BIOS Bridge Applications The Symbian OS-Side of the Application To use the DSP/BIOS Bridge APIs, you should follow standard Symbian OS C++ programming practices, and include the DSP/BIOS Bridge API header file, and link to the appropriate DSP/BIOS Bridge libraries. Header file: #include <e32std.h> /* required for Symbian OS apps */ #include <dspbridge.h> /* required for DSP/BIOS Bridge apps */ Library: bridgeapi.lib. DLL: Library Description bridgeapi.dll Main DSP/BIOS Bridge API DLL. ehwa.ldd Generic DSP/BIOS Bridge logical device driver, enabling control and communication with a DSP. For Hurricane, this is implemented by Symbian. ehwaomap.pdd Physical device driver, encapsulating platform-specific GPP≪DSP connection details. 2018/11/20

DSP/BIOS Bridge Introduction (BK) The Mechanics of Building DSP/BIOS Bridge Applications The DSP-Side of the Application The DSP-side of a DSP/BIOS Bridge application is built using TI’s Code Composer Studio (CCS). include the appropriate DSP/BIOS Bridge API header files, and link with the DSP/BIOS Bridge DSP-side libraries. Header files: #include <rmsdefs.h> /* DSP/BIOS Bridge Resource Manager Server definitions */ #include <rms_sh.h> /* RMS definitions shared on both GPP and DSP */ #include <node.h> /* For DSP/BIOS Bridge NODE_ APIs */ #include <strm.h> /* For DSP/BIOS Bridge STRM_ APIs */ Library files: Library Description bridge.a55l Main DSP/BIOS Bridge API library, includes NODE and STRM implementation. newdev.a55l Contains DSP/BIOS Bridge-specific device drivers. usr.a55l Contains DSP/BIOS Bridge-specific error handlers. omapshm.a55l Contains platform-specific code for Bridge’s DSP≪GPP link driver. If you use the platform-specific BIOS configuration database (CDB) seed file provided with the DSP/BIOS Bridge DDK, these libraries will be automatically linked into your application. If you create a new CDB seed file, then you’ll need to include these libraries in your Code Composer Studio project. 2018/11/20

DSP/BIOS Bridge Introduction (BK) The Mechanics of Building DSP/BIOS Bridge Applications Configuring Your Application in the DSP/BIOS Bridge Node Database In DSP/BIOS Bridge applications, blocks of related DSP code and data are abstracted as signal processing “nodes”. GPP-side DSP/BIOS Bridge APIs allow an OS application to create, execute, and delete nodes on the DSP at runtime. DSP/BIOS Bridge maintains a Node Database that holds configuration information about DSP nodes. DSP/BIOS Configuration tool (provided by CCS) is used to register the “nodes” information to Node Database. 2018/11/20

DSP/BIOS Bridge Introduction (BK) Debugging the DSP Base Image Generate COFF image Generate DBOF image cof2dbof loaded and started by DSP/BIOS Bridge, Load COFF image halt the DSP Load DBOF image CCS CCS Debugging 2018/11/20

DSP/BIOS Bridge Introduction (BK) DSP/BIOS Bridge Exception Handling SYS_error(“module_name”, X). USR_logError() call SHM_interrupt2(X) 2018/11/20

DSP/BIOS Bridge Introduction (BK) Task Node A Task node runs as an independent execution thread in the DSP’s RTOS. Communication Path In addition to the node-to-node and node-to-GPP messaging, task nodes can stream data to/from device nodes via stream (STRM) I/O. 2018/11/20

DSP/BIOS Bridge Introduction (BK) Task Node Communication Path intermediary devices must be used same device driver through which the RM Server communicates with the Resource Manager. 2018/11/20

DSP/BIOS Bridge Introduction (BK) Task Node Execution Timeline RM Server and Task Functions (Create, Execute, and Delete) Environment Structure Function Signatures Execution Context Enviroment Structure: typedef struct RMS_TskEnv { MSG_Obj message; Ptr moreEnv; //Arbitrary Pinter Ptr self; //DSP/BIOS task handle of this Task Node Thread } A task node references its environment via a node environment pointer, NODE_EnvPtr. Signatures: RMS_STATUS nodeCreate(Int argLength, Char * argData, Int numInStreams, RMS_WORD inDef[], Int numOutStreams, RMS_WORD outDef[], NODE_EnvPtr node) RMS_STATUS nodeExecute(NODE_EnvPtr node) RMS_STATUS nodeDelete(NODE_EnvPtr node) Create – RM Server; Execute – Task thread; Delete – RM Server 2018/11/20

DSP/BIOS Bridge Introduction (BK) XDAIS Socket Node An XDAIS socket node allows an XDAIS-compliant algorithm to “plug-in” to a DSP/BIOS Bridge application. The socket node provides a housing for the algorithm, calling algorithm functions as appropriate, and passing data to/from the algorithm as parameters in the algorithm function calls. 2018/11/20

DSP/BIOS Bridge Introduction (BK) XDAIS Socket Node algorithms must be reentrant within a preemptive environment, algorithm data references must be fully relocatable, algorithms must not directly access any peripheral device, etc. manage I/O between the algorithm and the rest of the DSP/BIOS Bridge application, and to allow scheduling within the DSP RTOS. Socket Concept 2018/11/20

DSP/BIOS Bridge Introduction (BK) XDAIS Socket Node Communication Paths 2018/11/20

DSP/BIOS Bridge Introduction (BK) XDAIS Socket Node Execution Timeline RM Server, XDAIS Socket, and XDAIS Algorithm (Three Phase: Create, Execute, and Delete) Environment Structure Function Signatures Execution Context Execution Context Function Execution Context algInit RM Server algNumAlloc RM Server algAlloc RM Server algActivate Task created for socket, or RM Server algDeactivate Task created for socket, or RM Server algControl Task created for socket algFree RM Server algMoved Not used alg process functions Task created for socket socketCreate RM Server socketExecute Task created for socket socketDelete RM Server 2018/11/20

DSP/BIOS Bridge Introduction (BK) Device Node A Device Node is used to either manage a DSP peripheral device, implement a software device, or to manage a communication path between two nodes.. Category Terminating Devices: source or sink data. Stackable Devices: In-place devices copying devices A new stream interface (STRM) has been defined for DSP/BIOS Bridge. STRM is based upon the SIO APIs provided by DSP/BIOS-II. The key differences between STRM and SIO are that STRM exports stream buffer allocation and free functions and only supports an issue/reclaim I/O model for a smaller code footprint. 2018/11/20

DSP/BIOS Bridge Introduction (BK) Device Node DSP/BIOS Bridge does not impose any special requirement on device drivers; once a driver works in DSP/BIOS-II (using SIO), it will work without modification as a device node in DSP/BIOS Bridge (using STRM). 2018/11/20

DSP/BIOS Bridge Introduction (BK) Device Node Communication Paths Device nodes do not support node-to-node or node-to-GPP messaging. Execution Timeline Function Signatures Each device node must provide seven functions in a driver function table. Same as devices in DSP/BIOS-II. Execution Context Device node functions are not invoked explicitly by the RM Server; some are called indirectly as the RM Server calls a task node’s create-phase function and the node opens a stream to the device, and others are invoked when nodes created by the RM Server perform device I/O in their execute phase. 2018/11/20

DSP/BIOS Bridge Introduction (BK) DSP/BIOS Bridge Node Database Node Configuration Process node creator. node integrator. 1. Development: Node creator configures DSP/BIOS Bridge nodes, and node integrator configures nodes into the embedded system. 2. Runtime: DSP/BIOS Bridge software framework automatically registers configured nodes into the DCD database. 3. Runtime (optional): Integrator or Resource Manager dynamically deploys new nodes and updates the DCD database. 4. Runtime: An application developer, through the Resource Manager, indirectly performs DCD database queries to instantiate new nodes. 2018/11/20