FW: Abstract of Axis' transaction interface donation


Subject: FW: Abstract of Axis' transaction interface donation
From: Bailey, Brian (brian_bailey@mentorg.com)
Date: Fri Feb 14 2003 - 07:52:27 PST


 
-----Original Message-----
From: Steve Wang [mailto:wang@axiscorp.com]
Sent: Friday, February 14, 2003 6:35 AM
To: itc@eda.org
Cc: Bailey, Brian; Vassilios.Gerousis@infineon.com; Jason Andrews
Subject: Abstract of Axis' transaction interface donation

 Included is the abstract for Axis' transaction interface donation. Please help review
the document in preparation for our conference call next week. Apologize for the delay
as I was busy with many other activities within Accellera for the past week. Please
forward me any questions you may have. Thank you.
 
(Jason or Brian, I may not be on the reflector so that this message may not be sent to the alias.
If you do not receive this message from the alias, can you forward it to the alias for me.
Thank you.)
 
------------------------------------------------------------------------------------------------------------------------
 
The objective of Common Transaction Interface (CTI) is modulize transaction Verification IPs into three separate components and provide well-defined interfaces associated with each component. Transaction IPs written for CTI can function in a standalone simulation environment running on a workstation, co-simulate on a simulation acceleration platform or run independently in an emulation environment. CTI's three components are: Environment, Transaction API, Bus Functional Model (BFM) macros.

CTI Environment

CTI environment's purpose is to program the transaction testing settings. C libraries include the following functions:

Threads (Parallel operation)

· Creation, start, yield, abort, and reset

· Conditional activity based on event triggering, time, function

· Signal definition to trigger an event activity

· Synchronization between threads

Memory

· Initialization

· Load

· Dump

Transaction API

Transaction API's purpose is to send and receive transactions, control FIFO transaction management and perform HW/SW synchronization functions. Within the CTI architecture, two FIFOs exist. One is dedicated for transferring transactions from the test generation environment to the Bus Functional Models (BFM). The other is for sending acknowledgements and messages from the BFM or DUT to the test environment. C libraries include:

Transaction Management

                        Put and get transactions from FIFO. (blocking and non-blocking calls)

Hardware/software synchronization

Optional synchronization routines to create software signals based certain
hardware activity. Includes timer wait routines.

FIFO Transaction Management

CTI architecture contains a buit-in FIFO for transaction input and output.
FIFO management functions include the following:

                        Initialize, sleep, synchronize, wait, query, space availability, flush

Bus Functional Model (BFM) Verilog/VHDL macros

BFM macros are Verilog or VHDL modules that the user instantiate to get and put data into the transaction FIFO. Transaction instructions, data and result notification are exchanged with software through the virtual channel FIFO.

For bus protocols that require transaction look-ahead, the BFM marcros provides macros to access all transactions within the FIFO to a dedicated memory buffer and provide instructions to scan the memory buffer. The common instruction decoder first identifies the group to which the instruction belongs, then passes the instruction header to the responsible processor and grants the FIFO control to the processor upon request for additional data access. More information is provided within the documented specification.

 

Documentation

A 114 page documentation is available along with architecture diagrams.

Interface Adoption & History

This interface has been successfully implemented with Axis' RCC simulation, acceleration and emulation system. Customers currently are using the Axis implementation of this interface for the AMBA and PCI transaction models. Additional transaction bus models are in development by Axis and independent model developers.

            

 



This archive was generated by hypermail 2b28 : Fri Feb 14 2003 - 07:53:06 PST