Here is "PLDWorld.{블로그}"...: 2007/01

2007년 1월 24일 수요일

Power MOSFET 적용 예가 정리된 곳 (WISDOM Technologies International)

WISDOM Technologies International

http://www.wisdomsemi.com/products/products_a_01.html

화면 좌측 sub-menu를 클릭하면 관련 적용 block diagram을 확인가능...

2007년 1월 19일 금요일

CSS Design Korea

이름: CSS Design Korea
개설일: 2005년 4월
URL: http://standardmag.org

포럼 http://forum.standardmag.org/
위키 http://wiki.standardmag.org/

소개: CDK는 거의 유일한 국내의 웹 표준 관련 커뮤니티 입니다. 웹 표준과 웹 접근성 그리고 관련된 여러가지 주제들을 다루고 있습니다. 포럼을 통해 커뮤니케이션을 형성하고, 위키를 통해 각종 문서 정리 및 모임 추진을 하고 있습니다.

2007년 1월 16일 화요일

Emailing: 수익성 높은 새로운 디자인의 아이팟 나노 모델

	뉴스 및 동향

수익성 높은 새로운 디자인의 아이팟 나노 모델 게재: 2007년 01월 04일 By David Carey President Portelligent Inc. Apple사는 2세대 아이팟 나노를 내놓으면서 자사의 인기 있는 플래시 기반 뮤직 플레이어의 디자인을 바꿨다. 전체 아이팟 제품 라인의 중간에 위치하고 있는 2세대 나노는 2기가바이트, 4기가바이트 및 8기가바이트 용량의 모델이 제공되는데, 이들은 각각 500곡, 1,000곡 및 2,000곡 정도의 노래를 저장할 수 있는 용량에 해당한다. 2세대 제품에서 달라진 것은 무엇일까? 가장 눈에 띄는 요소들로부터 시작하자면, Apple사는 케이스 디자인을 재구성하여 스테인리스제 통과 플라스틱제 프론트 케이스의 2부분으로 되어 있던 방식을 버리고 양극화 알루미늄 쉘 하나로 된 형태를 채택했다. 이 새로운 알루미늄 몸체 속에 전자 장치들이 빽빽하게 들어차 있다. 케이스 끝의 캡 부분들을 떼어낸 뒤 (아주 작은) 나사 몇 개를 풀어내면 핵심 전자 장치들을 케이스 통의 한쪽 끝으로부터 끄집어 낼 수 있다. 케이스의 대략적인 구조는 지금은 단종된 Apple사의 아이팟 미니로부터 빌려온 것이다. 마이크로드라이브 기반의 아이팟 미니는 상대적으로 상당히 큰 케이스를 필요로 했으며 전자 패킹도 2세대 나노 모델에서 볼 수 있는 집적도 수준에 미치지 못했지만, 기술 자체는 유사하다. 보호용의 끝 부분 캡을 제외하고는 미니의 경우와 마찬가지로, LCD(이 경우에는 176x132 픽셀의 TFT 디스플레이)를 위한 투명한 아크릴 윈도와 스크롤휠 방식의 어셈블리가 케이스 표면의 연속성을 깨는 유일한 부분들이다. PortalPlayer와의 차이점 Apple사에서는 기계 재설계와 함께 이 제품의 공급 체인도 크게 변경했지만, 선택된 설계 요소들은 상당 부분 그대로 놔두었다. PortalPlayer를 코어 미디어 프로세서로서 사용하지 않게 된 것이 아마도 가장 큰 변화일 것이다. Apple 라벨이 붙은 ASIC인 S5L870-B05는 삼성의 제품으로서 모든 오디오 및 스틸 이미지의 디코딩을 맡고 있다. 나노 모델의 CPU에 Apple사의 독점 마킹이 찍혀 있긴 하지만, 라벨을 볼 때 이 삼성 칩 내에 ARM 코어가 탑재되어 있음을 알 수 있다. 6밀리 x 6밀리 이하 크기의 이 다이는 PortalPlayer를 기반으로 하는 나노 모델의 이전 제품과 유사한 언더필 방식의 BGA 패키지로 되어 있다. 그러나 SST사의 별도 NAND 컨트롤러 구성요소를 갖추고 있던 1세대 디자인과는 달리, 이 삼성 CPU는 NAND 인터페이스를 직접 통합시킴으로써 비용과 복잡성을 줄인 것같다. 이 삼성 프로세서는 1메가바이트의 SST 플래시를 코드 일부나 전체를 저장하는 데 사용하고 있으며, Qimonda 32메가바이트 SDRAM이 시스템의 동작 메모리를 제공하는 것은 물론 어쩌면 NAND 플래시로부터 꺼내온 노래 데이터를 위한 버퍼 역할까지도 하고 있는 것같다. 다른 2세대 나노 모델들에 대한 검사 자료를 토대로, 삼성은 32메가바이트 SDRAM의 공급업체로 알려져 있다. 첫번째 나노 모델로부터 이어져 내려온 디자인 요소들 가운데는 Cypress사의 스크롤 휠 컨트롤러(CY8C21001A)와 전력관리용으로 수정된 NXP 칩(PCF50635)이 있다. 역시 오리지널 나노 모델로부터 수정된 Wolfson사의 부품(WM8750S)은 오디오 코덱 및 헤드폰 앰프용으로 선택되어 있다. 후자의 두 부분들은 삼성의 미디어 CPU와 같이 Apple사 고유 라벨이 찍혀 있는데, 이는 아마도 공급체인을 식별하기 힘들게 하려는 시도인 것같다. 보다 명백하게 마킹 되어 있는 다른 전력관리 부품들 가운데는 National Semiconductor사의 DC/DC 컨버터(LM34910B)와 Linear Technology사의 LTC4066(이것은 나노 모델의 USB 인터페이스를 통해 2.2밀리 x 33밀리 x 55밀리 크기의 웨이퍼 형 폴리머 배터리를 충전한다)이 있다. 배터리 자체는 표준 싱글셀 3.7V에서 330밀리암페어시 정도의 용량을 공급하는 것으로 추정된다. 이것은 총 사용가능 에너지 1.2와트시에 해당한다. 비용 면에서는 새로운 삼성의 프로세서(아마도 Apple사가 5 달러 정도에 소싱했을 것으로 보인다)보다 내부 NAND 플래시 메모리에 더 많은 비용이 든다. 최저 밀도의 2기가바이트급 나노 모델에서 조차도 하이닉스의 HY27UV08AG5M 4칩 스택형 NAND(단일 TSSOP 패키지에 들어 있는)는 20 달러 정도의 비용을 차지하고 있는 것같다. 물론 이는 Apple사에 대한 가격 할인과 계약구매 타이밍에 크게 의존하지만 말이다. SDRAM의 경우와 비슷하게, NAND 플래시에서도 멀티소싱이 중요하다. Toshiba와 삼성은 둘 다 이 새로운 나노 계열을 위한 NAND 플래시의 추가 공급 업체들로 알려져 있다. 이 제품은 TSSOP 패키지의 스택들을 사용하여 8기가바이트의 보다 큰 메모리를 갖추고 있는데, 이 패키지들 각각은 내부에 독자적인 멀티다이 스택들을 포함하고 있다. 시각적 증거와 Staktek사가 공개적으로 제공한 정보를 토대로 해볼 때, Toshiba사는 Staktek사의 TSSOP 패키지 스태킹 기술을 사용하고 있는 것같다. 이 모든 것들을 고려해보면, 2기기바이트 용량의 이 2세대 나노 모델은 액세서리(이어폰, USB 케이블 및 도킹 어댑터)를 포함하여 65달러 범위의 직접생산 및 소재 비용을 가질 것으로 추정된다. 보다 고밀도의 NAND 스택 가격을 다소 높이 잡는다면 4기가바이트 및 8기가바이트 버전의 소재 및 생산비는 각각 87달러 및 132달러 범위가 될 것으로 추정할 수 있다. 세 가지 모델들(2기가바이트, 4기가바이트 및 8기가바이트)의 소매가는 150달러, 200달러 및 250달러로서, 총 마진은 좋아보인다. 이는 로엔드의 경우 56퍼센트에서 하이엔드의 경우 47퍼센트에 이른다. 물론 제품 개발, 마케팅, 출하 및 모든 소프트웨어 라이선스와 관련된 다른 간접 비용들은 이 수치에 포함되어 있지 않지만, 어떠한 경우이든 여전히 상황은 상당히 긍정적이다. 보다 고밀도 NAND의 가격이 다소 떨어진다고 해도, 탑엔드 모델의 마진은 보다 신속하게 개선될 것이다. 최신 나노 모델이 이전 모델에 필적하는 인기를 누릴지는 아직 두고 볼 일이다. 소비자들은 아이팟에 다소 싫증을 느낄지도 모르고, 이 제품 라인의 빠른 진화는 구매자들이 잦은 제품 변화 및 업그레이드를 따라올 수 있는 능력을 소진시켜 버릴지도 모른다. 하지만 시장에 대한 그 같은 질문에는 오직 시간만이 대답해 줄 수 있다. 아직까지는 Apple사가 멋진 디자인에다가 수익성도 높아 보이는 또 다른 아이팟 모델들을 가지고 여전히 오디오 플레이어 시장을 지배하고 있다. Apple사에서는 기계 재설계와 함께 이 제품의 공급 체인도 크게 변경했지만, 선택된 설계 요소들은 상당 부분 그대로 놔두었다. 본 기사는 http://www.eetkorea.com/ART_8800447831_480303_c76a4ab2200701.HTM 에 있는 전자 엔지니어 기사에서 인쇄한 것입니다.

Emailing: Programmable Logic DesignLine | How to maximize FPGA performance

http://www.pldesignline.com/196900804

January 15, 2007

How to maximize FPGA performance

The more that can be done upfront with good coding styles, timing constraints definition, and resource planning, the easier it will be for the downstream tools to achieve timing requirements.

By Michelle Fernandez, Xilinx

Editor's Note: See also the related Product Release Article.

As FPGAs push the envelope of performance, understanding how to design for maximum performance requires knowledge of the device architecture and design software. Today's FPGAs resemble a true System-on-a-Chip (SoC) with many more sophisticated features than the glue logic FPGAs of the past. To maximize system performance, designers need to use proper design techniques such as defining timing constraints and selecting options in synthesis and implementation that work best for their design. This article describes how to achieve faster timing in the fewest design iterations.

Understanding the architecture
When evaluating a new FPGA architecture, it is important to understand the hardware features and the tradeoffs that can be made in the architecture. Datasheets, user guides, and technical papers on the architectural features should be thoroughly reviewed before moving forward with a design.

The first thing to learn about any FPGA is what makes up the basic fabric of logic. For example, each of the configurable logic blocks (CLBs) in a Xilinx Virtex-5 FPGA contains two slices; and each slice contains four 6-input look-up tables (LUTs), four registers, and dedicated carry logic. For maximum utilization of each slice, it is important to take into consideration the width of the LUTs, the connectivity between the basic elements, and any shared resources.

Many FPGA architectures also contain hard IP blocks, such as embedded memory and blocks used for DSP functions. If a hard-IP block continuously shows up as the source or destination of your critical path, there are a couple of things that can be analyzed to improve the performance. First, check to see if the design is making the most of the block's features and that the synthesis tool is inferring the features you expected from your RTL code. Use the dedicated pipeline registers inside the blocks to reduce the setup and clock-to-out timing. Evaluate the tradeoff between using dedicated blocks versus implementing the same function in slices to allow for placement flexibility. This can especially be important when using a high percentage of hard-IP blocks.

The clocking resources that are utilized in a design can also affect a design's performance. For example, Xilinx Virtex-5 FPGAs have I/O, regional, and global clocking resources. These devices are divided into clock regions which at most, can contain 4 regional clocks and 10 global clocks. During design planning, it is important to analyze how many clock regions are going to be used as well as specific clocks within a clock region. Placing your I/Os so that their interface logic does not require all the clock resources in a clock region gives the implementation tools greater placement flexibility.

Define timing requirements
Synthesis and implementation tools are driven by the performance goals that a user specifies with timing constraints. It is important to constrain all internal clock domains, input and output (I/O) paths, multi-cycle paths, and false paths. Define realistic timing constraints in synthesis order to prevent excessive replication.

In your synthesis report, check for any replicated registers and ensure that timing constraints that might apply to the original register also cover the replicated registers for implementation. When writing timing constraints for implementation, group the maximum number of paths with the same timing requirement first before generating a specific timing constraint. By consolidating constraints, implementation runtime and memory usage can be minimized.

Example of non-consolidated constraints (Xilinx constraint syntax)
TIMESPEC "TS_firsttimespec" = FROM "flopa" TO "flopb" 10ns;
TIMESPEC "TS_secondtimespec" = FROM "flopc" TO "flopb" 10ns;
TIMESPEC "TS_thirdtimespec" = FROM "flopd" TO "flopb" 10ns;

Consolidation of constraints using grouping
INST "flopa" TNM = "flopgroup";
INST "flopc" TNM = "flopgroup";
INST "flopd" TNM = "flopgroup";

TIMESPEC "TS_consolidated" = FROM "flopgroup" TO "flopb" 10ns;

Driving synthesis
For a synthesis tool to create a high-performance circuit, the tool needs to be properly driven by the designer. The first thing a designer needs to consider is proper coding techniques to ensure that inference of behavioral RTL made by the synthesis tool leads to the maximum usage of the architectural features. For example, Xilinx ISE Project Navigator's language templates – available in both Verilog and VHDL – are a great place to get coding examples.

Next, make sure that the synthesis tool has a complete picture of the design. If a design contains IP netlists or any other lower level black-boxed netlists, these netlists should be included in the synthesis project. Although the synthesis tool won't optimize any logic within the netlist, it will have a better understanding of how to optimize the HDL that interfaces to these lower level netlists.

The tool also needs to understand the performance goals of a design using the timing constraints supplied by the designer. If there are critical paths in the implementation that are not seen as critical in synthesis, try Synplicity Synplify PRO's –route constraint to force synthesis to focus on that path. Finally, there are a variety of tool settings in synthesis that should be explored. Refer to Fig 1 for suggested tool settings for Synplify PRO.

1. Suggested tool settings for Synplify PRO.It is important to start off with a baseline set of tool options and incrementally add new switches to understand the effects. Also note there are a variety of attribute settings that can affect how inference of logic is done and synthesis is optimized. These attributes are an easy way to affect synthesis with out having to re-code (see Table 1)

Table 1. Helpful Synthesis Attributes.*

* For a complete listing of attributes and their functionality, please see the synthesis tool's documentation.

Although timing performance might be enhanced, options that do lead to the replication of logic such as retiming in Synplify PRO can impact area. If the design is affected by high-fanout nets and you want the synthesis tool to reduce that fanout, use fanout attributes specifically on that specific net, versus globally specifying a maximum fanout limit. If hierarchical boundaries are maintained, a designer should make sure that ports are registered at the hierarchical boundaries. If critical paths cross over these hierarchical boundaries, certain optimizations will not be allowed by the synthesis tool. This can lead both to lower performance and higher area utilization. Before moving on to implementation, it is always important to review the warnings in the synthesis report. It is also beneficial to check the RTL schematic view for how the synthesis tool is interpreting the HDL and the technology schematic to understand how the HDL is mapping to the specific FPGA architecture.

Choosing implementation options
Having obtained an acceptable timing estimate from the synthesis tool, use the implementation tools to determine the true performance of the design. The implementation options that can be used are unique for each design depending on the performance goals of the design, the synthesis flow used, and its overall structure. Once the majority of the functionality is defined in the design's HDL and the effort is focused on timing closure, it is beneficial to run a series of different implementations with different sets of options to determine which is the best combination for the design.

ISE Xplorer is an example of a tool that will allow a designer to determine which options work best. ISE Xplorer has been tuned for each Xilinx FPGA architecture to try the best set of combinations. Although initial runtime can be longer because multiple implementations need to be run, once the design has the right set of options, it will likely reduce the number of design iterations to achieve timing closure.

Physical synthesis options in implementation can be used to re-optimize and pack logic based on knowledge of the critical paths of a design, leading to better placement and routing. Note that physical synthesis can lead to increased area due to replication of logic. Like synthesis, if hierarchy is maintained on a design but the critical path crosses those hierarchical boundaries, physical synthesis will not be able to optimize that path and potentially, inefficient packing will occur. To evaluate whether keeping hierarchy is affecting the performance of the design, turn off hierarchy preservation with an attribute or option during implementation. If it does prove to have an impact, reconsider how the hierarchical boundaries are defined.

Evaluating critical paths
By understanding the characteristics of the critical path, a designer can make better decisions on what to do for the next design iteration. A data path is comprised of both logic and interconnect delay. Individual component delays that make up logic delay are fixed. Logic delay can only be reduced if the number of logic levels are reduced or the structure of the logic is changed. By comparison, interconnect delay is much more variable and is dependent on the placement of the logic, routing congestion, and the competition between nets for the fastest routing resources. Before routing the design a quick timing analysis after placement is recommended. Although this timing report will only have estimates for the routing delays, it will give an idea of the critical paths the implementation tools are working on. If the critical paths have a high number of logic levels, designers may want to work on improving the logic levels versus running it through PAR. When the design has an excessive amount of logic levels that lead to many routing interconnects:

Try the different physical synthesis options to see if logic levels can be reduced.
Go back to synthesis and verify that critical paths reported in implementation match what is reported in synthesis. If they are not, use constraints like Synplify PRO's –route to have the synthesis tool focus on these paths.
Review the HDL code to ensure that it takes advantage of the hardware.

In the case where there are few logic levels but the certain data paths are not meeting the performance requirement:

Evaluate fan-out on routes with long delay.
If a critical path contains hard-IP blocks such as RAMBs or DSP48Es, verify the design is taking full advantage of the embedded registers. Also understand when to make the tradeoff between using these hard blocks versus using slice logic.
Analyze clock skew. Large clock skew can be caused by inefficient use of the clock resources in the design.
Perform a placement analysis. If logic appears to be placed far apart from each other, floorplanning of critical blocks may be required. Only floorplan where necessary. Over floorplanning will not give as much flexibility to the tool and could lead to worse performance.
If area groups were created for a design with a previous version of software or prior to many design changes, consider removing those area groups to evaluate whether or not they are negatively affecting placement.
Consider placing hard IP blocks such as embedded memory and DSP blocks.

Conclusion
Today's FPGAs have a variety of high performance features. In order to take full advantage of these features, a few things need to be considered. The more that can be done upfront with good coding styles, timing constraints definition, and resource planning, the easier it will be for the downstream tools to achieve timing requirements. It is also equally important to know what to do next when design requirements are not met in first iteration.

Michelle Fernandez is a technical marketing engineer in the Software Product Marketing Group at Xilinx. Based on the analysis of customer designs, Michelle provides recommendations aimed at improving FPGA design performance and ease of use to the development teams at Xilinx. Michelle joined Xilinx in 1999 and has held a variety of positions in customer support and field applications engineering. She holds a bachelor's of science degree in electrical engineering from University of California at Davis. Michelle can be contacted at: michelle.fernandez@xilinx.com.