-------- Original Message -------- Subject: Re: [sv-bc] Interesting LRM pli conflict Date: Tue, 3 Apr 2007 14:15:03 -0400 (EDT) From: Steven Sharp <sharp@cadence.com> Reply-To: Steven Sharp <sharp@cadence.com> To: sv-bc@server.eda-stds.org, sv-cc@server.eda-stds.org, gordonv@model.com I noticed this issue a while back, and we discussed it here. We concluded that the proper solution was > 2) layout memories in a "ref integer" compatible way > and disallow tfnodeinfo for memories in SV? Any of your other suggestions would affect the behavior of the SV language, changing what has been defined in the 1800 LRM. The PLI 1.0 interface was deprecated and is no longer part of the 1364 standard (and therefore is not part of the 1800 standard). The PLI 2.0 interface (AKA VPI) provides a clean way of accessing memories, so the tf_nodeinfo kludge is not needed for that any more. Yes, this could create some issues with legacy PLI. But we do need to be able to move forward at some point. When we have added a lot of new language constructs that are already not supported by legacy PLI, and that PLI interface has been removed from the language, it seems like a good point to do that. Another concern we have run into is performance of the VPI access to memories, compared to tf_nodeinfo. We have created some additional VPI access mechanisms to address those concerns. We would be happy to make those available for possible standardization. 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 Wed Apr 11 09:15:28 2007
This archive was generated by hypermail 2.1.8 : Wed Apr 11 2007 - 09:15:31 PDT