2007년 5월 31일 목요일

컴퓨터공부/Embedded에 해당되는 글 30건 (http://achiven.tistory.com/category/컴퓨터공부/Embedded)

열정을 희망으로, 희망을 현실로.. ::
 
컴퓨터공부/Embedded에 해당되는 글 30건
 
2007/05/16 :: arm-linux-??
2007/05/16 :: Makefile 만들기
2007/03/11 :: I2c란
2006/11/23 :: Rockbox에 대하여
2006/11/22 :: Mass Storage
2006/11/22 :: FTL정보
2006/11/19 :: Linux on ipod (1)
 
The end...

--
  Best Regards...


- Inner Secret Devices -

Chang-woo YANG

Homepage: http://www.PLDWorld.com
E-mail: podongii@PLDWorld.com

 

Add this card to your address book

2007년 5월 17일 목요일

PCI Express - 버추얼 인스트루먼트의 세계를 확장하십시오.

URL: http://www.ni.com/pciexpress/ko/

Introduction to PCI Express Training Slides

This presentation delivers an overview of the new PCI Express bus technology. The presentation offers a techincal overview of the evolution of PC buses , the benefits of PCI Express, and the physical and software layers of PCI Express.

Download the Presentation Files

PCI Express – An Overview of the PCI Express Standard- Developer Zone - National Instruments

URL: http://zone.ni.com/devzone/cda/tut/p/id/3767

Overview

This paper looks at the success of the widely adopted PCI bus and describes a higher-performance next generation of I/O interconnect technology – PCI Express – that will serve as a standard local I/O bus for a wide variety of future computing platforms. The paper also offers a technical overview of the evolution of PC buses, the physical and software layers of PCI Express, the benefits of PCI Express, and the implications this exciting new technology will have on measurement and automation systems.

Table of Contents

  1. Summary
  2. PC History
  3. PCI Bus History and Overview
  4. PCI Challenges
  5. PCI Express Architecture
  6. PC Architecture – Today and Future
  7. PCI Express Packaging
  8. Benefits of PCI Express
  9. Glossary
  10. Further Reading

About This Site (Ask the CSS Guy)

URL: http://www.askthecssguy.com/2006/10/about_this_site.html

Welcome. After spending a few years learning and implementing CSS, friends started asking me questions on how to accomplish certain layouts using CSS. I thought maybe there was a market for a site like this, so I started it. (Yeah, it uses the default movable type template - a real design is in the works.) UPDATE: (11-25-2006) Default Movable Type template is no more!

I realize that a name like "Ask the CSS guy" is a bit pretentious, but saying "Ask A CSS Guy" doesn't quite sound as good, does it? So, yeah, I'm positioning myself as an expert, but anybody who is anybody knows I'm not THE expert.

I started learning CSS in 2003 when a coworker at a new place I started working said, "This is how we do things." He mentioned a guy named "Zeldman" and other names like "Cederholm" and "Meyer", and though I had never heard of them before, I scrambled to find out who they are and digest as much of what they've written as possible. A name like theirs, or the others that run in their circle, would probably better qualify as the CSS guy. I would hope that any CSS assistance I may provide to you would be approved by those guys.

Thanks.

2007년 5월 10일 목요일

How to choose an RTOS for your FPGA and ASIC designs

Source: http://www.pldesignline.com/showArticle.jhtml?printableArticle=true&articleId=199500390



May 09, 2007

How to choose an RTOS for your FPGA and ASIC designs

As an alternative to purchasing an off-the-shelf RTOS or writing your own, a new software synthesis technique called RTOS synthesis may be of interest for certain applications.

By Bob Zeidman, Zeidman Consulting

Introduction
This article examines different options for putting a real-time operating system (RTOS) on a system on a chip (SoC). There are basically three options:

1. Purchase an off-the-shelf RTOS
2. Write your own RTOS
3. Use a software synthesis tool to automatically generate an RTOS.

If you purchase one, what is available and what are the tradeoffs? If you write your own, which issues will you need to take into account? If you synthesize one, what tools are available and how do they work?

What is a system-on-a-chip?
The definition of a system on a chip (SoC) varies somewhat, depending on the use. One definition is a chip that is so large – contains so many logic gates – that it takes the place of an entire system that would have taken an entire PCB full of chips only a few years ago. For the purposes of this article, however, we will use the definition that a programmable SoC – which may be implemented as a custom ASIC or using an off-the-shelf FPGA – must include a microprocessor.

What is an RTOS?
A good place to start is to define a real-time operating system. The book Real-Time Concepts for Embedded Systems, by Qing Li with Caroline Yao, defines an RTOS as: "a program that schedules execution in a timely manner, manages system resources, and provides a consistent foundation for developing application code."

The key differentiator between any old operating system and a real-time operating system is the term "timely." Of course, this vague adjective leaves lots of wiggle room. Rather than "timely," it might be better to say "within specified time constraints." An RTOS has specific time constraints that a desktop PC does not. For example, when you click on an icon, it may take seconds (or, unfortunately even minutes) to start the execution of a program while a disk cleanup operation or a virus scan is occurring in the background. By comparison, when you step on your brake pedal in your car, you can't have the operating system finish a disk scan before the brakes are activated. In this case the brakes must activate within a specific time, so the OS in your car must be a real-time OS.

The example of the braking system in a car is more precisely what is called a hard RTOS. This means that the time between pressing the brake pedal and the time that the brakes are engaged must have an absolute worst-case time, or latency. A hard RTOS has time constraints that must be met under any and all conditions for certain tasks. By comparison, a soft RTOS can usually respond within a certain time, though under some conditions there may be further, unpredictable delay. For example, a vending machine company may have surveys showing that customers want their candy bars within 2 seconds of pressing the button, but if one out of every thousand customers has to wait 10 seconds, there will be no catastrophic results (other than a swift kick to the machine).

The book goes on to say that: "in some applications, an RTOS comprises only a kernel, which is the core supervisory software that provides minimal logic, scheduling, and resource management algorithms. . . On the other hand, an RTOS can be a combination of various modules, including the kernel, a file system, networking protocol stacks, and other components required for a particular application. . ."

This definition illustrates one of the problems in defining an RTOS. Some people refer to the kernel, the basic task scheduler, as the RTOS while others refer to the kernel plus hardware drivers plus services as the RTOS. Those who followed the Microsoft anti-trust legal proceedings will remember that this same question came up there. When Microsoft added a file editor and a calculator and – specifically – a Web browser, did these constitute applications on top of the operating system, as the government insisted, or did they constitute additional functionality for the OS as Microsoft insisted? The answer is not simple and many reasonable people continue to disagree. For our purposes, we will refer to the RTOS as simply the task manager or kernel. The drivers and applications, though very important, will be considered to be separate.

Do You Need An RTOS?
If your SoC will be running more than one task then it needs an RTOS. If your SoC will run only one task, then most likely you would not need an SoC but could simply create a hardware state machine in Verilog or VHDL to implement the single task.

While it is theoretically possible to create the RTOS in hardware, the effort is difficult, there are few if any tools to support it, and it is very difficult to make changes during development and particularly to systems in the field. These are all the reasons why software is useful and why systems are migrating to processor-based SoCs.
One argument that you must be careful to avoid is the one that says the processor in your SoC is doing only one thing so there is no need for an RTOS. This argument is often heard when describing multiprocessor SoCs – those with multiple small processors, each handling a single piece of hardware or a single small task. The CEO of a company that produces configurable processors – someone who should have known better – made this argument at a recent talk. If your SoC contains multiple processors, each handling one task, the processors by definition are actually handling more than one task. Each processor is handling the task to which it is assigned plus the task of communicating with the other processors. All SoCs need some kind of RTOS. The question is which RTOS and whether to build, buy, or use a third, more recent, option – synthesize.

Purchasing an RTOS
Many commercial companies offer RTOSes that have been designed and debugged for you. These are often called "off-the-shelf" RTOSes. There are generally two kinds of off-the-shelf RTOS – ones where you purchase object code that has been compiled for the processor you will be using, and ones where you receive the source code and compile the code to your processor. These are described in further detail below.

Object Code: A traditional off-the-shelf RTOS consists of code that has been written, compiled, debugged, and tested by a company that then sells the object code. The main reason for selling object code is that this protects the intellectual property of the company because the object code is extremely difficult to reverse engineer. It also means that the customer relies on the vendor to do a good job and to support the code when there are problems.

The traditional method of charging for these kinds of RTOSes is with an upfront fee and a royalty. In other words, the vendor receives a certain amount of money to hand over the code to the customer and support it during system development; the vendor subsequently receives a little money for each system that the customer ships containing the RTOS. With the availability of embedded Linux, which is open source, the object code model is becoming less popular.

Open Source: Especially since the introduction of Linux, and later the introduction of real-time versions of Linux intended for embedded systems, users are often no longer willing to pay royalties and want their software for free. Of course there is no such thing as a free lunch. Companies do not stay in business by giving away free goods. Open source RTOSes may be free to download, but there is usually a steep learning curve.

Linux, for example, is a one-size-fits-all RTOS with every imaginable feature in it. Writing code to conform to Linux and configuring it to your system is non-trivial. Companies providing RTOS source code for free make their money by charging for tools, support, and code that runs on top of the RTOS. Also, be careful with regard to the temptation to obtain free code and free support from a users group or a university. In this case, the support you receive is done on an "as available" basis, so if your customer has a problem during summer vacation, you may have to wait until school is back in session to get help.

Writing your own RTOS
It surprises many people, even those in the industry, that about half of all embedded systems projects still use a proprietary, "home-grown" RTOS. There are many reasons for this. Many large companies, in order to protect their intellectual property and maintain tight control over their software, have developed their own RTOSes and continue to maintain them from project to project. This requires a lot of resources, both money and personnel, to do effectively.

Many small companies also write their own RTOS because they have a simple system and feel it is faster and cheaper to write a small polling loop task scheduler than spend money on a bloated, off-the-shelf RTOS with all the unnecessary bells and whistles. This has some merit in many cases, but it is also possible to underestimate the effort involved in implementing even a rudimentary task scheduler. Writing the code may be simple, but debugging it can be very time consuming, especially because many hazards will not appear except under very specific conditions. If exhaustive testing on the actual hardware is not performed before shipping the system, it is likely that intermittent problems will occur in the field that will be very difficult to track down, repeat, and fix.

Synthesizing an RTOS
A very new technology is now available called software synthesis, and in particular RTOS synthesis, that takes the concept of hardware synthesis and applies it to software. An RTOS synthesis tool allows you to write code for specific tasks in C, or theoretically any high level language.

In order for one task to call another task, or wait for another task to complete, a special primitive is inserted in the task source code that looks like a function call and that is recognized by the RTOS synthesis tool. The programmer also creates a configuration file to specify the parameters of each task, such as the task's priority and its period, and to specify the requirements of the operating system such as the scheduling mechanism.

The RTOS synthesis tool is then run on all of the task source code. The RTOS synthesis tool creates the appropriate semaphores and flags for each task and inserts the appropriate code to implement these features at the appropriate points in the task source code. The RTOS synthesis tool creates the necessary data structures and inserts them at the appropriate points in the task source code. The RTOS synthesis tool also creates task management source code to manage the tasks and their asSoCiated flags and semaphores. The RTOS synthesis tool also generates the RTOS source code that controls execution of each task.

An RTOS synthesis tool outputs source code, so it has many of the advantages of an open source RTOS, while at the same time producing code that is optimized for your proprietary system. The learning curve is small because the RTOS expertise is in the tool rather than required to be learned by you.

An RTOS synthesis tool is like a compiler. Originally, programmers needed to understand hardware very well in order to write assembly code. Each program was crafter for the specific hardware and optimized for speed or memory size. Programmers needed to understand stacks and heaps and memory allocation. As compilers became advanced, they did all of the work in those areas, allowing programmers to concentrate on perfecting the application itself. In the same way, an RTOS synthesizer allows a programmer to concentrate on the embedded application.

RTOS Considerations
Many of the issues regarding an RTOS for an SoC are the same as for any other embedded system. These issues can be divided into run-time issues and development-time issues. The first category concerns how the RTOS works and manages tasks in the system. The second category concerns developing the system code and the asSoCiated resource requirements.

Run-Time Issues
The run-time issues of an RTOS can be divided into several categories:

. Maintainability
. Performance
. Predictability
. Reliability
. Scalability
. Size

Maintainability: Maintainability can be both a run-time issue and a development time issue. At run-time, who addresses problems in the field when the RTOS has problems? Obviously, the system manufacturer is ultimately responsible. If you have developed the RTOS in-house or you have synthesized the RTOS, then you will be responsible for fixing the RTOS should problems arise. This can be a plus because you can respond quickly to problems in the field. It can be a negative if you do not have the resources to respond. If you have purchased the RTOS from another company, problems in the field can be offloaded, somewhat, to the RTOS vendor. However, their response time may not be as good as you need and their support is not free.

Performance: Performance can be measured in many different ways, and you must decide which ways are critical for your system. Typically, latency times are important – how long it takes the RTOS to switch from one task to another. This will depend on the task switching mechanism, the processor speed, the task priorities, and the granularity of the internal timer. If an RTOS is preemptive, meaning that the RTOS can suspend a task at any time in order to run a higher priority task, latency times will be more predictable, but preemptive RTOSes are larger, more complex, and more difficult to debug.

Often, engineers are not aware that many RTOSes are not preemptive, but are instead cooperative, meaning each task has full control of the system until it decides to give control back to the RTOS. Microsoft Windows 3.1 was cooperative but Microsoft Windows 95 and later versions are all preemptive. Linux, including embedded Linux, until version 2.6 was cooperative.

Cooperative multitasking works in an embedded system where you have control over each task including drivers and applications. You can ensure in the source code that the task behaves nicely and gives up control to the RTOS at reasonable times. However, if you use canned libraries and application object code, you run a risk that poorly written code will hang the system. If you require a hard RTOS, you should consider using a preemptive RTOS or synthesizing your RTOS in order to meet hard deadlines.

Another performance measure is data throughput. Performance can also be measured by the speed at which applications are executed. A system that is interrupting an application with many high priority tasks will take longer to complete the operation than one in which no higher priority tasks are running. An RTOS with an efficient mechanism for task queuing and swapping will run tasks faster. In many cases, but not all cases, a faster CPU will improve these performance numbers.

Predictability: Predictability is also important in an RTOS. An RTOS that has a best-case latency that is very close to its worst-case latency is better in many situations than one with a very fast best-case and very slow worst-case. The second system can perform better than the first in many cases, but the first system is more predictable. Again, predictability depends on factors such as whether the system is preemptive or cooperative, whether the code has been synthesized or hand written, and the efficiency of the task queuing and swapping mechanisms.

An RTOS that is written by hand must be tested under a variety of different situations, and numbers recorded, in order to determine best-case and worst-case timing constraints. An off-the-shelf RTOS should be characterized by the vendor after exhaustive testing. With a synthesized RTOS, static timing analysis can be performed in many cases in order to determine these numbers without exhaustive testing.

Reliability: The reliability of the RTOS is just one factor, but an important one, in determining the reliability of the entire embedded system. Other factors include the reliability of the board support package (BSP), the application software, the drivers, and the hardware.

Embedded systems using real-time operating systems are prone to certain hazards that can cause the system to hang or cause unwanted or unpredictable behavior. Below is a list and short explanations of these problems.

. Deadlock: A situation where a task is blocked from executing because it is waiting for a resource to become available while that resource is directly or indirectly waiting for the task to continue.
. Priority inversion: A situation where a high priority task is delayed while waiting to access a shared resource even though the resource is free to be used. In effect, the high priority task has been given a very low priority.
. Race conditions: This occurs when the outcome of an embedded system depends on the specific order in which tasks are executed.
. Starvation: A task cannot continue because it is waiting for a resource, but the operating system, usually due to a bug, will not give the task access even though the resource is available.

Some of these hazards can be prevented by the use of a well-designed RTOS and by the enforcement of well-defined rules for writing task source code. Again, the more third-party code you use, particularly compiled libraries and object code, the higher probability that your system will exhibit these kinds of hazards since you have no control over how the code is written.

Some hazards can be pinpointed by a software synthesis tool while the RTOS is being synthesized, allowing the programmer to fix it before compile time or run time. Some potential hazards can be eliminated entirely by the software synthesis tool. Some hazards can only be found by exhaustive testing of the final system under different sets of conditions.

Scalability: Scalability refers to how well you can add functionality to the system and still use the same RTOS. Scalability can be a run-time issue and a development time issue. Systems that are running in the field may require upgrades such that applications and drivers are added to the system. How well does the RTOS accept additional functionality?

Cell phones and PDAs are examples of devices where the user can add applications and the RTOS must support this. Synthesized RTOSes cannot be upgraded by simply adding an application because the synthesis only works when the source code for the entire system is known before synthesis. A synthesized system can only be upgraded by deleting the current system and loading entirely new software including the applications and RTOS.

Size: Code size can be an important factor, especially in consumer goods. Large code requires extra memory that consumes power. With regard to an SoC, a large RTOS can increase the system software size beyond what can be stored in RAM and ROM inside the SoC. In this case, an external memory is required, possibly slowing down the system and definitely increasing the system costs. An off-the-shelf RTOS from a commercial vendor tends to be very large because it must contain functionality to support all possible customers. Home grown and synthesized RTOSes tend to be much smaller and better suited to the memory requirements of an SoC.

Development Time Issues
The development time issues for an RTOS can be divided into several categories:

. Configurability
. Cost
. Driver and Application Libraries
. Maintainability
. Portability
. Scalability
. Standard Interfaces
. Tool Chain Support


Configurability: A home grown RTOS is, of course, as configurable as it gets. An open source RTOS is configurable, but it can be difficult to modify what is usually a complex piece of code. And, once modified, there is always the possibility that functions will break. How to find those broken functions and repair them is a big job.

Modifying object code is nearly impossible, though I have seen it done by a customer in order to temporarily fix a bug until the vendor could fix the source code and recompile (he did not get the Volkswagen Beetle that the company's advertising promised, though).

Synthesized code is very modifiable in that every new synthesis of the code produces new RTOS code. The ways to modify a synthesized RTOS is dependent on the workings of the synthesis tool and how much control the user is given.

Cost: Cost is obviously an important consideration at design time. RTOSes from vendors cost money up front, but can shorten development and testing time. They do not eliminate development and testing time because each embedded system is unique and problems will arise during development. And remember, there is no such thing as a free lunch, or operating system. Linux can be a good choice if you need many of the drivers and applications that have been created, and tested, to run on top of it. If you do not need those features, consider a different, smaller off-the-shelf RTOS or consider writing your own or synthesizing one.

Development time is another cost that engineers may tend to overlook. Longer development time translates not only to the cost of the salaries paid to the engineers but also the lost revenue from a product that gets to market later. For consumer products, this is particularly important. Writing your own RTOS can take a long time, particularly for a complex system. Using an off-the-shelf RTOS can speed up the development time, but only if the engineers are experienced with the particular RTOS, eliminating the learning curve.

Using an off-the-shelf RTOS can speed up development if it allows you to use existing drivers and applications provided by the vendor, or by the open source community. Synthesizing an RTOS can be the fastest way to create a system, especially if the drivers and applications need to be custom written for your system.

Driver and Application Libraries: Two important questions to answer are how many drivers and application programs are available for the RTOS you wish to use and how many of them do you need? The second question is important but sometimes goes unasked. If an RTOS has many drivers available, but all of your hardware is proprietary, then existing drivers do not help you.

For an SoC, this is very often the case since SoCs are so new and the hardware is configurable, meaning a standard driver will not work. If you can use existing drivers and applications and you have access to the source code, software synthesis tools can use the code with minor modifications, if any. If you do not have access to driver and application source code, an off-the-shelf RTOS may be advantageous.

Maintainability: Maintainability can be both a run-time issue and a development time issue. At development time, the question is how the RTOS can be maintained as the system hardware and software changes over time. An off-the-shelf RTOS may be relatively easy to maintain because it is designed by the vendor to support many different applications. It is the vendor's responsibility to maintain the system, though there is always the possibility that the vendor drops support altogether as has happened for many RTOSes in the past.

A home grown RTOS may be difficult to maintain unless engineers are hired specifically for that purpose. A synthesized RTOS is easy to maintain since the synthesis tool can be used over and over again to create a new RTOS for each new system.

Portability: An off-the-shelf RTOS has as much portability as the vendor can give it, which can be a lot or a little. Each new processor requires a new port of the RTOS to the new processor. If the processor is a popular one, chances are good that the vendor will port the RTOS. Of course, the porting process for new processors will take a while.

For a home grown RTOS, the portability depends on how many resources your company wants to spend on porting it to a new processor. This can be a long, lengthy process so most home grown RTOSes only work on one processor or family of processors, limiting your systems to that specific processor for future development.

An RTOS can be synthesized for any processor that has a C compiler because the synthesized RTOS does not rely on specific hardware to assist the RTOS. For this reason, a new RTOS can be synthesized for any processor, even a new processor immediately as it comes onto the market.

Portability is also affected by the peripherals and the hardware platform other than the processor. Off-the-shelf RTOSes often contain drivers for specific peripherals. This is a good thing if your system uses that specific hardware. This is not a good thing if your hardware does not use those supported by the RTOS. SoCs tend to use non-standard, proprietary hardware – the ability to design custom, optimized peripherals is a major advantage of an SoC – so that SoCs do not lend themselves as well to off-the-shelf RTOSes as do PCB based systems.

Scalability: Scalability can be both a run-time issue and a development time issue. How well does the RTOS accept additional functionality? As systems grow, an ideal RTOS will be able to adapt to them. Off-the-shelf RTOSes scale as long as the processor remains the same or mostly compatible with the previous processor. Home grown RTOSes typically can scale only if you have put the effort to design in scalability up front and have the resources to maintain the RTOS over several versions of the system. A synthesized RTOS scales easily because it is less hardware dependent and only requires each processor to have a C compiler.

Standard Interfaces: The off-the-shelf RTOS has the advantage when it comes to standard interfaces. A synthesized RTOS can make use of standard interfaces, but they may need to be modified by the user first. Sophisticated synthesis tools can automatically synthesize to specific standard interfaces if it is designed to do so.

Tool Chain Support: Because a synthesized RTOS is written in C, all development tools that work with C code can easily be used with it. A home grown RTOS, if it is written in C or another standard high-level language, can use these tools also.

Off-the-shelf RTOSes can be used with all development tools and have an additional advantage that some debuggers can be specifically tied into the tool to generate information that might be unavailable for debugging general C code. For example, the off-the-shelf RTOS can have hooks into a debugger to generate information about task latency, and to profile the memory usage, processor usage, and gather other useful information.

A synthesis tool can also generate such hooks that can be inserted into the RTOS code during debugging and not inserted for the release version of the code in order to minimize code size and improve performance.

SoC Issues
Certain of the issues mentioned above are particularly important for SoCs. In particular, these issues are:

. Configurability
. Driver Libraries
. Portability
. Scalability
. Size
. Tool Chain Support

Configurability: One of the main advantages of SoCs, particularly programmable SoCs, is their ability to be configured and customized. In particular, soft processors are designed such that the processor itself is configurable. Many off-the-shelf RTOSes are ported to a specific processor. It is difficult to port an RTOS to a configurable processor, but when it is done, the RTOS is ported to a specific configuration. This limitation requires that to use the RTOS, you must use that particular processor configuration. This eliminates one of the more desirable features of an SoC. A home grown RTOS can be written to the SoC configuration that you are using, but then it needs to be modified if that configuration changes. A synthesized RTOS can be synthesized to any processor configuration that is supported by a C compiler.

Driver Libraries: RTOS support for driver libraries are typically less important for SoCs than for ordinary PCB systems, because SoCs allow you to create custom, optimized, proprietary hardware that require unique drivers. So for all types of RTOSes, many proprietary drivers will need to be written.

Portability: SoCs are designed in a hardware description language like Verilog or VHDL in order to be able to translate that design to any FPGA or ASIC. If the RTOS is not portable, another large advantage of SoCs is lost. Home grown RTOSes are the least portable. Off-the-shelf RTOSes are portable, but only to specific processors with specific configurations that are supported by the vendor. Synthesized RTOSes are portable to any processor with a C compiler, which is practically any processor in existence.

Scalability: The flexibility of SoCs allows for much scalability in terms of hardware resources. Not being able to support scalable systems again reduces the advantage of an SoC. Home grown RTOSes are the least scalable. Off-the-shelf RTOSes are scalable as long as the processor remains constant. Synthesized RTOSes are very scalable.

Size: Most SoCs allow some amount of memory on chip, but not a significant amount because it is not cost effective. An off-the-shelf RTOS generally has a large memory footprint and requires an external memory to store the object code. A homegrown RTOS can be designed to use little memory, but requires effort to perform the optimization. An RTOS synthesis tool performs memory size optimization automatically and produces a tiny footprint that is only as large as the system requires.

Conclusions
There are many choices for an RTOS for your system on a chip. These choices can be divided into three general categories – purchasing an RTOS, writing an RTOS, and synthesizing an RTOS. You can purchase an RTOS in object code format or source code format.

This article has described each choice. This article has also itemized issues regarding the RTOS at run-time and during development that you should take into account. The article examined issues that are specific to SoCs. At this point you should have much of the information needed to begin an evaluation of specific RTOS solutions for your specific SoC requirements.

References and further reading

1. Barr, Michael and Ganssle, Jack, Embedded Systems Dictionary, CMP Books, Lawrence, KS, 2003.
2. Barr, Michael, Programming Embedded Systems, O'Reilly & AsSoCiates, CA, 1999.
3. Li, Qing with Yao, Caroline, Real-Time Concepts for Embedded Systems, CMP Books, Lawrence, KS, 2003.
4. Sridhar, T., Designing Embedded Communications Software, CMP Books, Lawrence, KS, 2003.
5. Zeidman, Bob, Designing with FPGAs and CPLDs, CMP Books, Lawrence, KS, 2002.

Bob Zeidman is the president of Zeidman Technologies (www.zeidman.biz), a company that develops hardware/software codesign tools. He is also president of Zeidman Consulting (www.ZeidmanConsulting.com), a contract research and development firm.

Since 1983, Bob has designed ASICs, FPGAs, and PC boards for RISC-based parallel processor systems, laser printers, network switches and routers, and other real time systems. His clients have included Apple Computer, Cisco Systems, Intel, Cadence Design Systems, and Texas Instruments. Among his publications are technical papers on hardware and software design methods as well as three textbooks –
Designing with FPGAs and CPLDs, Verilog Designer's Library, and Introduction to Verilog.

Bob has taught courses at engineering conferences throughout the world. He earned bachelor's degrees in physics and electrical engineering at Cornell University and a master's degree in electrical engineering at Stanford University.

2007년 5월 8일 화요일

The Top-10 Programmable Logic "How To" articles of 2006

출처: http://www.pldesignline.com/showArticle.jhtml?printableArticle=true&articleId=196801547



From alternative FPGA architectures to implementing three inversions using only two NOT gates (and no XOR gates), here's the "best-of-the-best" from 2006.

By Clive Maxfield / January 05, 2007

Over the last few issues of the Programmable Logic DesignLine newsletter leading up to the holidays, we've been counting down the top "How To" articles of 2006. The rating of these articles is based on the ones the visitors to
www.pldesignline.com read most often. Now, for the very first time, here they are all in one place:


#10 Alternative computing solutions, from single cores to arrays of 'things'

There are many ways of performing computations, including single CPU or DSP processors (chips or cores), multiple processors, arrays of "things", and "great big piles of gates."


#9 The state-of-play in multi-processor and reconfigurable computing

When a conventional processor (core) cannot meet the needs of a target application, it becomes necessary to evaluate alternative solutions such as multiple cores and/or configurable cores.


#8: How to take advantage of partial reconfiguration in FPGA designs.

The capability of designs to leverage partial reconfiguration opens doors to a whole host of applications.


#7: How to invert three signals with only two NOT gates (and *no* XOR gates): Part 2.

In part two of this article, we consider a dynamic solution to our original problem (using a ring oscillator and other "stuff"); also, we learn how to implement a NOT gate using four AND gates!


#6: FPGA Architectures from 'A' to 'Z' – Part 2.

If you are new to FPGAs, there are a bewildering number of different architectures and related concepts; but fear not, because this tutorial explains all.


#5: All About FPGAs.

An industry expert examines field-programmable gate arrays (FPGAs), including current and forthcoming architectures, technologies, and software tools.


#4: How to implement a digital oscilloscope in Structured ASIC fabric.

Structured ASICs provide quicker time-to-market and lower development costs than standard ASICs, while also providing higher performance and lower unit costs than FPGAs.


#3: How to invert three signals with only two NOT gates (and *no* XOR gates): Part 1

Even for hardened logic designers, these solutions will delight and entertain; also, there's a new "Brain Boggler" to be pondered.


#2: FPGA architectures from 'A' to 'Z' – Part 1

If you are new to FPGAs, there are a bewildering number of different architectures and related concepts; but fear not, because this two-part tutorial explains all.


#1: An introduction to different rounding algorithms

The mind soon boggles at the variety and intricacies of the rounding schemes that may be used for different applications. In addition to introducing different techniques, this article provides real-world examples of the types of errors associated with the different rounding schemes applied at various stages throughout a digital filter.


Embarrassingly enough, #3, #2, and #1 are all three that were penned by yours truly . . . just give me a moment, I promised myself I wouldn't cry . . .


Clive "Max" Maxfield is the editor of Programmable Logic DesignLine. Max is the author and co-author of a number of books, including Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), The Design Warrior's Guide to FPGAs (Devices, Tools, and Flows), and How Computers Do Math featuring the pedagogical and phantasmagorical virtual DIY Calculator.


Widely regarded as being an expert in all aspects of computing and electronics (at least by his mother), Max was once referred to as "an industry notable" and a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way. Max can be reached at
max@techbites.com.

액텔, FPGA에 최적화된 고성능 32bit 프로세서 개발



액텔은 최근 FPGA에 최적화된 고성능 32bit 소형 소프트 코어인 ARM Cortex-M1 프로세서를 발표했다. ARM과 공동으로 개발한 이 프로세서는 라이센스나 로열티가 없으며, 액텔의 플래시 기반 M1 지원(M1-enabled) Fusion 및 ProASIC3 FPGA에서 무료로 사용이 가능하다. Cortex M1 프로세서는 시스템 설계자에게 프로그램 가능한 유연성과 시스템 수준의 통합을 제공하기 때문에 저비용의 고성능 시스템 개발이 가능하다.

ARM의 3단계 Cortex-M3 공급 라인에서 파생된 Cortex-M1 프로세서는 액텔의 M1 지원 Fusion PSC(Programmable System Chip) 또는 ProASIC3 FPGA에서 최대 72MHz로 동작한다. 임베디드 애플리케이션을 위한 적절한 크기와 속도를 지원하고 있으며, M1A301000 ProASIC3 디바이스의 약 20%, 혼성 신호 M1AF600 액텔 Fusion PSC의 약 30%에 해당하는 4,300개의 타일 안에서 구현이 가능하다. Cortex-M1 솔루션은 또한 업계 표준의 AHB 버스와 연결해 서브 시스템을 구축할 수 있으며 프로세서에 주변 기능을 쉽게 추가할 수 있다.

Cortex-M1 프로세서에는 ARM 아키텍처를 대상으로 하는 광범위한 툴과 지식 정보가 지원되며, 이는 라이센스 기반 프로세서에서 제공하는 지원 수준을 훨씬 뛰어넘는 것이다.

액텔은 자사의 웹사이트에서 무료로 다운로드할 수 있는 CoreConsole IDP(IP Deployment Platform), SoftConsole 프로그램 개발 환경 및 액텔 Libero IDE(Integrated Design Environment)를 통해 Cortex-M1 프로세서를 지원할 예정이다.

액텔의 Cortex-M1 프로세서를 지원하는 M1A3P1000 ProASIC3 디바이스와 M1AFS600 Fusion PSC 제품은 오는 3분기에 첫 출시될 예정이며, 본격적인 공급은 4분기에 이루어질 예정이다. M1 디바이스의 가격은 3.95달러부터 시작된다.

Source:
http://www.ednkorea.com/article.asp?articleid=4419

OpenRISC 프로세서용 통합개발환경 ‘OpenIDEA’



다이나릿시스템이 업계 최초로 OpenRISC 프로세서 기반의 통합개발환경인 OpenIDEA를 발표했다. OpenIDEA는 소프트웨어 개발 스튜디오와 시스템 시뮬레이션 그리고 FPGA 보드 연동 기능을 제공한다.

다이니릿시스템에 따르면 최근 SoC 개발붐에 따라 신뢰성을 검증받은 RISC 프로세서에 대한 요구가 커지고 있다. OpenRISC는 무료로 사용이 가능한 공개 프로세서로서 ARM9 코어 수준의 성능을 갖추고 있다.

다이나릿시스템의 기안도 연구소장은 "무료/공개코드 프로세서 중 가장 넓은 사용자 층을 갖고 있는 OpenRISC1200은 32bit RISC 프로세서로 현재 RTL로 공개되어 있다. 또한 소프트웨어 개발환경은 GNU 툴을 기반으로 하고 있다. 하지만 아직 이렇다 할 사용자 편의성을 고려한 통합개발환경이 없다. 다이나릿시스템이 OpenIDEA를 개발하게 된 이유도 이 때문이다."라고 말했다.

OpenRISC의 경우 ISS를 제공하여 사용자의 능력에 따라 개발환경으로 활용이 가능하지만, 기술적인 어려움이 따른다. 프로세싱 코어가 내장된 설계의 경우 하드웨어/소프트웨어를 동시에 검증하는 것이 매우 중요한 부분인데, ISS만으로는 한계가 있기 때문이다.

OpenIDEA는 이러한 문제점들을 해결했다. 먼저, 그래픽 사용자 인터페이스를 만들어 C 프로그램 편집, 컴파일, 디버깅 등을 쉽게 할 수 있다. 둘째, 시스템 시뮬레이터의 기본 기능과 함께 HDL 시뮬레이터와 연동하도록 하여 실질적인 HW/SW 코-시뮬레이션이 가능하다. 셋째, 다이나릿시스템의 시뮬레이션 툴을 활용해 PCB 제작 없이 프로토타이핑을 개발할 수 있다.

OpenIDEA는 SoC 또는 임베디드 시스템에 OpenRISC를 적용하는데 필요한 개발환경이 모두 지원되는 통합 설계환경이다. 기안도 연구소장은 “OpenRISC는 소프트웨어 스튜디어 기능으로 소프트웨어 개발자의 생산성을 높일 수 있고, HW/SW 코-시뮬레이션 기능으로 시스템 통합 시뮬레이션이 가능하여 하드웨어와 소프트웨어를 동시에 검증할 수 있고, FPGA 보드 제작 없이 프로토타이핑을 할 수 있으므로 완벽한 기능 검증이 가능하다.”고 말했다. 한편, 다이나릿시스템은 FPGA에 맵핑된 설계 블록과 호스트 컴퓨터에서 수행되는 시뮬레이터가 USB를 통해 연동되는 FPGA/SW 동시 시뮬레이션 툴인 iNCITE를 함께 출시했다.

다이나릿시스템, www.dynalith.com
글/ 최찬용 기자(eric.choi@rbi-asia.com)

Source:
http://www.ednkorea.com/article.asp?articleid=4423

2007 전마협 하남 하프마라톤대회

지난 3월 31일, 머리털나고 첨으로 10Km 구간에 참가했는데 힘들어 죽을뻔 했슴...^^;
그래도 뛰고 나니깐 완주했다는 뿌듯함이 나름대로 느껴지더라는...

인텔 바이브 기술-개요

http://www.intel.com/cd/products/services/apac/kor/255666.htm

Information from Intel Corporation, 인텔 바이브 기술-작동 방식

http://www.intel.com/cd/personal/computing/apac/kor/our-technology/viiv/334683.htm