Background of HDL's
PHDL's toolchain or development flow is slightly different from many existing Hardware Description language (HDL) design environments. This is primarily because it only replaces half of the PCB design paradigm - Schematic Capture. In conventional HDL tools, the source code is incrementally written, debugged with a simulator, and synthesized into a model describing connectivity of available primitive logic elements. Most HDL toolchains additionally impose placement and routing constraints upon the design connectivity to optimize the hardware and achieve timing closure at implementation time (e.g. downloading a bitstream for an FPGA, or generating masks for an ASIC for fabrication). In the realm of high-speed PCB design, achieving timing closure is largely the responsibility of the layout technician with access to very expensive and thorough time domain reflectometry (TDR) simulators. This is primarily due to the fact that virtually every PCB is its own custom solution to the entire connectivity problem. Most of this is simply outside of the scope of what PHDL is intended to do: only capture the PCB connectivity. PHDL leaves the analyzing of this connectivity to other better suited and mature tools.
As such, PHDL is not a layout tool. At the time of this writing, PHDL does not handle any layout-specific tasks such as placement and routing (though future versions may provide initial placement capability). The PHDL compiler, either standalone or eclipse plug-in currently supports only a forward design flow that accepts PHDL source files as input, and translates them into a corresponding netlist that can be read by a layout tool. (Support for back-annotation from layout is being researched, however.) The PHDL user is expected to either have access to a layout tool of their choice and perform the layout in that tool, or know someone else who does who can accept their generated netlist and layout the board for them. Currently, PHDL supports PADS and EAGLE layout tools. An API and translator tool is also provided to allow users to easily translate a generic netlist generated by the phdl compiler into an arbitrary-format netlist format specific to a particular layout tool. With the exception of the translate tool however, the development flow looks like this:
Source Files are Used to Construct a Model (AST or Graph)
The first step in creating a board with PHDL is to define the connectivity in text-based source files. These files are then automatically pooled into a structure called a "resource set" by means of the Xtext and Eclipse framework. Each resource in the resource set is loaded as needed and lexed, meaning the characters are broken up into tokens consisting of keywords, identifiers, integers, and strings. These tokens are then parsed, meaning that they are organized into a model resembling the structure of a tree. This structure is also commonly referred to as an abstract syntax tree (AST) or graph. This tree forms the basis of an in-memory model of all available PHDL resources pooled in the resource set.
Next, any cross-references are resolved by the linker. Cross references may occur across file boundaries. This allows device primitive definitions to be placed in a separate library file, while being instanced from a different file that contains the design. Additionally, design hierarchy units (called subdesigns) can be placed in different files. The linker resolves cross-references lazily. This provides two advantages: (1) resources may consequently be loaded on a demand-basis which vastly improves performance, and (2), it automatically solves the problem where one cross reference depends on another (the second cross reference will be resolved automatically after the first).
Once all of the cross references have been resolved, the validator then reports any errors which form an invalid model. Examples of an invalid model include: (1) referencing a net that was never declared, or (2) assigning one array of nets to an array of device pins with a different width (what do we with the extra ones?) Another basic form of validation checks for duplicate names within containers. For example, you cannot declare two attributes with the same name within a device. Validations that require minimal resources to compute occur in real time as you type, while those that require more resources to compute are triggered when the resource is saved.
Additional IDE features
Additional features are available in the dotted region of the picture, that are NOT available with the standalone command-line compiler. These include syntax highlighting, content assist, template proposals, refactoring (renaming something and simultaneously all references to it), and also quick fixes.
Once the model has been validated successfully (completely free from errors), a project build is triggered. The build process involves a transformation of the graph that represents the source files, into a graph that represents a circuit which the source files imply. Without a lot of detail, the important thing to realize is that the model which represents the source files (a tree of text objects) is not sufficient to describe the actual circuit especially when hierarchy is involved! We call the process of transforming the text graph model to a circuit graph model elaboration.
Generation and Output
The last action that the compiler takes in the PHDL flow is to generate output files. These are placed in a folder called "src-gen" within the project, in a folder structure based on the package name and design name of the top level design. For example, if a design called "top" resides in a package called "mypackage", all generated output files would be named "top.*" and placed into the "/src-gen/mypackage/top/" folder.
The most important output file required for any layout tool is the netlist. It contains a list of devices instanced on the board (each with an elaborated reference designator name such as R1, R2, C1, C2... and their corresponding footprint and location within layout libraries), and a list of nets containing references to relevant pins of each of these devices above. Each net essentially describes which pins of all the above devices should be connected together. This netlist is then forwarded to the layout tool of choice, and a PCB layout is constructed with the conventional process. Once the layout is complete, Gerber files are generally sent to a manufacturer that can interpret them and produce the physical boards.
The other files generated are useful in conveying special placement or routing capability to the layout technician, and providing a Bill of Material for ordering parts.