Fpga Development

FPGA Development

Treat HDL as a description of concurrent hardware with explicit temporal and electrical interfaces. A correct design requires consistent functional intent, language semantics, clock/reset behavior, implementation constraints and verification evidence. Compilation, simulation, synthesis, timing and physical observation establish different facts.

Operating contract

1. Identify the requested decision and design boundary: new RTL, review, simulation failure, resource problem, CDC/timing analysis, implementation or hardware release. Use the smallest complete evidence set for that decision.
2. Record device/package, board revision, clocks, reset, I/O voltage and pin constraints before making target-specific claims. Pure RTL reasoning can proceed from a stated abstract interface without inventing a board.
3. State transaction semantics, latency, throughput, backpressure, loss/duplication policy, initialization and arithmetic behavior before implementation. A waveform picture is not an interface contract.
4. Keep synthesizable design and verification-only constructs separate. Match the HDL subset and vendor primitive model to the actual simulator and synthesizer versions.
5. Review constraint coverage and exception intent before interpreting slack. A green summary with missing clocks or unconstrained endpoints is incomplete evidence.
6. Before programming, resetting, erasing or otherwise changing connected hardware, confirm the target, scope, and rollback path before acting. Read-only discovery may proceed without confirmation. Bitstreams and programming paths must match the exact target.
7. Retain artifacts tied to one source/constraint/tool/device configuration. Do not combine yesterday's tests with today's unverified bitstream into a release claim.

Task routing

Read only the relevant depth references; use their templates to retain reviewable decisions.

Default design and verification loop

Specify observable behavior

Name the top-level ports, widths, signedness, units, clock domains and reset semantics. For each transaction define when acceptance occurs and when outputs become valid. Specify stalled behavior, maximum sustained rate, permitted bursts and buffering policy. Check producer and consumer rates before proposing a FIFO: finite storage cannot solve an unbounded service-rate deficit.

For numeric operations, derive intermediate widths from operand ranges and operations. Track the binary point through multiplication, accumulation, rescaling and conversion. State rounding, saturation, overflow and invalid-input policies. Test negative extrema and boundary values rather than relying on nominal positive examples.

Implement and inspect inferred hardware

Translate the contract into synthesizable combinational and sequential structures. Review assignment completeness, reset coverage, register enables, multiple drivers, accidental latches and width/signedness conversions. Check inference reports for expected memory, DSP, carry and register structures. A behavioral implementation that simulates correctly can infer unsuitable hardware or unsupported initialization.

Avoid expanding one methodology skill into vendor runbooks. Use the exact installed tool's documentation for commands, supported language, libraries and device primitives; retain that version with the result. Device-independent examples are teaching and regression artifacts, not pin-ready projects.

Verify temporal behavior

Build a self-checking testbench with a reference model or scoreboard, explicit timeout and diagnostic failures. Cover reset, stalls, simultaneous transfers, boundaries and parameter variants relevant to the design. Keep stimulus and checking free of sampling races. Record deterministic seeds when random stimulus is used.

Check that verification can fail: introduce a controlled local mutation that violates the contract and confirm the test rejects it. Remove the mutation from the deliverable. Passing a simulation with no effective checker provides little evidence; coverage counts show exercise, not correctness or exhaustive proof.

Formal analysis can supplement simulation when properties, assumptions, clock/reset abstraction and proof bounds are explicit. A bounded pass is not an unbounded proof; a vacuous property is not successful verification. Keep solver/tool/version and counterexample evidence with the result.

Model clocks, resets and crossings

Inventory primary and generated clocks and their actual relationships. For each crossing distinguish single-bit level, pulse/event, coherent word, pointer or stream. Select synchronization or transfer architecture according to its semantics. Independently synchronizing each bit does not guarantee coherent words. A narrow pulse can disappear; a pulse toggle can lose events if it changes too quickly.

Make reset assertion and release behavior explicit in every domain, including one-sided reset and clock absence. Device-specific synchronizer attributes and implementation constraints need the appropriate vendor guidance. Functional simulation does not model analog metastability reliability.