Adobe의 Open Screen Project라는 것이 발표되었습니다. Flash가 최근의 RIA(Rich Internet Applications)에서 거의 표준처럼 사용되고 있지만, 상당한 연산량과 아도비의 약간의 폐쇠적인 라이센스 정책으로 인해서 모바일 기기에서는 SWF를 직접 재생하기 보다는 SWF를 다른 방법으로 conversion하여 재생하는 방법이 많이 채택되었었습니다.
이는 Adobe에서 각 device에 대하여 flash play를 최적화 할수 있는 방법을 제공하지 않았으며, 공개된 스펙에서도 decoder를 만드는 것은 라이센스 위반으로 정의해 두었기 때문에 벌어진 일이라 할 수 있겠습니다.
이번에 Open Screen Project에서 SWF와 FLV/F4V 스펙에 대하여 open하고 porting API를 공개하기로 한 것은 각 device에서 최적화 할 수 있는 기회를 제공함으로써, 모바일 기기에서의 flash 영향력을 높이고자 하는 의도를 엿볼 수 있습니다.
지난 Android에 이어서, Adobe의 open screen project 까지.. 새로운 바람이 부는 것이겠지요.
Category Archives: SoC & IP design
TLM으로 설계가 이동할 것인가? (II)
지난 글에 대하여 방명록에 문의를 주신 분이 계셔서 간단히 적어봅니다.
지난 글에서 Tansaction Level Modeling(이후 TLM)이라는 것이 각광받고 있었지만, 설계에 있어서는 그리 쉽지 않고 tool의 지원이 미비해서 검증 분야에서 잘 되고 있다고 말씀 드렸었습니다.
이 부분에 대하여 kal9님께서 NoC의 경우 TLM이 더 쉽지 않겠는지에 대한 문의가 있으셨습니다.
일단, TLM의 장점은 추상화 정도(level of abstraction)가 높기 때문에 동작을 모델링하기 쉽고, 시뮬레이션이 빠르다는 장점을 가지고 있습니다. 따라서, multi-million gate를 지니는 SoC의 설계가 필요한 시점에서 각광을 받은 것이지요.
그런데, 문제는 TLM이 H/W로 직접적인 mapping할 수 있는 방법이 존재하지 않는데 있습니다. 즉, Transaction level 에서 설계된 모델은 어느 순간 H/W를 만들기 위하여 RT level model화 되어야 하는데, 이는 설계자에게 있어서 이중 부담이 됩니다. (지난 글에서도 언급하였듯, 어느 순간 TL Model to RTL Model(이후 RTLM)이 가능한 synthesys툴이 만들어진다면 — 예전에 behaviroal synthesis 이론과 비슷하겠지요? — 모르겠습니다만..)
따라서, 현재로서는 SoC 전반의 설계를 위하여 혹은 이를 RTL 검증을 위하여 사용하는 경우가 많습니다. 물론, SoC에서 원하는 동작이나 bandwidth가 보장되는지는 확인하기 위하여 TLM을 사용하는 것이 결코 “별일도 아니다”라고 생각하지는 않습니다. 아주 중요한 일이지요. 하지만, SoC 설계 시에 대부분 이런 정량적인 분석 이외에도 educated guess와 추가적인 margin을 적용하는 경향이 두드러지므로(특히 SoC를 만들때 정량적인 측정을 수행한 이후에 향후 application을 위하여 margin을 항상 두는 것을 고려해 볼때..), TLM을 사용하여 정량 분석을 하는 것이 그리 의미가 있는지는 아직 미지수 입니다. 물론 margin을 고려하기 어렵고, 상당히 tight한 application이 돌아가는 SoC라면 아주 큰 의미가 있겠습니다만…
여하튼.. 이러한 이유로 인하여 TLM을 이용한 SoC설계가 학계에서 인정받는 것 만큼 회사에서 폭넓게 받아들여지지는 않고 있는 것으로 파악됩니다. TLM에서 RTLM으로의 자동화된 이전 방법이나, TLM과 RTLM간의 등가성을 확보할 수 있는 방법이 존재하지 않는 단계에서는 TLM에서 SoC검증이 되었다 하더라도, RTLM에서 다시 검증을 해야 하는 운명인 것이지요.
단지, TLM을 이용한 SoC modeling이 있는 경우 이를 reference model로 삼을 수 있으므로, 검증을 위한 모델로서 사용하는 경향은 점점 확대되어 가는 것이겠지요. (이 과정에서 위에 이야기한 SoC에 대한 performance estimation도 가능하구요..)
NoC의 경우 말씀하신 것과 같이 TLM에 대한 요구가 더 절실해 질것으로 보입니다. NoC라는 것이 packet generation/passing overhead를 감수하고 bus로 인한 timing 문제나 loading의 문제를 해결하고자 하는 것이므로, 그 정도의 이득을 얻을 수 있는 용량의 SoC에서 적용될 것이니까요. 이때는 버스를 채용했을 때 보다 traffic이나 networking에 대한 분석이 당연히 어려울 것이므로 educated guess를 통해서 추정해 내는 것도 한계가 있지 않을까요 ^^;
그 정도의 복잡도가 된다면, 아마도 IP사들도, RTLM과 더불어 TLM을 만들어 제공해야 겠지요. 요즘에는 transactor를 이용하여 속은 RTL, 밖은 TL로 만드는 경우도 많습니다만 ^^; 이는 내부의 추상화 수준을 올린 것이 아니라 단지 TLM과 같이 검증하기 위한 방법이므로, TLM이 가질 수 있는 많은 장점을 포기할 수 밖에 없는 것이지요.
아.. 결과적으로 말씀드리자면, TLM은 언제가는 다가올 미래라고 생각합니다.
단지, 위에 말씀드린 TLM to RTLM간의 synthesis 방법의 정립과 TLM/RTLM간의 등가성 검증 방법의 정립이 선행되어야 전반적으로 이 설계 방법론이 폭넓게 받아들여 질 수 있겠지요. (학계에서 열심히 하고 있으니 좋은 결과가 있지 않을까요?) 혹은, 이런것이 없더라도, multi-million gate SoC가 너무나도 일반화된다면, IP 제공 업체들에게 TLM과 RTLM을 모두 제공하라는 전방위적인 압박이 오겠지요 ^^; (이것이 더 현실적일지도 모르겠네요..^^;)
Synopsys 버전을 찾아보기..
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 명령어를 쓰면 되고, 문자 대치하는 것도 훨씬 쉬워지고요.. ㅎㅎ<br /><br />여담입니다만, 텍스트 큐브로 업그레이드하면서, 소스 하이라이팅 기능과 박스 넣기가 좀 이상해져서, 이쁜 모양으로 소스코드 보여드리기가 상당히 힘드네요.. 집에서 컴퓨터 만질 시간이 생기면 한번 손을 봐야 겠습니다.