Category Archives: SoC & IP design : For beginners

동기가 가장 중요합니다.

2 Replies

가끔은 여러가지 경로(직접, 메일로, 게시판으로..)로 진로에 대하여 상담해 오시는 분들이 계십니다. 제가 아직은 배우는 과정에 있는 사람이고, 수많은 값진 경험을 가진 선배님에 비하면 습자지 한장 두께도 되지 않는 얇팍한 지식과 일천한 경험을 가졌을 뿐이지만, 질문해 오신 후배님들께 도움이 되었으면 하는 바람으로 답변을 장황하게 해 드릴때가 많습니다.
원래 많은 것을 아시는 분들은 간단하고 명료한 말로 잘 설명해 주시지만, 저처럼 아직 부족한 사람들은 빈깡통 소리를 내는지라, 주저리 주저리 말이 많은 거죠.

여하튼, 이때 빠지지 않고 드리는 이야기가 “즐길 수 있는 것을 선택하라“는 것입니다.

남은 생활동안 상당 기간을 이 일을 하면서 지내게 될 것인데, 그 선택의 기준으로 이것보다 좋은 것이 있을까요?

돈을 잘버는 것. 중요합니다.
다른 사람에게 존경 받는 것. 중요합니다.
편한 것. 중요합니다.
성취감을 얻어내는 것. 중요합니다.
재미 있는 것. 중요합니다.

“비전”이 있나요? 라는 질문에 대한 답이 가장 어렵습니다. 그 기준에 따라 비전이 있는지 잘 모르겠으니까요. 엔지니어라는 대부분 돈과는 좀 거리가 있는 듯 해요. (물론, 박봉에 시달린다는 이야기는 하지 않겠습니다. 하지만, 요즘 후배분들의 기준이 워낙 높으니까요 ^^;)

계속 공부해야 하고, 계속 습득해야 하는 분야이다보니, 자신의 현재 모습에서 할수 있는 능력을 소모만 해서는 안되는 분야지요.

이런 조건을 충족시키자면,  “Self Motivation을 가진 사람이 되어야 하는 것[1]이 이야기는 사실 제가 연구실에 들어가서 가장 먼저 교수님으로 부터 들은 조언들 중의 하나입니다. ”이지요. 제게 있어서는 self motivation을 충족시키는 가장 큰 요소가 “재미”와 “성취감”이라고 생각합니다.

재미란 건 모든 사람이 다른 기준을 가지고 있는 법이니, 제가 조언해 드릴 수 없는 부분이고..

제가 말씀 드릴 수 있는 건, 이쪽 업계에 들어 오시고 싶어하시는 분들께 어떤걸 공부하는 것이 좋은지, 여러분이 지금 배우고 있는 것이 이쪽 분야에서 얼마나 중요한 것인지 정도만 이야기 할 수 있는 것이지요. ^^;
주변에 계신 선배분들과 교수님과 적극적으로 상담하세요.

Notes & References

Notes & References
↑1 이 이야기는 사실 제가 연구실에 들어가서 가장 먼저 교수님으로 부터 들은 조언들 중의 하나입니다.

Register file vs. SRAM

6 Replies

정의로써 이야기하자면, Register file은 Register의 집합체를 통칭하는 말이며, SRAM은 Static RAM의 줄임말입니다. Register라는 말은 보통 D-FF과 같은 간단한 로직 형태의 저장 장치를 의미하며, 어떤 소자의 형태를 의미하지는 않습니다. 따라서, Register file은 D-FF의 합쳐진 형태로 나타낼 수도, SRAM으로 나타낼 수도, 혹은 특별한 형태의 소자를 사용할 수도 있습니다.


다만, 일반적으로 받아들여지기를 SRAM과 비교하였을 때 Register file은 빠르고, 더 size가 크고, 일반적으로 더 전력 소모가 심하리라 생각할 수 있습니다. 실제로 Full-Custom으로 구성되는 프로세서에서 Register file의 소자 형태는 중요한 논문 꺼리 중의 하나로 들어가 있으니까요.


이제 현실로 돌아와 보면.. (소위 ASIC이라는 Flow를 생각해서)


Memory component는 각 Fab 회사에서의 memory compiler를 사용하게 되는데, 신기한 것이 Register file이 SRAM보다 “더 작고, 더 전력 측면에서 유리하고, 더 빠른” 형태로 나오는 경우가 많다는 것이지요. 이는 일반적으로 생각하는 “Speed 와 Area는 반비례한다”라는 관계와 들어맞지 않는데요.


Physical Library를 만드는 Artisan의 이야기로는 “Register file과 SRAM 간의 기본 아키텍처 차이는 없으나, register file에서는 작은 인스턴스 크기인 경우에 최적의 결과를 나타낼 수 있도록 설계되었다”고 합니다.


즉, 이런 memory compiler들은 SRAM이나 Register File이라 불리는 메모리나 모두 6T 구조(6개의 transistor를 쓰는 구조인 것은 아시죠?)의 SRAM cell을 사용하지만, Register File로 구현되는 경우 column당 SRAM cell의 수를 최소화해서, bit-line cap 값을 줄이는 기법을 사용한다고 합니다. 따라서, 결과적으로 구현할 수 있는 크기에 제약을 받지만, 같은 형태의 SRAM에 비하여 빠르고, 더 작은 크기를 지니게 되는 것입니다.


이러한 형태로 구현되는 이유는 현재의 ASIC technology에서 SRAM cell만 가지고도 약 400MHz정도(0.18um에서)를 구현하는 것이 가능하고, 대부분의 ASIC 공정의 경우 Register file에 요구하는 속도 정도가 이 수준을 넘지 않기 때문이라고 하는 군요.


따라서, 이러한 형태를 따르는 memory compiler에 있어서는 일반적으로 이야기되는 “SRAM은 6T구조의 메모리이며, Register file은 filp-flop혹은 latch storing구조를 채용하는 빠른 형태의 메모리이다”라는 학교의 지식을 버려야 하는 것이겠습니다.

변화가 싫다?

8 Replies

이 이야기는 설계 회사에 들어가실 분들에게 유용할 수도 있는 글이라 생각하여 써봤습니다. ^^;
—–
차라리 백지가 좋은데, 그렇지 않은 경우가 있습니다.
학교에서 배워온 코딩 스타일(사실 학교에서 코딩 스타일을 가르쳐주지는 않지요?)과 회사의 코딩 스타일이 다를때 자기 자신이 납득할 때까지 바꾸기도 쉽지 않지요 (그게 바로 엔지니어니까요!)

회사에서는 왜 특정 코딩 스타일을 고집할까요?
반대로 학교에서는 왜 코딩 스타일에 둔감할까요?

회사에서는 “칩이 정상적으로 도는 것”이 가장 중요한 목표인 반면에, 학교에서는 시뮬레이션을 돌려서 “결과를 뽑는 것”이 가장 중요한 목표이기 때문이지요.

따라서, 회사에서는 아주 안전하고, depensive한 코딩 스타일을 유지하게 됩니다. 즉, 시뮬레이션과 합성 이후의 결과에 차이가 나기 어려운 코딩 스타일을 유지한다고 보시면 됩니다.

학교에서는 아이디어를 빨리 구체화해서 도는 걸 보이는 것이 목표니까.. 약간은 offensive한 문법을 사용합니다. 좀 위험한 넘도 많이 사용하구요. 그래서, 가끔은 질문 게시판에 “시뮬레이션은 도는데, 합성하면 이상하다.. 툴이 이상한거 아니냐.. “라는 질문이 올라옵니다.

이런 측면에서 예전 SIPAC 코딩 스타일이나, RMM의 코딩 스타일 가이드는 실무적으로 아주 중요합니다.
(SIPAC은 이제 사라졌지만 말입니다.) 학교에서만 끝낼것이 아니라면 RMM[1]RMM: Reuse Methodology Manual. Cadence, Synopsys 엔지니어들이 코딩 스타일에 대하여 가장 체계적으로 정리한 실무서입니다. 저는 SIPAC나 IPCOS의 코딩스타일 가이드라인이 모두 RMM에서 출발했다고 보는 입장입니다. ^^; 예전에 학회에서 SIPAC의 서책임님과 이런 이야기를 나누었다가 반박당한적도 있습니다만 ^^; 요기에 간단히 소개되어 있습니다. 을 보세요
—-

버젼 관리라는 것은 아주 중요합니다. 절대적으로 중요합니다.
하지만, 학교에서 버젼 관리하는 경우는 거의 못봤습니다.
회사에서도 하는 회사도 있고, 하지 않는 회사도 있습니다.

회사에서 소스 코드에 대한 버젼관리를 하고 있다면, 귀찮아하시지 마시고 긍정적으로 따라가십시요. 버젼 관리를 통해서 구원받을 날이 반드시 있습니다.
그리고, 버젼 관리를 하지 않는다면 반드시 버젼관리를 시작하십시요. CVS와 같은 강력한 툴이 있습니다. 하드웨어 검증 책마다 강조하는 것들이 있는데 빠지지 않는 것이 있다면 바로 버젼관리입니다.
—

버그 트래킹이란 것이 생소하신가요? 아직 체계적인 버그 보고 체계가 없다면, 지금부터는 고려할 때가 되었습니다. (이건 뭐, 상품 카피 같기도 하네요.. ^^;)
버그 트래킹은 어찌보면 “버그를 확인하고, 정확히 정의하고, 동일한 문제가 발생하지 않도록 체계적으로 관리하는 방법”이라 보는 것이 맞겠습니다.

Trac이나 Mantis, Bugzilla가 버그 트래킹 시스템에서 가장 많이 알려져 있겠습니다.

저도 사실 위의 3가지를 기반으로 저희 회사에 맞는 방법을 저울질 중인데.. 초반에는 버그 질라에.. 지금은 trac쪽에 약간 무게를 두고 있습니다. 사실 버그 트래킹 기법이라것이 소프트웨어 개발쪽에서 출발한 것이라, HDL에는 약간 귀찮은 면이 있습니다.

그것보다 더 귀찮을 것이라 생각되는 부분은 “변화를 싫어하는 마음”입니다.
버그 트래킹이나, 버젼 관리 좋다.. (듣기는 들었으니..) 하지만, 나를 귀찮게 하는 건 싫다..
이런 마음이 가장 문제겠지요..

귀찮더라도 도전합시다.

Notes & References

Notes & References
↑1 RMM: Reuse Methodology Manual. Cadence, Synopsys 엔지니어들이 코딩 스타일에 대하여 가장 체계적으로 정리한 실무서입니다. 저는 SIPAC나 IPCOS의 코딩스타일 가이드라인이 모두 RMM에서 출발했다고 보는 입장입니다. ^^; 예전에 학회에서 SIPAC의 서책임님과 이런 이야기를 나누었다가 반박당한적도 있습니다만 ^^; 요기에 간단히 소개되어 있습니다.