Editorial and AI policy
How FPGA Guide content is drafted, checked and reviewed, what AI assistance means here, and the limits we know about.
This page says plainly how the words on this site are produced. Content on FPGA Guide is drafted with AI assistance. The drafting runs on the editor’s own hardware, works from sources that are read and summarised in new words, and passes a set of automated checks before publication. Teaching content also passes a human review gate. The sections below describe each step, in the order it happens.
What AI assistance means here
A large language model, running locally on a machine the editor controls, writes first drafts from a brief. The brief names the topic, the audience, the house style and the sources. The model is instructed to explain from understanding and to write in its own words. It is not given competitor tutorials as text, and it is not permitted to quote more than one short passage per source.
For news briefs, the model is given the collected source articles for one story and must write a summary in which every number, date, part number and claim appears in at least one of those sources. For lessons and reference pages, the model works from vendor documentation, standards and papers, and writes code that is then compiled.
The editor sets the topics, writes and maintains the briefs, reviews what comes back, and is responsible for everything that is published. AI assistance means the drafting is faster. It does not mean nobody read the page.
Sources and attribution
Every page lists its sources. News briefs link each source article. Reference pages and lessons end with a list of the primary documents they rely on: vendor user guides, open standards, published papers. We prefer primary sources over secondary ones and say “according to” when a claim is a vendor’s rather than something we checked.
We do not use other tutorial sites as source text. We may look at them to see what topics people struggle with, but the words here are written from the primary documents and from experience.
Originality checks
Every draft is compared, by software, with every source it used.
| Check | Rule |
|---|---|
| Verbatim overlap | No run of 8 or more identical words shared with a source, with names, part numbers and document titles excepted |
| Overall similarity | The share of 5-word phrases in common with any source must stay below a fixed threshold |
| Quotations | At most one quotation under 15 words per source, in quotation marks and attributed |
A draft that fails is regenerated with a stronger instruction to paraphrase. After two failures it goes to the editor rather than being published.
Fact grounding for news
A news brief may only state what its listed sources state. The pipeline extracts every number, date, part number and specification from the draft and looks for it in the source text. Anything not found holds the brief for review. This does not make the sources true, but it does mean we do not add claims of our own to a news story.
Code
HDL in lessons, projects and reference pages must compile. Verilog and SystemVerilog are checked with Icarus Verilog and Verilator, VHDL with GHDL or nvc. Where a testbench exists it is run. A page whose code does not compile is held, not published. Code is also read by a person, because compiling is not the same as being correct or being good practice.
House style
British English spelling, metric units, short sentences, no marketing language. In security content we write “security” and avoid the marketing prefix that usually replaces it. The style guide is applied automatically where it can be (banned words, spelling) and by the editor where it cannot (tone, clarity).
Human review
Lessons, topic hubs, vendor pages, projects and reference pages wait for the editor’s approval before they go live. News briefs that pass every automated check publish without a person reading them first, because they are short, sourced and time-sensitive. The editor reads them afterwards and corrects or withdraws any that are wrong. That split is deliberate and this page will be updated if it changes.
Freshness
Reference pages carry a “last verified” date in their header. A weekly job re-checks tool versions, device lists and links, and marks a page stale when it cannot confirm them. A stale page stays online, because an old reference is usually better than none, but the date tells you how old.
What is never done
- Copying vendor figures, diagrams or screenshots. Our diagrams are drawn here, as timing diagrams and inline SVG block diagrams.
- Reusing another tutorial’s text, structure or code.
- Publishing a news brief without sources.
- Publishing HDL that has not been compiled.
- Presenting a vendor claim as a measured fact.
- Inventing a quotation, a person or a measurement.
Limits and known weaknesses
We would rather say these than have you discover them.
- A language model can produce fluent text that is wrong. The automated checks catch copied text and ungrounded numbers. They do not catch a confidently wrong explanation. The human review gate exists for this reason and it is only as good as the reviewer’s attention on the day.
- Fact grounding checks that a number appears in a source, not that the source is right or that the number means what the brief says it means.
- Compiling code proves syntax, not that a design is good or that it meets timing on real hardware. Only some projects have been run on a board.
- News briefs publish before a person reads them. A wrong brief can be live for several hours.
- Coverage follows the sources we collect. Vendors with good newsrooms and active open-source projects get more coverage than those without, which is a bias.
- The site started in November 2026 and most pages are young. Expect gaps, and expect the corrections log to grow.
If you find a mistake, the corrections page says what to do. If you think this policy is missing something, the contact page says how to tell us.