Summary. Hardware Requirements. Software Requirements. Directories. Application Note: Embedded Processing. XAPP996 (v1.

Transcription

1 Application Note: Embedded Processing Dual Processor eference Design Suite Author: Vasanth Asokan XAPP996 (v1.0) May 10, 2007 Summary This is the Xilinx Dual Processor eference Designs suite. The designs illustrate a few different dual-core architectures based on the MicroBlaze and PowerPC processors. The designs illustrate various concepts described in the Xilinx White Paper WP262 titled, Designing Multiprocessor Systems in Platform Studio. There are simple software applications included with the reference designs that show various forms of interaction between the two processors. Hardware equirements Xilinx ML402 and/or ML410 development boards and power supplies Xilinx Parallel 4 or USB cable S232 Cable Hyperterminal or some other terminal client Software equirements The software requirements are the following: Embedded Development Kit (EDK) 9.1i ISE 9.1i The Dual Processor eference Design Suite can be downloaded from: Directories Table 1 shows the directory structure of the files in xapp996.zip. Each directory also has a description of its function. Table 1: Directory Structure and Functional Description Directory Name Description sw pcores mp_designs_repository ml402 dual mb ml410 dual ppc ml410_dual_proc_mb_ppc Simple software applications illustrating multiprocessor communications. Source code is shared across all the EDK multiprocessor designs. EDK user repository containing the Mutex and Mailbox pcores as well as software drivers for the two peripherals. Dual MicroBlaze design for Xilinx ML402 board. Dual PPC design for ML410 board. Dual processor, MicroBlaze/PPC design for ML410 board. No caches on MicroBlaze Xilinx, Inc. All rights reserved. All Xilinx trademarks, registered trademarks, patents, and further disclaimers are as listed at PowerPC is a trademark of IBM Inc. All other trademarks and registered trademarks are the property of their respective owners. All specifications are subject to change without notice. NOTICE OF DISCLAIME: Xilinx is providing this design, code, or information "as is." By providing the design, code, or information as one possible implementation of this feature, application, or standard, Xilinx makes no representation that this implementation is free from any claims of infringement. You are responsible for obtaining any rights you may require for your implementation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of the implementation, including but not limited to any warranties or representations that this implementation is free from claims of infringement and any implied warranties of merchantability or fitness for a particular purpose. XAPP996 (v1.0) May 10,

2 eference Design Specifics eference Design Specifics The reference design suite in this application note contains three dual-core architectures. 1. Dual MicroBlaze Design 2. Dual PowerPC Design 3. A PowerPC-MicroBlaze dual processor design All three designs illustrate two fully functional processor systems interacting with each other via communication channels. Special cores are supplied as a part of the reference design package. These cores provide simple synchronization and message passing features for use between the two processors. These cores are: 1. OPB_Mutex The OPB Mutex core helps achieve synchronization between multiple processors when accessing shared resources. The core has a configurable number of mutexes and has a write to lock scheme. More information about the core is present in the Mutex datasheet is available by right clicking on the Mutex core in the Platform Studio IDE. The software interface is provided by the mutex_v1_00_a driver which is also provided with the reference design. 2. OPB_Mailbox The OPB Mailbox core helps a processor pass simple messages to another processor in a FIFO fashion. The Mailbox is suited for small to medium sized messages (< a few 100 bytes). The mailbox also offers an interrupt line which indicates the presence of data in the mailbox. More information about the core is present in the Mailbox data sheet which is available by right clicking on the Mailbox core in the Platform Studio IDE. The software interface is provided by the mbox_v1_00_a driver which is also provided with the reference design. All three designs have software applications illustrating communication using these cores. All the processors also have shared memory (external and internal) between them providing for a more heavy-weight and application specific data sharing scheme. The architecture of the three different systems is explained in the subsequent sections. Dual MicroBlaze Design This design illustrates a topology with two MicroBlaze processors on a single shared OPB bus. The processors use a shared OPB_Mutex core and shared OPB_Mailbox core to synchronize and pass messages. Both processors have access to external DD memory via the OPB and XCL interfaces. Apart from sharing external memory, the two processors share local memory (BAM) via LMB and OPB memory controllers. Each processor has an interrupt controller assigned to it to handle various in the interrupts in the system. Both processors have a debugger interface via the OPB_MDM core. Figure 1 shows a block diagram of the design XAPP996 (v1.0) May 10,

3 eference Design Specifics Figure 1: Dual MicroBlaze Processor Design DS996_01_ XAPP996 (v1.0) May 10,

4 eference Design Specifics This design illustrates a topology with two PPC405 processors on a single shared PLB bus. The processors use a shared OPB_Mutex core and shared OPB_Mailbox core to synchronize and pass messages. Both processors have access to external DD memory via the PLB interface. External memory is cached by both processors. Apart from sharing external memory, the two processors share local memory (BAM) via OCM and PLB interfaces. Each processor has an interrupt controller assigned to it to handle various in the interrupts in the system. Both processors have a debugger interface via the JTAGPPC controller. Figure 2 shows a block diagram of this design. XAPP996 (v1.0) May 10,

5 eference Design Specifics Dual PowerPC Design Figure 2: Dual PowerPC Processor Design DS996_02_ This design illustrates a topology with a PPC405 processor on a PLB bus and a MicroBlaze processor on an OPB bus. The processors use a shared OPB_Mutex core and shared OPB_Mailbox core to synchronize and pass messages. Both processors have access to external DD memory. However, while PPC405 has native access to external memory via its PLB bus, MicroBlaze needs to bridge from its OPB bus to the PLB bus. Due to limitations in the architecture of the PLB DD memory controller. MicroBlaze cannot cache external memory in this architecture. There are other high performance architectures possible for such a PPC405- MicroBlaze system, using the MPMC2 memory controller. efer to the Xilinx MPMC2 page for more information. In this design, apart from sharing external memory, the two processors share local memory (BAM) via LMB and OCM memory controllers. Each processor has an interrupt XAPP996 (v1.0) May 10,

6 Creating the Designs controller assigned to it to handle various in the interrupts in the system. Both processors have a debugger interface via the JTAGPPC controller and the OPB_MDM cores. Figure 3 shows a block diagram of this design. Dual Processor PowerPC-MicroBlaze Design Figure 3: Dual Processor PowerPC-MicroBlaze Processor Design DS996_03_ Creating the Designs This section discusses how these designs were created in the first place. While this application note will not cover the exact set of steps in tutorial form, the broad series of steps are similar across all the three designs. These broad steps are, 1. Create a single processor design targeting a particular development board, with all the necessary peripherals, local and external memory using Base System Builder Wizard. 2. Add the second processor via drag-drop in the IP Catalog and connect it to the system bus. 3. Connect the debug interface of the processor to the debug peripheral (JTAGPPC or MDM). Configure the debug peripheral, if necessary, to handle the second processor as well. 4. Provide local memory (to hold boot code) for the newly added processor. This is ILMB and DLMB memory for MicroBlaze and IOCM and DOCM for PowerPC. The local memory buses must be first added, followed by a connection to the processor and a connection to the memory controller. XAPP996 (v1.0) May 10,

7 Implementing the Designs 5. Connect external memory to the second processor. Connect cache links if required. 6. Add the interprocessor communication cores (Mutex & Mailbox) and configure them 7. Add shared local memory by connecting it via DLMB for MicroBlaze and DOCM for PowerPC. OPB or PLB can also be used to interface the shared local BAM memory. 8. Add bridge peripherals if necessary. Connect bridge time-out signals to the bus interfaces on either side of the bridge. 9. Add other miscellaneous peripherals, such as timer or interrupt controller, necessary to run reasonable software applications. 10. Verify if dynamic priority arbitration is necessary for the shared system bus. Currently, this is required for OPB based systems. 11. Go to the address view in the system assembly panel and configure a valid address range for all the peripherals and memories added above. 12. Verify clock and reset connections to all the peripherals added. Implementing the Designs unning the Software Unzip the entire reference design zip file into a directory of your choice. To implement a particular design, open the design up in XPS and click on Device Configuration -> Update Bitstream. To implement the software applications, click on Software -> Build All User Applications. Note: The pcores and drivers used in each design come from a project user repository (mp_designs_repository). EDK uses absolute paths for this location. However, the three EDK reference designs share the mp_designs repository directory. The designs have a manually coded relative path to the repository. The first time you open a project, EDK will convert this relative path to an absolute path. If you move a design or the repository somewhere else, you will need to update the repository paths as well. It is recommended that you copy over the pcores and drivers supplied in this mp_designs_repository to your global EDK design repository and thus these cores will be always available in your work environment. The following general notes apply to the setup required to run the software that shows the processors interacting. Connecting to the Processors There is an xmd.ini file in the root of each EDK project. The commands in the ini file, establish a connection from the debugger, XMD, to each processor. You can follow the commands to see how each processor is connected to in sequence. The debugconfig -reset_on_run disable command is required to make sure that downloading code on one processor does not reset the other. The file also initializes a TCP terminal to connect to the JTAG UAT (explained below). Processor STDIN/STDOUT The sample applications communicate to the outside world via UATs. Processor 1 typically uses the dedicated S232 UAT on the board. To be able to receive useful output from the second processor in the system, a JTAG UAT (via OPB MDM) is available on each design. To connect to the first processor s SDTOUT, connect a hyperterminal session (configured for 9600 baud, 8 data bits, no parity, 1 stop bit, and no flow control) to the COM port on your computer to which the S232 cable from the board is connected. On the ML410 board, COM0 is the serial port from which output is received. To connect to the second processor s SDTOUT, connect a hyperterminal session via TCP/IP to localhost:4321 (4321 is the default TCP terminal port opened by XMD). This establishes a connection to the JTAG UAT, tunneled via TCP/IP by XMD. Thus you can have two hyperterminal window open, each displaying output from one processor. XAPP996 (v1.0) May 10,

8 unning the Software Downloading the Bitstream To download the bitstream, click on Device Configuration -> Download Bitstream. Once the bitstream is downloaded you can connect to the processors by launching an EDK shell ( Project -> Launch EDK shell ) and then typing xmd xmp system.xmp It is recommended not to launch XMD from Debug -> Launch XMD, as this will establish a connection to only one single processor and this will interfere with the xmd.ini startup script. unning an Application Set There are four different categories of applications included in each design. Each example application consists of a software project each for processor 1 and one for processor 2. Hence to be able to see the demonstration of a particular concept, you need to download and run the each application on the corresponding processor. For example, to run the first demo application set (shared memory), the following steps have to be done. 1. Click on Debug -> Launch Software Debugger. 2. From the list of applications to debug, choose shm0 and click OK. 3. The GDB debugged window shows up with the sources for shm0 in the main source window. 4. Click on the un button. 5. In the Target Settings dialog that shows up, choose the appropriate port number which XMD has opened up for processor 1. The XMD connection log for the processor indicates the port number at which GDB must connect to while debugging this processor In most cases, this is 1234, but you can double check the log for the correct value in your session. 6. Click OK. 7. GDB stops at main. Click Continue to let the application run on the first processor. 8. To launch the second application, click on Debug -> Launch Software Debugger in the XPS window. 9. From the list of applications to debug, choose shm1 and click OK. 10. The GDB debugged window shows up with the sources for shm1 in the main source window. 11. Click on the un button. 12. In the Target Settings dialog that shows up, choose the appropriate port number which XMD has opened up for processor 2. The XMD connection log for the processor indicates the port number at which GDB must connect to while debugging this processor. In most cases, this is 1235, but you can double check the log for the correct value in your session. 13. Click OK. 14. GDB stops at main. Click Continue to let the application run on the second processor. Thus you can use two independent GDB sessions to launch applications on each processor and see the output. 1. Shared memory example (Software Projects shm0 and shm1) This example illustrates the use of simple shared memories between the two processors. Processor 1 writes a value to a shared memory location, sets a shared flag indicating that XAPP996 (v1.0) May 10,

9 unning the Software data is available and waits for Processor 2 to read it. Processor 2 reads the value and sets a flag indicating that it has consumed the data. This process is repeated on the shell. Figure 4: Output from Shared Memory Example (shm0) DS996_04_ Figure 5: Output from Shared Memory Example (shm1) DS996_05_ Synchronization example (Software Projects sharedconsole0 and sharedconsole1) This example illustrates the use of the OPB_Mutex core to perform synchronization when accessing a shared resource. The shared resource in this example is the primary on board S232 interface. Both processors redirect their STDOUT to this shared console. Without synchronization, the console output would become very garbled and useless. Hence, each XAPP996 (v1.0) May 10,

10 unning the Software processor locks the OPB_Mutex core before doing any output and unlocks the mutex when output is done. 3. Mailbox message passing example (Software Projects producer and consumer) DS996_06_ Figure 6: Output from Synchronization Example (sharedconsole0 and sharedconsole1) This example illustrates the use of the OPB_Mailbox core to pass data from a producer processor down to a consumer processor. The two processors exchange a greeting message first and then the producer passes on a larger kilobyte sized data structure to the consumer. The consumer verifies the transferred data against a known golden value. XAPP996 (v1.0) May 10,

11 unning the Software DS996_07_ Figure 7: Output from Mailbox Message Passing Example (producer) DS996_07_ Figure 8: Output from Mailbox Message Passing Example (consumer) 4. Mailbox interrupt generation example (Software Projects intrgen0 and intrgen1) DS996_08_ This example illustrates the use of the OPB_Mailbox core to interrupt one processor from the other. The OPB_Mailbox s Interrupt signals are used for this purpose. By setting a status bit in the Mailbox, the interrupt generation feature is enabled. Once enabled, processor 1 starts sending messages to processor 2. Processor 2 receives every message through an interrupt. It sends an acknowledge message (interrupt) back to Processor 1 to indicate receipt of the event. XAPP996 (v1.0) May 10,

12 Conclusion Figure 9: Output from Mailbox Interrupt Generation Example (intergen0) DS996_09_ Figure 10: Output from Mailbox Interrupt Generation Example (intergen1) DS996_10_ Conclusion This reference design set can be used as a starting point for creating custom multiprocessor systems based on MicroBlaze and PPC405 processors. These designs can be ported to other compatible boards in a relatively straightforward fashion. More processors and peripherals can be added to customize the design for the final application. evision History The following table shows the revision history for this document. Date Version evision 5/10/ Initial Xilinx release. XAPP996 (v1.0) May 10,