o What is smPla?

o What are PLA, PAL, PLD, GAL, FPGA (and so on)?

o smPla pin and parameter description

o Download and usage information

o Bug reporting

o Author

o Evangelism

smPla is a project aiming to develop a SystemVerilog module that models IEEE Std. 1364-2005 Verilog system tasks for Programmable Logic Array modeling. These system tasks are:

PAL System Task List
$async$and$array	$sync$and$array	$async$and$plane	$sync$and$plane
$async$nand$array	$sync$nand$array	$async$nand$plane	$sync$nand$plane
$async$or$array	$sync$or$array	$async$or$plane	$sync$or$plane
$async$nor$array	$sync$nor$array	$async$nor$plane	$sync$nor$plane

Surprisingly, this question comes up quite frequently. This webpage is too small a place to describe them and their differences. If you do not have access to a good text book on this topic, your best bet will be

1. Wikipedia or
2. datasheets of such chips from their manufacturers.

3.1 Pin description

Here are the pin description of smPla.
 

Input Pin Name	Description
mem[memWidthLeft:memWidthRight][memDepthLeft:memDepthRight]	Personality array.
a	Control inputs.
sync	0: sync, 1: async
func[1:0]	00: and, 01: nand, 10: or, 11: nor
array_plane	1:array, 0: plane

 

Output Pin Name	Description
b[memDepthLeft:memDepthRight]	Output from the PLA.

3.2 Parameter description

Following are the parameters that the smPla module accepts in its instantiation.

Parameter Name	Description
memWidthLeft	Index of the MSB of the personality array.
memWidthRight	Index of the LSB of the personality array
memDepthLeft	Index of the first row of the personality array.
memDepthRight	Index of the last row of the personality array

4.1 Distribution

smPla is distributed open source under GNU Public License Version 3 (GPLv3).

4.2 Download source

You can download smPla source from here.

4.3 Language

The core module and the testbench are written in SystemVerilog.

4.4 Directory structure

1. doc: home of this html file.
2. tb: testbench directory.
3. src: main SystemVerilog source directory.
4. build: directory where compilation takes place and also where flist and .do files reside.

4.5 Simulator support

smPla has been tested with Synopsys VCS (2009.06) and Mentor Graphics Questa (6.6b). It has also been tested with Icarus Verilog.

Although some moderate amount of testing has been done, user testing is always welcome. If you find a problem, please file a bug here.

smPla is developed by Swapnajit Mitra. Swapnajit's website Project VeriPage promotes use of SystemVerilog. All opinions expressed on this page are his own.

7.1 Wait! Did you say these models are already available in Verilog as system tasks? Then why are you building them again?

There are several reasons for building them using SystemVerilog.

1. There are freeware Verilog simulators that still do not support the standard system tasks. For example, as of now (April 2011), Icarus Verilog does not support them.
2. The author feels the architecture of the standard system tasks is horribly wrong. There are 16 system tasks as opposed to one module here to do the same job. Why pollute the name space?
3. The just about only justification of using a system task for PLA modeling was that a memory type could not have been passed to a Verilog module. This constraint is no longer valid for a SystemVerilog module. Something that can be done using Verilog/SystemVerilog should not need the use of PLI or system tasks to increase the efficiency of simulation.
4. The definitions of the PLA system tasks in the IEEE Std. 1364-2005 are incomplete at best, inaccurate at worst. Two such examples are:
   • The spec does not say what happens if the memory element contains X or Z for 'array' versions of the tasks.
   • The spec does not clearly say the definition of sync versions of the system tasks, leaving it to the interpretation of the reader.

7.2 Since a SystemVerilog module can now serve the purpose, are you recommending depricating the use of these PLA system tasks in future version of standard Verilog?

The answer is a resounding yes.

7.3 What would be a possible migration path for those who are already using the system tasks in their code today if those tasks are depricated in future version of standard Verilog?

The best way will be to download this package (smPla) and start using it with very minimal code change. Changing code is always a hassle, but not unheard of. For example, legacy code had to change for those who used defparam earlier but then it was depricated in the standard.

Also a PLI/DPI call is in work to make an interface between a front end similar to that of the system tasks and a SystemVerilog module backend.