Solvnet newsletter으로 보내진 reference script를 보다보니, 세상이 많이 바뀌긴 한거 같습니다. ^^;

Doony님께서도 블로그에 쓰셨습니다만, 저희도 Synopsys의 Design Compiler에 대한 의존도가 높다보니, Reference Methdology에 대하여 관심을 가지지 않을 수 없지요.

Design Compiler를 여러가지 버젼을 혼용하는 환경에서는 하나의 스크립트로 통합하여 사용하는데 어려움을 겪을 수도 있는데요.. (음.. 실제적으로 한 회사내에서 혼용하는 경우는 적겠지만, 저희 같은 경우는 IP 제공이 주된 업무이다보니, 버전을 적게 타는 스크립트를 주로 생각하게 되죠..)

이때는 compatibility_verion 이라는 synopsys의 내부 변수를 살펴보면 되죠. (printvar compatibility_verion 하면 현재 구동중인 버전을 알수 있어요. ) 근데 예전에는 이 버전의 형식의 그냥 숫자라서 여러 연산이 가능했는데, 이제는 Y니 A니 SP니 이런 영문자가 들어가서 좀 따지기 귀찮죠.. (여기에 대해서는 밑에)

이 변수를 어떻게 쓰느냐하면, 버전에 따라 지원하는 명령을 바꿀수 있도록 지원하는 거죠.
예를 들어 shell_is_in_upf_mode나 shell_is_in_xg_mode, shell_is_in_topographical_mode와 같은 환경에 대한 명령은 synopsys version이 올라가면서 추가된 것이라 예전 버젼에서 돌리면 에러가 발생합니다. 뭐, 덤덤히 그냥 지우고 돌리세요 해도 되지만 ^^;

이런 경우에는 다음과 같이 버젼 체크를 통해 간단히 벗어날 수 있지요.. 음.. 더 좋은 방법이 있을수도 있지만, 제가 잘 모르는 관계로.. ㅋㅋ

if {[string match {*2007*} $compatibility_version]} {
  set DC_SUPPORT_UCF        "true"
  set DC_SUPPORT_TOPO_MODE  "true"

} else if {[string match {*2006*} $compatibility_version]} {
  set DC_SUPPORT_UCF        "false"
  set DC_SUPPORT_TOPO_MODE  "true"
} else {
  set DC_SUPPORT_UCF        "false"
  set DC_SUPPORT_TOPO_MODE  "false"
}

if { $DC_SUPPORT_TOPO_MODE == "true" } {
  if {[shell_is_in_topographical_mode]} {
   ...

  }

}

Design Compiler에서 TCL을 지원하면서 여러가지 편해졌습니다. file system 조작도 file 명령어를 쓰면 되고, 문자 대치하는 것도 훨씬 쉬워지고요.. ㅎㅎ

여담입니다만, 텍스트 큐브로 업그레이드하면서, 소스 하이라이팅 기능과 박스 넣기가 좀 이상해져서, 이쁜 모양으로 소스코드 보여드리기가 상당히 힘드네요.. 집에서 컴퓨터 만질 시간이 생기면  한번 손을 봐야 겠습니다.

지난 DAC07 best selling book에서 1위를 차지한 Low Power Methodology Manual(이하 LPMM)이 synopsys를 통하여 무료 배포되고 있습니다.
단, Solvnet에 등록 아이디를 가지신 Synopsys 고객분들에 한하여 배포되면, Printing이나 Copy등이 불가능한 버전입니다.
게다가, 각 파일마다 personalized(어떻게 했는지는 모르겠습니다만)되어 있어서, 배포하면 걸린다더군요.

아이디를 가지신 분들은 다음 링크에서 받으시기 바랍니다. http://www.synopsys.com/lpmm 입니다.

등록은:  http://www.synopsys.com/news/events/sem ··· sem.html




≫ Primary Multi Track Agenda

Track A1 Abstract
Introduction to SystemVerilog testbench with the VMM Methodology
- Making the move from directed tests to constrained-random verification
- SystemVerilog testbench basics
- Strategies for adopting SystemVerilog testbench and the Verification Methodology Manual (VMM)

Debug and Analysis with DVE
- An overview of DVE (Discovery Visualization Environment)
- Using DVE for assertion, testbench and SystemC debug
- Using DVE with analog simulatioins

Track A2 Abstract
Formal Verification with Megellan
- Making the move from directed tests to constrained-random verification
- SystemVerilog testbench basics
- Strategies for adopting SystemVerilog testbench and the Verification Methodology Manual (VMM)

Verification of Low Power Designs
- An overview of DVE (Discovery Visualization Environment)
- Using DVE for assertion, testbench and SystemC debug
- Using DVE with analog simulatioins

Track B1 Abstract
Introduction to VMM Applications
- Register modeling and verification
- Block-to-system reuse and memory allocation techniques
- Data stream scoreboarding

Using Verification IP in a VMM Environment
- Using transaction-level SystemC models in a SystemVerilog environment
- Transaction-level Interface techniques in VCS
- Debugging mixed-abstraction, mixed-language environments in DVE

Track B2 Abstract
SystemC and SystemVerilog Design Verification with VCS
- Using transaction-level SystemC models in a SystemVerilog environment
- Transaction-level Interface techniques in VCS
- Debugging mixed-abstraction, mixed-language environments in DVE

Accelerating Verification using the VMM Hardware Abstraction Layer with ZeBu
- Introduction to hardware-assisted acceleration with the EVE ZeBu platform
- Using the VMM HAL to reuse a common testbench for simulation and acceleration
- Implementing acceleration-friendly checkers, monitors and data generators

Track C1 Abstract
Verifying Performance and Reliability of Nanometer Designs with HSIMplus
- Solutions for post-layout analysis with millions of extracted RC parasitics
- Verifying performance and reliability for IR drop effects and electromigration

Mixed-Signal Verification (MSV) challenges and solutions
- Bottom-up, mixed-signal Verification w/ Verilog, VHDL, & SPICE
- Mixed-language / Mixed-level simulation top down design and verification
- Transistor-level sign-off: why is this important?

Track C2 Abstract
Advanced high-accuracy circuit simulation with HSPICE
- Performing faster simulations
- Ensuring silicon accuracy with advanced models
- Improving productivity with behavioral modeling
- Employing high-speed signal integrity analysis capabilities
- Simulating process variability effects
- Accurately predicting PLL and VCO performance

Verilog HDL이 대세다!

이 이야기는 제 Blog전반에 걸쳐서 몇번 이야기 했었습니다. HDL을 배우고 사용하는데 있어서 Verilog HDL이 대세라는 것이지요. John Cooley는 VHDL을 고수하는 업체는 미군과 계약하고 일하는 업체나 일부 유럽 회사밖에는 없다고 이야기합니다. (VHDL을 미국방부에서 만들었으니 아직도 이쪽에 납품하려면 써야 하나봅니다.)

VHDL만 사용하는 사용자의 비율은 불과 4.0%에 불과하며, VHDL을 main으로 사용하는 사용자를 포함해도 전체의 20% 정도입니다.  Verilog사용자의 경우 VHDL을 사용하는 가장 큰 이유로 "기존에 있던 코드 때문에(legacy code)"라는 답변이 대부분입니다.

더욱 재미있는 것은 ^^; 이런 Mixed simulation을 사용할 때 사용하는 툴이 (이 응답에서는) 대부분 Modelsim이라는 점입니다. (modelsim이 주력 시뮬레이터는 아니구요.) Modelsim에게는 조금 위협적인 이야기가 되겠지요. 지금의 market share가 대부분 legacy code에 의한 것이라면 점차 legacy code의 사용이 줄어들면서 Modelsim의 입지도 줄어들 가능성이 있으니까요.

VCS의 약진!

전반적으로 functional 전 개인적으로 Simulator부분에 있어서 cadence design system의 NCsim series보다 Synopsys VCS series가 이 정도의 market share를 차지한다는 것에 놀라움을 느낍니다. 다시 한번 말씀드리듯이 DVCon은 functional verification engineer을 대상으로 하므로, 현재 상황이라기 보다 미래의 상황을 더 나타낸다고 보고 있으니, 더 놀라운 것입니다.

Linting과 Coverage는 Built-in?

저는 사실 Linter에 대해서 처음에는 상당히 호의적이었는데, 지금은 약간 갸웃~하는 입장인데요.
Linter라는 것이 문제가 발생할 부분을 코딩 스타일 점검 과정에서 미리 확인하는 툴은데요..유용하다는 데는 이견이 없습니다만, Simulator나 Synthesizer에서 "상당히 빠르게" 미리 문제를 확인할 수 있기 때문에 약간은 비관적입니다.

Code Coverage에 대해서는 가능성이 많다고 보는데, 문제는 현재 각 Simualtor에서 제공하는 기능이 일반적인 Code coverage기능(최소한 Line coverage정도는..)을 지원하고 있고, 어짜피 functional coverage는 assertion을 사용해야 할테니 강력한 code coverage를 요구하지 않는 다는 것이 문제겠지요. (아니, 실은 요구하는데 그 기능을 위하여 지갑을 열기가 쉽지 않은 것이겠습니다.)

여하튼..

결과를 보시면 알겠지만, SpyGlass가 아주 눈에 뜨입니다!
게다가 더욱 놀라운 것은 SpyGlass의 점유율이 2005년보다 약 8%나 증가했다는 것이죠.

또 하나 재미있는 것은 Leda사용자들이 Leda를 무지 싫어한다는 점입니다. 일단 Leda를 쓰지만 'Leda는 X같아서 못쓰겠고, 나중에는 SpyGlass를 쓰겠다'는 식으로요..

Waveform Viewer와 Environment는?

Waveform viewer는 실질적으로 Designer와 verification engineer들이 그야말로 끼고 사는 툴중의 하나인데요..(물론, verification enginner는 약간 덜 끼고 살죠..^^;)
대부분 Simulator에 번들링 되어온 툴을 많이들 사용합니다.

저같은 NCsim 사용자는 Simvision이나 Signal Scan을 사용하겠고, Modelsim 사용자는 Modelsim자체 툴을 사용하시겠고, Nanosim사용자는 Novas nWave가 번들링 되어 있으니 이넘을 사용하시겠죠.

그런데, 사실 요즘 세상에서는 파형만 보여주는 걸로는 부족합니다. 어떤 신호가 시점에서 unknown이 발생했으면, 어떤 신호에서부터 unknown이 타고 들어온건지 분석해주었음 좋겠고..
신호를 그래픽으로 따라 들어가 주었으면 좋겠고, 그 값이 어디서부터 바뀌어 들어온지도 알고 싶지요.

별거 아닌듯 한데, 이게 "생산력"을 아주 급격히 증가시켜줍니다!!
즉, 설계를 마치고 문제가 생기면 가장 시간이 오래 걸리는 부분이 파형보면서 문제를 파악하고 추적하는 건데, 이것을 편하게 해 주는 것은 정말 중요한 거죠.

밑에 표를 보시면 Novas의 툴들 Debussy/Verdi의 점유율이 아주 놀라운데요. 이런 맥락에서 이해하면 될 것 같습니다.
그래도, 제 생각으로는 simvision도 현재 상당히 강력해진 상황인데, 이 넘과 싸워서 사용자의 지갑을 열도록 만들수 있을 정도로 가치를 인정받았다는 의미이므로, 상당히 선전하고 있다는 거죠.
하긴 제 주변에도 Novas Debussy의 팬들이 몇 분 계시기는 하죠..^^;

EDA 업계 소식을 보다보면, '야~ 이 툴 정말 써보고 싶다'라는 생각을 해보곤 해요.
근데, 아시다시피 EDA 툴 한 카피의 가격도 가격이거니와.. EDA Tool의 Evaluation이라는 것이 회사 업무에 영향을 받기 때문에 회사 차원에서 evaluation하려면 여러 가지로 귀찮아요..

그래서, 그냥 개인적으로 evaluation 해 볼 수 있는 뭐 그런거 없나 싶기도 합니다. Technical Report정도를 작성하면서 말입니다. 외국의 경우에는 책이나 이런저런것에서 지원받는 경우를 보았습니다만, 사실 국내에서는 EDA 시장 자체의 규모가 작으니 불가능하겠지요. ^^;

오늘은 지난번 posting에 이어서 front-end 설계 엔지니어에게 있어서 주요 설계 도구중의 하나인 Design Compiler의 constraint 주는 방법에 대해서 Total negative slack과 Worst Negative slack의 관점에서 간략히 설명해 보겠습니다.

Design compiler는 잘 아시다시피 constraint 기반으로 optimization을 진행합니다.
즉, 설계를 어떤 방식으로 합성하여 최적화시키는지는 사용자가 해당 모듈에 대하여 원하는 목표치들.. 동작 주파수, 크기를 설정하면 그 값에 맞추어 합성 및 최적화을 진행하게 됩니다.

만일 constraint가 존재하지 않는 경우, 더 이상 최적화를 진행하지 않고 mapping으로 끝나게 되죠.

Slack?
모든 함성이 끝난 후 지정된 constraint 대비 합성 결과를 비교하여 slack을 나타내게 되는데, 아래 그림처럼 지정된 것보다 일찍 신호가 도착하면 positive slack이라 하지요. 이런 경우 설계자로서는 행복한 순간이니 바로 호프집으로 가서 뒷풀이하면 되겠습니다.

그 반대의 경우 negative slack이라 하는데, 지정한 constriant을 맞추지 못하는 것입니다.
따라서, 코드를 바꾸던, 툴이 더 힘을 낼수 있도록 스크립트를 작성하던..더 열심히 최적화를 해봐겠죠.

[slack의 이해- 출처는 잊었네요..]

이 명령은 WNS에서 critical range로 지정된 값 이내의 path에 대해서도 같이 optimization을 수행하도록 합니다.
이렇게 하면 DesignCompiler는

1) 우선 WNS를 줄이려 노력합니다.
2) WNS줄이기가 끝나면 critical range에 해당하는 path들을 줄이기 위해 노력합니다.

이 과정에서 WNS보다는 좋지만 여전히 neagtive slack을 발생시키는 net들에 대하여 더 합성을 하게 되는 것입니다. 따라서, 전반적으로 histogram을 보면 slack이 WNS쪽에 몰리지 않고 약간 더 뒤로 이동합니다.
이는 P&R과정에서 WNS를 해결할 가능성을 높이는 결과는 보여줍니다.


Back-End Tools로 hand-off하기..

지난번에 이야기한 것 처럼, 공정이 미세해지면서 front-end에서 wireload model을 사용하면 합성의 정확성이 떨어지고 P&R과정에서 여러가지로 힘들어집니다.
따라서, P&R을 좀더 쉽게 진행하려면 front-end에서 약간 더 빡세게 합성해줄 필요가 있습니다.
(물론, S사나 L사와 같이 back-end team에서 로직 수준까지 바꿔치기 해줄 수 있는 팀이 회사내에 존재한다면 뭐가 걱정이겠습니까? ^^; )

이때 흔히 사용하는 방법이 over constraint입니다.
즉, 타겟 주파수가 100MHz라면 110MHz에서 돌수 있도록 front-end에서는 합성하는 거죠..
(물론, back-end design house 잘못 만나면 10% 마진.. 어림도 없습니다..! orz)

over-constraint와 더불어 좋은 방법이 바로 TNS를 줄여서 전달하는 겁니다.
예를 들어 110MHz에서 sign-off할 것이라면 약 clock period를 8ns정도주고, critical_range를 1ns정도 주는 것이지요.

그럼, 툴은 좀더 노력하지만, 설계보다 constraint가 너무 심하게 들어가 있으니 WNS는 대략 -0.5이상이 발생할 거고.. TNS도 큰 값이 되어 있을 겁니다. 이때 critical range를 지정하면, 많은 path가 더 좋은 delay를 가지게 됩니다. (물론, sign-off시에는 110MHz로 STA해야겠죠?)

이렇게 보내면, P&R과정에서 WNS로 잡혔던 path에 대한 time-driven placement가 별 고민 없이 최적화를 시킬 수 있으므로, design house를 좀 잘못만나도 빠르게 timing closure를 이룰 수 있습니다.

결론적으로, 디자인 하우스를 잘 만나자! (농담입니다.^^;) critial_range를 이용하여 TNS 줄임으로, back-end에서 P&R에 따른 고민을 적게 하는 것이 좋겠습니다. ^^;

역시 뭐든 타이밍을 잘 맞춰야 합니다.

사실 logic synthesis에 있어서 synopsys design compiler가 가지고 있는 비중은 정말로 큽니다.

ASIC designer가 거치는 전체 설계 flow에서 logic synthesis는 어찌보면 implementation의 시작지점이기 때문에 아주 중요합니다.
거기서 만들어진 netlist의 질, 지정된 constraint들이 이후의 툴들에 얼마나 효과적으로 반영될 수 있는가.. 등등..

Synopsys가 design compiler라는 툴로, 이 logic synthesis를 잡아버리면서 (90%이상의 점유율이랍니다.. 완전 독점에 가깝지요..), 이 강력한 파급력으로 DFT, Floorplan, P&R까지 이전의 강자들을 무너트리고 있는 상태입니다.

물론, 다른 회사들도 이 황금어장을 그냥 놓아둘수 없었던지, cadence는 build gates라는 툴로, mentor는 percision으로, synplicity는 synplify AISC으로 대항하고 있지만.. 흠.. 안타깝게 아성은 무너지지 않고 있으며 오히려 더 견고해지고 있는 느낌입니다.

여하튼..

지난번에 synopsys의 topographical synthesis에 대하여 잠시 말씀드렸었는데..오늘 말하려 하는 것은 synopsys가 2004.06버젼부터 선보인(혹 틀릴수도 있어요..) XG 모드라는 것입니다.

처음에 XG모드는 memory를 더욱 효율적으로 사용하고, 더 빠르게 분석할 수 있도록 하자는 목적으로 기존의 DB형식을 대치하려 개발된 synopsys의 내부 표현 저장방식입니다.

저는 개인적으로 예전에 XG모드를 썼다가 크게 덴 적이 있습니다.
온갖 수사로 포장된 2004.06에서의 XG모드... SNUG에 tutorial로 설명된 것으로 보고 혹~ 해서 얼마간 썼었는데..DB모드에서는 정상적으로 합성되는 verilog HDL 소스들이.. 죽기도 하고, 운좋으면 합성되는데 netlist가 이상하기도 하고... 온갖 고생을 시겼었습니다.

그 이후 사실 쳐다보지도 않고 있지요..^^; (소심해서..)
새로 구입한 Design Compiler 2006.x 버젼은 실행시키면 바로 XG,TCL모드로 뜨는데, 일부러 db_mode로 띄워서 쓸 정도니까요..

그런데, 얼마전에 DFT compiler 교육에 교양삼아 참가했었는데, XG모드 이야기가 나오더군요..
뭐, 여러가지 "XG 좋네~ 쓰세요~" 이런류의 이야기 말미에.. "2007년부터 DB 모드는 없어집니다."

캬아악~! DB모드가 없어진다구? orz

XG 모드로 이전하기 위한 모든 정보가 있는 곳.

HDL을 이용해서 로직을 설계하고, 비메모리 반도체 만드는 사람들에게 있어서 필수 설계 도구(CAD)툴로는 synopsys의 design compiler를 들수 있겠습니다.

로직 합성 분야에서 약 90%이상의 점유율을 보이고 있는 것으로 조사(ESNUG에 따르면)되고 있으니, 거의 표준 설계 도구겠지요..

이 synopsys에서 오늘 miniDAC을 진행했습니다. babyworm은 이런 쇼를 좋아하는 편이라 올해도 빠지지 않고 갔지요. 시납시스에 있어서 가장 중요한 이슈는 이제 더이상 로직합성이 아닙니다 (가장 중요한 돈 벌이도구임에는 틀림없고, 여전히 중요합니다만..).
전체 설계 과정인 "HDL설계 및 시뮬레이션" -> "로직 합성" -> "auto P&R" 과정에서 중간에서 압도적인 점유율을 가지고 있고, 가장 중요한 과정을 잡고 있는 시납시스는 요즘 auto P&R부분에 상당한 신경을 쓰고 있습니다.
즉, HDL 설계 이후의 모든 과정을 점유하고자 하는 의욕을 보이고 있고, 그 성과는 아주 가시적으로 보입니다. auto P&R에서 한창 잘 나가던 apollo라는 툴을 가지고 있던 avant!사를 인수합병하면서, 새롭게 astro라는 툴을 내놓았고(사실 거의 apollo와 비슷했습니다.), 이제는 design compiler의 GUI인 design vision과 유사한 모양새를 가진 IC compiler를 주력으로 만들었으니까요.

시납시스에서 준 타거스 가방