Name Mangling in SystemVerilog (Issues for synthesis / P&R s

A

Andrew Burnside

Guest
Does anyone know if there are plans to introduce standardised name
mangling into SystemVerilog?

My situation is as follows:
Module test using SV testbenches (clocking blocks in interfaces
conditionally compileed)
Module interconnect using synthesisable SV interfaces
Pre-synthesis Integration test using SV TB

However, the issue is that when I come to synthesise the design, the
mangled SV interface names appear at top level. Therefore, I have a
top level Verilog file to pin out the SV interfaces into sensible
Verilog names.
This also includes appropriate tristates etc. to interface to the
outside world.

The issue is when carrying out back-annotated sims, as the top level
names are the Verilog names.
This means unless I can't reuse the SV integration test bench unless I
again map the Verilog names back to SV interfaces.
Has anyone else found a solution to this problem, or do people just
use a Verilog TB at this level?

Andrew
 
On Wed, 23 Jan 2008 01:38:45 -0800 (PST), Andrew Burnside
<andrew.burnside@sli-institute.ac.uk> wrote:

Module test using SV testbenches (clocking blocks in interfaces
conditionally compileed)
Module interconnect using synthesisable SV interfaces
Pre-synthesis Integration test using SV TB

However, the issue is that when I come to synthesise the design, the
mangled SV interface names appear at top level. Therefore, I have a
top level Verilog file to pin out the SV interfaces into sensible
Verilog names.
This also includes appropriate tristates etc. to interface to the
outside world.
Click to expand...
I think (not 100% sure) that it's illegal per the LRM to have
a top-level module with a (necessarily unconnected) interface
port. However, synthesis tools (as you say) are usually OK
with such modules, and flatten the interface port to a bunch
of regular ports with mangled names. The mangling certainly
differs between the two tools I've tried this on.

I'm not aware of any proposal or suggestion to standardize
this issue.

The obvious hack^wfix is to put a simple wrapper around
the (temporarily) top-level module, providing it with
the interface it requires, and pinning-out that interface's
signals to regular ports with names of your own choosing.
It's tedious, but manageable as a once-per-project exercise.
The benefits of interfaces still exist when this module is
integrated into a larger subsystem.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On 23 Jan, 22:36, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

I'm not aware of any proposal or suggestion to standardize
this issue.
Thanks Jonathan
Click to expand...

The obvious hack^wfix is to put a simple wrapper around
the (temporarily) top-level module, providing it with
the interface it requires, and pinning-out that interface's
signals to regular ports with names of your own choosing.
Can I check if you are suggesting putting a SV wrapper around the top
Click to expand...
level synthesisable Verilog wrapper, or the other way round?

The benefits of interfaces still exist when this module is
integrated into a larger subsystem.
Are you meaning that the system is as follows (brackets showing
Click to expand...
hierarchy)?

(SV wrapper to link to Test Bench (Verilog top level (SV System) ) )

Regards

Andrew
 
On Wed, 23 Jan 2008 15:09:25 -0800 (PST),
Andrew Burnside wrote:

Can I check if you are suggesting putting a SV wrapper around the top
level synthesisable Verilog wrapper, or the other way round?
Click to expand...
Sorry, I hadn't thought ahead that far :)

Putting a Verilog wrapper around your SV subsystem gives
you regular Verilog ports on its boundaries and prevents
name mangling of the ports by synthesis. So far so good.
What I had not addressed was the fact that you now have
a plain old Verilog module to verify, and of course you
want an interface to hook it to your SV testbench.

I generally do that with a completely separate interface
(NOT the one that the main design would usually expect
to connect to), linking signals in the interface to
pins on the DUT module by hierarchical reference:

module Synth_Top_Level(input logic In, output logic Out);
... // contains synthesisable SV module witn
... // interface port, interface to link to the port,
... // then bring interface contents out to ports here
endmodule

// Testbench will have a virtual interface reference to this...
interface TB_Hook_Intf(maybe some ports for clock etc);
logic In, Out; // to connect to DUT ports
endinterface

package Wonderful_OOP_Testbench;
typedef virtual TB_Hook_Intf hook_vi;
class Wonderful_Test_Environment;
protected hook_vi hook;
function new(hook_vi hook);
super.new.......
this.hook = hook;
endfunction
... /// Lots More Stuff
endclass
endpackage

module Test_Harness;
import Wonderful_OOP_Testbench::*;
TB_Hook_Intf th(...);
Synth_Top_Level DUT(th.In, th.Out);
Wonderful_Test_Environment env;
initial begin
env = new(th);
env.run();
end
endmodule

Now, of course, the test environment is invariant with
respect to synthesis.

Hope I haven't misunderstood your question again :)

Keeping the synthesisable and testbench interfaces
distinct sounds grim, but in practice seems to be
the safest thing to do - see other recent posts here.
Having said that, it is quite possible that the
TB_Hook_Intf could be appropriate for direct connection
to the SV synthesisable module's interface port,
for RTL-only simulation.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Jan 24, 9:35 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

Putting a Verilog wrapper around your SV subsystem gives
you regular Verilog ports on its boundaries and prevents
name mangling of the ports by synthesis.  So far so good.
Cheer Jonathan. This is what I had done, it was the second part that
Click to expand...
gets more interesting.

What I had not addressed was the fact that you now have
a plain old Verilog module to verify, and of course you
want an interface to hook it to your SV testbench.

I generally do that with a completely separate interface
(NOT the one that the main design would usually expect
to connect to), linking signals in the interface to
pins on the DUT module by hierarchical reference:
Thanks. I had wondered if I was missing a trick here.
Click to expand...
The problem though is if you simulate the post-synthesis netlist, then
the name mangling of SV interfaces makes identifying waveform signals
on interfaces even harder than the Verilog case. This also means that
a testbench which uses hierarchical references won't be portable.

I was also thinking of whether there is the case for bringing the
power of assertions onto the synthesised netlist. As I understand it,
assertions are currently stripped out by synthesis tools, or must be
at least optioned out (Of course I may be wrong). However, it seems
that assertions would be an ideal tool to catch some of the timing
funnies that sometimes occur within designs. Of course, it is possible
to do this at the boundary of the system, when you are back to the SV
TB. Though, I would have thought the name mangling issue would make it
hard to bind assertions into a design netlist

As to keeping the synthesisable and testbench interfaces separate
within a design. At the module level, once I had ironed out some of
the niggles, I found that conditional compilation works quite well. At
least this means that I can keep the interface code consistent. It is
a pity that virtual interfaces are a testbench construct. It would be
nice if interfaces could be polymorphic by realisation, without the
ugliness of ifdefs.
i.e.
i) Synthesis realisation 1 (e.g. ASIC)
ii) Test bench realisation
iii) Synthesis realisation 2 (e.g. FPGA)

Andrew
 
On 24 Jan, 10:06, Andrew Burnside <andrew.burns...@sli-
institute.ac.uk> wrote:


I was also thinking of whether there is the case for bringing the
power of assertions onto the synthesised netlist. As I understand it,
assertions are currently stripped out by synthesis tools, or must be
at least optioned out (Of course I may be wrong). However, it seems
that assertions would be an ideal tool to catch some of the timing
funnies that sometimes occur within designs. Of course, it is possible
to do this at the boundary of the system, when you are back to the SV
TB. Though, I would have thought the name mangling issue would make it
hard to bind assertions into a design netlist
Click to expand...
It's great when you don't even realise what someone else in the same
office is doing, as I found out today ;) !!!
We currently bind in SV assertions to our Verilog netlist, by aliasing
the hierarchical net names.
However, this is for designs which are mostly pure Verilog RTL.
It seems that this will be slightly more awkward for SV RTL and not
portable across tools. (Inconvenient, not impossible)

In terms of conditional compilation of test bench code by the use of
ifdefs, this looks like two steps forward one step back to the days of
pragmas.
 
"Andrew Burnside" <andrew.burnside@sli-institute.ac.uk> wrote in message
news:cac834c6-897d-4c8e-a00d-61fce554055f@s13g2000prd.googlegroups.com...
Does anyone know if there are plans to introduce standardised name
mangling into SystemVerilog?

My situation is as follows:
Module test using SV testbenches (clocking blocks in interfaces
conditionally compileed)
Module interconnect using synthesisable SV interfaces
Pre-synthesis Integration test using SV TB
Click to expand...
You didn't specify what tools you're using for synthesis/P&R.
Synopsys Design Compiler has a nice option/command which will
write out synthesized gate-netlists with a special "Systemverilog-wrapper",
preserving the port-names/interfaces/structure of the input-RTL.

Obviously, the wrapper changes the hierarchical relationship of the
contained netlist (since the wrapper adds 1 level of hierarchy), but this
might be good enough to get you started. I don't recall if DC/Primetime's
SDF-writer is smart enough to autotranslate the cell hierarchical-names.
 
On Jan 27, 7:36 pm, "talkb" <no...@talkb.com> wrote:
"Andrew Burnside" <andrew.burns...@sli-institute.ac.uk> wrote in message

You didn't specify what tools you're using for synthesis/P&R.
Synopsys Design Compiler has a nice option/command which will
write out synthesized gate-netlists with a special "Systemverilog-wrapper",
preserving the port-names/interfaces/structure of the input-RTL.
Click to expand...
Thanks. I hadn't realised that.
I have dual synthesis targets, ASIC using DC, and FPGA using Precision
RTL.
That's why the netname differences are a bit irritating.

By Systemverilog-wrapper, do you mean actual Systemverilog, or
sensibly named Verilog?
I suppose the P&R tools wouldn't take SV, so would be Verilog.

It would be interesting to see how Equivalence Checking tools handle
SV, but I guess I will have to wait on that.

Cheers

Andrew


Obviously, the wrapper changes the hierarchical relationship of the
contained netlist (since the wrapper adds 1 level of hierarchy), but this
might be good enough to get you started. I don't recall if DC/Primetime's
SDF-writer is smart enough to autotranslate the cell hierarchical-names.
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top