Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
  • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
  • G06F12/02—Addressing or allocation; Relocation
  • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
  • G06F12/10—Address translation
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
  • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
  • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

• the present invention pertains to on-chip systems. More particularly, the present invention relates to a method and apparatus for a configurable address mapping and protection architecture and hardware for on-chip systems.
• the operational model for most computer and/or on-chip systems involves the sending of requests from one or more processing units to one or more service modules in the system.
• a service module Upon receiving a request (i.e., an instruction) from a processing unit, a service module completes the task as requested. Then, there may be responses to be returned from the service module back to the processing unit. It is also very common to have a component in the system to act as both a processing unit and a service module.
• Many different ways may be used to deliver requests and responses between processing units and servicing modules.
• One of the most frequently used methods, for delivering the requests is by addressing (plus, protection checking). For instance, a request is tagged with a "destination address” and a "source protection identification (ID)".
• the destination address tells where the service module(s) is (are) located, and/or how to deliver the request to the service module(s).
• the source protection ID identifies the processing unit and is used to determine whether the service module(s) should execute the request, or whether the request can be delivered to the service module(s), thus providing access to the service module selectively depending on source identity.
• the number of transistors (often referred to as "gates") and the resulting gate size (and thus area) of the hardware module (on for example, an integrated circuit) devoted to address decoding and protection ID checking are comparatively large. Additional circuitry, which consumes more power, may also be needed in order to make this decoding and checking hardware dynamic (i.e., configurable) during operation.
• a wireless device especially, where the demand for a smaller chip die size and a lower power consumption is high, a large and power-consuming address decoding and protection-checking module is unacceptable. This presents problems.
• Figure 2 is a block diagram of a computer system
• Figure 3 illustrates one embodiment of the invention showing in a block diagram form an on-chip system with N processing units, M service modules, an address mapping and protection module, and a request-delivery module;
• Figure 4 illustrates one embodiment of the invention showing in a flowchart form the process in generating optimized address mapping and protection hardware
• Figure 5 illustrates one embodiment of the invention showing in block diagram form a hardware implementation for the configurable address mapping -and protection architecture
• Figure 6 illustrates one embodiment of the invention showing tin table form, a definition of some possible read-only, read-write, or not-accessible configuration parameters
• Figure 7 illustrates one embodiment of the invention showing in table form, a definition of some possible not-accessible configuration parameters.
• a method and apparatus for a configurable address mapping and protection architecture and hardware for on-chip systems are described.
• Figure 1 illustrates a network environment 100 in which the techniques described may be applied.
• the network environment 100 has a network 102 that connects S servers 104-1 through 104-S, and C clients 108-1 through 108-C. More details are described below.
• Figure 2 illustrates a computer system 200 in block diagram form, which may be representative of any of the clients and/or servers shown in Figure 1. More details are described below.
• circuitry for providing the necessary address mapping and protection functionality is provided in hardware.
• the invention allows a product designer to configure the address mapping and protection module at design time, such that, only the minimum specified mapping and protection is implemented into the hardware.
• the final gate size and power consumption of the address mapping and protection hardware module is determined by the specification of the product.
• the address width and data word width for each of the service modules may also be considered and used to minimize the number of signal wires to/from the service modules. This may result in hardware that is not over designed and may more easily meet the gate count and power consumption requirements of a product.
• a set of configuration parameters that may lead to overall gate size reduction, power consumption reduction, and/or the elimination of unnecessary signal wires for a final address mapping and protection hardware module.
• Figure 4 shows the processing flow that can be used in generating optimized address mapping and protection hardware.
• the architecture (423) includes the definition of the address mapping scheme, the definition of the protection scheme, the definition of the set of configuration parameters, and the definition of the specification language.
• the designer can design the address mapping and protection module with minimum hardware based upon the product requirements (405). Based on the product requirements and user models, the designer should be able to decide, for instance, the number of service modules in the system, the number of address regions for a service module, and how the information of an address region is going to be used (443).
• the designer needs to specify the address mapping and protection hardware module using the provided specification language (407 and 425).
• a post-processing tool which takes the design specification as input, is used and generates an optimized hardware gate-level netlist (427) for the address mapping and protection hardware.
• Figure 3 shows a block diagram of one embodiment of the invention having an on-chip system with N processing units at the top (302-0, 302-1 , through 302-N), and M service modules at the bottom (318-0, 318-1 , through 318-M).
• N processing units at the top (302-0, 302-1 , through 302-N
• M service modules at the bottom (318-0, 318-1 , through 318-M).
• an address mapping and protection module 306 showing the address mapping 308 and protection key map 310 followed by a request-delivery module 314.
• Figure 3 only shows the request delivery side of the system (i.e., the request side and does not show the return side).
• the use model of the system is the following:
• a request is sent from a processing unit (such as 320-N) to the address mapping and protection module (306).
• the request (such as that illustrated at 312 and 316) is sent to the service module (such as 318-2) by the request-delivery module (314).
• the address space for the entire on-chip system may be divided into R address regions.
• Each service module in the system may have multiple address regions.
• multiple address regions may be grouped into one address segment.
• a processing unit needs to tag the request with an address that is within an address region of the module.
• the information about an address region is kept in a region register stored in the address map hardware.
• Information about an address segment is kept in a segment register, which is also stored in the address map hardware.
• each protection key is kept in one protection key register, which resides in the protection key map hardware.
• Each address region is associated with at least one protection key, and each processing unit is assigned with one or more protection ID.
• the request is tagged with a protection ID (such as 515 shown in Figure 5) of the processing unit.
• the protection ID is checked against those protection keys associated with that address region to see whether it is safe to forward the request to the service module.
• Figure 5 shows one embodiment of the invention having ashardware implementation of the address mapping and protection architecture mentioned above.
• a request is shown with its destination address tag and protection ID tag (such as illustrated in Figure 3 at 304).
• the destination address contains three parts, a segment (base) address part 501a, a region (base) address part 501 b, and the offset within the region 501c.
• the address mapping hardware contains the S segment registers (503) and the R region registers (505a, b, and c, for example; and there can be more region pages as shown in Figure 3).
• Each address segment may contain multiple address regions - this is illustrated by having one page of region registers associated with each segment register (pages 505a, 505b, and 505c are associated with, for example, segment register 0, segment register 1 , and segment register 2, respectively.
• Figure 5 also shows that the address segment 0 has five region registers (505a).
• segment address of a request is used to match one of the segment registers (509), and the region address is used to match one or more of the region registers kept in the address map. Combining the two matching signals, in a normal case, one single match happens (511). Note that a duplicate match and a failed match may be detected, if desirable, as errors.
• the protection key register number associated with the region is returned (519); and the routing information for the targeting service module is also returned (513).
• the protection key register number (519) is used to filter out unrelated matches coming out of the protection key map module (517).
• a positive security okay signal (521) indicates that the request can be delivered to the servicing module.
• Table 1 shows a summary of the combinations and the results of a normal matching case (i.e., a single address match is identified and security check is also okay), and error cases.
• a normal matching case i.e., a single address match is identified and security check is also okay
• error cases i.e., a single match is identified.
• Information (saved in the matched region register) about the destination service module is forwarded to the downstream modules. For instance,
• the protection key ID is forwarded to the "Security Check Okay" circuit in order to complete the security check.
• the destination service module's data word width and physical target ID are forwarded to the request-delivery module.
• a set of configuration parameters and registers are also identified for the architecture mentioned above such that a designer can adjust them in order to build the address mapping and protection module with minimum hardware. The final goal is to reduce the hardware module's gate size, power consumption, and signal wires.
• DataWidth This parameter represents the data word size of a request. Different data word sizes can be allowed for requests coming from different processing units. However, only a single data width parameter is used here; thus, requests coming from the processing units have the same data word size. Setting this parameter to only the needed data word size can save gates and wires in the hardware module.
• AddrWidth This parameter represents the address tag width for the on-chip system; i.e, the dimension of the address mapping and protection module. Setting this parameter to only the needed address width can save a great number of gates and wires in the hardware module.
• SegmentSize register field This field tells the size of a segment; it can be used to reduce the number of bits for a segment register.
• RegionSize register field This field tells the size of an address region; it can be used to reduce the number of bits for a region register.
• RegionBase register field This field indicates the region base address of an address region.
• RegionProtectionKeyRegisterNum (RPKRN) register field This field tells which protection key register is to be used by the security checking logic when a single match occurs on this address region. Multiple register fields of this type can exist, however, only one is used here.
• RegionDataWidth register field This field tells the data word width of the service module that links to an address region. It can be used to trim data bus wires, if possible, connecting to the service module. It can also be used to indicate whether data packing or unpacking is needed; packing or unpacking may be needed when the data word size of a request's source processing unit is different from the data word size of the request's destination service module.
• RegionPhysicalTargetlD (RPTID) register field This field describes the physical linkage between an address region and a service module. This physical linkage can be, for example: (1) hardware routing information to be passed on to the request-delivery module in order to deliver a request to the service module; or (2) a hardware signal bit position such that, when the request-delivery module asserts the signal, a request is sent to the service module.
• RegionAddressSpace (RAS) register field This field allows an address region of a service module to be further partitioned.
• RegionEnable register field This field indicates whether or not this region register is used for the current design or to indicate whether the region is currently available; -
• NumProtectionKeys This parameter indicates how many protection key registers can exist in the system and is used to remove un-needed protection key registers. In addition, it can also save bits in each of the region registers, where a protection key number is stored.
• each of the registers can also be specified to be one of the following three usage types so that a minimum logic design can be applied to construct the hardware to save area and power:
• Non-Accessible (NA) Register Field A register field is hardwired to a power-on value and cannot be read, nor written.
• Register Field A register field is hardwired to a power-on value and needs to be software visible (read-only) during operation. In this case, extra gates are needed in order to allow the software read access of the register field.
• RW Read-Write Register Field
• extra circuitry for example, in the form of flip-flops and gates
• each register field can also be specified as an "exporting constant” (EC) register field such that the netlist portion of the register field is exported to the top-level of the final netlist. It makes the power-on value of a register field more easily to be manually modified, as needed by a product, late during the full chip generation process.
• the ProtectionKeyBitVector register field of each of the protection key registers can be declared as "exporting constant” field; therefore, it allows a final protection key map to be put into the chip late in the product generation process.
• Figure 6 and Figure 7 show two almost identical address mapping and protection configurations.
• the register fields in Figure 6 are of RO, RW, or NA type; however, for Figure 7, all register fields are of NA type, plus, the un-used region register 1 is removed.
• the number of flip-flops (also referred to as flops) saved in Figure 7 is 82; that is no flops are used in the address map (308) and the protection key map (310) as shown in the center of Figure 3.
• the address width of the hardware module is reduced from 20 to 17, and (2) the number of protection IDs is scaled down to 8, additional buffer register bits and signal wires can be saved versus the Figure 6 case.
• SegmentBase 0x10000 ⁇ access RW ⁇
• RegionAddressSpace 0 ⁇ access RO ⁇ RegionEnable: Yes ⁇ access RW ⁇
• RegionPhysicalTargetlD link to ServiceModule 1 using "targetselect pin 1" ⁇ access NA ⁇
• RegionAddressSpace 1 ⁇ access RO ⁇ RegionEnable: No ⁇ access RW ⁇
• RegionBase 0x00000 ⁇ access RW ⁇
• RegionProtectionKeyRegisterNum 0 ⁇ access RW ⁇ RegionDataWidth: 4B ⁇ access NA ⁇
• RegionPhysicalTargetlD link to ServiceModule 0 using "targetselect pin 0" ⁇ access NA ⁇
• RegionAddressSpace 0 ⁇ access RO ⁇ RegionEnable: Yes ⁇ access RW ⁇
• RegionSize 4KB ⁇ access RO ⁇
• RegionBase 0x10000 ⁇ access RW ⁇
• RegionProtectionKeyRegisterNum 1 ⁇ access RW ⁇
• RegionPhysicalTargetlD link to ServiceModule 2 using "targetselect pin 2" ⁇ access NA ⁇
• RegionAddressSpace 0 ⁇ access RO ⁇
• RegionPhysicalTargetlD link to ServiceModule 3 using "targetselect pin 3" ⁇ access NA ⁇
• RegionAddressSpace 0 ⁇ access RO ⁇ RegionEnable: Yes ⁇ access RW ⁇
• ProtectionKeyBitVector 0x007B ⁇ access RW and EC ⁇
• ProtectionKeyBitVector 0x0085 ⁇ access RW and EC ⁇ ⁇ [0032]
• the address region 1 is disabled at the initialization time (i.e., the region register's RegionEnable field is set to "No"), but can be re-configured at run-time because the field is read/writable.
• the request address width is 20 bits and data word size is 16 bits.
• ServiceModule 0, 1 , 2, and 3.
• Address region 0, 1 , and 2 exist in the address segment 0 and are based at address 0x00100, 0x01000, and 0x0000, and of size 256 bytes, 4K bytes, and 16 bytes, respectively.
• the region register 1 is not enabled at the current time, but, can be used as a future addition.
• Address region 3 and 4 exist in the address segment 1 and are based at address 0x10000 and 0x11000, respectively; both are 4K-byte in size.
• RegionPhysicalTargetlD link to ServiceModule 1 using "targetselect pin 1" ⁇ access NA ⁇
• RegionSize 16B ⁇ access NA ⁇ RegionBase: 0x00000 ⁇ access NA ⁇ RegionProtectionKeyRegisterNum: 0 ⁇ access NA ⁇ RegionDataWidth: 4B ⁇ access NA ⁇
• RegionPhysicalTargetlD link to ServiceModule 0 using "targetselect pin 0" ⁇ access NA ⁇
• RegionAddressSpace 0 ⁇ access NA ⁇ RegionEnable: Yes ⁇ access NA ⁇
• RegionProtectionKeyRegisterNum 1 ⁇ access NA ⁇
• RegionPhysicalTargetlD link to ServiceModule 2 using "targetselect pin 2" ⁇ access
• RegionAddressSpace 0 ⁇ access NA ⁇
• RegionSize 4KB ⁇ access NA ⁇ RegionBase: 0x11000 ⁇ access NA ⁇ RegionProtectionKeyRegisterNum: 0 ⁇ access NA ⁇ RegionDataWidth: 4B ⁇ access NA ⁇
• RegionPhysicalTargetlD link to ServiceModule 3 using "targetselect pin 3" ⁇ access NA ⁇
• RegionAddressSpace 0 ⁇ access NA ⁇ RegionEnable: Yes ⁇ access NA ⁇
• PROTECTIONKEY(O) ⁇ ProtectionKeyBitVector: 0x007B ⁇ access NA and EC ⁇
• PROTECTIONKEY(l) ⁇ ProtectionKeyBitVector: 0x0085 ⁇ access NA and EC ⁇
• a post-processing tool which takes the specified design (such as the specification text shown above) as input, is used and generates an optimized hardware netlist for the address mapping and protection hardware.
• Figure 1 illustrates a network environment 100 in which the techniques described may be applied.
• the network environment 100 has a network 102 that connects S servers 104-1 through 104-S, and C clients 108-1 through 108-C.
• S servers 104-1 through 104-S and C clients 108-1 through 108-C are connected to each other via a network 102, which may be, for example, an on-chip communication network.
• the network 102 might be or include one or more of: inter-chip communications, an optical network, the Internet, a Local Area Network (LAN), Wide Area Network (WAN), satellite link, fiber network, cable network, or a combination of these and/or others.
• the servers may represent, for example: a master device on a chip; a memory; an intellectual property core, such as a microprocessor, communications interface, etc.; a disk storage system; and/or computing resources.
• the clients may have computing, storage, and viewing capabilities.
• the method and apparatus described herein may be applied to essentially any type of communicating means or device whether local or remote, such as a LAN, a WAN, a system bus, on-chip bus, etc.
• client and server is for clarity in specifying who initiates a communication (the client) and who responds (the server). No hierarchy is implied unless explicitly stated. Both functions may be in a single communicating device, in which case the client-server and server-client relationship may be viewed as peer-to- peer. Thus, if two devices such as 108-1 and 104-S can both initiate and respond to communications, their communication may be viewed as peer-to-peer. Likewise, communications between 104-1 and 104-S, and 108-1 and 108-C may be viewed as peer to peer if each such communicating device is capable of initiation and response to communication.
• FIG. 2 illustrates a system 200 in block diagram form, which may be representative of any of the clients and/or servers shown in Figure 1.
• the block diagram is a high level conceptual representation and may be implemented in a variety of ways and by various architectures.
• Bus system 202 interconnects a Central Processing Unit (CPU) 204, Read Only Memory (ROM) 206, Random Access Memory (RAM) 208, storage 210, display 220, audio, 222, keyboard 224, pointer 226, miscellaneous input/output (I/O) devices 228, and communications 230.
• CPU Central Processing Unit
• ROM Read Only Memory
• RAM Random Access Memory
• the bus system 202 may be for example, one or more of such buses as an on- chip bus, a system bus, Peripheral Component Interconnect (PCI), Advanced Graphics Port (AGP), Small Computer System Interface (SCSI), Institute of Electrical and Electronics Engineers (IEEE) standard number 1394 (FireWire), Universal Serial Bus (USB), etc.
• the CPU 204 may be a single, multiple, or even a distributed computing resource.
• Storage 210 may be Compact Disc (CD), Digital Versatile Disk (DVD), hard disks (HD), optical disks, tape, flash, memory sticks, video recorders, etc.
• Display 220 might be, for example, a Cathode Ray Tube (CRT), Liquid Crystal Display (LCD), a projection system, Television (TV), etc. Note that depending upon the actual implementation of the system, the system may include some, all, more, or a rearrangement of components in the block diagram.
• an on-chip communications system on an integrated circuit may lack a display 220, keyboard 224, and a pointer 226.
• a thin client might consist of a wireless hand held device that lacks, for example, a traditional keyboard.
• the present invention can be implemented by an apparatus for performing the operations herein.
• This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer, selectively activated or reconfigured by a computer program stored in the computer.
• a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, hard disks, optical disks, compact disk- read only memories (CD-ROMs), digital versatile disk (DVD), and magnetic-optical disks, readonly memories (ROMs), random access memories (RAMs), electrically programmable read-only memories (EPROM)s, electrically erasable programmable read-only memories (EEPROMs), FLASH memories, magnetic or optical cards, etc., or any type of media suitable for storing electronic instructions either local to the computer or remote to the computer.
• ROMs readonly memories
• RAMs random access memories
• EPROM electrically programmable read-only memories
• EEPROMs electrically erasable programmable read
• the methods of the invention may be implemented using computer software. If written in a programming language conforming to a recognized standard, sequences of instructions designed to implement the methods can be compiled for execution on a variety of hardware platforms and for interface to a variety of operating systems. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, application, driver,...), as taking an action or causing a result. Such expressions are merely a shorthand way of saying that execution of the software by a computer causes the processor of the computer to perform an action or produce a result.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Software Systems (AREA)
• Storage Device Security (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (3)

Family

ID=32176015

Family Applications (1)

Country Status (6)

Cited By (1)

Families Citing this family (46)

Citations (3)

Family Cites Families (45)

• 2002
  • 2002-11-05 US US10/288,973 patent/US7266786B2/en not_active Expired - Lifetime
• 2003
  • 2003-11-03 WO PCT/US2003/035022 patent/WO2004044681A2/en not_active Ceased
  • 2003-11-03 KR KR1020057007810A patent/KR100982145B1/ko not_active Expired - Fee Related
  • 2003-11-03 JP JP2004551691A patent/JP4768990B2/ja not_active Expired - Lifetime
  • 2003-11-03 EP EP03781736.8A patent/EP1561175B1/en not_active Expired - Lifetime
  • 2003-11-03 AU AU2003287494A patent/AU2003287494A1/en not_active Abandoned
• 2005
  • 2005-09-27 US US11/237,038 patent/US7793345B2/en active Active
• 2010
  • 2010-09-01 US US12/874,123 patent/US8443422B2/en not_active Expired - Fee Related

Patent Citations (3)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events