Seperate controller and datapath in RTL designs

Hello

I would like to ask if synthesis tools like Design Compiler or any other tool can separate the desciption of controller and datapath in RTL designs.
What I mean is the tool can read RTL design file (VHDL/Verilog) and visualize/output description files for the controller and the datapath of the design.
Any advise is appreciated.
Thanks

Hi Prokul,

You only get to see what the tool sees as datapath on a design-by-design basis (what are the instances, how are resources in them implemented, area, signal widths etc.), but dumping out files for the control and datapaths is not supported. RTL designs when coded mix the two most of the times, the tool too doesn't see any reason for separating them.

To see a list of datapath instances and associated details:

After compile,
set_current_design <design of interest> followed by
report_resource [-hier]

where report_resources is a common datapath-related reporting command issued at the end of synthesis runs. There are others too listed in the DC tool commands manual (analyze_datapath etc.) - search for the 'datapath' keyword there and in the DC user guide for more.

Not only the tool does not have this discrete separation of control vs datapath, we also don't have it in design anymore. Sure, in textbooks we still teach this classical approach, but reality is that a design has control paths that depend on data, and datapaths that operate over control signals. I see no benefit in having specific reports for each. You care about critical paths, that is it.

Control path signals independent of data path would be a register block setting static configuration like enables and modes and are a common occurence in present-day designs. Whereas a status signal, say a CRC result, depends on parsing incoming data. Both kinds exist aplenty in present-day designs.

report_resources and other such commands help validate a desired form of the implemented HW. A mux coded in IP RTL and going to multiple chip generations and multiple libraries is left coded as a regular mux in RTL and flagged to synthesis/DFT engineers to be implemented in a desired form - discrete AND and OR gates, a regular discrete mux or a clock mux. Synthesis/DFT scripts are then tuned accordingly. Hundreds of such instances can then be validated by running a report_resources at the end than manually going through the netlist.