Transcript 디지털 시스템 설계(1)

디지털 시스템 설계(1)
디지털 회로설계 방법의 진화
 1970년대 이전
 반도체회로설계라는 말 자체가 생고
 엔지니어가 직접 수작업으로 설계
 1970년대
 직접 설계 했던 수작업에서, SPICE 검증단계로 전환
 CAD(Computer Aided Design) 시대
 Layout Design, 1,000 Gates 이하의 회로설계
 1980년대
 CAE(Computer Aided Engineering) 시대
 Schematic Capture와 Logic Simulation
 Gate Level Design, 10,000 ~ 100,000 Gates급의 회로 설계 시작
 1990년대 이후
 EDA(Electronic Design Automation), HDL(Hardware Description Language) 시대
 HDL과 설계자동화 Software를 이용
 100,000 Gates 이상의 회로설계
 추후
 Hardware와 Software 를 동시에 설계하는 Co-design 시대로 이동 전환
디지털 회로설계 방법
 Schemetic
 각 모듈(레지스터, Mux, Gate등)의 Graphic Symbol을
이용하여 회로를 직접 설계
 HDL
 VHDL
 상위수준에서 논리회로 수준까지의 기술용이
 다양한 시뮬레이션 지원
 Verilog-HDL
 RT 수준에서 게이트 수준까지의 기술용이
 하드웨어에 ㅔ가까운 기술로 의도데로 합성잘됨
 System-C
 상위수준에서 RT 수준까지 설계가능
 C++ 라이브러리를 이용한 쉬운코딩
디지털 회로의 종류
 조합회로
 회로의 타이밍이 각 게이트의 시간 지연과 입력 시그널
에 의해서만 결정됨
 Multiplexer, Encoder/Decoder, Comparator, ALU,…
 회로의 병렬성을 잘 고려해야 함
 순차회로
 주기적인 클럭이 입력으로 들어가서 데이터의 흐름을
제어
 Flip-Flop, Latch등을 포함한 FSM, pipelined logic, …
 VHDL 내에 Flip-Flop과 Latch를 명시하는 구문이 없기
때문에 의도대로 구현하기 위해서는 주의해야 함
디지털 시스템의 구분

SoC(System on Chip)


CPU


산술, 논리 연산 Unit인 ALU와 명령어를 읽어 각 유닉을 제어하는 CU를 묶은 ALU+CU 형태
MPU(Micro Processor Unit)


하나의 IC에 제어, 연산, 입출력, 저장장치가 모두 있는 Stand alone 형태
CPU의 소형판, CU+ALU, IO 및 메모리가 없음
MCU(Micro Controller Unit)


On chip에 CU+ALU+IO+Memoryrk 모두포함
MICRO COMPUTER(MICOM:일본식용어)
 GPU(Graphics Processing Unit)

그래픽전용 프로세서로, 소수점계산전문 CPU
 DSP(Degital Signal Processor)
 아나로그 신호(음성, 그림)를 디지털로 고속변환 후 고속의 계산전용 CPU
 ASIC(Application Specific Integrated Circuit)
 특정 어플리케이션전용(주문자 반도체)
 대량생산시 상대적으로 저가, 속도 빠름
 개발기간이 긴 단점
 PLD(Programmable Logic Device)
 AND-OR product Term 으로 구성되어 있어 원하는 논리회로가 구성가능
 FPGA(Field Programmable Gate array) CPLD(Complex Programmable Logic Device

사용자들이 마음 데로 칩상에 논리회로를 구성하여 자신이 원하는 기능을 만듬
VHDL 출현배경
 IC 또는 시스템의 복잡도와 함께 그설계의 난이도 급증
 Top-down 설계
Algorithmic level, register transfer level 등 high-level에서 설계 시작
 트랜지스터 105 --> cell 104 --> block 102 --> module 101 -->
VLSI --> 시스템
 프로그램을 만들듯 HDL(Hardware Description Language)을 이용하여
하드웨어를 표현
 CAD tool을 이용하여 자동적으로 (필요에 따라 수동적인 방법도 사용
하여) low-level의 설계를 생성
 설계기간 단축, 설계관리, 교환, 재사용에 효과적
 HDL은 1970년대부터 많은 관심을 모음
CDL, DDL, ISP, PMS, AHPL 등
 표준HDL의 필요성 인식
VHDL 출현배경
 VHDL의 공식적 논의는1981년 VHSIC program의 일환으로 시작
 제안 요청은 미국 공군에서 작성, 1983년 초에 확정
 Intermetrics, IBM, Texas Instruments와 VHDL 및 지원 소프트웨어
의 개발에 대한 계약
 1985년 VHDL version 7.2
 1987년12월 IEEE Computer Society산하 VHDL Analysis and
Standardization
Group이 IEEE Standard 1076-1987로 확정
 미국 국방성은 military standard 454로 지정
 많은CAD 회사들이 VHDL 지원 tool을 다투어 개발
 1993년 새로운 version을 IEEE Standard 1076-1993으로 확정
Design Flow
하드웨어 계층구조
 Architecture
 CPU, memory, interconnection, bus, …
 HW/SW Partitions, instruction set, protocol,…
 System C, VHDL, nML, …
 Register transfer
 Datapath, ALU, multiplier, MUX, register file, …
 HDL coding
 VHDL, Verilog HDL, System C, …
 Gate/Logic
 XOR, AND, Tri-state, netlist
 Synthesis
 Switch
 Transistors, analog
VHDL의 특징
 표현 능력
• 게이트수준에서 시스템 수준까지
• Structural, behavioral, data flow, mixed description
• Transport, inertial delay model
• User-defined resolution function
 설계 관리에 대한 지원
• Package
• Multiple architecture bodies
• Generic, generator등 을 이용한parameterized design
 확장성
• User-defined attribute
• User-defined type
• Overloading
 CAD tool 과의 연결 문제
•시뮬레이션지향적 언어
• Synthesis, timing verification, critical path analysis, testing등에
대한 지원 부족
시뮬레이션 모델
 Concurrent Processes + Signals
 Sensitive signal, Simulation cycle, delta delay
시뮬레이션 과정
VHDL의 기본구조
Library
Entity
Architecture
Configuration
Entity
Architecture
Configuration
Architecture
VHDL의 설계 스타일
Bottom-up
 가장 기초적인 소자부터설계해나감
 점차큰블록을 이루어감, 벽돌 쌓기
 ASIC이 나오기 전의 초창기방법
Top-down
 최 상위 블록에서부터 기능별로 쪼개나감
 divide-and-conquer
 복잡한 시스템에 적용
Mixed
 두 가지 방식을 혼합하여 설계
VHDL 설계 스타일
 동작 기술(behavioral description)
 C언어와 같은일반적인순차프로그램처럼동작
 설계자가 이해하기 쉬움
 실제 하드웨어 구현에 있어 최적화가 힘듬
 구조적 기술(Structural description)
 물리적인 블록들과 그들 간의 연결
 회로가 복잡해지면 이해하기가 힘듬
 실제 하드웨어와 가깝기 때문에 의도대로 구현 가능
 데이터 흐름 기술(Data-flow description)
 동작 기술과 구조적 기술의 중간 단계
 시그널들의 병렬성 인정
 and, or 와같은 연산자 사용 허용
기본구성
 시뮬레이션 과정
 Design entity는 entity declaration과 architecture body로 구성됨
 design entity = entity declaration(interface) + architecture body(behavior)
기본구성
 Entity Declaration
 Interface를 정의
 Generic
Design 파라미터 선언에 사용
실제 동작표현부분에서 사용할 상수를 선언 또는 외부에서 받아 들일 수 있
는 형태로 표현
 Port
회로의 외부와의 연결고리인 입출력 port(PIN)을 선언
선언방식
1) IN
: Input 만 가능
2) OUT
: Output 만 가능(Read 않됨)
3) INPUT : 양방향 가능
4) BUFFER : OUT 과 같은기능으로 ,Read가 가능
5) LINKAGE : 위 표현에 해당이 않된 외부와 연결되지 않은 것에 지정
기본구성
 Syntax
entity entity_name is
[generic
(generic_list);]
[port (port_list);]
[begin
entity_statement_part]
end [entity_name];
entity sample is
generic (
WIDTH : integer := 8; -- 내부에서 상수화
BIT_SIZE: interger; -- 외부에서 값을 받음
dly_di_do: TIME := 4.5 ns);
port (DI : in bit_vector(WIDTH-1 down to 0);
DO : out bit_vector(WIDTH-1 down to 0));
end sample;
기본구성
 Architecture Body
 Behavior를 정의
 다음과 같은 description이 가능
 Structural description
 Data flow description
 Behavioral description
 Mixed description
 Syntax
architecture architecture_name of
entity_name is
{architecture_declarative_item}
-- architecture 안에서 사용할 변수선언
Begin
{operation}
end [architecture_name];
기본구성
 Multiplexer의 structural description
-- Structural description
library prim;
use prim.gates.all;
architecture struct of mux is
signal selb, t1, t2: BIT;
-- configuration specification
begin
i1: inv port map (selb, sel);
a1: and2 port map (t1, x, sel);
a2: and2 port map (t2, y, selb);
o1: or2 port map (mout, t1, t2);
end struct;
기본구성
 Multiplexer의 data flow description
-- Data flow description
architecture dflow of mux is
signal t1, t2: BIT;
begin
t1 <= x and sel;
t2 <= y and (not sel);
mout <= t1 or t2;
end dflow;
기본구성
 Multiplexer의 behavioral description
-- Behavioral description
architecture behav of mux is
begin
process (sel, x, y)
begin
If sel = '1' then
mout <= x;
else
mout <= y;
end if;
end process;
end behav;
기본구성
 Test Bench
-- Test bench for 2-way multiplexer
-- Entity declaration
entity test_mux is
end test_mux;
-- Architecture body
-- Needs TEXTIO package
use STD.TEXTIO.all;
architecture mixed of test_mux is
signal x1, x2, y, sel: BIT;
-- mux component declaration
component mux
port (x, y, sel: in BIT;mout: out BIT);
end component;
-- configuration specification
for all: mux
use entity work.mux(struct);
begin
-- component instantiation statement
-- for mux component instantiation
m1: mux port map (x1, x2, sel, y);
-- concurrent signal assignment
-- statements for test vector
sel <= '0', '1' after 50 ns, '0' after 100 ns,
'1' after 125 ns;
x1 <= '1', '0' after 25 ns, '1' after 50 ns,
'0' after 75 ns, '1' after 100 ns;
x2 <= '0', '1' after 25 ns, '0' after 50 ns,
'1' after 75 ns, '0' after 100 ns;
기본구성
-- process statements for displaying
-- simulation results header
process
variable strbuf: LINE;
begin
WRITE (strbuf, " time sel x1 x2 y");
WRITELINE (output, strbuf); wait;
end process;
-- simulation results
process (sel, x1, x2, y)
variable strbuf: LINE;
begin
WRITE ( strbuf, NOW, RIGHT, 6);
WRITE (strbuf, sel, RIGHT, 5);
WRITE (strbuf, x1, RIGHT, 5);
WRITE (strbuf, x2, RIGHT, 5);
WRITE (strbuf, y, RIGHT, 5);
WRITELINE (output, strbuf);
end process;
end mixed;
time
0ns
0ns
25ns
25ns
50ns
75ns
75ns
100ns
125ns
125ns
sel
0
0
0
0
1
1
1
0
1
1
x1
0
1
0
0
1
0
0
1
1
1
x2
0
0
1
1
0
1
1
0
0
0
y
0
0
0
1
1
1
0
0
0
1
기본구성
Package
 흔히 쓰이는 type이나 subprogram 등을 한 장
소에 모아 선언해 둠으로써 다른 여러 설계가
공유하여 사용 할 수 있도록 해줌
 C와 같은프로그래밍 언어에서 include(header)
file과library(archive) file을 이용하여 type이나
subprogram을 여러 프로그램에서 공유하여 사
용할 수 있게 하는 것과 흡사
 Design entity와 마찬가지로 두 부분으로 나뉨
package = package declaration(interface) +
package body(subprogram body)
기본구성
 Sub Program
 일반적인 프로그램 언어처럼 중복되어 많이 사용되는 부분을 Function 이나
Procedure 라 부르는 Sub Program을 이용하여 간단히 표현
 Procedure 방식은 함수입출력선언자에 여러종류(in, out, input 등)의 Data
type으로 표현가능
procedure COMPARE (X,Y: in BIT; Z:out BIT) is
begin
if X = Y then
z <= ‘1’;
else z <= ‘0’;
end COMPARE;
기본구성
 Function방식은 결과값(return)이 있으며 함수입력선언자 입력, 출력등을 지정 할 수 없
고
 단지 입력만 선언 할 수 있음
 Function 이름선언에 “”를 사용하면, 함수입력선언자에 단 2개의 입력만 사용할수있음
 선언된 Function을 사용할때는, aaa <= To_bit(A,B), aaa <= a and b; 로 사용
function To_bit (S: std_ulogic; Xmap:BIT := ‘0’)
return BIT is
begin
if S = ‘1’ or S = ‘H’ then
return ‘1’;
elsif S = ‘1’ or S = ‘H’ then
return ‘0’;
else return Xmap;
end if
end To_bit;
function “and” (l: std_ulogic; r: std_ulogic)
return std_ulogic is
begin
return (AND_TABLE(1, r));
end “and”;
기본구성
 Syntax
package_declaration ::=
package package_name is
{package_declarative_item}
end [package_name];
package_body ::=
package body package_name is
{package_body_declarative_item}
end [package_name];
기본구성
기본구성
 Design Unit과 분석
 Design unit
 독립적으로 분석 될 수 있는 단위
 entity declaration, architecture body, package declaration,
package body 등
 Design unit은 분석되면 중간 형태(intermediate form)로 되
어 독립적으로 library에 저장됨(library unit)
 Design file은 여러 개의design unit으로 이루어지며, 여러 개
의 design unit을 포함하는 physical file로 구현
기본구성
 Syntax
design_file ::= design_unit {design_unit}
design_unit ::= context_clause library_unit
context_clause ::= {context_item}
library_unit ::=
primary_unit | secondary_unit
context_item ::=
Library_clause | use_clause
primary_unit ::=
entity_declaration
| configuration_declaration
| package_declaration
secondary_unit ::=
architecture_body
| package_body
기본구성
 분석순서
 주어진design unit을 분석하기 전에 그 design unit이 참조
(reference)하는 모든 다른primary unit들을 분석해야 함
 Secondary unit을 분석하기 전에 대응되는primary unit을 먼저 분
석해야 함
기본구성
 Design Library





Design unit이 분석된 결과인 중간 형태의 자료(library unit)가 저장되는 장소
File이나 directory로 구현
Resource sharing을 가능하게 해 줌
각각의 design library는 하나의 "logical name"을 가짐
VHDL은 logical name이 STD인 design library를 지원
 STANDARD라는 package와 TEXTIO라는package를 포함
 WORK라는 logical name을 갖는 design library는 분석할 때에 사용되는
working library임
 Library와 이에 포함된 package를 사용하려면 library clause와 use clause를
이용
 Implicit context item: