Mike, See http://www.eda.org/sv-bc/hm/3348.html , or its Mantis item 905. Unless the interface has no parameters and no interface-type ports, there's no way to accurately predict what type of interface instance will be connected to that module port. For example, there's no way to know for sure how big a bus will be. An interface-type in a port declaration is usually generic (unless that kind of interface has no parameters). Unlike with a struct or class type, you cannot fully specify in the port declaration the type of interface instance that will be connected. And a problem with enhancing port declarations to support this is that the type of an interface instantiation depends not just on its obvious parameters, but also on the implicit parameters of its own interface ports, and so on. So an interface-type port is similar to a type parameter without a default type, as in Mantis 907. -- Brad -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Michael Burns Sent: Wednesday, April 15, 2009 10:15 AM To: sv-ec@eda.org Subject: [sv-ec] Question about interface ports on modules Hi folks, There is a restriction in 23.3.3.4 (that has been around since Accellera SV) that any interface ports of a module must be connected to an interface instance at a higher level of hierarchy. This would seem to preclude creating an RTL design with interface ports at the top level. What is the reason for this restriction? Am I misunderstanding the meaning here? More specifically, for simulation one would normally have a testbench that instantiates the DUT and connects the interface ports - no problem there. However, many other tools (synthesis, formal, back-end, etc.) read in just the DUT. Would those tools be required to reject a design with top-level interface ports? Thanks, Mike -- 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 15 11:18:14 2009
This archive was generated by hypermail 2.1.8 : Wed Apr 15 2009 - 11:19:03 PDT