Data processing: structural design – modeling – simulation – and em – Simulating electronic device or electrical system – Computer or peripheral device
Reexamination Certificate
2000-02-17
2004-07-13
Ingberg, Todd (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Simulating electronic device or electrical system
Computer or peripheral device
C703S023000, C703S020000, C703S022000, C703S027000, C717S107000, C717S138000, C717S151000, C717S163000, C709S241000, C709S241000, C709S241000, C709S241000, C709S241000, C709S241000, C716S030000, C716S030000, C716S030000, C716S030000
Reexamination Certificate
active
06763327
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is directed to operating systems and real-time operating systems as well as systems and techniques for developing the same, and in particular it is directed to operating systems and real-time operating systems for processors that have easily configurable features.
2. Background of the Related Art
Operating systems (OSes) and real-time operating systems (RTOSes) provide basic software services required by a variety of software applications. An OS or an RTOS brings together in one package the basic services that are common to many applications. By doing so, the OS or the RTOS keeps the application developer from duplicating those basic services within each application. For reasons described in greater detail below, the following discussion will focus on RTOSes; however, it should be kept in mind that the information disclosed herein is also applicable to OSes.
Most of the basic features supplied by an RTOS are not specific to features supplied by a particular processor. Only a small fraction of the services that an RTOS supplies are specific to a particular processor. For example, an operating system often manages basic input and output operations. Traditional POSIX-style I/O interfaces require many things that are not processor-specific. At the same time, however, I/O usually requires interaction with processor-specific features like interrupts. Consequently, operating systems in general group such processor-specific features into a unit and define an interface to that unit. Different operating systems use different names for this interface: the VxWorks® RTOS from Wind River Systems, Incorporated of Alameda, Calif. calls this layer the architecture layer; Windows NT® calls it the HAL; and the Nucleus RTOS from Advanced Technology, Incorporated of Mobile, Ala. has no specific name for the interface, but simply provides an implementation in a small set of files which are referenced in their portability documentation.
In all cases, this set of services (called herein the abstraction layer) is designed as a convenience to the operating system's higher-level features. Consequently, this abstraction layer varies from one RTOS to another, and the functionality it provides is specific to the operating system even though part of the implementation is specific to a processor.
As a result, the implementation of this abstraction layer becomes a combination of processor-specific coding and operating system coding. If either the processor or the operating system changes, the implementation of the abstraction layer needs to be modified. Such a manual reimplementation of operating system services when the processor is modified becomes especially problematic in the case of a configurable processor.
The problem of different members of traditional processor families offers a limited parallel to the problems of a configurable processor. Operating systems have, to date, dealt with these problems using several different methodologies applied to the architecture layer of the operating system.
The first of these methodologies is source code preprocessor directives that allow the user to include code for all of the processors in a single module. In this case, modules in the architecture layer are instrumented with preprocessor directives. Which processor is being supported is selected at compile time by the build system. The other code, though included in the source code, is not in the object code.
There are difficulties with this method. Code that is not being compiled is not being tested for correctness. Since the interface to sections of code switched with the preprocessor directives is ill-defined, this is a source of common code breakage. Building the architecture layer for a particular configuration requires that all of the source code in the module be rebuilt, even though much of it may be processor-independent. Readability of the source code is often more difficult because of the additional complexity that the preprocessor directives introduce. Maintenance of the source code is made more difficult for the same reason.
The second of these methodologies is run-time determination of processor features. Consider several members of a processor family that differ from one another only by the size of the instruction cache. A set of code can be written that at run time determines the cache size.
There are difficulties with this method as well. Not all features can be successfully run-time detected. So, while presence of cache is available for detection, generation of certain interrupts may not be detectable. Determining processor configuration at run time can be less efficient as well in that more time is taken to determine the configuration. Also note that in the cases where family members extend the ISA using the same register indices and/or opcodes, it is even more likely that runtime detection will not be possible. This case is quite common for an extensible processor where different uses are extending the ISA at the same time.
The last of these methodologies is the creation of a separate source file for each member of the CPU family. This is a different expression of the first methodology.
The problems here related to the content of this source file. Because architecture layers are OS-centric rather than processor-centric, the content of these files has large content that is not processor-specific. When this content needs to change, the change must be propagated across all of the files. Since each CPU family member has its own file, again a maintenance problem is created.
OSes and RTOSes make use of the abstraction layer in different ways; for example, certain issues which make the abstraction layer appropriate for use with an RTOS are not present in the OS environment. On the other hand, many RTOS do not use ancillary devices such as MMU translators which can be abstracted by the abstraction layer for an OS.
A configurable processor is a processor that acquires different characteristics based on a user specification. In this case, the set of processor features that must be handled by the abstraction layer is not static and must adapt to different processor configurations. Today processors have been introduced in families with each member of the family containing a different set of features from the other members of the family; however, the number of processors in any given family has been relatively small—especially when compared to the number of different processors that can be produced by a configurable processor generator.
Note, however, that not all processor configurations are substantially different from the operating system perspective. Changes to some configuration parameters are transparent to the operating system because these changes do not affect the processor at a software functional level and, thus, the operating system is not affected. For example, processor configuration include information about the technology that is to be used to create the processor. This configuration substantially affects the generation of the processor, but does not affect the software that runs on the processor. In the following discussion it is assumed that the phrase “different configuration” implies a configuration on which an OS or RTOS produced for another configuration will not work properly due to the differences between the two configurations.
As mentioned previously, this abstraction layer consists of two separate conceptual components. The first component includes operating system-specific logic and functionality whereas the second component includes processor-specific logic and functionality. In existing solutions, these two components are meshed together. Such an implementation introduces significant problems when the abstraction layer must be reimplemented due to changes to the processor feature set. Because of the close interaction between the operating system and the processor functionality, the reimplementation can produce problems in either area of the abstraction layer.
Moreover, changes to the operating sys
Chea Kevin C.
Gauthier Marc E.
Konas Pavlos
Songer Christopher Mark
Ingberg Todd
Pillsbury & Winthrop LLP
Tensilica, Inc.
Thomson W. D.
LandOfFree
Abstraction of configurable processor functionality for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Abstraction of configurable processor functionality for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Abstraction of configurable processor functionality for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3244119