Answers in line (I hope). Regards, Bryan ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Alsop, Thomas R Sent: Tuesday, December 18, 2007 1:06 PM To: Bullis, Bryan; Steven Sharp; sv-bc@eda-stds.org; Brad.Pierce@synopsys.com Subject: RE: [sv-bc] Mantis 1984 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? [BKB] We had to switch from var to wire. 2 states can't be of type wire. Right? The problem was that it wasn't until we wanted to drive the signal from the TB that we had multiple drivers. Until that point we only had one source and so the signal could be either wire or var. 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?[BKB] yes var to wire. 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? [BKB] Module stubbing is a where we would use an IFDEF to remove all the code of a module except for the port declarations. In the then clause we had an initial block where we sourced all outputs to an "off" state. The inputs dangled. The else side was the functional code. Kind of like using two architectures in VHDL with one named STUB and the other RTL. We compiled the design into two different libraries and used configurations to select which implementation we desired. The "Island" TB is sometimes known as Unit or Block. It is basically a TB for the design that we want to focus on. We would STUB out all the blocks we did not want for that TB. 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. [BKB] Explained above. The purpose for the initial blocks was to ensure there were no X's on any nets. This way interconnections to the block which were not a focus of the TB did not cause any issues. 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? [BKB] It doesn't. we had some items as 2 state which had to be moved to logic. > >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. [BKB] We used interfaces and modports as well. I was just commenting 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? [BKB] That is. Speed is important at times. 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. [BKB] Can't speak to Analog needs. Our system was pure digital. Though I have heard of the desire to have Reals support X propagation. > >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 <http://www.mailscanner.info/> , 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 11:28:01 2007
This archive was generated by hypermail 2.1.8 : Tue Dec 18 2007 - 11:28:33 PST