Advantages of Python over Perl

In the new competitive generation of chip designing where Time-to-Market is so critical and also the complexity of designs is increasing exponentially.  Adding to that it is also observed that the Verification is always considered the longest pole and takes nearly 70% of the chip design life cycle. Hence any opportunity to automate a  task that is repeatable more than once is considered of most importance to improve the verification productivity. This is where  “scripting” skills are highly valuable for any  Verification engineer.

After many years of writing design and verification automation scripts in Perl and Python, we would like to throw some light on the advantages of using Python.

Maintainability

As we all know, Perl is easy to write but hard to read, especially when someone else has written it. There are multiple ways of writing the same code. Add to this fact that many engineers take pride in writing highly obfuscated Perl that is a pain for others to read.

Maintainability is a critical aspect of any engineering project. Throwing away code and rewriting it is a productivity loss. Unfortunately, this happens a lot with Perl.

Python, on the other hand, has a clean syntax and typically there is only one way of doing what you want. Python code is hence much more readable. Even people who have never written Python code ever can understand it, as the syntax is very “pseudo-code” like. It is also easier to functionalize and modularize code in Python as the language naturally encourages this.

Re-usability

Perl is designed for use and throw. You write something in Perl, run it and then forget about it. It is very difficult to extend the functionality of a Perl script. Typically you would not have organized your code into functions, as Perl syntax does not encourage that. When you try adding some functionality to your Perl script you realize that re-writing it completely is better than re-using the earlier script and extending it.

Python syntax encourages re-usability. The mindset is different. When you write code in Python, you write with future re-usability in mind. This is really tough to do in Perl. Perl encourages shortcuts.

Scale

Writing large pieces of code (more than 50k lines) in Perl exposes the weaknesses in the language. Maintainability, performance, and packaging are big issues. Can I package my application in a way that doesn’t require users to download and install modules used by the application?

Perl encourages users to download and install modules as needed. IT departments are not comfortable with upgrading Perl installations on thousands of server farm nodes. It would be an IT nightmare.

Python distributions, on the other hand, come with a majority of the module libraries included. Also, Python allows the packaging of applications so users do not have to manually download and install all module and library dependencies needed to run an application.

Final words

Perl is great at some things. For example, it has fantastic regular expression capabilities (it can even combine multiple regexp’s and match all of them together!). Perl is a worthy successor to awk.

Bottom line:  For use and throw scripts, Perl is great. But, if your code needs to be checked into a version control system and will potentially be modified by other people, I would prefer Python over Perl.

Transaction Recording In Verilog Or System Verilog

As there is not yet a standard for transaction recording in Verilog or VHDL, ModelSim includes a set of system tasks to perform transaction recording into a WLF file. Transaction modeling allows users to raise the level of description, analysis and debugging of their designs to the transaction level. A transaction represents a transfer of high-level data or control information between the test bench and the design under test (DUT) over an interface or any sequence of signal transitions recorded in the simulation database as a transaction.

The API is the same for Verilog and SystemVerilog. As stated previously, the name "Verilog" refers both to Verilog and SystemVerilog unless otherwise noted.

The recording APIs for Verilog and VHDL are a bit simpler than the SCV API. Specifically, in Verilog and VHDL:

• There is no database object as there is in SCV; the database is always WLF format (a .wlf file).

• There is no concept of begin and end attributes All attributes are recorded with the system task $add_attribute() or add_attribute.

• Your design code must free the transaction handle once the transaction is complete and all use of the handle for relations or attribute recording is complete. (In most cases, SystemC designs ignore this step since SCV frees the handle automatically.)

A transaction has a begin time, an end time, and attributes. Examples of transactions include read operations, write operations, and packet transmissions. The transaction level is the level at which many users think about the design, so it is the level at which you can verify the design most effectively.

Transactions are recorded on a stream. A stream is a collection of transactions, recorded over time. A stream has a name, and usually exists somewhere within the test bench hierarchy – for example a driver might have a stream which represents all the transactions that have occurred on that driver. Each driver defines a collection of attributes ( transaction items ) which are defined by users, and which are meaningful to the transaction. The values of attributes are set for each transaction. Finally, transactions can be linked to each other. A link has a direction and a user-defined name, and specifies a relation between the two transactions.

module top;

    integer stream, tr;

    initial begin

        stream = $create_transaction_stream("Stream");

        #10;

        tr = $begin_transaction(stream, "Tran1");

        $add_attribute(tr, 10, "beg");

        $add_attribute(tr, 12, "special");

        $add_attribute(tr, 14, "end");

        #4;

        $end_transaction(tr);

        $free_transaction(tr);

    end

endmodule

Here,

1. $create_transaction_stream() is used to define a transaction stream. You can use this system task to create one or more stream objects.

 module top;
        integer hStream

        initial begin
            hStream = $create_transaction_stream("stream", "transaction");
            .
            .
        end
        .
        .
    endmodule

2. $begin_transaction is used to start a transaction by providing a valid handle of the transaction as shown below.

integer hTrans;
.
.
 hTrans = $begin_transaction(hstream, "READ");

In this example, we begin a transaction named "READ" on the stream already created. The $begin_transaction system function accepts other parameters to specify: the start time for the transaction, and any relationship information, including its designation as a phase transaction.

The return value is the handle for the transaction. It is needed to end the transaction or record attribute.

3. $end_transaction has a single required argument – the handle of the transaction that is to be ended. It also has a single optional argument, the time in the past that this transaction ended. After a transaction has been ended, the transaction handle can still be used to add attributes and create relations.

$end_transaction( handle transaction [, time endTime])

4. $free_transaction has a single argument – the handle of the transaction to be deleted. Once a transaction is deleted the handle becomes invalid. It cannot be used in any other recording interfaces.

$free_transaction (handle transaction)

5. $add_attribute has two required arguments – a transaction handle on which the attribute is to be created and the attribute that is to be recorded. There is one optional argument of type string named attributeName. This attributeName specifies an alias name for the attribute. If not specified, the name used for the attribute is the actual name of the SystemVerilog object.

$add_attribute( handle transaction,  object attributeValue  [, string attributeName])

6. $add_relation has three arguments – the first two are the two transaction handles which are related. The third argument is the string name of the relation.

$add_relation( handle sourceTransaction,  handle targetTransaction,  string relationshipName)