text:
US 7356628 B2 Abstract An integrated circuit on which are implemented a number of devices that conform to the Rapidio network architecture. Included in the integrated circuit are two addressed RapidIO devices and switching devices which provide 24 switching ports. The devices have a packet receiving side and a packet transmitting side; the packet receiving side of each of the devices is connected by 128-bit wide paths termed poles its own packet transmitting side and each of the other transmitting sides. Features of the integrated circuit include centralized multicasting and configuration control for all of the devices on the integrated circuit, provisions for having more than one address in a RapidIO device, techniques for defining the address space routed by a routing table, techniques for managing congestion, and advanced buffer management techniques.
Claims(19) 1. A network device that operates in a network whose architecture permits only a single architectural address to be specified for the network device, the architecture further specifying configuration information including user-defined configuration information for the network device and the network device being characterized by memory containing:
first user-defined configuration information that indicates whether the network device has only the architectural address; and
second user-defined configuration information specifying a set of additional addresses to which the network device responds, the network device
responding to an address received in the device when the first user-defined configuration information indicates that the device has only the architectural address by comparing the received address to the architectural address and if the received address matches the architectural address, further responding thereto and
responding to the received address when the first user-defined configuration information indicates that the device has the set of additional addresses by comparing the received address to the architectural address and if the received address matches the architectural address, further responding thereto and otherwise comparing the received address to the additional addresses in the set and if the received address matches one of the additional addresses, further responding thereto.
2. The network device set forth in
the network device has a plurality of addressable components; and
the architectural address and the additional addresses are addresses of the addressable components.
3. The network device set forth in
each of the addressable components has a set of configuration information;
the address of the addressable component is in the set of configuration information for the addressable component; and
the second user-defined configuration information contains the sets of configuration information for the addressable components having the additional addresses.
4. The network device set forth in
the network device is implemented in an integrated circuit.
5. The network device set forth in
a configuration manager that is separate from the addressable components and manages the configuration information for all of the components.
6. The network device set forth in
the network's architecture defines maintenance packets that contain device addresses; and
the configuration manager receives a maintenance packet received in the device and uses the first and second user-defined configuration information to determine whether the maintenance packet is directed to one of the component devices.
7. The network device set forth in
third user-defined configuration information contained in the memory that when the first user-defined configuration information indicates that the device has additional addresses in addition to the architectural address, indicates a number of addresses; and
the device uses the number of addresses indicated in the third user-defined configuration information to determine a maximum number of addresses to compare with the received address.
8. The network device set forth in
when the first user-defined configuration information indicates that the device has additional addresses, the first user-defined information further indicates the architectural address's location.
9. The network device set forth in
the third user-defined configuration information further indicates a location of the second user-defined configuration information.
10. The network device set forth in
when the first user-defined configuration information indicates that the device has additional addresses, the first user-defined configuration information further indicates the architectural address's location.
11. The network device set forth in
the second user-defined configuration information is contained in an array thereof; and
the location indicated in the third user-defined configuration information is the location of the array.
12. A method used in a network device that operates in a network whose architecture permits the network device to have only a single architectural address to cause the device to respond to one or more additional addresses in addition to the architectural address for the device, the architecture further having configuration information including user-defined configuration information and the method comprising the steps of:
if there are additional addresses, including the additional addresses in first user-defined configuration information;
setting second user-defined configuration information to indicate whether the device has only the architectural address or the additional addresses; and
on receipt of an address in the network, responding to the received address by performing steps including
if the second user-defined configuration information indicates that the device has only the architectural address, comparing the received address to the architectural address and further responding thereto if there is a match; and
if the second user-defined configuration information indicates that the device has the additional addresses and the received address does not match the architectural address, comparing the received address to the additional addresses and further responding thereto if a match is found.
13. The method set forth in
the network device has a plurality of addressable components; and
the architectural address and the additional addresses are addresses of the addressable components.
14. The method set forth in
each of the addressable components has a set of configuration information that includes the component's address; and
in the step of including the additional addresses, the set of configuration information for the component is included.
15. The method set forth in
in the step of setting second user-defined configuration information, when the second user-defined configuration information indicates that the device has additional addresses, the second user-defined configuration information is further set to indicate the location of the architectural address.
16. The method set forth in
setting third user-defined configuration information to indicate the number of additional addresses when the second user-defined configuration information indicates that the device has one or more additional addresses; and
in the step of comparing the received address to the additional addresses, making the comparison with the number of additional addresses specified in the third user-defined configuration information.
17. The method set forth in
setting the third user-defined configuration information to further indicate a location of the first user-defined configuration information; and
in the step of comparing the received address to the additional addresses, using the location in the third user-defined configuration information to locate the additional addresses.
18. The method set forth in
setting third user-defined configuration information to indicate the number of additional addresses when the second user-defined configuration information indicates that the device has one or more additional addresses; and
in the step of comparing the received address to the additional addresses, making the comparison with the number of additional addresses specified in the third user-defined configuration information.
19. The method set forth in
setting third user-defined configuration information to indicate a location of the first user-defined configuration information; and
in the step of comparing the received address to the additional addresses, using the location in the third user-defined configuration information to locate the additional addresses.
Description This application shares portions of its Detailed Description with two other patent applications that have a common assignee and are being filed on even date with the present patent application. The applications are docket freesc01.003, Swartzentruber and Wilcox, Packet switch having a crossbar switch that connects multiport receiving and transmitting elements, and docket freesc01.004, Swartzentruber and Wilcox, Efficient multi-bank buffer management scheme for non-aligned data. The new disclosure in the present patent application begins in the section titled Details of configuration interface 515. 1. Field of the Invention The invention relates generally to packet switches implemented in integrated circuits and more particularly to packet switches that include devices that conform to the RapidIO architecture. 2. Description of Related Technology Problems in Interconnecting the Subsystems of a Digital System As the circuits that make up digital devices have gotten smaller and smaller, more and more subsystems have been included in the case that contains the processor. For example, thirty years ago, the case of a minicomputer contained only the processor and the memory. Hard drives and communications gear were separate. The case of a modern laptop PC has perhaps a tenth of the volume of the minicomputer case, but the case typically contains the processor, the memory, a hard drive, a removable drive, a keyboard, a screen, a microphone, a speaker, and various communications systems, including a wireless communications system. As the number of subsystems in the case has grown, the difficulties of communication between the subsystems have increased. Originally, communication was by means of a single bus that connected the processor and all the peripherals. Driven by the different performance requirements of the peripherals, the single bus quickly became a hierarchy of buses. Subsystems are placed at the appropriate level in the hierarchy according to the performance level they require. Low performance subsystems are placed on lower performance buses, which are bridged to the higher performance buses so as to not burden the higher performance subsystems. Bridging may also be used to deal with legacy interfaces. The need for higher levels of bus performance is driven by two key factors. First, the need for higher raw data bandwidth to support higher peripheral device performance requirements, second the need for more system concurrency. The overall system bandwidth requirements have also increased because of the increasing use of DMA, smart processor-based peripherals and multiprocessing in systems. Over the past several years the shared multi-drop bus has been exploited to its full potential. Many techniques have been applied, such as increasing frequency, widening the interface, pipelining transactions, splitting transactions, and allowing out of order completion. Continuing to work with a bus in this manner creates several design issues. Increasing bus width, for example, reduces the maximum achievable frequency due to skew between signals. More signals will also result in more pins on a device, traces on boards and larger connectors, resulting in a higher product cost and a reduction in the number of interfaces a system or device can provide. Worsening the situation is the desire to increase the number of subsystems that can communicate directly with each other. As frequency and width increase, the ability to have more than a few subsystems attached to a shared bus becomes a difficult design challenge. In many cases, system designers have inserted a hierarchy of bridges to reduce the number of loads on a single bus. Using a High-Speed Switch to Connect Subsystems A fundamental solution to the problem of using buses to connect subsystems of a digital system is to replace the bus with a very high speed switch. Subsystems of the digital system are connected to the switch and communicate by sending each other packets of information. Each packet contains a destination address, and the switch routes each packet to the destination subsystem. Advantages of using a very high speed switch instead of a bus include the following:
A standard architecture for interconnecting subsystems with switches is RapidIO�, which is described in overview in the white paper, RapidIO: The Interconnect Architecture for High Performance Embedded Systems, copyrighted in 2003 and available at http://www.rapidio.org/zdata/techwhitepaper_rev3.pdf in 2005. There are two broad classes of devices in the RapidIO architecture: endpoints and switches. Endpoints have addresses in a RapidIO network and source and sink transactions to and from a RapidIO network. Switches are responsible for routing packets across the RapidIO network from the source to the destination using the information in the packet header without modifying the logical layer or transport layer contents of the packet. Switches do not have addresses in the RapidIO network. Switches also determine the topology of the RapidIO network and play an important role in the overall performance of RapidIO. Some RapidIO devices can act both as endpoints and switches. Both switches and endpoints support maintenance transactions which give users of the network access to architectural registers in the devices. The RapidIO architecture has a layered architecture with three layers:
Components of the packets belong to each of these layers. A typical RapidIO packet is shown at 115. Certain fields are context dependent and may not appear in all packets. The request packet begins with physical layer fields 119. Included in these fields is an �S� bit that indicates whether this is a packet or control symbol. An �AckID� indicates an ID to be used when the packet is acknowledged with a control symbol. The �PRIO� field indicates the packet priority used for flow control. The �TT� field 121, �Target Address� field 125, and �Source Address� field 127 indicate the type of transport level address mechanism being used used, the address of the endpoint device the packet is to be delivered to, and the end point device from which the packet originated. The �Ftype� field 123 and the �Transaction� field 129 indicate the kind of transaction that the destination endpoint is to perform in response to the packet. �Size� field 131 is an encoded transaction size. Data payloads 137 in RapidIO packets are optional and range from 1 byte to 256 bytes in size. �srcTID� field 133 contains a transaction ID that the source endpoint has given the transaction. RapidIO devices may have up to 256 outstanding transactions between two endpoints. For memory mapped transactions, the �Device Offset Address� 135 follows. Data payload field 137 is followed by a 16-bit CRC. Then comes the next packet 141. In terms of the layers, physical fields 119 and CRC field 16 belong to the physical layer: TT field 121, target address field 125, and source address field 127 belong to the transport layer; the remaining fields belong to the logical layer. RapidIO packets are classified by the values of Ftype field 123 and Transaction field 129 according to the kind of transaction they belong to. The kinds of transactions include:
For the present discussion, system support transactions are of particular importance. Basic Approaches to the Design of Switches: In the digital age, two basic approaches are used in the design of switches: crossbars and shared memory. At 207 is shown an implementation of a switch made using shared memory. All of the ports 209 share access to shared memory 211. Because the memory is shared, arbiter 217 must determine which of the ports gets access to shared memory at any particular time. Shared memory 211 contains two kinds of information: the packets 213 being switched by the switch and a descriptor table which contains descriptors that describe the location and size of each of the packets stored in packet memory 213. The descriptors are organized into queues belonging to the ports. When a packet comes in at a port 209, the port stores the packet in packet memory 213, makes a descriptor for the packet, and places the descriptor on the queue of the port by which the packet is to leave the switch. When a port's queue contains descriptors, the port outputs descriptors until the queue is empty. The bandwidth and latency of switch 207 are determined by how long it takes to store a packet into shared memory, make and place the descriptor in the proper queue in descriptor table 215, and read the packet from shared memory 211. As long as a port has descriptors on its descriptor queue, the port can output packets. The routing for switch 207 is far less complex than that for switch 201; however, a shared memory 211 must be large and the operation of making a descriptor and placing it on the proper queue is too complex to be easily done in simple hardware. It is an object of the invention to provide a new switch architecture for switches implemented in integrated circuits that overcomes the disadvantages of the switch architectures of Reference numbers in the drawing have three or more digits: the two right-hand digits are reference numbers in the drawing indicated by the remaining digits. Thus, an item with the reference number 203 first appears as item 203 in The following Detailed Description will begin with an overview of an integrated circuit for a new type of RapidIO device which includes both endpoint and switching devices. In the following, this device will be termed a combined switch and endpoint RapidIO device, or CSERD. Features that are of particular interest in the CSERD are:
The overview will be followed by detailed descriptions of components of the CSERD that are particularly relevant to these features. Overview of the CSERD Overview Block Diagram: From the point of view of switch 315, all clients 307 are the same; there are however, two types of client: serial clients 309, which are components of switches 306, and endpoint clients 308, which are components of endpoints. In the following discussion, when a client is being referred to without regard to its type, the reference number 307 will be used; otherwise the reference number for the client's type will be used. In CSERD 301, each switch 306(i) has its own serial client 309(i) and endpoint client 308 is shared between endpoints 303(0 and 1). In addition to a serial client 309(i), a switch 306(i) has two delta groups 311(i) which provide connections to the physical media from which switch 306(i) receives RapidIO packets and to which switch 306(i) provides RapidIO packets. These connections to the physical media are termed in the following ports. In a preferred embodiment of CSERD 301, each switch 306(i) has 8 bidirectional ports 313(0 . . . 7) that are implemented by a pair of delta groups 311(i). For routing purposes, the ports may be treated as individual ports or banks of four ports, one bank belonging to each delta group. Operation of CSERD 301 is as follows: RapidIO packets 115 may either be produced by an endpoint 303(i) or received in a port 313(i)(j) belonging to a switch 306(i). In either case, the packet 115 includes a target address 125 that specifies a RapidIO endpoint. Each client 307(i) includes a routing table (not shown) that indicates which client 307(0 . . . 3) is the destination for that target address and which port in the device that the client belongs to will take the packet 115 to its destination. If the target address is that of an endpoint 303(i) in CSERD 301, the destination client is endpoint client 308; otherwise, it is the serial client 309(i) to which the media that will take the packet to its destination is connected. In the following, the destination client will be termed the far end client. When the packet comes into a client 307(i), the client employs the lookup table to determine the far end client 307(0 . . . 3) to which the packet is to be routed and the port in the client. The packet is then placed on pole 317(i)(j) to far end client 307(j), which outputs it to the specified port 313. The information that passes via pole 317(i)(j) are the packet and signals that indicate the start and end of packet transmission and the destination port. Of course, many variations on the architecture shown in Architectural Characteristics of CSERD 301 From an architectural point of view, CSERD 301 may be broadly characterized as packet switching apparatus which includes a plurality of devices. Each device has a receiving part which receives packets from a number of sources and an outputting part which outputs packets to a number of destinations. The destinations are specified by destination specifiers in the packets. The receiving part of each device is connected to the outputting parts of each device including itself by output data paths. There is routing apparatus in each of the receiving parts which responds to the destination specifier by routing the packet from the receiving part via the output path which connects the receiving part to the outputting part which outputs packets to the specified destination. CSERD 301 may also be characterized from an architectural point of view as apparatus which implements a plurality of packet network devices in an integrated circuit. The packet network devices are defined by an architecture for a patent network that has addressable and non-addressable devices. The apparatus includes an addressable device in the integrated circuit which is a destination for packets defined by the architecture and a non-addressable device in the integrated circuit which routes packets to their destinations. The non-addressable device is coupled to the addressable device and responds to a packet whose destination is the addressable device by routing the packet to the addressable device and responding to a packet whose destination is not the addressable device by routing the packet as required by the destination. CSERD 301 may further be seen from an architectural point of view as apparatus which implements a plurality of packet network devices in an integrated circuit. The integrated circuit includes the plurality of packet network devices and a device manager for the plurality of packet network devices which performs functions for each of the packet network devices as required by that packet network device. The functions include configuring individual ones of the packet network devices and when the packet network devices include devices having input ports for receiving packets and output ports for providing packets, the functions include a multicast function that receives multicast packets from any of the plurality of input ports, makes copies of the multicast packets, and provides the copies to ports of the plurality of output ports. Overview of Applications: Details of the Endpoints and the Configuration Interface: Details of the endpoints 303(0) and (1) and of the configuration interface to which maintenance bridge 305 belongs are shown in block diagram 501 of The Endpoints Seen at the highest level, CSERD 301 has endpoint interfaces that define a data plane and a control plane for the network defined by the RapidIO devices. The data plane is the network seen as a mechanism for moving streaming data from one endpoint of the network to another endpoint of the network. The control plane is the network seen as a mechanism for controlling the movement of the streaming data. The distinction between the data plane and the control plane is reflected in the interfaces by means of which the endpoints output data received in the end point from the RapidIO network and receive data to be sent over the RapidIO network and in the kinds of RapidIO packets. The interfaces are listed in table 601. The relationship between the data plane and the control plane and the RapidIO packet types is shown in table 603. Endpoint A 303(0) can be used as a data plane interface to the switching fabric to which serial clients 309(0 . . . 2) belong. Endpoint B 303(1) can be used as either a control plane interface or as a second data plane interface to the switching fabric. Configuration interface 515 can be used for local configuration, network discovery, and statistics gathering. Like the other interfaces, it is connected via the endpoint client to the serial clients and thereby to the RapidIO network. Configuration interface 515 can thus respond to control plane data from CSERD 301 or other devices on the RapidIO network and can provide such data to CSERD 301 or the other devices. Continuing in more detail, Endpoint A 303(0) supports input of data to CSERD 301 and output of data from CSERD 301 in modes that are compliant with the CSIX-L1, UL-2, UL-3, SPI-3 and GMII data plane interface standards. Endpoint A 303 provides a connection between the selected interface and the devices of CSERD 301. It performs MPHY, class or priority ordering of traffic that is sent from the fabric to the endpoint. It translates between ATM cells, CFrames, SPI packets, and Ethernet frames and RapidIO packets. It also provides the segmentation required to transfer large PDU's across the RapidIO network. Message Passing Bridge 509(0) allows for the conversion of data plane RapidIO packets of types 0 and 9 to packets of types 11 and 13, which are used for control plane traffic and with RapidIO endpoints that cannot handle packets of types 0 and 9. At 511 and 513 are indicated the RapidIO packet types that are handled by endpoint A 303. Endpoint B 303(1) provides a connection to a host processor or other Ethernet device for bridging to the RapidIO fabric. This port uses the GMII or MII physical interface for Gigabit Ethernet or Fast Ethernet connectivity. This interface can also be used as a second data plane interface to the fabric. It handles the same packet types as endpoint A and does the same conversions in message passing bridge 509(1). The basic structure of endpoints 303(0) and (1) is the same: they have a message passing bridge 509 which handles RapidIO packets of types 11 and 13, a data streaming translation unit 507 which translates between RapidIO packets and the packets used in the streaming data interfaces served by the endpoints, and the interfaces 503 to the media for the streaming data interfaces. In the case of endpoint A, there is a memory buffer 505 which permits data from different ones of the interfaces 503 to be passed to translator 507 and vice-versa. Both endpoint A and endpoint B have segmentation and reassembly block 504. The block segments large packets from the endpoint's interfaces 503 into a sequence of RapidIO packets and reassembles large packets for the endpoint's interfaces 503 from a sequence of RapidIO packets. The Configuration Interface The Configuration interface provides a connection for device configuration, statistics collection, and RapidIO network discovery. A microprocessor bus interface 517 and an I2C interface 519 are provided for handling these tasks. Interface 519 can also be used to read from PROM 521. A RapidIO Maintenance packet buffer is provided so that maintenance packets (type 8) can be generated and sent across the RapidIO network, or received by the interface. This allows for configuration of remote RapidIO devices and for implementing the RapidIO network discovery protocol. Maintenance Bridge 305 handles all of the RapidIO maintenance transactions that are directed to one of the Regatta endpoints, any of the ports, or the switch. These transactions all employ type 8 RapidIO packets. Configuration of CSERD 301 is handled by a controller 525, which reads and writes the registers in register map 527. Register map 527 collects the statistics registers 531, configuration registers 529, and CAR and CSR registers 533 from each RapidIO port, the endpoints and the switch. The contents and function of these registers are defined by the RapidIO standard. Also included in the registers are buffers 535 and 537 for holding RapidIO maintenance and response packets (type 8) These registers are managed by controller 525 and can be read from or written to locally by the microprocessor or I2C interface, or remotely by RapidIO maintenance packets. The actual registers specified by register map 527 are distributed throughout CSERD 301. Routing table 513 contains the routing information used to determine the destination of an incoming RapidIO packet. RapidIO maintenance packets are also used to read and write entries in routing table 513. Arbitration between maintenance bridge 305, controller 525, and interfaces 517 and 519 for access to the resources required by these entities is done by ARB 523. Data Flows in CSERD 301 The following dataflows may occur in CSERD 301: Endpoint 303(i) to a switch 306(i)
When a message passing or maintenance request packet is received, a response packet is generated and sent back to the requester. The source address of the request packet is used as the destination address for the response. The client 307(i) will do a lookup on the destination address to determine the appropriate client 307(j) and port 313(k) to which to send the response packet and will send the response packet via internal switch 315 to that client 307(i), which will send the port to its destination via port 313(k). Overview of the Internals of the Clients: Clients 307 Generally
Endpoint client 308's ingress function involves receiving RapidIO packets from either one of the endpoints 303(0) and (1) or maintenance bridge 305 and routing the packets to the poles 317 that will carry the packets to their far end clients 307. The ingress path involves arbiter 715, which arbitrates among the endpoints 303(0 and 1) and maintenance bridge 305 for access to client 308, buffer 713, in which the packets are stored until they are output to a pole, priority select 711, which selects the next packet to be output to a given pole according to a priority specified in the packet as modified by factors such as the length of time the packet has been waiting and the availability of buffer space in the far end, and routing table lookup 709, which determines the pole that is to receive the packet. As will be explained in more detail in the following, routing is done in parallel with storage in buffer 713. When performing the egress function a client 307 is serving as a far end for itself or the other clients 307 from which the client 307 receives packets via the poles that are connected to the egress function. The egress function routes the packets received on the poles 317 to the client 307's ports. In the case of endpoint client 308, the ports are connected to an endpoint 303 or maintenance bridge 305. The egress path includes switch arbiter 703, which arbitrates among the received packets for access to endpoint client 703's ports. Arbitration is done according to the priority in the packet's PRIO field. Serial Client 309(i) The differences between serial client 309(i) and endpoint client 308 stem from the fact that each serial client 309 is a part of a RapidIO switch 306 with 24 bidirectional ports 313. There is an ingress path and an egress path for each port. Beginning with the ingress path, each port 313 has hardware 731 and 729 which converts the serial data received in the ports to 32-bit parallel chunks and places the chunks in buffer 727. The packet to which the chunks belong is then routed at 731 and output to the pole 317 required to take the packet to the client 307 from which it can reach its destination. Arbiter 733 arbitrates among the ports for access to the poles. Again, routing is done in parallel with buffering. In the egress path, the data for the packets comes in 128-bit chunks from a pole 317. Switch arbiter 717 arbitrates among the packets. Port select 719 selects which of the ports 313 is to receive the data and priority select 721 places the packets in buffer 725 for port 313 according to the packets' priorities. Flow control 723 inserts flow control packets into buffer 725 where these are required to alter the rate of flow of packets being received at the port. Output is then in 64-bit chunks to hardware 729 and 731, which converts the chunks into serial packets. Details of the Endpoint Client Endpoint Client Ingress Unit: Beginning with packets from endpoints 303(0) and (1) and maintenance bridge 305, ingress unit 801 has three ports 803 to deal with these packets; one of these ports, 803(i), is shown in The data belonging to a packet comes in at 804(i); control signals indicating the start and end of the packet are received at 802(i). When a packet 115 comes in at 804(i), ingress control unit (ICU) 805 extracts the target address field and applies it to ingress routing table (IRT) 815 to determine the pole the packet is to be output on and the port the packet is to be transmitted from after it has reached the far end client 307(i) to which the pole is connected. Ingress control unit 805 puts the pole and destination port in a descriptor 811 for the packet along with other information about the packet and writes the pole and source port to the AckID field in physical bits 119. This field has been chosen because it is not included in the computation of the packet's CRC. The packet's descriptor 811 is placed in ingress descriptor queue 809. As shown in detail at 811, the other information includes how the packet is to be read from ingress buffer 818 (Flip), whether dropping the packet is prohibited, (ND), whether receipt of the packet may result in a flow control packet being output to the packet's sender, what the packet's priority is, the word count (WC), and a valid flag for the descriptor. The determination whether the packet can be dropped is based on the packet type and configuration settings for the packet types; the priority is determined from priority bits in the packet's physical bits 119, and the word count is a count made by ICU 805 as the packet is input. The packet itself goes via latch 817 to the port's ingress buffer 818. Ingress buffer 818 is shared by all of the ports 803 and is divided into partitions, one for each of the ports from which endpoint 308 receives packets. In a preferred embodiment, each partition is large enough to hold 32 of the largest RapidIO packets. The packet is placed in the partition belonging to the port at which the packet is received. The ingress unit treats the packets in the partition as a queue in which the packets have the same order as their descriptors in IDQ 809. When a packet's descriptor 811 comes to the head of ingress descriptor queue 809, ingress port arbiter 820 reads the descriptor, the state of ingress descriptor queue 809, and the state of the port to which the packet is to be output to decide whether the packet can be output to the pole specified in the descriptor on this arbitration cycle. The packet is output to buffer 819 and from there to the specified pole. When the packet is output, IBR 813 generates signal 822(i) to the port physical interface indicating that a packet has been output from buffer 818. What happens to the packet on output is determined by the contents of the packet's descriptor 811. The value of the pole field determines which pole 317 the packet is output to, and the value of the port field determines the setting of the signal clix2cli0_dest in signals 821 which specifies the port to the far end client 307. If the flip bit is set, the words of the packet are rearranged on output; if ND is not set and the current condition of the port requires a drop, the packet is dropped. Ingress packet drop 807 generates the signal which causes buffer 818 to drop the packet. When pole 317 is outputting the packet, signals 821 indicate that the data on the pole is valid, the destination port for the data, and the start and end of the packet. The packet itself is output at 820. Signal 823 indicates that the pole's far end can take data. It is input to egress buffer manager 824, which passes it on to ingress pole arbiter (IPA) 820 for use in deciding whether to output a packet to the pole. Egress buffer manager 824 also inserts flow control packets into latch 822 to control output of data from data sources to the ports of the client. These are placed on the pole that returns packets to ports in the end point client. It is of course possible that more than one buffer 818 may be simultaneously attempting to output a packet to a pole 317. IPA 820 determines which packet will go to a pole according to the following principle: port and pri from the packet descriptor 811 for the packet are passed through Arbiter 820 to access buffer state for the far end client which is maintained in Egress Buffer Manager 824(i) handling the specified pole or poles. The sum of valid requests are separated into four priority tiers, with stalled Flow Control packet insertion having highest priority, normal Flow Control packet insertion the next, followed by stalled packets, and finally normal traffic having the lowest priority. All packets assigned to a particular priority tier are treated as equal, and a simple round-robin is done between all Ports/FC units with active requests in that tier. Note that all requests are qualified for available buffer space prior to being presented in any tier. Thus, stalled traffic cannot prevent non-stalled traffic from proceeding when stalled traffic requests cannot make progress but non-stalled traffic requests can. The mechanism for giving a transient higher priority to stalled packets will be explained in detail later. Routing in the Ingress Unit: A challenge in the design of systems for routing RapidIO packets is that target address 125 may be up to 16 bits long, which means that there are 217−1 possible addresses that must be accounted for in the routing table. A simple routing table that had 1 entry for each possible address would have to have 217−1 entries and would require too much die space to be economically implemented in an integrated circuit. That is particularly the case when, as in CSERD 301, the routing table is distributed and there is a local routing table like IRT 815 for each client 307. The usual solution for reducing the size of the routing table is applying a hashing function to the address to obtain a smaller index into the routing table. This solution, however, adds computational complexity and requires either a relatively large routing table or a variable number of references to the table and therefore a variable amount of time to route an address. Neither the additional computational complexity nor the tradeoff between table size and time to route an address is desirable in an integrated circuit such as CSERD 301. The address space which IRT 815 will route is defined by an offset 917, a mask 915, and a base value 919. Offset 917 determines the least significant bit at which a ten-bit sliding window in target address 125 begins; mask 915 masks the bits 914 that are not in sliding window 914, and base value 919 provides a predetermined value which is compared with the result of masking bits 914 to determine whether the target address belongs to the address space routed by IRT 815. If it does, IRT 815 is indexed using index bits 913 and the routing for address 125 is specified by routing table entry 905(i) corresponding to index bits 913. Otherwise, the packet is routed to a default destination. There are CSRs for offset 917, mask 915, and base value 919 for each IRT 815, and these CSRs can be set to the values required to define a particular address space via maintenance packets. It should be noted here that the technique used here for defining the address space for an IRT 815 can be used in any situation where a key is used to index a table. Mechanism 901 can be modified to route addresses belonging to different address spaces simply by changing the value of offset 917 and/or by changing mask 915 and/or by changing the base value 919. To give a simple example, if offset 917 is set to 0 and the mask is set to 0, bits 6-15 of the target address are used to index IRT 815 and bits 0-5 of the target address are simply ignored. When arrangement 901 is set up in this fashion, the address space includes any destination address 125. A more complicated example is the following: to set up IRT 815 so that the address space that it will route consists of all even addresses (addresses whose lsb is 0), one would set offset 917 to 1, base value 919 to 0, and the mask to 1. When this is done, bits 0-4 of the address are masked out and therefore not considered and the mask bit is set so that the value of bit 15 is compared with the value of base value 919. When the comparison is made, an address will be in the address space which can be routed by IRT 815 only if its lsb is 0, i.e., if the address is an even address. The sliding window, offset, mask, and base value 919 can be used to specify many different address spaces. For example, if a routing system is hierarchical, that is, it consists of a tree of nodes and the form of the address corresponding to a node is determined by the position of the node in the tree, arrangement 901 can be set up to route only nodes at a certain level of the hierarchy. Similarly, different setups can by used to define unicast and multicast address spaces. Seen in broad terms, arrangement 901 includes the following: a processing unit that has access to memory in which is stored the routing table, the offset value, a base value, and address which may or may not belong to the address space defined by the offset value and the base value. The processing unit applies the offset value to the address to determine the bits of the address that are to be used to index the routing table. It then uses the non-index bits of the address and the base value to determine whether the address belongs to the address space, and if the address does belong to the address space, the processor uses the index bits to index the routing table. The technique may of course be used in any situation in which a key must be reduced to a shorter index into a table. The Endpoint Client Egress Unit: An incoming packet on pole 317(i) comes in at 820(i) and goes to egress control unit (ECU) 1007(i) and to egress buffer (EBUF) 1003(i). ECU 1007(i) reads the destination for the packet from signals 821(i) and fields from the packet to make egress packet descriptor 1011. The fields are Buf, which indicates the location in buffer 1003 of the packet, WC, the packet's word count, Pri, its priority, the port it is intended for, whether it is a multicast packet, and whether the descriptor is valid. The descriptor is stored in an egress descriptor queue (EDQ)1009(i,j). There are four such queues, one for each pole/port combination. Within an EDQ 1009(i,j), there are subqueues for each priority. The subqueues are implemented by means of bit vectors. Each bit vector has as many bits as the maximum number of descriptors EDQ 1009(i,j). When a packet in EBUF 103(i) has a particular priority, the bit corresponding to the position of the packet's descriptor in EDQ 1009(i,j) is set in the bit vector for the priority. Associated with each EDQ 1009(i,j) is an egress buffer available (EBA) queue 1010(i,j). When a packet whose descriptor is in EDQ 1009(i,j) has been successfully sent from the port, the packet's descriptor is placed in EBA queue 1010(i,j). When the descriptor comes to the head of EBA queue 1010(i,j), the storage for the packet in EBUF 1003(i) is made available for another packet. Output of a packet to a port 1005(i) is controlled by the port's egress port arbiter (EPA) 1015(i), which handles the queues 1009 from one pole in strict priority order, using strict FIFO order within priority and round-robin ordering between poles with packets at the same priority. The descriptor taken from EDQ 1009(i,j) is the descriptor at the head of the highest-priority queue in that EDQ 1009(i,j). The packet that corresponds to the descriptor is then output at 1023(i). The descriptor 1011 for the packet moves into port 1005(i)'s Retry Descriptor Queue (ERQ) 1017(i) and given the form shown at 1019. ERQ 1017(i) is a single FIFO, which contain descriptors 1019 for packets in the order in which the packets were output to the port. As long as the descriptor 1019 remains in ERQ 1017(i), the packet remains in buffer 1003(i). Descriptors remain in the Retry Descriptor Queue until status for the link transfer is received via signal 1029, which indicates that the oldest descriptor 1019 in ERQ 1017(i) may be discarded and its buffer returned for reuse. In response to this signal, RTY CTL 1021(i) reads the descriptor 1019 at the head of ERQ 1017(i) to obtain the source Pole for the packet represented by descriptor 1019 and the buffer number for the packet's storage in buffer 1003. RTY CTL 1021(i) writes the storage's number back to the source pole's EBA 1010(i) and activates signal 823(i) to the source pole so that the ingress unit at the other end of the pole knows that buffer space is available for packets from this pole in this egress unit. Signals 1027(i) indicate when transmission of the packet starts, stops, or is aborted. It may happen that the recipient of a packet that has been output indicates that the packet was defective. In that case, the descriptor in ERQ 1017 is used to resend the packet. EPA 1015(i), ERQ 1017(i), and RTY CTL 1019(i) for the pole and the pole's EBR must all coordinate their behavior with the behavior of the corresponding components for the other three poles. This coordination is achieved by means of signals 1031, 1033, 1035, and 1037. Multicasting Packets RapidIO permits routing of copies of packets to multiple destinations. When a packet is to be multicast, its target address 125 specifies a multicast group ID. A list of ports is associated with the multicast group ID and the copies of the packet are output to all of the ports on the list. The multicast group IDs and the associated ports are specified in the CAR registers for a RapidIO device. In CSERD 301, multicasting for all of the RapidIO devices is done in endpoint client 308. The routing table for each port that receives packets to be multicast is set up so that the address space which it routes includes the multicast group IDs. A packet whose target address 125 specifies a multicast group ID is routed to CMCU port 824 in endpoint client 308. CMCU port 824 generally resembles port 803(i), but has the following differences:
Ingress multicast table IMT 825 and egress multicast table EMT 1013 are logically a single table. IMT 825 is located in the ingress unit of endpoint client 308. There is an EMT 1013 in the egress unit for each of the clients 307. EMT 1013 is located in the pole in the egress unit which is connected to endpoint client 308. The logical table has 1024 entries. Address space defining arrangement 901 is used to define an address space which includes all of the multicast group identifiers that will be received in the ingress unit. Each entry for a multicast group identifier specifies the pole/port combinations for the ports to which packets belonging to the multicast group are to be output. An entry in IMT 825 has four bits corresponding to the four poles; if a copy of a packet belonging to the multicast group is to be output to the pole, the bit corresponding to the pole is set. The corresponding entry in EMT 1013 for the specified pole has a bit for each port belonging to the egress unit. If the bit for the port is set, a copy of the packet is to be output to the port. Replication of a multicast packet thus happens in two stages: once in the ingress unit of endpoint client 308, where copies of the packet are made for each pole indicated in the IMT 825, and once in the far end egress unit for the pole, where copies are made for each port indicated in the EMT 1013 for the egress unit. Multicasting works as follows in CSERD 301. The IRTs 815 for all of the ports in CSERD that receive packets that are to be multicast have entries for the multicast groups to which the packets belong. The pole-port combination for all of those IRT entries routes the packet to CMCU port 824. There, IMT 825 and EMT 1013 indicate the routing for each copy of the packet to be multicast. CMCU 824 makes copies of the packets to be multicast, makes descriptors for them, and places the packets in IBUF 833 belonging to the CMCU port and the descriptors in IDQ 828. The multicast packets are then output as described above for the packets received in port 803(i). To the extent permitted by congestion in CSERD 301, the packets are output to all of the poles indicated in the packet's entry in IMT 825 simultaneously. In the far end egress units, the packet is placed in EBUF 1003(i) for the pole connected to endpoint client 308 and a descriptor for the packet is placed in EDQ 1009 for each port to which the multicast packet is to be output. An entry for the packet is also made in a multicast buffer available queue (MCBA) that exists for this pole's EBUF only. The entry has a bit for each of the ports; if a copy of the packet is to be output to a port, the bit for that port is set. As a copy of the packet is output from a port, the bit is cleared. When all of the bits have been cleared, the packet's storage in EBUF 1003(i) may be freed. The flow of an example multicast packet which comes to endpoint client 308 and must be multicast from a number of ports in the switches 306 is as follows:
The following additional steps occur if the destinations for the multicast include an endpoint 303(i):
The Serial Client Egress Unit: Congestion Control: Congestion Control Generally in RapidIO RapidIO controls congestion by means of flow control and packet priorities. The RapidIO standard provides for flow control both between RapidIO switches and between RapidIO end points. The mechanism employed is RapidIO flow control packets. There are two kinds of flow control packets: one that specifies that the source stop sending packets and another that the source resume sending packets. RapidIO switch devices may send flow control packets but are never the destinations for such packets. As may be seen from the use of flow control packets, the basic RapidIO model is that a packet source assumes that the RapidIO network can take a packet unless the source has received a flow control packet that indicates the contrary. As was mentioned in the discussion of endpoint client ingress unit 801, when the state of EBUF 1003 for a pole of a client 307(i) indicates that a flow control packet directed to the source of data for the port is necessary, IPA 820 causes Egress Buffer Manager 824 to make the flow control packet for the port and place it on the pole that returns the packet to client 307(i) for output by the client's egress unit. The foregoing presumes of course that EBUF 1003 in client 307(i) is able to accept the flow control packet. If it cannot because a port has ceased functioning, this will eventually be detected and a maintenance packet will be sent to deal with the problem. This packet will go to maintenance bridge 305, not to the client 307(i) with the broken port, and maintenance bridge 305 can directly cause client 307(i) to drop the packets in EBUF 1003 that are intended for the port. As previously mentioned, there are two priority bits in the physical bits 119, allowing for priority levels from 0 through 3, with 3 being the highest. The user can assign priorities to packets arbitrarily; typically, priority 0 is for ordinary data plane packets; priority 1 is for high priority data plane packets; priority 2 is for control plane packets; priority 3, finally, is for flow control packets and response packets. Flow Control Between Clients 307 of CSERD 301 Flow control across the poles of CSERD 301 is provided by buffer release signal 823 for the pole. The signal goes to the ingress unit at the other end of the pole and indicates that a packet has been sent from the pole's egress buffer 1003. The signal is received in the egress buffer manager 824 of the ingress unit at the other end of the pole and passed on to the ingress unit's IPA 820. IPA 820 will not send a packet via the pole unless the signal indicates that the egress unit at the other end of the pole has room for the packet. Dealing with Stalled Packets in CSERD 301 A packet is stalled in CSERD 301 when it is at the head of the IBUF for the port at which the packet entered CSERD 301 and remains there. A packet will stall if other packets with which the stalled packet is contending for access to the pole have higher priorities and are therefore given precedence over the stalled packet for output to the pole. Of course, if a packet remains stalled for any length of time, the IBUF for the port fills up and the EBM 824 issues a flow control packet to the port. A preferred embodiment of CSERD 301 deals with stalled packets by permitting IPA 820 in a client 307(i) to treat the stalled packet as though it had a higher priority than the priority indicated by its priority bits and if that doesn't end the stall, to drop packets whose descriptors indicate that they may be dropped. The values of the counters and of the pole, port, pri, ND, FC, and vld fields of head descriptor 1313 are output to IPA 1323, which is also aware of whether the port to which the packet is being directed (specified in the port field of the descriptor) is accepting data. When IPA finds that a packet can be output, it so indicates on output packet signal 1325 for IBUF 1303; if it finds that a packet must be dropped, it so indicates on drop packet signal 1327. There are two cases:
Stalled packet arbitration can be broadly characterized as employing the following method: a threshold time is established for determining whether a particular packet is stalled. In establishing the threshold time, the amount of space remaining in the buffer containing the stalled packet may be taken into account. When the threshold time is exceeded, the arbiter responds by treating the particular packet during arbitration as if the particular packet had a higher priority. Advantages of stalled packet arbitration include the following:
Stalled packet arbitration may be employed in any situation where a number of packets are contending for access to a resource. Details of Configuration Interface 515 A feature of the RapidIO architecture is the use of Capability Registers (CARs) and Control/Status Registers (CSRs). The CARs are read only registers which make the characteristics of a RapidIO device available to software which uses the device. The CSRs are writable registers which software may use to configure the device and determine the device's configuration. As shown at 533 in Addressing an Endpoint in a RapidIO Device with Multiple Endpoints While placing all of the CARs and CSRs in configuration interface 515 is advantageous in its own right both because it makes centralized control of the registers easier and because it simplifies the design of the clients 307, it also solves a problem which the RapidIO architecture poses for CSERD 301, namely that the architecture provides for only a single address for a RapidIO device, and consequently permits only one addressable component in a RapidIO device. CSERD 301, however, has two such addressable components, namely endpoints 303. To solve this problem, CSERD 301 has a mechanism which permits CSERD 301 to have more than one address and thus to have more than one addressable component. Addressing in the RapidIO Architecture: The CARs and CSRs of interest in the present discussion are device CARs and CSRs 1403. Included in CARs and CSRs 1403 are processing element features CAR 1405, which defines the kinds of components the device contains, switch port information CAR 1407, which indicates the total number of ports in the device, and base device ID CSR 1407, which specifies the device's ID in the RapidIO network to which the device belongs. There may be only one base device ID CSR 1408 in device CARs and CSRs 1403. To illustrate the problem posed by the architecture, Extending RapidIO to Provide for More than One Endpoint in a RapidIO Device: The challenge in extending the Rapid IO architecture to provide for more than one endpoint in a RapidIO device is to do so in such a manner that the device will continue to work with other RapidIO devices which adhere strictly to the standard and thus have no notion of a RapidIO device that has more than one base device ID. As shown in The information needed by another RapidIO device that is aware that CSERD 301 may have more than one endpoint is in user-defined address space 1505. User-defined address space 1505 contains an endpoint CAR and CSR list 1517 which contains copies 1508(0 . . . n) of the CARs and CSRs for each of the non-default endpoints. It further contains two registers: default_ep 1509 and num_endpoints 1513. If default_ep is null, the only endpoint is the default endpoint. If it is non-null, it includes a pointer to the default endpoint. The remaining endpoints are located using num_endpoints register 1513, which specifies the number of endpoints in the device and the offset 1515 of the start of endpoint CAR and CSR list 1517. The arrangements of Apparatus that employs the foregoing technique can be broadly characterized as follows: the apparatus has a first user-defined configuration register that indicates whether the network device has only an architectural address that is prescribed by the network's architecture and second user-defined configuration registers that contain the addresses of additional devices. When the first configuration register indicates that the device has only an architectural address, the device compares an address received in the device with the architectural address; when the first configuration register indicates that the device has additional addresses, the device compares the received address to the architectural address, and if the received address does not match the architectural address, to one or more of the additional addresses. The foregoing Detailed description has disclosed to those skilled in the relevant technologies how to make and use an integrated circuit which combines a number of RapidIO devices, and has further disclosed the best mode presently known to the inventors of making the circuit. It will be immediately apparent to those skilled in the relevant technologies that the techniques disclosed in the Detailed Description may be employed not only to make integrated circuits that combine Rapid IO devices, but for devices used in packet networks generally, whether or not implemented in integrated circuits and whether or not the network conforms to the RapidIO architecture. In particular, the use of poles to connect the input and output sides of multiported devices, the congestion avoidance techniques, the multicasting techniques, and the techniques for dealing with devices that have more than one address may be employed where the devices involved are not implemented in a single integrated circuit, and the techniques for defining an address space for a lookup table may be used in any circumstance where a large key has to be reduced to a smaller index. Details of the implementations described herein are of course necessarily affected by the fact that the implementation is implementing the RapidIO standard and are also affected by the exigencies of implementing such a complex device in an integrated circuit. For all of the foregoing reasons, the Detailed Description is to be regarded as being in all respects exemplary and not restrictive, and the breadth of the invention disclosed herein is to be determined not from the Detailed Description, but rather from the claims as interpreted with the full breadth permitted by the patent laws. Patent Citations
Referenced by
Legal Events
Rotate |


text:
Poll: Pregnancy Bathroom Habits
Has being pregnant affected your bathroom habits?
81% | Yes -- ugh! | ||||||
19% | No, thankfully! | ||||||
192 Total votes cast. |
Top Polls:
Rewarding Good GradesIs it okay to reward good grades with cash?
If your child were the victim of a bully, what would you do first?
Thanksgiving Main Course
What's the main course for your family's Thanksgiving feast?
Bedtime Reading
How often do you read to your kids?
Stay-at-Home vs Working Moms
If money or quality child care were not an issue, which option would you choose?

subset: commoncrawl


text:
News Flash! I'm gonna kick your ass!
Don't you try and run! Face the Light!
News Flash! Here comes the cavalry!
Mono e mono, let's Fight, Fight, Fight!
Human paralysis from media games!
Children cower from corperate gains!
Governing fairy tales, all uncooth,
throw in some monarchs, we'll never be soothed!
News Flash! Robotic Albert Einsteins!
Can metaphorical shrapnel be the only one?
News Flash! If your system had a face...
I would kick it in the balls! Just for fun!
APC's lined near and far...
political masks, don't know who you are...
A legion of entrenched stocks and shares...
Finding one decent motherfucker is awefully rare!
ooooh... wa-oh... wa-oh...
You only truly cared about your-
self... wa-oh... wa-oh...
Life for me is just an empty
shelf... wa-oh... wa-oh...
Feeling so hidden, so
caged... Hoo-rah! Hoo-rah!
Can't contain this Primal Rage!
News Flash! Hear me out.
News Flash! I need not to kill.
News Flash! Surrender Now.
News Flash! It's not a thrill.
News Flash! I'm not afraid.
News Flash! You cannot win.
News Flash! Your religious bullshit.
News Flash! It's you who sinned.
Now i'm here to make.
| Email this Short story
| Add to reading list


text:
Contributors to our blogs are faculty, alumni, and students of Seminary of the Southwest sharing their reflections from the context of a community of faith. We hope you enjoy reading, and we invite your comments.
Two months in Peru: mission, adventure, and study
Rising senior William "Rod" Clark spent two months in Peru learning about the mission of the Anglican Diocese of Peru. We invite you to read and view his adventures and reflections on mission.
We Heart Austin in July
T.J. and Annie Freeman enjoy Austin, even in the hot summer. Follow their We Heart Austin posts for their favorite places to hang out in this great city. T.J. has completed his second year towards an MDiv. They came to us from the Diocese of Indianapolis.


text:
Pop Culture Junkies
Here are some celebs who's birthday is today! To learn more about them and how old they are turning click on their name!
Ahmad Rashad
Allison Janney
Billy Sunday
Calvin Klein
DeAngelo Hall
Dick Cavett
Gail Devers
Jack Welch
James A. Garfield
Jim Mora Jr.
Jodie Foster
Larry Johnson
Larry King
Matt Sorum
Meg Ryan
Michael Wilbon
Miss Elizabeth
Robert Beltran
Terry Farrell
Help me wish they a Happy Birthday!! Is today your birthday too??


text:
Three separate drilling plans were created to save the 33 Chilean miners trapped in the San Jose mine. Margaret Warner talks to one Americans who helped orchestrate the rescue. Continue reading
In a documentary airing on most PBS stations, "Nova" captured the gripping story of the 33 Chilean miners trapped underground for more than two months and explores the science used to rescue them. Continue reading
A group of trapped Chilean miners is being lifted to freedom on-by-one in a gripping rescue scene. Jonathan Miller gives a recap of the dramatic rescue from the site at the San Jose mine. Continue reading
Much has been done to keep the Chilean miners in good spirits but what about the families of these miners? Tom Bearden reports from Chile on how they are holding up. Continue reading
It's been a month since a mine collapse in Northern Chile trapped 33 men. As efforts continue to keep them healthy and happy, a rescue date still isn't set. Jeffrey Brown talks to Tom Bearden about the options being used in the rescue efforts and how the miners and their loved ones are holding up. Continue reading
The 33 trapped Chilean miners have been stuck underground for 21 days and they may not get out until Christmas. Tom Clarke of Independent Television News reports. Continue reading
In Chile, 33 miners trapped for 17 days were found to be alive, but they face months more underground before they can be rescued. Matt Craze of Bloomberg News updates the rescue efforts. Continue reading


text:
Skylight SOHO. January 26, 2012. By Bennett Marcus
New York magazine once did a shoot of your apartment. Why weren't your cats in it? "They don't come out. They're very shy. They hid under the couch." —JASON WU
Do you have any inexpensive staples that you wear all the time? "A staple… I have so many clothes, there's nothing I wear all the time. Which is, like, a really good problem to have." —BLAKE LIVELY
Do you have Super Bowl plans? "I was actually asking my publicist yesterday if I could go. I was, like, 'Is there any way I can get a ticket to go to the Super Bowl?' I've never been, so I think it would be fun. I don't know football." Do you think Tom Brady looks better with short hair or long? "Short. Short." —CHLOË MORETZ
We hear you're actually quite a good cook. Any specialties? "I'm big into lobster risotto right now." What's your secret? "Butter. Like Paula Deen." —EMMY ROSSUM
Are you shopping tonight? "No. I feel like everything is already going to be gone by the time I get in there. I'm going to have to go to the Target in Encino when I get back home. I'm hoping that people in Encino – nothing against them – but maybe they won't know about Jason Wu." —JAIME KING
Are you an aggressive shopper? "I am a meek, meek shopper, and my stylist will tell you that, too. I lose patience really easily; I'd rather shop in the grocery store than in the department store. I can pick an apple like nobody's business." —GAIL SIMMONS


text:
Whether you use the term managed services or application service providersor use the currently trendy term of on demandhosted solutions provide a quick and simple way for businesses to get up and running with an enterprise application. Ricohs DocumentMall, which was updated in May, is no exception, providing a capableif somewhat simplesolution for storing, sharing and managing corporate documents and other digital media.
During tests, eWEEK Labs was able to quickly get up and running using DocumentMall, and it was simple to load and share documents using the service.
However, the product does have shortcomings. Rather than enabling complex workflows by default, DocumentMall is limited to processing documents mainly through routing and permission settings. In addition, Microsoft Corp.s Internet Explorer with an ActiveX control enabled is required to make full use of the Web-based interface.
Furthermore, although Ricoh generally does a good job of securing access to DocumentMall, companies will have to decide whether theyre comfortable with sending and storing sensitive documents outside their corporate infrastructure.
Click here to eWEEK Labs review of Xythos Enterprise Document Management Suite.
DocumentMall pricing is based on the service contract length (either one or three years) and the amount of storage purchased. One gigabyte of storage for one year is priced at $800. As the amount of storage and the length of the contract increase, the price paid per year decreases.
The underlying technology of DocumentMall is based on the venerable Documentum application (acquired through EMC Corp.s purchase of Documentum Inc. in 2003). However, the Web-based interface of the Ricoh system has only a passing resemblance to the Documentum interface and is clearly designed to be more simple and intuitive.
From this interface, users have access to an in-box showing documents that have been shared, routed or sent, and users can see all public and personal document cabinets, or document folders. It was very simple during tests to create folders and upload multiple documents, applying simple permission settings along the way.
Documents can be routed to other users via e-mail, DocumentMall in-boxes or both, and basic permission settings control who can access the documents and how. The product provides standard check-in and check-out capabilities and includes a Citrix Systems Inc. applet for viewing documents when a user does not have the necessary application. We also liked the simple audit button that provides all the usage and tracking information for a document a user has appropriate rights to.
Documents can enter the system via other methods as well. Not surprisingly, given Ricohs experience as a hardware vendor, Ricoh scanners with multifunction capabilities can be upgraded with firmware that lets them scan directly to DocumentMall cabinets. Documents can also be sent via e-mail-based Internet faxing.
We found administration of DocumentMall as basic and simple as the products main interface. We could manually add users and groups to the system or upload a text file with user information, but there is no direct integration with company directories. We could also define attributes for custom document types, create basic user group permission sets and view detailed audit logs for the entire deployment.
Next page: Evaluation Shortlist: Related Products.


text:
Coffee Articles
Francesco Sanapo On stage now!
1602/06/11 Coffee NewsJoyful music makes this Italian shine! His technicals seem perfect from the stands. His charismatic personality seems to match his coffee. I could see Francesco going on to the semi finals, but we'll have to wait and see. "I love my work" "Fantastic experience" Francesco Sanapo
Tim Wendolboe, 2004 World Barista Champion shares his thoughts on competing
1502/06/11 Coffee News -
Stefanos Domatiotis from Greece!
1302/06/11 Coffee NewsDown to the very last second, Stefanos from Greece just competed moments ago for the 5th time returning to the WBC! He has worked very hard to win all 5 National Championships. Not many people do that! I'll be back with a backstage interview with Stefanos


text:
MONKTON — Water quality tests done by the Lewis Creek Association late last week have determined that two swimming sites in northern Addison County are currently unsafe for swimming.
The sites, along Lewis Creek at Route 7 in Ferrisburgh and Tyler Bridge Road in Monkton, tested for unsafe levels of E. coli.
ADDISON COUNTY — Between golden rays of early morning light last Wednesday, three volunteers for the Addison County Riverwatch Collaborative weaved through patches of poison parsnip along the Lemon Fair River. Middlebury College professor Kathy Morse, Cornwall's David Anderson and Starksboro's Matt Witten were taking samples and running various tests to monitor the Otter Creek tributary's health.


text:
Filed under: Capitalism, Economy, Freedom, Taxes | Tags: Debunking Liberal Lies, Economy, The Federal Reserve, The Finincial Crisis
I am an enormous fan of the Hoover Institution's Uncommon Knowledge programs. This last week, Peter Robinson interviewed Richard A. Epstein and John Taylor. Peter Robinson's question: Are we all Keynesians Now? After introducing the opposing approaches to economics of John Maynard Keynes and Milton Friedman, economists Richard Epstein and John Taylor discuss U.S. monetary policy from the 1970s onward.
Richard A. Epstein, on the left above, is a founder of the field of law and economics. He is director of the John M. Olin Program in Law and Economics at the University of Chicago and a fellow at the Hoover Institution. John Taylor is a former undersecretary of the Treasury for international affairs. He is a fellow at the Hoover Institution and a professor of economics at Stanford University.
The controversy in the world of economics and finance today is between the Keynesian economics that the Obama administration follows and the free market ideas of Milton Friedman that the Republicans believe are proven to be more effective.
This interview is like sitting in on a conversation with three brilliant friends. Each segment in about 6 minutes long, so you can watch at your pleasure. What's neat is that you can go back and review any part that you didn't understand. Unlike those college seminars, if you didn't take good notes, all you have to do is play them over again.
The previous interviews are all available at the same link above. They range from Thomas Sowell, to Dambisa Moyo, Charles Kesler, Antonin Scalia and John Bolton to mention only a few of the many guests. I recommend them highly.
Filed under: Capitalism, Democrat Corruption, Economy | Tags: Auto Bailout, Czars, Rewarding Unions, The Federal Reserve
Since 1955, the share of workers who belong to a union has dropped from 33 percent to about 11 percent. Though unions have become increasingly unpopular, they managed to scrape together $52 millions of member dues to donate to Democrat political campaigns this last year. The unions have helped to wreck two major industries, automobiles and steel.
Democrats are not ungrateful. The Unions have been rewarded with shares of GM and Chrysler that should belong to the taxpayers. Now, Denis Hughes, president of the AFL-CIO in New York, who has been interim head of the New York board of the Federal Reserve since May, when Stephen Friedman stepped down, is expected to become permanent head. So now this union activist has been elevated to one of the most important financial posts in the country, a troubling sign of the Obama administration's over-reliance on organized labor.
Federal Reserve chief Ben Bernanke has been nominated to a second term, no surprise, as this is a time of unusual financial crisis. The naming of Denis Hughes is the surprising news, of the 'what could they be thinking' kind.
Hughes has no significant financial experience. He is not an economist, and his educational background does not inspire confidence. He has a B.S. degree from the Harry Van Arsdale School of Labor Studies at Empire State College. His experience has been as a union official and political operative. His entire career has been spent strong-arming and fighting the very people he will now be regulating. He may be more expert at extracting concessios from corporate America than in the complications of high finance.
As Investors Business Daily asks:
More to the point, can those on Wall Street who come before him in routine regulatory matters expect fair treatment? Will union issues become part of the New York Fed's agenda? Will banks find requests to expand or merge stymied because unions fear a loss of jobs somewhere?
Elevating a person to the most important of the Fed Banks, whose experience would suggest an inbred hostility to capitalism and free markets, seems dangerous. Yet the White House has also named former United Steelworkers adviser Ron Bloom from head of the auto task force to "industrial policy czar" in charge of manufacturing. Itself an astounding nomination. Where does this government find the authority for an "industrial policy czar?" And since when does America have an industrial policy?
Unions have consistently been hostile to capitalism and the free market. They are opposed to free trade, and favor restrictions. They are inclined towards protectionism in the contrary belief that imports will damage their own opportunity. They favor minimum wage laws which harm beginning workers.
Unions are being rewarded with huge chunks of stimulus funds for construction and infrastructure projects that are restricted to union labor. Stimulus funds will also go to rescue union pension funds which are in financial trouble, since they spent their union dues on politics.
Policies always have consequences, and Democrats have little interest in consequences, only in their good intentions. High labor costs and hostility to the free market will drive business and investment overseas. Unemployment will continue to rise— including union jobs— and economic recovery will be long, long delayed.


text:
Permanent URL to this publication: http://dx.doi.org/10.5167/uzh-4728
Schmidlin, P R; Müller, J; Bindl, A; Imfeld, H (2008). Sinus floor elevation using an osteotome technique without grafting materials or membranes. International Journal of Periodontics and Restorative Dentistry, 28(4):401-409.
| Accepted Version 1MB |
This retrospective study aimed to radiographically assess sinus floor remodeling after using a modified osteotome technique without graft materials or membranes. After pilot drilling, residual bone was fractured and raised with the schneiderian membrane to the final implant length using osteotomes. Self-tapping implants were placed, and restorations were placed 6 months later. Twenty-four patients were available for follow-up after a mean observation period of 17.6 +/- 8.4 months. The implant survival rate at that time was 100%. Bone filling around the implants was measured and compared with baseline digital radiographs. New bone formation was 86.3% +/- 22.1% mesially and 89.7% +/- 13.3% distally. In nine cases, digital volume tomography was used to verify regeneration. Within the limitations of this study, use of the schneiderian membrane led to considerable bone regeneration, and good clinical success was achieved despite the omission of graft materials.
Citations | Downloads |
Additional indexing
Item Type: | Journal Article, refereed, original work |
Communities & Collections: | 04 Faculty of Medicine > Center for Dental Medicine > Clinic for Preventive Dentistry, Periodontology and Cariology |
Dewey Decimal Classification: | 610 Medicine & health |
Language: | English |
Date: | August 2008 |
Deposited On: | 06 Nov 2008 15:58 |
Last Modified: | 27 Nov 2013 19:51 |
Publisher: | Quintessence Publishing |
PubMed ID: | 18717379 |
Users (please log in): suggest update or correction for this item
Repository Staff Only: item control page


text:
Jon Teitel's McDonald's All-American Lineup Projections
Plus 2 teams whose All-American will no longer be with his prior team
(All-American year in parentheses)
Incoming 2012 All-Americans in Bold
Underclassmen who have declared for draft in italics
G: Larry Drew II (2008)
G: Tyler Lamb
F: Shabazz Muhammad (2012)
F: Travis Wear (2009)
F: David Wear (2009)
Early 2012-13 Ranking: Teams 31 to 45
Continuing with the Early 2012-13 Ranking, here are teams 31 to 45.
NCAA Tournament Interviews: Arizona's Miles Simon
Jon Teitel: You played at Arizona for Hall Of Fame coach Lute Olson. What made him such a great coach?
Conference Finals Predictions: Big 12, Big East, Pac-12 & More
- Akron
- America East
- Arizona
- Baylor
- Bethune-Cookman
- Big 12
- Big East
- Big West
- Cincinnati
- Colorado
- Conference USA
- Lamar
- Louisville
- Marshall
- McNeese St
- Memphis
- Missouri
- Nevada
- New Mexico
- New Mexico St
- Norfolk St
- Ohio
- Pac-12
- San Diego St
- Southland
- Stony Brook
- Texas Southern
- Vermont
- Conference Tournaments
- Game Predictions
Montana Wins Big Sky Title: Wednesday's Quick Hitters
UConn and USF were the big winners on Wednesday at Madison Square Garden, while West Virginia and Seton Hall now await their NCAA tournament fate.
Bracketology: Remaining Teams That Can Steal Bids
bubble teams were able to
breathe easier when Murray St and Creighton won close conference titles, the
coast is not entirely clear.
Here's a brief look at the remaining teams most likely to "steal" bids from the
bubble hopefuls**.
Poll: Which Projected 13 Seed Would You Be Most Afraid to Face?
Bracketology: Arizona In, Texas on Edge, St. Joseph's Close
Davis Leads #1 Kentucky Past Vanderbilt: Saturday's Quick Hitters
#4 Kansas clinched their eighth consecutive Big 12 title with a wild 87-86 overtime win over #3 Missouri, placing head coach Bill Self in some esteemed company. Here are today's "Quick Hitters":
Bracketology Implications: What To Know On Thursday
Latest Articles
- Bracketology: Selection Sunday Projection
- Bracketology: Saturday Night NCAA Tournament Projection
- Non-BCS Top 25: Creighton, Colorado St Rise
- College Basketball Top 50: Indiana Ends Regular Season #1
- Non-BCS Top 25: Valpo Replaces BYU
- College Basketball Top 50: Maryland and Iowa St Drop Out
- Non-BCS Top 25: Davidson In, Wyoming Out
- College Basketball Top 50: #2 Gonzaga Hits All-Time High
- Non-BCS Top 25: Air Force, Davidson Making Moves
- College Basketball Top 50: Another Week, Another #1


text:
Love you too!
Added to Bag!
We'll let you know if it's back in stock!
Added to Wishlist!
Pickin' Party Scarf
$19.99 $5.9970% off!
Grab your mandolin or fiddle, wrap this sheer, plaid scarf over your complementary plaid button-up, skinny cords, and western booties, then gather with your most musically-inclined pals! With accents of orange, navy, and green, framed by light fringe, this flowing wrap is one in which you'll love to jam!
Final Sale: This item cannot be returned or exchanged.
- 100% Cotton.
- Measures 73 x 28 inches.
- Machine wash.
- Imported


text:
It will tough to manage all your fan mails! LOL!
Rani is one of my very favorites, dearest! :)
She's gorgeous honey.
Apr 29th, 2011 Replylol this is so funny, DA is already so much work and now I am here too, but big hugs to you babes
Apr 30th, 2011 ReplyThe work on the robe is absolutely fantastic. I'm not a fan of the framing though.
Apr 29th, 2011 ReplyVery gorgeous painting! Love the details on the textures and it's nicely well done.
Apr 29th, 2011 Reply


text:
3. Eco-friendly concept design For eggs packaging made of hay. By Polish designer Maja Szczypek.
Via designtaxi.com
5. German footwear chain Görtz created these bird displays for their children's section with shoelaces serving as worms.
Via thedrum.com
6. Another concept design for a fictional vodka brand: "Spine." More than any other liquor, vodka is pure marketing, so I wouldn't be surprised to see this on shelves some day. By German designer Johannes Schulz.
Via designtaxi.com
7. Campbell's has partnered with the Andy Warhol Foundation to produce a limited edition range of tomato soup cans inspired by the artist's work. The cans are available in British markets starting today.
For the third straight summer, Russia held an ad and design "Feykstival" — for concept work. This year it was held in Riga. Here are three of the winning package designs.


text:
From Joomla! Documentation
Revision as of 20:46, 10 May 2013 by JoomlaWikiBot (Talk | contribs)
This Namespace has been archived - Please Do Not Edit or Create Pages in this namespace. Pages contain information for a Joomla! version which is no longer supported. It exists only as a historical reference, will not be improved and its content may be incomplete.
Destroy the data for a particular session identifier in the SessionHandler backend.
Description:JSessionStorageDatabase::destroy [Edit Descripton]
public function destroy ($id)
Parameter | Type | Default | Description |
$id | string | The session identifier. |
- Returns boolean True on success, false otherwise.
- Defined on line 123 of libraries/joomla/session/storage/database.php
- Since
See also
- JSessionStorageDatabase::destroy source code on BitBucket
- Class JSessionStorageDatabase
- Subpackage Session
- Other versions of JSessionStorageDatabase::destroy
SeeAlso:JSessionStorageDatabase::destroy [Edit See Also]
User contributed notes
<CodeExamplesForm />


text:
Eyes on the road? Augmenting traffic information
Document type: | Conference Papers |
Peer reviewed: | Yes |
Author(s): | Martin Johansson, Mårten Pettersson |
Title: | Eyes on the road? Augmenting traffic information |
Conference name: | Designing Augmented Reality Environments |
Year: | 2000 |
Pagination: | 147-148 |
Publisher: | ACM Press |
City: | Elsinore, Denmark |
Organization: | Blekinge Institute of Technology |
Department: | Department of Human Work Science and Media Technology (Institutionen för arbetsvetenskap och medieteknik) Dept. of Human Work Science and Media Techn., S-372 25 Ronneby +46 455 38 50 00 http://www.iar.bth.se/ |
Authors e-mail: | email@example.com, email@example.com |
Language: | English |
Abstract: | This position paper outlines design ideas gained from a project dealing with different interaction concepts when designing a computer based navigation systems for truck drivers working over large areas and where the delivery and pick-up points from time to time are unfamiliar to the driver. The extension of this previous project includes more ?untraditional? technology, but has the same approach and uses the same basic concepts. Both the original design and the new design are based on an empirical study of truck drivers work practice. |
Subject: | Human Work Science\Human Computer Interaction Human Work Science\Work Practice |
Keywords: | Augmented reality, Interaction paradigms, Traffic information, Work Practice based design |
Note: | Available via ACM Digital Library (www.acm.org) |