2007년 7월 19일 목요일

Emailing: [VHDL]01-클럭 짝수분주

 

[VHDL]01-클럭 짝수분주

하드웨어

2005/12/26 10:55

VHDL을 하면서 가장 처음 접하는것이 클럭 분주일 것입니다.

가장 간단하면서도 가장 많이 쓰이고, 가장 중요한 것이기 때문이지요.

 

짝수분주는 단순히 자신이 원하는 분주의 수를 반으로 나눠서 그 위상을 반전시켜주기만 하면 아주 간단 합니다.

물론 분주의 숫자가 커지면 카운터를 사용하는것이 간단하게 구성되지만, 2분주나 4분주 같은경우에는 굳이 카운터를 쓰지 않아도 되지요..

 

2분주를 하기 위해서 필요한건 사실 FF하나만 쓰면 되니까 정말 필요한건 거의 없구요.

우선 2분주의 예를 보겠습니다.

 

-- Clk_div2.vhd

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

Entity Clk_div2 is
    Port(
  clk_in : in std_logic;    --원 소스클럭 입력

  reset : in std_logic;     --초기화를 위한 리셋입력
  div2 : out std_logic      --2분주된 클럭 출력

          );
End Clk_div2;

 

Architecture arch_Clk_div2 of Clk_div2 is
Begin
Clock_div : Process(clk_in)
 Begin

  If reset = '1' then

    div2 <= '0';

  ElsIf clk_in'event and clk_in = '1' then
    div2 <= not div2;
  End If;
 End process;
End arch_Clk_div2;

 

아키텍쳐 부분에서 해주는것 없이 아주 간단하게 해결되지요??

그저 클럭이 high로 바뀔때마다 출력되는 div2의 값을 반전만 시켜주면 2분주가됩니다.

4분주의 경우에는 ElsIf 안에 한번 더 div2가 바뀔때마다 반전 시켜서 출력해 주면 끝이구요..

그 이상의 경우에도 마찬가지 방법을 적용하면 됩니다. 하지만 숫자가 늘어나면 자신도 햇갈리니까 카운터를 쓸 수 밖에 없겠지요??

그럼 이제 카운터를 사용한 16분주를 구성해 보겠습니다.

16분주로 구성하려면 카운터는 8까지 셀 수 있어야 하니까 3비트 카운터가 있어야 되겠군요.

-- Clk_div16.vhd

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

Entity Clk_div16 is
    Port(
  clk_in : in std_logic;    --원 소스클럭 입력

  reset : in std_logic;     --초기화를 위한 리셋입력
  div16 : out std_logic    --16분주된 클럭 출력

          );
End Clk_div16;

 

Architecture arch_Clk_div16 of Clk_div16 is

  signal cnt8 : std_logic_vector(2 downto 0); --8개를 세기 위한 3비트 카운터
Begin
Clock_div : Process(clk_in)
 Begin

  If reset = '1' then

    div16 <= '0';

    cnt8 <= "111";                                      --카운터 값을 초기화(리셋이 풀리면 카운터 값이 0이 되고, 이 첫클럭에서 분주를 시작하도록 하기위해서 111을 초기값으로 했습니다.)

  ElsIf clk_in'event and clk_in = '1' then

    cnt8 <= cnt8 + '1';
    If cnt8 = "000" then

      div16 <= not div16;

    End If;
  End If;
 End process;
End arch_Clk_div16;

이것도 역시 엄청 간단하지요??

짝수분주는 위의 예문처럼 아주 간단하게 해결됩니다...

음.. 하지만 위의 카운터를 사용한 16분주에는 정확히 자신이 원하는 결과는 나오지 않을 겁니다.

힌트를 드리자면, 리셋이 풀리면서 첫클럭이 들어올 때 동작한다는 내용이지요.

그래도 클럭은 정확히 16분주가 되지만 첫번째 클럭부터 동작하지는 않는다는 것이지요(사용하는 프로그램에 따라서 000에 반전되는것과, 001에 반전되는것이 있을껍니다.)

이에 관한 내용은 우선 이유를 생각해 보시길... 물론 여기에 관한 내용도 다른 주제로 여기에 올릴 예정 입니다.

출력하기 취소

2007년 7월 12일 목요일

2007 제12회 '바다의 날' 기념 마라톤 대회

지난 6월2일, 3월 31일 2007 전마협 하남 하프마라톤대회 이후 두번째로 도전하는 10Km 마라톤... 역시나 힘들어 죽을뻔 했슴...^^;

YouTube - Canon - Trace Bundy

http://www.youtube.com/watch?v=FRWU2DysF30

10 Years Old South Korean Boy Copy 'Canon' in one week.


2007년 7월 11일 수요일

Eleven Engineering Incorporated

http://www.elevenengineering.com/

Wireless Solutions & Semiconductor Technology

Eleven Engineering is a fabless semiconductor company specializing in wireless baseband processors and digital wireless audio modules. Leveraging the multithreaded technology of its XInC™ family of wireless processors, Eleve n has become a global leader in digital wireless audio. The Squeak product line of wireless digital audio modules ship in the WHAM2 form factor which is small and highly integrated to provide designers, developers, and manufactures with drop-in solutions for a wide range of wireless audio applications. All Squeak products employ Eleven's unique adaptive frequency hopping algorithm; WFD (Walking Frequency Diversity) to deliver superior audio quality of service (QoS), even in the crowded 2.4 GHz band. Eleven also offers evaluation kits, development kits, reference designs, and engineering services to facilitate easy integration and reduce time to market.

Silicon
XInC - wireless processor
XInC2 - wireless processor with built-in audio features


Digital Wireless Audio
Squeak 1.5 - high performance digital wireless audio
Squeak 1C - low-power digital wireless audio


Partner Information
Microlinear - RF front-end for Squeak 1.5
Chipcon - RF front-end for Squeak 1C
Texas Instruments - Audio market products

2007년 7월 5일 목요일

Home - VHDL Dev - Your home for VHDL development resources and assistance

 
VHDLDev.com is a new site designed for current VHDL designers and the future VHDL guru want-a-be. There are many good VHDL sites out there but none that provides a user community and exchange like VHDLDev.com. The website's intent is to provide a central location for VHDL information and bring VHDL users together to help one another and exchange ideas.

--
  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년 7월 3일 화요일

Emailing: Enhanced FPGA suits compute-intensive apps

News & Trends

Enhanced FPGA suits compute-intensive apps
Posted: 01 Nov 2006

Capitalizing on expiring FPGA patents and an accelerating shift of FPGAs into data-path processing, startup Velogix Inc. is developing a high-performance programmable-logic platform to run the billions of operations each second needed by applications like video and imaging, test and measurement, and communications. The platform is planned for unveiling by year's end.

As FPGAs grow denser and faster, they cannot only serve as logic-aggregation solutions, but can also take on data-path-dominated designs that demand significant computational capabilities. Such on-chip resources as large amounts of memory and dedicated multiplier-accumulator elements allow these FPGAs to deliver billions of multiply-accumulate operations per second and implement complex system functions. This application shift has been noted by major FPGA suppliers like Xilinx Inc. and Altera Corp., with their latest Virtex and Stratix platforms, respectively, as well as new companies like California-based Velogix.

By leveraging the latest processes, FPGAs hit density and performance levels that let the chips do more data-path and computational processing, said Danny Biran, VP of product and corporate marketing at Altera. Whether used as standalone processors or coprocessors, FPGAs can often replace such dedicated functions as DSPs, or can accelerate complex algorithms that the DSP block could not execute fast enough.

Altera's electronic system-level design tools make it easier to port algorithms to the FPGA by working at higher levels of abstraction, Birin said.

Application-optimized platforms help Xilinx deliver better performance in different market segments, the company's senior manager for DSP marketing, Narinder Lall, said. By offering a different mix of on-chip intellectual property (IP), he said—specifically citing memory, DSP and Serdes—"we can deliver platforms better able to serve the computer, networking and signal-processing markets." Adding more system-level capabilities lets FPGAs deliver performance exceeding that of CPUs. "We are also working with software providers such as Matlab and Simulink to develop tools that make it easier for algorithm developers to port their algorithms without knowing much about the underlying FPGA fabric," said Lall.

At Semico Research, Rich Wawrzyniak, senior analyst for ASICs, sees the shift to 65nm as an opportunity for FPGA vendors to increase on-chip resources and provide faster I/O pins. At the high end of the FPGA families, he expects this to give companies a big leap in compute capabilities.

These observations confirm research done by Velogix, which expects to deliver a high-performance, high-capacity programmable-logic platform before the year is out. The programmable-logic products now getting final touches will take on system designs in areas like imaging, test and measurement, computation, communications and A/V, said Velogix CEO Vivek Pendharkar. While these markets have existing programmable-logic solutions, Pendharkar said, a breakthrough opportunity exists for new products to handle computationally intensive applications.

With ASIC costs escalating, Pendharkar said, the timing is opportune to enter the market. Moreover, since some key programmable-logic patents have expired, there is no longer any patent overlap with the technology in development at Velogix.

New platforms will have higher levels of hard IP and a novel fabric core, Pendharkar said. Along with the new fabric, Velogix will also develop easy-to-use system-implementation tools, Pendharkar said, that will deliver shorter compilation times than the tools used for current-generation FPGAs. The first implementations will use Taiwan Semiconductor Manufacturing Co.'s 90nm process technology, he said, and will offer compelling prices and performance.

Acceleration's cost is falling as FPGAs offer higher capacities, said Martin Mason, director of silicon product marketing at Actel Corp. General-purpose CPUs and DSPs don't always offer needed flexibility, often making FPGAs the only alternative. SRAM-based FPGAs need dedicated compute blocks to achieve high multiply-accumulate throughputs, but on the fine-grained ProASIC flash-based FPGAs, high-performance multipliers and other compute elements can be implemented in the fabric, Mason said.

- Dave Bursky
EE Times


This article was printed from EE Times-Asia located at: http://www.eetasia.com/ART_8800439900_0_NT_481013b7.HTM

Back to Article Home

2007년 6월 18일 월요일

業界 最初의 90nm 基盤 非揮發性 FPGA solution, Xilinx의 새로운 Spartan-3AN platform

업계 최초의 90nm 기반 비휘발성 FPGA 솔루션, 자일링스의 새로운 스파르탄-3AN 플랫폼 출시

SRAM 기반 디바이스의 성능과 기능을 모두 지원하는 비휘발성 FPGA
도메인별로 최적화된 새로운 FPGA로 더 높은 시스템 통합과 더 낮은 시스템 비용, 더 높은 보안 실현

멀티 플랫폼 전략을 기반으로 제품라인을 확장해 나가고 있는 자일링스는 업계에서 가장 진보된 비휘발성 FPGA(Field Programmable Gate Array) 솔루션인 스파르탄(Spartan™)-3AN FPGA 플랫폼을 발표했다. 이 새로운 플랫폼은 이미 검증이 완료된 스파르탄-3 제너레이션 저가격 FPGA 패브릭을 기반으로 구현되었으며, SRAM 기반 FPGA에서 제공되는 성능 및 기능의 장점을 모두 통합하고 있는 것은 물론 싱글 칩 솔루션으로 구현이 가능한 비휘발성 플래시 기술의 이점을 안정적으로 실현하고 있다.

또한 이 플랫폼은 업계 최대의 유저 플래시 메모리와 첨단 보안기능을 제공하며, 특히 보다 높은 수준의 시스템 통합과 보안을 중요시하는 비휘발성 애플리케이션에 최적화되어 있다. 스파르탄-3AN 플랫폼은 가장 근접한 경쟁사 제품과 비교해 최대 1,000배 이상의 온칩 유저 플래시 영역과 뛰어난 시스템 유연성을 제공하고 있어 경쟁사의 비휘발성 FPGA 성능을 훨씬 능가한다.

자일링스의 GPD(General Product Division)사업부 크리스토프 첸(Christophe Chene) 마케팅 수석 이사는 "스파르탄-3 제너레이션 제품군에 새롭게 추가된 이 최신 제품은 멀티미디어 인코딩/디코딩 및 데이터 압축/해제 기능을 비롯해 마이크로컨트롤러 애플리케이션과 같은 비휘발성 싱글 칩 솔루션을 필요로 하는 공간에 민감한 애플리케이션에 적합하다."고 말하고 "프로그래머블 플랫폼과 임베디드 플래시 기술의 결합은 이러한 다이나믹한 애플리케이션 분야에 가장 유연하고, 안정적이면서 비용 효과적인 솔루션 제공이 가능하다."고 밝혔다.

아이서플라이(iSuppli)의 조단 셀번(Jordan Selburn) 수석 애널리스트는 “임베디드 비휘발성 메모리는 전반적인 애플리케이션 스펙트럼 상의 다양한 범주에서 시스템의 핵심요건으로 자리잡아 가고 있다.”고 말하고 “프로그래머블 및 시스템 레벨의 고집적이 가능하다는 장점 이외에도 스파르탄-3AN과 같은 제품들은 설계 보안 및 인증 등과 같은 중요한 문제들을 칩 디자이너들이 처리할 수 있도록 한다.”라고 설명했다.

저가의 유연한 보안 기능
스파르탄-3AN 플랫폼은 리버스 엔지니어링(Reverse Engineering) 및 복제, 비인증 오버빌딩(Overbuilding)을 방지하기 위한 다양한 디바이스 보안 기능들을 제공한다. 이 플랫폼은 자일링스의 Device DNA 기술을 통해 유효한 설계 인증 및 유연한 설계 레벨의 보안 기능을 구현할 수 있도록 저가격의 효율적인 매커니즘을 제공한다. 완벽한 유연성을 기반으로 설계자들은 인증 실패 후의 대응방법이나 인증 알고리즘을 직접 설계할 수 있다. 임베디드 플래시 메모리를 지원하는 스파르탄-3AN 플랫폼은 외부로부터의 모든 컨피규레이션 커뮤니케이션을 숨길 수 있어 FPGA 내에 있는 디자인을 파악하는 것은 거의 불가능하기 때문에 보다 최적화된 보안기능을 구현할 수 있다.

스파르탄-3AN 플랫폼의 첨단 플래시 기술은 Device DNA 기능을 새로운 레벨로 향상시키는 Factory Flash ID와 유저 플래시 영역을 제공하고 있다. Factory Flash ID는 Device DNA의 시리얼 넘버와 매우 유사하다. 모든 플래시 디바이스는 서로 다른 고유의 Factory 세트 ID를 가지고 있으며, 인증 알고리즘에 추가하거나 읽기가 가능한 64byte의 Long word를 제공한다. 유저 플래시 영역은 64byte 워드의 1회 프로그램이 가능한 공간으로 인증 결과를 저장하기 위해 사용이 가능하다. 또한 유저 영역은 시스템 내에서 결코 변경이 되지 않는 유저 데이터나 리비전을 위한 트래킹 시리얼 넘버들을 저장할 수 있다.

기능 저하 없는 비휘발성 FPGA
스파르탄-3AN 플랫폼은 첨단 시리얼 플래시 기술을 통해 데이터 보존기간 20년, 10만번의 쓰기/지우기 사이클이 가능한 새로운 표준의 비휘발성 FPGA로 경쟁사 제품에 비해 최대 1,000배의 쓰기/지우기 사이클을 제공하고 있다. 임베디드 및 스토리지 애플리케이션을 위한 최대 11Mb의 유저 플래시를 온 칩으로 제공함으로써 비용절감은 물론 풋프린트 사이즈를 줄일 수 있으며, 외부 메모리를 사용하지 않아도 된다. 또한 파인-그레인드(Fine-Grained) 보호 기능과 락다운(Lockdown), 지우기 기능을 통해 실시간 제어가 가능하다.

스파르탄-3AN 플랫폼은 최초의 90nm 비휘발성 FPGA로 듀얼 모드의 전력 관리 기능을 제공한다. 서스펜드(Suspend) 모드에서는 40% 이상의 전력 감소가 가능하고 웨이크 업 타임은 100㎳ 미만이며, 타임 도메인에 따라 시스템 레벨의 동기화가 가능하다. 하이버네이트(Hibernate) 모드에서는 최대 99%의 정적 전력소모를 줄일 수 있다.

차세대 컨피규레이션 관리
스파르탄-3AN 플랫폼은 유연성과 비용 효과적인 접근방법을 통해 빠르게 변화하는 마켓의 비휘발성 요구에 대응해 나가고 있다. 설계자들은 싱글 디바이스로 구현이 가능하며, 멀티플 컨피규레이션을 통해 서로 다른 다양한 기능 세트들을 관리할 수 있다. 스파르탄-3AN 디바이스는 설계자들이 멀티플 컨피규레이션을 저장할 수 있고 컨피규레이션 파일 간의 다이나믹한 선택이 가능하다.

또한 멀티플 컨피규레이션은 동일한 하드웨어 디자인을 사용해 진단 노드나 기능 업그레이드, 완벽한 제품 차별화 등을 지원할 수 있다. 프로토콜이나 버스, 인터페이스의 수와 같은 결정사항들을 새로운 마켓의 요건에 맞도록 다이나믹하게 변화시킬 수 있다. 사실상 무한한 재컨피규레이션이 가능한 멀티부트 기능의 통합으로 시스템 전체 비용을 낮추고 보다 쉽게 필드 업그레이드가 가능하다.

스파르탄 -3AN FPGA
스파르탄-3AN 플랫폼은 5개의 비휘발성 디바이스를 선택적으로 이용할 수 있다. 5만에서 140만 시스템 게이트 범위와 최대 576Kb의 블록 RAM, 그리고 총 16Mb의 임베디드 플래시, 26개의 범용 I/O 프로토콜 표준을 지원하는 최대 502개의 I/O 등이 제공된다. 또한 DCM(Digital Clock Manager)과 멀티플라이어, 저전력 모드 등과 같은 고유의 혁신적인 FPGA 성능을 통해 브릿징을 비롯한 메모리 인터페이스, 디지털 시그널 코-프로세싱, 임베디드 컨트롤 애플리케이션에 이상적인 솔루션을 제공한다. 모든 디바이스는 스파르탄-3A FPGA와 핀 호환된다.

가격 및 공급시기
고객들은 ISE™ 9.1i 설계 툴과 애플리케이션별로 특화된 스파르탄-3 제너레이션의 IP 라이브러리를 이용해 스파르탄-3AN FPGA를 기반으로 한 시스템 설계가 현재 가능하다. 현재 XC3S200AN, XC3S700AN, XC3S1400AN 디바이스의 엔지니어링 샘플이 공급되고 있으며, 2007년 3분기까지 모든 5개 디바이스의 양산 제품이 출하될 예정이다. 2007년 말에는 고객의 생산 스케쥴에 맞춰 4,000 로직 셀과 195개의 I/O를 제공하는 스파르탄-3AN 디바이스를 미화 4.9달러¹ 에 설계자들에게 제공할 예정이다. 따라서 스파르탄-3AN 디바이스는 세계 최초로 미화 5달러 미만에 공급되는 4Mbit 플래시 기반의 고집적 FPGA 제품이다.

¹리세일 수량 25만개 기준, 3S200AN-4FT256C

2007년 6월 15일 금요일

FPGA와 ASIC 모두에 이용할 수 있는 DSP 합성 엔진



FPGA와 ASIC 모두에 이용할 수 있는 DSP 합성 엔진
게재: 2007년 06월 01일

조윤주

신플리시티(www.synplicity.com)가 Synpilfy DSP ASIC 에디션을 출시함으로써, ESL 소프트웨어 라인을 확장했다. 신플리파이 DSP ASIC 에디션은 기술 독립적인 솔루션을 제공한다는 신플리시티의 전략에 따라 FPGA 뿐만 아니라 ASIC 디자인에도 적용할 수 있는 업계 유일의 DSP 합성 엔진이다.

신플리파이 DSP AISC 에디션은 단일 모델로 FPGA, ASIC 기기 모두에 최적화된 아키텍쳐 알고리즘을 실행하여, FPGA, 혹은 ASIC 디바이스에서의 구현을 위한 알고리즘 레벨의 고급 RTL 코드를 자동으로 개발할 수 있도록 해준다. 알고리즘 자동 구현의 독특한 DSP 합성으로, 디자이너들이 속도와 영역 간 상충 관계를 검토할 수 있어, 수작업으로 직접 코딩하는 방식보다 현저하게 높은 품질의 결과를 얻을 수 있다.

신플리시티의 Andy Haines 마케팅 수석 부사장은 “신플리파이 DSP ASIC 에디션은 월등한 생산성과 성능을 제공하기 때문에, DSP를 FPGA또는 ASIC 제품에 구현하려는 사람들이 반드시 선택하는 기술이 될 것”이라며 자신감을 피력했다.

신플리파이 DSP ASIC 에디션은 FPGA를 이용해서 ASIC 디자인을 프로토타이핑함으로써, 기능 상의 버그를 빠르게 찾아낼 수 있으며, 보통 100MHz가 넘는 빠른 작업 속도로 복잡한 상호작용을 더 많이 관찰할 수 있다. 또한, 신플리파이 DSP ASIC 에디션은 시높시스, 케이던스, 그리고 타 ASIC 메모리 IP 회사의 로직 합성도 지원하는 등 표준 ASIC 플로우에 완벽하게 통합될 수있는 솔루션을 제공한다.

신플리시티는 FPGA 합성 솔루션 부문의 선두기업으로서, 2004년부터 매년 EE Times가 실시한 FPGA 고객만족도조사에서 1위를 기록하고 있다. 신플리시티는 전세계 20개 지사를 두고 있으, 본사는 미국 캘리포니아 써니베일에 위치해 있다. 더욱 자세한 정보는 신플리시티 웹사이트(www.synplicity.com)에서 찾을 수 있다.

- Source:
http://www.eetkorea.com/ART_8800466660_480103_NT_631e9f61.HTM

HDMI

고화질 멀티미디어 인터페이스(High Definition Multimedia Interface).

고선명 텔레비전(HDTV)에서 멀티미디어 콘텐츠를 보호하기 위한 방송 규격. HDTV나 셋톱 박스를 통해 고화질의 방송 영상을 수신할 때 불법 복제를 막기 위한 보안 기능으로서, 모든 콘텐츠를 무제한 복제, 1회 복제, 복제 불가의 3 종류로 분류하여 복제를 엄격히 통제하고 있다.

미국전기전자학회(IEEE)가 처음 제안했으며, 일부 유명 가전업체와 방송업계, 영화사에서 참여하고 있다.

리니어, 다기능 USB 배터리 차저 출시

Just F.Y.I...
 
Korean article URL: http://www.eetkorea.com/ART_8800467728_1103011_NP_185de6f1.HTM
English article URL: http://www.eeproductcenter.com/powersources/brief/showArticle.jhtml?articleID=199902328
 
Product URL: Linear - LTC3559 - Linear USB Battery Charger with Dual Buck Regulators LTC3559 LTC3559EUD#PBF (http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1003,C1037,C1078,C1088,P37930)
 
Thanks... C.W. :)

신제품

인쇄: 파일을 선택한 후 브라우저 메뉴에서 인쇄하십시오.

리니어, 다기능 USB 배터리 차저 출시
게재: 2007년 06월 11일

다기능 리니어 차저 + 듀얼 싱크로너스 벅

리니어 테크놀로지 코리아가 핸드헬드 어플리케이션을 위해 효율적인 다기능 전력 관리 솔루션 LTC3559를 개발했다고 밝혔다.

LTC3559는 독립형 리튬이온/폴리머 배터리 차저와 2개의 고효율 싱크로너스 벅 레귤레이터를 통합했으며, 로우프로파일 3mm x 3mm DFN 패키지로 제공된다. 리니어 배터리 차저는 어댑터 전원으로는 최대 950mA, USB 전원으로는 최대 500mA의 충전 전류를 제공할 수 있다.

이 제품은 20%/100% 풀스케일 충전 전류 세팅, 셧다운/이네이블(enable)을 위한 SUSP 핀, 그리고 /CHRG 핀에서 4개 차동 표시 상태 등 USB 기능성이 높은 것이 특징이다. 또한 배터리 에너지를 아끼기 위해 LTC3559는 서스펜드 모드에서 배터리로부터 3uA 미만의 전류를 소모한다. 이 차저는 최대 5.5V(최대 7V의 절대 과도전압으로 더욱 강력함 제공)의 입력이 가능하다.

LTC3559의 통합 싱크로너스 벅 레귤레이터는 100%의 듀티 사이클 동작이 특징이고, 각각 최대 400mA의 출력 전류를 제공할 수 있으며, 프로그래머블 출력 전압은 0.8V로 낮다. 내부 저 RDS(ON) 스위치는 90%의 높은 효율을 제공함으로써 배터리 런타임을 극대화 할 수 있다. 뿐만 아니라 버스트 모드(Burst Mode�) 동작은 경부하에서 효율을 최적화하며, 대기 전류 소모량은 35uA(셧다운 시 1uA 미만)에 불과하다.

정주파수 전류 모드 아키텍처를 사용하는 이들 벅 레귤레이터는 2.5V ~ 5.5V의 입력 전압 범위에서 동작한다. 스위칭 주파수는 2.25MHz로, 높이가 1mm 미만인 저가의 초소형 커패시터 및 인덕터를 함께 사용할 수 있다. 또한, 이들 레귤레이터는 세라믹 출력 커패시터와 안정적으로 동작해 출력 전압 리플이 매우 낮다.


본 기사는  에 있는 전자 엔지니어 기사에서 인쇄한 것입니다.http://www.eetkorea.com/ART_8800467728_1103011_NP_185de6f1.HTM
http://www.eetkorea.com/ART_8800467728_1103011_NP_185de6f1.HTM

이전 기사로 | 전자 엔지니어

 
 

2007년 6월 5일 화요일

[fpga-cpu] x86 16bit CPU

-------------- Original message -------------
From : "N S"<
nshimizu@yahoo.com>
To : <
fpga-cpu@yahoogroups.com>
CC :
Date : Tue, 5 Jun 2007 10:8:34 +0900 (KST), Mon, 4 Jun 2007 18:08:27 -0700 (PDT)
Subject : [fpga-cpu] x86 16bit CPU

 

One of my graduated student agreed to open his design
under the GPL.

I put the sample code "x86FPGA package" under my web.

http://www.ip-arch.jp/indexe.html

It requires:
sfl2vl (convert SFL to Verilog),
Icarus Verilog,
NASM
and some other UNIX tools to run simulation.

We have ran FreeDOS under Icarus Verilog,
and also we ran a monitor program on ALTERA UP3 FPGA
board.

maybe I sent under the way email, sorry if you have
multiple copies.

Naohiko Shimizu,
IP ARCH, Inc.

__________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting

[Non-text portions of this message have been removed]

__._,_.___
To post a message, send it to: fpga-cpu@yahoogroups.com
To unsubscribe, send a blank message to: fpga-cpu-unsubscribe@yahoogroups.com

Recommendations for Booting Windows from USB Storage Devices



Source: http://www.microsoft.com/whdc/device/storage/usb-boot.mspx

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