-----Non-member submission----- Message-ID: <44A8ECA6.2070003@freescale.com> Date: Mon, 03 Jul 2006 12:08:38 +0200 From: Michael Rohleder <michael.rohleder@freescale.com> Organization: Freescale Semiconductor Hi all, sorry for speaking up without having been asked to do so, but as a one of the very few industry members in this committee I feel I have the obligation to do it ... Bassam, you are right that one trend in our industry is to go away from file-based interchange methodologies. I believe there is no need to discuss the reasoning behind this, but on the other hand there is seldom a full replacement of an file based interchange method with an API based interfacing; usually they coexist or you can use the file based route for debugging means (a good example for this would be the OpenAccess API). And, as Stu and Neil correctly pointed out, .vcd files are used for much more than interchanging waveform information between a simulator and a waveform viewer. Last, but not least, I think we should never ignore the user's perspective here. Not all engineers I know are so familiar with C/C++ that they would be happy to have just a Read API to access waveform information. I would strongly suggest to - enhancing .vcd file format and syntax to include the new information available within SystemVerilog AND - further improving the read API (and probably define a write API) that is on par with these capabilities for providing a faster access to the related data Best regards, -Michael Rohleder Bassam Tabbara wrote: >Hi All, [apologies for wide cc] > >I want to comment that the trend in our industry today, driven by users, >is to move away from file-based interchange for obvious reasons that I >will not motivate here (some is in clause already). If gate abstraction >and below is taking this route it behooves SV's RTL and above to do so >too and move away from files. The Read API does this by using SV's VPI >as the data model/access API. Yes Stu some more control/read >extension/specialization is warranted (for tasks/API) for new types, and >yes Neil the *write* API is missing, covered in part by ease of DPI/SV >task call. > >The data model approach is a "new" (tool-integration) use model so >likely will have some growing pains. We can make the call on whether to >put resource into improving it or fall back on extending VCD despite >known issues and limitations. > >Thx. >-Bassam. > >-----Original Message----- >From: owner-sv-cc@eda-stds.org [mailto:owner-sv-cc@eda-stds.org] On >Behalf Of Stuart Sutherland >Sent: Monday, June 26, 2006 11:01 PM >To: Neil.Korpusik@sun.com; 'Francoise Martinolle' >Cc: sv-cc@verilog.org; sv-bc@verilog.org; 'Clifford E. Cummings' >Subject: [sv-cc] RE: [sv-bc] FW: mantis item 104: vcd file and data read >API > > >I agree with all that Neil has said. I will add that VCD files are used >for more than just waveform displays. Some companies have in-house >tools that extract information from VCD files. VCD is an important part >of HDL based design, and needs to be enhanced to support more of >SystemVerilog types, including dynamic types. VCD also needs to be >enhanced to provide more efficient file formats. Standard switches need >to be added to the VCD system tasks that provide for more capabilities, >and for backward compatible modes. In-house tools seldom migrate to new >language features as quickly as EDA vendors, so backward compatibility >is critical. > >Stu >~~~~~~~~~~~~~~~~~~~~~~~~~ >Stuart Sutherland >stuart@sutherland-hdl.com >+1-503-692-0898 > > > > >>-----Original Message----- >>From: owner-sv-bc@server.eda-stds.org >>[mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Neil Korpusik >>Sent: Monday, June 26, 2006 6:31 PM >>To: Francoise Martinolle >>Cc: sv-cc@server.verilog.org; sv-bc@server.verilog.org; Clifford E. >>Cummings; stuart@sutherland-hdl.com >>Subject: Re: [sv-bc] FW: mantis item 104: vcd file and data read API >> >>Here is my feedback on the question of vcd versus the SystemVerilog >>API. >>I am assuming that you are referring to clause 30 in SystemVerilog. >> >> 30. SystemVerilog data read API >> >>I don't view the API described in clause 30 as a replacement for the >>vcd file format. There is a completely different use-model required >>for each of these. >> >>vcd: >> >> This file format allows data produced from one application to be >>read into >> a different application. There is no extra work required on the >>part of the >> user to pass vcd data between applications that support this file >>format. >> Each application understands the same file format. >> >>API: >> >> In order to use the API to pass data between applications can >>require some >> effort on the part of the users. In order for the data produced by >>one >> application to be used by another application requires the >>following: >> >> Application A - writes out data to its proprietary file format >> - must provide the API for this data file. This >>will >> presumably be provided by a library file that >>can be >> linked into a second application. >> Application B - must be able to use the API from application A >>to get >> access to the data written out by application >>A. >> - the provider of application B could provide a >>library >> that could be linked to the API library >>provided by >> application A. That would then allow the user >>of >> application B to link it with the API library >>for >> different applications, so that application B >>can now >> read in data from each of the proprietary file >>formats >> supported by those other applications. >> - alternatively application B could provide a >>prepackaged >> version of its application that already has the >> library for application A linked into it, so >>that it >> can read in the file produced by application A. >> >> > > > >>In >> general, this will not be the case. >> >>This use of the API to allow interoperability of the files produced by >> >> > > > >>one application is useful, but it will undoubtably require work on the >> >> > > > >>part of the user community to make it work. There will most likely be >>a few places where the interoperability will be provided (e.g. for a >>major waveform tool's file format), but in general this type of >>interoperability won't be provided by the tool vendors. It will then >>be up to the user's to be able to link the required set of libraries >>to make it work. >> >>The vcd file format offers a simple means of passing data between >>different applications. Yes, it can be inefficient, but it works. Once >> >> > > > >>we start talking about various libraries and so forth, there can be >>issues with linkers and version compatibilities. >> >>Neil >> >> >>Francoise Martinolle wrote On 06/21/06 09:54,: >> >> >>>Resend since I sent it to eda.org before. >>> >>> >>> >>> >>> >>-------------------------------------------------------------- >>---------- >> >> >>>*From:* Francoise Martinolle >>>*Sent:* Monday, June 19, 2006 2:29 PM >>>*To:* 'SV-CC' >>>*Cc:* Bresticker, Shalom; 'Clifford E. Cummings'; >>>'stuart@sutherland-hdl.com'; Francoise Martinolle; 'sv-bc@eda.org' >>>*Subject:* mantis item 104: vcd file and data read API >>> >>>The BC committee would like to get the opinion of the CC >>> >>> >>committee on >> >> >>>mantis item 104. >>>Mainly the question is "would the database read API be a total >>>replacement for vcd format" >>>or should we extend the vcd format to support new SV datatypes. >>> >>>If we want to extend VCD, should we limit it to statically >>> >>> >>elaborated >> >> >>>objects of the design? (Specifying how dynamically >>> >>> >>elaborated objects >> >> >>>for example automatic variables, or objects of dynamic datatypes are >>> >>> > > > >>>dumped can be difficult.) Currently VCD has been extended to allow >>>unpacked structs >>> >>> >>(section 24.2 >> >> >>>in P1800: this is sort of a hack) but does not provide support for >>>unpacked arrays. >>> >>>Cliff, Stu, >>>can you provide the VCD user point of view? >>> >>>Francoise >>> ' >>> >>> >>-- >>--------------------------------------------------------------------- >>Neil Korpusik Tel: 408-720-4852 >>Senior Staff Engineer Fax: 408-720-4850 >>Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems >>email: neil.korpusik@sun.com >>--------------------------------------------------------------------- >> >>Received on Mon Jul 3 04:26:38 2006
This archive was generated by hypermail 2.1.8 : Mon Jul 03 2006 - 04:26:51 PDT