The RASSP Digest - Vol. 3, September 1996


Mississippi State Develops On-Line FPGA VHDL Model Generator

by Robert Reese and J. Scott Calhoun


Abstract

As part of our RASSP Tech Base VHDL modeling and distribution objectives Mississippi State University (MSU) has developed and released an on-line FPGA VHDL model generator.

The objectives of the MSU tech base contract are to provide VHDL models for COTS parts, primarily concentrating on PLDs, RAMS, and ROMS. To date, we have released VHDL models for several parts in these general families, including several standard PLD models (22V10, several PALs), standard RAM/ROM models, dual port RAMS, and some general bus interface glue logic models. We have also made available several VHDL packages which are useful for creating additional part models within these general families.

Another objective of our program was to advance beyond low-complexity PLD models and provide a VHDL model for a field programmable gate array. Recently, we made an alpha release of a VHDL model for the Xilinx X4000 FPGA family. The remainder of this article will discuss our approach to this model.

1. Xilinx X4000 FPGA

The Xilinx X4000 family is a static RAM based FPGA. The basic logic cell is called a Configurable Logic Block (CLB) and contains two 4-input lookup tables, two D flip-flops, and dedicated carry logic. The lookup tables can implement two separate 4-variable functions; the output of the tables can also be combined to form a third logic function. The lookup tables can also be used as an asynchronous SRAM, synchronous SRAM (X4000E) or dual port SRAM (X4000E). Combinational outputs can be registered via the flip-flops if desired.

I/O is handled via a versatile Input Output Block (IOB) which have several configuration options such as registered/non-registered on the input or output signals, tri-state output, programmable output slew rate, pullup/pulldown on output, and output polarity. There are several other logic resources on the chip as well - an on-chip oscillator, fast decoders, tri-state buffers, pullups, high-drive buffers, startup logic, and boundary scan capability.

2. Modeling Goals and Approach

Our goals in modeling the X4000 was to provide a VHDL model which supported logic functionality, timing, system level features, and have good performance. System level features include simulation of capabilities not normally supported during gate level development - i.e, startup emulation, boundary scan support, and in-system programming. The SRAM programming of the X4000 gives the part a dynamic reconfigurability capability via in-system programming. After looking at the problem, we decided not to support dynamic reconfigurability in our VHDL model of X4000 for several reasons:

a. Supporting dynamic reconfigurability could severely impact model performance, both in execution time and in memory footprint. This conflicts with our goal of achieving good performance.

b. Dynamic reconfiguration is not a capability which is used that often.

c. Supporting dynamic reconfigurability would require a non-disclosure agreement with Xilinx concerning the format of the programming bit-stream which might hinder model distribution.

Not supporting dynamic reconfigurabilty meant that a static VHDL model could be generated from one of the intermediate logic representations which are created during the design/mapping process. Xilinx supports two netlist formats which describe mapped logic - XNF (Xilinx Netlist Format) and LCA (Logic Cell Array). XNF is an intermediate gate level description while the LCA netlist uses the on-chip logic primitives (CLBs, IOBs, tri-state buffers, etc). We chose the LCA format because we felt it would be easier to support system level features (startup, boundary scan) at this level and because the generated package/speed-grade timing information refers directly to these primitives.

3. Model Library and Generator

A VHDL X4000 module library was written to support the logic primitives. Currently, the first release (May 96) of this library supports all logic functionality except for the startup and boundary scan logic. Some timing functionality is included but work is still in progress in this area. A Perl5 script named 'lca2vhd' converts an LCA file into a VHDL structural model which uses the X4000 module library. Any net delay information present in the LCA file (produced by Xilinx back annotation) is represented in the VHDL model. X4000 module timing information is read from a separate file generated by the Xilinx mapping process and is based upon selected package type and speed grade. The 'lca2vhd' script converts net names in the LCA file to VHDL-compatible names; a command line option allows user control over name mapping which proves useful in generating vectored signal names. The X4000 module library has been tested with both Mentor Quick-VHDL and Vantage VHDL development environments.

4. On-line Model Generation

In keeping with the on-line release mechanism used by MSU to distribute its VHDL models, the FPGA model generator takes this paradigm to the next level. The FPGA VHDL model library for the X4000 is distribtued via the World Wide Web (WWW) download at

http://www.erc.msstate.edu/mpl/vhdl/html/models/library/xilinx.html

Once the X4000 library is downloaded and compiled, VHDL models of specific X4000 designs can be generated via the on-line model generator at

http://www.erc.msstate.edu/mpl/vhdl/html/models/library/xilinx/lcaform.html

This unique form takes advantage of an emerging HTTP feature allowing files to be uploaded to the web server {Note: this feature is currently supported by Netscape Version 2.0 or greater}. LCA files (with optional name mapping and timing files) are uploaded to the MSU RASSP webserver. The uploaded files are fed to the lca2vhd generator. The generated models are then tarred and compressed and available for download. The model generator form along with and example of the generator output execution is illustrated in Figure 1 and Figure 2.

This unique application takes a significant step towards the use of on-line CAD systems which may be prevalent in the future. We hope to collect usage data that will help the DoD and CAD industry determine the value of these on-line applications. An example of the model generator output for a CLB component used within a design is given below.

	CLB_PD: x4000CLB
		GENERIC MAP (
			WD_G4 => 3.6 ns,
			WD_G3 => 1.9 ns,
			WD_F4 => 1.3 ns,
			WD_F3 => 1.1 ns,
			WD_F1 => 2.1 ns,
			WD_C1 => 3.7 ns,
			WD_K => 1.4 ns,
			MGeneration => MGeneration,
			XGeneration => XGeneration,
			Ref  => Ref&":CLB_PD",
--	Config F4:F4I G2: G3:G3I X: Y: XQ:QX YQ: FFX:K:RESET
	FFY:RESET DX:H
--				DY: F:F3:F4:F1
--	G:G3:G4 H:F:G:H1 H1:C1 DIN: SR: EC: RAM:
	CARRY: CIN: COUT: CDIR: 
		CLBTags => CLBTagsArrayData(PD_blk),
		CLBTiming => CLBTimingRecordData,
		RAMTiming => RAMTimingRecordData,
--	F = (F1*~((F3 + F4)*~(F3*F4))), G = (G3*G4),
	H = (~H1*(G + F))
			CLBFuncs => CLBFuncsArrayData(PD_blk)
		)
		PORT MAP (
			G4 => N_1I120_PATH_NET_23,  -- $1I120/PATH/				NET_$23
			G3 => N_1N237, 	         -- $1N237
			G2 => open, 	 
			G1 => open, 	 
			F4 => N_1I120_PATH_C_1002_4,  -- $1I120/PATH/				C_1002_4
			F3 => N_1I120_PATH_N_437, -- $1I120/PATH/				N$437
			F2 => open, 	 
			F1 => N_1I120_PATH_NET_38, 	 -- $1I120/				PATH/NET_$38
			C1 => N_1N116_2, 	         -- $1N116_2
			C2 => open, 	 
			C3 => open, 	 
			C4 => open, 	 
			K => N_CLK, 	                 -- CLK Y => open, 
			YQ => open, 	 
			X => open, 	 
			XQ => N_1N237, 	         -- $1N237
			COUT => open, 	 
			CIN => open, 	 
			GSR => GSR_LCA2XNF	  
		);

In the above generic map for 'CLB_PD', the 'CLBFuncs' generic contains the lookup table and carry logic mapping which is

	PD_blk =>
		(funcF => "0000000010011001",  -- F1(MSB),F2,F3,F4 			inputs
		funcG => "0001000100010001",  -- G1(MSB),G2,G3,G4 			inputs func
		H => "00101010",          -- F(MSB), G, H1 
		funcC => (OTHERS => '0')      -- carry logic function
	),

The 'CLBTags' generic contains a structure defining the particular CLB configuration. Timing data is passed within the 'CLBTiming' and 'RAMTiming' generics with net delays specifed via the various 'WD_*' generics.

5. Future Work

Our current goals (in order):

a. Complete all timing functionality.

b. Add X4000E support; this variant of the X4000 adds synchronous SRAM and dual-port SRAM capability in the CLB.

c. Add startup emulation and boundary scan support.

Our schedule calls for completion of this work by September '96.

Robert Reese and J. Scott Calhoun
Microsystems Prototyping Laboratory
Engineering Research Center
P.O. Box 6176
Mississippi State, MS 39762
reese@erc.msstate.edu


Newsletter Index
The RASSP Digest - Vol. 3, September 1996
newsletter/html/96sep/news_17.html