AI(Artificial Intelligence)와 IoT(Internet of Things) 등 주문형 chip(ASIC, application-specific integrated circuit)에 대한 시장의 요구는 늘어나고 있고, 실제로 많은 chip들이 설계되고 있으나, 실질적인 삶의 변화로까지 이어지지는 경우는 드뭅니다.
많은 ASIC 설계들이 기능적으로 오류가 있거나, 계획하였던 성능 조건을 만족시키지 못하기 때문입니다. 좋은 반도체를 만들어서 우리의 삶을 좀 더 윤택하게 하려면, 규모가 커지고 복잡해진 설계를 다룰 수 있는 고도화된 기능 및 성능 검증을 제공하기 위한 서비스가 필요합니다. 메타앙코르는 그러한 서비스를 제공함으로써 사람을 이롭게 하는 반도체가 많아지는 것을 목표로 하는 회사입니다.
Courses
Reviews
- Basic Design Synthesis Training (Digital Circuit Design Implementation)
- Basic Design Synthesis Training (Digital Circuit Design Implementation)
- Basic SystemVerilog Testbench (Circuit Design Verification)
- Basic SystemVerilog Testbench (Circuit Design Verification)
- Basic SystemVerilog Testbench (Circuit Design Verification)
Posts
Q&A
영상이 이상합니다.
김민재 님, 소리가 나는 영상과 시간대를 알려 주실 수 있으신지요?
- 0
- 1
- 33
Q&A
'fork-join_none'으로 시작된 백그라운드 스레드의 종료는 어떻게 관리되나요?
조재용님, 이 부분은 Simulator 들에서 관리가 되는 것으로 알고 있습니다. SV LRM 정의로만 본다면, 자식 스레드가 완료된 이후 스레드의 종료 절차로 스레드가 완료되고, 스레드에서 사용되었던 class 들이나 메모리들이 모두 release 되어 재사용 되도록 정의가 되어 있습니다. 간혹, tool의 오류로 좀비가 생길 수는 있으나, 이러한 부분들도 simulation 종료와 함께 모든 thread 들이 종료되어야 하는 것으로 정의가 되어 있습니다. 답변이 되셨을까요?
- 0
- 1
- 20
Q&A
SystemVerilog 내 program 이 top module 의 역할을 하는건가요?
원숭이 알러지 바나나님, 수강해 주시고 질문도 주셔서 감사합니다. SystemVerilog의 program 블록은 testbench 동작을 정의하는 블록으로, Verilog에서의 top module과 동일한 역할을 하는것은 아닙니다. Verilog에서는 일반적으로 top module이 Design과 testbench의 모든 구성요소를 포함하는 최상위 계층으로 동작합니다. 즉, stimulus generation, DUT instance, simulation test run의 구동점이 모두 하나의 모듈, 최상위 top module 내부에 작성되게 됩니다. 이 구조에서는 testbench와 DUT가 같은 simulation time slot 내에서 실행되기 때문에, signal 업데이트나 event scheduling 과정에서 race condition이 발생할 수 있습니다. SystemVerilog의 program 블록은 이러한 문제를 해결하기 위해 도입된 개념입니다. Program은 testbench의 procedural part를 감싸는 최상위 컨테이너 역할을 합니다. Program은 DUT와 같은 시간 단계에서 신호를 업데이트하지 않도록 scheduler 상에서 별도의 region에서 실행됩니다. 즉, program 블록은 testbench가 DUT의 신호를 읽을 때 이미 안정된 값을 받게 됩니다. 이로 인해 race condition이 자연스럽게 제거됩니다. 따라서 program은 DUT와 testbench 간의 타이밍 독립성을 보장하기 위한 상위 procedural 컨테이너 블록이라고 보는 것이 정확합니다. 또한 program을 사용하지 않고 단순히 module로 testbench를 구성할 수도 있지만, 이 경우 scheduler 상에서 DUT와 동일한 region에 위치하게 되므로 race condition 발생 가능성을 완전히 배제할 수 없습니다. 실제 프로젝트에서는 대부분 class-based testbench(OOP 구조)를 사용하면서 interface와`program을 함께 구성하고, tool vendor의 권장 가이드에서도 program 블록 사용을 권장하는 이유가 바로 이 race-free 동작에 있습니다. 하지만 이러한 개념은 EDA tool 회사마다 가이드가 조금씩 다릅니다. Race condition 유발에 크게 영향이 없다는 주장도 있고 해서, 현재 program 을 쓰는 경우와 안 쓰는 경우가 혼재되어 사용되고 있습니다. 사용자가 경우에 맞게 적용해서 사용하시면 됩니다. 그리고, program block 에는 interface 와 module 을 instance 할 수 없기 때문에 완전한 top container 로 사용은 할 수 없지만, procedural block 들과 oop test 용으로 사용할 때는 내부에 module instance 가 없고, interface instance 가 없다면 top container 로 simulator 에 입력으로 줄 수도 있습니다. 마지막으로, program의 사용은 SDC나 실제 제조 단계의 timing constraint 와는 관련이 없는 개념 입니다. 이는 RTL 설계의 timing synthesis 과정이 아닌 simulation 단계에서의 event scheduling 레벨의 race 방지이기 때문입니다.답변이 되었는지요?
- 2
- 2
- 36
Q&A
강의문의
모란님, 수강 해 주셔서 너무 감사 드립니다. 현재 UVM Basic 강의가 10월 말 오픈 예정으로 준비 중에 있습니다.기타 SV/UVM 고급 과정과 SystemVerilog Assertion 과정도 준비 중에 있습니다. 궁금하신 부분 있으시면 언제든 말씀해 주세요.
- 1
- 1
- 41