Archive for August, 2010

The Role of the Technical Marketing Engineer in Verification

by Andrew Piziali, Independent Consultant

In our previous blog posts on the subject of verification for designers we addressed the role of the architect, software engineer and system level designer. We now turn our attention to perhaps the least understood—and oftentimes most vilified—member of the design team, the technical marketing engineer. But, before we explain why, what is the role of the technical marketing engineer? After all, not all companies have such a position.

The technical marketing engineer is responsible for determining customer product requirements and ensuring that these requirements are satisfied in the delivered product. They typically build product prototypes—initially slideware and later rudimentary functional code—that are evaluated by the customer while refining requirements. With each iteration the customer and engineer come closer to understanding precisely what the product must do and the constraints under which it must operate. This role differs from other traditional marketing functions such as inbound and outbound communication. Given that such a position exists, how does the technical marketing engineer contribute to the functional verification of a design?

Although there are many definitions of functional verification, my favorite is one I recorded at Convex Computer Corporation some twenty years ago: “Demonstrate that the intent of a design is preserved in its implementation.” It is short, colloquial and simple:

• • Demonstrate — Illustrate but not necessarily prove
• • Intent — What behaviors are desired?
• • Design — The various representations of the product before it is ultimately realized and shipped
• • Preserve — Prevent corruption, scrambling and omission
• • Implementation — Final realization of the product for the customer

The technical marketing engineer plays a key role in this process as demonstrated by one personal experience of mine in this role.

One company I worked for offered a product that assisted in producing clean, efficient, bug-free code through pre-compilation analysis. In this environment one could navigate through your code within its module (file) structure, as well as within its object structure. However, the programming language supported not only objects—language elements that are defined, inherited and instantiated–but also aspects—language elements that group object extensions into common concerns. I proposed adding an aspect browser to the product as a natural extension to its existing navigation facilities. The challenge was inferring the aspect structure of a program from its files and object structure because an aspect is not explicitly identified as such in the program.

I put together a slide presentation that illustrated the two existing navigation paradigms, as well as the proposed aspect navigation. The feature looked great from a user interface perspective, but could it be implemented? Since heuristics could be employed in identifying each aspect, I also illustrated each heuristic and its application by way of sample code and its structure. This animated slide presentation served as the first prototype demonstration of the aspect browser for the product. When reviewed with existing users, they were able to provide valuable feedback about the new feature and its utility and limitations. When subsequently referenced by the programmer implementing the feature, it served as a rough executable specification.

Returning to the vilified technical marketing engineer, why are some poor souls subject to this criticism? More often than not, the marketing engineer promised more capability, performance or features than could be delivered by the developers. It is easy to “Powerpoint” a feature that cannot be implemented so the marketing engineer must walk far enough down the implementation path to understand what is feasible. If they do, they will likely avoid this charge and remain a perceived asset by the design team. Moreover, their employer will retain a reputation for delivering quality “product-ware,” not vaporware or slideware!

Asif Jafri, Verification Consultant, Verilab

task wait_for_end();
     super.wait_for_end();
     end_vote.wait_for_consensus();
endtask

endclass: tb_top 

The code above shows how we can instantiate various voters that will participate in the test completion.

You can choose to use the consensus_force_thru command to pass to propagate the force up.

Using these techniques to end your test will make your testbench scalable and reusable over various projects.

John Aynsley, CTO, Doulos

Having discussed some of the technical details of the implementation of the TLM-2 standard in VMM 1.2 in previous posts, it is time to stand back and ask what it is all for, especially considering that VMM must now co-exist alongside UVM in some projects. Fortunately, using the OSCI TLM standard as a basis for communication takes us a long way down the road toward interoperability, both between VMM and UVM and between VMM and SystemC.

We have seen that VMM 1.2 now supports the concept of ports and exports borrowed from SystemC and the closely related concept of sockets from the TLM-2 standard. Armed with these new concepts, VMM now offers two alternative communication mechanisms: communication between a producer and a consumer through an intermediate channel (the vmm_channel), and communication using direct function calls from producer to consumer (and vice versa) through ports and sockets. So what? Well, the benefits of direct communication were reviewed in an earlier post, but in summary, the simplicity of direct communication can speed up simulation by removing the number of context switches between processes and can provide an easy-to-follow completion model for knowing when a transaction is over. VMM users now have the choice between channel-based communication and direct communication. Channel-based communication works just fine, and may be preferred in native VMM environments. Direct communication is closer to the communication model used in UVM and in SystemC TLM-2.0, so may be preferred when working in a mixed environment, such as when integrating VMM and UVM components or when driving SystemC models from a VMM test bench.

We have also seen that VMM 1.2 supports the generic payload and extension mechanism from the SystemC TLM-2.0 standard. Frankly, this addition is unlikely to be of much interest in native VMM environments, but could be critical when it comes to including SystemC reference models in a VMM test bench. Say you have an existing SystemC reference model written to the TLM-2.0 standard, and you want to drive it from a VMM test bench. The new features in VMM 1.2 would allow you to construct a transaction within the VMM environment that has precisely the attributes expected by the TLM-2.0 standard generic payload, and then to pass that transaction over the fence from SystemVerilog to SystemC. It is possible to code the SystemVerilog-to-SystemC interface yourself using the DPI (for details see http://www.doulos.com/knowhow/sysverilog/DVCon10_dpi_paper) or to use the TLI (Transaction Level Interface) provided by Synopsys. I will say more about the TLI in a later post.

I have heard some VMM users say that they like the idea of being able to use the industry standard blocking transaction-level interface in VMM. Indeed, given the relatively small size of the overall hardware verification community and the cost of maintaining multiple standards, the sharing of ideas between standards in this way has to be a good thing. The early adopter release of UVM, the Universal Verification Methodology from Accellera, uses communication based on the SystemC TLM-1 standard. Even as I write this post, Accellera are considering the best way to incorporate the TLM-2-style interfaces as used in VMM into UVM, which should help make transaction-level communication between the two methodologies a little easier.

John Aynsley, CTO, Doulos

Having introduced both the blocking and the non-blocking transport interfaces in previous blog posts, it’s now time to look at TLM sockets in VMM 1.2.

In the SystemC TLM-2.0 standard, sockets are a mechanism that simplifies the instantiation and binding of multiple ports and exports for the various standard transaction-level interfaces by encapsulating several interfaces in a single object, the so-called socket. One initiator socket is bound to one target socket using one bind operator, and it is then possible to call all of the standard TLM-2.0 interface methods through that one pair of sockets. Moreover the socket has a BUSWIDTH parameter which represents the width of the data word transferred over the bus on each beat and which prevents sockets of different widths being inadvertently connected together.

Because VMM supports neither the full set of interfaces from the TLM-2.0 standard, nor the functionality of specified bus widths, nor the interoperability achieved by mandating the use of standard socket types, the value of sockets is considerably reduced in VMM compared to the SystemC TLM-2.0 standard. Nonetheless, the TLM sockets in VMM do allow both blocking and non-blocking transport method calls to be made through a single pair of sockets.

Let’s look at an example:

class initiator extends vmm_xactor;
`vmm_typename(initiator)
vmm_tlm_initiator_socket #(initiator, vmm_tlm_generic_payload) m_socket;
…

begin
…
m_socket.b_transport(tx, delay);
…
end
…
begin
…
status = m_socket.nb_transport_fw(tx, phase, delay);
…
end

virtual function vmm_tlm::sync_e nb_transport_bw( int id=-1,
vmm_tlm_generic_payload trans, ref vmm_tlm::phase_e ph, ref int delay);
…
endfunction : nb_transport_bw
…
endclass: initiator

As you can see above, the vmm_tlm_initiator_socket allows both b_transport and nb_transport_fw calls to be made through a single socket, as well as being able to accept incoming nb_transport_bw calls.

On the target side, the vmm_tlm_target_socket accepts incoming calls to both b_transport and nb_transport_fw as well as allowing outgoing calls to nb_transport_bw:

class target extends vmm_xactor;
`vmm_typename(target)
vmm_tlm_target_socket #(target, vmm_tlm_generic_payload) m_socket;
…

task b_transport(int id = -1, vmm_tlm_generic_payload trans, ref int delay);
…
endtask : b_transport

virtual function vmm_tlm::sync_e nb_transport_fw( int id=-1,
vmm_tlm_generic_payload trans, ref vmm_tlm::phase_e ph, ref int delay);
…
endfunction : nb_transport_fw

…
begin
…
status = m_socket.nb_transport_bw(tx, phase, delay);
…
end
…
endclass: target

Finally, at the top level, there is just a single pair of sockets to bind:

class tb_env extends vmm_group;
`vmm_typename(tb_env)
initiator  m_initiator;
target     m_target;
…

virtual function void build_ph;
m_initiator = new( “m_initiator”, this );
m_target    = new( “m_target”,    this );
endfunction: build_ph

virtual function void connect_ph;

m_initiator.m_socket.tlm_bind( m_target.m_socket );

endfunction: connect_ph

endclass: tb_env

That’s all there is to it!

The SystemC TLM-2.0 standard provides so-called convenient sockets, some of which can automatically convert incoming calls from b_transport to nb_transport and vice-versa. The VMM implementation achieves a similar result using the vmm_connect utility, which I will describe in a future post.

Currently, RAL does not schedule multiple concurrent READ/WRITE accesses to the same register at the same time. RAL
assumes all physical transactions to be atomic, i.e. a transaction is completed before the next cycle is started.
Even if we try to do a parallel READ, RAL will block one of the two accesses and schedule it sequentially. This is
to ensure that the accesses are not corrupted and also because of the fact that the main idea behind RAL is in
abstracting accesses to the registers.

However, in specific cases, there might be a verification requirement to create specific corner cases on the buses.

A typical corner case to check parallel access to a shared register would be as shown in the code snippet below,

Sample code :

     fork
       /* READ the CONTROL_REG via the APB interface */
       env.ral_model.blk_inst.CONTROL_REG.read(status, data , , "APB");

       /* Read the CONTROL_REG via the AHB interface */
       env.ral_model.blk_inst.CONTROL_REG.read(status, data , , "AHB");
     join

Our intention here is to query the control register from two different domains "APB" & "AHB" in parallel or write
through one interface and do a read access through another. But as already mentioned, a controlling semaphore
mechanism tied to each register will sequentially schedule the above two accesses. To create such corner cases we
can use the RAL proxy transactor with "vmm_ral_access::read/write()" which is not going be blocked as the semaphore
resides in the register. The code below illustrates how we can do this.

Sample code :

     fork
       /* READ the CONTROL_REG via the APB interface */
       env.ral.read(status, env.ral_model.blk_inst.CONTROL_REG.get_address_in_system("APB"), data, 32, "APB");

       /* READ the CONTROL_REG via the AHB interface */
       env.ral.read(status, env.ral_model.blk_inst.CONTROL_REG.get_address_in_system("AHB"), data, 32, "AHB");
     join

The "vmm_ral_reg::get_address_in_system()" method can be used here to generate the correct address corresponding
to the domain of interest and the same can be passed with the "vmm_ral_access::read()/write()" task. 

We can also do the following:

1)	Read CONTROL_REG through one of the interfaces using "env.ral_model.blk_inst.CONTROL_REG.read()" &
2)	Read the same register via vmm_ral_access::read() through the other interface as illustrated in the
        sample code below.

Sample code :

     fork
       /* READ the CONTROL_REG via the APB interface */
       env.ral_model.blk_inst.CONTROL_REG.read(status, data , , "APB");

       /* READ the CONTROL_REG via the AHB interface */
       env.ral.read(status, env.ral_model.blk_inst.CONTROL_REG.get_address_in_system("AHB"), data, 32, "AHB");
     join

Because the semaphore is in the register, the access through the proxy transactor is not going to be blocked. 

Also, if the DUT and physical transactor supports pipelined read/write accesses, the generic transactions can
also be executed concurrently. You must first enable this capability by defining the compile time macro,
VMM_RAL_PIPELINED_ACCESS.

Amit Sharma, Synopsys

In one of my previous posts on  Virtual Registers I talked about how you use RAL to model Virtual Registers or fields which are an efficient means of implementing large number of registers in  memory or RAM instead of individual flip-flops.  I also mentioned that they are  implemented as arrays associated with a memory.

In this post, I will talk about how you access these registers through RAL. Normal registers can be accessed using  the hierarchical name in RAL. For these, RAL  would generate the offsets and addresses required.  However, for virtual registers, along with  the virtual register name you need to provide the index ID to refer to them for read and write operations. Accordingly, RAL  generates the offset address based on the index ID of the virtual register.

Consider the following example:

The above RALF specification would translate into the following SV classes in the RAL model

‘DMA_BFRS’  which is the instance of the Virtual Registers class ‘ral_vreg_dut_DMA_BFRS’ is not an array in the RAL Model and is thus different from a typical register array modeled in RAL.

Now, how do you access the individual registers mapped to the memory?  You have to specify the index as the argument to the read/write methods. For example, To access the 4th index of this array, the access would like:

blk.DMA_BFRS.write(4, status, ‘hFF);

RAL would ultimately access the RAM to enable this access. Hence, the following are functionally equivalent:

blk.DMA_BFRS.write(4, status, ‘hFF);
and
blk.ram.write(4 * 0×0004 + 0×1000, status, ‘hFF);

The following illustration explains this point:

You can see that you now have an option to access these registers in different modes, but both will eventually go through the RAM. You can leverage the Virtual register Callbacks or the RAL memory callbacks for additional customizations and extensibility, in addition to other capabilities that you get when you are using VMM RAL.

Hope, this was useful.. do comment on any other specific functionality that you might look at when modeling these kind of registers.

Paul Kaunds, founder, Kacper Technologies

Today power has become a dominant factor for most applications including hand-held portable devices, consumer electronics, communications and computing devices. Market requirements are shifting focus from traditional constraints like area, cost, performance and reliability to power consumption.

For efficient power management, power intent has to be reviewed at each phase along the design flow — starting from RTL, during synthesis, and in place and route in the physical design. Power specifications of the design will be common throughout the flow. In order to implement uniform power flow, we need a common format which is easily understood by all tools used along the flow with reusability and that can be declared independent of the RTL. The creation of the UPF (unified power format) as the IEEE standard has been the best solution for specifying power intent for design implementation as well as verification. UPF sits beside design and verification, and develops relationship between the design specifications and low power specifications.

Understanding the driving factors, designers have opted for advanced low power design techniques like Power Gating, Multi Supply Multi Voltage (MSMV), Power-Retention, Power-Isolation etc. Such low power constraints have increased design complexity, which have a direct impact on verification. This makes the verification engineers’ job more challenging as they have to verify the power intent bugs along with functionality.

Some of the low-power design verification challenges are:

• · Power switch off/on duration
• · Transitions between different power modes and states
• · Interface between power domains
• · Missing of level shifters, isolation and retention
• · Legal and illegal transitions
• · Clock enabling/toggling
• · Verifying retention registers and isolation cells and level shifter Strategies

To tackle these challenges, we need a structured and reusable verification environment which is power aware and encapsulates the best practices when verifying such complex low power designs. To address the low power requirements of one of the complex telecom designs, we made use of (Verification Methodology Manual for Low Power (VMM-LP) ) for SONET/SDH verification. (http://www.vmmcentral.org/vmmlp/vmmlp.html)

We developed a framework for accelerating the verification of low power designs. Our verification environment included VMM along with UPF, RAL, and a power state manager controlled by a power management unit.

Generation of Power control signals

Power Scenario generation

Power scenario generation eased the verification of power aware designs. To generate power signals, a user can simply enter the ranges in a scenario file depending on power specifications. The same generator can be used along with any other VMM environment without any modifications for conventional verification. Some of the capabilities that can be made configurable in this scenario include: varying retention, isolation and power widths.  Additionally, other key capabilities were enabled:

• · Adheres to standard power sequence as specified in VMM_LP
• · All the power signals and power domains are parameterizable
• · Power Generator can be hooked to any VMM environment
• · Gives a well defined structure to define power sequences
• · Avoids overlapping of control signals
• · Allows multiple save, restore in each sequence

The Power state manager takes care of state transition operations by defining power domains, states, modes and their dependencies. It is the key holder for all power transitions that can monitor all transitions dynamically.

Automated Power Aware Assertion Library

Another mechanism to address the challenges in low power verification is the usage of powerful LP assertions. Low power assertions are dealt in conjunction with design’s logic data checkers. VMM-LP assertion rules and coverage techniques helped us to achieve a comprehensive low power verification solution. It suggested some handy recommendations to ensure a consistent and portable implementation of the methodology.

To increase our efficiency of Low Power Telecom design verification, we also developed an automated Power Aware Assertion Library which is generic to any domain and can be hooked to any design. Assertion library is built on top of VMM_LP rules and guidelines with standard power sequencing. Key features of our Assertion library include:

• · Assertions to verify access of software addressable registers in on/off conditions
• · Clock toggling during power on/off
• · Reset during power off
• · Power control signals sequencing etc.
  

More details on our flow and usage can be found online in the paper we recently presented at the Synopsys User Group meeting (SNUG) in Bangalore:

https://www.synopsys.com/news/pubs/snug/india2010/TA3.1_Kaunds_Paper.pdf
https://www.synopsys.com/news/pubs/snug/india2010/TA3.1_kaunds_pres.pdf