Hi Mahesh,
I used a "dumb" script to strip out much of the unnecessary DEF information, or any information that might give the customer more detail about our physical design build process than absolutely needed.
This involved removing filler cells, boundary context cells, welltap cells, ROWs/TRACKs/GCELLGRIDs, BLOCKAGES, NETs & SPECIALNETs, and VIAs.
/project/mercury/designers/rbassett/copy_PN85.1.dft_iter0_best_hm_xlgx_stripped_DEF_to_send_to_customer.sh
#! /bin/bash
mkdir -p /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF
BLOCK=hm_xlgx
path_to_best_version=/project/mercury/giant/giant-2024.4.1/user/sb064722/PN85.1.dft_iter0/impl/hm_xlgx/invs
cp -p $path_to_best_version/inputs/data/$BLOCK.def.gz /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF
gunzip /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.def.gz
/project/mercury/bin/strip_BLOCKAGES_from_DEF.rb /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.def > /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_BLOCKAGES.def
/project/mercury/bin/strip_FILLS_from_DEF.rb /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_BLOCKAGES.def > /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_FILLS.def
/project/mercury/bin/strip_NETS_from_DEF.rb /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_FILLS.def > /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_NETS.def
/project/mercury/bin/strip_SPECIALNETS_from_DEF.rb /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_NETS.def > /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_SPECIALNETS.def
/project/mercury/bin/strip_VIAS_from_DEF.rb /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_SPECIALNETS.def > /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_VIAS.def
grep -v -e "^ROW" -e "^TRACK" -e "^GCELLGRID" -e "^\- ENDCAP" -e "^\- WELLTAP" /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_VIAS.def > /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_ROW_TRACK_GCELLGRID.def
mv /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.def /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.orig.def
cp -p /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.NO_ROW_TRACK_GCELLGRID.def /project/mercury/data_transfer/outgoing/2024_05_29.PN85.1.BLOCK_DEF/2024_05_29.PN85.1.BLOCK_DEF/$BLOCK.def
Be aware - this process isn't "smart", and leaves behind a bunch of semi-colons like this:
;
;
;
...
I opened the files and "cut" the above section out of the DEF file before sending it to the customer.
All of this usually reduced the DEF file size by ~10x, and allowed the customer to load the DEF file into their physical synthesis tool easier and faster.
Sending block timing reports and data to the customer
Hi Mahesh,
Here's a summary of what we discussed this morning:
1) copy /project/mercury/bin/create_timing_summary.sh local to your block's Innovus "rpts" directory
2) update the paths and variables in the local create_timing_summary.sh file
3) run it : ./create_timing_summary.sh
4) update the generated README.txt in the testcase directory with items like:
VT%'s
REV_TAGs
Description of block and experimental conditions used
etc.
5) compare README.txt with most recently sent README.txt, to see if anything is missing or if too much information is included in the file
6) Review the files to be sent (i.e. make sure there are non-zero DEF, Verilog, SDC files, etc.)
7) tar the testcase directory per instructions in /project/mercury/doc/mercury_ftp_instructions
8) Encrypt the testcase directory with GPG per instructions in /project/mercury/doc/mercury_ftp_instructions
9) upload *.tgz.gpg file (from Linux) to Box (via Firefox Box)
FYI - if it won't upload, logout of Box, and log back in to Box and try again.
Hi Mahesh,
Similar to the way I created testcases in Innovus, here's my template script to create AVO/PrimeTime testcases for the customer:
/project/mercury/bin/create_timing_summary_avo.sh
I will also forward you a recipe from Mark Nevin in an email thread titled "[Mercury] EN2.1 hm_fh AVO timing reports and restore session" that describes the process to change the pointers in the PrimeTime database to relative path locations, instead of hard-coded paths (for libraries, etc.).
look for his statement "So I think there are two options:"