KMLM List

["Refice, Justin A" <Justin.Refice@xxxxxxxxxx>]

The transport interface was considered, but we're not using
bidirectional communication either...

Basically, a read is bidirectional, a write is unidirectional, and we'd
like to have similar (if not identical) syntax between the two.

If instead of being setup like:

RSP transport( const REQ & );

The Transport interface has a :

Void transport (const REQ & , RSP&);

Then we'd be in business.  (Speaking of which, why wasn't a void version
of transport implemented?  Get has both versions... why not do it for
transport?)



-Justin

-----Original Message-----
From: Rose, Adam [mailto:Adam_Rose@xxxxxxxxxx] 
Sent: Wednesday, May 04, 2005 11:37 AM
To: Refice, Justin A; systemc-forum@xxxxxxxxxxx
Subject: RE: [Systemc-forum] Memory based accesses & TLM


Justin,

Get and put were certainly not intended to be used in this way.

Why not use tlm_transport_if ? What you have here is bidirectional
communication, so why not use the bidirectional transport interface ?

Adam.

> -----Original Message-----
> From: systemc-forum-admin@xxxxxxxxxxx 
> [mailto:systemc-forum-admin@xxxxxxxxxxx] On Behalf Of Refice, Justin A
> Sent: 04 May 2005 15:40
> To: systemc-forum@xxxxxxxxxxx
> Subject: [Systemc-forum] Memory based accesses & TLM
> 
> I'm trying to create a shared component which will exist 
> between two separate SystemC Models, written by two separate 
> SystemC Modelers.  This component is *basically* a RAM.
> 
> Now, we're also trying to use the TLM libraries as much as 
> possible, however in this case it seems to be a little 
> difficult.  If we look at the RAM like standard memory, you 
> would have 4 ports:
> 
> Read:
> Tlm_blocking_put<address>
> Tlm_blocking_get<data>
> 
> Write:
> Tlm_blocking_put<address>
> Tlm_blocking_put<data>
> 
> This seems like a rather excessive amount of puts and gets 
> considering all I want to do read and write from a memory 
> structure.  I was considering changing the setup so that the 
> address would be contained within the data itself, so instead 
> of 4, you'd have 2:
> 
> Read:
> Tlm_blocking_get<data w/ addr>
> 
> Write:
> Tlm_blocking_put<data w/ addr>
> 
> For the write, this is not a problem at all... but for the 
> read, this involves some interesting usage c++ references.  Basically:
> 
> Void Get( T &t ) would require that t have an address pre-loaded.
> t get(tlm_tag<T>) wouldn't work. (I could just have it send out an
> SC_ERROR)
> 
> I was wondering if anyone else has encountered this problem, 
> and thought of another tlm-centric way of solving it.  (W/o 
> TLM, this just becomes
> academic)
> 
> 
> 
> _______________________________________________
> Systemc-forum mailing list
> Systemc-forum@xxxxxxxxxxx
> https://www.systemc.org/mailman/listinfo/systemc-forum
>