전자 산업의 태동 이후, 제조 기술은 보다 우수한 기능의 새로운 EDA 툴 개발을 촉진하는 원동력이 되어 왔다. 그리고 이제는 전자 산업을 재편할 정도의 기술적인 전환점에 도달했다. 대부분의 디자이너들에게 있어서 최신 IC 제조 기술을 사용하는 것은 이제 더 이상 최고의 목표가 아니다. 오늘날의 제품은 경쟁력을 유지하기 위해 복잡한 기능을 수행해야 한다. 130nm 이하의 공정에서 나타나는 기생 현상은 디바이스가 제 기능을 발휘하는 데 악영향을 미친다. 반면 대부분의 디자이너들은 이러한 문제를 해결하는 방법에 대해 교육 받지 않았으므로 개발 주기는 길어지고 비용은 증가하게 되었다. 따라서 레이아웃에서 문제를 피해 가거나 해결하길 기대하지 말고 문제를 본질적으로 피하는 방법을 찾는 것이 바람직하다. 이렇게 하려면 제품이 제 기능을 수행하고 일정에 맞출 수 있게 해주는 신중하고 정밀한 시스템 레벨 설계가 필요하다.

현재 개발된 대부분의 IC 제품은 설계 오류로 인해 적어도 한 번은 리스핀을 수행해야 한다. 리스핀 한 번에 드는 직접 비용은 평균 100만 달러가 넘으며, 이로 인해 시장 진출 기회를 상실하는 대가는 수천억 달러에 달한다. 그래서 디자이너는 가능하면 제조 공정을 신중하게 선택하고 다른 누군가가 새로운 공정 기술의 알려지지 않은 함정을 탐험해 주길 바란다. 엔지니어들은 프로젝트 초반에 제품의 계획, 정의, 작업 분할에 더 많은 시간을 투자한다. 그러나 유감스럽게도 이런 작업에 사용하는 툴은 대체로 정밀하지 않다. 툴은 인간의 의사소통에 쓰이는 언어를 기반으로 구성돼 있다. 즉, 무형식 의미론(informal semantics), 실행 모델로 변환할 수 없는 스프레드시트, 제품 개발에 사용되는 형식으로 업데이트하거나 변환하기 어려운 그림 등이 포함돼 있다. 시스템 레벨 작업을 위한 보다 정교한 툴이 있긴 하지만 나머지 개발 플로우와 통합시킬 수 있는 툴은 거의 전무한 실정이다. 따라서 엔지니어는 수작업으로 정보를 기존 툴에 재입력해야 한다. 수동으로 번역해야 할 데이터의 양과 복잡성으로 인해 오류 발생 가능성이 높은 것은 당연하다.

새로운 모델링 언어를 찾아서
1990년대 말, Verilog가 하드웨어 모델링 언어로 널리 사용되면서 디자이너는 시스템 레벨 구성을 모델링하기에는 Verilog의 기능이 너무 취약하다는 사실을 깨닫기 시작했다. 일부 EDA 벤더가 이 문제의 해법을 찾기 위해 노력했다. 물론 대부분 신생 벤더였다. 당시 주요 난관은 하드웨어와 소프트웨어 구현 간의 상반관계(trade-off)와 하드웨어 엔지니어와 소프트웨어 개발자 간의 의사 소통을 향상시키기 위한 설계 방법의 지원이었다. 1999년 9월, 약 50개 업체의 지원을 받아 OSCI(Open SystemC Initiative)가 구성되었다. OSCI의 1차 목표는 시스템 레벨의 지적 재산권 관련 제품의 교류와 C++ 모델링 플랫폼을 통한 하드웨어/소프트웨어 동시 설계를 촉진시키는 것이었다. C++를 기본 언어로 채택했던 이유는 C와 C++가 칩 디자이너와 소프트웨어 엔지니어가 주로 사용하는 언어였기 때문이다.

지금은 Synopsys의 일부가 된 Co-Design Automation은 하드웨어 디자이너들 사이에서의 선호도를 고려해 Verilog를 시스템 레벨 모델링 언어 개발의 시발점으로 보았다. Synopsys는 ‘1999년 설계 자동화 컨퍼런스(1999 Design Automation Conference)’에서 새로운 언어인 Superlog를 발표했다. 이름에서 알 수 있듯이, Superlog는 Verilog의 초집합이다. 2002년 6월 Accellera는 SystemVerilog라는 새로운 언어의 3.0 버전을 발표했다. Co-Design은 Accellera 위원회와 손 잡고 Verilog의 기능을 확장했다. Synopsys는 Co-Design을 합병한 후, 더 많은 Superlog 사양을 Accellera에 공여했다. 표준을 제정하는 컨소시엄인 Accellera는 현재 SystemVerilog 버전 3.1을 발표한 상태이다.

2001년 Verilog 재표준화 이후, Verilog 연구 그룹은 새 버전이 시스템 레벨 모델링 요구 사항에 부응하지 못하므로 새로운 버전을 내놓아야 한다는 판단을 내렸다. 이 그룹은 IEEE의 후원 하에 연구를 수행하고 있으며 프로젝트 승인 요구서(PAR) 번호는 1364이다. SystemC, Verilog, SystemVerilog는 지난 12개월 동안 언론의 지대한 관심을 받았는데, 이들 언어의 특성과 개발 상태는 면밀히 지켜볼 만한 가치가 있다. 또한 IEEE도 PAR 번호 1076의 VHDL-200X라는 프로젝트에서 VHDL의 새 버전 개발 작업을 진행 중이다(사이드바 기사 "'시스템이라는 별칭이 필요 없는 VHDL” 참조).

그러나 안타깝게도 VHDL-200x 연구 그룹은 하드웨어 모델링에 있어 SystemVerilog의 대안 개발에 열중하고 있는 것 같다. 이 접근 방식의 문제점은 VHDL이 결코 Verilog나 SystemVerilog의 훌륭한 대안이 될 수 없다는 사실에 있다. VHDL은 구문과 의미론이 훨씬 풍부하므로 전자 공학 하드웨어 뿐만 아니라, 이종 시스템 모델링에 더 적합하다. 실제로 칩과 멀티칩 기반 시스템이나 멀티보드 시스템은 하드웨어, 소프트웨어, 기계 시스템의 동시 모델링이 필요하다. 이 작업에는 VHDL이 가장 적합하고 연구 그룹도 이를 따라야 한다. 표 1에는 기존의 언어와 새로 제안된 언어를 통틀어 다양한 모델링 언어의 주목할 만한 사양들이 요약돼 있다.

SystemC
OSCI는 SystemC 개발의 지침이 되는 5가지 요건을 명시했다. 이 요건에 따르면 SystemC는 하드웨어/소프트웨어로 구현해야 하는 시스템 기능에 관한 고차원 기술을 지원하고, 시스템 설계자가 하드웨어/소프트웨어 분할 결정을 최대한 연기할 수 있도록 허용하며, 시스템 표현을 하恙�佇?구현하는 방법을 제공하고, 최첨단 시스템의 복잡성을 관리하는 메커니즘을 제공해야 한다.

SystemC는 새로운 클래스를 가진 C++이다. 주요 이점으로는 언어로서의 발전 수준과 퍼블릭 도메인(public-domain) 상태를 꼽을 수 있다. 디자이너가 실시간 운영 체제 개발을 비롯한 다양한 애플리케이션에C++를 사용해 왔기 때문에 C++는 강력한 언어라 할 수 있다. 또한 퍼블릭 도메인(public-domain) 상태로 인해 비용이 아주 저렴하지만, EDA 벤더는 이미 형성된 거대한 잠재 고객층에 독자적인 툴을 제공함으로써 수익을 창출할 수 있다. C++는 소프트웨어 개발 툴이기 때문에 의미론(semantics)이 하드웨어 모델링 기능을 지원하지 않는다. OSCI는 개발자가 클래스를 작성하여 언어 확장을 정의할 수 있는 C++의 기능을 사용해 이 문제를 해결했다. 클래스를 정의할 때 엔지니어는 구문과 런타임 의미론을 모두 명시할 수 있다.

일반적으로 새로운 의미론은 기존의 의미론적 정의가 오버로드(overload)되는 방식으로 정의된다. 오버로드란 C++ 언어의 로컬 영역 내에서 규칙을 재정의하는 것을 뜻하는데, 이 경우는 SystemC 클래스 라이브러리를 일컫는다. 디자이너가 라이브러리에서 정의한 변수와 프리미티브를 사용하면 새로운 규칙이 효력을 발생한다. 다른 곳에서 정의한 변수와 프리미티브를 사용하면 원래의 C++ 규칙이 효력을 발휘한다. 새로운 런타임 의미론을 정의하면, C++ 컴파일러가 생성한 이진 문자열을 이해하는 프로그램이 실행 가능한 새 코드를 컴파일러가 생성한다. 그러면 클래스 정의에 있는 추가적인 정보를 통해 C++ 런타임 기능을 확장하여 SystemC 시뮬레이터를 개발할 수 있다. OSCI는 시간, 동시성, 하드웨어 데이터 형식이라는 세 가지 기본적인 개념을 C++에 추가해야 했다.

소프트웨어 프로그래밍 언어는 프로그램을 실행하는 하드웨어가 실행 타이밍을 정하므로 시간을 이해할 필요가 없다. 하지만 하드웨어를 모델링해야 할 경우, 시간 지연과 실행 시퀀스를 모델링할 수 있어야 한다. 어떤 하드웨어 모델이 다음에 실행되어야 하고 한 하드웨어 프리미티브에서 다음 프리미티브로 신호가 전파되는 데 시간이 얼마나 걸리는지 시뮬레이터에 제시할 수 있어야 한다. 소프트웨어 프로그래밍 언어가 병렬 실행(parallel execution) 개념을 지원하긴 하지만 동시성은 이해하지 못한다. 병렬 실행이란 결합도가 약한 하드웨어 시스템이 독립적으로 둘 이상의 명령 스트림을 실행하는 것을 뜻한다. 보통 세마포어 프리미티브(semaphore primitive)를 사용하여 이런 병렬 실행을 동기화하는데, 세마포어 프리미티브는 의도한 알고리즘이 제대로 실행되는지 감시하는 글로벌 상태 시스템 역할을 한다.

하드웨어 동시성(concurrency)이란 일단 전원을 켜면 모든 하드웨어가 동시에 작동하는 것을 의미한다. 그래서 시뮬레이터는 원래부터 동시적이지 않은 명령 시퀀스를 처리하는 컴퓨터에서 실행되는 동안 동시성을 흉내내야 한다. C++의 기본 데이터 형식은 하드웨어 모델링에 부적합하다. 예를 들어, 3상 논리값을 기술하는 데 사용할 수 있는 데이터 형식이 존재하지 않는다. SystemC는 네 가지 값의 논리 시스템을 C++에 추가하여 디지털 논리 모델링을 가능하게 했다. 하지만 아직 디지털 논리와 아날로그 논리 간의 상호 작용과 아날로그 모듈의 구성 검사는 지원하지 않는다. 가장 최신 버전은 SystemC 버전 2.0.1로 알려져 있다.

• 검증 과정에서 유지해야 하는 특성 정의(어서션)
  
• 검증 과정에서 테스트해야 하는 기능 정의(기능적인 대상 범위)
  
• 입력 제한, 올바른 시퀀스, 올바른 시퀀스 조합 명시(자극 생성)

• 여러 추상화 단계에서 그리고 한 설계에서 다른 설계로 재사용할 수 있는 테스트벤치(검증 인프라) 작성
  
• 검증 과정에서 참조 모델로 사용되는 수준 높은 모델 작성
  
• 트랜잭션과 스코어보드 같은 공통적인 검증 데이터 구조 모델

• 동적 프로세스 생성/소멸
  
• 속성을 사용하여 자극 생성을 유도하기 위한 중량 조합을 명시하는 기능
  
• 테스트벤치의 기능 대상 범위의 데이터 액세스로 반응성 테스트벤치 작성 허용
  
• 테스트벤치로 설계 회로 어디서나 신호를 검사하고 실행할 수 있는 표준화된 신호 액세스 기능
  
• FIFO와 연관 배열(associative array) 같이 사전에 정의되어 공통으로 사용하는 검사기와 데이터 형식 라이브러리
  
• 보다 추상적인 프로세스 간의 통신 메커니즘

다음번 언어 개정 버전을 SystemVHDL이라고 부르지는 않지만 개정안은 설계 품질과 검증 생산성을 개선할 속성-사양과 검증 자동화 기능 뿐만 아니라, 보다 수준 높은 모델링과 추상화 기능을 제공할 것이다.

표1-언어 사양



저자

Stephen Bailey는 Mentor Graphics의 기술 마케팅 엔지니어이자 IEEE 1076 워킹 그룹의 회장이다.

요약 내용

• 모델링 언어는 전자 시스템 레벨 설계에 사용하기에는 부족한 면이 많다.· SystemC, SystemVerilog, Verilog 2005는 많은 공통적인 사양을 갖고 있다.
  
• 연구 그룹에서는 SystemVerilog과 Verilog 2005를 단일 언어로 병합하려 한다.
  
• 연구 그룹은 또한 VHDL에 사양을 추가하고 있다.

이 포스팅은 리퍼러 로그에 남은 검색어를 통하여 살펴본, 제 블로그에 방문하시는 분들이 관심을 가지는 것에 대한 친절(?)한 답변들입니다. ^^;

verilog 관련
가장 많은 검색어는 verilog/VHDL 입니다. 요즘에 이걸로 수업받으시는 분들이 많고, 요즘이 term project 철이라서 검색 순위가 급증하고 있는 것이 아닌가 생각합니다.

* Verilog와 VHDL중에 어떤것이 더 좋은가..
둘 다 좋은 언어입니다. verilog가 "설계"라는 목적에 좀더 부합하고, VHDL이 "검증"에 더 편리한 기능을 제공합니다. 개인적으로 생각하기에 verilog가 설계만 따진다면 더 편하다고 생각합니다.

* VHDL -> verilog변환, verilog ->VHDL 변환
가끔 뉴스 그룹에서 이거 변환 프로그램 찾으시는 분들도 봤는데, vhdl2v 같은 전용 변환 프로그램이 있기는 합니다만, 시도해보시면 상당한 스트레스를 받을 것이라 생각합니다.  ESNUG에 나온 내용을 붙이자면, 잘 안된다! 입니다.

ESNUG내용보기

http://www.deepchip.com/items/0386-11.html
Hello John,

I'm scrambling my head over this...

I am using VHDL-2-Verilog translator by ASC.  I could not translate my
functions from VHDL to Verilog -- they are simply skipped!

My VHDL source code has a package which has some function declarations
(eg. calculate_lrc(data)) and definitions in it.  The problem is when I try
to convert the package or code from VHDL to Verilog, the functions are
skipped.  So the verilog file just has constants and no "function", as if
there was no function declaration in the original file.

I tried using -Function_Map option but it would only allow me to keep the
original function call but the parameters are skipped.  Also no function
conversions.

So does ASC's vhdl2v not support function and procedure conversions from
VHDL to Verilog?

  - Rakesh Mehta
     Nortel Networks

대안으로는 verilog나 vhdl이나 동일한 중간 포맷으로 해석해서 사용하는 툴을 쓰는 건데..
제가 사용해본 것은 Summit design의 visual HDL로 변환하는 것이었는데, 역시 structural 설계는 잘되는데 약간 behavioral하게 설계된건 잘 안되었습니다.

만일 동작만 보면되고, 안의 내용은 필요없다! 라고 생각하신다면, synopsys에서 합성한 후에 원하는 format으로 netlist를 출력해서 시뮬레이션에 사용하는 것이 제일 속편합니다. 물론, simulation용 라이브러리를 물어야 하지만 말입니다.
(뭐, 요즘엔 ncsim이나 modelsim이나 모두 VHDL/Verilog를 single kernel에서 시뮬레이트해서 이런 필요는 없겠지만.. 라이센스 문제가 아닌 이상엔 말이죠..)

* verilog에서의 #
위의 문법은 원하는 만큼 지연을 발생시키는 것입니다. 합성시에는 무시됩니다.

* verilog에서의 <=과 = 의 차이
blocking assignment와 non-blocking assignment를 혼동하시는 분들이 생각보다 많은데요..(저도 verilog 처음에 잘 몰랐습니다.) blocking assignment는 "시간이 흐르지 않는 상태(흐르지 않게 block하면서)에서 값이 저장된다"이구요.. non-blocking assignment는 "시간이 흐르면서 값이 저장된다" 입니다.
즉, 아래와 같은 연속된 assign의 경우 위의 blocking을 사용하였을때 d는 a의 값을 가지게 됩니다. 값의 할당 자체에 시간이 소모되지 않도록 하나의 할당이 끝날때까지 시간을 멈추기 때문입니다...
그런데, 밑의 nonblocking 예에서는 "값을 할당하자"라는 것은 현 시점에서, 값이 갱신되는 것은 delta delay이후에 이루어지게 됩니다. 왜냐하면, 값이 할당되든 안되든 값을 할당하겠다는 3개의 문장을 모두 보고나서 delta delay이후에 값이 갱신되기 때문이죠.

이해 되시려나요?

* verilog PLI 관련
예전에 계속쓰려다 잠시 중단되었는데, PLI 관련 내용은 요즘에 제 작업 관계로 앞으로 1~2개월동안 자주 올라올 확률이 높습니다. 테스트 벤치 생성 유닛과 scoreboard를 C로 만들고 이걸 verilog PLI로 연결할 예정이거든요..
기대하셔도 좋을듯..


다른 검색을 통한 리퍼러 로그..
Design Compiler와 VCS, Modelsim에 대한 검색이 많았습니다.
사실, 툴에 대해서는 소개나, 새소식만 하고 있어서 별다른 내용이 없었는데 말이죠.. ^^;
참.. 시뮬레이션 하는 방법은 quick reference guide를 살펴보시면 쉽게 하실 수 있습니다. ^^;

프로세서에 대한 검색으로 들어오신 분들도 많았습니다. intel, AMD, ARM, calmRISC, M-Core, EISC(감사합니다.)
블로그에 좀더 프로세서에 관련된 좋은 내용을 적을까 싶기도 한데.. 이쪽 분야 하시는 분이 워낙 적어서 누가 관심이 있을까.. 라는 씨니컬한 마음이 될때도 있습니다. ^^;

아.. 특이한것이 virtual UART를 검색해서 들어오신 분이 계시던데..
제가 이 블로그에서 PLI + TCL/TK를 조합한 virtual UART라는 걸 만든적이 있다고 말씀을 드린적이 있는데, 검색해서 들어오신분은 아마 회사분이 아니실까 생각합니다. 회사분이시라면 인트라넷에 올라간 virtual UART 관련 메뉴얼을 참조하세요.. 소스코드와 작성법이 다 있으니까요..^^;

<출처 : http://babyworm.net/tatter>

verilog가 큰 수에 작은수를 대입할때 '0'으로 채우는 것으로 알고 있어.

module tilde (output reg[7:0] z, input [3:0] a);
    always @* begin
      z = ~a;
    end
endmodule

위의 예에서도 상위 4비트는 '0'이 되어야 겠지? 하위 4비트는 당연히 a의 반전이겠지만 말야.. 근데, 적어도 modelsim에서는 상위 4비트가 항상 1이 된다! 내가 잘못 이해한거야? 아님 모델심 문제야?

여기에 대해서 여러가지 대답들이 있는데.. 대답을 보기전에 우선 몇가지 정리해 보시지요..^^;
기본적으로 큰 값에 대한 assign시에 RHS의 값이 LHS값보다 작은 경우 그 값은 확장되면서 상위값은 '0'으로 채워집니다. 왜냐하면 verilog에서 기본적으로 다루어지는 수치형은 'unsigned'이기 때문이죠.
verilog 2001에서는 signed라는 예약어가 들어가서 signed 수로 인식되기도 합니다만, 위의 예에서는 관련이 없겠지요?

질문자는 assign 동작이 ~(inversion)보다 늦게 일어나므로, inversion 이후에 assign이 일어나야 하며, assign과정에서 확장 동작이 일어나야 하는데, 왜 동작은 inversion이전에 크기 확장이 일어난것 같이 동작하느냐는 것이 가장 중요한 질문의 요지입니다.

그런데, 위의 예에서는 왜 '1'로 채워지는 것일까요? 이것은 verilog에서 연산을 처리하는 rule과 관계가 있습니다.
이 문제에 대하여 지존급의 대답을 해준 케이던스의 sharp님의 글을 보면 아주 명확히 설명하고 있습니다.

Verilog first determines the width of an expression based on the largest operand in it, including the LHS of any assignment.  Then it extends all operands (actually, all context-determined operands) to the width of their expression before performing any operations.  All extensions are done as early as possible, in an attempt to avoid overflows in intermediate results.

가장 중요한 verilog 연산에서의 크기 확장 법칙이 위의 법칙입니다. 즉, 연산 이전에 LHS를 포함한 모든 연산 요소를 살펴보아서 가장 큰 값에 맞추어 값을 확장하는 것입니다. 이는 "C"언어에서의 type casting rule과 완전히 다르기 때문에 많은 분들이 헷깔리게 되는 것이지요.

sharp님이 추가적으로 설명한 부분은 사실 저도 정확히는 모르고 있던 부분인데.. (경험으로는 알고 있었습니다만, 명확한 이론은 없었습니다.) 연산에 따른 확장에 대해서 알려주고 있습니다.

When the result of an operation will have a fixed width regardless of the width of its operand, there is no reason for the operand to care about the width of the context.  This is true of the reduction operators.  The result will always be 1 bit, no matter what the operand width is.  There is no point in extending the operand.  Instead, the 1-bit result will be extended to the width of the expression as soon as it is produced.  The operand of a reduction operator is
self-determined.
On the other hand, all the bits of a bitwise NOT will be available to the expression containing it, and may be assigned or used in another bitwise operation.  So the operand of a bitwise NOT is context-determined.

But one has a self-determined operand and the other has a context-determined operand.  The Verilog LRM fully specifies this for all the operands of all the operators.  They generally follow a logical scheme that makes sense.  And again, in most cases they are designed to give reasonable results, so that most users don't have to worry about them.

상당히 어려운 이야기인 것으로 보입니다만, 실은 같은 width를 보장해야 하는 연산과 그렇지 않은 연산이 있고, 이에 따라 확장을 하는 부분이 있다.. 라고 요약하시면 되겠습니다. 위의 룰은 처음 설명 드린 룰의 보충내용이므로 그리 중요하지는 않습니다.

이러한 문제는 "고민을 시작하면" 엄청나게 신경쓰이는 문제이므로, 일반적인 coding style을 따져서 문제가 될만한 부분을 초기에 잡아나가는 것이 현명하겠습니다.
즉, 1) verilog coding시에서 width 지정을 정확히 하고, 확장이 필요한 경우 명시적으로 concat operation을 쓰자. 2)일반적으로 width를 지정하지 않은 상수는 verilog에서 32bit으로 처리되므로, 이로 인해 원하지 않는 동작을 피하고 싶으시다면, 항상 상수를 지정할때 width를 지정하는 하자.
이런 일반 룰만 지키신다면 머리 아플일이 없겠지요..^^;

좋은 Coding Style의 존재 이유가 "불명확한 코드로 나중에 머리 아프지 말고 코딩 부터 잘하자.."이런 것이니까요..^^;


추가적으로..
comp.lang.verilog에 인터뷰에서 asynchonous설계시 주의할점에 대해서 물어봤는데.. 대답을 못했다는 내용도 있네요.^^; 얼마전에 이야기한 metastable에 대한 이야기를 묻는 것이지요.. 정말 많이 물어보는 질문이기는 한가보군요..

<출처 : http://babyworm.net/tatter>