Monthly Archives: November 2006

검증의 대세는 system verilog?

검증 작업을 시작했다는 포스팅을 얼마전에 했었습니다.
뭐, 일단 검증 시나리오 짜고, function coverage 전략 세우고.. 이런것 부터 시작했습니다만..

verilog로 약간 검증 마인드로 이런 저런 것을 작성하다보니, synthesizable subset의 틀이 얼마나 옭죄고 있었나라는 생각이 심각히 들더군요..

verilog 표준에서 정의된 동작에 대해서 어느정도는 알고 있다고 자부하고 있었는데, 좀더 깊이 알게 되는 기회가 되고 있는 것 같습니다. 얼마전 gil님께서 class와 비슷한 verilog를 말씀하신 이유도 납득이 가구요..
사용자 삽입 이미지
하지만, verilog는 추상화 레벨을 높이기에 약간 무리가 있기는 하더군요.. 물론, 어짜피 regression vector쪽에는 PLI위주로 가게될 것으로 구상해두었지만, 일반적인 경우에는 PLI사용을 꺼리시는 분들도 있는 관계로 왠만하면 verilog만으로도 어느정도 coverage를 보일 수 있도록 구상하고 있는데… 약간 까다로운 점이 있습니다.

그래서, 대안 처럼 생각하고 있는 부분이 SystemVerilog인데, 아직 제가 본격적으로 공부해본것이 아니라 스펙 수준에서 표준 문서만 한번 훓어본 정도에서 멈추어 있던 상태라 약간 깨름직 했었습니다.
그런데, verification guild에서도 그렇고, comp.lang.verilog도 그렇고 system verilog에 대한 내용과 비중이 점점 높아가는 것을 알 수 있겠더군요.

사실 verification guild의 guild master가 vmm-sv의 저자이기도 하니까 그렇겠지요..
하지만, writing testbench 책이 HVL이 아닌 system verilog만을 이용해서 다시 작성할 수 있을 정도로 system verilog의 verification기능이 강력하다는 것은 아무래도 끌리는군요.
(옆에 보이는 책이 writing testbenches using systemverilog책이 바로 예전에 제가 다시 읽고 있다는 writing testbenches의 새 버젼이지요. 요즘에 가장 사고 싶은 책입니다. 하지만, 가격이… 가격이.. orz)

Verification Methodolgy Manual for SystemVerilog와 같은 책이 나온것도 사실 system verilog가 대세가 되는 것 아냐? 라는 생각을 가지게 하는 이유이기도 하지만 말입니다. (또한권의 가장 사고 싶은 책입니다. 역시 가격이.. 에휴… ) 사용자 삽입 이미지책의 홈페이지에는 system verilog를 이용한 verification에 대한 개략적인 정보는 얻을 수 있습니다.

사실 초기에 저는 cadence의 SCV를 필두로한 systemC에 대항하기 위해서 synopsys가 선택한 카드가 system verilog일 것이라는 곱지 않은 시선을 가지고 있었습니다.
하지만, 요즘에 와서는 system verilog를 native로 지원하는 simulator들이 속속 등장하고 verilog표준에 system verilog가 포함될 것으로 예정되어 있는 상태이니.. 정말 systemverilog가 HVL을 대체할 정도로 강력하다면, 대세가 될 확률이 높아지겠지요.

여하튼, 지금 가지고 있는 system verilog for design(stherland저)책이라도 한번 봐둘 필요는 있을 것 같습니다. ^^;
사실 예전에 이 책 봤을때는 systemverilog에 대해서 약간 실망을 했었는데, 검증의 측면에서는 어떨지 한번 공부해 봐야겠습니다.

이 부분은 역시 작업 마치면 한번 정리하죠..나~~~중에

반 DRM.. 사실 표준화되지 않은 DRM이 문제 아닌가..

[wp]GPL [/wp]3.0에서 가장 많이 변한 부분이 DRM에 관한 부분이라고 합니다.
(저는 아직 GPL 3.0을 읽어보지 않았으며, ZDnet의 기사만을 참조하였습니다. )

얼마전 리챠드 스톨만(제가 존경하는 분들중의 한분인데요..)의 강연에서 DRM에 대한 이야기가 나왔고, 이 부분에 대한 많은 이야기가 블로그 스피어상에서 나오고 있는 것으로 알고 있습니다.

사실 DRM은 생각보다 넓게 퍼져 있습니다.
가장 대표적인 것이 국내 서비스중에 “멜론”이겠고, 애플의 “iStore”겠지요..

그런데, 문제는 사용자가 특정 기기를 사용하지 않는 경우 멜론에서 정식으로 구입한 음원은 절대 다른 기기에서 사용할 수 없습니다. 이는 명백하게 음원의 가격을 지불한 사용자에게 불필요한 제약을 가하는 것입니다.
이런 문제가 얼마나 심각하면, 하나의 DRM을 다른 DRM으로 변환하는 transcoding과 같은 다양한 연구가 진행되겠습니까..

여하튼, 이 문제에 대한 GPL의 대답이 아래와 같은 것이겠지요.

GPLv3의 개정 초안을 보면, GPL이 적용되는 소스코드에는 ‘권고적으로 또는 원칙적으로 소스 코드의 수정 버전을 설치 내지 실행하는데 필요한 일정 암호화 키나 인증 키가 포함되어야 한다. 소스 코드 사용을 제한하는 어떤 키가 하드웨어에 존재한다고 해서 소스 코드에 키가 포함되어야 한다는 위 요건이 바뀌거나 하지는 않는다,”고 규정하고 있다.
[ZDnet에서 인용]

하드웨어에 종속적이지 않아야 한다는 의미로 받아들일 수도, 소프트웨어상에 키가 포함되어야 하기에 DRM이 무력화 된다는 의미로 받아들여질 수도 있겠습니다만.. 문제 인식 자체에는 공감합니다.

그런데, 이게 anti-DRM으로 연결되어야 하느냐는 좀 아닌거 같습니다.

[wp]DRM[/wp]이란 것이 저작자의 권리를 지키자는 취지에서 개발된 것으로, 불편하지만 있어야 한다는 것으로 생각하기 때문입니다.

사실 [wp]DRM[/wp]과 [wp]GPG[/wp](GNU PGP)에 무슨 차이가 있겠습니까?
하나는 저작권을 보호하는 것이고, 하나는 개인정보 보호에 사용된다는 점 외에는 사실 같은거라고 보고 있거든요..

저작자의 권리를 보호해야 하지만, 이를 과도하게 보호해서 정당한 가격을 지불한 사용자에게 제약을 가하면 안된다는 것이죠. 아니, 고객의 권리를 제한한다는 것이 얼마나 우스운 일입니까?

두 가지 권리를 모두 보호할 수 있는 가장 합리적인 방법은 (스톨만 아저씨가 이야기 하신것처럼) “인식의 변화”가 맞습니다만, 이게 어렵다면 차선의 방법은 “표준화된 DRM”이 되겠지요.

몇몇 표준단체에서 DRM관련 표준화에 대해서 고민하고 있습니다만, 각 업체간의 이런 저런 알력이 있으니 쉽지만은 않을거라 생각합니다. ^^;

그래도, 최대한 빨리 표준화가 되어야 할 문제겠지요..

에이.. 칩 좋다고 성공합니까?

여러가지 칩들 중에 버그가 많은 칩이 존재한다는 건 이미 알려진 이야기지요..
그중에 소프트웨어적으로 회피할 수 없는 심각한 문제를 숨기고 있는 칩도 있구요..

그럼에도 성공하는 칩이 있습니다.

버그 없고 잘 나온 칩인데 실패하는 칩도 있습니다.

성공하는 칩은 적절한 시점에 적절한 가격으로 출시된 경우가 대부분입니다.
칩이 기획되고 나와 상용화까지가는데, 최소 1년, 길면 2~3년이라고 보면 성공한 칩은 “미래에 대한 예측에 성공했다”고 보는 것이 옳을 것입니다.

소위 이야기하는 블루 오션 전략에 성공하는 패턴이겠지요.

국내 비메모리 회사들중에 현재 매출순위 top 10안에 들어가는 회사들이 바로 이 블루오션에 개척에 성공한 케이스라고 생각합니다. (물론, 이 분야가 이제는 심각한 레드 오션으로 바뀌고 있는 상황이니 다른 매출꺼리를 찾아나가고 있는 중이겠습니다. 새로운 시장을 개척하는 방향이 대부분 회사에서 비슷한 방향으로 진행되고 있다는 건 좀 우려되는 상황이긴 하죠..)
사실 국내 비메모리 반도체 회사들이 대부분 벤쳐 기업으로서 출발했으니, 이러한 블루 오션 전략으로 올인하는 방향이 가장 현명한 선택이었음에는 의심의 여지가 없습니다.

시스템 업계에서 새로운 칩을 선택하려고 하는 시점에 시의 적절하게 나온 칩들은 만일 약간의 버그가 있더라도 기능과 가격적인 메리트로 일어날 수 있는 것이지요. 물론, 버그 없는 칩이 같이 있었다면 더 어려운 상황이었겠죠.

그럼 ocean이 점점 피빛으로 물들어 갈때 해야 하는 전략은 무엇이 있겠습니까?
칩 자체의 가격을 낮추는 것이 가장 먼저 떠오를 수 있는 생각이겠지만, 이런 전략은 궁극적으로 어려움을 초래할 가능성이 있습니다.

다른 방법으로는 바로 사용자 측면에서 비용을 낮출 수 있도록 도와주는 것입니다.
소위 이야기되는 bug-free나 platform based가 이런 것이겠습니다.
버그가 없다는 건 어찌보면 시스템 업체에서 고생할 가능성을 최소한으로 줄일 수 있도록 한다는 건데.. 실제적으로는 bug뿐만이 아니라 사용자의 실수를 알려줄 수 있는 기능(칩의 입장으로는 overhead겠습니다만..)까지 넣는 것이 바람직하겠습니다.

Platform-based 라는 것이 상당 시간동안 회자되고 있습니다.
특정 분야의 시스템에 맞추어져 있는 chipset과 소프트웨어를 갖추어 놓고, 이를 시스템업체에 제공하는 방법이 platform based 방법이라 볼 수 있는데, 시스템 업체의 입장에서는 시스템 제작에 따르는 부담을 극적으로 감소시킬 수 있다는 장점이 있겠죠..

칩 업체 입장에서는 해야할 것이 너무 많으니 부담되는 것으로 받아들여지는 경우가 더 많은 것 같습니다.
하지만, 적극적인 플랫폼의 개발이 개발된 칩의 사용 가능성을 한층 넓힐 수 있는 확실한 방법이 됩니다. (만일 버그가 있더라도 제공된 software로 효과적으로 숨길수도 있고 말입니다. ^^;)
게다가, 칩 업체가 시스템 업체에 대한 지원 부분도 아주 효과적으로 줄일 수 있으니, 장기간으로 보았을때는 좋은 플랫폼을 제공하는 칩이 성공하는 칩이 되겠습니다.

에이.. 칩만 좋다고 성공합니까? 칩만 만든다고 되는건 아니라니까요..