This step will provide a final gds file which is used to tape-out the chip. In this environment, one can perform schematic and extracted level simulations on the final design. Here are some of the parameters you may need to modify in the respective files. The only thing to modify here is the paths to the cadence tools.
If you get errors where the tools cannot be found, you need to change the paths in this file to point to the tool locations in your unix environment. Before starting the design flow process, it is imperative to copy all of the necessary library and technology files into their proper directories. This directory houses all of the. The technology. These libraries should all be located in the design kit of the particular technology of use.
Once these libraries are located, they need to be copied into the. These files consist of the layer mapping files that are required to stream gds files out of encounter and into Cadence layouts, and the technology file. The layer mapping files, to our dismay, do not generally come with a specified suffix.
This suffix tends to be either. The file name is generally given somewhere in the design kit documentation. Examples of these files are provided in the current working directories as. Once you locate these files, copy them into the.
Although not necessary right now, you can also copy the technology file into this directory. This may be used later to do steps with library characterization and additionally testing features. Lastly, some technologies provide footprint files that may be necessary to run the back-end flow.
If your technology provides a footprint file, copy this into the. This footprint file typically has a. The first file to modify is the. In this file, we need to add the proper names of our lib, lef, v, tech, gdsin, and gdsout files. This script is shown in Fig. Just replace these file names with the names of the files for your proper technology.
If you placed the files in the proper directories as stated in the previous section, you will only need to modify the filenames and nothing else. The next step to tackle is to setup the design constraints for your particular project.
This consists of defining the clock requirements, setup and hold time constraints, skew, rise, and fall time constraints. There is a. The four files are :. Here , Design stands for the design name and will from here on out , which in this case is DenaliCordicProcessor. The first file defines the constraints used for RTL compiler, the second defines constraints for the intial back-end synthesis, the third defines for scan chain synthesis, and the fourth defines for post-clock-tree-synthesis.
The constraints in each of these files are close to identical, and can be tweaked to achieve the desired performance. All of these constraints listed are in ns. These constraints will likely be parameterized in future revisions, however for now these constraints must be changed manually in the scripts.
To be pessimistic, the constraints can be set the same for each sdc file, however, the constraints can be set tighter more realistic in the postcts version of the sdc file. The next step in setup is to define the pad ring for the current chip.
The pads must be defined in three different files :. The first file defines where the pads are located on the pad frame, and is where you name the pads. This file also tells the back-end tool Encounter where to place the pads on the chip. A snip of this file is shown here in Fig.
N-north, E-east, W-west, S-south, se-southeast, sw-southwest, ne-northeast, nw-northwest. The next place to define your IO pads is in the topmodule. This file is attached to the gate-level netlist generated by the RTL compiler tool, and a snip of this file is shown here in Fig. Figure 5: Piece of the topmodule. In this file, you need to define how the IO pads connect to the top level ports, and how they should connect into the design.
An example is shown here :. IO Dout[0] ,. The rest of the line states where the verilog ports connect to in the design. This file simply lists the four corner pads, so that they can be added into the design later. The last place to add IO pads is in the sdc files. The purpose of this is to tell the tools which pads are input pads, and are driving signals onto the chip. Again, you can follow the example as shown in the sdc files to update your code accordingly.
The last step in the setup is to update the configuration file to meet your project specifications. This file is located at :. The first things to change in this file are the buffer, inverter, and delay footprints.
These are defined on the lines :. The names of these footprints are either defined in the technology. The next thing to add is to list the proper technology clock buffer cells. This is done in :. If your power net names are different, or would like to tie additional global signals to power or ground rails, add them in these lists.
This section shows how we have setup the script for running RTL compiler, and how you can use and modify it for your own project. The main script to run the Cadence RTL compiler on your design is. This script calls two different scripts that are located in. These two scripts are :. This parameter should contain any cells that you do not want the RTL compiler to use when synthesizing your logic down to a gate-level verilog netlist.
If you do not specify to avoid these cells, RTL compiler, for instance, may mistake an IO cell for a buffer, since functionally they appear to be the same. Clock buffers are avoided at this stage because they are meant for use in clock-tree-synthesis CTS which does not happen until the back-end flow. Other parameters in this file that you may want to modify are the RTL optimization settings.
This will effect how hard RTL compiler tries to accurately meet your provided timing constraints. You can also change other settings related to power, clock gating, etc in this file.
To further understand these settings, refer to the RC manual. This script should be setup and parameterized to where no editing is necessary. The script to run RTL compiler is located at. With your environment setup correctly, to run this script simply cd into the. This will launch RTL compiler and run the scripts provided in the.
The reports generated from the RTL compiler will be stored in the same directory.. Once the tool finishes running, cd into. Two files of particular interest may be the errorlog and warnlog files in the. If you have not setup the rc files properly for your project, these files will detail the warnings and errors given by RTL compiler to help you debug and find what you have missed.
The rc. It actually uses the same tool, and the scripts are setup in the same manner. Here, the command to launch the DFT flow is located at :. In order to run this command, simply cd into the. The directory structure is setup identical to the rc directory. The output netlists and reports are placed into the.
The purpose of this flow is to insert scan chains into the design, so that the tester can use the scan chains to test the final chip. As it stands, six manual scan chains are inserted into the current design, which is done in the.
A snip of this code is shown here in Fig. Shows the scan chain definitions and setup. There are four important things to note from this code snip. This statement defines the top-level node which is used to control the scan shifting when the scan-chain is enabled. In the code snip shown in Fig.
This should be connected to a pad, since this shift enable signal will come from off-chip. This signal defines when the chip is in test mode, and is using the scan chain.
In the example shown in Fig. The next statements to note are the actual scan chain definitions. In this example, 6 chains are defined, and are running between the input and output ports the cordic processor core.
Here, you can create an arbitrary number of chains, you must define the ports which the chains run between, and you must define whether the chains share outputs with another port muxed output or not. The last thing to note here is that you must define a test clock signal. You can define this signal to be the same clock used for the rest of your design, however you could also choose to use a different clock for your scan chain.
However, if you do this, you will have to optimize the design flow to include multiple clock signals. Cadence Encounter is the chosen Cadence tool to run the back-end synthesis flow.
The first required step to run the back-end flow is to setup two initialization scripts. These scripts are :. We will discuss the init. Blogs New entries New comments Blog list Search blogs. Groups Search groups. Log in Register. Search only containers. Search titles only. Search Advanced search…. New posts. Search forums. Log in. Install the app. Contact us.
Close Menu. Welcome to EDAboard. To participate you need to register. Registration is free. Click here to register now. Register Log in. JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding. You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser.
0コメント