lazyuvm 1.9.6

Local-first Git-native verification evidence layer for RTL projects, EDA reports, and CI review.

LazyUVM

Latest release: v1.9.6 | PyPI: lazyuvm 1.9.6

Turn existing EDA reports into local PR evidence, and catch stale requirement evidence before merge.

LazyUVM is a local-first Git-native verification knowledge layer for teams that want reviewable evidence without replacing their simulator or sign-off flow.

pip install lazyuvm
lazyuvm demo quickstart

Already have a coverage report?

lazyuvm pilot evidence \
  --coverage-report reports/vcs_urg.txt \
  --config lazyuvm.toml \
  --out LazyUVM_Report

That writes local Markdown/JSON evidence plus LazyUVM_Report/index.html. It is artifact-only, warning-first, redacts local paths by default, and does not edit lazyuvm.toml.

First time here? The 30-second anonymous feedback form has only three questions and does not ask for login, email, files, company names, internal paths, RTL, specs, or logs.

What It Is

LazyUVM is a sidecar evidence layer for RTL verification workflows:

existing EDA output
  -> local LazyUVM JSON / Markdown / HTML evidence
  -> PR review, CI artifacts, onboarding, and stale-evidence checks

It keeps requirement/spec/register/behavior/coverage/waiver traceability in reviewable local files instead of a hidden spreadsheet or private dashboard.

LazyUVM is not a simulator.

LazyUVM is not a vManager replacement.

LazyUVM is not sign-off verification.

It makes VCS, Xcelium, Questa, Verilator, vManager, LCOV, and internal-script outputs easier to review in Git and CI. The enterprise flow stays in place.

Why Use It

• Review without opening huge logs. Coverage holes, waivers, packs, and requirements become local PR artifacts.
• Keep verification memory in Git. lazyuvm.toml records requirement source, owner, revision, and linked coverage/assertion/waiver evidence.
• Catch stale evidence early. Spec changed. Did verification follow? A green regression is useful, but it is not enough evidence by itself.

The report bundle includes a Stale Evidence Focus section before the raw requirement map. It highlights cases like:

requirement: revB
coverage: revA
assertion: missing
owner: system
next action: DV owner must review coverage update

That is the core question:

Spec changed. Regression still green. Which evidence followed?

10-Minute EDA/CI Pilot

Try LazyUVM beside your current flow first. Do not change merge gates or sign-off processes on day one.

lazyuvm pilot evidence \
  --coverage-report reports/vcs_urg.txt \
  --config lazyuvm.toml \
  --out LazyUVM_Report

The command runs:

coverage parse -> gate -> req trace/doctor/draft -> report bundle

The output path is local:

LazyUVM_Pilot_Evidence/
LazyUVM_Report/index.html

See docs/pilot_evidence_command.md for the full command boundary.

Requirement Drafts

Do not start by hand-writing every requirement record. Generate a draft, review it, then copy only approved entries into Git.

lazyuvm req draft \
  --spec-trace-json LazyUVM_Spec_Trace.json \
  --gate-json LazyUVM_Gate.json \
  --eda-report-json LazyUVM_EDA_Report.json \
  --out LazyUVM_Requirement_Draft.toml

lazyuvm req draft-review \
  --draft LazyUVM_Requirement_Draft.toml \
  --out LazyUVM_Requirement_Draft_Review.md

req draft emits review-only candidates such as owner = "TODO" and revision = "TODO". It uses local evidence, does not infer private PDF contents, and does not edit project files. The schema is lazyuvm.requirement_draft.v1.

req draft-review reports missing owner, missing revision, linked evidence counts, and candidates that need human review. The schema is lazyuvm.requirement_draft_review.v1.

Use lazyuvm req doctor after reviewed requirements exist:

lazyuvm req doctor --config lazyuvm.toml
lazyuvm req doctor --config lazyuvm.toml --json --out LazyUVM_Requirement_Doctor.json

The first v1.8 requirement map focuses on requirement source, owner, revision, and linked coverage/assertion/waiver evidence, so stale-evidence review starts from a small Git-friendly record instead of a hidden spreadsheet.

v1.9 adds lazyuvm.requirement_issue_taxonomy.v1, so doctor warnings can be grouped as missing owner, missing revision, orphan requirement, stale coverage, stale assertion, or stale waiver while keeping the older warning codes stable. v1.9.1 also groups doctor issues by owner/team, so reviewers see who should look first without turning the report into a sign-off or blame system. v1.9.2 treats private or unknown revision schemes as revision_needs_review instead of guessing that evidence is stale. v1.9.3 makes requirement IDs in the report bundle clickable, so owner and issue queues jump straight to the detailed requirement row. v1.9.4 surfaces Requirement Doctor warnings in the short CI summary, so a green gate can still point reviewers at stale or ambiguous requirement evidence. v1.9.5 adds review-only repair hints with TOML snippets, so the doctor can show what to review next without mutating lazyuvm.toml. v1.9.6 shows those repair hints inside requirements.html, so a reviewer can jump from stale evidence to the suggested review-only snippet in the static CI artifact.

Docs: docs/requirement_draft_workflow.md, docs/requirement_draft_review.md, docs/requirement_issue_taxonomy.md, docs/requirement_ownership.md, docs/requirement_map_v1_draft.md, docs/requirement_stale_scenario_demo.md, docs/stale_evidence_for_beginners.md, docs/v1.8_readiness_checklist.md.

Feedback

First time here? Use the 30-second anonymous feedback form. No login, email, or file upload is required.

The form asks only:

• what kind of user you are;
• whether you tried the README, demo, install, or your own report;
• what blocked you or made you curious.

Please do not paste RTL, proprietary specs, full logs, customer names, company names, internal links, or local paths. One anonymized sentence is enough.

If you already ran a pilot, the deeper docs ask who owns the requirement when a spec changes and where coverage/assertion/waiver evidence can go stale.

Docs: docs/anonymous_feedback_form.md, docs/pilot_feedback_request.md, docs/pilot_feedback_summary.md, docs/anonymized_requirement_feedback.md, docs/v1.7_eda_ci_pilot_hardening.md.

Docs

The full documentation index is docs/README.md. Start here:

Goal	Link
Install	docs/install.md
Understand the sidecar boundary	docs/not_a_vmanager_replacement.md
Run a pilot	docs/pilot_evidence_command.md
Parse EDA reports	docs/eda_ci_recipes.md
Review stale evidence	docs/stale_evidence_for_beginners.md
Use local AI safely	docs/facts_only_ai.md
Reuse packs	docs/pack_reuse_workflow.md
Read release notes	CHANGELOG.md

More docs and demo commands

Core demos:

lazyuvm demo quickstart
lazyuvm demo gallery
lazyuvm demo pilot
lazyuvm demo pilot-case
lazyuvm demo eda-samples
lazyuvm demo case-study
lazyuvm demo fixture-kit
lazyuvm demo artifact-names
lazyuvm demo reviewer-noise
lazyuvm demo artifact-qa
lazyuvm demo artifact-stability
lazyuvm demo friction
lazyuvm report redact-check

Reviewer assistant commands:

lazyuvm review summarize --gate-json LazyUVM_Gate.json --out LazyUVM_Review_Summary.md
lazyuvm review checklist --gate-json LazyUVM_Gate.json --out LazyUVM_Review_Checklist.md
lazyuvm review next-actions --checklist-json LazyUVM_Review_Checklist.json --out LazyUVM_Review_Next_Actions.md
lazyuvm review toml-draft --next-actions-json LazyUVM_Review_Next_Actions.json --out LazyUVM_Review_TOML_Draft.md
lazyuvm review pilot-safe --next-actions-json LazyUVM_Review_Next_Actions.json --out LazyUVM_Review_Pilot_Safe.md
lazyuvm review explain --next-actions-json LazyUVM_Review_Next_Actions.json --facts-out LazyUVM_Review_AI_Facts.json --prompt-out LazyUVM_Review_AI_Prompt.txt --out LazyUVM_Review_AI_Explanation.md
lazyuvm report bundle --review-summary-json LazyUVM_Review_Summary.json

Detailed docs:

• Pack ecosystem: docs/pack_author_guide.md, docs/pack_contribution_template.md, docs/pack_adoption_recipe.md, docs/pack_quality_policy.md, docs/registry_experiment.md.
• v1 readiness and security: docs/v1_readiness_audit.md, docs/security_adoption_kit.md, docs/security_offline.md, docs/eda_offline_adoption.md.
• Small-team adoption: docs/case_study_small_rtl.md, docs/pilot_adoption_kit.md, docs/eda_ci_pilot_workflow.md, docs/eda_ci_pilot_case_study.md, examples/pilot_feedback/pilot_feedback.md, docs/v1.1_eda_ci_stabilization.md, docs/v1.2_pilot_friction_stabilization.md.
• EDA fixtures: docs/eda_fixture_adoption_kit.md, docs/eda_fixture_harness.md, docs/eda_fixture_matrix.md, docs/eda_custom_parser_hints.md.
• CI artifact UX: docs/ci_artifact_naming_policy.md, docs/gitlab_jenkins_pilot.md, docs/reviewer_noise_reduction.md, docs/redaction_doctor.md, docs/report_bundle_reviewer_guide.md, docs/report_bundle_interactivity_policy.md, docs/v1.3_report_bundle_ux_stabilization.md.
• Artifact trust: docs/v1.4_artifact_qa_baseline.md, docs/first_use_artifact_loop.md, docs/ci_artifact_qa_recipe.md, docs/golden_artifact_snapshots.md, docs/new_user_friction_audit.md, docs/public_demo_gallery.md, docs/v1.4_artifact_trust_stabilization.md.
• Team policy: docs/team_policy_profiles.md, docs/v1.5_team_policy_stabilization.md, examples/policy_ci_demo/README.md.
• Reviewer assistant and AI boundary: docs/facts_only_ai.md, docs/review_summary.md, docs/review_checklist.md, docs/review_next_actions.md, docs/review_toml_draft.md, docs/review_pilot_safe.md, docs/review_ai_explain.md, docs/reviewer_artifacts_in_report_bundle.md, docs/v1.6_reviewer_assistant_stabilization.md, docs/ai_review_workflow.md, review.html.

Who It Is For

LazyUVM is a practical fit for students, open-source RTL projects, small teams, and teams that already have simulator output but want lighter PR evidence.

If your company already has a mature enterprise sign-off flow, keep it. Use LazyUVM only as local review evidence beside that flow.

Release Status

Current repository version: 1.9.6

Latest tagged release: 1.9.6

Latest release note: docs/releases/v1.9.6.md

See RELEASE_CHECKLIST.md before cutting a tag. For small public-safe contributions, see CONTRIBUTING.md. For sensitive reports and private design-data boundaries, see SECURITY.md.