After making a chip, it is essential to check whether it operates properly without errors. However, since semiconductor chips are small but have a very complex structure, testing is not easy.
That’s why Design For Test (DFT) is applied to SOC chips. You can think of it as planting a structure that can inspect itself inside the chip in advance during the design stage. This is the most effective way to do it, since testing a complex SOC as an individual function has its limits.

Configuring DFT can be simply summarized as “1. Add a circuit to test whether the function of each block operates properly, and 2. Provide a clock to operate the added test circuit.” There are techniques for implementing DFT, such as Scan Chain, BIST (Built-In Self-Test), and JTAG, and as circuits for testing are added to already designed function blocks, applying DFT becomes more difficult as the system becomes more complex. We will look at DFT in more detail later. I will explain about adding circuits for Test 1, including Scan Chain, BIST, and JTAG, at that time. To give a spoiler, we are preparing a DFT Canvas for DFT, targeting a release in the second quarter of this year, and we are also preparing a DFT Canvas story.

For now, since we are talking about Clock Canvas, I will only talk about creating a separate clock for Test 2 related to Clock.
Since the clock is the reference of the system, any block must have a clock to operate. This means that a clock is required even if you want to test, and a separate test clock is required for the test circuit added to each block.
In order to simplify the test, it is ideal to use a single test clock. This makes DFT implementation easier and test timing easier, but the problem is that SOC has multiple clock domains. Multiple test clocks may also be required.

Even just hearing this, the difficulty of designing the clock’s DFT seems difficult enough, but there is another problem.
Who will design the DFT? If there is a separate DFT designer, there is no problem. However, in reality, there are many cases where there is no DFT designer.
As a result, the function block designer designs only his function to work well and passes it on, and expects the implementation stage to do a good DFT, but the implementation stage engineer does not have enough design information for the function block, so it is not easy to make a good DFT.
In this situation, the best way for DFT is to configure it by adding a Test Mux or adding an OCC (Observe-Control-Compression) point to imitate the clock system of the Function level as much as possible, and this is the current general DFT system design method.

What are the problems with this configuration?
1. It takes too long to configure the DFT system.
2. The consistency of the DFT test cannot be secured.

The Implementation stage engineer who creates the DFT must continuously inquire with the Function block designer to imitate the Function mode as much as possible. The process of asking, answering, and designing creates an infinite loop as shown in the figure above. It usually takes about a month to secure the Test clock through this process, but it can take up to half a year. Every day is important in making a chip, and it is very inefficient to spend several months for an invisible function.

In addition, since the Test clock, which is made separately for DFT, is made by the Implementation stage engineer, it can be made with a different structure from the Function clock.
In the worst case, it may work without problems in the Test and be mass-produced, but the actual Function may not work. In addition, the timing margin of the Test clock and the Function clock also differs, so the operation in the test environment and the actual operating environment may differ, making debugging very difficult when an error occurs in the actual operating environment.
As a result, the consistency of the DFT test cannot be secured, so a chip that passes the test but does not work properly may be produced. The meaning of applying the DFT may be lost.

칩을 만들고 나서 오류 없이 제대로 동작하는지 확인을 하는 것은 필수죠. 그런데 반도체 칩은 작지만 매우 복잡한 구조를 가지고 있기 때문에, 테스트가 쉽지 않습니다.
그래서 SOC 칩에는 Design For Test (DFT) 즉, 테스트를 위한 설계를 적용합니다. 칩 내부에서 스스로를 검사할 수 있는 구조를 설계 단계에서 미리 심어두는 것이라고 보면 됩니다. 복잡한 SOC를 개별 기능으로 테스트 하는 것은 한계가 있기 때문에 이렇게 하는 것이 가장 효과적입니다.

DFT를 구성한다는 것은 “1. 각 블럭의 Function이 제대로 동작하는지 Test할 회로를 추가하고, 2. 추가한 Test 회로를 동작시킬 clock을 제공한다”로 간단하게 요약할 수 있습니다. DFT를 구현하는 기법들로는 Scan Chain, BIST (Built-In Self-Test), JTAG 등이 있고, 이미 설계된 Function 블럭들에 Test를 위한 회로를 추가하다 보니, 시스템이 복잡할수록 DFT를 적용하는 것은 더 어려워집니다. DFT에 대한 내용은 나중에 따로 더 자세하게 살펴볼 예정입니다. Scan Chain, BIST, JTAG 내용을 포함하여 1번의 Test를 위한 회로 추가에 대해서는, 그때 설명을 하도록 하겠습니다. 스포를 하자면, 올해 2분기 출시를 목표로 DFT를 위한 DFT Canvas를 준비하고 있고, DFT Canvas 이야기도 같이 준비 중입니다.

지금은 Clock Canvas 이야기이니 clock과 관련된, 2번 Test를 위한 별도의 clock을 만드는 것에 대한 얘기만 해보려고 합니다.
clock은 시스템의 레퍼런스이기 때문에, 어떤 블럭이라도 움직이려면 기본적으로 clock이 있어야 합니다. 그 얘기는 테스트를 하려고 해도 clock이 들어가야 한다는 말이고, 각 블럭에 추가된 Test 회로를 위한 별도의 Test clock이 필요하다는 의미입니다.
테스트를 단순하게 하기 위해서는 하나의 Test clock을 사용하는 것이 이상적입니다. 이렇게 하면 DFT 구현도 쉬워지고, 테스트 타이밍을 맞추기도 쉽기 때문인데, 문제는 SOC는 여러 개의 clock domain이 있다는 점입니다. Test clock도 여러 개가 필요할 수 있습니다.

여기까지만 들어도 이미 Clock의 DFT 설계의 난이도는 충분히 어려워 보이는데, 문제는 더 있습니다.
DFT를 누가 설계 할 것인가? 입니다. DFT 설계자가 별도로 있으면 문제가 없습니다. 하지만 현실은 DFT 설계자가 없는 경우가 대부분입니다.
그러다 보니, Function 블럭 설계자는 자신의 Function만 잘 동작하게 설계해서 넘겨주면서, Implementation stage에서 DFT를 어떻게 잘 해주길 바라게 되고, 정작 Implementation stage 엔지니어는 Function 블럭의 설계 정보가 충분하지 않으니, DFT를 잘 만들기가 쉽지 않습니다.
이 상황에서 DFT를 위한 최선은, Function level의 Clock 시스템을 최대한 모방하도록 Test Mux를 넣거나 OCC (Observe-Control-Compression) point를 추가하여 구성하는 것이고, 이렇게 하는 것이 현재의 일반적인 DFT 시스템 설계 방식입니다.

이렇게 구성하면 뭐가 문제가 될까요?
1. DFT 시스템 구성에 시간이 너무 오래 걸립니다.
2. DFT 테스트의 정합성을 확보할 수 없습니다.

DFT를 만드는 Implementation stage 엔지니어는 Function mode를 최대한 잘 모방하기 위해 Function 블럭 설계자에게 지속적으로 문의를 해야합니다. 묻고 답하고 설계하고  위 그림처럼 무한 반복 loop이 생성됩니다. 이 과정을 거쳐 Test clock을 확보하는데 보통 1개월이면 빠른 편이고, 반년이상 까지도 걸리게 됩니다. 칩을 만드는데 하루하루가 중요한데, 보이지 않는 기능을 위해서 수 개월의 시간을 소요 하는 것은 너무 비효율 적입니다.

그리고, DFT를 위해 따로 만드는 Test clock을 Implementation stage 엔지니어가 만들다 보니 Function clock과 다른 구조로 만들어질 수 있게 됩니다.
이렇게 되면 최악의 경우, Test 에서는 문제 없이 동작해서 양산을 했는데, 실제 Function은 동작하지 않는 일이 발생할 수도 있습니다. 거기다 Test clock과 Function clock의 Timing margin도 달라져, 테스트 환경과 실제 운영 환경에서의 동작이 다를 수 있게 되어, 실제 운영 환경에서 오류가 발생했을 때 디버깅이 매우 어려워집니다.
결과적으로 DFT 테스트의 정합성을 확보하지 못해 테스트를 통과했는데도 제대로 동작하지 않는 칩이 나올 수도 있게 됩니다. DFT를 적용한 의미가 없어지게 될 수도 있습니다.