ee-datasheet-master（ee 数据表主控）

EE Datasheet Master

Iron Law: PDF Content Only

ALL DATA MUST ORIGINATE FROM THE PDF.
Allowed: Extract → Calculate from extracted data
Forbidden: Use prior knowledge → Fill gaps with guesses

Allowed Derivations

When deriving: Show source data (page) + calculation steps + result

Forbidden Behaviors

When the PDF Cannot Provide the Answer

"NOT SPECIFIED IN DATASHEET" is not a dead end. Always follow it with how to obtain the missing information.

Response Template

"[Parameter] is not specified in this datasheet. To obtain it: [specific method below]."

If the datasheet references an application note or supplementary doc by name, cite it:

"Section X references Application Note [AN-xxx] for this topic — search [Manufacturer] website."

Reasoning Framework for Missing Parameters

When a parameter is absent, reason through these questions to give a concrete, actionable path:

1. Why is it missing?

• *Wrong document* — this is a brief/product datasheet; the full reference manual or application note contains it → identify the correct document by name
• *Test-condition mismatch* — the spec exists but not at the user's specific conditions (load, frequency, temperature) → explain which conditions differ and how that affects the value
• *Application-dependent* — the value depends on external components or PCB layout the user controls → explain what determines it and how to calculate or simulate
• *Manufacturer-controlled* — the data is from qualification testing, not released publicly → identify the right contact channel

2. What does the user actually need it for?

• Design margin check → an approximation or worst-case bound may be sufficient
• Debugging a failure → direct measurement in the actual circuit is more reliable than a datasheet value
• Qualification / compliance → only manufacturer-provided data is acceptable

3. What is the most direct path given the above? Tailor the recommendation to the specific parameter and context — a thermal resistance question for an LDO in a hot enclosure calls for a different answer than the same question for a signal-path op-amp. Reason about: what equipment would give this measurement, what document would contain this spec, or what formula derives this value from things the user can measure or control.

6-Phase Workflow

┌─────────────────────────────────────────────────────────────┐
│  Phase 0: Pre-scan        →  全文扫描，建结构地图            │
│  Phase 1: Diagnosis       →  text vs image PDF 决策         │
│  Phase 2: Device ID       →  确认器件，推断关键参数          │
│  Phase 2b: Targeted Scan  →  推断 patterns，二次精准扫描     │
│  Phase 3: Section Mapping →  定位各功能区页码               │
│  Phase 4: Extraction      →  精准提取 + TEMPLATES 结构化输出 │
└─────────────────────────────────────────────────────────────┘

See PDF_STRATEGY.md for the entry-point decision table and detailed workflow. Read that first — it tells you which phase to start at before running any command.

Quick Reference

Most common case — device named, 1–2 specific parameters asked (start here):

# Phase 3: Search directly for the parameter the user asked about
python scripts/pdf_tools.py search_table <pdf_path> "<parameter>"   # e.g. "quiescent current", "dropout voltage"
python scripts/pdf_tools.py search <pdf_path> "<parameter>"         # try alternate phrasings if first is empty

# Phase 4: Read the identified page
python scripts/pdf_tools.py text <pdf_path> <page_num>
python scripts/pdf_tools.py tables <pdf_path> <page_num>

Less common — unknown PDF, open-ended analysis, or complex multi-parameter extraction:

# Phase 0: Pre-scan (slow — only when you need a structural map)
python scripts/pdf_tools.py info <pdf_path>
python scripts/pdf_tools.py page_hints <pdf_path>        # scan ALL pages → minutes on large docs

# Phase 2: Identify Device (only if device is not already known)
python scripts/pdf_tools.py text <pdf_path> 1

# Phase 2b: Targeted re-scan (complex ICs only — charger, MCU, CODEC)
python scripts/pdf_tools.py dump_patterns > /tmp/custom_patterns.json
python scripts/pdf_tools.py page_hints <pdf_path> --patterns /tmp/custom_patterns.json

# Phase 3: Caption-based section mapping
python scripts/pdf_tools.py search_caption <pdf_path>    # find Figure/Table captions
python scripts/pdf_tools.py search <pdf_path> "Electrical Characteristics"

Parameter Inference (LLM Decision)

Universal Parameters (for full-analysis queries only)

When the user asks for a complete analysis or overview, extract these 5 baseline parameters. Skip this for targeted single-parameter queries — if the user asks "what is the dropout voltage?", go find that, not the package outline.

Device-Specific Parameters (Inferred by LLM)

After identifying the device, infer what specs matter:

1. Read device description (first 3 pages)
2. Understand: What does this device DO?
3. Infer: What specs matter for this device?
4. Search: Use pdf_tools to locate those specs

For the complete device-type → key specs lookup table and per-device extraction shortcuts, see PDF_STRATEGY.md → Phase 2 and Device-Type Shortcuts.

Key insight: Device description tells you what to measure. Don't use predefined lists.

Output Format

# [Part Number] Datasheet Analysis

## Summary
[1-2 sentences]

## Key Specifications
| Parameter | Min | Typ | Max | Unit | Source | Notes |
|-----------|-----|-----|-----|------|--------|-------|
| ... | ... | ... | ... | ... | Page X, "Table Name" | |
| [unavailable param] | — | — | — | ... | NOT SPECIFIED | Measure: [method] |

## Pin Configuration
- Package: [Type]-[Pin Count]
- Power Domains: [List ALL with pin numbers]
- Interfaces: [I2C/SPI/UART with addresses]

## Critical Design Considerations
1. [Issue with guidance]

## Common Pitfalls
- [Pitfall]: [How to avoid]

Common Mistakes

Red Flags - STOP and Verify

If you think:

• "I know this chip..."
• "Typically this value is..."
• "Based on my experience..."
• "Similar chips have..."

STOP → Re-read PDF → Extract from source

Reference Files