Tag Archives: SoC

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

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

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

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

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

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

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

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

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

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

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

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

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

Verilog PLI 배우기 (1)

Verilog 사용자가 별로 없는지라(이 이야기에 발끈~하는 엔지니어 분들도 계시겠지만, 사실 C언어 사용자 보다는 적은거 맞잖습니까.., 우리나라 사람들중에 공학도 중에, 전자공학도 중에, verilog HDL을 쓰는 분을 따지면 별로 안되죠..^^) 국내에는 verilog PLI에 대하여 다루고 있는 페이지도 별로 없다.

개인적으로도 verilog PLI 관련 내용은 외국의 웹 페이지나, sutherland의 책을 참조하고 있는데, 국내의 많은 분들도 PLI를 적극적으로 이용하고 있음에 의심에 여지가 없건만 다들 숨기기만 하시니, 참조할 곳이 참 적기만 하다.

책이야기와 더불어 verilog PLI 이야기를 특히 VPI 이야기를 한번 해보려 한다.
뭐, 나도 PLI중의 tf_나 acc_는 좀 써봤지만, VPI는 얼마전에 처음 다루어 보았다.

그래서 공부 겸사 겸사.. 시간 될때 마다 정리해서 올려보려고한다.

우선 이번에는 PLI에 대한 대략적인 틀에 대해서~
(뭐 머리속에 있는 걸 쓰는 것이니 틀린것이 있을지도..)

PLI는 Programming Language Interface, 즉 verilog 에서 C/C++과 같은 언어와의 연동을 위하여 제공하는 일종의 API이다. 예전에 정의된 tf_, acc_(소위 PLI1.0)는 각각의 상황에 맞는 수많은 함수가 존재해서, 적절한 함수만 찾으면 쓰기는 쉽다는 장점이 있었다. (babyworm도 예전에 이걸 가지고 simulator와 verilog와 연동시킨 적이 있다..)

하지만, 함수가 너무 많아서 reference가 없으면 도저히 쓰기 어렵고, 명확히 정의되지 않았다는 단점이 있다(특히 verilog simulator와의 interfacing부분에 있어서 표준화 되어 있지 않다).

VPI는 다시 정의된 PLI함수로서 소위 PLI2.0으로 불린다. 예전에는 시뮬레이터 지원이 잘 안된다는 단점이 있었다지만, 요즘 시뮬레이터에서는 대부분 지원하고, 상당히 일관된 인터페이스를 지니고 있는 장점을 가지고 있다.

개인적으로는 acc_, tf_ 를 알면 verilog simulator가 어떻게 object들을 처리하는지 정말 잘~ 알게되는 장점(?)이 있는 반면, VPI는 그런 거 알 필요 없이 함수의 설정만 알아도 대부분 처리할 수 있다는 장점이 있다.
사용자 입장에서 어떤것이 편한 것인지는 말할 필요가 없다.

PLI는 기본적으로
1. 그 함수를  verilog simulator에 등록하는 부분을 지니고,
2. 해당 PLI 함수의 초기화, 호출, 크기 검사를 수행하는 callback 함수를 지니고 있다. (PLI1.0에는 misctf라는 재미나고 babyworm이 잘 사용하는 callback이 하나 더 있었다)

PLI를 verilog simlator와 연동하는 가장 쉬운 방법은 dynamic library로써 PLI함수를 컴파일하고, 이를 verilog simulator호출 시점에서 시뮬레이터에 알리는 것이다.

간단한 예를 들자면,

ncverilog +access+rwc +loadvpi=./aaaa.so:aaa_bootfunc test.v
이런식이다. 위에서 loadvpi라는 옵션을 사용헀는데, 이는 VPI 형태의 PLI함수를 포함한 동적 라이브러리를 시뮬레이션 시에 포함하되, aaa_bootfunc 이라는 것이 등록함수(다른 말로 bootstrap이라고 한다)로 사용할 것임을 알려주는 것이다.

다음번에는 실제적으로 VPI의 전반적인 얼계에 대해서 살펴봅시다.