Subject: Use Cases & Requirements
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Sun Aug 11 2002 - 16:09:54 PDT
Hello,
I am a simple minded guy that looks at this effort from a user's perspective. The easiest way for me to do this is to derive requirements from the intended use cases. So what are these?
My initial set would be:
UC1) Deliver an API for the new assertion capabilities of SystemVerilog (SV)
[background: interface or enhancements for these new features]
UC2) Provide a set of features to obtain/generate coverage data for SV
[background: needed for profiling/test coverage/statistics on the generated code]
UC3) invocation of foreign language (FL) functions/procedures from SV
[background: extension of SV functionality with user defined functions]
UC4) inclusion of FL modules in a SV simulation
[background: usage of C/C++/SystemC/Esterel-C/whatever models in a SV simulator]
UC5) synchronization of a FL application/module with the Verilog simulator
[background: another simulation kernel/ISS needs to be integrated]
UC6) enablement of debug support for software/u-programs executed by the set of models within SV
[background: if we want to support HW/SW co-xxx; then we also need to look at this]
What would be the high level requirements for this? A set of very high level requirements can be:
UC1:
[ no experience here, I'm sorry ]
UC2:
. identification of SV object to obtain coverage data (fsm-states/transitions,reg/wires/interfaces,module,line,statement/blocks,toggles,...)
. must cover all possible types of SV objects (what about C-like objects, int, ...)
. start/reset/stop counting
. return maximum reachable value
. return non-covered SV objects
. return count on covered SV objects
. definiton of conditions for selective coverage, pruning of the counting process ("count if "...)
. user definable coverage specification ("watch object for")
. save/restore (for counting check points)
UC3:
. pass SV values to the FL code and vice versa
. modification of SV values passed to the FL code
. support of the complete set of data types defined within SV for parameter passing
. provision of conversion functions for SV specific data types into FL data type and vice versa
. FL function/procedures are executed without modifying time (neither real time, nor delta cycle)
UC4:
. capability to instantiate an instance of the FL module within VL (in SV)
. method to define the connectivity between the ports of the FL module and SV (in the FL or in SV)
. explicitely defined, crystal clear execution semantics for the FL module
. information about simulation specific events (e.g. start-up, terminate, initial reset, save/restore)
. capability to convert pin-wiggling based I/O to transaction-level I/O and vice-versa
[ also in case of transactions that are distributed over time ]
. solve the issue of resolution over the VL/FL boundary (x VL drivers + y FL drivers -> net value)
. capability to identify the sensitivity of ports of the FL module
. FL module is executed when at least one of the (sensitive) ports at its boundary changes its value
. Post port changes from within the FL module
. Generate events from within the FL module
[ how to handle FL modules within synthesis ]
UC5:
. capability to interfere when simulation advances (time changes, delta cycles changes)
. information about simulation specific events (e.g. start-up, terminate, initial reset, save/restore)
. request to halt, terminate simulation, save/restore
UC6:
. identify SV specific information that must be made visible for debug purposes (Debug Objects)
. access to SV specific information (e.g. reg, wire, memory, interface); especially read/write
. capability to interfere with accesses to Debug Objects by the simulator
. synchronize with SV simulator; request to stay in a known state while doing debug work
. halt, terminate, start simulation
. ability to define user specific debug functions that can be interactively executed (see UC3);
registration of these functions and invocation by the user
General Requirements
Compiler independence
- the API's must not be dependent on the usage of a specific compiler for the FL
OS independence
- the API's must not be dependent on a specific OS (Solaris, Linux, HP-UX, Windows)
- no dependence on endianess, threads handling
Clearly defined semantics
- the API's must behave consistent in clearly stated manner
64-bit support
Support for all data types of SV in a consistent and complete manner
Just my $0.02
Regards,
Michael
P.S. And yes, I know I am acting against my quote :-)
-- Quote of the day: "Better to remain silent and be thought a fool than to speak out and remove all doubt." [Abraham Lincoln (1809-1865)]NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( ) when marked, please note: This e-mail and any attachments are confidential and Motorola reserves all rights of privilege in respect thereof. It is intended for the use by the addressee only. Please delete it from your system, if you are not the intended recipient. Any use, disclosure, or copying of the included information is unauthorised. ___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, ASA Methodology | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
This archive was generated by hypermail 2b28 : Mon Aug 12 2002 - 01:34:41 PDT