search

verilog-to-routing / vtr-verilog-to-routing

Verilog to Routing -- Open Source CAD Flow for FPGA Research
https://verilogtorouting.org
Other
1.02k stars 395 forks source link

Improvements/fixes related the power estimation flow #1797

Closed aman26kbm closed 3 years ago

aman26kbm commented 3 years ago

This issues encompasses a few issues/improvements related to the power estimation flow.

Documentation fixes/improvements

The documentation for the power estimation flow seems to have a couple of issues:

  1. The hierarchy of headings doesn't seem correct (eg. Global Routing heading should be under Architecture Modelling)
  2. The function name power_calc_primitive, referred to in the documentation, doesn't exist in the code anymore. The function is called power_usage_primitive

The documentation could also be enhanced a bit. Eg. we could tell what file contains the output of the flow.

For these two documentation related points, I've filed a PR: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/1796

Error saying missing nets in the BLIF

I tried to run the flow on an existing architecture and an existing benchmark. I am seeing errors in the VPR log file that say that a net was present in the activity file but not found in the BLIF file. The errors are prefixed with "Error", but the run still completes successfully. I thought may be the flow passes but the power estimation isn't happening. However, the .power file has some non-zero power numbers. And also the number of these errors in the log is quite small compared to the number of nets in the activity file. So, this makes me think that power estimation does happen for atleast some nets.

Here's the command I used: ../scripts/run_vtr_flow.py ../benchmarks/verilog/diffeq1.v ../arch/timing/k6_frac_N10_frac_chain_depop50_mem32K_40nm.xml -power -cmos_tech ../tech/PTM_45nm/45nm.xml -temp_dir power_flow_try_45nm

The benchmark, arch file, cmost tech file are available in the master. Here's a couple of the errors I see:

Error: net diffeq_paj_convert^MUL~0[32] found in activity file, but it does not exist in the .blif file
Error: net diffeq_paj_convert^Xoutport~3_FF found in activity file, but it does not exist in the .blif file

The first net is just an unconnected net in the BLIF. So, may be that's the issue. The message is a bit misleading. The other net though seems to be legitimately connected. So, I don't know what's going with that one.

There are a few possibilities:

  1. The errors are actually just warnings. The nets are somehow not relevant to power (unconnected or something).
  2. The power estimation flow is missing these nets and the currently reported power numbers aren't correct.

Adding an example architecture file that could be used as a reference

I couldn't find an architecture file in the repo that contains/demonstrates the power estimation related features. There is a power directory in the arch folder and there are some files in there that do have some things like pin-toggle, ignore, sum-of-children. But many other features seem to be unused (like auto-size, absolute, etc)

If these are the right example files, maybe we can update the documentation and point to these files. Otherwise, I am working on a file for power estimation (this arch file will be based on the COFFE_22nm arch files I've created for Koios benchmarks). Once completed, I will check this power-aware arch file into the repo and we can point to it in the power estimation documentation.

aman26kbm commented 3 years ago

@vaughnbetz , @jgoeders please take a look.

vaughnbetz commented 3 years ago

Thanks @aman26kbm . I see you've fixed the documentation in PR #1796 (merged). Thanks! For the missing names in blif file: those look like they should be warnings to me (assuming the flow completes and produces power numbers). The equivalent conditions in Quartus are warnings for example (found a name in the activity file but not the design).

We can remove nets from designs if they don't go anywhere or are connected to blocks with no outputs etc (sweeping code in vpr). So perhaps these nets were in the blif that came out of abc but are swept away by vpr? If you can confirm they don't exist in the vpr netlist then I think it's safe to treat these as warnings, and the code should be changed to make them warnings. Errors should terminate the program (but just printing an error message doesn't terminate it -- it just means some code should then terminate vpr). So since vpr didn't terminate, it appears these are miscategorized as errors. @jgoeders : any thoughts?

aman26kbm commented 3 years ago

Ah.. that's it. I checked the netlist/blif generated by VPR. It doesn't contain these nets. (I actually didn't know we could generate a post-implementation netlist from VPR. Thanks for my "you learn something everyday" dose for today :))

So, I guess these messages should just be warnings. I looked at the code that generates this message. It doesn't use the standard error logging function, it just uses VTR_LOG and using the string "Error" in the message. That's the reason it doesn't terminate the program.

 22     VTR_LOG(
 23         "Error: net %s found in activity file, but it does not exist in the .blif file.\n",
 24         net_name);

Fixing this is easy. I can just change VTR_LOG to VTR_LOG_WARN and remove the string "Error". But before I do this, it'll be good to hear from @jgoeders to confirm that we're not missing anything.

vaughnbetz commented 3 years ago

Thanks @aman26kbm . That fix sounds good to me.