Showing papers on "Hardware register published in 1999"

System with control registers for managing computer legacy peripheral devices using an advanced configuration power interface software power management system

Abstract: A computer system permits the use of a software-based power management system, such as ACPI, while maintaining compatibility with legacy peripherals. The computer system utilizes a sleep register and a decoy register that receive sleep requests from the operating system. The sleep type bits transmitted to the sleep register are configured to allow the computer system to remain in fully operational mode, and only the decoy register receives the correct sleep type bits from a sleep request. When a sleep enable bit in the decoy register is set by a sleep request, an SMI is generated to run an interrupt service routine to perform any desired configuration routines prior to sleep mode. The interrupt service routine then writes the true sleep type bits to the sleep register, placing the computer system into sleep mode. The sleep enable bit resides in the highest byte of the decoy register so that byte-wide write operations do not trigger the SMI before the entire 16-bit sleep request is received.

Toward evolvable hardware chips: Experiments with a programmable transistor array

Abstract: Evolvable hardware is reconfigurable hardware that self-configures under the control of an evolutionary algorithm. The search for a hardware configuration can be performed using software models or, faster and more accurate, directly, in reconfigurable hardware. Several experiments have demonstrated the possibility to automatically synthesize both digital and analog circuits. The paper introduces an approach to automated synthesis of CMOS circuits, based on evolution on a programmable transistor array (PTA). The approach is illustrated with a software experiment showing evolutionary synthesis of a circuit with a desired DC characteristic. A hardware implementation of a test PTA chip is then described, and the same evolutionary experiment is performed on the chip demonstrating circuit synthesis/self-configuration directly in hardware.

Design of a flexible coprocessor unit

Abstract: Todays FPGA technology allows reconfigurable hardware to be integrated into standard PC hardware. A hardware like this allows for on-the-fly reconfigurable hardware. It is possible to remove and insert complete subsystems just by reinitializing the configurable components. These systems make new demands on software that often can't be fulfilled by the classical device driver concept used in todays operating systems. This paper presents a flexible and on-the-fly reconfigurable hardware subsystem for interworking systems. Furthermore, a software integration for fast and efficient reconfiguration of the hardware is introduced. It provides a flexible integration into a Unix environment.

State management in a co-verification system

Abstract: A method and apparatus for state management in a co-verification system is described. The invention allows acceleration of co-simulation without loss of information that can occur from independent simulation of software and hardware components of a design. For example, counters included in a hardware component that are influenced by software components are simulated and updated by the software simulator when simulation of hardware and software is not synchronized. When the counter or other hardware component that is maintained by software simulation causes a hardware event (e.g., an interrupt) to occur, co-simulation is resynchronized and the hardware component is updated. Improved acceleration of co-simulation is thereby provided.

C for system level design

Abstract: Few people disagree with the fact that today about 80% of a system is software running on a "platform" of general purpose or custom processors (CPU and/or DSP) tightly coupled with unique dedicated hardware. This makes C (or C++) an obvious candidate for a system level design language. Without good hardware/software partitioning tools and support for C-based hardware design, the software content may have to increase by necessity. With the right hardware support a system team has the flexibility to make cost, performance, power trade-offs and decide later in the game how much of the system is software and how much is hardware. Another issue is legacy software and hardware. Legacy C software is well understood but legacy hardware is usually only available as RTL (Verilog or VHDL) at best. Therefore the ideal system level design language is C (or C++) based, accommodates hardware design but also co-exists with the vast legacy of Verilog and VHDL based re-usable hardware. CoWare N2C is practical solution, used in real life design around the world, that a) preserves the C software development paradigm for software people, b) adds the necessary clocking to C to enable hardware designers to move C functionality into a hardware architecture, and c) co-exists C for co-design and co-simulation) with existing hardware in Verilog or VHDL.

Method and apparatus for compound hardware configuration control

Abstract: Hardware reconfiguration is accomplished through the use of low-level, self-terminating software processes that allows a high degree of parallelism in the reconfiguration operation, even in systems utilizing a mixture of recently developed hardware and software in combination with legacy components. In a system including a centralized processor resource and a plurality of interconnected hardware elements, a method is provided for performing hardware reconfiguration, the method comprising the steps of receiving a request for reconfiguration of one or more predetermined hardware elements, and, in response thereto, initiating at least one master terminal process to determine family relationships among the predetermined hardware elements and other hardware elements to which the predetermined hardware elements are connected. Based upon these family relationships, terminal slave processes are initiated to accomplish hardware element reconfiguration. Apparatus for performing hardware reconfiguration is also described.

Function unit allocation in processor design

Abstract: Methods and apparatus are described for selecting operation devices or hardware components for a processor, such as an embedded processor having pipelined data paths. The process may include identifying a set of hardware components, such as function units, and a plurality of characteristics for those hardware components. A first set of characteristics may include the ability to add, subtract, multiply, and the like, or they may be multi-functional. A second set of characteristics for the hardware components may include cost, throughput and the like. A plurality of these characteristics of the hardware components are incorporated into an algorithm, which is then solved for one or more desired parameters, such as type and number of hardware components. In one preferred embodiment, the least cost assembly of hardware components is found for carrying out a set of computations defined by an algorithm to be executed on the processor according to a preferred initiation interval.

Applying authentication data to hardware unit, e.g. chip card having private key by encrypting data using public key and transmitting to hardware unit

Abstract: Authentication data existing outside the hardware unit are encrypted using a public key outside the hardware unit, and then transmitted to the hardware unit. The private and the public key are generated within the hardware unit. The hardware unit may be a chip card. The authentication data may be personal identification numbers (PINs), or biometric data such as a fingerprint. A certificate may be transmitted with the authentication data. A transport key or a card-specific identification key may be used to secure the data.

Delft-Java dynamic translation

Abstract: This paper describes the DELFT-JAVA processor and the mechanisms required to dynamically translate JVM instructions into DELFT-JAVA instructions. Using a form of hardware register allocation, we transform stack bottlenecks into pipeline dependencies which are later removed using register renaming and interlock collapsing arithmetic units. When combined with superscalar techniques and multiple instruction issue, we remove up to 60% of translated dependencies. When compared with a realizable stack-based implementation, our approach accelerates a Vector Multiply execution by 3.2/spl times/ for out-of-order execution with register renaming and 2.7/spl times/ when hardware constraints were considered. In addition, for translated instruction streams, we realized a 50% performance improvement for out-of-order execution when compared with in-order execution.

Network interface for a data communication system

Abstract: A system architecture for a high speed serial bus compatible with the 1394 standard is disclosed. A transaction interface coordinates data packets received from or sent to a 1394 bus. A kemel/scheduler/dispatcher is used to allocate memory resources, and start a variety of tasks and services. The tasks and services vary depending on protocols used in a transport layer and application layer used in conjunction with the 1394 layers. Each task operates according to a state machine progression The transaction interface accepts data information from the tasks and forms data packets for delivery to the 1394 bus. The data packets are initially sent via an associated hardware register, but if busy, the transaction interface polls for other available registers. In addition, all queued transactions are loaded into registers in the most expedient manner.

Method and system for communication in a heterogeneous network

Abstract: An exemplary embodiment of the present invention is a system having a diverse hardware platform monitored and managed from a central control node in a distributed, parallel, heterogeneous computing environment. The central control node executes both a hardware monitor program and an intermediary program to monitor and manage diverse hardware in a distributed, parallel, heterogeneous computing environment. The intermediary program emulates network frame hardware by facilitating communication between the hardware monitor program and diverse node hardware. Another exemplazy embodiment of the present invention is a method for facilitating communication between a hardware monitor for monitoring and management of node hardware and for providing an interface for administrator interaction with the node hardware and diverse node hardware in a distributed, parallel, heterogeneous computing environment. The intermediary program receives requests from the hardware monitor for the diversenode hardware and sends responses to the hardware monitor from the diverse node hardware. The intermediary program decodes and encodes these responses and requests, respectively, using hardware monitor protocol and diverse node hardware protocol.

Method and system for low level testing of central electronics complex hardware using Test nano Kernel

Abstract: The method and system of the present invention provides for a test tool consisting of a Test nano Kernel and supported test programs (exercisers) which sequentially stage validity tests for central complex electronics hardware for architecture and hardware implementation for a single processor or in a multiprocessor system. Central electronics complex hardware is a processor, memory sub-system and system bridge coupled together and may include the input/output ports. Each stage becomes increasingly complex as the hardware platform becomes more stable. The Test nano Kernel consists of approximately 500 K of software code, provides multiprocessor support and implements context and 64-bit execution, effective equal to real and shared memory service, segment register attachment, gang scheduling and CPU affinity services. The Test nano Kernel provides for a smooth transition from simulation due to its capabilities to run simulation test cases on real hardware.

A hardware/software partitioning algorithm for processor cores of digital signal processing

Abstract: A hardware/software cosynthesis system for processor cores of digital signal processing has been developed. This paper focuses on a hardware/software partitioning algorithm which is one of the key issues in the system. Given an input assembly code generated by the compiler in the system, the proposed hardware/software partitioning algorithm first determines the types and the numbers of required hardware units, such as multiple functional units, hardware loop units, and particular addressing units, for a processor core (initial resource allocation). Second, the hardware units determined at initial resource allocation are reduced one by one while the assembly code meets a given timing constraint (configuration of a processor core). The execution time of the assembly code becomes longer but the hardware costs for a processor core to execute it becomes smaller. Finally, it outputs an optimized assembly code and a processor configuration. Experimental results demonstrate that the system synthesizes processor cores effectively according to the features of an application program/data.

Method and apparatus for generating a specific computer hardware component exception handler

Abstract: A method and apparatus for generating a specific computer hardware component exception handler and emulating memory accesses to such a hardware component include processing steps that begin by determining whether an address of a CPU instruction is within the address space of the computer hardware component. When the address is within the address space of the computer hardware component, the address and data size are saved in emulation registers. The processing then continues by entering a software exception handler to process the memory access requests directed to the computer hardware component based on the data size. The processing within the software exception handler begins by reading from a plurality of computer hardware component registers to obtain a register setting. The processing then continues by generating a specific computer hardware component function based on the register settings. The processing then continues by storing the specific computer hardware component function in cache memory. The process then continues by performing the specific computer hardware component function upon data to produce a specific emulated hardware component data. The performance of the specific computer hardware component function may be done by executing an instruction that identifies an address and data size.

Using software objects to communicate with hardware devices

Abstract: An interface to one or more hardware devices includes a configuration library and objects to model the hardware. Software programs using the interface need not understand how to communicate with the hardware. Instead, the software programs may communicate with the interface. In turn, the interface communicates with the hardware. The software may be written when the hardware implementation features are unknown.

Configurable hardware block

Abstract: The invention relates to a configurable hardware block which is designed to read data stored in a storage means according to its configuration, to process the read-out data arithmetically and/or logically and to write the data representing the result of the processing into the storage means. The hardware block described is characterized in that it is capable of interacting with external hardware, thereby providing a flexible and universally applicable hardware block.

Hardware/Software Co-Design of I/O Interfacing Hardware and Real-Time Device Drivers for Embedded Systems

Abstract: We have conceptualized a hardware-software co- design strategy for creating I/O interfacing hardware and real-time operating system device drivers for microcontrol- lers, enabling hardware independent access to I/O devices at near-zero overhead. We achieve this low overhead through the addition of a hardware mechanism to the microcontroller architecture that we call nanoprocessors. The architecture extensions are orthogonal to the underlying microarchitec- ture and can be implemented inexpensively, and are thus suit- able for use in low-cost microcontrollers. Our current research is to validate this concept through extensive testing on a simulated processor, and to measure the cost-effective- ness of the hardware architecture extensions over a wide range of design choices. 1. Overview We have conceptualized a hardware-softw are co-design strategy for creating I/O interfacing hardware and real-time operating system (RTOS) device drivers for microcontrollers, enabling hardware independent access to I/O devices at near- zero overhead. We achieve this low overhead through the addition of a hardware mechanism to the microcontroller architecture that we call nanoprocessors. The architecture extensions are orthogonal to the underlying microarchitecture and can be implemented inexpensively, and are thus suitable for use in low-cost microcontrollers. Our current research is to validate this concept through extensive testing on a simu- lated processor, and to measure the cost-effectiveness of the hardware architecture extensions over a wide range of design choices. In this paper, in Section 2, we first discuss the general objec- tive of our research into developing an RTOS that can support component-based software. In Section 3, we provide exam- ples of the high overhead incurred by some input/output (I/O) devices. In Section 4, we present one of the microarchitecture enhancements that we are designing especially for use by an RTOS. We describe how the hardware is used to reduce the overhead for I/O devices in Section 5. Finally, in Section 6, we summarize the current status of this work in progress. 2. Real-Time Operating Systems

Building custom processors with Handel-C

Abstract: Triggering and data acquisition for the ATLAS LHC experiment requires state of the art computer hardware. Amongst other things, specialised processors may be required. To build these economically we are looking at reconfigurable computing, and a high-level hardware description language: Handel-C. We had previously implemented a specialised network hardware application in AHDL-a hardware description at the level of gates, flip-flops and state machines. As a feasibility study, we have rewritten the application in Handel-C -a language similar to C, except that it can be translated into hardware. There were problems to solve: high data throughput with complex pipelines; timing constraints; I/O interfaces to external devices; difficulties with the Altera devices. We gained valuable experience, wrote useful support tools, and discovered clean new ways to make the most of the language in the high-speed domain.

Low-cost radio frequency (RF) link for point-to-point data transfer

Abstract: An apparatus for data transfer using radio frequency (RF) energy, includes a first software application that sources and links the data transfer, a second software application for controlling a communications hardware for the data transfer, a hardware device for formatting the data and gaining access to a media, and a physical layer interface hardware, coupled to selectively receive a signal representing the data from the hardware device and to provide an output to the hardware device, for sending and receiving a radio frequency communication. The second software application for controlling the communications hardware uses a target data transmission media of infrared light.

Method and system to dynamically decide address used for unique identification of hardware components on common bus

Abstract: PROBLEM TO BE SOLVED: To provide a technology for automatically deciding system configuration information and assigning an address on a common bus. SOLUTION: Each cell station 100 includes a plurality of hardware components and a hardware controller 110, communicated on a common bus 115. An address space is logically divided into two ranges, that is, a 1st address range called a 'common access address' and a 2nd address range called an 'assignment address'. One address is reserved for a primary node to assign addresses, such as the hardware controller. Thus, each hardware component makes communication with the hardware controller having any of common access addresses to request a channel. When each hardware component receives an address assigned by the hardware controller, each hardware component makes communication, by using the assigned address after that. Collision which occurred among a plurality of the hardware components on the common access channels can be minimized through the assignment of a plurality of channels.