Patent Grant
7020723
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
This invention relates to a serial, low pin count communications interface that enables the extension of an internal Common Bus Architecture (CBA) bus segment to one or more external physical devices and more particularly to a method of allowing multiple, hardware embedded configurations to be recognized by an Operating System in an independent manner.
The communication to and from both home and office is undergoing a change to provide both cable and DSL broadband access. It is highly desirable to provide a common computer/software/peripheral platform architecture across cable, DSL, IEEE 802.11, IP phone and voice gateways. A communications processor architecture includes a 32-bit MIPS processor, a switched bus architecture, a distributed DMA architecture, optimized memory interface, programmable memory management and write back or write through cache write policy. The software platform for the services includes device drivers (USB, PCI, Ethernet, HDLC, Timers, 802.11 etc.), RTOS support (VxWorks, Linux, Nucleus etc.), networking software (ATM, TCP/IP, bridging, routing, filtering etc.), network management (SNMP, web servers/stacks), PC drivers, and robust APIs with clearly defined software layers for customers to add value. A communications chip for all of these markets becomes costly. Texas Instruments Inc. built a product that has two DSPs for voice, many interfaces, a mixed signal processor, RAM, a MAC, a complete segmentation re-assembly (SAR) engine for ATM, HM interface, a broadband interface, memory interface and a VGA. The result is a product that has 256 pins and the chip becomes costly. This is also not very expandable because any expansion peripherals must be placed on the memory bus, which consumes memory bandwidth that is critical to the operation speed of the CPU. This also means that access to the peripheral is in the asynchronous cycle, which is slow as compared to DRAM. A 16-bit bus could be added with 32 pins but that is costly and would have a limited memory range. Many developers for products in these areas do not want to pay for such a costly chip with excess functionality. We have had to disable features on the chip but the customer still has to pay for features not used.
It is highly desirable to provide platforms for market segments wherein the main function is functionally integrated and an expansion capability is provided via a low cost, software compatible communications link.
Texas Instruments Incorporated provides for this by providing a serial, low pin count communications interface that enables the extension of an internal Common Bus Architecture (CBA) bus segment to one or more external physical devices. This is known as VLYNQ and it accomplishes this function by serializing bus transactions in one device, transferring the serialized transaction between devices via a VLYNQ port, and de-serializing the transaction in the external device. Multiple VLYNQ modules may be included on a single device such that VLYNQ devices are effectively daisy chained.
Referring to
As illustrated in
An example of an application enabled by VLYNQ is a low cost derived voice application, allowing one or more C55x DSP devices to connect to an a Texas Instruments Inc. Avalanche Broadband Controller over 3-pin serial interfaces. For more information of VLYNQ, refer to application Ser. No. 10/382,679 filed Mar. 6, 2003 entitled “Communications Interface”. This application is incorporated herein by reference.
Successfully connecting VLYNQ devices requires an in-depth knowledge of the hardware module and accompanying register set. It is therefore highly desirable to provide a method to aid in connecting the devices.
In accordance with one embodiment of the present invention, an in-depth knowledge of the hardware module and accompanying register set is provided by abstracting these details and automatically configuring the module in the system.
In accordance with an embodiment of the present invention a method of allowing multiple, hardware embedded configurations to be recognized by an operating system in a root device comprises the steps of recognizing and utilizing multiple embedded hardware configurations in remote devices and making the configurations recognizable by an operating system in an independent manner.
In accordance with an embodiment of the present invention an enumerator discovers all remote devices and creates address and interrupt maps between remote devices and a root device.
In accordance with an embodiment of the present invention an enumerator reads a remote device identification register and locates associated device configuration file and then determines if the remote device has more than one interface module and if there is more than one interface module, recursively performing the previous steps until the end of the interface chain is reached.
In accordance with an embodiment of the present invention, a communication system for enabling extension of an internal common bus architecture (CBA) bus segment of a first root device to an internal CBA bus segment of a second device includes a module in the first device and a module in the second device and an external cable between these modules. The first root device includes an enumerator for automatically configuring for said second device module or more modules and/or external devices to be added to the system by a recursive discovery and configuration algorithm.
VLYNQ is a serial, low pin count communication interface that enables the extension of an internal Common Bus Architecture (CBA) bus segment to one or more external physical devices. VLYNQ accomplishes this function by serializing bus transactions in one device, transferring the serialized transaction between devices via a VLYNQ port, and de-serializing the transaction in the external device.
Referring to
Throughout this document, references are made to VLYNQ “gateways” and “portals”. The definition of a VLYNQ gateway is a VLYNQ module on a remote device that is the first one encountered when traversing out from the root device. Each device, therefore, has a single VLYNQ gateway module. All other VLYNQ modules on each remote device are termed “portals”.
Several references are made to VLYNQ “branches”. A branch is defined as all of the remote VLYNQ devices connected to a single root VLYNQ module. This includes the directly connected device and any daisy-chained devices connected from that point.
Successfully utilizing VLYNQ would normally require an in-depth knowledge of the hardware module and accompanying register set. The purpose of the VLYNQ enumerator is to abstract these details from the higher-level software developers, freeing them to focus on applications.
The VLYNQ enumerator software 33 automatically configures each VLYNQ in the system 30, creating a unified view of the system from the software perspective. Developers need little or no knowledge about VLYNQ hardware. The enumerator 33 operation is designed to be executed during system boot, and requires no intervention on the part of the user. The only required inputs are properly formatted device configuration files for each VLYNQ device in the system. The format of these files is specified in later in the specification under Device Information Files. The output of the enumerator 33 is an output file that contains address maps and interrupt information for each device (37 and 38) and VLYNQ module discovered in the system 30. This file is discussed in more detail later in The Output File.
The heart of the VLYNQ enumerator 33 is a recursive discovery and configuration algorithm. It discovers all remote VLYNQ devices like 37 and 38 and creates address and interrupt maps from remote devices back to the root device. The VLYNQ module has flexible, built-in facilities for address translation and interrupt forwarding. Based on the identities of the discovered VLYNQ devices (and their associated device information files), the enumerator 33 configures each VLYNQ and puts the results in an output file of the file system. For the example of
Remote devices are identified using VLYNQ's chip version register. The enumerator 33 is able to read the remote chip version register to identify remote devices and determine which device information file should be accessed. The table that follows lists the device ID's that have currently been assigned:
Each “pass” of the VLYNQ enumerator 33 configures a single branch of the system. A branch in this case is defined as all VLYNQ devices connected to a single VLYNQ module on the root device. The software reads the root device configuration file to determine how many VLYNQ modules are on the root device. For each root module, the recursive algorithm is executed (this is one “pass” of the enumerator).
In the enumerator algorithm, starting with a VLYNQ module on the root device, it determines if there is a link (Step 1). If there is a link, the enumerator 33 reads the remote device identification register and locates the associated device configuration file (Step 2). It then determines if the remote device has more than one VLYNQ. If there is more than one VLYNQ, the enumerator 33 recursively performs the above steps until the end of the VLYNQ chain is reached (Steps 3–7). The enumerator 33 determines that the VLYNQ chain is ended if a discovered device has only one VLYNQ module (Step 3), or if there is no link on all VLYNQ portals of a remote device. As the enumerator is working toward reaching the end of the chain, it also creates address mappings to the VLYNQ modules that it finds along the way (Step 4). This gives the enumerator 33 the information that it needs to revisit the VLYNQ modules later in order to create mappings for the remote peripherals. Once the enumerator reaches the end of a VLYNQ chain (Step 7 and 8), it creates mappings for the peripherals on the end device (Step 9). The return total size of all remote peripheral maps is sent to be recomputed the memory maps based on return value at Step 10. At this point, the recursive algorithm returns, which effectively moves the control back to the previous VLYNQ device in the chain. It then determines if there is another local VLYNQ and if so goes onto the next VLYNQ and traverses it to the end of its chain, as before. Eventually, the program flow will return to the root device (Step 8), which means the enumerator has completed all tasks for the given branch, and returns.
The recursive nature of the algorithm allows this software to function properly on arbitrarily large VLYNQ systems. There are no limitations on the total number of VLYNQ devices or on per device VLYNQ multiplicity. However, VLYNQ hardware has some limitations such as the total amount of possible mapped space per branch (currently 64 MB), and the total amount of interrupts available per branch (32). These limitations are discussed further under Limitations and Notes.
Device Information Files
Format and Development of Device Files
This section describes the format and use of device information files. These files must contain information relating to the address map, interrupt map, and peripheral communication requirements (reverse mapping) for the device.
Below is a summary of the format used for device into files, and a simple example:
Each entry in the file must contain an “id” parameter to identify the peripheral. VLYNQ entries must contain the base address and portal size, as well as the register address and size. This information can be found in the associated device specification. Peripheral entries must contain only a base address and size, but have several optional parameters.
Optional parameters are explained below:
Optional Peripheral Parameters
The VLMapped parameter is used to designate whether or not the peripheral will be included in the interrupt and memory map. If an entry of “VLMapped=0” is made in a peripheral entry, this peripheral is skipped by the enumerator. If VLMapped is set to anything else (or excluded altogether), the enumerator will attempt to map it.
The int_line (and int_type, int_pol) parameter is used to specify which interrupt lines the peripheral uses on the VLYNQ device. One may specify up to 8 interrupts per device. This is a limitation of current VLYNQ hardware, which only has 8 interrupt input lines as of the date of this specification. Multiple interrupts are supported for a single peripheral, by creating an entry with a semi-colon delimited interrupt list, as in “int_line=1;2;3;4”.
The int_type and int_pol parameters may be used alongside int_line to specify the interrupt type and polarity. For int_type, a value of 0 specifies a level-sensitive interrupt, while a value of 1 is reserved for pulsed interrupts. Int_pol may be set to 0 (active high) or 1 (active low).
The map_to (and map_to_offset, map_to_size) parameter is used to map the peripheral directly to a memory region on the root device. The map_to entry should be filled in directly with a semi-colon delimited list of regions to map to (i.e. map_to =sar;sdram). The enumerator will read the root device information file looking for the sar and sdram entries, in this example. Ensure that these entries exist in the root device file. In the output file, the enumerator will replace the text “sar” and “sdram” with the mapped addresses to each of the regions.
The map_to_offset and map_to_size fields (optional) may be used to specify an offset from the base address of the root peripheral, and the size to map. If not used, the offset is assumed to be zero, and the size will be set to the entire size of the requested root memory region.
An example of the use of the map_to parameter is the VDSP device, which for some application needs to access the SAR (Segmentation and Reassembly) module on the root device.
In general, all of the information necessary to generate a device information file is available in the specification for the device. For the most efficient usage of VLYNQ resources, list all vlynq entries in the file in the order of base address, starting with 0. Do the same for all peripheral entries. All address entries in device information files should use the physical address found in the associated memory map for the device. Also, each interrupt line entry should give the number of the VLYNQ interrupt line used for that peripheral-this information should be available in the device specification.
The Output File
Output Format and File API
The following describes the output file and specifies software interface for accessing the file.
When the enumerator algorithm has completed, all of the mappings are collected and output to the output file. This file contains all of the information contained in the root file (options.conf), concatenated with any new entries that correspond to remote peripherals that have been discovered on VLYNQ devices. From the perspective of the software developer, remote peripherals can be treated in exactly the same manner as local peripherals. An example output file is given below:
Example Output File (output.con)
In the example given above, one remote device was discovered, with one vlynq and one vdsp peripheral. The locator parameter may be ignored (it is useful to the enumerator development team as debug information in the case of failure). One will find that the base addresses given in the device information file have been altered and are now valid virtual addresses. One will also notice that the interrupt values have been remapped and may now contain a different interrupt number. Finally, for any “map_to” entries that were specified in remote device information files, the name of the root peripheral region to map_to has been replaced with a virtual address that is valid for that peripheral. In the example, assuming that the VDSP device information file contained parameter entries “map_to=sar, map_to_size=0×1000”, the vdsp may now reach the SAR in the root device by accessing memory region 0×a400000-0×a401000.
Using this API, it is simple to extract any or all values from the output file. It is suggested that the software developer read all of the data in the output file into internal data structures in order to avoid accessing the file at run-time (see the above example).
Limitations and Notes
VLYNQ Address Maps
Each VLYNQ module can perform address translation for up to four mapped regions. The enumerator software maps utilizes VLYNQ map resources efficiently, sharing maps where possible. The algorithm currently uses the first map to map any VLYNQ portal registers on the remote device (if there is more than 1 VLYNQ device). If there are multiple VLYNQs on a remote device, and their base addresses are not contiguous, more that one VLYNQ map will be required. For the most efficient operation, all VLYNQ register regions should be contiguous in the memory map. If this requirement is met, a virtually unlimited number of VLYNQ modules can be supported per device.
The second VLYNQ map is typically used to allow access to remote devices that are even further “downstream”. This is only necessary if the remote device has more than one VLYNQ. Since VLYNQ portals are so large (64 MB typically), it is impossible to map the entire size of a portal. Instead, assuming that VLYNQ portals have been allocated contiguously in the device memory map, one VLYNQ map is exhausted for every two VLYNQ portals. The implication of this is that VLYNQ devices may have a maximum of 7 VLYNQ modules (assuming that the device does not also have any peripherals to map).
After VLYNQ registers and portals have been mapped, any device peripherals may be mapped if any of the four maps remain, or if peripheral regions happen to be contiguous with maps that have already been configured. Again, it is important that the device designer make every effort possible to map important peripherals and registers contiguously, in order to allow the greatest possible flexibility for VLYNQ systems.
If VLYNQ map resources run out before all maps have been configured, an error message will be generated, and some peripherals will not be mapped and will not have an associated entry in the output file.
Interrupts
Each VLYNQ branch (each root VLYNQ module) may map up to 32 remote interrupts. This limitation is imposed by the 32-bit size of the Interrupt Pending/Set register in VLYNQ. A further limitation of 8 interrupts per VLYNQ device is imposed by the fact that each VLYNQ module currently supports only 8 interrupt input lines.
Each VLYNQ module in the system consumes one interrupt for any VLYNQ module interrupts that may occur. The interrupt value assigned to any VLYNQ or peripheral is written to the output file.
Interrupt Handling
Each root VLYNQ is wired to a single interrupt in the root interrupt controller. When one of the interrupts is asserted, the VLYNQ Interrupt Status/Clear register must be read to determine which interrupt(s) have occurred. The software must then compare this value to the mapped interrupt values that were read from the output file to determine the source of the interrupt. The VLYNQ Interrupt Status/Clear register may be found at the following address: (VLYNQ virtual base address=0×10). Read this memory location to determine the interrupt status. After servicing the interrupt, one should also clear the interrupt. To clear an interrupt, write a 1 to any bit in the register.
Reverse Mapping
Remote devices may require a direct mapping to a peripheral or memory region on the root device. This functionality can be used by adding the “map_to” parameter to peripherals in a device information file. Doing this consumes a single VLYNQ map in each portal VLYNQ module, and consumes one or more maps in the root VLYNQ module. One may map remote devices to a maximum of four non-contiguous address regions on the root device. If reverse maps are made to contiguous regions on the root device, the only limitation is the 64 MB portal size.
While the invention has been described and shown with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6003097 | Richman et al. | Dec 1999 | A |
| 6425033 | Conway et al. | Jul 2002 | B1 |
| 6446142 | Shima et al. | Sep 2002 | B1 |
| 6496893 | Arai | Dec 2002 | B1 |
| 6523081 | Karlsson et al. | Feb 2003 | B1 |
| 6567876 | Stufflebeam | May 2003 | B1 |
| 6671748 | Cole et al. | Dec 2003 | B1 |
| Number | Date | Country | |
|---|---|---|---|
| 20040215861 A1 | Oct 2004 | US |
