StefanSchippers
commented
8 months ago hi @kwmartin,
I have the following instance in a verilog design:
the ram symbol has the following attributes:
type=subcircuit
vhdl_stop=true
verilog_netlist=true
format="@name @pinlist @symname"
template="name=x1 dim=5 width=8 hex=0 datafile=ram.list modulename=ram"
generic_type="datafile=string modulename=string"_The verilog_netlist attribute is not needed unless you are doing a mixed VHDL/Verilog design that requires split netlisting mode (one file per module) and you have a simulator (like commercial Cadence Ncsim or Mentor Modelsim, don't know if they still are named like this) that is able to elaborate and link mixed (VHDL/Verilog) designs. You can leave it there, it has no side effects._
No need to use verilog_format at all. This is used for primitive devices, so something that does not have an underlying definition (= type not set to subcircuit)
verilog_format defines the netlisting rule (what is to be generated in the netlist for the symbol instantiation) if the symbol type is anything different from subcircuit. if you set for the symbol:
type=primitive
and (I have tuned this on my example):
verilog_format="@symname #( @dim ) @name ( @pinlist , @VCC , @VSS );"
the verilog_format is correctly used:
ram #( 11 ) xcoderam ( LDMBUS[15:0] , LDMADD[10:0] , LDDATA[15:0] , LDWEN_RAM , LDOEN_RAM , LDCK , LDCEN_RAM , LDMASK[15:0] , VCC , VSS );
However in this case no module expansion occurs. Xschem will not descend into the symbol.
You can use a `include directive to include the definition.
The template attribute defines the default instance name (x1) followed by module parameters (if any).
The generic_type just defines parameter types that require special grammar, like strings (they need "..."), for integer types you don't need to define anything.
format is used for spice netlists, so it has no role in Verilog netlists.
This is the produced netlist (regarding the ram instance and ram module):
...
...
ram
#(
.dim ( 11 ) ,
.width ( 16 ) ,
.hex ( 0 ) ,
.datafile ( "ram.list" )
)
xcoderam (
.LDDOUT( LDMBUS ),
.LDADD( LDMADD[10:0] ),
.LDDIN( LDDATA ),
.LDWEN( LDWEN_RAM ),
.LDOEN( LDOEN_RAM ),
.LDCK( LDCK ),
.LDCEN( LDCEN_RAM ),
.LDM( LDMASK )
);
...
...
// expanding symbol: benacus/ram.sym # of pins=8
// sym_path: /home/schippes/xschem/xschem_library/benacus/ram.sym
// sch_path: /home/schippes/xschem/xschem_library/benacus/ram.sch
`timescale 1ps/1ps
module ram
#(
parameter dim = 5,
parameter width = 8,
parameter hex = 0,
parameter datafile = "ram.list",
parameter modulename = "ram"
)
(
output wire [width-1:0] LDDOUT,
input wire [dim-1:0] LDADD,
input wire [width-1:0] LDDIN,
input wire LDWEN,
input wire LDOEN,
input wire LDCK,
input wire LDCEN,
input wire [width-1:0] LDM
);
...
...
// ram behavioral code follows...
..You can add additional implicit (usually power) pins by using as you did verilog_extra="...." and adding the default assignment for these implicit (set by attributes) port connections.
kwmartin
Background: Using xschem with iverilog and gtkwave to do some system level verilog sims of things like quadrature ddfs's, digital delta-sigma blocks, resonator-based digital filters, etc. To make testbenchs of new blocks, I use Python string templates to fill in an xschem generated verilog netlist (based on yaml configuration files to define specifics of different test benches). The xschem verilog netlister over-all is working extremely well; really well done Stefan! Small Issue, when I use the verilog_format symbol parameter, the block parameter is not being filled in. My symbol globals are:
resulting in the following testbench template:
Note in the instantiation, no parameter is present. With exactly the same everything, except commenting out the verilog_format parameter, I get a correct netlist (with explicit node connections), and now the parameter is present. I can attach a zip of the other files if needed.