RE: [sv-bc] [Fwd: [sv-cc] Added Mantis item 2054 - deprecate Data Read API]

Hi all:

the original intent of the read-api was to address the following issues:

1- handling new types (structs, etc). This, of course, could also be done by appropriate extensions to VCD.
2- handling "dynamic" data. By this I mean data that is not static to the design but appears/disappears as the simulation runs:
automatic variables, dynamic arrays, queues, mailboxes, program threads, etc
3- representing assertion status/coverage status/"transaction" status, effectively embedded markers in the data stream, with
attached meta-data.

Another impetus was that, at least at the time, all vendors had their own proprietary internal waveform representation, and for all
VCD was typically a 2nd best representation. The read API was intended to be a common API to all those internal database-like
representations ie it does not require a specific on-disk representation, merely requires a standard interface to such data. Vendors
would be able to keep their own particular internal formats without exposing their know-how while still permitting users access to
the contents.

In addition, a VCD file is just a linear store. There is no way to index into such a file without reading it all first. As VCD files
get larger and larger, the cost to reading even just a small handful of signals is very high and proportional to the length of the
file and not to the activity of the signal being read. And suggestions of using compression make the VCD indexing problems
significantly worse. 

Further, it is almost impossible to make scalable parallel parsers for linear text files, but quite straightforward to do for
database-type representations. Given that multi-core CPUs are now the norm, failing to create a representation that such machines
can use would be a major failing. As multi-threaded programming is my bread-and-butter these days, this class of technical concern
shows up high in my priorities.

As to the issue raised by Michael that large parts of the user community are not C coders. Yes, this is a legitimate concern, but at
the same time it is possible and even straightforward to adapt a C interface for usage in Tcl/Perl/Python/etc. I understand that
existing VCD processing scripts would no longer work. But such scripts would in any case need to be significantly modified to deal
with the new types and categories of data that SV can expose.

Anyway, as most know, I no longer work in simulation so I haven't been tracking in much the SV standard nor following what has been
happening with the read API. When it was first put together the champions were Bassam Tabara and I (aka Novas and Synopsys)

Purely from a standards perspective, I think the read API has a place and an important one. I believe this is at the same level of
importance as the other interfaces (direct API, VPI). But at the same time, currently I am not free to give much of my time to the
standard, so I cannot backup my opinions with much action. Can anybody step up?

Joao


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.