Clock constraint and timing summary
A constraints task: define a clock, run a local timing flow, and interpret pass/fail without uploading vendor logs.
D3 · 60–120 min · yosys, nextpnr, vivado
How results are checked
Run this challenge on your computer using the required EDA tool. The site validates the structure of report.json. A submitted report alone does not prove that the task was completed.
Goal and prerequisites
- Distinguish a clock constraint from a pin constraint.
- Reduce a timing verdict to a safe report.json.
- Keep vendor license data and local paths out of public reports.
- Basic understanding of synchronous logic.
- A locally installed open-source or vendor timing flow.
Challenge package
Version, licence and checksum
CC-BY-4.0 · MIT · FPGA.camp
- version
- 1.0.0
- size
- 318 bytes
- sha256
- ba153e6af726953ab7aaeb0beb5a4deefced7d0366382a5c1433a4863c241ffe
Run locally
Open-source timing flow
make timing TOOLCHAIN=yosys-nextpnr
Vendor timing flow
make timing TOOLCHAIN=vivado
Normalize timing verdict into report.json
make report
Criteria and common mistakes
Scoring rubric
| id | criterion | points | required | evidence_path |
|---|---|---|---|---|
| clock-defined | Clock constraint is defined explicitly | 30 | yes | checks.clock_defined |
| timing-verdict | Timing verdict is extracted correctly | 40 | yes | checks.timing_verdict |
| privacy | Report has no local paths or license data | 30 | yes | privacy |
- Using the wrong units for the clock period.
- Copying a full timing log into the report.
- Leaving absolute working-directory paths in messages.
Validate report.json
Choose a local check report, up to 512 KB. Source code and archives are not needed.