Category Archives: SoC & IP design

Design Compiler의 TNS, WNS..

오늘은 지난번 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을 맞추지 못하는 것입니다.
따라서, 코드를 바꾸던, 툴이 더 힘을 낼수 있도록 스크립트를 작성하던..더 열심히 최적화를 해봐겠죠.

”]

TNS와 WNS
그럼 오늘의 주제인 TNS와 WNS는 무엇일까요?
TNS는 total negative slack이라해서, negative slack의 합입니다. 즉, 설계의 모든 net에서 발생한 negative slack을 더한 값이죠. 전반적으로 설계가 어떻다.. 를 의미합니다.
WNS는 worst negative slack이라해서, negative slack중에 가장 나쁜 값 하나를 이야기합니다.

이 값들이 어떤 의미를 가지냐 하면, WNS는 나쁘지만 TNS는 그리 나쁘지 않은 경우, WNS만 최적화하면 되기 때문에 front-end에서건, back-end에서건 그 path가 잡힐 확률이 아주 높습니다.
반대로 WNS는 별로 나쁘지 않지만 TNS가 매우 나쁜 경우, 설계상의 대부분의 path가 worst case에 몰려 있는 상태이므로, 더 이상 최적화와 P&R을 열심히 돌려도 별로 좋아지기 힘들다고 보시면 됩니다.

WNS와 TNS의 처리
Synopsys DesignCompiler에서 delay를 최적화 시키는 방법은 기본적으로 Worst Negative Slack(WNS)를 하나씩 줄여나가는 방법에 기반을 둡니다.

즉, 로직을 mapping시키고, negative slack이 발생한 net들을 주욱~ 나열한 후, 그중에 가장 나쁜 넘(WNS)에 해당하는 net을 최적화하고,
다시 negative slack net을 주욱~ 나열하고, 또 WNS를 최적화하고.. 이런식의 반복입니다.
단, WNS를 줄이면서 TNS가 늘어나면 안되게 하고 있습니다. 즉, 합성 과정에서 WNS를 줄일 수 있더라도 TNS가 늘어나는 경우라면 synopsys에서 받아들이지 않습니다.

Synopsys의 기본적인 합성 방법이 이해되시나요?

TNS도 같이 줄이기

위의 설명에서 synopsys에서 기본적으로 사용하는 WNS기반의 최적화를 보여드렸는데, 이 경우 전반적인 path가 WNS근처에 몰려 있을 확률이 아주 높습니다. (design_vision이나 primetime에서 histogram으로 확인하실 수 있습니다.)
즉, 이 말은 앞에 설명하였듯이 나중에 P&R이 아주 귀찮아 진다는 거죠..
그래서, TNS를 좀더 빡~시게 고려할 수 있는데.. 이것이 바로 오늘 이야기 하려하는 critical_range에 대한  이야기입니다. 우선 문법.

이 명령은 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에 따른 고민을 적게 하는 것이 좋겠습니다. ^^;

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

EISC 관련 기사 하나.. TMA2560-RFID/USN용 센서 노드 칩

제가 설계한 건 아니고, 회사의 simple 32비트 [wp]EISC[/wp]가 들어간 칩인데.. ETRI와 다목적 [wp]RFID[/wp]/USN 과 같은 [wp]wireless sensor network[/wp]의 node및 bridge용으로 만들고 있는 칩입니다.  
뭐, 사실상 직접적인 target은 센서 노드쪽에서 가장 많이 사용되는 ATMEGA128L을 노리고 있는 칩이지요.
최종적으로는 RF 부분과 통합 설계가 될 예정인데, 그중에 1차 버젼입니다.

이거 담당하고 있는 분은 처음에 이 칩 나왔을때 테스트때문에서 회사에서 매일 매일 죽을려고 했었습니다.  ^^;

Digital과 analog가 섞이는 것도 섞이는 것이고, design house도 좀 말썽이고.. 여러가지 머리 아픈 부분이 있어서 말이죠.. 특히 이 칩같은 경우 저전력 하려고 클럭은 기본이고 파워마져 끊고, main die이외에 EEPROM die와 Flash die를 MCP해 놓아서 테스트가 어려워서 정말 고생했지요..

그래도, 이제 동작하고 신문기사까지 나왔으니 고생한 보람이 있네요…^^;
차선임! 수고하셨소~

[#M_기사보기|less..|
[전자 엔지니어에서 퍼왔습니다.]
ETRI(한국전자통신연구원)는 USN용 고성능 제어장치(MCU) 칩 개발에 성공했다고 6일 밝혔다. USN용 고성능 제어장치(MCU) 칩

이 칩은 기존의 8비트 프로세서 칩 성능을 32비트로 4배 개선시켰고 메모리도 기존 128KB 수준을 256KB 수준으로 2배 업그레이드 한 것이며 어플리케이션도 다양한 응용분야에서 사용가능 하다고 ETRI는 말했다. 또한 이번 개발을 계기로 USN관련 연구개발에 탄력이 붙을 것으로 전망했다.

기존의 USN 센서노드는 일상생활에서 흔히 볼 수 있는 온도, 습도의 증감, 화재발생 여부 등 단순신호만을 감지하여 전달 처리할 수밖에 없었지만, 이번에 ETRI가 개발한 칩을 센서노드에 적용시키면 영상정보 전달 및 음성신호 감지 처리까지도 가능하다. 이에 따라 복잡한 센싱 데이터를 센서노드에서 가공 처리하여 전달할 수 있어 다양한 USN 응용서비스 제공이 가능한 게 특징이다.

즉, 응급상황시 비명을 지르면 주변의 센서가 이를 인식, 센서노드에 정보를 전달해 도움을 청할 수 있고 또는 CCTV의 음영지역에서 센서노드의 설치로 위험신호가 감지되면(호루라기(Whistle)를 불면) 가까운 경찰서에 알려줄 수도 있어 ‘안전귀가 서비스’ 등에도 유용하게 활용될 수 있다.

ETRI는 정보통신부 “RFID/USN용 센서태그 및 센서노드 기술개발” 사업을 통해 에이디칩스와 공동으로 “USN용 고성능 32비트 MCU TMA2560”을 개발하는데 성공했으며, 상용화 시점은 2007년 하반기로 전망했다.

아울러 내년에는 개발된 프로세서와 통신기능 칩을 하나의 칩으로 즉, SoC(System-on- Chip)화 할 계획이여서 통합 칩의 크기 또한 계속 줄게 될 것이다고 밝혔다.

ETRI는 11월 7일부터 코엑스에서 개최되는 ‘RFID/USN KOREA 2006’ 국제 전시회 및 컨퍼런스에 TMA2560 및 본 칩을 이용한 위험감지인식과 산업현장 감시제어 응용 서비스를 옥타컴과 태광이엔시와 공동으로 각각 시연해 보일 예정이다.

_M#]

Verilog newsgroup에서의 몇가지 이야기

verilog news group에는 여러가지 verilog 관련 이야기가 나오는데.. 몇가지만 옮겨 봅니다.

1. Implicit Zero Padding?
verilog의 bit 확장에 대한 부분인데요.. 간략히 써보면 다음과 같은 질문입니다.

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

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

위의 예에서도 상위 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에 대한 이야기를 묻는 것이지요.. 정말 많이 물어보는 질문이기는 한가보군요..