The other day I saw some posts to the Yahoo Specman group regarding e ports. The last one in the thread asked for some introductory information on ports which I thought might make a good topic for my entry today.
As I was researching what I wanted to include in the post when I came across some related content in Chapter 7 of the Usage and Concepts Guide for e Testbenches manual in the Specman help. Rather than ramble on myself, I thought it might be better to just quote this entry, as a good introduction, and then add a few comments afterwards. Enjoy!
“…
A port is an e unit that connects to a simulated object or another e unit. There are five kinds of e ports:
• Simple ports -- Let you sample and drive objects written in a foreign language or transfer data between e units.
• Event ports -- Let you make an e unit sensitive to an event in a foreign object or make the foreign object sensitive to an e event. You can also use event ports to transfer events between e units.
• Method ports -- Let you make calls between e methods and foreign language functions or between e methods in different e units.
• Buffer ports -- Let you insert data elements into a queue or extract elements from a queue in FIFO order.
• Indexed ports -- Let you access sub-elements, like simple field types, of complex elements modeled in Verilog or SystemVerilog.
External Ports Versus Internal Ports
• The main usage for simple, event, and method ports are as external ports--connecting an e unit to a simulated object. However, these ports can also be used as internal e2e ports--connecting an e unit to another e unit.
• Buffer ports are supported for internal (e2e) ports only.
• Indexed ports are supported for external simple ports only.
Benefits
Ports are a critical component of reusable verification environments, especially for system-level verification. Ports let you create a transparent interface to any external simulation vehicle. For example, via ports, the same verification environment is usable for HDL, SystemC, and HW accelerated designs.
An external port is bound to a simulated object, such as a Verilog register or net, VHDL signal, SystemVerilog array, or SystemC method. To use the port to access a different object, you simply change the binding. All the code that reads or writes to the port remains the same. Similarly, port semantics remain the same, regardless of what simulator is used.
Example
unit encoder {
clk: in event_port is instance; // event port declaration
keep bind(clk, external);
keep clk.hdl_path() == "clk";
};
… “
I think that is a good explanation of what ports are, and a little bit on how to use them. However, there is one thing that isn't immediately obvious from the text book explanation. In short, Ports provide a great way to formally build strong encapsulation into your e environment.
To elaborate, using ports between e units creates an extremely robust interface that is easily documented; and I think that this is a key point that is often overlooked when using ports. This "robust interface" concept is critical to effective code reuse, as well as distributing code development across multiple resources and geographies. Specifying clean interfaces and promoting encapsulation facilitates both of these activities. Thus, if you are not already familiar with ports I believe that you will quickly find that they provide a better solution then the more traditional pointer based approach.
As always, I would love to hear your thoughts on using ports.
Stay tuned as I think I would like to add some more to this topic in a future post.
Until Next Time…
Brett Lammers
Advanced Verification Core Competency Team Member
Cadence Design Systems, Inc.