Case-Study Case-Study, Integration, Design Flow
Most groups that would benefit from a graphical FPGA design tool already have VHDL. Often quite a lot of it: a detector interface written for a previous experiment, a serial protocol nobody wants to re-derive, a filter that took two people three months to get right, an algorithm that is the group’s actual intellectual contribution.
For those groups the question is never “should we work graphically instead”. It is “what happens to the code we already have”, and if the answer is “rewrite it as blocks”, the conversation is over.
The mechanical problem
Wrapping an existing entity so that a schematic tool can place it has always been possible and has always been tedious. Someone reads the entity declaration, re-types every port name, direction and width into a form, re-types the generics and their defaults, and gets one of them subtly wrong. Then the entity changes and the whole thing is stale, silently, until synthesis fails or — worse — does not.
The Custom HDL block removes the re-typing step. The VHDL is edited in a Monaco editor, the same editor component that Visual Studio Code is built on, inside Sci-Compiler. GHDL parses it, and the ports and generics are extracted from the entity itself.
The consequence that matters is not the saved typing. It is that the entity stays the single source of truth. Add a port, hit Scan HDL, and the block on the sheet grows a pin. There is no second copy of the interface to keep in step.
Recent work has been almost entirely about making that extraction trustworthy on real code rather than on examples: std_logic ports that were being missed, generics whose table came up empty when a default had an unusual form, generic defaults of every type detected properly, and STD_LOGIC, STD_LOGIC_VECTOR, TIME and REAL generics all handled. INOUT and BUFFER ports are now rejected with a clear error rather than being half-supported — which is the right behaviour, because a mode the surrounding netlist cannot express should fail loudly at the point of import.
Syntax checking before synthesis
GHDL is doing more than reading the entity. It compiles, which means a syntax error surfaces in the editor rather than twenty minutes later in a Vivado log.
For anyone who has waited out a synthesis run to discover a missing semicolon, this is a change in the shape of the working day. The iteration loop for the HDL portion of a design becomes seconds instead of tens of minutes, and the long run is reserved for the things that genuinely need it.
Multi-file support means an entity with its own packages and sub-entities comes in as a unit, and the design hierarchy is displayed, so what got imported is visible rather than assumed.
What this makes possible
The division of labour it enables is the actual point.
The parts of a design that are standard — the ADC interface, the trigger logic, the energy filter, the histogram, the DMA and readout, the register file — come from the library, where they are already written, already verified and already documented. The part that is specific to the group, the algorithm nobody else has, stays in VHDL, under the group’s own version control, reviewed by the people who understand it.
That is a better outcome than either extreme. Rewriting a working algorithm as blocks discards verified code and the understanding that went into it. Writing the whole design in VHDL means re-implementing readout infrastructure that has been written a thousand times, and debugging it.
The realistic caveats
Two things are worth being clear about.
The imported entity is a black box to the rest of the tool. Sci-Compiler knows its interface, not its behaviour, so it cannot simulate inside it, cannot estimate its resources before synthesis, and cannot warn you about a timing path within it. That is inherent, not a limitation to be fixed: it is what “bring your own code” means.
And the interface has to be expressible. Ports must be in or out; anything relying on tri-states or bidirectional buses at the block boundary needs restructuring before it can be imported. In practice this is a small change confined to the top level of the entity, but it is a change, and it is better to know that at the start than halfway through.
This is a reference design describing an integration flow. The block behaviour and the extraction rules are as documented.
