Per,
All good points. Comments embedded.
Bojsen, Per wrote:
> Hi John,
>
> > We have to be careful not to fall in the
> > trap of significant complication to the infrastructure
> > to deal with some of this stuff for little gain realized
> > and for only addressing the tip of an iceberg of deadlock
> > opportunities.
>
> Agreed. I raised the issue primarily to find out if there
> it is mandated that the application bind all ports or not.
> From what you say, it sounds like there is no such mandate
> and that it is up to the application to deal with the consequences
> of leaving ports unbound.
johnS:
Yes.
>
> > In this particular situation that you describe, I have found
> > it useful in the past to not bind to transactors whose interfaces
> > that are disabled from a given simulation. Different testbenches
> > can be configured to stimulate different interfaces while
> > other interfaces remain idle.
>
> I agree that this is an important use model if for no other
> reason than that emulation compilation is very expensive.
> The user will want to be able to use the same hardware configuration
> with as many tests as possible so it is important to be able to
> leave transactors idle. However, leaving transactors idle at
> the application level does not necessarily translate to leaving
> ports unbound. For instance, Zaiq has defined an application
> level idle mechanism for its SCE-MI transactors. We still bind
> to all SCE-MI ports. The application will tell unused transactors
> to idle indefinetely.
johnS:
Let's allow for either approach.
>
> > In such a scenario it might be typical for a transactor to
> > monitor in input port to wait for an activation transaction
> > but not stop the clock.
>
> So when you are not using the transactor you leave the port
> unbound and it will wait forever without stopping the clock . . .
johnS:
Yes.
>
> > In fact, stoppage of clocks while
> > blocking for the first input is more atypical than typical.
>
> Interesting. I assume you have at least one transactor that
> will stop the clock at the beginning of emulation, though,
> otherwise how can you guarantee repeatable cycle stamp
> values?
johnS:
Perhaps one could have a global "reset transactor" that does this.
But all interface transactors would not need to stop the clock.
>
> > It logically follows then that for output ports, we should
> > never have a clock stoppage either because disabled transactors
> > should never send output.
>
> But in order to be able to disable the transactor it must have
> an input port, right? This is an important guideline for hte
> transactor coding guidelines document as you point out.
johnS:
Good point.
Alternatively, the infrastructure could send outputs from
"output only" transactors to the bit bucket if their ports
are never bound.
In otherwords, the C side, by not binding an output port, is
declaring "I shall ignore all output from this transactor".
Infrastructure can optimize accordingly.
>
> > And I think non-bound ports can be quite a useful feature
> > when used correctly.
>
> So essentially you confirmed that there is no requirement that
> all ports be bound and you also confirmed that idling of
> transactors must be handled at the application level. I am
> fine with that.
>
> We can probably close this issue real quick unless somebody
> else objects :-)
johnS:
Great !
>
> Per
>
-- johnS
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient. Any review, reliance or distribution by others or
forwarding without express permission /\
is strictly prohibited. If you are /\ | \
not the intended recipient please | \ / |
contact the sender and delete / \ \
all copies. /\_/ K2 \_ \_
______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
Received on Wed Mar 17 12:21:25 2004
This archive was generated by hypermail 2.1.8 : Wed Mar 17 2004 - 12:21:26 PST