SPLIT AHB DOUBT

[terabits]

Hi

What should be the incr address after a split in between a wrap
transaction.
for example

in a wrap 8. i byte length starting adress is 2

2 3 4 5 6 7 0 1 is the actual address sequence right..
if split occured at 6, rest 3 i can do as 3 singles or incr, but incr
is suggested
so when i say incr my address is 7 8 9 but not 7 0 1 according to
INCR.
is this right ??? or i need to save 7 0 1 addresses and send 1 by
one....
please help

regards.

 

[Joseph]

terabits wrote:

Hi

What should be the incr address after a split in between a wrap
transaction.
for example

in a wrap 8. i byte length starting adress is 2

2 3 4 5 6 7 0 1 is the actual address sequence right..
if split occured at 6, rest 3 i can do as 3 singles or incr, but incr
is suggested
so when i say incr my address is 7 8 9 but not 7 0 1 according to
INCR.
is this right ??? or i need to save 7 0 1 addresses and send 1 by
one....
please help

regards.

You can use :
Address 7 INCR Non-seq
Address 0 INCR Non-seq
Address 1 INCR Seq

Joe

 

[terabits]

Hi

That sounds perfect but..
when i say incr i dont have control on the address
if i say starting address is 7 and is single byte address will be
incremented 7 8 9 sequence....right ???

You can use :
Address 7 INCR Non-seq
Address 0 INCR Non-seq
Address 1 INCR Seq

Joe- Hide quoted text -

- Show quoted text -

 

[Joseph]

terabits wrote:

Hi

That sounds perfect but..
when i say incr i dont have control on the address
if i say starting address is 7 and is single byte address will be
incremented 7 8 9 sequence....right ???



You can use :
Address 7 INCR Non-seq
Address 0 INCR Non-seq
Address 1 INCR Seq

Joe- Hide quoted text -

- Show quoted text -

Hi there,

Are you designing an AHB bus master?
If you are designing AHB slave, then it should handle
the transfer as indicated by HADDR & HTRANS (HTRANS should
indicate if it is a sequential access from the last one).

If you are designing an AHB master, why you don't have
control on the address?

Joe

 

[terabits]

Hi Joe

I am designing an ahb master.
well here is the scenario.
no where in the spec says what is the address when split resumes.
they say you can complete the rest of the transaction with either
single/or any valid bursts/incr burst. and they suggest undefined
lenght incr.
In the spec they say when an undefined length transfer occurs it
increments the previous address by the size (pls not it never does the
wraps)
my question here is if a wrap burst breaks at the border, when it
resumes if we give incr (as suggested by them) it will increment
address (here i mean no control of address)
but it will not do the wraps. so i am asking is that okay ??
or we need to consider wraps if wraps calculate the address before
hand and give all seqs.
and if it is incr4 or something burst it can be followed by a simple
incr undefined ?
moreover for all the transfer we calculate the address on the fly we
dont calculate and keep them aside...

which is not clear about wraps in the spec

rgds

 

[Joseph]

terabits wrote:

Hi Joe

I am designing an ahb master.
well here is the scenario.
no where in the spec says what is the address when split resumes.
they say you can complete the rest of the transaction with either
single/or any valid bursts/incr burst. and they suggest undefined
lenght incr.
In the spec they say when an undefined length transfer occurs it
increments the previous address by the size (pls not it never does the
wraps)
my question here is if a wrap burst breaks at the border, when it
resumes if we give incr (as suggested by them) it will increment
address (here i mean no control of address)
but it will not do the wraps. so i am asking is that okay ??
or we need to consider wraps if wraps calculate the address before
hand and give all seqs.
and if it is incr4 or something burst it can be followed by a simple
incr undefined ?
moreover for all the transfer we calculate the address on the fly we
dont calculate and keep them aside...

which is not clear about wraps in the spec

rgds

Hi there,

For INCR burst, if HTRANS equal 0x2 (Non-sequential), the address
does not need to be the increment of previous address. Only when
HTRANS equal 0x3, then your address must be increment of previous
one. For example, it is perfectly okay to have transfer
sequence of
Address HTRANS HSIZE HBURST
0x004 NON-SEQ Word INCR
0x008 SEQ Word INCR
0x00C SEQ Word INCR
0x000 NON-SEQ Word INCR <= Address is not increment of
previous one, but HTRANS is 0x2
so it is not illegal.

So you can resume a wrap transfer after a split by issuing
Address HTRANS HSIZE HBURST
0x010 NON-SEQ Word WRAP8
0x014 SEQ Word WRAP8
0x018 SEQ Word WRAP8 <= Split response here
.... ; wait for AHB slave
0x018 NON-SEQ Word INCR ; resuming last wrap transfer
0x01C SEQ Word INCR
0x000 NON-SEQ Word INCR ; Address is not increment of last
; address, indicated by HTRANS=0x2
0x004 SEQ Word INCR
0x008 SEQ Word INCR

When designing the master, at the beginning of the burst
you need to store :
- starting address of burst
- type of burst (HBURST as well as HSIZE)
- Current count of the burst transfer, this increment as the burst
proceed.
When the burst resumed after the split, from the stored information
you can still work out the correct address value and wrap boundary.
Hence generate the required INCR transfer.

regards,

Joe

 

[terabits]

that is hlepful thankq i still have doubts..you mean to say,
technically you are splitting the rest of the transfer to two INCR
transfers
as slave has no other mechanism to detect the end of the transfer of
an undefined length burst unless it encounters the next non sequence
transfer.
so in this case 0x18,0x1c are treated as 1 incr burst transfer and.
0x00..0x08 is considered as another INCR transfer by slave. right ??

So you can resume a wrap transfer after a split by issuing
Address HTRANS HSIZE HBURST
0x010 NON-SEQ Word WRAP8
0x014 SEQ Word WRAP8
0x018 SEQ Word WRAP8 <= Split response here
... ; wait for AHB slave
0x018 NON-SEQ Word INCR ; resuming last wrap transfer
0x01C SEQ Word INCR
0x000 NON-SEQ Word INCR ; Address is not increment of last
; address, indicated by HTRANS=0x2
0x004 SEQ Word INCR
0x008 SEQ Word INCR

When designing the master, at the beginning of the burst
you need to store :
- starting address of burst
- type of burst (HBURST as well as HSIZE)
- Current count of the burst transfer, this increment as the burst
proceed.
When the burst resumed after the split, from the stored information
you can still work out the correct address value and wrap boundary.
Hence generate the required INCR transfer.

 

[Joseph]

terabits wrote:

that is hlepful thankq i still have doubts..you mean to say,
technically you are splitting the rest of the transfer to two INCR
transfers

Yes, the remaining transfers are carried out by two INCR bursts.

as slave has no other mechanism to detect the end of the transfer of
an undefined length burst unless it encounters the next non sequence
transfer.

Yes, for the AHB slaves, it must detect the status of HTRANS to
determine when the burst terminate.

so in this case 0x18,0x1c are treated as 1 incr burst transfer and.
0x00..0x08 is considered as another INCR transfer by slave. right ??

Correct.

regards,
Joseph

 

[terabits]

Hi joseph

thanq verymuch for the help, so that adds much complexity in master
when it has to accept the split for wrap bursts...
and one more quick question, is there any need for slave to know about
the burst information, like
when the transers are carried from master to slave with some
interemediate manipulation it can always get the transaction as
single ??

suppose i have an incr4 transfer ,intermediate logic passes that to
slave as 4 singles ? slave need not bother whether it is burst or
single or whatever right ? just take the address and give it..will
that do ??

rgds

Yes, for the AHB slaves, it must detect the status of HTRANS to
determine when the burst terminate.

so in this case 0x18,0x1c are treated as 1 incr burst transfer and.
0x00..0x08 is considered as another INCR transfer by slave. right ??

 

[terabits]

and one more question here.

suppose i initiated a single transaction on slave, it gave split
response, so i need to transer again ideally
is it ture can slave splits singles also ??
>

 

[Joseph]

terabits wrote:

and one more question here.

suppose i initiated a single transaction on slave, it gave split
response, so i need to transer again ideally
is it ture can slave splits singles also ??

For previous question:
Slave can always handle transfers as single.
A really simple AHB slave only need to check
- HTRANS[1]
- HREADY
- HSEL
to determine if the transfer is valid. Then it take
the HADDR, HSISE, HWRITE, etc, to carry out the transfer.
Having burst information allow an AHB slave to
be optimised so that system performance could be
improved. This is optional, so not all AHB slave
have HBURST input.

For the new question:
Strictly speaking yes, but in most cases you won't
design a peripheral in this way. It is better off
to have a status register in your peripheral to
indicate if it is ready for a data transfer.
One of the biggest problem is that when you have
a debugger connected to your system, and you
open a memory view of your peripheral, the debugger
might have problem dealing with the split behaviour.
If the AHB slave only generate split in burst transfer,
then a debugger access (usually single transfer)
will not have any problem.

Nowaday with multi-layer AHB solutions we tend to avoid
split / retry responses. You can find more info on this in
http://www.arm.com/pdfs/DVI0045B_multilayer_ahb_overview.pdf

regards,

Joseph

 

[terabits]

Hi Joseph

thanku verymuch for the detailed reply,
right now all the slaves in the chip are treating every transaction as
single, and they hence they give split whenever they like.....
it could be a split to single also..anyways i cannot change all of
'em, will have to be careful for debugger kinda masters.
thanks anyways it was very helpful

regards

For previous question:
Slave can always handle transfers as single.
A really simple AHB slave only need to check
- HTRANS[1]
- HREADY
- HSEL
to determine if the transfer is valid. Then it take
the HADDR, HSISE, HWRITE, etc, to carry out the transfer.
Having burst information allow an AHB slave to
be optimised so that system performance could be
improved. This is optional, so not all AHB slave
have HBURST input.

For the new question:
Strictly speaking yes, but in most cases you won't
design a peripheral in this way. It is better off
to have a status register in your peripheral to
indicate if it is ready for a data transfer.
One of the biggest problem is that when you have
a debugger connected to your system, and you
open a memory view of your peripheral, the debugger
might have problem dealing with the split behaviour.
If the AHB slave only generate split in burst transfer,
then a debugger access (usually single transfer)
will not have any problem.

Nowaday with multi-layer AHB solutions we tend to avoid
split / retry responses. You can find more info on this inhttp://www.arm.com/pdfs/DVI0045B_multilayer_ahb_overview.pdf

regards,

Joseph