Skip Nav
Home » Forums » SystemC Forum

Icon - KMLM List KMLM List

View email archives for the history of this mailing list.

List Home All Archives Dates Threads Authors Subjects
systemc-forum - RE: [systemc-forum] TLM2.0 timing diagram w/ for multiple burst transac Message Thread: Previous | Next
  • To: "Bernard Deadman" <bdeadman@xxxxxxxxxx>
  • From: "Bradley, Mike" <mike_bradley@xxxxxxxxxx>
  • Date: Thu, 21 Oct 2010 14:34:12 -0600
  • Cc: <systemc-forum@xxxxxxxxxxxxxxxxx>
Send Email to systemc-forum@lists.systemc.org:
Send new message
Reply to this message
Hi,

I found an interesting read, the "STARC TLM GUIDE" (registration
required).  They define a two dimensional array of abstraction levels.
It is timing accuracy vs. communication data granularity (bus
granularity).

Given this definition you can have AT timing with any bus granularity.
It then maps the OSCI and OCP definitions into their super-set
definition.  

They then define 5 abstraction levels of interest:

Name   Timing              - Data Granularity
============================================
UTTR   Untimed-transaction - transaction 
ATTR   Approximately timed - transaction
ATBP   Approximately timed - Bus Phase
CABC   Cycle accurate      - Bus Cycle
CABS   Cycle accurate      - Bus Signal  (This is RTL)


It seems that both the AT timing abstractions can take into account the
timing of bus bursting, but only in CA timing are the bursts actually
implemented.

So, I'm still not clear, for example if you are using ATBP mode, and you
initiate a transaction to transfer 100 Mbytes of data, can the bus
arbitrator interleave other masters in the middle?  Seems like a major
problem if you can't.  I suppose the master could break the transfer
into smaller transfers, but isn't part of the point of TLM is to
separate computation from communication?

-Mike



-----Original Message-----
From: Bernard Deadman [mailto:bdeadman@xxxxxxxxxx] ;
Sent: Thursday, October 21, 2010 12:53 PM
To: Bradley, Mike
Cc: systemc-forum@xxxxxxxxxxxxxxxxx
Subject: Re: [systemc-forum] TLM2.0 timing diagram w/ for multiple burst
transaction


Hi Mike,

One point to make is that "transaction based verification" which we've 
all been working with for years is just another form of mixed 
abstraction modeling.  The broader ability to mix RTL components into 
system-level models is starting to happen for a number of reasons:

i) if you built the TLM model of the system first, it can form part of 
your verification strategy - simply replace one of the TLM blocks with 
the RTL to get a good confidence that it's going to work, though in many

cases the RTL code coverage you achieve with the TLM won't be good 
enough to sign off for manufacture.

ii) in some cases you may be using purchased IP or legacy IP that isn't 
available in a TLM form.  Using mixed abstraction modeling (ie mixing 
TLM & RTL) allows you to do early / parallel software development 
without having towait for / write a full set of TLM models

iii) mixed-abstraction modeling can be part of a successive refinement 
development flow - start with the system-level model and plug in more 
and more RTL blocks as you complete them, until you have a major block 
or device available in RTL.  At that point you can switch the RTL to an 
emulator and run the rest of the system in TLM against 'real' hardware 
in the emulator


As far as your block of data example is concerned, my take on it is the 
information you get from this level detail isn't worth the effort UNLESS

the bus logic / arbitration etc. and indeed most of the system are truly

cycle accurate - basically if you can't get all the transactions to 
arrive at exactly the right relative time, you're not going to get the 
right answer anyway, so a fuzzy approach like "allow a random number of 
cycles between 15 and 40 for the block transfer" is far cheaper to write

and run and allows you to validate other parts of the system.

Regards,

Bernard



Bradley, Mike wrote:
> Hi,
>
>   
>> Why not model the time for the whole burst without considering the
>>     
> individual transfers?
>
> One reason I can think of is it then assume the arbiter would not
break
> up a series of bursts from one master.  I believe it is quite common
for
> s/w to say "write a block of data" but that the block of data on the
bus
> is interleaved with other transactions from other masters.
>
> So, you would need some type of cycle-approximate model of the bus to
do
> this.  How this is best done, I'm not sure. I guess you could insert
RTL
> models, but now you have a mixed simulation, and a break in the TLM
> transaction.  Not sure of the ramifications of this, but it seems
there
> is some advantage to having the TLM transaction go all the way to the
> target, and get a return directly from the target.  
>
> I can see advantages for mixing systemC TLM models with RTL for
> verification, just not on board for arch. Exploration.
>
> -Mike
>
> -----Original Message-----
> From: Bernard Deadman [mailto:bdeadman@xxxxxxxxxx] ;
> Sent: Thursday, October 21, 2010 11:18 AM
> To: Bradley, Mike
> Cc: systemc-forum@xxxxxxxxxxxxxxxxx
> Subject: Re: [systemc-forum] TLM2.0 timing diagram w/ for multiple
burst
> transaction
>
>
> Mike,
>
> Yes, it can do it, but you have to consider the cost & value.  As I
was 
> trying to point out, TLM is about reading / writing defined sized
blocks
>
> of bytes.  If you model at more precision it costs time ie
performance, 
> but what value does it bring?  If you're hoping to look at issues like

> bus congestion you have to go to a cycle accurate model because you
have
>
> to model the arbitration between multiple devices on the bus, at which

> point you're almost at RTL anyway, except that you've spent time &
money
>
> on a second set of models.  If you don't go down to this precision,
why 
> waste time modeling the transfer phases?  Why not model the time for
the
>
> whole burst without considering the individual transfers?
>
> Regards
>
> Bernard
>
>
> Bradley, Mike wrote:
>   
>> Hi,
>>
>> I don't think you can have very good "AT" performance without taking
>> burst transfers into account.  Indeed most CPU data transfers and
>> instruction read will be cache line accesses, which are bursts.
>>
>> Would not TLM 2.0 be able to timing-model this?  If not, and you have
>>     
> to
>   
>> go down to RTL and back, seems like a kludge. 
>>
>> -Mike
>>
>> -----Original Message-----
>> From: Bernard Deadman [mailto:bdeadman@xxxxxxxxxx] ;
>> Sent: Thursday, October 21, 2010 10:45 AM
>> To: A, Nizamudheen
>> Cc: Bradley, Mike; systemc-forum@xxxxxxxxxxxxxxxxx
>> Subject: Re: [systemc-forum] TLM2.0 timing diagram w/ for multiple
>>     
> burst
>   
>> transaction
>>
>>
>> Hi Nizam,
>>
>> TLM basically models memory reads / writes and most of the TLM models

>> achieve a compromise between performance and accuracy without 
>> considering how block transfers are broken down into word reads &
>>     
> writes
>   
>> on a bus, so there's no standardization for this level of precision.
>>     
> As 
>   
>> an example we deliver transactors that interface / convert TLM to RTL

>> buses like AXI & OCP that support burst mode transfers. The
>>     
> transactors 
>   
>> are fully protocol compliant at the cycle-level but the TLM still 
>> operates with a byte array & length payload.
>>
>> The disadvantage of modeling the individual transfers in TLM is, of 
>> course, performance. Taken to extremes the TLM models are going to 
>> replication what the RTL does to get the accuracy at the word
transfer
>>     
>
>   
>> level (almost cycle-accurate in most cases) but then you lose the 
>> performance advantage from using TLM so why not stick with the RTL
and
>>     
>
>   
>> avoid the cost of creating the second set of models?
>>
>> Perhaps we can help you better if you can explain your goals in
>>     
> modeling
>   
>> at this level of precision in a TLM environment?
>>
>> Regards
>>
>> Bernard
>>
>>
>>
>> A, Nizamudheen wrote:
>>   
>>     
>>> Hi Mike,
>>>
>>> Thanks for your response.
>>>
>>> I was trying to create an extension to the base-protocol and I 
>>> couldn't find any example or statement in LRM regarding multi-burst 
>>> transaction.
>>>
>>> Regards,
>>>
>>> Nizam
>>>
>>>
>>>     
>>>       
>
------------------------------------------------------------------------
>   
>>   
>>     
>>> *From:* systemc-forum@xxxxxxxxxxxxxxxxx 
>>> [mailto:systemc-forum@xxxxxxxxxxxxxxxxx] *On Behalf Of *Bradley,
Mike
>>> *Sent:* Thursday, October 21, 2010 7:26 PM
>>> *To:* systemc-forum@xxxxxxxxxxxxxxxxx
>>> *Subject:* RE: [systemc-forum] TLM2.0 timing diagram w/ for multiple

>>> burst transaction
>>>
>>> Hi Nizam,
>>>
>>> I Looked around but could not find one. Best I could find is in the 
>>> TLM2.0 LRM. There are commercial tools that implement TLM2.0 burst 
>>> transactions for you (only one I know of is Vista from Mentor, but
>>>       
> I'm
>   
>>>     
>>>       
>>   
>>     
>>> sure there are others). Have you looked at commercial solutions, or 
>>> just wanting to create your own?
>>>
>>> -Mike
>>>
>>> *From:* systemc-forum@xxxxxxxxxxxxxxxxx 
>>> [mailto:systemc-forum@xxxxxxxxxxxxxxxxx] *On Behalf Of *A,
>>>       
> Nizamudheen
>   
>>> *Sent:* Tuesday, October 19, 2010 7:06 AM
>>> *To:* systemc-forum@xxxxxxxxxxxxxxxxx
>>> *Subject:* [systemc-forum] TLM2.0 timing diagram w/ for multiple
>>>       
> burst
>   
>>>     
>>>       
>>   
>>     
>>> transaction
>>>
>>> Hi,
>>>
>>> Can some-one point me to a TLM2.0 transaction diagram for a 
>>> multi-burst read/write transaction?
>>>
>>> Regards,
>>>
>>> Nizam
>>>
>>>     
>>>       
>>   
>>     
>
>
>   


By Date: Previous | Next Current Thread By Thread: Previous | Next