Re: Q: Analysis port binding

From: David C Black <dcblack@xtreme-eda.com>
Date: Mon Oct 25 2010 - 16:14:01 PDT

Since they inherit from sc_object in current implementation, I don't think they can be created after end of elaboration occurs. Am I mistaken?

------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader
http://www.Xtreme-EDA.com
(Consulting, Services & Training for all your ESL, verification and DFT needs)
Voice: 512.850.4322 Skype: dcblack FAX: 888.467.4609

On Oct 25, 2010, at 2:45 PM, Philipp A. Hartmann wrote:

> David, all,
>
> if I understand the analysis ports correctly, it's intended to use
> bind()/unbind() dynamically during simulation. The mere existence of
> unbind() already suggests that, right?
>
> Moreover, since they are not derived from
> sc_port<tlm_analysis_if<T>,...>, I think they can also be
> created/destroyed while the simulation is running.
>
> I agree, that both features should probably be documented in the
> standard, since the name ..._port might imply the opposite.
>
> Did we agree to make tlm_analysis_port<T>::bind() virtual during the
> bind/operator() discussion? In that case, I would propose to make
> unbind() virtual as well.
>
> Thanks,
> Philipp
>
> On 23/10/10 16:53, David C Black wrote:
>> Is it legal to bind()/unbind() analysis ports during simulation? It seems to me this would be a useful thing, but it is not specifically discussed in the standard.
>>
>> Use case:
>> Turn on analysis only during certain sections of simulation.
>> Turn off to reduce overhead
>>
>> The current TLM permits this behavior, but I don't find it documented anywhere.
>
>
>
> --
> Philipp A. Hartmann
> Hardware/Software Design Methodology Group
>
> OFFIS Institute for Information Technology
> R&D Division Transportation · FuE-Bereich Verkehr
> Escherweg 2 · 26121 Oldenburg · Germany
> Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Oct 25 16:14:38 2010

This archive was generated by hypermail 2.1.8 : Mon Oct 25 2010 - 16:14:41 PDT