EDA Flows

In this section, some typical EDA flows that are more dynamic than the ones we have used so far are shown.

You will consider a project that implements a simulation based on calling a tool named simulate. The model is that a directory will contain a group of stimulus files. The intent is to run one job for each stimulus file in the directory. The job will run the simulate program within the context of a unique subdirectory for each stimulus file.

The Tcl file to define the jobs in this project will use the Tcl glob notation to discover all the stimulus files in the directory based on their having a name with the suffix .stim. Then it will create a subdirectory using the base name of the stimulus file, and run a job in that subdirectory.

In this example, two FDL procedures are introduced: E and R. The procedure E defines the environment in which the simulation jobs must be executed. In this case, the environment is the combination of the BASE environment, which is part of any normal FlowTracer installation, and the SPICE environment, which is presumably an environment that has to be setup for each site to support the running of the SPICE tool, since the location of the simulation software varies from site to site.

The procedure R defines the resources required by the subsequent jobs in the flow. In this case, we declare that each job requires one license of the tool 'spice' (represented by the resource 'License:spice') and at least 250MB of RAM.

E "BASE+SPICE"
R "License:spice RAM/250"
foreach stimulusFile [glob *.stim] {
    set root [file root $stimulusFile]
    indir -create $root {
        J vw simulate ../$stimulusFile -o $root.log
    }
}

This shows how jobs would be defined in a production environment so that a project's flow gets defined by way of running vovbuild against a script holding the job definitions using the FDL language and tcl.

The back-end flows for placement and routing of blocks tend to require many sequential steps, each one requiring different resources, such as licenses and RAM. While many organization use the same tool suites, such as Cadence's Silicon Ensemble, it is rare to see the core tools such as qp and wroute called directly. Instead, each organization has its own wrapper script to define how those tools are to be invoked. In our example, the wrapper script is called pnr and is presumably accessible from the environment called EDA.

set block [shift]
E "BASE+EDA+CADENCE"

R "License:qp RAM/250"
J vw pnr place $block
J vw pnr scanins $block

R "License:wroute RAM/2000"
J vw pnr route $block
J vw pnr clocktree $block

R ""
J vw pnr to_gds $block