Hi Bryan, I've just got a few questions about your comments (below). Thanks, -Tom >-----Original Message----- >From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On >Behalf Of Bullis, Bryan >Sent: Tuesday, December 18, 2007 4:05 AM >To: Steven Sharp; sv-bc@server.eda-stds.org; Brad.Pierce@synopsys.com >Subject: RE: [sv-bc] Mantis 1984 > >When design teams move more fully in to SV and also couple an SV >Testbench, you should. I've (general user) had this issue come up >already. [Alsop, Thomas R] Can you elaborate what the issue was? What you describe here seems like a connection and driver issue. How does modeling nets as 2 state fix the problem you had? We worked around it by changing the declaration in the RTL to >accommodate the restriction. [Alsop, Thomas R] Do you mean converting to net type? The issues arose for us when we had one >command ASIC testbench and utilized Module Stubbing to get our Island >Testbenches. [Alsop, Thomas R] What is "Module Stubbing" and "Island" TB's? This necessitated the TB to drive some signals the are >also driven (via initial statements) in our RTL. [Alsop, Thomas R] You lost me here. Why would you have intial statements driving RTL signals "in the RTL"? Unless these are ROM's this is considered part of the TB. As a result we had to >ensure all Ports were of type wire and not var and thus not 2-state. [Alsop, Thomas R] How does moving to 2-state remove the effort you had to make? Or is there another benefit that you lost in this transition that I missed? > >My 2cents [Alsop, Thomas R] I too have been working on connecting SV code to SVTB and generally did not have any issue hooking the two together. I used SV interfaces and modports so I don't know if this inherently resolves the issue that you may have face with V95 ports or some other port style. I read through this issue and (correct me if I am wrong) thought in only addressed modeling net types as 2 state (0 & 1 and not Z or X). The improvements you get from this are no X propagation and faster simulation speeds. What else am I missing? I did chat with our Analog simulation expert and he tells me that this is not a big need (if I understand the benefits). Most of the simulation time spent in Analog modeling is consumed in the Analog engine and the amount of analog wire's is relatively small so he doesn't see a big benefit from simulation performance. X propagation is also not an issue since the control logic it hooks up to is digital and already set to 2 state mode. > >Regards, >Bryan > >-----Original Message----- >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of >Steven Sharp >Sent: Monday, December 17, 2007 9:53 PM >To: sv-bc@eda-stds.org; Brad.Pierce@synopsys.com >Subject: RE: [sv-bc] Mantis 1984 > > >>From: "Brad Pierce" <Brad.Pierce@synopsys.com> > >>Then we should finally address ballot issue 228 >> >> http://www.eda-stds.org/svdb/view.php?id=694 >> >>Back in 2005 I voted against deferring this issue. > >I think it would be good to address this. However, I have not been >hearing any demand for 2-state nets from users. > >I have been hearing requests for real nets, for use in simple analog >modelling. However, these requests seem to include a desire for >multiple drivers and a variety of driver resolution algorithms. > >Steven Sharp >sharp@cadence.com > > >-- >This message has been scanned for viruses and dangerous content by >MailScanner, and is believed to be clean. > > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Dec 18 10:20:53 2007
This archive was generated by hypermail 2.1.8 : Tue Dec 18 2007 - 10:21:24 PST