| 1: |
What is STL? |
| A: |
STL is an acronym for Socket Transaction Language. STL describes a
flexible assembler-level transaction description language that a
CoreCreator QuickCore Model reads to determine what transactions it should
initiate on its OCP master interface to exercise an OCP slave core
design. |
|
| 2: |
Do I have to use only STL for my QuickCore Model OCP
tests? |
| A: |
Either STL or the Verilog task-based interface can be used to develop
QuickCore Model OCP tests. This support for the Verilog task interface was
provided as part of the OCP 2.0 specification and the CoreCreator 4.0
version. |
|
| 3: |
What are the differences in using STL and Verilog for my QuickCore
Model OCP tests? |
| A: |
STL is a basic assembler-level transaction level language, while the
Verilog task interface is based upon the higher-level Verilog language.
STL only provides the ability to drive the Master side of the OCP
interface, while the Verilog task interface has a extensive library of
routines for both the Master and the Slave. |
|
| 4: |
Can I use both STL and Verilog for my QuickCore Model OCP
tests? |
| A: |
In general, the STL and the Verilog task interface should be viewed as
two separate programming approaches for programming the QuickCore models.
If these two programming interfaces are mixed together, then unpredictable
results may occur. However, there is one case where the Verilog task
interface can be safely used with STL. This is the case where the Verilog
task interface state tasks can be used to set up the state environment for
the Master model, and then STL can be used to drive the Master model. |
|
| 5: |
Can I use VHDL for my QuickCore Model OCP tests? |
| A: |
Unfortunately, at this point in time, the QuickCore Models only
support the Verilog task interface, along with STL. However, support for
the VHDL language could be added as an enhancement in the future. |
|
| 6: |
If I join OCP-IP, what software do I get? |
| A: |
You gain access to software called "CoreCreator" and "CoreCreator II."
The legacy CoreCreator is actually a set of programs. It includes a
graphical user interface, as well as programs, to dissassemble trace files
into human readable form, to protocol check these trace files and to
report on the performance shown in the trace files. CoreCreator also
includes the Quick Model Cores, which are bus functional models for OCP.
Legacy CoreCreator does not support OCP 2.2.
CoreCreator II allows users to verify, debug, and analyze OCP Cores and
OCP-based Systems. It is comprised of two fundamental component parts:
first, Synopsys DesignWare® verification IP provides OCP master and slave
transactors that generate and respond to all types of OCP 2.2
transactions, and a simulation monitor that provides coverage reports of
the functional coverage groups defined in the Protocol Compliance section
of the OCP Specification. Second, Sonics' performance analyzer (ocpperf2)
and disassembler (ocpdis2) measure interface performance and help view the
behavior of the OCP traffic. Both component parts are configurable to
support the wide range of OCP 2.2 interface options.
CoreCreator II can be used with traditional Verilog and VHDL testbench
environments to create directed tests for OCP designs. It now also adds
support for the Verification Methodology Manual that can be used to
develop constrained-random verification environments. CoreCreator II
provides the Verification IP and debugging tools necessary for validating
Open Core Protocol implementations, reducing design time and risk,
ensuring rapid time to market.
For more information please visit www.ocpip.org/socket/corecreator
or contact admin@ocpip.org.
|
|
| 7: |
What RTL and simulation languages are supported by
CoreCreator?
|
| A: |
Both Verilog and VHDL are supported. All popular simulators are
supported including Verilog-XL, NCVerilog, VCS and ModelSim. |
|
| 8: |
Can CoreCreator be used on Linux based systems? |
| A: |
The default platform for the CoreCreator toolset is Sun Solaris,
however this toolset is also made available for the Linux platform. |
|
| 9: |
How is OCP compliance testing done? |
| A: |
When using CoreCreator to exercise an OCP interface, an OCP monitor
generates an activity log, which is processed during simulation by the
OCPCHECK2 program. This OCPCHECK2 program analyzes this OCP activity, and
checks to see that this activity conforms to the OCP protocol
specification. Thus, any OCP protocol violations are immediately reported
during simulation. However, this OCPCHECK2 tool can also be run in a
stand-alone mode as a simulation post-processing step after the simulation
completes. |
|
| 10: |
How do I know if my core is OCP compliant? |
| A: |
There is not a test vector compliance set at this time. So, you should
construct an STL file and/or Verilog task interface file, that exercises
all OCP operations the core needs to comply with. To test the design using
CoreCreator as described above - write representative testbenches of your
core's behavior and run a simulation with the OCP checker on. Any protocol
deviations are flagged in the ocpcheck output file for the core. |
|
| 11: |
What does the OCP protocol checker check for? |
| A: |
It monitors all of the activity across the OCP interface, and checks
for all aspects of the OCP protocol. STL or the Verilog task interface can
be used to drive OCP activity on the OCP interface, and the OCP protocol
checker will check to see that this OCP activity meets all of the
requirements of the OCP protocol, as defined in the OCP
specification. |
|
| 12: |
If my bridge passes OCP check, is it OCP compliant? |
| A: |
The interactions that OCPCHECK authenticates are. However, unchecked
ones may not be. There is no attempt to verify that all possible OCP
signal sequences are exercised. Thus, STL or the Verilog task interface
should be used to generate a sufficient number of OCP transactions, which
thoroughly exercise all of the various OCP capabilities for this bridge
interface. |
|
| 13: |
What are OCP-IP's plans for compliance testing? |
| A: |
Currently, OCP-IP has a self-certification program where members
obtain vendor identifications and use our CoreCreator product to determine
compliance. We have reviewed current industry practices and have made
available English-based rule sets to permit verification by both assertion
and traditional functional verification approaches. These verification
rule sets are described in detail in the OCP 2.2 version specification. A
large group of EDA providers have shown interest in making these rule sets
with their commercial offerings. |
|
| 14: |
What types of verification rule sets does OCP-IP provide? |
| A: |
The OCP 2.2 Specification provides very detailed information
concerning verification checking in the following areas: Protocol
compliance, Configuration compliance and Functional Coverage. These
detailed rule set description are provided to allow developers to create
their own verification tools for OCP verification. These tools can be
developed using either static or dynamic verification approaches. |
|
| 15: |
What levels of functional coverage are used for OCP compliance
testing? |
| A: |
OCP compliance testing considers functional coverage at the signal
level and the transaction level. Detailed information concerning toggle
coverage, state coverage, and meta coverage requirements and
recommendations are provided in the OCP 2.2 Specification. |
|
| 16: |
Why are there no transfer level functional coverage
metrics? |
| A: |
Recall that the OCP hierarchy is signal, phase, transfer and
transaction. Thus, it would seem natural that OCP functional coverage
would follow the same ordering. However, this ordering does not work well
for SRMD bursts, since the number of phases per transfer is not constant.
In addition, the combination of phases into transfers is a pure protocol
checking related matter. Thus, the transfer level is not considered with
regard to OCP functional coverage metrics. |
| [[CODE ] ] |
