cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
13,137 Views
Registered: ‎07-15-2015

pre-hooks and message configuration / suppression / demotion?

 

I've created a Tcl script to do all the Vivado message configuration in one place. It contains things like:

 

set_msg_config -id {[filemgmt 56-3]} -suppress
set_msg_config -id {[Project 1-498]} -suppress
set_msg_config -id {[Synth 8-5410]} -severity WARNING -new_severity INFO
set_msg_config -id {[Place 30-12]} -severity WARNING -new_severity INFO
set_msg_config -id {[Route 35-328]} -suppress
set_msg_config -id {[Route 35-426]} -suppress
set_msg_config -id {[DRC 23-20]} -string {(PLIO-7)} -severity WARNING -new_severity INFO
set_msg_config -id {[DRC 23-20]} -string {(DPIP-1)} -severity WARNING -new_severity INFO
set_msg_config -id {[DRC 23-20]} -string {(DPIR-1)} -severity WARNING -new_severity INFO
set_msg_config -id {[DRC 23-20]} -string {(DPOP-1)} -severity WARNING -new_severity INFO
set_msg_config -id {[DRC 23-20]} -string {(DPOP-2)} -severity WARNING -new_severity INFO
set_msg_config -id {[DRC 23-20]} -string {(REQP-1839)} -severity WARNING -new_severity INFO
set_msg_config -id {[DRC 23-20]} -string {(REQP-181)} -severity WARNING -new_severity INFO
set_msg_config -id {[DRC 23-20]} -string {(RPBF-3)} -severity WARNING -new_severity INFO
set_msg_config -string {(NetListWriters:298 - No output is written to)} -severity WARNING -new_severity INFO

 

 

QUESTION #1 pertains to the pre-hooks:
I had other functions like get_param, set_param, puts, etc... in my script, so they could not be embedded in .xdc files; error messages say parser does not support those commands. So I added my script to the Synthesis Pre-Hook list, which runs fine for the most part.

 

However, there are certain rules that seem to get checked in multiple steps (e.g., Synthesis and Implementation), and the pre-hook code is local to each step; i.e., unless I add the same script to both Synthesis AND Implementation pre-hooks, it "forgets" everything set suring the Synthesis pre-hook when it starts Implementation.

 

Now I see some of the messages come up during Write Bitstream, so I have to add the pre-hook to that step as well. It appears there are more places a pre-hook and a post-hook can be inserted than what's documented in the GUI panes.

 

#1a) Is there a short list somewhere of all the steps where pre-/post-hooks can be inserted, with correct syntax please? (I've started adding based on the template in my .xpr file), but not sure if that or the menu panes offer the complete list...

 

#1b) Is there a place in the GUI panels where the settings from a "flow pre-hook" can be set and retain global effect across all steps throughout the flow, from elaboration through Write Bitstream?

 

#1c) Or should I just source the message config script one time from the Tcl command line before clicking "Generate Bitstream" in the GUI?

 

Because my logfiles now show they annoying messages like:

 

WARNING: [Common 17-1361] You have specified a new message control rule that is equivalent to an existing rule with attributes ' -ruleid {1} -id {[filemgmt 56-3]} -suppress '. The existing rule will be replaced.

 

 

QUESTION #2:

The other issue at the moment is that when Bitstream Generation completes in the GUI panel, under the Project Summary tab, the Synthesis and Implementation panes show approximately the correct number of Warnings (excludes those which were demoted to Info), but the DRC Violations pane shows a large number of Warnings (apparently doesn't recognize the demotions).

 

Also, the Messages window/tab shows the Warning and Info count without regard to the message configuration settings;

i.e., without the message configuration script, there are about 2600 Warnings and 2400 Infos. Because the script demotes about 2400 Warnings, the Message window should about 200 Warnings and 4800 Infos, but

 

-- the checkboxes still shows the non-demoted numbers

-- when you filter by a checkbox, the demoted warnings display for Warnings, and not under Infos

-- Warning icons remain as "!" for items that got demoted; they don't get replaced by the "i" Info icon.

 

If I examine and count the number of "WARNING:" and "INFO:" occurrences in the synth/runme.log and impl/runme.log files, they do reflect the demotions and expected counts for messages of each type.

 

So the GUI output is suspect and not up to date.

 

Any suggestions?

 

Thanks yet again!  :)

 

 

 

0 Kudos
7 Replies
Highlighted
Guide
Guide
13,123 Views
Registered: ‎01-23-2009

it "forgets" everything set suring the Synthesis pre-hook when it starts Implementation

 

This is pretty fundamental to how Vivado project mode works. When you are working in project mode, you are working with the runs manager. The runs manager is the mechanism that creates and manages the runs (synth_1, impl_1). Using the Vivado infrastructure, you set up and configure these runs so that they can be launched.

 

When a run is launched, though, the actual work is done by a second invocation of Vivado that runs in the background. The runs manager basically builds a non-project mode script for the background process that does all the operations. This background Vivado starts clean (with no context from the foreground), which executes the script. The script

  1) reads in the starting point (whether it be RTL code and constraints for synthesis, or the .dcp from the previous step for all other steps)

  2) sets up any environment required

  3) executes the pre.tcl script for this step

  4) invokes the processing step using the non-project mode command (synth_design, opt_design, place_design...)

      - the command line for the processing step is built based on the properties set on the run in the foreground process

  5) writes out the resulting .dcp file (to a known location in the project infrastructure - as instructed by the script)

  6) generates some reports and puts them in known locations

  7) executes the post.tcl script for this step

  8) repeats steps 3-7 if there are multiple steps to be done as part of this run

  9) exits

 

Therefore, the set_msg_config commands you do in one pre.tcl script are local only to that background process. They are not part of the "design database", and hence to not get stored in the .dcp. This is why they only affect the step in question.

 

Some of the impl_1 steps can be done together or can be split up. So of you (for example) start from the synthesized design and run

 

launch_runs impl_1 -to_step write_bitstream

 

and put these set_msg_config in the pre.tcl for opt_design, it will stay in effect for all the steps.

 

Conversely, if you split up the runs (i.e. do the normal 'launch_runs impl_1', which stops before bitstream generation, then when you "resume" the run to do bitstream generation), the commands applied to the earlier run are gone.

 

As for which steps have pre.tcl and post.tcl steps, I believe the GUI has them all - they are for

synth_design, opt_design, power_opt_design, place_design, power_opt_design (post place), phys_opt_design, route_design, phys_opt_design (post route), and write_bitstream. As for the commands to set them, I would just use the GUI to figure them out (simply set them in a test project) - but they are of the form...

 

set_property STEPS.PHYS_OPT_DESIGN.TCL.PRE {C:\home\x.tcl} [get_runs impl_1]

set_property STEPS.POST_ROUTE_PHYS_OPT_DESIGN.TCL.PRE {C:\home\xxx.tcl} [get_runs impl_1]

 

All this being said, it is probably easier just to source your script to configure the messages (once) in the foreground process. When done here, they are kept with in the project infrastructure database, and are therefore automatically written into all the scripts generated by the foreground process for the background processes.

 

Avrum

Highlighted
13,077 Views
Registered: ‎07-15-2015

Nice, concise, and awesomely precise... Thank you!

 

0 Kudos
Highlighted
13,059 Views
Registered: ‎07-15-2015

Just some add-ons to supplement the discussion... (still related to 2015.4)

 

1) When I source the script from the GUI's Tcl console as a first step before starting the full flow (Generate Bitstream), upon completion, the Messages window shows the correct count, categorization, and icons for Warning and Info count after the demotions. Like!

 

2) When I set this up in the GUI, the default Flow Navigator pane has items to click for Elaboration Settings, Synthesis Settings, Implementation Settings, and Bitstream Settings. All but Elaboration Settings offer entry blanks to set the pre and post hook files. I did not find menu blanks to enter pre/post hooks for the other steps Avrum mentioned, so it would seem you have to follow the template Avrum described. (The .xpr file does show the pattern for the three mentioned above, and has blanks for all the other steps, so I suppose you could edit the .xpr file manually to fill in those if desired.

 

-- Note to Xilinx: Would this suggest it's a good thing to add a fully global FLOW pre-hook option to the menus? (I'll eventually get my stuff into a fully scripted, non-project flow soon, but am fighting other fires and still learning tricks at the moment. ;)  )

 

BTW, if settings from the above script are applied before a run, they appear to be permanent additions to the database; i.e., if you exit the tool and resume, and start a new compile without deleting the database first, if you source the message config script before starting, you will get a message about existing rules being overwritten.

 

 

3) In the process of trying the single-script-sourced-before-compile approach, I went through the GUI panels and deleted my pre-hook files for Synthesis, Implementation, and Bitstream Generation. Upon checking the .xpr after exiting the tool, the hook was gone from the Synthesis and Implementation steps, but was not removed from Bitstream Generation. I repeated the process 3 times, making sure to hit Apply, and got the same result every time. Had to delete it from the .xpr file via manual edits. Unlike!

 

4) It seems messages that do not include ID in the standard format (e.g. [DRC 23-20] ) are not addressed by set_msg_config; either that, or I expressed the following command incorrectly:

 

set_msg_config -string {(NetListWriters:298 - No output is written to)} -severity WARNING -new_severity INFO

does not demote

WARNING:NetListWriters:298 - No output is written to nco_fine_dpram.xncf

from a warning to an info.

 

There are several other Warnings that do not include the standard [format], e.g. 

WARNING: set_property SHREG_EXTRACT could not find object (constraint file cons.xdc, line 628),

and I think it would be good for tool robustness (and user scriptability) if all (appropriate) messages could be brought into the same format and treated uniformly.

 

 

5) As a minor nit, when you run get_msg_config -verbose -rules, the display is sorted alphabetically instead of numerically. My wish list would include seeing that changed to a numeric sort.

 

Rule Name Rule Current Message Count
1 set_msg_config -ruleid {1} -id {[filemgmt 56-3]} -suppress 0
10 set_msg_config -ruleid {10} -id {[DRC 23-20]} -string {{(DPOP-1)}} -severity {WARNING} -new_severity {INFO} 0
11 set_msg_config -ruleid {11} -id {[DRC 23-20]} -string {{(DPOP-2)}} -severity {WARNING} -new_severity {INFO} 0
12 set_msg_config -ruleid {12} -id {[DRC 23-20]} -string {{(REQP-1839)}} -severity {WARNING} -new_severity {INFO} 0
13 set_msg_config -ruleid {13} -id {[DRC 23-20]} -string {{(REQP-181)}} -severity {WARNING} -new_severity {INFO} 0
14 set_msg_config -ruleid {14} -id {[DRC 23-20]} -string {{(RPBF-3)}} -severity {WARNING} -new_severity {INFO} 0
15 set_msg_config -ruleid {15} -string {{(NetListWriters:298} {-} {No} {output} {is} {written} {to)}} -severity {WARNING} -new_severity {INFO} 0
2 set_msg_config -ruleid {2} -id {[Project 1-498]} -suppress 0
3 set_msg_config -ruleid {3} -id {[Synth 8-5410]} -severity {WARNING} -new_severity {INFO} 0
4 set_msg_config -ruleid {4} -id {[Place 30-12]} -severity {WARNING} -new_severity {INFO} 0
5 set_msg_config -ruleid {5} -id {[Route 35-328]} -suppress 0
6 set_msg_config -ruleid {6} -id {[Route 35-426]} -suppress 0
7 set_msg_config -ruleid {7} -id {[DRC 23-20]} -string {{(PLIO-7)}} -severity {WARNING} -new_severity {INFO} 0
8 set_msg_config -ruleid {8} -id {[DRC 23-20]} -string {{(DPIP-1)}} -severity {WARNING} -new_severity {INFO} 0
9 set_msg_config -ruleid {9} -id {[DRC 23-20]} -string {{(DPIR-1)}} -severity {WARNING} -new_severity {INFO} 0

 

 

0 Kudos
Highlighted
13,051 Views
Registered: ‎07-15-2015

At the risk of needing another thread, this brings up a few more questions I'll tack onto here for now:

 

1) Despite having all the message configurations in place "globally" and returning the correct Warning/Info counts per the demotions, if I run report_drc afterward, messages that were demoted from Warning to Info by set_msg_config show up as warnings with the "!" icon.

 

It appears I could use create_drc_check to make new rules with customized severity, but it's a lot of work and errors will be reported if you overlap an existing check. I would just like to have report_drc use the same severities I have assigned for reporting during the compile flow. Is there a better way to do this?

 

2a) Just wondering about messages that get suppressed via set_msg_config: Are they checked and executed during the compile flow, but not reported? Or does the compile process skip them entirely? It seems eliminating certain categories of checks could speed up the compile process.

 

2b) Does anyone know if all DRCs available to the report_drc command are executed during a compile flow? If not, which ones are enabled, or if those not enabled by default can be enabled for the the compile flow?

 

3) Does anyone know if EVERY check available during synthesis is run during report_drc if you select EVERY checkbox in the report_drc menu?

 

I was surprised to discover

 

WARNING: [Constraints 18-401] set_max_delay: 'my_core_0/hsi_0/hsi_rx[3].hsi_rx_u/meta_sync_0' is not a valid endpoint. 

 

in my post-synthesis logfiles, because I had run check_design -verbose and report_drc with all ruledecks selected, and this did not show up.

 

Thanks yet again!

 

 

Tags (1)
0 Kudos
Highlighted
Guide
Guide
13,047 Views
Registered: ‎01-23-2009

2) When I set this up in the GUI, the default Flow Navigator pane has items to click for Elaboration Settings, Synthesis Settings, Implementation Settings, and Bitstream Settings. ... I did not find menu blanks to enter pre/post hooks for the other steps Avrum mentioned

In the "Implementation Settings" there is a whole long list (scroll down), which shows the different steps involved in "implementation". Each of these has an entry for pre.tcl and post.tcl. The "Bitstream Settings" are actually just a repeat of the "Implementation Settings" under the "write_bitstream" part.

 

Avrum

 

Tags (1)
0 Kudos
Highlighted
13,035 Views
Registered: ‎07-15-2015

> In the "Implementation Settings" there is a whole long list (scroll down), which shows the different steps

> involved in "implementation". Each of these has an entry for pre.tcl and post.tcl.

 

And with a giant dinosaur egg on my face, I thank you once again.

 

I didn't have the other steps enabled, so I just completely overlooked them. I didn't scroll down far enough to see the Bitstream Settings option under Implementation (at the bottom), because I found it first under Program and Debug --> Bitstream Settings.

 

Kind of awkward that it exists in two places; maybe that's why deleting my Tcl pre-hook from under the Program and Debug version of Bitstream Settings was not honored in the .xpr file... (?)

 

Tags (1)
0 Kudos
Highlighted
12,978 Views
Registered: ‎07-15-2015

 

Just some minor additional comments:

 

1) In my message management script, I changed all the warnings from " -new severity INFO" to "-suppress" and found that although they are now correctly suppressed in the GUI panels and runme.log files, the impl_dir/mychip_drc_opted.rpt and impl_dir/mychip_drc_routed.rpt report files still contain all the original messages with the original severity of Warning.

 

Vivado apparently does not respect the set_msg_config assignments sourced in a pre-run Tcl file when it does report generation at the end of each step. Even if I add pre- and post- hook message configuration to every step of the flow (in case Vivado was doing the reports in a separate follow-on process where it lost the step's process settings), it still disregards the new message priorities/suppressions when it writes the reports.

 

 

2) For reference, this is what the .xpr file would look like if the pre/post hook script "../vivado_msg_config.tcl" were added to every possible step in the flow:

 

<Step Id="synth_design" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl">
<Step Id="opt_design" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl"/>
<Step Id="power_opt_design" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl"/>
<Step Id="place_design" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl"/>
<Step Id="post_place_power_opt_design" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl"/>
<Step Id="phys_opt_design" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl"/>
<Step Id="route_design" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl"/>
<Step Id="post_route_phys_opt_design" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl"/>
<Step Id="write_bitstream" PostStepTclHook="$PPRDIR/../vivado_message_config.tcl" PreStepTclHook="$PPRDIR/../vivado_message_config.tcl"/>

 

 

0 Kudos