B

---

Examples

---

This appendix contains the following examples.

• Overriding Hierarchical Data Type Propagation in a Design
• Resolving Data Type Conflict
• Netlisting a Design Containing Packed and Unpacked Arrays

Overriding Hierarchical Data Type Propagation in a Design

You can override the data type propagation from a port of a SystemVerilog cellview in a hierarchical upwards fashion. For this override, change the value of the dataType property of that port in the place master, also refered to as the symbol, of the cellview to the data type you want to propagate. For details, see “Overriding Hierarchical Data Type Propagation”.

As illustrated in the following figure, a top-level schematic contains instances of the SystemVerilog cellviews sub1 and sub11. These cellviews have wreal ports.

When you generate the netlist of the top-level schematic, the wreal data type is propagated to the output ports of the schematic, which are out1, out2, and out3. The netlist is illustrated below. The bold text illustrates the wreal propagation.

module top ( output wreal  out1 , output wreal  out2 , output wreal  out3  );

sub1 I3 ( out1, out2);
sub11 I4 ( out1, out3);

endmodule

You can override the wreal data type propagation with the wrealsum data type to add the signals sub1.out1 and sub11.out1 in the top module. To achieve this, perform the following steps:

1. Open the sub1 symbol in Virtuoso Symbol Editor.
2. Select the port that represents out1 and press Q to display the Edit Object Properties form of that port. See the following image.
   
   
3. Change the value of the dataType property from wreal to wrealsum.
4. Click OK.
5. Click Check and Save on the Virtuoso Symbol Editor toolbar. You can then close the editor.
6. Open the sub11 symbol in Virtuoso Symbol Editor. Then perform step 2 to step 5 to change the dataType property value of the symbol port out1 to wrealsum.
   
   At this point, you have overridden the data type in the symbols of the cellviews sub1 and sub11 to wrealsum. The cellviews still contain ports of data type wreal.
7. Open the top-level schematic that contains the updated symbols.
8. Generate the SystemVerilog netlist of the design. In this netlist, the data type wreal is overridden by wrealsum, as required.

The netlist where the data type is overridden is illustrated below. The bold text indicates the data type override.

module top ( output wrealsum  out1 , output wreal  out2 , output wreal  out3  );

sub1 I3 ( out1, out2);
sub11 I4 ( out1, out3);

endmodule

Resolving Data Type Conflict

SystemVerilog Integration Environment can encounter conflicts when propagating data type. For details, see “Managing Data Type Conflicts”.

It is possible that two instances connected to a port have different SystemVerilog data types. For example, in the following design, the top-level schematic contains instances of the SystemVerilog cellviews sub1 and sub11. Cellview sub1 has wreal ports. Cellview sub11 has port out1 of the data type wrealsum, and port out2 of the data type wreal.

When you generate the netlist of the illustrated design, SystemVerilog Integration Environment encounters a conflict when propagating the data type to the output port out1 because the connected ports have different data types.

By default, the SystemVerilog Integration Environment does not propagate the data type to the output port in case of a type mismatch. However, you can set the hnlSVSetDefaultTypeOnTypeConflict flag to t to propagate the default data type when there is data type conflict.

Alternately, you can also set a custom conflict resolution mechanism to determine which data type must be propagated. For this, define the function hnlSVResolveDataTypeConflict as required and load it. For example, you can define and load the function through the simulation run control file .simrc. The return value of this function must be list(isRefPort portKind dataType isUnpacked).

The following example procedure stored in .simrc instructs SystemVerilog Integration Environment to propagate the data type wrealsum when a data type conflict is encountered.

procedure( hnlSVResolveDataTypeConflict(dt1 dt2)
     let( (isDT1RefObj isDT2RefObj dt1PortKind dt2PortKind dt1DataType
           dt2DataType isDt1Unpacked  isDt2Unpacked resolvedDT )

; Define conflict resolution mechanism

; Check whether dt1 is a reference object

isDT1RefObj = car(dt1)

; Check whether dt2 is a reference object

isDT2RefObj = car(dt2)

; Find the portkind of dt1

dt1PortKind = cadr(dt1)

; Find the portkind of dt2

dt2PortKind = cadr(dt2)

; Find the dataType of dt1

dt1DataType = caddr(dt1)

; Find the dataType of dt2

dt2DataType = caddr(dt2)

resolvedDT = dt1DataType

;Check whether dt1 is unpacked 

isDt1Unpacked = cadddr(dt1)

;Check whether dt2 is unpacked 

isDt2Unpacked = cadddr(dt2)

; Check if there is conflict between "real" "wreal" or "wrealsum" datatype then resolve datatype to "wrealsum"

when( and( member(dt1DataType list("real" "wreal" "wrealsum")) 
member(dt2DataType list("real" "wreal" "wrealsum"))) 
      resolvedDT = "wrealsum")
    resolvedDT = list(isDT1RefObj dt1PortKind resolvedDT isDt1Unpacked)

         ; return resolved dataType

         )
      )

When you generate the netlist of the design after setting the data type conflict mechanism, SystemVerilog Integration Environment propagates the required data type. It generates the following netlist for the schematic example illustrated in this section. The bold text highlights the data type propagation as a result of the defined conflict resolution mechanism.

module top ( output wrealsum  out1, output wreal  out2 , output wreal  out3  );

sub1 I3 ( out1, out2);
sub11 I4 ( out1, out3);

endmodul

If the conflict resolution mechanism was not set, SystemVerilog Integration Environment would generate the following netlist, where no data type is propagated to the output port out1.

module top ( output   out1, output wreal  out2 , output wreal  out3  );

sub1 I3 ( out1, out2);
sub11 I4 ( out1, out3);

endmodul

Netlisting a Design Containing Packed and Unpacked Arrays

SystemVerilog Integration Environment supports the netlisting of designs with ports of the type packed array or unpacked array. Consider a design library test that contains the following SystemVerilog definition of module packed_unpacked_data.

//systemVerilog HDL for "test", "packed_unpacked_data" "systemVerilog"
module packed_unpacked_data(packed_array, unpacked_array);

  output [7:0] packed_array;
  output real unpacked_array [7:0];

endmodule

In this module, the port packed_array is declared as a packed array of default type logic. The port unpacked_array is declared as an unpacked array of type real.

The symbol of the SystemVerilog cellview packed_unpacked_data is instantiated as I0 in the schematic mid, as illustrated below.

When you generate the netlist of the schematic, SystemVerilog Integration Environment processes the design appropriately and generates the following netlist.

module mid ( input wire logic  [7:0] C, input var real  D [7:0] );
packed_unpacked_data I0 ( C[7:0], D[7:0]);
endmodule

Consider the following schematic mid1, where two instances of the symbol of packed_unpacked_data are instantiated as I0 and I1. Note the pins A, B, C, and D.

When you generate the netlist of this schematic, SystemVerilog Integration Environment processes the design appropriately and generates the following netlist.

module mid1 ( output wire logic   A, output var real  B , input wire logic  [7:0] C, input var real  D [7:0] );

packed_unpacked_data I1 ( {A, A, A, A, A, A, A, A}, '{B, B, B, B, B, B, B, B});
packed_unpacked_data I0 ( C[7:0], D[7:0]);

endmodule

If the flag vlogPrintAssignForUnpacked is set to t and SystemVerilog Integration Environment is restarted, the assign statements for the unpacked arrays are printed, as illustrated in the following netlist.

module mid1 ( output wire logic   A, output var real  B , input wire logic  [7:0] C, input var real  D [7:0] );

var real cdsNet0[0:7];
assign cdsNet0 = {B, B, B, B, B, B, B, B};

packed_unpacked_data I1 ( {A, A, A, A, A, A, A, A}, cdsNet0);
packed_unpacked_data I0 ( C[7:0], D[7:0]);

endmodule