DOCSLIB.ORG

Predictable Scheduling for a Soft Modem

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Predictable Scheduling for a Soft Modem Predictable Scheduling for a Soft Modem Michael B. Jones and Stefan Saroiu December 2000 Technical Report MSR-TR-2000-88 Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 Predictable Scheduling for a Soft Modem Michael B. Jones Stefan Saroiu Microsoft Research, Microsoft Corporation Department of Computer Science & Engineering One Microsoft Way University of Washington Redmond, WA 98052 Seattle, WA 98195-2350 USA USA [email protected] [email protected] http://research.microsoft.com/~mbj/ http://www.cs.washington.edu/homes/tzoompy/ Abstract • INT – the signal processing routines are executed in Soft Modems use the main processor to execute mo- an interrupt handler (a.k.a. in interrupt context). This dem functions traditionally performed by hardware on the is the original version. modem card. To function correctly, soft modems require • DPC – the signal processing routines are executed in that ongoing signal processing computations be performed the context of a Deferred Procedure Call (DPC) on the host CPU in a timely manner. Thus, signal proc- [Solomon & Russinovich 00, pages 107-111]. essing is a commonly occurring background real-time • THR – the signal processing routines are executed in application—one running on systems that were not de- the context of a kernel thread scheduled using the signed to support predictable real-time execution. This standard priority-based Windows 2000 scheduler. paper presents a detailed study of the performance char- • RES – the signal processing routines are executed in acteristics and resource requirements of a popular soft the context of a kernel thread scheduled using a Ri- modem. Understanding these requirements should inform alto/NT CPU Reservation [Jones & Regehr 99b]. the efforts of those designing and building operating sys- tems needing to support soft modems. Furthermore, we We captured performance profiles of each of the four believe that the conclusions of this study also apply to versions of the driver and compared and contrasted the other existing and upcoming soft devices, such as soft modem performance. We report on the benefits and the Digital Subscriber Line (DSL) cards. We conclude that (1) problems encountered with each of the driver versions signal processing in an interrupt handler is not only un- analyzed. One of the goals of this study is to make the necessary but also detrimental to the predictability of other detailed performance characteristics of a popular soft mo- computations in the system and (2) a real-time scheduler dem available to the industry, allowing this data to inform can provide predictability for the soft modem while mini- their work on providing predictable execution on con- mizing its impact on other computations in the system. sumer and general-purpose operating systems. While the soft modem’s 14.7% CPU load is not high 1. Introduction per se, a problem with the vendor version is that all of this Soft modems use the main processor to execute mo- time is spent in interrupt context. Once connected, the dem functions traditionally performed by the digital signal execution of the interrupt handler typically lasts 1.8ms processor (DSP) on the modem card. Soft modems have with a repeatable worst case of 3.3ms during connection. enjoyed large success in the home computer market. Two This study shows that signal processing in interrupt reasons for their success are low cost and the flexibility of context is not only unnecessary but also detrimental to the migrating to newer technologies by simple software up- predictability of other computations in the system. While grade. Given recent advances in CPU processing power, DPCs and priority-based scheduling cause milder side the impact of a soft modem on the throughput of the sys- effects upon the rest of the system, they nevertheless suf- tem is reasonable—we measured a 14.7% sustained CPU fer from some of the same drawbacks as the original ver- load on a 450 MHz Pentium II. Because soft modems need sion. This study supports the conclusion that certain kinds periodic real-time computations on the host CPU in order of real-time scheduling abstractions provide a good an- to maintain line connection and transmit data, a mecha- swer to the observed predictability problems that can be nism ensuring predictable scheduling is essential. caused by the soft modem. This paper presents a detailed study of the perform- Indeed, their real-time requirements and omnipres- ance characteristics and resource requirements of a popu- 1 ence make the soft modems an excellent environment for lar soft modem . We analyzed the vendor-supplied version testing the feasibility and the practicality of soft real-time of the driver and three additional versions that we created. scheduling for commodity operating systems. One section The four versions of the soft modem driver are: of our results is dedicated specifically to studying the ef- fectiveness of using a particular set of real-time schedul- ing abstractions for supporting the predictability require- ments of the soft modem. This paper demonstrates a con- crete set of benefits when real-time scheduling is applied 1 Our agreement with the manufacturer prevents us from to the computations employed by a soft modem. identifying this soft modem. Finally, we believe many of the lessons learned from Modems can be classified into hardware-based mo- studying soft modems are applicable to a wider class of dems (traditional modems) or software-based modems, problems. Other soft devices are already in use, with more depending on where each of these functions are executed. coming soon. For instance, software-based Digital Sub- 2.1.1 Hardware-based Modems scriber Line (Soft DSL) [Tramontano 00] devices have Traditional modems implement all the modem func- been announced. As will be detailed, Soft DSL has similar tionality in hardware on the modem card. Dedicated chips execution period requirements, but significantly larger provide signal modulation and interpret the AT command overall CPU requirements than soft modems. set. The card also provides A/D and D/A converters. On The remainder of this paper is structured as follows: older modems, the Universal Asynchronous Re- Section 2 provides background on soft modems and oper- ceiver/Transmitter (UART) chip implements the asyn- ating systems support for predictable execution. Section 3 chronous interface between the modem and the computer. describes the hardware and software tools used for our Today, the PCI bus interface often provides this function- study. Section 4 details how the soft modem used in these ality, replacing the UART chip. experiments operates. Section 5 discusses the four soft 2.1.2 Software-based Modems modem driver versions used in this study. Section 6 con- tains our results. A roadmap of the results can be found at Software-based analog modems use the host proces- the beginning of Section 6. Section 7 tells one of the “war sor to perform some of the modem functions traditionally stories” from our investigation. Section 8 discusses possi- performed on the modem card. Two types of software- bilities for further related research. Section 9 relates some based modems have emerged [Dell 99]: industry perspectives on the findings of the study. And 1. Controllerless modems (alsoknownaswinmodems or Section 10 presents our conclusions. Then, following the linmodems), which perform and interpret the standard Acknowledgements and References, Appendix A presents attention (AT) commands on the main processor. Sig- some supplemental results. nal modulation, A/D, and D/A are implemented by hardware on the modem card. 2. Background 2. Soft modems, which perform signal processing (as 2.1 Modem Taxonomy well as AT commands) on the host CPU, unlike both A modem is a peripheral device that enables comput- regular and controllerless modems. Modem data buff- ers to communicate with each other over conventional ers may reside in host memory. Soft modems still have phone lines. The term modem stands for Modula- hardware-based A/D and D/A converters. tor/Demodulator. The purpose of a modem is to convert Today, the software-based analog modems are very (modulate) the digital signal that a computer understands common on the new computer systems, both for worksta- into an analog signal that can be carried over a phone line, tions and especially for laptops. Some of the reasons for and to re-convert (demodulate) the analog into a digital their success are low cost, low power consumption, and signal at the other end [Anderson et al. 96]. Demodulation maximum upgrade flexibility. Drawbacks are high CPU consists of digitizing analog waveforms using an A-to-D and memory usage. The scant availability of drivers for converter followed by the application of signal processing operating systems other than Windows has also contrib- algorithms. Modulation consists of a different set of signal uted to their limited use on non-Windows platforms. processing algorithms to produce a digitized waveform, 2.2 Commodity Operating Systems and Real- whichissentthroughaD-to-A converter. Time Applications Traditional modem communication standards assume General-purpose operating systems such as Windows that both ends of a data connection are linked to the public 2000, Linux, and Solaris are increasingly being used to switched telephony network (PSTN) by analog lines. This run time-dependent tasks such as audio and video proc- limits the communication bandwidth to 33.6Kbps in each essing despite good arguments against doing so [Nieh et direction [3Com 98]. By assuming that one of the end- al. 93]. This is the case even though many such systems, points is connected digitally to the PSTN (like most Inter- and Windows 2000 in particular, were designed primarily net Service Providers are), modern modems are able to to maximize aggregate throughput and to achieve ap- achieve speeds of up to 56Kbps downstream and proximately fair sharing of resources, rather than to pro- 33.6Kbps upstream using the V.90 protocol [ITU 98].
Load more

Recommended publications
  • A Programmable Microkernel for Real-Time Systems∗
    A Programmable Microkernel for Real-Time Systems∗ Christoph M. Kirsch Marco A.A. Sanvido Thomas A. Henzinger University of Salzburg VMWare Inc. EPFL and UC Berkeley [email protected] tah@epfl.ch ABSTRACT Categories and Subject Descriptors We present a new software system architecture for the im- D.4.7 [Operating Systems]: Organization and Design— plementation of hard real-time applications. The core of the Real-time systems and embedded systems system is a microkernel whose reactivity (interrupt handling as in synchronous reactive programs) and proactivity (task General Terms scheduling as in traditional RTOSs) are fully programma- Languages ble. The microkernel, which we implemented on a Strong- ARM processor, consists of two interacting domain-specific Keywords virtual machines, a reactive E (Embedded) machine and a proactive S (Scheduling) machine. The microkernel code (or Real Time, Operating System, Virtual Machine microcode) that runs on the microkernel is partitioned into E and S code. E code manages the interaction of the system 1. INTRODUCTION with the physical environment: the execution of E code is In [9], we advocated the E (Embedded) machine as a triggered by environment interrupts, which signal external portable target for compiling hard real-time code, and in- events such as the arrival of a message or sensor value, and it troduced, in [11], the S (Scheduling) machine as a universal releases application tasks to the S machine. S code manages target for generating schedules according to arbitrary and the interaction of the system with the processor: the exe- possibly non-trivial strategies such as nonpreemptive and cution of S code is triggered by hardware interrupts, which multiprocessor scheduling.
    [Show full text]
  • Super 7™ Motherboard
    SY-5EH5/5EHM V1.0 Super 7Ô Motherboard ************************************************ Pentium® Class CPU supported ETEQ82C663 PCI/AGP Motherboard AT Form Factor ************************************************ User's Guide & Technical Reference NSTL “Year 2000 Test” Certification Letter September 23, 1998 Testing Date: September 23, 1998 Certification Date: September 23, 1998 Certification Number: NCY2000-980923-004 To Whom It May Concern: We are please to inform you that the “SY-5EHM/5EH5” system has passed NSTL Year 2000 certification test program. The Year 2000 test program tests a personal computer for its ability to support the year 2000. The “SY-5EHM/5EH5: system is eligible to carry the NSTL :Year 2000 Certification” seal. The Year 2000 certification test has been done under the following system configuration: Company Name : SOYO COMPUTER INC. System Model Name : SY-5EHM/5EH5 Hardware Revision : N/A CPU Model : Intel Pentium 200/66Mhz On Board Memory/L2 Cache : PC100 SDRAM DIMM 32MBx1 /1MB System BIOS : Award Modular BIOS V4.51PG, An Energy Star Ally Copyright © 1984—98, EH-1A6,07/15/1998-VP3-586B- 8669-2A5LES2AC-00 Best regards, SPORTON INTERNATIONAL INC. Declaration of Conformity According to 47 CFR, Part 2 and 15 of the FCC Rules Declaration No.: D872907 July.10 1998 The following designated product EQUIPMENT: Main Board MODEL NO.: SY-5EH Which is the Class B digital device complies with 47 CFR Parts 2 and 15 of the FCC rules. Operation is subject to the following two conditions : (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.
    [Show full text]
  • Interrupt Handling in Linux
    Department Informatik Technical Reports / ISSN 2191-5008 Valentin Rothberg Interrupt Handling in Linux Technical Report CS-2015-07 November 2015 Please cite as: Valentin Rothberg, “Interrupt Handling in Linux,” Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg,¨ Dept. of Computer Science, Technical Reports, CS-2015-07, November 2015. Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg¨ Department Informatik Martensstr. 3 · 91058 Erlangen · Germany www.cs.fau.de Interrupt Handling in Linux Valentin Rothberg Distributed Systems and Operating Systems Dept. of Computer Science, University of Erlangen, Germany [email protected] November 8, 2015 An interrupt is an event that alters the sequence of instructions executed by a processor and requires immediate attention. When the processor receives an interrupt signal, it may temporarily switch control to an inter- rupt service routine (ISR) and the suspended process (i.e., the previously running program) will be resumed as soon as the interrupt is being served. The generic term interrupt is oftentimes used synonymously for two terms, interrupts and exceptions [2]. An exception is a synchronous event that occurs when the processor detects an error condition while executing an instruction. Such an error condition may be a devision by zero, a page fault, a protection violation, etc. An interrupt, on the other hand, is an asynchronous event that occurs at random times during execution of a pro- gram in response to a signal from hardware. A proper and timely handling of interrupts is critical to the performance, but also to the security of a computer system. In general, interrupts can be emitted by hardware as well as by software. Software interrupts (e.g., via the INT n instruction of the x86 instruction set architecture (ISA) [5]) are means to change the execution context of a program to a more privileged interrupt context in order to enter the kernel and, in contrast to hardware interrupts, occur synchronously to the currently running program.
    [Show full text]
  • Pentium 82430VX / P54C PCI Mainboard User’S Guide & Technical Reference 5V A0/A2/A5 Ii ¨ ª
    Pentium 82430VX / P54C PCI Mainboard User’s Guide & Technical Reference 5V A0/A2/A5 ii ® ™ About This Guide This UserÕs Guide is for assisting system manufacturers and end users in setting up and installing the mainboard. Information in this guide has been carefully checked for reliability; however, no guarantee is given as to the correctness of the contents. The information in this document is subject to change without notice. Copyright Notice Copyright 1997, Soyo Computer Inc. All rights reserved. This manual is copyrighted by Soyo Computer Inc. You may not reproduce, transmit, transcribe, store in a retrieval system, or translate into any language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, any part of this publication without express written permission of Soyo Computer Inc. Trademarks Soyo is a registered trademark of Soyo Computer Inc. All trademarks are the property of their owners. Disclaimer Soyo Computer Inc. makes no representations or warranties regarding the contents of this manual. We reserve the right to revise the manual or make changes in the specifications of the product described within it at any time without notice and without obligation to notify any person of such revision or change. The information contained in this manual is provided for general use by our customers. Our customers should be aware that the personal computer field is the subject of many patents. Our customers should ensure that they take appropriate action so that their use of our products does not infringe upon any patents. It is the policy of Soyo Computer Inc.
    [Show full text]
  • Additional Functions in HW-RTOS Offering the Low Interrupt Latency
    HW-RTOS Real Time OS in Hardware Additional Functions in HW-RTOS Offering the Low Interrupt Latency In this white paper, we introduce two HW-RTOS functions that offer the lowest interrupt latency available and help create a more software-friendly environment. One of these is ISR implemented in hardware, which improves responsiveness when activating a task from an interrupt and eliminates the need for developing a handler in software. The other is a function allowing the use of non-OS managed interrupt handlers in a multitasking environment. This makes it easier to migrate from a non-RTOS environment to a multitasking one. R70WP0003EJ0100 September, 2018 2 / 8 Multitasking Environment with Lowest Interrupt Latency Offered by HW-RTOS 1. Executive Summary In this white paper, we introduce two functions special to HW-RTOS that improve interrupt performance. The first is the HW ISR function. Renesas stylized the ISR (Interrupt Service Routine) process and implemented it in hardware to create their HW ISR. With this function, the task corresponding to the interrupt signal can be activated directly and in real time. And, since the ISR is implemented in the hardware, application software engineers are relieved of the burden of developing a handler. The second is called Direct Interrupt Service. This function is equivalent to allowing a non-OS managed interrupt handler to invoke an API. This function %" "$# $""%!$ $ $""%!$!" enables synchronization and communication "$ "$ between the non-OS managed interrupt handler and $($ $($ '$ '$ tasks, a benefit not available in conventional $ $ software. In other words, it allows the use of non-OS # $ % " "$) ) managed interrupt handlers in a multitasking $($ '$ environment.
    [Show full text]
  • Communication Theory II
    Microprocessor (COM 9323) Lecture 2: Review on Intel Family Ahmed Elnakib, PhD Assistant Professor, Mansoura University, Egypt Feb 17th, 2016 1 Text Book/References Textbook: 1. The Intel Microprocessors, Architecture, Programming and Interfacing, 8th edition, Barry B. Brey, Prentice Hall, 2009 2. Assembly Language for x86 processors, 6th edition, K. R. Irvine, Prentice Hall, 2011 References: 1. Computer Architecture: A Quantitative Approach, 5th edition, J. Hennessy, D. Patterson, Elsevier, 2012. 2. The 80x86 Family, Design, Programming and Interfacing, 3rd edition, Prentice Hall, 2002 3. The 80x86 IBM PC and Compatible Computers, Assembly Language, Design, and Interfacing, 4th edition, M.A. Mazidi and J.G. Mazidi, Prentice Hall, 2003 2 Lecture Objectives 1. Provide an overview of the various 80X86 and Pentium family members 2. Define the contents of the memory system in the personal computer 3. Convert between binary, decimal, and hexadecimal numbers 4. Differentiate and represent numeric and alphabetic information as integers, floating-point, BCD, and ASCII data 5. Understand basic computer terminology (bit, byte, data, real memory system, protected mode memory system, Windows, DOS, I/O) 3 Brief History of the Computers o1946 The first generation of Computer ENIAC (Electrical and Numerical Integrator and Calculator) was started to be used based on the vacuum tube technology, University of Pennsylvania o1970s entire CPU was put in a single chip. (1971 the first microprocessor of Intel 4004 (4-bit data bus and 2300 transistors and 45 instructions) 4 Brief History of the Computers (cont’d) oLate 1970s Intel 8080/85 appeared with 8-bit data bus and 16-bit address bus and used from traffic light controllers to homemade computers (8085: 246 instruction set, RISC*) o1981 First PC was introduced by IBM with Intel 8088 (CISC**: over 20,000 instructions) microprocessor oMotorola emerged with 6800.
    [Show full text]
  • Intel Prepares MMX CPU Wave After Weak 1996, AMD and Cyrix Ready 1997 Counterstrike
    MICRODESIGN R ESOURCES SPECIAL REPORT Intel Prepares MMX CPU Wave After Weak 1996, AMD and Cyrix Ready 1997 Counterstrike by Michael Slater Nineteen ninety six was a remarkably successful one for Intel and a difficult one for its competitors. It was a quiet year for Intel in terms of new products, but the company nevertheless increased both its market share and its gross margin—thanks, in large part, to weak performances from AMD and Cyrix. (See list on page 14 for a summary of the key events of 1996 and pointers to Microprocessor Report’s coverage.) This year promises to be far more turbulent. Not only is Intel intro- ducing two major new product lines—P55C (officially, Pentium Processor with MMX Technology) and Klamath—but AMD and Cyrix will each launch their own next-generation processors, which will be more formi- dable competitors to Intel’s line. Intel is sure to do well despite the stepped-up challenge, but its dominance of the market is unlikely to be quite as complete in 1997 as in 1996. Intel Shifting into In 1996, Intel’s microprocessor lineup changed little. After the introduction High Gear of the 150- and 166-MHz Pentiums in January, the only new products were the 200-MHz Pentium and 150-MHz Mobile Pentium. The P55C would have been a great kicker for fall sales, but Intel apparently didn’t have the part ready in time. Intel began producing P55C processors in the late fall but chose not to announce the part until January in order to minimize the impact on the Christmas selling season.
    [Show full text]
  • Interrupt Handling
    ,ch10.10847 Page 258 Friday, January 21, 2005 10:54 AM CHAPTER 10 Chapter 10 Interrupt Handling Although some devices can be controlled using nothing but their I/O regions, most real devices are a bit more complicated than that. Devices have to deal with the external world, which often includes things such as spinning disks, moving tape, wires to distant places, and so on. Much has to be done in a time frame that is differ- ent from, and far slower than, that of the processor. Since it is almost always undesir- able to have the processor wait on external events, there must be a way for a device to let the processor know when something has happened. That way, of course, is interrupts. An interrupt is simply a signal that the hardware can send when it wants the processor’s attention. Linux handles interrupts in much the same way that it handles signals in user space. For the most part, a driver need only register a handler for its device’s interrupts, and handle them properly when they arrive. Of course, underneath that simple picture there is some complexity; in particular, interrupt handlers are somewhat limited in the actions they can perform as a result of how they are run. It is difficult to demonstrate the use of interrupts without a real hardware device to generate them. Thus, the sample code used in this chapter works with the parallel port. Such ports are starting to become scarce on modern hardware, but, with luck, most people are still able to get their hands on a system with an available port.
    [Show full text]
  • IDT Winchip 2A Data Sheet
    Preliminary Information PROCESSOR Version A Data Sheet Preliminary Information January 1999 IDT WINCHIP 2ATM PROCESSOR DATA SHEET This is Version 1.0 of the IDT WinChip 2 version A Processor data sheet. The latest versions of this data sheet may be obtained from www.winchip.com © 1999 Integrated Device Technology, Inc. All Rights Reserved Integrated Device Technology, Inc. (IDT) reserves the right to make changes in its products without notice in order to improve design or performance characteristics. This publication neither states nor implies any representations or warranties of any kind, including but not limited to any implied warranty of merchantability or fitness for a particular purpose. No license, express or implied, to any intellectual property rights is granted by this document. IDT makes no representations or warranties with respect to the accuracy or completeness of the contents of this publication or the information contained herein, and reserves the right to make changes at any time, without notice. IDT disclaims responsibility for any consequences resulting from the use of the information included herein. LIFE SUPPORT POLICY Integrated Device Technology's products are not authorized for use as components in life support or other medical devices or systems (hereinafter life support devices) unless a specific written agreement pertaining to such intended use is executed between the manufacturer and an officer of IDT. 1. Life support devices are devices which (a) are intended for surgical implant into the body or (b) support or sustain life and whose failure to perform, when properly used in accordance with instructions for use provided in the labeling, can be reasonably expected to result in a significant injury to the user.
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Interrupt Handling with KSDK and Kinetis Design Studio
    Freescale Semiconductor Interrupt handling with KSDK and Kinetis Design Studio By: Jorge Gonzalez / Technical Information Center Freescale Semiconductor About this document The Kinetis Software Development Kit (KSDK) is intended for rapid evaluation and development with Kinetis family MCUs. Besides of the peripheral drivers, the hardware abstraction layer and middleware stacks, the platform provides a robust interrupt handling mechanism. This document explains the implementation and handling of interrupts when using KSDK in baremetal mode and when using MQX RTOS. Kinetis Design Studio IDE was used as reference, but the concepts should apply for any particular IDE supported by KSDK. Software versions The contents of this document are valid for the latest versions of Kinetis SDK and Kinetis Design Studio by the time of writing, listed below: . KSDK v1.2.0 . KDS v3.0.0 Content 1. GLOSSARY 2. CONCEPTS AND OVERVIEW 2.1 Interrupt Manager 2.2 Vector table location 2.3 Interrupt priorities 3. KSDK INTERRUPT HANDLING 3.1 Baremetal interrupt handling 3.2 MQX RTOS interrupt handling 3.3 Operating System Abstraction layer (OSA) 4. KDS AND PROCESSOR EXPERT CONSIDERATIONS 4.1 KSDK baremetal 4.2 KSDK baremetal + Processor Expert 4.3 MQX for KSDK 4.4 MQX for KSDK + Processor Expert 5. REFERENCES Interrupt handling with KSDK and Kinetis Design Studio 2 Freescale Semiconductor Freescale Semiconductor 1. GLOSSARY KSDK Kinetis Software Development Kit: Set of peripheral drivers, stacks and middleware layers for Kinetis microcontrollers. KDS Kinetis Design Studio: Integrated Development Environment (IDE) software for Kinetis MCUs. API Application Programming Interface: Refers to the set of functions, methods and macros provided by the different layers of the KSDK platform.
    [Show full text]
  • Brainiacs, Speed Demons, and Farewell; 12/29/1999 Page 1 of 2
    Brainiacs, Speed Demons, and Farewell; 12/29/1999 Page 1 of 2 Client Login Search MDR Home Vol 13, Issue 17 December 27, 1999 Brainiacs, Speed Demons, and Farewell Some Vendors Learn Later Than Others That Clock Speed Drives Performance As my final editorial for this august publication, I would like to reflect on how the industry has changed--and in some ways stayed the same--since one of my earliest editorials, discussing Brainiacs and Speed Demons (see MPR 3/8/93, p. 3). At that time, Digital's brand-new Alpha line, HP's PA-RISC, and the MIPS R4000 strove for high clock speeds, while IBM (Power), Sun (SuperSparc), and Motorola (88110) focused on high-IPC (instruction per cycle) designs. In 1993, Speed Demons used simple scalar or two-issue designs running at 100 to 200 MHz in state-of-the-art 0.8-micron IC processes; Brainiacs could issue three or four instructions per cycle but at no more than 66 MHz. In the subsequent seven years, better IC processes have greatly improved both the IPC and the cycle time of microprocessors, leading some vendors to claim to deliver the best of both worlds. But a chip becomes a Speed Demon through microarchitecture design philosophy, not IC process gains. The Speed Demon philosophy is best summed up by an Alpha designer who said that a processor's cycle time should be the minimum required to cycle an ALU and pass the result to the next instruction. The processor can implement any amount of complexity so long as it doesn't compromise this primary goal of ultimate speed.
    [Show full text]