LLM이 UVM 검증 시스템을 자연어로 조작하는 경우

1. 가상의 상황: UVM System Manager

회사 내부에 UVM System Manager라는 검증 관리 툴이 있다고 가정합니다. 이 툴은 UVM test 목록 조회, 특정 test 실행, regression 실행, log 분석, assertion failure 추출, coverage report 조회, waveform signal timeline 추출, Jira ticket 생성까지 담당합니다.

uvmctl list-tests --block nand_ctrl
uvmctl run --test nand_read_burst_test --seed 12345
uvmctl log --run-id RUN_20260429_001
uvmctl coverage --block nand_ctrl --report latest
uvmctl wave --run-id RUN_20260429_001 --signals cmd_valid,cmd_ready,data_valid

2. MCP를 붙이면 구조가 어떻게 바뀌는가?

핵심은 LLM이 UVM System Manager의 내부 API를 직접 아는 것이 아니라, MCP Server가 UVM System Manager를 감싸서 LLM이 호출 가능한 tool로 노출한다는 점입니다.

3. MCP Server가 제공하는 Tool 예시

가상의 uvm-manager-mcp-server는 아래 기능을 tool로 노출할 수 있습니다.

LLM은 내부 CLI syntax를 외우는 것이 아니라, tool 이름·설명·입력 schema를 보고 어떤 기능을 호출할지 결정합니다.

4. 사용자의 자연어 요청 예시

이 한 문장 안에는 여러 개의 검증 작업이 들어 있습니다.

1. 최신 regression 찾기
2. 실패한 test 찾기
3. 실패 log 분석
4. UVM_ERROR / UVM_FATAL 확인
5. assertion failure 확인
6. coverage hole 확인
7. 원인 후보 정리
8. SVA 후보 제안

5. 내부적으로 일어나는 일

1) tool 목록 조회

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

MCP Server는 자신이 제공하는 tool 목록과 inputSchema를 반환합니다.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_regression_failures",
        "description": "Get failed UVM tests from a regression run",
        "inputSchema": {
          "type": "object",
          "properties": {
            "block_name": { "type": "string" },
            "regression_id": { "type": "string" }
          },
          "required": ["block_name"]
        }
      },
      {
        "name": "get_uvm_error_summary",
        "description": "Summarize UVM_ERROR and UVM_FATAL messages",
        "inputSchema": {
          "type": "object",
          "properties": { "run_id": { "type": "string" } },
          "required": ["run_id"]
        }
      }
    ]
  }
}

2) 실패 regression 조회

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_regression_failures",
    "arguments": {
      "block_name": "nand_read_path",
      "regression_id": "latest"
    }
  }
}

MCP Server 내부에서는 기존 CLI나 API를 호출할 수 있습니다.

uvmctl regression failures --block nand_read_path --id latest

응답 예시는 이렇게 돌아옵니다.

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Failed tests:\n1. nand_read_burst_test, run_id=RUN_1042, seed=98341\n2. nand_read_ecc_retry_test, run_id=RUN_1047, seed=19283"
      }
    ],
    "isError": false
  }
}

3) log, assertion, coverage를 순서대로 조회

tools/call:
  get_uvm_error_summary(
    run_id="RUN_1042"
  )

tools/call:
  get_assertion_failures(
    run_id="RUN_1042"
  )

tools/call:
  get_coverage_holes(
    block_name="nand_read_path",
    report_id="latest"
  )

6. 사용자가 받는 최종 답변

사용자는 JSON-RPC, CLI 명령어, log path를 직접 보지 않습니다. LLM은 MCP tool 결과를 모아 사람이 읽기 좋은 검증 리포트로 정리합니다.

nand_read_path 최신 regression에서 가장 먼저 실패한 test는
nand_read_burst_test입니다.

실패 run_id는 RUN_1042이고 seed는 98341입니다.

가장 먼저 발생한 문제는 read command handshake가 완료되기 전에
data_valid가 먼저 assert된 것입니다.

즉, read command가 cmd_valid && cmd_ready로 accept되기 전에
read data path가 먼저 동작한 것으로 보입니다.

관련 assertion failure:
  a_read_data_after_cmd_accept

coverage hole:
  read command backpressure scenario가 충분히 cover되지 않았습니다.
  특히 cmd_valid가 유지되고 cmd_ready가 늦게 오는 상황에서
  data_valid가 premature하게 올라오는 corner case가 남아 있습니다.

7. SVA 후보까지 제안할 수 있다

MCP tool이 log, assertion, coverage 정보를 모아주면 LLM은 그 근거를 바탕으로 SVA 후보를 제안할 수 있습니다.

• read command accept 전 data_valid 금지
• cmd_valid && !cmd_ready 동안 command payload stable 확인
• read command accept 후 정해진 latency window 안에서만 data_valid 허용
• reset 직후 pending read transaction이 없을 때 data_valid 금지

property p_no_data_valid_before_read_cmd_accept;
  @(posedge clk) disable iff (!rst_n)
    data_valid |-> read_cmd_accepted;
endproperty

a_no_data_valid_before_read_cmd_accept:
  assert property (p_no_data_valid_before_read_cmd_accept)
  else $error("data_valid asserted before read command was accepted");

pending read 상태를 명시적으로 관리하면 더 엄밀한 형태로도 쓸 수 있습니다.

logic read_cmd_pending;

always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    read_cmd_pending <= 1'b0;
  end else begin
    if (cmd_valid && cmd_ready && cmd_type == READ)
      read_cmd_pending <= 1'b1;
    else if (data_valid && data_ready)
      read_cmd_pending <= 1'b0;
  end
end

property p_data_valid_requires_pending_read;
  @(posedge clk) disable iff (!rst_n)
    data_valid |-> read_cmd_pending;
endproperty

a_data_valid_requires_pending_read:
  assert property (p_data_valid_requires_pending_read)
  else $error("data_valid asserted without pending read command");

8. MCP가 아닌 것과 MCP인 것

9. 하드웨어 검증 관점에서의 비유

하드웨어 검증자에게는 아래 비유가 가장 직관적입니다.