Hi Brian, ITC members, Assuming you intended to say "limited standard that covers the SystemVerilog HDL", I agree with you proposal. Cadence wants the issue of Verilog and VHDL tabled as an open issue at this time, but we do not wish to bring to the table any proposal that will further defocus the SystemVerilog effort. We believe that the urgency and the pace at which we are progressing in addressing the SystemVerilog issues in SCE-MI 2.0 makes it questionable if we could resolve all 3 HDL languages by the time table that we have agreed upon. I think it is fruitless to predict that and we should cross this bridge when we get to it. Thanks, Shabtay ________________________________ From: Brian Bailey [mailto:brian_bailey@acm.org] Sent: Wednesday, October 12, 2005 4:59 PM To: vreeland@broadcom.com; Shabtay Matalon; bojsen@zaiqtech.com; itc@eda.org Subject: RE: supporting DPI in VHDL - possible scenarios for implementation Hi Guys, I agree with Russ and Shabtay on this. If we can table the Verilog/VHDL discussion for a while and focus on the function call interface for C and SystemVerilog, I think we will be able to work out a number of the kinks in this before we reach our issues deadline. If we completely deadlock on the VHDL/Verilog issues, then we should push forward with a limited standard that covers the 2 languages only, but make sure we provide a clear timetable of when the other languages will be supported directly, rather than being left on the 1.X standard. Brian ________________________________ From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Russell Vreeland Sent: Wednesday, October 12, 2005 4:36 PM To: 'Shabtay Matalon'; bojsen@zaiqtech.com; itc@eda.org Subject: RE: supporting DPI in VHDL - possible scenarios for implementation What I proposed was that we table discussions of Verilog 2001 and VHDL with regard to SCEMI 2.0 until we complete the gist of the specification for SystemVerilog. If it turns out that time doesn't permit revisiting the question before our deadline arrives, then it could possibly be a SCEMI 2.1 topic if the spec continues to evolve. I don't think that we have any discussion or consensus regarding the means that a completely SCEMI 2.0 (no mixed SCEMI 1.1) simulation will use to deliver time to the "C" side from the HDL side. Since there are technologies in play here that don't have to rely on a count of a fastest clock to give a quantized time measurement, I think --- for starting the discussion --- that we should begin with the requirement that every imported function call should include some time information that the C side can use to resync its global time variable. No more frequent time info exchange should be required. In pure simulation mode, no such requirement is necessary -- the C side can get time through vpi accesses. russ --------------------------------------- --- Russ Vreeland (949)926-6143 --- --- vreeland@broadcom.com --- --- Senior Principal Engineer --- --- Broadcom Corporation --- --------------------------------------- -----Original Message----- From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Shabtay Matalon Sent: Wednesday, October 12, 2005 3:14 PM To: bojsen@zaiqtech.com; itc@eda.org Subject: RE: supporting DPI in VHDL - possible scenarios for implementation Hi Per, First, I (and I assume Russ) have not proposed that we drop Verilog and VHDL in SCE-MI 2.0, but that we support it per the SCE-MI 1.1 use model. I don't think that it is realistic to expect significant usage with DPI-based SCE-MI 2.0 approach (given the current time frame proposed for SCE-MI 2.0) to complete the standard on time and also and solidify a Verilog and VHDL solution that meets the objectives that we set for SCE-MI 2.0. Implementing a SCE-MI 2.0 interface along your proposal below that maintains clock control and forces simulation to use cycle stamp as the only mean to account for time, is not the type of solution that will increase adoption of SCE-MI 2.0 based VIPs among simulation users. I think it only reinforces the argument to focus on SystemVerilog first and incrementally add compatible solution for Verilog and VHDL. See my specific response embedded enclosed. Note that I am going on vacation, so you won't hear from me until 10/20. Regards, Shabtay >-----Original Message----- >From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per Bojsen >Sent: Wednesday, October 12, 2005 12:02 AM >To: itc@eda.org >Subject: RE: supporting DPI in VHDL - possible scenarios for implementation > >Hi Shabtay, > >> Your proposal is based on using clock control SCE-MI 1.1 in >> simulation. > >I showed you one possible implementation to answer you challenge >to show an implementation that does not require modifying the >simulator compiler. Do you at least agree that implementing >a function-based interface on top of SCE-MI 1.1 as outlined is >possible without modifying the simulator compiler? You do not >have to like the solution to agree :-) [Shabtay] This is not an issue whether I like the solution or not. Does making the solution for Verilog and VHDL "DPI like" makes it compatible with the SystemVerilog based solution? If we want to do justice to the Verilog and VHDL market with new SCE-MI 2.0 standard, let's either remove clock control as in DPI, provide a solution that does not require clock control (as per the Macro based approach we proposed) or use SCE-MI 1.1 for a while until we come up with a good solution. The problem I see is that each solution that you or John proposed so far for Verilog and VHDL came with its own set of issues resulting with unacceptable solution for Verilog and VHDL simulation users. > >> Such an implementation now forces us back into viewing time >> progression on the HW side by only using cycle stamps. > >Strictly speaking cycle stamp is the only concept of time that exists in >SCE-MI, so this is not a new issue. [Shabtay] This was barely acceptable to emulation users and is not acceptable to simulation users. > >> This imposes significant restrictions on the user. > >I disagree about the restrictions being significant. The whole purpose >of SCE-MI is to provide a fast transport layer from a software-based >verification environment into a simulation engine that in general will >be some sort of hardware accelerated engine, but may also be a software >simulator. If you look at the whole range of engines out there, on most >of them only cycle stamping (counting clock cycles) makes sense as a way >to measure time. SCE-MI users will be aware of this. IP vendors that >write portable models will be aware of this, because they should/will >use the SCE-MI API only and there is no GetSimTime() call in SCE-MI. >So the biggest problem really is that your waveforms may look funny >depending on how the SCE-MI 1.1 subset is implemented. [Shabtay] The waveform issue is a big issue given that debug is a critical part of any solution. I am afraid that we'll have to disagree on this if I failed to convince you so far. > >It has been stated before that it is possible to implement SCE-MI 1.1 on >software simulators in a way that takes care of this problem, i.e., that >allows waveforms to be viewed such that periods where cclocks are >stopped appear as zero simulation time. This is the root of your >problem with using SCE-MI 1.1 as a foundation for implementing a >function-based interface, right? [Shabtay] This issue applies to the approach that you have proposed here. Are you suggesting that we modify our simulator or provide a patch to simulation users? > >> Any trace data and any system tasks that uses time will see a >> different time from the one reported by cycle stamp. > >I don't believe SCE-MI supports system tasks let alone system tasks >that use time, so the real problem is how waveforms appear. [Shabtay] SCE-MI neither supports nor precludes the use of time on the HW side. Users can do what they want. For example, assertions firing on the HW side can report time independently of SCEMI. I think we all reached already the conclusion that we want to eliminate clock control and different view of time moving forward. So why drill on this option? > >> Practically, the simulation use model will be highly restrictive. > >Actually, it will be no more restrictive than running on any emulator >with SCE-MI. So is this unacceptably restrictive? Given that the >goal of supporting SCE-MI on simulators is to allow development and >debugging of SCE-MI-based environments that will run on emulators >eventually, I don't think so. [Shabtay] I'm afraid we disagree. > >> Neither the macro based approach across all HDLs that Cadence proposed >> in the past nor the existing DPI based proposal for SystemVerilog >> imposes such a restriction on the end user. > >Actually they do in part due to the backwards compatibility with >SCE-MI 1.1. [Shabtay] That's a user's choice. If we provide a solution in the future that does not rely on clock control, we leave it to the users to choose which of the two use models they prefer to use. > >> Why would we impose it only on Verilog and VHDL users? > >Well, do not forget that what we are talking about here is just one >possible way of implementing the function-based interface in Verilog >and VHDL. There are other ways that do not use SCE-MI 1.1 clock >control. For instance, instead of replacing the function calls with >SCE-MI 1.1 infrastructure you can replace it with some PLI-based >infrastructure without any clock control mechanism. Calls happen >in zero time solely by virtue of having the simulator thread wait >for the results from the software side. I see now that it was a >mistake to show you a SCE-MI 1.1-based solution; I had assumed that >using SCE-MI 1.1 would be a nice basis due to it being well understood. [Shabtay] Yes, it was a mistake. Can you show me how you use PLI for implementing export functions in Verilog 2001? > >Regardless, any vendor that wants to implement SCE-MI 2.0 on a >simulator must address the SCE-MI 1.1 subset and hence deal with the >clock control issues you talk about. But that is an issue completely >separate from whether a function-based interface has any merit on >`old' Verilog and VHDL. Do you agree? [Shabtay] Yes. > >> We need to distinguish between modifying user's source code and >> mandating that users comply with a certain methodology. Independent of >> the API that is being used, users will have to build transactors, >> define the hierarchies and make connections to certain API resources >> in a certain way. Everything that you have described so far falls into >> the methodology of using the SCE-MI 1.1 API and none requires >> regeneration of the user's environment. > >I would agree with you but I bet that we would not be using the same >definition of `regeneration of the user's environment', then. For >example, in VHDL to make a SCE-MI 1.1 environment simulatable you need >to connect both user-visible SCE-MI 1.1 infrastructure as well as >implementation specific infrastructure from the guts of the macros to >whatever central block does the clock control, for instance. This >could entail adding ports to macro instances, adding extra signals to >the user blocks that instantiate macros, threading these signals up >and down the user's hierarchy, and adding one or more implementation >specific blocks to the user's hierarchy. Does this constitute >regenerating the user's environment? [Shabtay] No it doesn't. I think I explained that above. Users and modelers need to understand an interface its requirements and how to use it. Once they follow the guidelines, we should run their environments with any libraries we wish w/o modifying the source code they use for debugging. > >> Different implementation can do different things. The macros "guts" >> for example could be fully generated by the infrastructure linker or a >> parameterized library may be linked in. > >This is of course irrelevant to what happens to the code that >instantiates these macros. [Shabtay] Correct. > >> The strongest reservation I have to modifying users' code is the >> implication on debug. [...] It is not acceptable to modify their code >> (even if we state that the modified code is equivalent) and ask users >> to debug a modified code regenerated by our application. Do you still >> think that this is acceptable to simulation users? > >Oh, yes, I definitely disagree with you here. Anyone who is used to >C/C++ programming is familiar with this. The code that the compiler >sees is a pre-processed (or regenerated, if you will) version of >the code the user wrote. This is nothing new. It is up to the >implementation to make the impact on debug as small as possible. [Shabtay] Yes, if you build the environment such that you don't expose any code regeneration to the user. I asked your or John to show me an implementation for Verilog on simulation that does all that. Instead of just telling me what we should do, why won't you address to the my original request and show me how you implement the flow on standard Verilog 2001 simulator using PLI/VPI or whatever the simulator can support? > >> But I have not seen yet a proposal for a functional bases API that its >> implementation meets these principles. > >You did not really answer my question, so let me rephrase. The >function-based interface proposals you have seen so far fail to >meet your principles. Is it correct that the only principle they >fail to meet is the `no code regeneration' principle? If not, what >other principles do they fail? [Shabtay] The example above with your SCE-MI 1.1 clock control based proposal illustrates that you can work around one issue (avoid code regeneration) and stumble on a different issue. Let me suggest that you illustrate the 'no code regeneration' with Verilog 2001 using PLI. I listed the important principles we look at, but I can't guarantee it is complete. We need to use common sense after all. > >I'd like to note that your `no code regeneration' principle has not >been agreed upon by the committee. [Shabtay] I'm sorry. We are committed to providing EDA tools and solutions that are acceptable to our customers based on feedback that we have received from customers over the years. I conveyed and explained the reasons for the principles we adopted as a result of such feedback and hope the committee will agree to these. If they will agree or not is not in my control... > >> Now, it is my understanding that you also support Russ idea to focus >> on SystemVerilog for SCE-MI 2.0 and deal with Verilog and VHDL for >> SCE-MI 2.1. > >No, I do not agree with this as stated. I do agree that we should >probably focus on SystemVerilog for a while, but I do not agree that >we should drop `old' Verilog and VHDL from 2.0. [Shabtay] I addressed this above. > >> Should we then stop discussing this at this point and focus on >> SystemVerilog for SCE-MI 2.0? > >No :-) I'd like to see your macro proposal so I can evaluate your >claim that it fulfills your principles by myself, for instance. [Shabtay] While we will need to provide some incremental update to the macro proposal that we proposed in the past, you already have seen most of it on Accellera web. You are more than welcomed to assess what was posted. I have yet to hear from others, but if Russ latest proposal is agreed to (we stated we support it), there is no use in bringing any new or updated Verilog and VHDL proposals to the table at this time. All should remove Verilog and VHDL related content besides the interoperability models with SCE-MI 1.1. > >Per >Received on Tue Oct 25 18:01:05 2005
This archive was generated by hypermail 2.1.8 : Tue Oct 25 2005 - 18:01:16 PDT