3

I am using Synopsys Design Compiler(SDC) for synthesis with compile_ultra. This option does advanced datapath extraction which basically tries to group(or chain) together as many arithmetic operations as possible and then uses carry-save arithmetic in order to efficiently implement this chain of operations. This is described in SDC user guide. The optimization supposedly leaves behind a description of the extracted datapath in binary files. I am pointing out these in the following screenshot. Is there a way to see what these files contain and figure out what datapath was finally produced by SDC ?

add_304_64_DP_OP_283_2056 is the name of the extracted datapath(as shown in the report_resources output at the beginning of the image). The corresponding had_unwound8_add_304_64_DP_OP_283_2056_0.a.e and had_unwound8_add_304_64_DP_OP_283_2056_0.b.e files are dumped by SDC.

Screenshot

Note: Cross posted from electronics stackexchange since it did not find enough purchase there.

shrm
  • 1,112
  • 2
  • 8
  • 20
  • what do you mean by a "description"? DC typically outputs a gate level netlist as a Verilog file or database. Are you looking for how it grouped your add operations together? – Guy Jul 30 '14 at 21:00
  • @Guy I know I can dump the final netlist of the whole design, but what I am looking for is the datapath it came up with during the `compile_ultra` optimization. This datapath will be too difficult to recognize in the final netlist, if not impossible. So yes, I am looking for how it grouped add(or any other) operations. – shrm Jul 30 '14 at 21:29
  • In general if you want control over what DC does it is best to code your RTL to do exactly what you want rather than run the tool and ask it what it did. A CSA reduces three add inputs into two until it has only two terms remaining, then adds them together with a classic adder. You can directly instantiate a DW CSA adder to control this. – Guy Jul 30 '14 at 22:12
  • @Guy This is a big design so instantiating CSAs manually wont work. Moreover, SDC goes beyond register boundaries to group the operations. I am more interested in 'how' DC does it rather than the netlist itself. – shrm Jul 31 '14 at 03:51
  • There's no such thing as a design that's too big to use manual instantiations; scripting or generate statements can create large trees of manual instantiations. My point is why do you want to know how DC is doing what it does? If you're asking how then probably it's not doing the right thing, and the best solution is to tell it what the right thing is rather than try to reverse engineer how the tool came up with its own answer. YMMV but this is how we have tackled thorny timing and congestion issues in our devices. – Guy Aug 01 '14 at 17:28
  • @Guy 'There is no such thing'.....LOL. I have no congestion issue. Thanks for your inputs. – shrm Aug 02 '14 at 10:26
  • It's been a while since I have used DC but you should be able to get a netlist with the high-level arithmetic primitives in it mapped to the GTECH library before you map to the target gate library. That will let you see what the compiler did to your code. You shouldn't have to manually instantiate arithmetic blocks since the whole point of the high-level arithmetic synthesis is to give flexible control over their implementation which you won't always want to be a CSA. – Kevin Thibedeau Sep 07 '14 at 16:49

1 Answers1

0

The files contained in dwsvf folder (*.a.e and *.b.e) are produced for downstream tools for Equivalence Checking(EC) such as Fomality. THe format of these files are open source standard provided by Synopsys and is named V-SDC. Those files are intended to provide information about the generated datapaths to EC tools in order to speedup the EC process.

In order to view the details of the datapaths generated, report_resources command can be used in DC.

shrm
  • 1,112
  • 2
  • 8
  • 20