Subject: RE: Handling of "implicit" declarations
From: David Smith (david_smith@avanticorp.com)
Date: Mon Sep 24 2001 - 12:45:39 PDT
Since most place and route systems are based on cell connectivity they would then have to read the interface specification that is used, determine what the physical port connections are to find out how to route wires.
This seems problematic. Are you really proposing that interfaces be used when we get to the cell level and the connection to the interface is determined either on the instance (example 1 - in which case the problem I allude to seems to still exist), using modports, or with the simple interface connection. The last two have the problem that the physical connections are not represented in the interface.
It seems that this is a problem that can be resolved during decomposition and instantiation. It would also mean that the mapping from interface to wires is done in the block where the cells are instantiated or at least in a close parent.
I will have to think some more on this. It seems similar to the bus and bus ripping problem or "bundle" in Cadence (and others).
Thanks for the thoughts.
David
-----Original Message-----
From: Stefen Boyd [mailto:stefen@boyd.com]
Sent: Monday, September 24, 2001 12:04 PM
To: David Smith
Cc: 'vlog-pp@eda.org'
Subject: RE: Handling of "implicit" declarations
At 11:23 AM 9/24/2001 -0700, David Smith wrote:
>How does this work for a netlist description of a cell based design that has to be used to drive place and route?
>
>Are you saying that all cells have to be re-written to use interfaces?
David,
No, you don't have to rewrite cells to use interfaces.
My option 2 was directed at this problem. For example,
let's talk to an ethernet phy:
module eth_phy (input clk, data, output tx_ok);
...
endmodule
if we want to connect to this module, we have several
options. Let's assume that the interface contains
the three wires we need.
1) instantiate using the wires of the interface:
eth_phy eth_phy(ethint.clk, ethint.data, ethint.tx_ok);
2) instantiate with modport
eth_phy eth_phy(ethint.tx_modport);
3) instantiate without modport (all wires in interface are
hooked up... so you'll only be allowed to have the
three used by the transmitting phy).
eth_phy eth_phy(ethint);
At 11:24 AM 9/24/2001 -0700, David Smith wrote:
>Also, how do you do partial change of an interface? I have one branch I want to modify to be implemented at the cell level and the rest at the system level. I have to change the definition of just those interfaces do I not? Is this not similar to having to change declarations? Help me understand since it is not clear.
Keep in mind that an interface is only declared
at one place and it is passed everywhere else
as an "interface" declaration. Huh??? Let me
show an example:
module top;
env_ctl env_ctl;
exp_fifo lan2wan_data1;
eth2pl3 eth_intf1;
eth_gen eth1(eth_intf1, lan2wan_data1, env_ctl);
...
endmodule
I have an eth_gen module with three interfaces connected.
If I look at the eth_gen module header:
module eth_gen(interface send2dut,
interface checker_pkts,
interface env_ctl);
...
endmodule
Notice that send2dut is simply of type "interface." If
I have five of them and wanted one of those five to
use a physical implementation on one side, I can do
it two different ways:
1) create a new interface that has the physical
implementation and connect that to the one
instance that needs a low level interface.
For example:
eth2pl3_low_level eth_intf_LL;
eth_gen eth1(eth_intf_LL, lan2wan_data1, env_ctl);
2) create a 'split-personality' interface. It would
have tasks and functions to call for high level
interfaces, but would also include the wires
needed for the low level implementation.
Either way, you can work with mixed levels of
representation in the design.
Stefen
--------------------
Stefen Boyd Boyd Technology, Inc.
stefen@BoydTechInc.com (408)739-BOYD
www.BoydTechInc.com (408)739-1402 (fax)
This archive was generated by hypermail 2b28 : Mon Sep 24 2001 - 12:52:10 PDT