This document applies Version e.Card software. Please contact UTMC lat
|
|
|
Top Searches for this datasheet
e.Card Applications Development Guide
This document applies Version e.Card software. Please contact UTMC latest software release.
Visit page http://www.utmc.com/ecard/ Send documentation product comments ecard@utmc.aeroflex.com.
January 2001
Information this document subject change without notice. Companies, names, data used examples fictitious unless otherwise noted. part this document reproduced transmitted form means, electronic mechanical, without express written permission Aeroflex UTMC, Inc.
Copyright Aeroflex UTMC Microelectronic Systems Inc., 2001
Table Contents
Table Contents Using This Document
What Should Know This Document Organized.v Conventions Used This Document Obtain Additional Information Provide Feedback. Third-Party Publications UTMC e.Card Publications.
Chapter
Designing Your Application's Architecture
Introduction. Information Flow e.Card System e.Card Programming Paradigms Pipelining with e.Card Pipelining within e.Card Distributed Processing using Multiple e.Cards Interrupt Polling Concepts. Record Processing Versus Processing e.Card Hardware Characteristics Characteristics Embedded MIPS Processor Characteristics 1-10 UTCAM-Engine Characteristics 1-10 FIFO Management. 1-12 Pipelining Operations Through Engines. 1-14 Reading Status Data from Output FIFO 1-15 UTCAM-Engine Tables. 1-16 Dynamic Virtual Record Indexing. 1-18 Internal Table Types 1-18
Chapter
Compiling Linking Embedded MIPS Applications
Introduction. Chapter Contents. Idiosyncrasies MIPS Processor. Coprocessors. 5-Stage Pipeline. Registers 64-bit Processing Data Types Alignment Address Spaces Memory Manager Instruction Overview Caches. Initialization. 2-10 Interrupts Exceptions 2-11 Other Software-Related Conventions 2-12
January 2001
e.Card MIPS Application Programming Interface (API) 2-13 Software Package Layout 2-14 MIPS Startup Code Walkthrough 2-14 Tour e.Card Address Map. 2-15 Limitations 2-16 Exception Handler Limitations. 2-17 Cross-Compiler Environment. 2-18 Sections Relocation 2-20 Assembly Language Programming 2-21 Programming 2-22 Linker Command Files 2-22 Makefiles Build Application. 2-25 Files Created Build Process. 2-25 Debugging Techniques. 2-26 Exception Messages from UART 2-27 PMON. 2-29 Gdb. 2-29 Host/e.Card Handshaking Data Synchronization. 2-29 Handshaking Methods 2-30 Sychronization Issues. 2-31 MIPS Cache Coherency Concerns Workarounds 2-31 Related Compiler Issues 2-33 Serial Port (UART) Programming 2-33 UART Library Source Files. 2-34 Accessing UART Registers 2-34 Software Modes Available UART Programming. 2-34 Serial Communications Restrictions Caveats 2-35 Basic Coding Tips Improving Performance 2-36 Advanced Topics. 2-37 Accessing e.Card Memory Configuration Structure. 2-37 Bypassing with Custom Coding. 2-38 Optimization Techniques. 2-38 Interrupt Processing. 2-38
Chapter
Host Library Functions .3-1
Introduction. Library Function Descriptions BootCard(). CloseCard(). dmaClose() dmaDone(). dmaOpen(). dmaStart(). intEnableInterrupts() intWaitException() 3-11 intWaitMessage0() 3-12 intWaitMessage1() 3-13 intWaitPost(). 3-14 intWaitWatchdog() 3-15 OpenCard() 3-16 ReadInboundFree() 3-17 ReadMessage() 3-18
January 2001
ReadMessage64() 3-19 ReadOutboundPost() 3-20 SendMessage32Wait(). 3-21 SendMessage64Wait(). 3-22 SetupCircularQueues(). 3-23 WriteMessage() 3-24 WriteMessage64() 3-25 WriteOutboundFree(). 3-26 WriteInboundPost(). 3-27
Chapter
MIPS Library Functions
Introduction. Library Function Descriptions cacheInvalidateDCACHE() cacheInvalidateICACHE(). cacheInvalidateRange() cacheWBackRange(). camAddDiscreteRecord() camAddPrefixRecord(). camConfigNewDiscreteTable() camConfigNewPrefixTable() 4-10 camCount() 4-11 camDeleteDiscreteRecord() 4-12 camDeletePrefixRecord() 4-14 camDeleteTable(). 4-15 camLoadMemory(). 4-16 camLoadTable(). 4-17 camReadData() 4-18 camReadStatus(). 4-19 Status Codes 4-20 camSeekDiscretePartialRecord(). 4-22 camSeekDiscreteRecord() 4-24 camSeekPrefixRecord(). 4-26 camSeekProximity() 4-27 camSetContext() 4-29 camSetContextQuick() 4-30 camSetHierarchy(). 4-31 camUnloadMemory() 4-32 camUnloadTable() 4-33 camWaitCAM() 4-34 camWriteCAM(). 4-35 intHookInterrupts(). 4-36 intEnableInterrupts(). 4-38 sysCardReady() 4-40 sysReadInboundPost(). 4-41 sysReadMessage() 4-42 sysReadMessage64() 4-43 sysReadOutboundFree(). 4-44 sysSetupCircularQueues(). 4-45 sysWriteInboundFree() 4-46 sysWriteMessage() 4-47 sysWriteMessage64() 4-48 sysWriteOutboundPost() 4-49
January 2001
Appendix Appendix Appendix
e.Card Address .A-1 Host Software Package Layout .B-1 MIPS Software Package Layout .C-1
January 2001
Using This Document
Using This Document
What Should Know
this manual, should familiar with board specification, UTMC e.Card design layout, install configure peripherals your host computer system. Familiarity with MIPS compiler very useful.
This Document Organized
chapters this document organized follow design flow recommended UTMC. e.Card Applications Development Guide contains following chapters: Chapter "Designing Your Application's Architecture" page 1-1, discusses design workable application e.Card. Chapter "Compiling Linking Embedded MIPS Applications" page discusses aspects working with MIPS processor your application. Chapter "Host Library Functions" page discusses generate host application software with e.Card, well describing host function calls. Chapter "MIPS Library Functions" page discusses generate MIPS User Application Software, describes e.Card driver routines available MIPS application software. Appendix "e.Card Address Map" describes address e.Card. Appendix "Host Software Package Layout" describes components host/apps/ top-level directory e.Card Host development Appendix "MIPS Software Package Layout" explains components mips/ top-level directory e.Card MIPS development
Conventions Used This Document
Table "Conventions Used This Document," explains conventions used this document.
TABLE Conventions Used This Document Convention italics <variables> system information Definition Titles documents referred this manual appear italics. Information that vary command, such filename, appears lowercase letters words enclosed angle brackets. System-related information, including prompts, filenames, error messages, indicated courier font. Information that must enter exactly appears this document indicated bold font. Horizontal ellipses following menu item choice indicate that selecting choice will immediately bring pop-up menu.
input
January 2001
Using This Document
TABLE Conventions Used This Document Convention Definition Vertical ellipses indicate omitted information relevant example shown.
italics dialog box)
italicized item dialog indicates that selection optional.
Obtain Additional Information Provide Feedback
UTMC provides e-mail address customers communicate issues concerning e.Card. e-mail address
ecard@utmc.aeroflex.com
Visit www.utmc.com/ecard latest e.Card information downloadable software documentation.
Third-Party Publications
publications listed below provide supplemental information that helpful when using e.Card.
TABLE Third-Party Publications Document Title This Document. Copy
MIPS
provides general information MIPS compilers. provides detailed information MIPS compiler. describes language compiler. Assembler Using Porting Linker Make
Sweetman, Dominic. Morgan Kaufmann Publishers, 1999. ISBN: 1558604103. references pertain this 1999 edition. Quantum Effect Devices, Inc. This manual available download from www.qedinc.com. Visit www.gnu.org/manuals this other manuals. http://gcc.gnu.org/onlinedocs/
RM5200 Family User Manual, Rev.
C-compiler manuals
January 2001
Using This Document
UTMC e.Card Publications
TABLE UTMC e.Card Publications Document Title This Document. Copy
e.Card Hardware Software Installation Configuration e.Card Technical Summary e.Card Product Overview
describes install e.Card board software configure them use. describes technical aspects e.Card. training slides describing product.
Visit
www.utmc.com/ecard.
January 2001
Using This Document
viii
January 2001
Designing Your Application's Architecture
Chapter Designing Your Application's Architecture
Introduction
This manual meant system designer wants achieve full performance potential e.Card Distributed Query Processor. order exploit exciting technology, important understand unique architecture features e.Card, including associative memory capabilities, embedded processor characteristics, distributed processing features. This manual also contains function call reference guides application program interface (API) libraries that provided easy programming host application well programming e.Card embedded MIPS processor. highest level abstraction, e.Card viewed query processor. simply receives queries from host processor, resolves queries using native associative memory capabilities, returns results host. maintaining queue unprocessed queries queue query results, e.Card host processor cooperate efficient distributed processing manner, freeing host processor perform other meaningful work, while e.Card busy resolving query. Figure shows this general processing model. Host Processor e.Card Unprocessed Query Queue Process e.Card Processsors Process
Query Results Queue
FIGURE General e.Card Processing Model
January 2001
Designing Your Application's Architecture
also important understand environment which e.Card applications developed operate. first step understand capabilities e.Card architect application design achieve optimal performance. second step design develop host application program. Next, software which will e.Cards embedded MIPS processor. last step host application load e.Card application begin cooperative processing designed first step. Figure shows general application development flow.
FIGURE e.Card Software Development Flow
Information Flow e.Card System
Figure shows basic flow information within e.Card System. This manual describes this flow detail, documents application program interface (API)
January 2001
Designing Your Application's Architecture
provided with e.Card. This allows programmer access power e.Cards associative memory capabilities high level programming environment. Figure shows host process presenting high level query MIPS processor single e.Card system. MIPS processor creates execution plan used resolve query utilizes UTCAM-Engine processors e.Card facilitate query resolution. MIPS processor presents commands input FIFOs UTCAM-Engine associative memory processors reads status data from these engines output FIFOs. This process repeated pipelined manner until MIPS processor collected information necessary resolve query. MIPS processor then presents query result host.
FIGURE e.Card System Information Flow
e.Card Programming Paradigms
Pipelining with e.Card
e.Card designed facilitate pipelining both with host processor within card. pipelining commands similar assembly line which specialized workers perform tasks with special equipment training. task passed from worker
January 2001
Designing Your Application's Architecture
another, workstation begins working next task This concept applies both commands that passed through e.Cards FIFOs interaction host processor with e.Card. Figure shows e.Card operating pipelined mode with host processor.
FIGURE Host/e.Card Pipeline
This approach differs from normal multiple processor system which multiple process threads operate parallel multiple processors arbitrate shared resources. pipelined model performance improved because critical resources, such memory, dedicated single processor.
Pipelining within e.Card
special interest e.Card application designer input output FIFOs contained chip. input FIFO queues commands that have been input chip. e.Cards embedded MIPS processor write commands this FIFO queue while UTCAM-Engine processing previously written command. Similarly, output FIFO holds results recently completed commands, which MIPS processor read while UTCAM-Engine working subsequent command. order commands always maintained, shown Figure These FIFOs allow application running e.Cards embedded MIPS processor operate pipelined mode. using these FIFOs, possible MIPS both
January 2001
Designing Your Application's Architecture
UTCAM-Engines running parallel. This significantly contribute performance application. MIPS Timeline:
Association1 Chip Time Chip Time Chip Time Chip Time Association Chip Time Association Chip Time
Engine Timeline:
Seek Time
Seek Time
Seek Time
FIGURE Timeline Example Showing Pipelined Seeks
With this power comes responsibility. important e.Card embedded MIPS application properly control these FIFOs. Each Engine contains four 256-bit input four 256-bit output FIFO entries. important overflow FIFO capacity which result degraded performance system lockup. recommended procedure MIPS application more than three commands ahead point time. This accomplished writing three commands Engines then relieving output FIFO with results first before writing another command input FIFO.
Distributed Processing using Multiple e.Cards
Using single e.Card, processing distributed from host processor e.Card. This will improve overall system performance provided that host processor other tasks perform.
January 2001
Designing Your Application's Architecture
Still more processing power brought bear problem employing multiple e.Cards, shown Figure Here e.Cards work parallel behalf single host. four e.Cards utilized this manner.
FIGURE Distributed Processing with Multiple e.Cards
order pipelined process optimally efficient, throughput each pipeline should balanced. responsibility e.Card application designer distribute workload between host e.Card manner that best balances tasks. Figure shows pipeline balanced should measure actual performance order optimize pipeline.
FIGURE Balancing Pipelined Process
Interrupt Polling Concepts
Another important concept e.Card programmers grasp involves interrupts polling. These methods used process determine when asynchronously
January 2001
Designing Your Application's Architecture
operating task complete result available. Either these methods used with e.Card. Figure contrasts these concepts.
FIGURE Polling Interrupt-Driven Architectures
polling architecture, continual check performed until condition being checked achieved. Within e.Card, this ideal method MIPS processor when checking completion previously requested engine operation. What makes this method ideal overhead. Commonly, this method will result wasted processor cycles, especially application pipelining commands through engines. interrupt-driven architecture, operating system suspends operation process thread until interrupt received. This method often ideal host processor when interacting across with e.Card. There conditions under which better host poll e.Card rather than wait interrupt. These conditions are: task requested e.Card will take less time perform than will take host process interrupt. interaction between host e.Card consists single process thread that sufficiently pipelined balanced such that host won't generally have long wait before begin processing results previous query. host does handle interrupts well.
January 2001
Designing Your Application's Architecture Record Processing Versus Processing
Another basic concept elemental e.Card involves record processing processing. record processing, each operation affects single record. processing, entire data set, consisting multiple records, affected single operation. database environments, normal commands processing commands while transaction cursor approach record processing. Record processing also common record management file systems such ISAM files. While e.Card's engines manage many tables, they only delete record time. Similarly, seek only return contents record. role MIPS processor implement processing using more engines elemental record processing operations resolve complex processing query.
e.Card Hardware Characteristics
Figure shows block diagram e.Card. workhorses e.Card Content Addressable Memory (CAM) engines which provide e.Cards native associative memory capability. These patent-pending chips, known UTCAM-Engines, perform, unprecedented speeds, functions normally relegated database software. Each UTCAM-Engine drive gigabyte memory. detailed discussion capabilities UTCAM-Engines covered later this chapter. Chapter documents function calls that provided access UTCAM-Engines. Another element e.Card 64-bit MIPS processor which programmed interface with host application exploit power UTCAMEngines. This processor memory storage operating software data. megabytes this memory available. This processor programmed using standard C++. discussion issues related programming MIPS processor contained Chapter third important component e.Card controller which handles communication between host computer e.Card. operation this controller generally transparent e.Card system designer, however important understand capabilities limitations when designing application. host e.Card routines which pass data control information from e.Card documented Chapters respectively. final component note UART, which provides debug communication with host computer through e.Cards serial port. connecting e.Card connector hosts serial port with serial communication cable, e.Cards MIPS processor able display text message standard terminal monitor program running host.
January 2001
Designing Your Application's Architecture
FIGURE e.Card Block Diagram
Characteristics
itself imposes performance limitation that e.Card system designer must understand. Compared moving data host processors e.Card's MIPS UTCAM-Engine bus, relatively slow. example, while e.Card perform million lookups second, less than million these lookup keys their associated responses actually discretely transmitted across dedicated 33MHz 32-bit bus. there additional devices, such other e.Cards, sharing this bus, then capacity would even further limited. this reason, e.Card system designer should attempt architect system which passes complex queries across relies e.Cards embedded MIPS processor resolve query with numerous discrete lookups. This strategy also useful offloading additional work from host assist balancing workload between host processor e.Card. should also noted that there overhead associated with each transfer. most efficient manner moving data across Direct Memory Access (DMA) transfer large blocks data. comparison, moving 1000 words single word transfers will take times longer than transferring 1000 64-bit words single transfer. January 2001
Designing Your Application's Architecture
e.Card provides mechanisms transferring single words well transferring large packets using e.Cards features. judicious these transfer methods left e.Card system designer. buses come four categories that have significantly different bandwidths. oldest architecture utilizes 32-bit interface running 33MHz. Newer systems 64-bit interface 66MHz-bus speed both. Table shows maximum possible data transfer rates these different configurations. e.Card hardware installer responsible correctly setting speed width jumpers e.Card. e.Card transparently handles options.
TABLE Transmission Flow
32-bit 64-Bit
MB/second MB/second
MB/second MB/second
Embedded MIPS Processor Characteristics
e.Card's RISCMarkRM 526164-Bit Superscalar Microprocessor. processor dual issue, which means that issue integer floating-point instruction cycle. operates internally with system memory bus. processor dual integrated on-chip caches; 32KB associative instruction cache 32KB associative data cache. also integrated memory management unit high-performance floating point unit. floating point unit process MFLOPS. process uses MIPS Instruction set. programmed using MIPS compatible cross-compiler. Current development work being done with royalty free MIPS cross-compiler.
UTCAM-Engine Characteristics
UTCAM-Engine provides e.Cards associative memory capabilities. block diagram UTCAM-Engine chip shown Figure center chip four modules that perform basic data management functions. Configuration module responsible tasks related logical organization data. Table Management module manipulates entire tables while Record Management module operates upon individual records within database. Memory Test module allows memory driven UTCAM-Engine addresses physical address memory self-test purposes.
1-10
January 2001
Designing Your Application's Architecture
e.Card, UTCAM-Engines system buses connected e.Cards embedded MIPS processor. UTCAM-Engines memory connected DIMM sockets which populated with memory modules.
FIGURE UTCAM-Engine Functional Block Diagram
UTCAM-Engine chips employed e.Card each support intrinsic operations. following state diagram shows interaction these operations which will introduced here discussed detail later this document. e.Card programmer invokes these operations using library function calls described Chapter Before engine used, must initialized. This initialize operation transparently invoked BootCard() function, e.Card programmer doesn't need concerned with details this operation. Once engine initialized, there reasonable next actions. Either memory tested using combination memory load unload operations more tables configured. Once least tables have been configured, hierarchy established between them.
January 2001
1-11
Designing Your Application's Architecture
Before table record manipulation operations performed, table must have context This operation identifies table that subsequent record table operations will operate against. Once context established, records added, sought, deleted will. Also, table loaded unloaded entirety records counted. table deleted, than context must another table table must configured.
FIGURE UTCAM-Engine General Flow Write Operations
FIFO Management
Input output FIFOs contained each engine facilitate parallel operation UTCAM-Engines e.Cards embedded MIPS processor. Figure shows MIPS processor interacting with engines FIFOs. MIPS reading from writing these FIFOs while engine processing previously requested operation.
1-12
January 2001
Designing Your Application's Architecture
Input FIFO Bits
Queued Command Slot Command
MIPS Processor
Slot Slot Slot Output FIFO Bits Bits
Status Data Slot
Engine Core
Results Earlier Command
Status Status Status Status
Data Slot Data Slot Data Slot Data Slot
Command Results
FIGURE MIPS Engine FIFO Interaction
engine commands written MIPS, except Record, Load Memory Load Table, occupy slot until they executed. these exceptions; Record occupies slot every bytes association. Load Memory Load Table occupy slot every bytes written. important overflow input FIFO. Overflow input FIFO results when MIPS tries write FIFO there available slot. this occurs, MIPS will halt until input FIFO opens Input FIFO overflow avoided designing application keep pipeline short. only three commands pipeline time, then there will chance overflowing FIFO. completion commands, except Context, Seek Discreet, Seek Proximity, Unload Memory Unload Table, results status data occupying output FIFO slot. these exceptions, Context does store results, slot used. Seek Discreet results will occupy slot each bytes association returned. Seek Proximity's results will occupy slot each bytes (optional) association returned. Unload Memory Unload Table results will occupy slot each bytes returned. Failing relieve output FIFO result filling engine halting. this occurs, engine will wait until MIPS finishes reading slot from output FIFO January 2001 1-13
Designing Your Application's Architecture
then engine will write results output FIFO begin process next command from input FIFO. output FIFO completely fills engine halts MIPS keeps writing input FIFO fills, then both engine MIPS will halt. This will result deadlock situation which only rectified booting e.Card BootCard().
Pipelining Operations Through Engines
Processor halting deadlock avoided proper pipeline planning. Figure shows example this accomplished when adding large number records table. pipeline first seeded with records then each record added, result entry pulled from output FIFO. When records have been added, pipeline emptied.
FIGURE Example Avoiding FIFO Overflow when Adding Records
When UTCAM-Engine completes operation, stores status data output FIFO. table management operations, MIPS routines waits engine complete operation returns these values calling program function call parameters. This, course, sequential processing methodology. support pipelining, MIPS record management routines allow caller optionally specify that should wait operation complete. When this option selected, program responsible reading status data from output FIFO. This allows program pipeline operations through engine. properly manage engines output FIFO, e.Card software developer needs read status data from output FIFO. order properly interpret results from these reads, software designer must understand engine interprets status data read when increments from output FIFO slot next.
1-14
January 2001
Designing Your Application's Architecture Reading Status Data from Output FIFO
following table describes operation engine when MIPS performs ReadStatus() ReadData() function calls. first column represents three possible conditions oldest output FIFO slot. Either contains result operation that terminated abnormally (aborted) contains result successfully terminated operation, there completed operations output FIFO. second column specifies whether operation generates output FIFO slot data when completes normally. seek operations only record operations that return data. last columns describe interpret results ReadStatus() ReadData() function call affect that these calls will have active entry output FIFO. example, table shows that operation terminates abnormally, matter whether operation seek not, then calls either ReadStatus() ReadData() will have same effect. They will return status (indicating command aborted) increment active entry output FIFO next oldest entry.
TABLE Read Status Read Data Behavior FIFO Slot Completion Status Operation Seek Discreet Seek Proximity
ReadStatus() Effect
ReadData() Effect
Abnormal
Normal
Normal
Return Status Increment Output FIFO Return Status Increment Output FIFO Return Status
Return Status Increment Output FIFO Return Status Increment Output FIFO Returns Data Increment Output FIFO after last data word read
complete pending command
Returns Null Status Word (0000000080000000h)
Returns Null Status Word (0000000080000000h)
ReadData() function returns 64-bit word. Even though each output FIFO slot hold four 64-bit words, only relevant ones need read. engine knows which words contain valid data which ones don't. example, MIPS program performs SeekDiscreteRecord() function table with 7-byte association operation completes successfully match found) ReadData() function executed with output FIFO slot created command being oldest slot, then 64-bit word containing 56-bit association will returned. output FIFO will automatically increment next slot next ReadData() command will reading results from command that followed SeekDiscreteRecord() call.
January 2001
1-15
Designing Your Application's Architecture
Normally, pipelined program will read status first and, depending upon result, will then read data. example, program might read status determine that command complete yet. then read status again determine that command completed successfully. Based upon this information, might read data retrieve result operation. possible program streamline this process possible results does contain words with conversely, have other than always set. this case, then program simple read data distinguish status from data based upon marker bit. This will make program slightly more efficient eliminating need perform status read. information returned status read allows program determine number useful things: operation complete? operation abort? what caused error? complete description information provided status read described Chapter operation complete successfully? many ReadData() calls will take read results? What table context? What operation doing? (This provided debug assistance.)
UTCAM-Engine Tables
strengths e.Card ability administer multiple tables native hardware. This offloads significant task that normally relegated CPU. Each UTCAM-Engine manage 8192 independently configurable tables. Tables created Configure Table operation which allocates space table. Tables reference number from 8192. point time, only table have context. Subsequent operations performed against this table. configuration information tables numbered cached on-chip, allowing very quick nanosecond) context changes. Configuration information other tables maintained conventional memory. Context switches these tables requires nanoseconds. composite tables cannot exceed available memory. Individual tables cannot exceed size SDRAM bank. Depending upon memory used, each engine that populated with memory will drive from SDRAM banks. table wont bank free memory been allocated, then error status will indicate that table would have exceeded physical memory. generally good idea configure large tables first then smaller ones since memory allocated first manner. allocating larger tables first, engine will better able utilize contiguous space within each memory bank. Each table sized store 100P records where 8<N<27 represents packing density. packing density indicates percentage tables theoretical maximum that populated records point time. Performance gradually impacted packing density increases indicated graph shown Figure
1-16
January 2001
Designing Your Application's Architecture
Seek Performance Relative Packing Density
Relative Seek Time
Packing Density
FIGURE Packing Density Impact Performance
packing density provides optimal performance. recommended that packing density exceeded. record additions continued beyond this point, Record operation will eventually return error status indicating that table full. time this happens, negative impact performance become quite significant. Table Table below show maximum number records that stored table, depending size, based upon value optimum maximum represents while maximum represents 75%.
TABLE Record Capacity Smaller Tables
Optimum Maximum
1.5K
TABLE Record Capacity Larger Tables
Optimum Maximum
128K 192K
256K 384K
512K 768K
1.5M
January 2001
1-17
Designing Your Application's Architecture Dynamic Virtual Record Indexing
e.Cards UTCAM-Engine tables indexed dynamically automatically. This means that there need index table after table maintenance. When record added, automatically indexed using provided. These record keys must unique operate primary indexes. Secondary indexes must handled MIPS code using separate index tables. There indexing storage overhead.
Internal Table Types
tables populated with records that have basic elements association. key, described earlier, index record. association simply stream bytes that contains more associated data elements. There three general types tables supported e.Cards UTCAM-Engines. These are: Discrete Normal Width Tables Discrete Extra Wide Tables Prefix Tables Discrete normal width tables fastest. They support byte byte association. association width zero used, then table operates validation list. When seek performed against validation list, association returned only status used indicate exists table. association stored contiguous memory, then table said packed. association stored separate memory segment, then table unpacked. Internally, discrete records stored 32-byte packets. default, combined association requires packet size that same alone, then record will packed. Otherwise, will unpacked. When table configured, this overridden forcing table packed even when larger packed size required. Record operations against packed tables generally about nanoseconds faster than unpacked tables. Unpacked tables, other hand, require large block contiguous memory. Tables with combined association widths that exceed bytes always unpacked.
1-18
January 2001
Designing Your Application's Architecture
Figure shows packed unpacked discrete normal width tables. Packed Unpacked Bytes
Bytes
Association
Bytes
Association Bytes
FIGURE Discrete Normal Width Table Record Formats
Discrete extra wide tables intended tables with record structure that requires large amount associated data. Generally, these tables slower access than normal width discrete tables. Storage space associations these tables dynamically allocated. advantage this that memory only required records that stored table point time. This memory also potentially into memory segments that small entire table. disadvantage that allocating deallocating memory, which happens when record added deleted, relatively slow. This especially true memory becomes fragmented with many free segments that smaller than association size extra wide table. Figure shows discrete extra wide table. Bytes
Association Bytes, where
FIGURE Discrete Extra Wide Table Record Format
Prefix tables used IPV4 protocol longest prefix matching. Using these tables, program store prefixes (most significant bits) specified lengths store associated data. Each prefix prefix table carries 32-bit association. longest prefix match returns association prefix which fully matches longest series most significant bits key. Like discrete tables, prefix tables sized from records. example below assumes that prefix table exists been populated shown.
TABLE Example Prefix Table Contents Prefix Bits Length Association
0110001 0110001011001 January 2001
Bits Bits
R107 1-19
Designing Your Application's Architecture
TABLE Example Prefix Table Contents Prefix Bits Length Association
1011000101 Bits 10110 Bits R220 101101 Bits 0110 Bits Example: longest prefix match performed using 32-bit longest prefix match results association R107 being returned because bits R107 match most significant bits bits match. While four bits match, this prefix long R107. other prefixes fail match most significant bit. Prefix tables differ from discrete tables several ways. Both association widths prefix tables fixed bits. Prefix tables configured with minimum maximum significance lengths specify shortest longest prefixes stored table. Prefix tables "group enabled." group enabled prefix table stores 7-bit group with each prefix record allow non-homogeneous prefixes stored single table. This eliminates need configure multiple prefix tables, which reduces need context from prefix table another leads better memory management. When table configured "group enabled", group must passed with each seek. Otherwise, there need pass group when performing seek operation. bits, with them significant Association bits
FIGURE Prefix Table Record Format
addition IPV4 routing, prefix tables used decision trees. each bit, from most significant least represent yes/no decision priority order, than outcomes various combination entered records prefix table. longest prefix match such table yields decision that passes most decision tests. Takes about times long perform longest prefix match than normal width discreet table.
1-20
January 2001
Compiling Linking Embedded MIPS Applications
Chapter Compiling Linking Embedded MIPS Applications
Introduction
This chapter discusses technical concepts related embedded programming e.Card, contains many advanced concepts. want quick introduction creating provided sample applications, skip ahead section "Makefiles Build Application" page 2-25. e.Card uses embedded 64-bit MIPS processor provide flexible powerful processing resource tightly coupled dual UTCAM-Engine search engines. described Chapter best potential e.Card only realized custom application developed MIPS conjunction with host processor. most efficient have MIPS keeping UTCAM-Engines busy while host performing other higher-level operations. take full advantage this hardware configuration, should become aware issues that relate this MIPS processor. Fortunately, only member software development team would likely need take responsibility these issues. rest team could focus coding bulk actual application programming language. minimum, someone development team should familiar with: basic understanding e.Card address map, specifically DRAM memory SO-DIMM size type e.Card, discussed section titled Tour e.Card Address Map" page 2-15 Appendix basic understanding MIPS program virtual addresses converted into physical addresses, discussed section titled "Address Spaces Memory Manager" page 2-5. organization directories files provided e.Card MIPS software development package, discussed section titled "Software Package Layout" page 2-14. development environment Makefiles (most software developers already will familiar with this), discussed section titled "GNU CrossCompiler Environment" page 2-18. basic understanding interpret MIPS exception message UART, discussed "Debugging Techniques" page 2-26 "Exception Messages from UART" page 2-27. basic understanding performance-oriented programming techniques, discussed "Basic Coding Tips Improving Performance" page 2-36.
January 2001
Compiling Linking Embedded MIPS Applications
This chapter describes concepts need aware properly create embedded application e.Card. More importantly, awareness familiarity with these topics will allow develop higher-performance, more efficient, robust application, flexibility uniqueness hardware. skip some sections subsections this chapter depending your interests experience.
Chapter Contents
main sections chapter are: "Idiosyncrasies MIPS Processor" page 2-2: This section briefly explains various ways MIPS differs from conventional architectures. useful anyone needing write modify assembly language, also provides introduction MIPS address important modifying linker command file. "e.Card MIPS Application Programming Interface (API)" page 2-13: e.Card software support package contains MIPS startup code well function calls interfacing UTCAM-Engine search engines. This section discusses technical issues related using these calls, e.Card memory been configured, also explains startup code works. "GNU Cross-Compiler Environment" page 2-18: This section provides introduction explanation cross-compiler tools used develop applications MIPS e.Card. "Debugging Techniques" page 2-26: development environment provides ability breakpoints other debug features using diagnostic serial port e.Card. "Serial Port (UART) Programming" page 2-33: This section discusses application might able diagnostic serial port purposes, using provided software routines. "Advanced Topics" page 2-37: Advanced techniques maximizing performance discussed. These techniques needed most applications. should comfortable with concepts Chapter programming language. additional familiarity with assembly language, microprocessors, development tools great benefit.
Many these concepts issues also described more general sense) reference text MIPS Run, Sweetman, described "Third-Party Publications" page
Idiosyncrasies MIPS Processor
some ways, MIPS microprocessor architecture uniquely different than that other popular processors. This section provided help quickly recognize these differences, instead spending time trying piece together reading longer reference texts.
January 2001
Compiling Linking Embedded MIPS Applications
Much material this section deals with assembly language technical issues. most cases, e.Card MIPS software package will require modification particular application. Nevertheless, this section provided tutorial introduction some idiosyncrasies MIPS architecture. Historically, progressive changes MIPS Instruction Architecture (ISA) have been identified Roman numeral convention. first referred MIPS which original 32-bit ISA. Subsequent levels always backwardscompatible. Note that processor e.Card implements MIPS Instruction Architecture (ISA) level MIPS Thus, also execute MIPS through MIPS instruction sets.
Coprocessors
MIPS processor core itself only performs normal computational functions, such loads stores, basic arithmetic logic operations, conditional branches. Coprocessors used handle floating-point functions other important control configuration responsibilities. While term coprocessor might make think outboard chip that physically separate from main processor core, coprocessors tightly integrated with main functionality, often distinction slight best. integral MIPS coprocessors follows: Coprocessor (CP0) performs configuration, cache control, exception interrupt control. This coprocessor accessed using special instruction op-codes. Initial setup MIPS performed e.Card MIPS startup code, should normally modified developers. Coprocessor actually Floating Point Unit (FPU). Compilers optionally exploit this increased floating-point performance. However, e.Card does require floating-point support intended operation. Refer Chapter Mips more information programming. While coprocessors defined MIPS architecture, they exist MIPS processor e.Card.
5-Stage Pipeline
non-floating-point operations, MIPS uses pipelined architecture conjunction with memory caching) high performance. Most time, pipelining does affect code should written. But, when writing assembly code, aware issues: Branch delay slot: instruction following kind branch instruction always executed, regardless whether branch taken case conditional branch). Branch delay slot refers instruction that follows branch instruction. Note that jump conditional branch instructions apply here, with exception branch-likely instructions. (Refer Section 1.5.5 Mips Run.) Load delay slot: given load instruction (which loads data from memory into register), following instruction cannot data that register. This following instruction called load delay slot, cleverly optimized code will something this instruction that still useful, does that data. least,
January 2001
Compiling Linking Embedded MIPS Applications
instruction should placed there. Note that MIPS uses interlock mechanism stall pipeline should instruction require register loaded preceding instruction, thus averting data error expense performance. Coprocessor hazards: When register modified, pipeline configuration changed, some cases number delays required avoid hazards. amount requirements this delay detailed processor's data sheet, should normally interest developers.
Registers
MIPS general-purpose 64-bit registers program usage. They generalpurpose that op-code which uses register operand these registers. They referred assembly language through $31, although mnemonic naming convention more commonly used. these registers behave special way:
(mnemonic name zero) always zero useful when zero needed occasion. (mnemonic name always contains return address after subroutine-type jump-and-link instruction (described later). remaining registers truly general purpose hardware concerned. However, software convention been established which gives purpose most these registers, which reflected their mnemonic names. This convention relates compilers exception handlers these registers, some these convention details mentioned later this chapter, where relevant.
Refer Section Mips more information.
64-bit Processing
While MIPS configured either 32-bit 64-bit mode, e.Card MIPS startup code always configures 64-bit mode. MIPS architecture started 32-bit only (MIPS earlier); fact, instructions still only bits wide. Most op-codes existed before 64-bit versions existed. When 64-bit architecture (MIPS III) came out, previously-existing op-codes still needed function they before. Thus, long only MIPS instructions, lower bits each register will have same value processor were MIPS This possible because when executing MIPS (32-bit) instructions, upper bits 64-bit registers will always contain copies (just like sign extension). This allows arithmetic, comparisons, logical operations, even address remain compatible with 32-bit versions. However, order take advantage true 64-bit logical arithmetic operations, op-codes were added MIPS III, such dsub (doubleword add), (load doubleword).
January 2001
Compiling Linking Embedded MIPS Applications
Refer Section Mips more information. remainder this chapter assumes MIPS 64-bit mode.
Data Types Alignment
UTMC uses data-type conventions shown Table MIPS e.Card MIPS API:
MIPS name MIPS typedef size (bytes) assembler convention
doubleword dword word halfword byte
ui64 ui32 ui16
TABLE e.Card Data-type Conventions
Memory load store instructions must typically aligned. This means that doublewords must accessed 8-byte address boundaries (address evenly divisible words must accessed 4-byte address boundaries, halfwords 2-byte boundaries. Byte accesses have this restriction. Compilers should never allow such violations happen, assembler programmers must aware this issue. unaligned access causes exception occur. Sections 2.5.2 8.4.1 Mips provide more information unaligned accesses.
Address Spaces Memory Manager
MIPS ability serve central processor large, multi-tasking, multi-user operating system environment, complete with process protections virtual memory. this, MIPS flexible memory management unit (MMU) which includes translation lookaside buffer (TLB). plan TLB, this sound complicated. allows huge amounts virtual memory paged mapping concepts that relevant large multi-tasking multi-user environment. e.Card startup code completely disables TLB, since e.Card only somewhat-modest embedded application. Another large-system trait distinction between kernel, supervisor, user spaces. Again, these exist help protect critical kernel memory, example, from rogue user program containing bug. MIPS e.Card always executes kernel mode, address space memory descriptions kernel mode operation. Nevertheless, still involved memory addressing, there some unusual traits that should understand related operation: While MIPS internally refer 64-bit address, external system interface only provide bits addressing.
January 2001
Compiling Linking Embedded MIPS Applications
These external 36-bit addresses referred physical addresses, while internal addresses (whether bits) referred either program virtual addresses. With notable exception, e.Card MIPS uses only 32-bit program addressing, since bits more than adequate cover entire range MIPS devices DRAM that will ever available e.Card. This also because 32-bit pointers storage performance efficient. MIPS address divided into large sections that have traditional names. While e.Card only uses 64-bit mode, easier first understand 32-bit mode:
Virtual Address Range (hex) FFFF.FFFF C000.0000 BFFF.FFFF A000.0000 9FFF.FFFF 8000.0000 7FFF.FFFF 0000.0000
Traditional Section Name kseg2 kseg1 kseg0 kuseg
Size 512MB 512MB
Description mapped unmapped, uncached unmapped, cached mapped, user space
TABLE MIPS 32-bit Mode Address
Mapped means that must used translate virtual address into physical address (causing exception virtual address does exist needs paged from hard disk, example). Mapped ranges used since e.Card MIPS does stated above). Thus, only unmapped ranges kseg0 (cached) kseg1 (uncached) important here. both these, lower bits program address become physical address, with upper bits Note that both kseg0 kseg1 512MB. example, program address BFC0.0000 would become physical address 0.1FC0.0000. Even though uses 32-bit program addressing, address value (e.g. C-language pointer) will sign-extended 64-bits once loaded into register. Thus, this register then used load store instruction, 64-bit program address that used. 64-bit-mode MIPS address been carefully designed actually inside 32-bit-mode map, order provide backwards compatibility 32-bit instructions running 64-bit-mode. This 64-bit address looks shown
January 2001
Compiling Linking Embedded MIPS Applications
Table
Virtual Address Range (hex) FFFF.FFFF.FFFF.FFFF FFFF.FFFF.C000.0000 FFFF.FFFF.BFFF.FFFF FFFF.FFFF.A000.0000 FFFF.FFFF.9FFF.FFFF FFFF.FFFF.8000.0000 C000.00FF.7FFF.FFFF C000.0000.0000.0000 9800.000F.FFFF.FFFF 9800.0000.0000.0000 9000.000F.FFFF.FFFF 9000.0000.0000.0000 4000.00FF.FFFF.FFFF 4000.0000.0000.0000 0000.00FF.FFFF.FFFF Traditional Section Name ckseg2 ckseg1 ckseg0 xkseg xkphys xkphys xksseg 64GB 64GB Size 512MB 512MB Description mapped unmapped, uncached unmapped, cached mapped unmapped, cached, 36bit physical unmapped, uncached, 36-bit physical mapped, supervisor space mapped, user space
xkuseg 0000.0000.0000.0000 TABLE MIPS 64-bit Mode Address
Note that some address details differ from that described Mips Run. Defer above table, since accurately reflects e.Card hardware. very interesting important point notice that 32-bit sections kseg0 kseg1 same place 64-bit sections xkseg0 xkseg1, once address sign-extended. This perfectly fine most software utilize 32bit addresses. xkphys section (either cached uncached) unique that only (other than TLB) program address full 36-bit physical address. There situation which xkphys used e.Card MIPS API, this discussed later Tour e.Card Address Map" page 2-15.
Instruction Overview
MIPS instructions bytes wide (32-bits). This true even 64-bit mode. This section provides very brief description various types op-codes. intent only introduce some common characteristics. will still need instruction reference plan modify create assembly language. NOTE: assembler allows additional addressing modes implicitly supported MIPS processor, such data label external variable, label plus offset. these situations, assembler automatically synthesizes instructions needed realize desired January 2001
Compiling Linking Embedded MIPS Applications
operation (this seen examining assembler listing file). These extra addressing modes various synthetic instructions available described Mips Run. Common characteristics MIPS instruction include: Immediate operands: Most arithmetic logical instructions have least immediate version. immediate operand 16-bit value. consequence this that order load immediate 32-bit value into register, op-codes could required, this reason synthetic instruction invented (see following bullet). Note this description does apply shift amount shift op-codes, which 5-bit value. Synthetic instructions: (load immediate) examples synthetic opcodes that assembler actually implements using sequence real op-codes. This provided convenience, because op-codes with immediate operands only 16-bits. example, 32-bit cause assembler build 32-bit value into register using followed (assuming that both upper lower halves non-zero). also exists loading 64-bit register values. really just shift instruction zero register, intuitive that op-code zeroes. Loads stores: Load store always means from MIPS system memory (DRAM). operand register that contains data either read from written memory, another operand register that used base address memory, final operand 16-bit signed offset that added base address. Note that since offset 16-bit signed value, limited range -32768 32767. example, instruction 0x0100(t0) means "store least-significant byte 64-bit register into memory location whose program address value 64-bit register plus 256". Mnemonics with them: letter mnemonic generally intended mean "unsigned". However, actual functional meaning depends type instruction which applied: Loads: version will sign-extend read data into higher-order bits register, while non-"u" version will sign-extend. Adds subtracts: Here, unsigned does refer type operands. Instead, means that over- underflow occurs, then cause exception occur. This normally desirable, non-"u" versions typically never used. (Note that adds subtracts same either signed unsigned numbers.) Multiply divide: Here, unsigned intuitive that versions expect unsigned operands, while non-"u" versions expect signed operands. Multiplies divides must know whether operands signed unsigned, order behave correctly. less than: While there numerous conditional branch instructions, they assume that operands signed values. application ever needs perform unsigned comparison then must instead sltu January 2001
Compiling Linking Embedded MIPS Applications
which allows perform less-than comparison using unsigned numbers. (While trap instructions also this, handling resulting exception clumsy.) Branches jumps: effective jump addresses must aligned 4-byte boundary. Some interesting differences exist within this category instructions: Only type jump specify address entire memory space, consists jalr jump-register instructions. This means value register-operand directly used 64-bit target address. Note that possible cause exception this because much address space mapped. next step down jump instructions. this case, operand 26-bit immediate operand that shifted left bits form 28-bit address (since addresses must 4-byte boundaries). remaining higher-order bits program counter used create effective target address. Thus, jump only take place within region that program counter smallest jump range exists conditional branch instructions. this case, operand signed 16-bit immediate operand that shifted left bits form 18-bit signed offset. This offset then added program counter create effective target address. Thus, conditional branches only jump addresses within ±128KB range. jump-and-link instructions jalr used perform subroutine calls, where return address needed. addition performing actual jump, these instructions place address instruction following branch delay slot into register $31, described "Registers" page 2-4). subroutine return back calling program simply finishing with instruction. 64-bit MIPS instructions: only immediate data into upper 32-bit portion 64-bit register using doubleword shift instructions (synthetic instruction this). Also, remember that non-doubleword arithmetic shift instructions simply signextend result into upper 32-bit portion register. programmer compiler) must understand when doubleword version really needed. Refer Chapter Mips more complete explanation full instruction set. More advanced assembly language programming require access user's manual specific MIPS processor e.Card.
sltiu,
Caches
pipelined processor cannot very without holding pipeline wait DRAM controller fetch instruction read memory location. Thus, MIPS architectures have utilized caches reduce time takes read write data code. cache fast, on-chip static which holds frequently accessed code data quickly available MIPS read write. Note that cache size much
January 2001
Compiling Linking Embedded MIPS Applications
smaller than external memory (DRAM) size, therefore portions external memory swapped cache memory they needed. Recall from "Address Spaces Memory Manager" page that program address determine whether access given physical address done cached uncached manner. requirements application specific access determine whether caching makes sense (e.g. accessing device, such UART, should always uncached one). MIPS contains separate code data caches, each which 32KB size. cache line bytes, this smallest portion cache that transferred from external DRAM. This transfer done 4-cycle, 64-bit wide burst cycles bytes each). This burst transfer mechanism unique cache line reads writes, therefore highest bandwidth transfer possible. Uncached accesses occur bursts, usually much slower, except small data transfers. size cache line important implications. bytes minimum size memory that cached, likewise minimum size that swapped back into external memory. Most time, programmer application need worry about cache details. However, there cases where caching desired improve DRAM transfer performance. these cases, application needs ensure that cache contents flushed external DRAM before transfer occurs over bus. These types issues dealt with "MIPS Cache Coherency Concerns Workarounds" page 2-31.
Initialization
MIPS always starts execution fetching instructions from program address BFC0.0000, which corresponds physical address 0.1FC0.0000 unmapped, uncached kseg1 section address space. This seen from previously-discussed memory tables. kseg1 section good choice, because takes safest approach avoiding cache. cache both would need properly set-up initialized before safe them (this done startup code e.Card MIPS API). first thing startup code must set-up program stack place MIPS into 64-bit mode initialize (must done even application does TLB) invalidate cache place safe ready condition) enable/disable certain interrupts perform other required hardware peripheral initializations Some these tasks involve reading writing registers. Typically, next step instruction perform absolute jump into kseg0. While target physical address very close current physical address,
2-10
January 2001
Compiling Linking Embedded MIPS Applications
important point that kseg0 cached, jump-register only move from kseg1 kseg0 (because farther than 256MB away address space). initialization steps must performed every time MIPS released from reset.
Interrupts Exceptions
term exception already been mentioned this chapter. Some examples situations that cause exception are: Interrupts, either external hardware (via Int[] pin, from UART, example) internal software interrupts (break, syscall instructions). Note that there also internal timer that issue interrupt, that might employed provide watchdog sanity-check routine event timeout situation. Using this timer involves more advanced usage MIPS consult UTMC assistance. Memory translation exceptions, most likely from bug-laden code trying access mapped memory region when being used (but, large operating systems might this exception swap virtual page from hard drive, example). Arithmetic floating-point errors, such overflow, (not number), division zero, Undefined instructions, unaligned addresses, other instruction-related errors. When exception occurs, MIPS takes following steps: restart address returned-to after exception handled) stored register, named (exception program counter). interrupts disabled (via register). Cause (CP0) register that exception handler determine exact cause exception. address exceptions, BadVAddr (CP0) register also set. Additional registers depending upon type exception. MIPS starts fetching instructions from proper address type exception. These program addresses shown Table
Exception vector address (MIPS program address) Exception Reset refill XTLB refill Cache error Interrupt Interrupt Common FFFF.FFFF.BFC0.0000 FFFF.FFFF.8000.0000 FFFF.FFFF.8000.0080 FFFF.FFFF.A000.0100 FFFF.FFFF.8000.0180 FFFF.FFFF.8000.0200 (API default) FFFF.FFFF.BFC0.0000 FFFF.FFFF.BFC0.0200 FFFF.FFFF.BFC0.0280 FFFF.FFFF.BFC0.0300 FFFF.FFFF.BFC0.0380 FFFF.FFFF.BFC0.0400 default 32-bit mode 64-bit mode Comments
FFFF.FFFF.8000.0180 FFFF.FFFF.BFC0.0380 TABLE Exception Vectors Addresses
this table, note that bits that used slightly modify exception vector locations: used place vectors (except cache errors)
January 2001
2-11
Compiling Linking Embedded MIPS Applications
into cached kseg0 region, higher response performance; used separate common exceptions from interrupts, also better handler performance. These issues dealt with "Interrupt Processing" page 2-38. Note also that refill exception will occur with MIPS 64-bit mode. Normally, exception handler, after cause been determined corrective actions have been taken (for example, reading character UART), handler needs return execution point code that interrupted. This conveniently done with eret instruction, that: Re-enables interrupts (again, register bit). Returns control address that stored (CP0). table indicates that each exception handler only instructions long (128 bytes). This might adequate simplest handler. However, order larger handler transparent, must have save registers purposes, that restore them back before returning original code. Using stack described "Other Software-Related Conventions" page 2-12 this purpose generally avoided since stack area unsafe (due cache error, etc.). Instead, exception handler uses exception frame, which agreed-upon safe area store away register contents until handler ready return. Registers ($26) ($27), convention, reserved exception handlers, since handler needs least register order save other registers arbitrary location memory.
Other Software-Related Conventions
This section describes software conventions which relate assembler compiler deal with stacks with optimizing code when accessing global static data. These issues arise later this chapter. MIPS hardware does contain true support stack (e.g. there built-in push instructions), software calling conventions need one. Therefore, register ($29) used stack pointer conventional sense, code must properly subtract appropriately. stack grows downward conventional), must always aligned 8-byte boundary accommodate doubleword loads/stores). Stack pointer register initialized e.Card MIPS startup code based special symbol _stack_addr that created linker based linker command file, discussed "Linker Command Files" page 2-22 section this chapter. final comment stacks with compilers utilize stack frames parameter passing. This topic covered Section 10.9 Mips Run. similar paradigm exists concept GP-relative addressing. Recall that loads stores register provide base-address, which 16-bit signed offset added. general sense, instructions will required perform load store arbitrary 32-bit address (one load register with upper bits, load/store providing lower bits offset). This significantly increase size execution time programs that global static data (data local function normally stored that function's stack frame). 2-12 January 2001
Compiling Linking Embedded MIPS Applications
convention used where global static data that "small" collected together same memory region. Global pointer ($28) then initialized point middle this region, that access data this region requires only single load store instruction offset used address specific data location ±32KB range. case stack, global pointer register initialized e.Card MIPS startup code based special symbol that created linker based linker command file. drawback this scheme that size this region limited 64KB; thus, assembler compiler must decide what candidates this region. Since smallersized data would have higher percentage overhead without GP-relative addressing, convention place objects less than certain size (usually bytes) into this region (but size setting modified using compiler assembler options).
e.Card MIPS Application Programming Interface (API)
UTMC provides software package with e.Card which consists startup code, library (for convenient control e.Card hardware), sample applications, utility routines using UART (e.Card serial port), related software development files. NOTE: While much source code appearing this software package will bear strong resemblance that described Mips elsewhere, this true general. differences effort clearly comment describe novices what source code doing, also code's unique history. UTMC refers this entire package e.Card MIPS API. However, library most notable piece this package, since UTCAM-Engines which distinguish e.Card's abilities. Most remaining components standard MIPS fare, though they have been tailored e.Card's hardware specifics heavily commented clarity. details MIPS library functions described Additional insight into this library gained examining source code library, well referring UTCAM-Engine Technical Summary document (available UTMC's site). will also consider e.Card address part API, since affects works applications must store data transfer data to/from host. Note that some concepts terms used here covered until "GNU CrossCompiler Environment" page 2-18. UART utility routines discussed until "Serial Port (UART) Programming" page 2-33.
January 2001
2-13
Compiling Linking Embedded MIPS Applications Software Package Layout
e.Card MIPS software package provided with e.Card starting point developers create MIPS applications. e.Card Host (for developing application running host processor) described another document. Brief explanations components mips/ top-level directory e.Card MIPS development package appear Appendix
MIPS Startup Code Walkthrough
quick walkthrough MIPS startup sequence, occurs using unmodified e.Card MIPS API, presented here help follow what source files involved. most applications, only visible step startup sequence that name application's top-level "main()" procedure must ecard_main(): host application calls Host BootCard() routine, which uploads MIPS code (from S-record file) into MIPS system DRAM e.Card. also uploads data-structure which describes sizes timing parameters DRAM memory configurations MIPS both UTCAM-Engines. After verifying integrity uploaded code, BootCard() routine de-asserts reset line e.Card, releasing both MIPS dual UTCAM-Engines from reset. MIPS begins executing code located program address BFC0.0000 uncached region kseg1, which physical address 0.1FC0.0000. reset vector file label reset. This first instruction immediately jumps label _start. Note that exception handlers appear below this reset vector code, part startup sequence. Procedure _start assembler routine also file This routine first sets stack pointer global pointer based linker command file settings. _start then calls _init_mips subroutine. Procedure _init_mips assembler routine also file This where initialization takes place (placing MIPS into 64-bit mode, among other things). Before returning back _start, _init_mips first calls subroutines Cache_Invalidate_ICACHE() Cache_Invalidate_DCACHE(), which part library. Because contents on-chip cache memory powered-up with random data, Cache_Invalidate_ICACHE() Cache_Invalidate_DCACHE() routines must initialize instruction data caches, respectively, fresh cleared state, ready begin caching memory accesses. Note that these routines actually library functions linked from library. _init_tlb assembler routine makes sure that TLB's mapping registers (which also power-up with random data) initialized that inadvertently mapping anything. This desirable that during debugging, illegal memory location access will always cause XTLB exception occur, resulting debug-port message clearly alerting developer problem. January 2001
2-14
Compiling Linking Embedded MIPS Applications
Once control returned back _start, certain interrupts (such external UART interrupt) then enabled (via register bits), depending upon application's requirements. _start then explicitly performs jump-register procedure _start_user(), based linker address this procedure. This significant, since linker command file defines this routine being region kseg0 MIPS address map, which cached, jump-register instruction only kind that jump enough from kseg1 kseg0. Procedure _start_user() routine also file ecard_init/mips_startups.c. This routine starts using data-structure eCardMemConfig (which previously been uploaded Host routine BootCard()) properly initialize both UTCAM-Engines based host's memory configuration file. Once UTCAM-Engines have been initialized, main application routine ecard_main() then called (while also passing down single application-definable BootCard() parameter), startup completed.
ecard_main() some point needs issue handshake back Host issuing CardReady() call, telling host application that e.Card application finished necessary setups initializations, ready start receiving data transfers processing, etc. This step-by-step description actually glosses over concepts related assembly code interact between each other with cross-compiler toolset (such calling conventions, linker directives sections, on). "GNU CrossCompiler Environment" page 2-18 revisits these issues more useful details, reference texts.
Tour e.Card Address
Most details e.Card address affect application developed. APIs able correctly deal with most these hardware details, applications discouraged from accessing hardware resources directly. However, DRAM portions address influence application planned, since default linker command file conservatively work with smallest 32MB SO-DIMM configuration. Larger e.Card configurations 256MB SODIMM) likely have different linker command file, mainly allow programs have much larger regions memory available code, data, allocation heap, NOTE: references DRAM memory relation e.Card address always mean MIPS system DRAM. contrast, UTCAM-Engine DRAM subsystems (four DIMM sockets, through SK4) completely independent from this address only accessed UTCAM-Engine commands. Appendix contains tables describing e.Card address details. Note that only physical addresses listed these tables. There basically different ways access particular physical addresses:
January 2001
2-15
Compiling Linking Embedded MIPS Applications
MIPS uncached accesses: previously described "Address Spaces Memory Manager" page section, 32-bit physical addresses accessed uncached manner kseg1 region (however, note that this region actually ckseg1 since always uses MIPS 64-bit mode). MIPS program virtual address will thus physical address ORed with A000.0000 (which signextended bits internally). MIPS cached accesses: same token, 32-bit physical addresses accessed cached manner kseg0 region (ckseg0, actually). MIPS program virtual address will physical address ORed with 8000.0000. Host accesses: host access DRAM resources using Host calls transferring memory from e.Card. These functions passed either DRAM physical address MIPS program virtual address 32-bit e.Card address function will mask MSBs either way. Note that direct access e.Card resources from host processor without using Host supported. final characteristic worth mentioning separate MIPS system DRAM regions address map. SO-DIMMs come "single-sided" "double-sided" varieties "stacked" term that sometime used instead "double-sided". "Double-sided" indicates that SO-DIMM actually functions individual DIMMs, which address regions shown. Note that region described SO-DIMM "Side-1" will enabled "single-sided" SO-DIMM configuration. Notice that SO-DIMM configurations, MIPS system DRAM always ends with physical address 1FFF.FFFF always contiguous (with gaps) entire memory range, even "double-sided" configurations. Thus, embedded applications have uniform DRAM resource their disposal, linker command file only thing needing modification allow applications utilize entire DRAM. However, advanced application needing high-performance interrupt handling wish relocate SO-DIMM "Side-1" this issue introduced "Interrupts Exceptions" page 2-11 discussed detail "Interrupt Processing" page 2-38.
Limitations
effort been made make library flexible enough most applications, while remaining performance-efficient. However, should aware limitations. most cases, only remedy these limitations will custom coded effort which likely requires assembly language techniques. library calls presently arranged separate source files, thus compiled into common object files. Because this, linker will include instruction library calls into final application, even most functions ever used. this becomes concern memory limitations, example, then contact UTMC assistance.) elemental routines ReadCAM() WriteCAM(), which read write UTCAM-Engines, must written assembler. This because full 36-bit physical address needed address UTCAM-Engines, e.Card MIPS only utilizes 32-bit pointers (which done reduce overall code size execution January 2001
2-16
Compiling Linking Embedded MIPS Applications
time). While this really limitation, will require custom coding implemented assembler direct UTCAM-Engine accesses ever necessary. Note that routines contained file utcam_api_asm_cam.S these elemental routines instead written completely assembler. This done performance reasons, also work around erratum which presently exists UTCAM-Engines. calls conform parameter-passing conventions, therefore some cases) stack frame used pass parameters. Extra MIPS cycles needed prepare registers (possibly) stack frame with passed parameters. faster solution might instead implement most time-critical inner-loop routine assembler, directly reading writing UTCAM-Engines without additional overhead. NOTE: Note that commands, must preserve strategy employed AddDiscreteRecord_ASM() AddPrefixRecord() routines avoid UTCAM-Engine erratum ER#11. routines utilize UTCAM-Engine hardware interrupts all. While this possible with e.Card, most MIPS applications will primarily using UTCAM-Engines process incoming host data, will involved other processing that would justify overhead interrupt service routine. related reason described next section.
Exception Handler Limitations
Recall that exception handlers need able deal with multiple categories exceptions. absence hardware interrupts, exceptions will only occur unexpected event code, such address, unaligned access violation, illegal op-code, arithmetic overflow. exception handlers provided with e.Card MIPS very basic, that they will report certain register contents UART, either return exceptioned code loop indefinitely. examine this source file reset_exhandler_tlb.S. common exception vector takes care general exceptions well interrupts. Some rudimentary code been provided which examines MIPS Cause register determine precise cause exception, transfers control appropriate interrupt-specific handler. Otherwise, passes control default handler. Source code these specific handlers located source file mips_startups.c, however, these routines presently used, only provided crude prototypes. primary problem with relying upon exception handlers high-performance interrupt servicing that exception handlers located uncached memory location. Therefore, performance will prohibitively slow once interrupt occurs. Observant readers will point that exists register which changes interrupt exception vector (and most other vectors) instead located alternate cached memory location. While this true, poses practical problem related MIPS system DRAM located e.Card address map. January 2001 2-17
Compiling Linking Embedded MIPS Applications
problem that part DRAM must located boot location, located high physical address 0.1FC0.0000, another part would also need located interrupt vector's cached physical address 0.0000.0180. contiguous DRAM this deep (512MB), thus only this possible would with dual-stack SO-DIMM memory module. dual-stack module would provide different banks DRAM, which could then mapped different high ends e.Card address map. card dual-stack SO-DIMM, then address could changed allow high-performance, cached interrupt handler. feel that your application requires this, then contact UTMC, since this re-mapping involves non-trivial host-driver changes.
Cross-Compiler Environment
cross-compiler special type compiler which runs type processor platform, generates code different type, this case MIPS processor used e.Card. UTMC uses Compiler Collection (GCC) toolset this purpose. This document does intend reference this toolset, instead introduces developer usage flow only discusses those details that relate e.Card. minimum, member application development team would need familiar with Makefile concepts assembler basics. General information references these development tools available either Internet (refer Table "Third-Party Publications," page -vi) from bookstores. cross-compiler environment primarily consists following programs: gcc: This most commonly thought language compiler; source code compiled into assembly code which then assembled with However, also used process assembly language source files with also runs pre-processor both assembly code. Therefore, executed these purposes, command-line options used pass options these other programs. This assembler (aka gas), never executed directly; instead, calls passing applicable command-line options using -Wa, flag. cpp: pre-processor used both assembly code files. handles basic details such expanding directives (e.g. #define, #ifdef, etc.) removing comments. assembly code files e.Card MIPS pre-processed before assembly, therefore comments equates coded using conventions. Note that never called directly; instead, calls passes applicable command line options cpp. linker combines multiple object files into single executable, resolving external global references between object files while checking conflicts. also uses linker command file determine absolute addresses memory objects (code, data, stack, heap, etc.). Note that while call automatically link after compiling, e.Card MIPS flow runs separately after source files have been compiled and/or assembled into object library files.
2-18
January 2001
Compiling Linking Embedded MIPS Applications
make: This program which uses Makefile which contains commands, options, filename relationships carry steps necessary correctly produce final executable application. Note that normally make which runs among other things. make very useful here since checks file dates determine, example, re-compile necessary since source file been modified since last compile (i.e. object file's date older than source file's date). make also able include project-wide definitions (e.g. options filesystem paths) from common included file, well take care project-specific idiosyncrasies. ranlib: combines compiled assembled object files into single archive file, while ranlib extracts index symbols defined each these object files stores index into this same archive. result what commonly known library function calls. Each application's development environment will include following types files: assembly code: Files with extension contain assembly language. Typically, only those MIPS instructions related either initial MIPS configuration exception handling need implemented with assembly language. Writing assembly language require very tedious detailed effort, should avoided when possible. Most applications will need deal with this. Note that capitalized extension indicates that e.Card MIPS assembly language source files will automatically pre-processed with before being assembled code: Files with extension contain programming language code. (The e.Card MIPS does embed assembly code within file.) headers prototypes: terms header prototype sometimes used interchangeably. They refer files with extension, which usually contain definitions (data types #define's) function prototypes which often shared multiple source files using #include directive. libraries: library file (extension collection function calls provided linker resolving function calls application. These function calls have been written either assembly code, have already been compiled assembled. linker command file: linker command file (extension .ld) informs linker what address ranges various code data sections should located (sections explained "Linker Command Files" page 2-22), also creates labels used MIPS startup code global pointer, stack, heap, etc.). makefile: makefile always name Makefile (though advanced user could override this), carries steps necessary completely build final executable binary file. actually more powerful than simple script batch file. S-records: S-record file (extension .srec) represents binary data text format, useful industry-standard format describing data pattern. this case, represents executable application (i.e. code initialized data) ready upload MIPS system DRAM. Unlike many embedded processor systems, e.Card does contain EPROM Rather, application code (initialized) data uploaded MIPS system DRAM e.Card while MIPS held reset, reset released once January 2001 2-19
Compiling Linking Embedded MIPS Applications
code data been verified uploaded without errors. this done from host application Host library's BootCard() function. NOTE: options linker command files provided part e.Card MIPS must modified without complete understanding their implications.
Sections Relocation
When application compiled, compiler typically groups different types memory elements together. example, executable code elements grouped together while data elements (variables, structures, arrays, etc.) grouped together separately from code elements' group. These groups commonly known sections. compiler goes step further allowing additional groups with more specific meanings, such keeping initialized data separate from uninitialized data, There traditional sections with predefined names, there also user-defined groups with custom names meanings attributes directives assembler) embedded source code instruct what section each function variable should placed default behavior acceptable most cases. Sections provide convenient group together related elements refer them common name. given section unique name consists block data with gaps Until final linking step building application, section does belong particular address. e.Card MIPS environment uses sections, Table summarizes each section's name purpose, alphabetical order:
Section Name .bss COMMON .data .init .lit4 .lit8 .rodata Purpose "large" local static-uninitialized zero-initialized data "large" global uninitialized zeroinitialized data "large" non-zero-initialized data only contains startup code, functions, data float (32-bit) constants double (64-bit-floating point) constants read-only data "small" local static- uninitialized zero-initialized data Comments initialized zeroes startup initialized zeroes startup "large" consists whatever "small" unique e.Card MIPS uses global-pointer (gp) addressing uses global-pointer (gp) addressing e.g. string constants some global constants
.sbss
"small" defined option; initialized zeroes startup; uses global-pointer (gp) addressing TABLE e.Card MIPS Relocatable Sections
2-20
January 2001
Compiling Linking Embedded MIPS Applications
Section Name .scommon .sdata .text Purpose "small" global uninitialized zeroinitialized data "small" non-zero-initialized data Comments uses global-pointer (gp) addressing; initialized zeroes startup "small" defined option; uses global-pointer (gp) addressing
contains non-startup code application code will .text TABLE e.Card MIPS Relocatable Sections
embedded applications, sections provide convenient control where various memory elements mapped into system DRAM. linker command file contains instructions which tells linker where MIPS' program address each section should begin. linker command file will discussed later. Until linking step building application, each these sections thinks that starts address elements that section located positive address offset increasing from zero. However, when linker arranges sections into MIPS program address map, addresses these elements becomes non-zero unique order prevent kind overlap (which would result program corruption). This arranging sections linker known relocation. Note that sections .bss .sbss will automatically initialized zeroes MIPS startup code that provided e.Card MIPS API. compiler aware this, will only place either uninitialized zero-initialized data these sections.
Assembly Language Programming
Assembly code source files always have filename extension conventions, this indicates that file assembly code file that requires pre-processing cpp, which correct since e.Card MIPS uses C-style comments directives within assembly code files. final linking step does occur until other source files have been compiled and/or assembled Makefile. Writing embedded applications assembly language will extremely rare, even modifying MIPS startup files ecard_init/) will only necessary advanced custom applications most applications will entirely developed There assembler options that interest developers. They used modifying ASFLAGS= definition application's Makefile:
num: Tells assembler place data types that less than equal bytes (with sizes defined .comm, .lcomm, .extern directives) into .sdata .sbss sections instead .data .bss sections. Items which qualify then accessed using global pointer (gp) faster accessing; however, global pointer only access 64KB data linker will issue failure message this occurs. default value NOTE: This exact same option must also given linker modifying LDFLAGS= definition, also application's Makefile.
January 2001
2-21
Compiling Linking Embedded MIPS Applications
assembler uses directives give developer control over many things directives reserved keywords that begin with period. example, .section name directive used instruct assembler which section subsequent code will assembled into. There also directives .text, .data, which predefined .section .text|.data directives, .lcomm which defines symbol (data) .bss section (.comm slightly different that symbol expected merged with same symbol name from different object file, i.e. shared symbol). Additional information options found manual Assembler, link which found Table "UTMC e.Card Publications," page -vii.
Programming
code source files always have filename extension source files compiled assembled, final linking step does occur until other source files have been compiled and/or assembled Makefile. There compiler options that interest developers. They used modifying CFLAGS= definition application's Makefile:
num: Tells compiler place global static data types less than equal bytes into .sdata .sbss sections instead .data .bss sections. Items which qualify then accessed using global pointer (gp) faster
accessing; however, global pointer only access 64KB data linker will issue failure message this occurs. default value NOTE: This exact same option must also given linker modifying LDFLAGS= definition, also application's Makefile. compiler uses attributes give developer control over many things, notable attribute section attribute. This allows developer override usual section that used object, which function, variable, type declaration. example, following function will placed into .init section:
void forced_into_init(void) _attribute_ ((section (".init")));
Note that functions, this attribute must only applied function prototype, function's definition. Additional information options found manual Using Porting GCC.
Linker Command Files
linker command file (abbreviated LCF, also known linker script) critical component embedded application since instructs linker where MIPS program address should placing various types code data structures. linker command file conventionally filename extension .ld, referenced LDFLAGS= application-specific Makefile. most applications, only items that need modification
ORIGIN= LENGTH= parameters specified MEMORY{} section LCF.
2-22
January 2001
Compiling Linking Embedded MIPS Applications
This allows developer adjust memory region sizes code data, either because special needs application, because application uses e.Card configuration with larger-capacity SO-DIMM (and thus larger MIPS system DRAM size). Appendix describes DRAM memory address ranges various e.Card SO-DIMM configurations. NOTE: ORIGIN= parameters always MIPS program virtual addresses, physical addresses. Refer Tour e.Card Address Map" page 2-15 explanation this. following table describes provided with e.Card MIPS will arrange various sections application within MIPS system DRAM. Note that this default designed work with minimal 32MB SO-DIMM configuration:
MIPS Program MEMORY{} Virtual) Maximum Region Address Size Name Range (bytes) 9FFF.FFFF 9FFF.F000
Linker Section Name .init
Description reserved exception handler exceptionframe area reserved startup code (e.g. memory config parameters) MIPS boot vector, exception handlers, startup code, queues
Comments Warnings must never used developers (except possible replacement exception handler) must used developers
INIT
9FFF.EFFF 9FFF.E000
.init
9FFF.DFFF 9FC0.0000 9FBF.FFFF
3.992M (4088K)
.init
must used developers
.rodata
CODE
.text 9F80.0000 TABLE e.Card MIPS Default Linker Command File Memory
traditionally placed CODE region since never written
January 2001
2-23
Compiling Linking Embedded MIPS Applications
MIPS Program MEMORY{} Virtual) Maximum Region Address Size Name Range (bytes) 9F7F.FFFF DATA 9F20.0000 9F1F.FFFF 9F00.0000
Linker Section Name COMMON
Description uninitialized does appear Srecord file uninitialized does appear Srecord file uninitialized does appear Srecord file uninitialized does appear Srecord file
Comments Warnings zero-init'ed startup code zero-init'ed startup code zero-init'ed startup code GP-relative zeroinit'ed startup code GP-relative
.bss
.scommon
.sbss sdata .lit4 .lit8 .data
only appears floating-point apps only appears floating-point apps
GP-relative GP-relative
defines label _stack_addr there mechanism bottom prevent stack overflow DATA
defines labels _heap_addr heap "pool" (e.g. _heap_end malloc() calls) bottom TABLE e.Card MIPS Default Linker Command File Memory 9EFF.FFFF 9E00.0000
Notes this table: Refer table "Sections Relocation" page 2-20 explanation linker section names. Each linker section contiguously arranged previous section within given MEMORY{} region. Linker sections always aligned 16-byte boundaries. highest address actually utilized within each MEMORY{} regions will depend upon application itself. unused upper portion each region will contain unknown data once application booted (via BootCard() Host function). register value linker symbol _gp, which 8-bytealigned address just above .data section. January 2001
2-24
Compiling Linking Embedded MIPS Applications
Additional information options syntax linker program found manual Linker.
Makefiles Build Application
Makefile functions like batch script file does, that methodically performs individual steps needed take source code files linker command file assembles, compiles, links them into final executable binary file (actually S-record file). Makefile usually application-specific executed simply running make application directory make will process file named Makefile exists, fails does not. build sample applications: Change your current directory that application wish build. Check verify that file named Makefile exists that directory. make clean command line this will remove previously compiled results prepare directory fresh build. make command line with options (this assumes that already been installed configured, that your command search paths have been properly up). will have files your directory. most important Srecord file appname.srec, since will needed Host BootCard() library function upload application code data e.Card's MIPS system DRAM. next section will into more detail about usefulness these files.
Finally, should noted that many cases, there will Makefile higherlevel directory which, when executed using make, will move recursively though subdirectories Makefiles those sub-directories. This useful building large, modular projects. Makefile directives options that application-independent (i.e. which need same e.Card applications) appear file defines.mak, which must included application Makefiles. developer should fully competent Makefile concepts including variables used implicit rules before making changes defines.mak.
This chapter intended make reference. Additional information options make found manual Make. Refer Table "Third-Party Publications," page information obtain copy.
Files Created Build Process
After executing Makefile build final application, will have output files directory: S-record file industry-standard format specifying byte-oriented data, which then either programmed into PROM uploaded embedded processor system. Each line consists token (S3, etc.), followed 2*.srec:
January 2001
2-25
Compiling Linking Embedded MIPS Applications
character value byte count that line, followed 8-character 32-bit address, followed sequential byte data (two characters byte), ends with two-character byte value checksum line. Note that these 32-bit addresses indicate MIPS program address, physical address. This because linker generates S-record file based linker command file, which must represent MIPS program addresses, necessary when MIPS sets registers, among other things. Host API's BootCard() library call will convert these into physical DRAM addresses suitable uploading e.Card's interface. *.LIST: This disassembly listing entire application, broken procedure assembler-label boundaries (objdump program used generate this listing). MIPS program address left column, followed 32-bit instruction (little-endian), disassembled instruction mnemonic. Note that many cases, this listing will show disassembly text strings initialized data, which should generally ignored. *.SYMBOLS: This listing variables, functions, linker symbols their addresses program used generate this listing). convenient that sorted increasing address. (Note that some symbols, particularly non-static local variables some read-only constants, will appear name this file .MAP file, don't forget that uninitialized locals stack frame.) letter code used indicate type symbol lowercase letters indicate local symbols, while uppercase letters indicate global external) symbols. should only encounter following letters: symbol absolute value (e.g. LCF-defined symbols) symbol uninitialized data (e.g. .bss) symbol initialized data (e.g. .data) symbol initialized GP-relative data (e.g. .sbss) symbol read-only data (e.g. "const" declaration symbol uninitialized GP-relative data (e.g. .sdata) symbol code (e.g. .text) symbol unknown this will true symbols .init section *.MAP: This linker report, difficult understand, which other files have been generated they easier look
Debugging Techniques
There multiple ways debug applications running MIPS processor. most manual method combine following techniques: UART library calls output text strings characters interspersed with
puthex2(), puthex16(), etc. function calls. Thus, MIPS application output
numbers strings help determine what going program code. These puthexN()-style functions defined source file ecard_init/mips_startups.c, there versions (the number
2-26
January 2001
Compiling Linking Embedded MIPS Applications
nibbles 4-bit characters output) equalling Note that examples using these function calls available utcam_api/test subdirectory package tree. exception occurs, this will indicated UART output appearing serial monitoring terminal screen. next section will help understand interpret significance information that generated exception. this time, PMON debugging support available. UTMC plans support them forthcoming release software development package.
Exception Messages from UART
discussed "Interrupts Exceptions" page 2-11, exception occur various reasons. default exception handlers provided with e.Card MIPS package generates messages resembling example shown following figure:
General EXCEPTION!! CR(13) EPC(14) BadVAddr(08) SR(12) 0x80808014 0xFFFFFFFF9F800458 0xFFFFFFFF9F200042 0x34410081
this example, unaligned store operation MIPS program address 0x9F200042 occurred, store instruction branch delay slot following branch jump instruction MIPS program address 0x9F800458 (thus instruction actually address 0x9F80045C). Read find decipher this yourself! Note that there also additional text, depending upon whether exception hardware interrupt, etc. Refer exception handler source code file complete details. Here generally interpret message values four MIPS control coprocessor (CP0) registers displayed most exception messages: Cause Register describes specific cause most recent exception. fields this register described following figure:
positions: name: width: IP[7:0] ExcCode
fields this register are: this indicates that exception occurred branch delay slot (see description Register). Coprocessor number, event Coprocessor Unusable exception. Enables dedicated interrupt exception vector (see Table 12). IP[7:0] Indicates interrupt pending (refer "Interrupt Processing" page 2-38 section this chapter).
January 2001
2-27
Compiling Linking Embedded MIPS Applications
ExcCode Exception Code field, which specifically describes cause exception. following tables lists possible values:
ExcCode value
Mnemonic TLBL TLBS AdEL AdES -FPE
Description Interrupt modification exception exception (load instruction fetch) exception (store) Address error exception (load instruction fetch) Address error exception (store) error exception (instruction fetch) error exception (data reference: load store) Syscall exception Breakpoint exception Reserved instruction exception Coprocessor unusable exception Arithmetic overflow exception Trap exception Reserved Floating-Point exception Reserved TABLE Exception Codes
Notes Common Causes hardware software interrupt access unmapped address
most commonly unaligned address parity error time-out (i.e. hardware error) results from syscall instruction results from break instruction attempt execute undefined instruction op-code attempt execute instruction non-existent coprocessor caused non-u (non-unsigned) arithmetic instruction caused trap-type instruction used floating-point coprocessor
Exception Program Counter Register contains MIPS program address instruction that direct cause exception. However, Cause Register set, contains program address branch jump instruction immediately preceding instruction that caused exception. BadVAddr Virtual Address Register contains most recent virtual MIPS program) address that caused either Address Error exception type. Status Register contains various operating mode, interrupt enabling, diagnostic state settings MIPS processor. will describe details here, since they typically significant understanding nature exception (unless enabling utilizing interrupts MIPS, which case should have access RM5200 Family User Manual).
2-28
January 2001
Compiling Linking Embedded MIPS Applications
Once have determined address instruction causing exception, then refer .LIST .SYMBOL files that were generated your Makefile understand nature problem.
PMON
(TBD)
(TBD)
Host/e.Card Handshaking Data Synchronization
Handshaking between host processor MIPS processor needed allow processor signal alert other that some form activity requested completed. e.Card supports across interface efficient, low-latency, bidirectional handshaking mechanism (I2O stands Intelligent Input/Output, industry-standard method efficiently passing messages between devices bus.) application will provided handshaking functions exchange messages with other application other processor). Data synchronization issues exist high performance nature hardware e.Card. hardware achieves this high-performance employing FIFO buffering caching techniques. Here some examples: FIFO buffering: This technique used either allow device continue read more data ahead what really needed prefetching), gather small portions data merge them into higher-bandwidth burst access. There places where this occurs: between e.Card's interface MIPS system DRAM, within bridge devices that make host system's infrastructure (e.g. motherboard's chip-set). caching: MIPS processor caches data accesses external memory that done cached kseg0 region address map. This desirable since significantly increases speed performance, side effect leaving modified data within cache MIPS which reflected external DRAM. effects these mechanisms must considered when transferring data between host processor MIPS processor e.Card. e.Card commonly used on-demand data processor, high-importance that data transferred from processor processor quickest manner, with minimal delay. Data that being held FIFO increase this delay allowed transferred casual, default pace. More critically, both processors must aware these issues order ensure that important data still lingering cache FIFO, that correct data acted upon instead stale, incorrect data.
January 2001
2-29
Compiling Linking Embedded MIPS Applications
Fortunately, both APIs provide functions which allow applications perform efficient handshaking, force FIFOs empty pending data still held them, perform cache maintenance operations. This section will further describe these three situations will describe techniques functions needed avoid problems maximize performance. final section touches related compiler issues.
Handshaking Methods
While possible processor agreed-upon DRAM location message flag convey handshake other processor, this technique will have excessive overhead latency fact that this DRAM better suited larger bursts data transfer. Instead, application should capitalize mechanisms pass messages between processors. There three basic message types available: messages: Used send receive short 32-bit messages across bus, these simplest mechanisms understand. When message register written processor, interrupt optionally generated other processor, which should then retrieve message data. message register each direction (four total) available. doorbells: Similar message registers, when least 32-bit doorbell register set, interrupt optionally generated other processor. distinction from message registers that doorbell registers geared towards setting clearing individual bits alert other processor e.g. status flags), rather than writing 32-bit words. doorbell register available each direction. circular queues: This allows processor submit 32-bit entries head queue, optionally causing interrupt other processor which then able fetch next entry from tail same queue. circular queues, post queue free queue, available each direction (four total), each range size from entries. Post queues contain request-related data, while free queues data that posted response request opposite direction post queue). Note that while data storage queues located MIPS system DRAM, they still provide efficient mechanism hardware support head/tail pointer maintenance interrupt generation. Terminology needed clearly indicate direction message. Inbound refers message from host processor MIPS, while Outbound means from MIPS host processor (i.e. MIPS always inside "bound"). example, Outbound doorbell means that MIPS least doorbell register, possibly causing interrupt host processor, host subsequently should read outbound doorbell register determine which MIPS. Circular queues confusing. example, while Inbound Post queue contains messages from host MIPS process, Inbound Free queue intended messages from MIPS back host response incoming circular queue message. convention here that Inbound queues intended host2-30 January 2001
Compiling Linking Embedded MIPS Applications
initiated requests, with request data being issued Inbound Post queue response data returned back host Inbound Free queue. Likewise, Outbound queue intended MIPS-initiated requests. details support functions described Chapter Chapter this document. types function calls provided: setup functions: Used configure each type message whether generates interrupt, also configure depth circular queues. These functions only need called once each type message, message doorbell types interrupts desired (the default behavior). action functions: These cause actual reading writing message registers queues occur. interrupt generated other processor, depending upon whether enabled that message type. NOTE: MIPS interrupts presently supported APIs. Thus, Inbound messages type cannot cause interrupt MIPS, setup functions provide this ability. MIPS typically ondemand role, this expected cause performance issues. "Exception Handler Limitations" page 2-17 explanation this been done.
Sychronization Issues
When host processor performs write operation e.Card, sequence operations occurs across bus. least, controller host controller e.Card involved. These controllers permitted industry standard) buffer some these operations interest improving overall average performance over bus. However, this improvement often realized only larger sequences data transfers. These controllers take approach waiting after each access another contiguous access follows controller e.Card itself, consecutiveaddress writes queued FIFO until 64-byte burst performed more efficiently MIPS system DRAM. Latency becomes issue when only part this FIFO filled, MIPS needs data start processing Fortunately, Host provides function FlushPCI() which typically should called after last data transfer occurred before MIPS issued handshake begin processing. This function described Chapter this document.
MIPS Cache Coherency Concerns Workarounds
Caches cause headaches shared memory system. MIPS system DRAM indeed shared memory because accessed both MIPS host. While host does cache MIPS system DRAM, MIPS itself can, this cause coherency issues. Coherency thought consistency,
January 2001
2-31
Compiling Linking Embedded MIPS Applications
lack consistency occurs when, example, MIPS updated data data cache, host accesses shared memory thinking that reading updated data, instead host reads stale data data that really wanted still MIPS' data cache. There basic scenarios this issue: stale data MIPS cache: This always means MIPS' data cache, occurs when host updates DRAM while same cache-line already resides cache. Thus, subsequent MIPS accesses that address will now-stale cacheline, will updated data from host. stale data DRAM: This occurs when MIPS updates data cache, subsequent host access that address will updated data still cache. This issue only applies when MIPS accesses memory cached manner, accesses kseg0 region MIPS address map. However, cached accesses very desirable from speed perspective, fact that DRAM burst-transfers only occur cached reads writes. addition stale, there other term which useful dirty. cache-line marked dirty when been changed (written MIPS eventually needs written back into external memory. Eventually mean when newer data needs read into same cache location, when application intentionally wants Fortunately, cache controlled from MIPS application using useful operations: write-back: cache line marked dirty, then written back into external memory, otherwise this operation nop. invalidate: cache line marked invalid, data will used again. cache location freed loading cached memory location. possible both write back invalidate together, also possible invalidate dirty cache line, which would likely cause loss data. UTMC plans supply cacheWBackRange() cacheInvalidateRange() library calls, which will take program address byte length parameters apply respective operation corresponding data cache-lines. This will provide MIPS application with ability fully utilize speed caching while still ensuring data integrity transfers. These routines will available next major revision software package. There final hazard related caches. program tries perform both cached uncached accesses same memory locations, then uncached accesses bypass cached data those same locations, creating coherency problem. other words, uncached accesses check cache first, thus create situation where either cache, read, containing stale data. solution here divide address into cached uncached regions, which cache-line boundary bytes), keep them completely separate. Section 11.7 Mips goes into further detail these subjects.
2-32
January 2001
Compiling Linking Embedded MIPS Applications Related Compiler Issues
important problem arise programming language when dealing with shared memory locations that accessed applications both MIPS host. default, compiler assumes that only "thing" that change given memory location. Thus, believes that unless explicitly written location itself, then data that location cannot change. example this looping until memory location becomes non-zero (e.g. flag variable) compiler thinks that only read location once, further loop iterations need re-read that same memory location ever again, because nothing else should modifying data that location. Obviously, there problem with this behavior MIPS will never notice that host processor changed data this memory location! Note that this issue unrelated caching issues, purely problem with assumptions compiler. This a
Other recent searches
ZFDC-10-21 - ZFDC-10-21 ZFDC-10-21 Datasheet
SPB-4810LWG - SPB-4810LWG SPB-4810LWG Datasheet
RC7144 - RC7144 RC7144 Datasheet
R3600-02 - R3600-02 R3600-02 Datasheet
R3600-02 - R3600-02 R3600-02 Datasheet
R3600-06 - R3600-06 R3600-06 Datasheet
L120TR5N-LC - L120TR5N-LC L120TR5N-LC Datasheet
JRC0428 - JRC0428 JRC0428 Datasheet
Privacy Policy | Disclaimer
© 2012 Datasheet Archive
