Digital simulation is quite straightforward. GHDL is well established here. I implemented a simple counter in VHDL to use an example for flow development. The source code is shown in the figure below and simulation traces from the testbench at the bottom of the page.

I implemented this part of the flow based on a standard Makefile. I switched to normal bash scripts for later parts because it became difficult to track built dependencies across folders. I may have to look into Tcl/Tk or other solutions at some point.

entity counterx is
    port (clk:  in  std_logic;
          rst:  in  std_logic;
          count: out std_logic_vector(2 downto 0)
    );
end;

architecture main of counterx is
    signal  cnt:    unsigned(2 downto 0);
begin

    process (clk,rst)
    begin
        if rising_edge(clk) then
            if (rst = '1') then
                cnt <= (others => '0');
            else
                cnt <= cnt + 1;
            end if;                
         end if;
    end process;

    count <= std_logic_vector(cnt);     
end;

 

To cut a (quite) long story short, you can see the flow I came up with below.

The diagram above shows how the individual steps of the flow are connected. The starting point is the design (A VHDL source file) in the blue file box. In subsequent steps, this design will be transformed by various tools into new intermediate representations (grey). To aid this, technology description files and testbenches are needed (orange). The output at the end of the flow are the three green files, which describe the PCB layout (Gerber), the part list (BOM) and where the parts have to be placed on the PCB (Pick & Place).

Right now, everything is based on shell scripts that have to be invoked manually and sub-sequentially. The numbers in the process boxes indicate the number of the script that performs this step. Scripts ending on zero (10,20,30) are mandatory steps for the flow, scripts ending on other digits are optional, e.g. for intermediate simulation.

The output of the automated part of the flow is an unrouted PCB. Routing and design file generation has to be invoked manually with the indicated tools.

You can find the current state of affairs on Github.

https://github.com/cpldcpu/PCBFlow

The technology description files and scripts reside in subfolders. Subfolder 10 also holds the design files.

Please be aware that the placement tool is in a very early experimental stage. Constants in the code may have to be tuned for better results depending on input design.

All intermediate and output files are stored in the work folder. It can be cleaned by calling the "clean_all.sh" script.

I am planning to follow up with some addtional logs explaining how I arrived at the current state, to show some examples and to document future changes.

Automatic synthesis of digital circuits has been the domain of very expensive electronic design automation tools in the past decades. Since a few years, there seems to be considerable momentum to develop and make available free toolchains for ASICs and FPGAs.

Notable projects

Yosys

Yosys is probably the project that started the renewed momentum in free EDA tools. Is a versatile framework for logic synthesis and initially targeted a verilog to FPGA flow with a backend specific to lattice FPGAs. In the mean time this has been extended to SymbiFlow an open source toolchain supporting many FPGAs. ghdl-yosys-plugin is a plugin based on GHDL that brings VHDL support to Yosys. (So I can achieve my goal of being able to use VHDL).

Verilog to Routing

Is a verilog to FPGA toolchain with a freely configurable backend allowing to explore different FPGA architectures, which is in contrast to Yosys which is somewhat hardcoded for specfic FPGA architectures. It is based on a different logic synthesis tool, Odin II.

I pondered for a while whether it was possible to adapt a FPGA toolchain to create PCB based designs. The idea would be to provide a matrix of fixed functional elements and let the toolchain do the  routing. Unused elements could be removed later. In the end I did not pursue this route since the toolchains are heavily geared towards working with larger functional elements (e.g. LUTs), which cannot be easily implemented in discrete logic on a PCB.

qflow

Qflow is an open source synthesis flow targeting integrated circuits, that combines several preexisting tools to a full workflow. It is available from http://opencircuitdesign.com/. Yosys or Odin II is used  for synthesis, Greywolf for placement and routing, qrouter for routing.

The-OpenROAD-Project

The OpenLane flow is another digital design flow that picked up a lot of momentum and sees a lot of activity. It uses Yosys as the synthesis frontend and a newley developed tools, OpenROAD app, for placement and routing. The flow supports the /skywater-pdk, an open process development kit for a 130 nm CMOS process.

Lists of open source EDA tools:

open-source-cad-tools
eda-collection

Adopting an ASIC flow?

The problem of synthesizing digital logic for a PCB is actually very simular to synthesizing logic for an integrated circuit.

The image above shows the architecture of the OpenLane Flow (taken from here). The input to the flow is a our design file and a description of the technology, the PDK. At each step in the flow, the design is transformed in some way and saved in an internal representation until finally a layout file is generated. There are some feedback loops were tools parameters have to be finetuned to optimize the result.

Let's go through it step-by-step. Normal text is the OpenLane flow, italics are my thoughts.

• Synthesis
  1. yosys - Performs RTL synthesis
  2. abc - Performs technology mapping
  3. OpenSTA - Performs static timing analysis on the resulting netlist to generate timing reports

This step takes the Verilog/VHDL source and turns it into a list of logic gates. The critical step here will be to define a set of logic gates that can be implemented in discrete logic and convince the tool to map to only these gates. Timing analysis is a step we will skip for now as the focus should be to get a functional circuit at first. Improvement of maximum clock speed could be a later optimization.

• Floorplan and PDN
  1. init_fp - Defines the core area for the macro as well as the rows (used for placement) and the tracks (used for routing)
  2. ioplacer - Places the macro input and output ports
  3. pdn - Generates the power distribution network
  4. tapcell - Inserts welltap and decap cells in the floorplan

The floorplan prepares the area where the synthesized logic goes and creates the power network. As a first step I will treat the power network as a normal net, which should be acceptable if performance is not a goal. A big question is wether the tools can be repurposed resued in any way.

• Placement
  1. RePLace - Performs global placement
  2. Resizer - Performs optional optimizations on the design
  3. OpenDP - Perfroms detailed placement to legalize the globally placed components

Places the predefined logic cells in a grid into the predesignated area on the IC. A critical step is to optimize the arrangement of the logic cells to minimize the length of interconnecting wired needed. We would have to do the same for the PCB and write the component footprints and placements. For our PCB flow, the output of this step should be an unrouted PCB.

• CTS
  1. TritonCTS - Synthesizes the clock distribution network (the clock tree)

Optimized timing of the clock destribution network. For the PCB based flow we can treat the clock network as any other in a first step. This will only work if we can make sure that we have logic that cannot create unwanted conditions as a results of different timing. The easiest way to ensure this is to use D-flipflops.

• Routing
  1. FastRoute - Performs global routing to generate a guide file for the detailed router
  2. CU-GR - Another option for performing global routing.
  3. TritonRoute - Performs detailed routing
  4. SPEF-Extractor - Performs SPEF extraction

Routing of interconnects. Tools for ICs typically rely on many routing layers and detailed rules to optmize the routing. Since there are already many autorouters available for PCBs, the first step would be to use an existing tool.

• GDSII Generation
  1. Magic - Streams out the final GDSII layout file from the routed def
  2. Klayout - Streams out the final GDSII layout file from the routed def as a back-up

This step is akin to generating the Gerber files for PCB manufacturing. There are many tools available for PCBs, so this should be solveable.

• Checks
  1. Magic - Performs DRC Checks & Antenna Checks
  2. Klayout - Performs DRC Checks
  3. Netgen - Performs LVS Checks
  4. CVC - Performs Circuit Validity Checks

Design rules checks are also available for PCBs, so we can rely on existing tool.

As stated in the introduction, the goal of this project is to create a workflow to generate a PCB with discrete (transistor based) logic from a hardware description language file. This should happen in a reproducible and automated way, with as little user interaction as possible.

Let's get one thing out of the way first, the inevitable question of "why"? Some possible reasons:

• I'd like to use this as an opportunity to tinker with open source electronic design automation (EDA) flows and learn more about their inner workings.
• The availability of low cost PCB manufacturing and assembly services had the side effect of allowing manufacturing of complicated discrete logic circuits for little money. Nothing more satisfying than to get actual hardware from your design.
• More and more open source EDA tools are becoming available, providing a solid foundation to build on.
• Because I (possibly) can! Well...

To be a bit more specific about the goals:

• The source language should be VHDL, because that is what I am used to. Verilog is a close second, in case there is no other choice.
• The target logic family should be resistor transistor logic (RTL). The reason for that is that the MMBT3904, a bipolar NPN transistor, is currently the cheapest transistor at the JLCPCB assembly service. I may also look into NMOS logic.
• As a first step, the main goal should be to get a functional circuit that implements the HDL input. It is acceptable to compromise on performance. For example, timing analysis, clock tree insertion and power routing can all be introduced or optimized at a later time.