orca® verilog® simulation manual

Version 4.1 1

Last Link Previous Next

ORCA®Verilog® Simulation Manual

For Use WithVerilog® Software XL-Version 2.6.36 or higher and ORCA 4.1, and ispLEVER 2.0 and higher

Technical Support Line: 1-800-LATTICE or 408-826-6002 (international)

2 ORCA/VHDL Simulation


Verilog Simulation Manual

Verilog-XL and Verilog are registered trademarks of Open Verilog InternationalEPIC and Timing Wizard are trademarks of Xilinx, Inc.ModelSim is a registered trademark of Model Technology, Inc.ORCA and SCUBA are registered trademarks of Lattice Semiconductor Corporation.Synopsys, FPGA Compiler, VSS ad FPGA Express are trademarks, and SmartModel and SmartModels are regis-tered trademarks of Synopsys, Inc.Synplicity is a registered trademark of Synplicity, Inc.All other brands or product names are the trademarks or registered trademarks of their respective owners.

Lattice Semiconductor Corporation Field Programmable Gate Arrays 5555 NE Moore Court Hillsboro, OR 97124

Copyright © 2004, Lattice Semiconductor Corporation, All rights reserved.

ORCA/Verilog Interface CONTENTS

ORCA/Verilog Interface iContents


Table of

Cover

ORCA

ORCA

Index

Tech Support

Contents

Web Site

FAQs

GO TO

Page OVERVIEW ................................................................................................................... 1

SOFTWARE REQUIREMENTS ................................................................................... 2

SETTING THE DESIGN ENVIRONMENT ................................................................. 2Environment Variables ..................................................................................... 2

ORCA VERILOG DIRECTORY STRUCTURE ........................................................... 3

SIMULATION USING ORCA VERILOG MODELS ................................................... 6

SIMULATION USING NEOPRIM VERILOG MODELS FOR ORCA 2CA/2TA ...... 7

SIMULATION USING NEOPRIM VERILOG MODELS FOR ORCA SERIES 3 .... 10

USING ORCA 3 SPECIAL CELLS IN VERILOG SIMULATIONS ......................... 13Series 3 PCM Cells ......................................................................................... 13

Module Configuration ............................................................................. 13PCM[BT] Port Declarations .................................................................... 14Synthesis Support .................................................................................... 14FREQUENCY Attribute ......................................................................... 15

Series 3 Clock Controller Cells ...................................................................... 15

USING ORCA 4 SPECIAL CELLS IN VERILOG SIMULATIONS ......................... 16Series 4 PLL Cells .......................................................................................... 16

Module Configuration ............................................................................. 16[H,L]PPLL Port Declarations .................................................................. 17PLL[1,2] Port Declarations ..................................................................... 17Synthesis Support .................................................................................... 17

SIMULATION USING MTI MODELSIM FOR ORCA SERIES 4 ............................ 18System Bus SmartModel Simulation (Series 4) ............................................. 18

Front End/Back End Verilog Simulation With MTI ModelSim® ........... 18Back End Verilog Simulation With MTI ModelSim ............................... 19

APPENDIX ................................................................................................................... 20MEMORY INITIALIZATION IN VERILOG ............................................... 20USING GSR/PUR IN VERILOG .................................................................. 23

Using GSR/PUR in Verilog for ORCA2 and ORCA3 Libraries ............. 23Using GSR/PUR in Verilog for ORCA4 and Later Libraries ................. 24Programmable GSR Support (Series 3 and Series 4) .............................. 24

USING TSALL IN VERILOG ....................................................................... 27ILLEGAL NAMES AND CHARACTERS ................................................... 28

http://www.latticesemi.com/products/devtools/software/orca/index.cfm

http://www.latticesemi.com/support/faq/

http://www.latticesemi.com/support/index.cfm

ORCA/Verilog Simulation 1

Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


ORCA/Verilog Simulation Interface

OVERVIEW

This manual describes the Optimized Reconfigurable Cell Array (ORCA) simulation process using the Verilog® simulator and the ORCA place and route tools in the ispLEVER software.

Note

Note that version numbers for the interface software are continually being updated with each release. Check with the vendor on version number and how it affects the file names or syntax that make it possible to perform tasks as they relate to simulation of designs with ORCA. Check with technical support with compatibility and support issues.


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


SOFTWARE REQUIREMENTS

The ORCA/Verilog Simulation Interface is compatible with the following software:

• Latest version of ispLEVER software with ORCA devices installed.

• Verilog-XL® version 2.6.36 or newer version

• Verilog on-line documentation

SETTING THE DESIGN ENVIRONMENT

This section helps you customize your Verilog environment for designing an ORCA FPGA.

Environment Variables

Make sure you have installed the latest version of ispLEVER with ORCA devices installed and that the FOUNDRY environment variable is set. The FOUNDRY variable points to the ispFPGA (PC) or ispfpga (UNIX) directory.

The variable should be set as follows:

$ setenv FOUNDRY <ispfpga_directory>

Note

Note that these variables are automatically set by the software and you should not have to manually set them. If for some reason, they are changed, this provides instruction for resetting them.


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


ORCA VERILOG DIRECTORY STRUCTURE

Installing ORCA creates the following directories that are used for Verilog (assumes $FOUNDRY as the top level directory):

The remainder of this manual describes how to simulate using the Verilog libraries. The figure on the next page shows the ispLEVER ORCA FPGA data flow, and the design flow on the page following that shows where the simulation libraries fit in with respect to ORCA.

Directory Description

verilog Verilog Library

verilog/bin Executable scripts

verilog/data Simulation Libraries

verilog/data/orca2 ORCA Verilog 2C Simulation Models

verilog/data/orca2a ORCA Verilog 2A Simulation Models

verilog/data/neoprims NeoPrim Verilog Simulation Models

verilog/data/orca3 ORCA Verilog Series 3 Simulation Models

verilog/data/orca4 ORCA Verilog Series 4 Simulation Models


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


ORCA FPGA Data Flow

Design Capture

MAP

PAR

TRCE

TRCE

BITGEN

B A

S I

C

D E

S I

G N

F

L O

W

ORCA Data Flow

.prf file

.ngo

NGDBUILD

PAR

MAP

EDIF2NGD

EPIC TRCE

DEVPROG

.tek.mcs.exo

TargetDevice

NGD2EDIF

NGD2VER

NGD2VHD

EDIF 2.0.0Netlist

.twr file

NGD LogicalDesign DB

NCD PhysicalDesign DB (.ncd )

SCUBASynthesis

Third PartySchematic

Capture

Third PartySynthesis

ORCA MacroLibrary

( .ngd )

LDBANNO

NGDANNO

.nga

Series 3 Back-endDataflow

2CA/2TA Back-endDataflow

Preferencefile

translators

.bitPROMGEN or

.rbt

BITGEN

.ngm

.ncd

.edn

.v

.vhd

.sdf

.sdf

.edn

.v

.vhd

.sdf

.sdf


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


Simulation Using ORCA Verilog Models and NeoPrim Verilog Models with ORCA

ORCADevice

Verilog HdlStructural

Verilog-XLORCA VerilogLibrary Models

Create EDIF (.edn)

.v

Netlist

Simulation

.v

for ORCA

ORCAMap, Place, Route

.v, .sdf

Verilog NeoPrim/ORCA3Netlist and

sdf file

SimulationVerilog-XL

.vmd

NeoPrim/ORCA3

Library Models

Front End Pre-ORCA Simulation

Back End Post-ORCA Simulation

Verilog


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


SIMULATION USING ORCA VERILOG MODELS

1. The design should be in structural verilog format. This verilog structural netlist consists of components that are found in the Verilog Macro Library. The netlist is typically created by logic synthesis or by using Module/IP Manager to generate a SCUBA® (ORCA Synthesis compiler for User Programmable Arrays) module. The following example shows structural verilog code in terms of the ORCA verilog models:

`timescale 1 ns / 100 psmodule sample (I1,TX,OUT1); input I1; output OUT1;IBM IN43 (.I(I1), .O(I1_IN));AND2 G51 (.A(I1_IN), .B(I1_IN), .Z(I1_INX));BTZ6 BTZ6 (.I(I1_INX), .T(TX), .O(OUT1_O), .B( I1_INTER));AND2 G63 (.A(OUT1_O), .B(OUT1_O), .Z(OUT1_OX));OB6 OUT23 (.I(OUT1_OX), .O(OUT1));endmodule

2. Verify that the design is functionally correct by simulating in verilog using the Verilog Macro Library. The verilog executable command would include the ORCA Verilog Model Library found at <full path to ORCA Foundry>/verilog/data/orca3. Refer to the Verilog-XL® Reference Manual for details. Below is an example .f file that can be used at the command line to simulate a verilog netlist with the ORCA library using the following command:

verilog -f filename.f

-a -y <full path to ORCA Foundry>/verilog/data/orca2> -y <full path to ORCA Foundry>/verilog/data/orca2a> +libext+.v testbench.v design.v


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


SIMULATION USING NEOPRIM VERILOG MODELS FOR ORCA 2CA/2TA

1. Generate a back-annotated VERILOG netlist from ORCA by executing the following commands:

ngdanno <file_name>.ncd -o <file_name>.nga <file_name>.ngm ngd2ver -w <infile>

Command summary:

ngdanno [-o <ngafile[.nga]>] [-p <prffile[.prf]>] <ncdfile[.ncd]> [<ngmfile[.ngm]>]

-o: Output file name(s)

-p: Preference file

<file_name>.ncd: Input file from mapper containing the placement routing and timing information

<file_name>.nga: (generic annotated file) Contains the logical design combined with the post-layout delays from the physical design

<file_name>.ngm: (generic mapping file) Contains mapping information

ngd2ver [-n] [-w] <infile> [<outfile>]

-n: Output flattened netlist. Note that this may increase the run time but will remove redundant components from the netlist

-w: Overwrite the output file

<infile>: Input file: .ngd or .nga

<outfile>: Output file name (default is <infile>.vmd)


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


2. The design should now be described in terms of verilog NeoPrim cells which is output from ORCA. The following example shows a design written in terms of the verilog NeoPrim cells:

// Lattice Semiconductor Verilog produced by program ngd2ver, Version ORCA Foundry 4.0

module sample ( TX , OUT1 , I1 , I1_INTER, CK ); input I1, CK; output OUT1 ; inout TX , I1_INTER ; NEOPD TSALLN_PD ( .OUT ( TSALLN ) ); NEOFF \REG1 ( .OUT ( OUT1_O ), .IN ( I1_INTER ), CLK (

CK ),.SET (VDD), .RST, (GSRNET), .CE (VDD ) ); OUT23 OUT23 ( .O ( OUT1 ), .I ( OUT1_OX ), .TSALLN (

TSALLN ) ); NEOAND2 G63 ( .IN0 ( OUT1_O ), .IN1 ( OUT1_O ), .OUT (

OUT1_OX ) ); NEOOPAD \OUT1.PAD ( .PAD ( OUT1 ) ); NEOBPAD \I1_INTER.PAD ( .PAD ( I1_INTER ) ); NEOONE VCC_18 ( .OUT ( VCC ) ); endmodule

3. If you are going to use the .sdf file for simulation, you must include the $sdf_annotate command in the verilog testbench: The syntax can be found in the Verilog-XL Reference Manual. An example of the command is shown below. Chip.sdf is the name of the .sdf file, top.chip is the level of hierarchy where the .sdf file is written, and maximum is the delay that we use for our simulations.

initial begin $sdf_annotate(“chip.sdf”, top.chip,,,”maximum”); end


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


4. Verify that the design functions correctly by simulating it with the .sdf delay file and using the Neoprim Verilog Model Library. The verilog executable command would include the Neoprim Verilog Model Library found at <full path to ORCA Foundry>/verilog/data/neoprims. Below is an example of what the verilog.f file would look like with reference to the neoprim library. This file can be executed at the command line with the following command:


-a-y <path to ORCA Foundry>/verilog/data/neoprims+libext+.vmdtesetbench.vnetlist.vmd

For a complete description of how to use the ORCA design verification tools, see the appropriate topic in the online help system.


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


SIMULATION USING NEOPRIM VERILOG MODELS FOR ORCA SERIES 3

This section describes how to run simulations using Verilog Neoprims/ORCA3. Note that ORCA supports ORCA3 backannotation to Neoprim as well as ORCA 3 libraries.

To use Verilog Neoprims for ORCA Series 3 simulation:

1. Generate a back-annotated VERILOG netlist from ORCA by executing the following commands:

ldbanno [-w] [-z] [-a] [-n <type>] [-l <libtype>] [-s <separator>] [-p <prffile>] [-o <verilog[.v]>] [-d <delays[.sdf]>] [<ncdfile>]

Command summary:

-w: Overwrite the output file(s)

-z: Zero delay (do not calculate or write any delays)

-a: Write all delays (even if they are zero) (-z takes precedence over -a)

-n <type>: ‘verilog’ to write a verilog netlist

-l <libtype>: Library element type to use, i.e., or3c00 (default) or neoprims

-s <separator>: Hierarchy separator character

-p <prffile>: Preference file (only output load preferences are used)

-o <verilog>: Output netlist file; defaults to <libfile>.v

-d <delays>: Output delay file; defaults to <ldbfile>.sdf

<ncdfile>: Input file (.ncd)

Use ldbanno -h <type> for detailed netlist and a notation options. For example, use the following syntax:

ldbanno -w -n verilog filename.ncd


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


2. The design should now be described in terms of verilog NeoPrim cells which is output from ORCA. The following example shows a design written in terms of the verilog NeoPrim cells:

// Lattice Semiconductor Verilog produced by program ngd2ver, Version ORCA Foundry 9.2

module sample ( TX , OUT1 , I1 , I1_INTER, CK ); input I1, CK; output OUT1 ; inout TX , I1_INTER ; NEOPD TSALLN_PD ( .OUT ( TSALLN ) ); NEOFF \REG1 ( .OUT ( OUT1_O ), .IN ( I1_INTER ), CLK

( CK ),.SET (VDD), .RST, (GSRNET), .CE (VDD ) ); OUT23 OUT23 ( .O ( OUT1 ), .I ( OUT1_OX ), .TSALLN (

TSALLN ) ); NEOAND2 G63 ( .IN0 ( OUT1_O ), .IN1 ( OUT1_O ), .OUT

( OUT1_OX ) ); NEOOPAD \OUT1.PAD ( .PAD ( OUT1 ) ); NEOBPAD \I1_INTER.PAD ( .PAD ( I1_INTER ) ); NEOONE VCC_18 ( .OUT ( VCC ) ); endmodule

3. If you are going to use the .sdf file for simulation, you must include the $sdf_annotate command in the verilog testbench: The syntax can be found in the Verilog-XL Reference Manual. An example of the command is shown below. Chip.sdf is the name of the .sdf file, top.chip is the level of hierarchy where the .sdf file is written, and maximum is the delay that we use for our simulations.

initial begin $sdf_annotate(“chip.sdf”, top.chip,,,”maximum”); end


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


4. Verify that the design functions correctly by simulating it with the .sdf delay file and using the Neoprim Verilog Model Library. The verilog executable command would include the Neoprim Verilog Model Library found at <full path to ORCA Foundry>/verilog/data/neoprims. Below is an example of what the verilog.f file would look like with reference to the neoprim library. This file can be executed at the command line with the following command:


-a-y <path to ORCA Foundry>/verilog/data/neoprims+libext+.vmdtesetbench.vnetlist.vmd

For a complete description of how to use the ORCA design verification tools, see the appropriate topic in the online help system.


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


USING ORCA 3 SPECIAL CELLS IN VERILOG SIMULATIONS

Series 3 PCM Cells

The PCM is a special function block that is used to modify or condition clock signals for optimum system performance. Some of the functions that can be performed with the PCM are clock skew reduction, duty cycle adjustment, clock multiplication, clock delay reduction, and clock phase adjustment. By using PLC logic resources in conjunction with PCM, many other functions, such as frequency control, are possible. PCMBUFs are the PCMs in the bypass mode. PCMBUFs should be used to generate clocks without any delays.

PCM has two modes of operation, delay-locked loop (DLL) and phase-locked loop (PLL). Some operations can be performed by either mode and some are specific to a particular mode. In general, DLL mode is preferable to PLL mode for the same function because it is less sensitive to input clock noise.

Module Configuration

The models can be programmed in the following two ways:

1. Program the models by passing the following parameters (generics) on the HDL model instantiations.

Generics Possible values

PCM := “DLL1X”, “DLLPD”, “PLL”, “PCMBUF”

DUTY := 3.125 to 96.875 (percent duty cycle)

PDELAY := 1 to 31 (32nds of a full cycle)

DIV0 := 0 to 8 (0 bypasses the divider)



DISABLED_GSR := '0' or '1’ (defaults to 1)


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


2. By writing/reading the appropriate bits to the configuration registers during simulation.

The full PCM model is initialized to the mode specified by the parameters (default is PCMBUF), and the registers are initialized based on the values of the parameters passed. See the FPGA Data book, July 1999, for more detailed information about each of the attributes.

PCM[BT] Port Declarations

INPUTS: CLKIN, FB, WE, RE, A[2:0], DI[7:0]

OUTPUTS : ECLK, SCLK, LOCK, DO[7:0]

Synthesis Support

• For all synthesis tools, PCMB, PCMT are don’t touch elements.

• Since there is one input pin added to PLLB and PLLT elements, they are don’t touch elements until the synthesis library is updated.

• For Verilog, it is necessary to define each parameter and also to specify that same value as an attribute to be passed through the synthesis tool to the EDIF. Alternatively, the attribute can be added to the EDIF file by using an editor.

• The following are examples of the syntax for the attributes that are passed by the synthesis tools as attributes to the output EDIF netlist.

DISABLED_DONE := '0' or '1’ (defaults to 1)

PWRON := '0' or '1' (defaults to 1)

FBDELAY := in ps



Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


VERILOG: defparam U1.PCM=”DLL1X”; defparam U1.FBDELAY=12.237; defparam U1.DIV0=0; // [vendor specific attribute keywords] U1 PCM DLL1X // [vendor specific attribute keywords] U1 FBDELAY 12.237 // [vendor specific attribute keywords] U1 DIV0 0

• For more detailed information about the PCM functionality refer to the FPGA Data book, January 1998.

FREQUENCY Attribute

The PCM needs a FREQUENCY attribute when the PLL[BT] or PCM[BT] is used. The value of the FREQUENCY attribute is the SCLK frequency (the CLKIN frequency was used previously). In most cases, the SCLK frequency must be between 5 and 100 MHz.

See the Data sheet for valid FREQUENCY value for each of the Series 3 families of devices.

Series 3 Clock Controller CellsThe clock controller cells (CLKCNTL[BLRT]) can come from a dedicated pad or from PCMBUF. They have two inputs, CLKIN and SHUTOFF. When SHUTOFF is asserted it stops the clock after two clock cycles.


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


USING ORCA 4 SPECIAL CELLS IN VERILOG SIMULATIONS

Series 4 PLL Cells

The PLL is a special function block that is used to modify or condition clock signals for optimum system performance. The Series 4 PLL is composed of eight parts: four dedicated PLLs (PLL1 and PLL2) designed to meet Broadband Network applications and clocking needs, two high speed programmable PLLs, (HPPLLs) and two low speed programmable PLLs, (PPLLs) for general purpose.

Programmable PLLs have four modes of operation, BYPASS, DUTYCYCLE, PHSHIFT, and DELAY.

Module Configuration

The [H]PPLL models can be programmed in the following two ways:

1. Program the models by passing the following parameters (generics) on the HDL model instantiations.

For example for the [H]PPLL models:


MCLKMODE := “BYPASS”, “DUTYCYCLE”, “PHSHIFT”, “DELAY”

NCLKMODE := “BYPASS”, “DUTYCYCLE”, “PHSHIFT”, “DELAY”

VCOTAP := 0 to 7

PDELAY := 1 to 31 (32nds of a full cycle)





Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


2. You can configure the PPLL through the EPIC user interface from a dialog box after double clicking on a placed element. See the EPIC “Editing Series 4 Designs” chapter in the EPIC User’s Guide for more detailed instructions.

[H,L]PPLL Port Declarations

INPUTS: CLKIN, FB

OUTPUTS : MCLK, NCLK, LOCK, INTFB

PLL[1,2] Port Declarations

INPUTS: CLKIN

OUTPUTS : CLKOUT, LOCK

Synthesis Support

• For all synthesis tools, HPPLL, PPLL, and PLL are don’t touch elements.

• For Verilog, it is necessary to define each parameter and also to specify that same value as an attribute to be passed through the synthesis tool to the EDIF. Alternatively, the attribute can be added to the EDIF file by using an editor.

• Refer to the ORCA synthesis vendor manuals for examples of the syntax for the attributes that are passed by the synthesis tools as attributes to the output EDIF netlist. These manuals are the ORCA Mentor Graphics® Interface Manual and the ORCA Synplicity® Interface Manual.

For more detailed information about the PLL functionality refer to the latest FPGA Data book.


DISABLED_GSR := '0' or '1’ (defaults to 1)



Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


SIMULATION USING MTI MODELSIM FOR ORCA SERIES 4

System Bus SmartModel Simulation (Series 4)This section describes Series 4 system bus SmartModel simulation using Verilog.

Front End/Back End Verilog Simulation With MTI ModelSim®

To perform front end or back end Verilog simulation with MTI ModelSim, do the following:

1. Set the environment variable LMC_HOME to point to the directory where SmartModels are installed. These are installed when ORCA is installed.

2. Create an MTI work directory in the directory in which you generated the Verilog structural netlist, using the MTI command:

vlib work

3. Copy the modelsim.unx (for UNIX) or modelsim.pc (for PC) from the $FOUNDRY/vhdl/data/orca4/mti directory into your current directory as modelsim.ini.

4. Copy the SYSBUS.v file and sysbus_top.vhd (for UNIX) or sysbus_top.v.pc (for PC) from $FOUNDRY/verilog/data/orca4/ directory.

5. Compile the structural Verilog netlist into this work directory, using MTI's vcom:

vcom sysbus_top.v SYSBUS.v <file_name>.v

6. Simulate it using the ORCA VHDL library and MTI's vsim:

vsim <entity_name> [arch_name]


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


Back End Verilog Simulation With MTI ModelSim

To perform back end Verilog simulation with MTI ModelSim, do the following:

1. Set the environment variable LMC_HOME to point to the directory where SmartModels are installed. These are installed when ORCA is installed.

2. Copy the SYSBUS_TS.v file and sysbus_top_ts.v from $FOUNDRY/verilog/data/orca4/ directory.

3. Compile the structural Verilog netlist into this work directory, using MTI's vcom:

vcom sysbus_top_ts.v SYSBUS_TS.v <file_name>.v

The SmartModel sysbus_top_ts.v already has the timing numbers for speed grade -2. If you wish to simulate with a different speed grade then you must do the following:

a. Copy the system_top_ts_1.tf (for -1 speed grade) or system_top_ts.m.tf (for minimum speed grade) from $FOUNDRY/verilog/data/orca4 directory to your working directory as system_top_ts_.tf file.

b. Set the environment variable LMC_HOME to point to the working directory.

c. ModelSim will automatically pick up the new timing file for simulation.

4. Simulate it using the ORCA Verilog library and MTI's vsim:

vsim <entity_name> [arch_name]


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


ORCA/Verilog Simulation APPENDIX

APPENDIX

MEMORY INITIALIZATION IN VERILOG

There are 21 different memories available in the ORCA Verilog Simulation Library for front end simulation. Memories will automatically initialize to zero if they are not initialized with some number. There are two methods available for initializing the memories.

1. The first method was supported previously and has not changed. Inside the models are tasks that allow the simulator to load the model from a file or show the internal contents of the model. From inside your testbench which instantiates the FPGA, you must scope down inside the model to the task to use it. Because of the hierarchical method used to create the models, some models have one additional level of hierarchy inside of them. Below is an example of some code from a testbench of the call to the task to load the memory from a file and then display the contents of the RAM using the show task. The contents are displayed on the screen and written to the verilog.log file.

initial begin u1.u2.INST5.INST5.load(“loadfile”); u1.u2.INST5.INST5.show(0,15);end;

The u1 represents the instance name of the FPGA, u2 is the instance name of the memory that we want to load, and the INST5.INST5 are two levels of hierarchy that are inside of the memory model. The instance hierarchy can be seen inside of the memory models in the verilog/orca, orca2a, or orca3 front-end simulation library. The instance names INST5.INST5 are fixed and cannot be changed.

• The following models have one hierarchical level inside of them and require only one INST5 hierarchical scope: DCE16X2, DCE16X2Z, DCE32X4, DCF16X2, DCF16X2Z, RCE16X4, RCE16X4Z, RCE32X4, RCF16X4, RCF16X4Z, ROM32X4, ROM16X1, and the ROM32X1. The following command is an example of loading the RCF16X4:

u1.u2.INST5.load(“loadfile”);


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


Note that there is only one INST5 in the call to the load task.

• The following models have two hierarchical levels inside of them: RPP16X4, RPP16X4Z, RPP16X2, RPP16X2Z, RPE16X2, RPE16X2Z, RPE16X4, and the RPE16X4Z. Note the 2 INST5’s in the call to the load task:

u1.u2.INST5.INST5.load(“loadfile”);

The file that is read into the memory (named loadfile in this example) must be in binary format, 2 or 4 bits wide depending on the memory that is being initialized and length of 16 locations. The file is assumed to be in the current working directory but the path to the file can be included within the quotes.

2. The second method of loading the memories is by using a parameter that is passed into the memory. This method is supported for both the front- and back-end netlist. This front-end simulation netlist can be generated using Module/IP Manager to create a SCUBA module or by a synthesis tool. If the INITVAL string attribute is present in the EDIF file that is input into an ORCA design flow, then the initialization string will be written to the back-end netlist.

The following examples show initialization of a front-end and back-end memory. The parameter string is read (MSB....LSB). For the DCE16X2,because a hex digit is 4 bits wide and memory is only 2 bits, the two MSBs of each digit would be ignored; memory location 0 would get a 0, and memory location 15 would contain a 1 because the third bit of the hex 5 would be ignored.

DCE16X2 #(64'h5432109876543210) mem_0_0_1 (.AD0(waddr0), .AD1(waddr0), .AD2(waddr0), .AD3(waddr0), .DI0(datain2), .DI1(datain2), .CK(clk), .WREN(wren), .WPE(scuba_vhi), .RAD0(raddr0), .RAD1(raddr0), .RAD2(raddr0),.RAD3(raddr0), .RDO0(dataout2));

NEOSR16 #(16'h3210) RAM16X1_C ( .DIN ( DI0 ), .RAD0 ( AD0 ), .RAD1 ( AD1 ), .RAD2 ( AD2 ), .RAD3 ( AD3 ), .RCLK ( HIGH ), .WAD0 ( AD0 ), .WAD1 ( AD1 ), .WAD2 ( AD2 ), .WAD3 ( AD3 ), .WCLK ( CK ), .WREN ( WREN ), .WPE ( WPE ), .SET ( LOW ), .RST ( LOW ) , .DOUT ( DO0 ) );

The memory initialization parameter can be entered in binary or hex format. If the memory is 2 bits wide, the hex number will always have the first two MSB’s ignored.


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


USING GSR/PUR IN VERILOG

Using GSR/PUR in Verilog for ORCA2 and ORCA3 Libraries

1. For front-end simulation, if the GSR function is NOT used there is no requirement for the designer to do anything to the design or the testbench. The GSR signal will not be visible in the front-end netlist. However, the GSR signal is always present inside the models of the registers. Because of this, the GSR can be used as a global set/reset which defaults to active LOW.

2. For the back end simulation, if the GSR signal is not used, a signal named GSRNET will be present in the netlist, connected to all registers, and pulled up. This GSRNET signal can be forced to create a reset pulse to act as a power-up reset as shown below:

`timescale 1 ns / 100 psmodule testbench; initial begin force u1.GSRNET = 1’b0; #time release u1.GSRNET; end // circuit stimulus code // Circuit instance MYCHIP u1 (IN1,IN2,IN3,OUT0);endmodule

3. If the GSR function is used, the designer must define the location of the GSR signal in the verilog testbench. The GSR signal can originate anywhere in the hierarchy of the circuit and the signal itself can have any name, but the variable GSR_SIGNAL is fixed and must be defined in the testbench. Review the following example and note that GSR is not defined in the port of ‘mychip’ but is defined inside of ‘mychip’:

`timescale 1 ns / 100 psmodule mychip_tb; ‘define GSR_SIGNAL mychip_tb.u1.GSR // circuit stimulus code // Circuit instance MYCHIP u1 (IN1,IN2,IN3,OUT0);endmodule

In this example the GSR signal originated inside the design called ‘mychip’ (instance u1). If it exists down in some hierarchy, then the definition could be:


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


‘define GSR_SIGNAL mychip_tb.u1.x.y.z.GSR

where x.y.z are additional hierarchical module names.

Using GSR/PUR in Verilog for ORCA4 and Later Libraries

The global set/reset function in front-end Verilog simulation for ORCA Series 4 and higher must be done differently than in prior architectures. To ensure proper simulation, it is necessary to instantiate GSR, PUR, and TSALL elements in your designs which contain any library elements that are affected by them.

For instance, when you instantiate a flip-flop, for example, that is affected by global set/reset in front-end Verilog netlists, then you must instantiate the GSR and PUR elements in the top-level module with the instance names GSR_INST and PUR_INST, respectively. Similarly, for any output or bidirectional buffer instantiation, you must instantiate TSALL with the instance name TSALL_INST.

The example below shows proper syntax for instantiating GSR and PUR elements:

GSR GSR_INST (.GSR (<global reset sig>)); PUR PUR_INST (.PUR (<powerup reset sig>));

The example below shows proper syntax for instantiating TSALL:

TSALL TSALL_INST (.TSALL (<global tristate sig>));

Programmable GSR Support (Series 3 and Series 4)

Programmable GSR support allows the user to disable the GSR functionality on selected register elements. This feature gives the user the ability to retain design information on a PFU basis when using GSR to set/reset the rest of design.

The PUR component will now be used to set/reset register elements at power-up. GSR is used for global set/reset at all other times of operation. The PUR signal will need to be instantiated in your HDL design since it is currently not inferred.


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


In the current version of ispLEVER, programmable GSR is supported via an attribute attached to instantiated library cell instances in the HDL design netlist. The attribute is "DISABLED_GSR" with value "1". The resulting synthesized output EDIF netlist will contain the attribute "DISABLED_GSR" with value "1" for each component instance containing the attribute. The ORCA tools will recognize this attribute and disable the GSR functionality accordingly.

The following is an example:

module TEST (D0, D1, SP, CK, SD, PD, CD, PRESETG, PRESETP, FL1S1B_Q, FL1S1D_Q,FL1P3BX_Q, FL1P3DX_Q);input D0, D1, SP, CK, SD, PD, CD, PRESETG, PRESETP;output FL1S1B_Q, FL1S1D_Q, FL1P3BX_Q, FL1P3DX_Q;

parameter DISABLED_GSR = 1;defparam FL1S1B1.DISABLED_GSR = DISABLED_GSR;defparam FL1P3DX1.DISABLED_GSR = DISABLED_GSR;

IBM IN1 (.I(D0), .O(D0B));IBM IN2 (.I(D1), .O(D1B));IBM IN3 (.I(SP), .O(SPB));IBM IN4 (.I(CK), .O(CKB));IBM IN5 (.I(SD), .O(SDB));IBM IN6 (.I(PD), .O(PDB));IBM IN7 (.I(CD), .O(CDB));IBM IN8 (.I(PRESETG), .O(GSR));OB6 OUT1 (.I(FL1S1B_QB), .O(FL1S1B_Q));OB6 OUT2 (.I(FL1S1D_QB), .O(FL1S1D_Q));OB6 OUT3 (.I(FL1P3BX_QB), .O(FL1P3BX_Q));OB6 OUT4 (.I(FL1P3DX_QB), .O(FL1P3DX_Q));GSR G1 (.GSR(GSR));PUR P1 (.PUR(PRESETP));FL1S1B FL1S1B1 (.D0(D0B), .D1(D1B), .CK(CKB), .SD(SDB), .PD(PDB), .Q(FL1S1B_QB), .QN(FL1S1B_QNB));FL1S1D FL1S1D1 (.D0(D0B), .D1(D1B), .CK(CKB), .SD(SDB), .CD(CDB), .Q(FL1S1D_QB), .QN(FL1S1D_QNB));FL1P3BX FL1P3BX1 (.D0(D0B), .D1(D1B), .SP(SPB), .CK(CKB), .SD(SDB), .PD(PDB), .Q(FL1P3BX_QB), .QN(FL1P3BX_QNB));


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


FL1P3DX FL1P3DX1 (.D0(D0B), .D1(D1B), .SP(SPB), .CK(CKB), .SD(SDB), .CD(CDB), .Q(FL1P3DX_QB), .QN(FL1P3DX_QNB));

endmodule


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


USING TSALL IN VERILOG

For the front-end simulation, an external pin on the FPGA can be used to tristate all the outputs. Because the TSALL signal is an internal signal in the models, the TSALL signal must be defined using the ‘define compiler directive in the front-end simulation testbench. A TSALL component called TSALL must also be defined in the netlist for ORCA to know what signal is the TSALL signal. Below are examples of the testbench and the front-end Verilog netlist. The front-end tristate signal TS in the example below is active LOW and will tristate the output buffers when it is LOW. This is the default active state.

• Example of the front-end testbench:

module top; ‘define TSALL_SIGNAL top.x.TSALL; //testbench info - no references to TSALL it //is implicit in the models TRY X (.IN(IN), .OUT(OUT)); endmodule

• Example of the front-end verilog netlist:

module TRI (TS, I3 I4, OBZ12F_Z, OBZ6_Z, OBZ12PD_Z) input TS,I3,I4; output OBZ12F_Z, OBZ6_Z, OBZ12PD_Z; IBM IN99 (.I(TS), .O(TSALL)); TSALL T1 (.TSALL(TSALL)); OBZ6 OBZ6_1 (.I(OBZ6_IX), .T(OB_TX), .O(OBZ6_Z)); //This shows that OBZ6 //which uses TSALL internally does //not have a port called TSALL endmodule

For the back-end simulation, the TSALL signal is present in the netlist and the default active state changes to HIGH. The signal name changes to TSALLNET and will automatically be connected to the tristate control signal defined in the front-end netlist. There is no ‘define state or any requirements to the testbench. It is important to note that the active state changes so that the outputs are tristated when the signal is driven HIGH.


Table of

Index

Cover

Master

Home

List of Docs

Contents

Page

Index

Page

GO TO


ILLEGAL NAMES AND CHARACTERS

Certain names and characters used in a design may cause problems at some point in your ORCA design flow. See Illegal Names and Characters in the ORCA Macro Library section of the ORCA Libraries Manual for a list of names and characters to avoid.

ORCA/Verilog Interface I-1Index

INDEX


Table of

Cover

ORCA

ORCA

Index

Tech Support

Contents

Web Site

FAQs

GO TO

Page

BBack end simuluation

Verilogwith MTI ModelSim (Series 4), 18

Back end Verilogsimulation with MTI ModelSim, 19

CCommands

ldbanno, 10loadfile, 21ngd2ver, 7ngdanno, 7sdf_annotate, 11verilog, 9, 12

DDesign

environmentsetting, 2

simulationNeoprim verilog model (2CA/2TA), 7Neoprim verilog model (Series 3), 10ORCA verilog model, 6

Directory structure, 3

EEnvironment variables, 2

FFigures

Simulation flow, Verilog, 5FREQUENCY (attribute), 15Front end simuluation

Verilogwith MTI ModelSim (Series 4), 18

GGSR

instantiating in Verilog, 23, 24

HHierarchy

and Verilog Simulation library models, 20

IInstantiating

GSR in Verilog, 23, 24TSALL in Verilog, 27

Lldbanno (command), 10Libraries

ORCA Verilog Simulation, 20loadfile (command), 21Loading memories, 20

MMemories, loading, 20Memory initialization, 20ModelSim

system bus simulation (Series 4) using Verilog, 18

Module configurationfor PCM (Series 3), 13PPLL (Series 4), 16

MTI ModelSimBack End Verilog Simulation with, 19Front End VHDL Simulation with, 18

NNeoprim

verilog model simulation (2CA/2TA), 7verilog model simulation (Series 3), 10

ngd2ver (command), 7ngdanno (command), 7

OORCA

verilog model simulation, 6verilog simulation library, 20




ORCA/Verilog Interface I-2Index


Table of

Cover

ORCA

ORCA

Index

Tech Support

Contents

Web Site

FAQs

GO TO

Page

PPCM

module configuration (Series 3), 13PCM (Series 3)

using in Verilog simulation, 13PLL

port declarations (Series 4), 17synthesis support for, 17

PLL (Series 4)using in Verilog simulation, 16

PPLLmodule configuration (Series 4), 16port declarations (Series 4), 17synthesis support for, 17

RRequirements

software, 2

Ssdf_annotate (command), 11Setting

design environment, 2Showing contents of memories, 20SIMULATION

Front End VHDL with MTI ModelSim, 18Verilog Front End/Back End with MTI

ModelSim, 28Simulation

flowVerilog (figure), 5

Front End Verilog with MTI ModelSim, 19Neoprim verilog model (2CA/2TA), 7Neoprim verilog model (Series 3), 10ORCA verilog model, 6

Software requirements, 2System bus (Series 4)

simulation with MTI ModelSim, 18

TTSALL

instantiating in Verilog, 27

VVERILOG

Simulation with MTI ModelSim (Front End/Back End), 28

VerilogBack end simuluation with MTI ModelSim

(Series 4), 18, 19Front end simuluation with MTI ModelSim

(Series 4), 18simulation

flow, 5using Neoprim models (2CA/2TA), 7using Neoprim models (Series 3), 10using ORCA models, 6

system bus simulation (Series 4), 18verilog (command), 9, 12




orca® verilog® simulation manual

Documents