Project

General

Profile

[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  Voneline
  WFH
General Info
  Papers

Issue #826

/*verilator tracing_off*/ causes compile errors

Added by Lane Brooks almost 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Invoking/Options
% Done:

0%


Description

We are embedding a Xilinx microblaze processor into an FPGA. I want tracing for it and all its dependencies disabled while leaving tracing for the complete rest of the design enabled. If I wrap /*verilator tracing_off*/ around the instantiation of the processor and that seems to have no effect as all the microprocessor signals and its submodules still come through. Instead I add it as the first and last line of the microprocessor module, and it fails to verilate with %Warning-MULTIDRIVEN messages like the following:

%Warning-MULTIDRIVEN: ../../../lib/xilinx/RAMB16BWER.v:147: Signal has multiple driving blocks: MCS.mcs_0.U0/lmb_bram_I/RAM_Inst/Using_B16_S2.The_BRAMs15.RAMB16_S2_1.mem

Am I misusing the /*verilator tracing_off*/ directive? Is there a way to turn off tracing down one branch of the hierarchy?

History

#1 Updated by Wilson Snyder almost 5 years ago

  • Status changed from New to AskedReporter

At present verilator tracing_off turns off tracing around any signals/variables that are encountered. If there's a cell it doesn't mean don't trace within that cell - to do that you would need the pragma above any module statements and the ones below that module as you noticed.

I do not object to changing this behavior, the pragma results in setting a flag attached to each FileLine - so where the trace routines process Cells just test it before iterating, I'd be glad to take that patch back.

Tracing disables some optimizations, so that is what is almost certainly causing the error, though I'm a bit surprised that a MULTIDRIVEN was the result so perhaps it's more an indirect effect.

#2 Updated by Dennis Muhlestein almost 5 years ago

So from your comment do I understand correctly that you can't disable an entire subtree easily?

I've tried the tracing commands lane mentioned and also with verilator config in a config file

`verilator_config
tracing_off -file "<path to microblaze.v>" 
tracing_off -file "<path to xilinx libs/*.v"

Result is the same though, 3G+ vcd files and it doesn't appear the tracing is turned off.

I suppose we could modify our dump call to take a parameter for the number of levels but we need the traces in other modules that are leveled deeper than the micro controller.

#3 Updated by Lane Brooks almost 5 years ago

Wilson,

Is there any other way to disable tracing only on a certain branch of the hierarchy?

#4 Updated by Wilson Snyder almost 5 years ago

At present there is not another way to disable the hierarchy, but I think the patch to disable a cell if trace_off is currently off for that cell would be quite easy.

#5 Updated by Dennis Muhlestein almost 5 years ago

I'm quite new to the verilator sources but if you pointed me in the right direction to look I could probably add that support.

It seems to me it should work like this:

wire x; // trace file would have data for x but nothing for any of the signals or additional modules used in y.
// verilator tracing_off
somemodule y (.trace_signal(x));
// verilator tracing_on

#6 Updated by Wilson Snyder almost 5 years ago

First, create/modify a test_regress/t test that disables tracing on a cell using the trace_off/trace_on markers. Run it and it should fail since you haven't implemented it.

In verilog.y you'll see nodep->trace is set on a AstVar object. Add a new similar trace method to AstCell, and set that similarly where cells are created in verilog.y.

Then in L3LinkDot which recurses through cells, in the AstVar visitor, if m_cellp->trace() (which you saved state for in verilog.y) is clear, clear that variable's trace attribute.

#7 Updated by Dennis Muhlestein almost 5 years ago

Ok so it looks like the context of the cell visitor and the var visitor don't overlap. Maybe I'm looking in the wrong spot.

V3LinkDot.cpp , only class with m_cellp is LinkDotResolveVisitor

That class has

virtual void visit(AstCell* nodep, AstNUser*); 
// and
virtual void visit(AstVar* nodep, AstNUser*);

Amongst the rest.

I placed a couple trace statements in those methods and found that visit cell exits before any visit var calls are made. in visit cell m_cellp is set back to NULL.

So anyway, I was able to modify the lexer easily enough and set the debug flag on the module but I'm not quite seeing how to get from cell to variable.

#8 Updated by Wilson Snyder almost 5 years ago

Can you point to your code, including a self-test?

#9 Updated by Wilson Snyder almost 5 years ago

  • Status changed from AskedReporter to Resolved

Pushed to git the changes to make trace_off apply to child cells.

#10 Updated by Dennis Muhlestein almost 5 years ago

Awesome I'll test the changes out.

Sorry I hadn't had a chance to respond w/ my test case or start of the code I'd worked on. Been very busy with a few issues that are bigger on the totem pole.

#11 Updated by Wilson Snyder almost 5 years ago

  • Status changed from Resolved to Closed

In 3.866.

Also available in: Atom