|
|
 | | From: | CalinD | | Subject: | AHB slave design question | | Date: | 18 Jan 2005 06:02:59 -0800 |
|
|
 | Hello
I am involved in a project that has an AHB slave interface, and I am
responsible for designing the interface plus writing the Verilog code
and testbench. First of all I must state that I am new to AMBA.
The project spec says that the slave AHB interface should support
"only" the NONSEQUENTIAL type of transfer. After studying the AHB spec
I have come to the conclusion that this means that the interface does
not support bursts (implicitly doesn't support SPLIT and RETRY
responses?) but only single transfers at random addresses. After
reading the AHB FAQ from the ARM website
(http://www.arm.com/support/faqip/580.html), I saw that two consecutive
NONSEQ transfers are not supported, but IDLE transfers must be inserted
between them. Does this mean that if only NONSEQ transactions are
performed, the pipelined nature of AHB is rendered useless, because of
IDLE transfers are inserted, and the master simply has to use two
cycles for transfers at random addresses? Am I correct or is there
something that I'm missing? Can someone help clarify?
Best Regards,
Calin
|
|
| | From: | Joseph | | Subject: | Re: AHB slave design question | | Date: | Tue, 18 Jan 2005 14:36:54 +0000 |
|
|
| CalinD wrote:
> Hello
>
> I am involved in a project that has an AHB slave interface, and I am
> responsible for designing the interface plus writing the Verilog code
> and testbench. First of all I must state that I am new to AMBA.
> The project spec says that the slave AHB interface should support
> "only" the NONSEQUENTIAL type of transfer. After studying the AHB spec
> I have come to the conclusion that this means that the interface does
> not support bursts (implicitly doesn't support SPLIT and RETRY
> responses?) but only single transfers at random addresses. After
> reading the AHB FAQ from the ARM website
> (http://www.arm.com/support/faqip/580.html), I saw that two consecutive
> NONSEQ transfers are not supported, but IDLE transfers must be inserted
> between them. Does this mean that if only NONSEQ transactions are
> performed, the pipelined nature of AHB is rendered useless, because of
> IDLE transfers are inserted, and the master simply has to use two
> cycles for transfers at random addresses? Am I correct or is there
> something that I'm missing? Can someone help clarify?
> Best Regards,
> Calin
>
Hi Calin,
You can have two (or more) sonsecutive Non-SEQ transfers (see the 4th
example on the page you mentioned). You don't need to have Idle cycle
between them.
Even for Non-SEQ transfers you can have split / retry response.
The question should be whether your slave need to generate these
response. Unless your slave device have high latency in R/W accesses,
usually you can just use the wait states if you need a few clock cycles
for the access.
AHB slave devices should support burst transfers. If a device can
support Non-SEQ transfers I can see why it couldn't cope with SEQ
transfers. You don't need to decode HBURST information, you can handle
SEQ transfer just like a Non-SEQ transfer.
regards,
Joseph
|
|
| | From: | CalinD | | Subject: | Re: AHB slave design question | | Date: | 18 Jan 2005 08:06:37 -0800 |
|
|
| Hello Joseph and thank you for your reply
> You can have two (or more) sonsecutive Non-SEQ transfers (see the 4th
> example on the page you mentioned). You don't need to have Idle
cycle
> between them.
How did I miss that? Sorry :(
> Even for Non-SEQ transfers you can have split / retry response.
> The question should be whether your slave need to generate these
> response. Unless your slave device have high latency in R/W
accesses,
> usually you can just use the wait states if you need a few clock
cycles
> for the access.
My conclusion that the slave does not support SPLIT/RETRY responses was
based on the fact that the HMASTER, HMASTCLOCK and HSPLIT ports do not
appear in the port list for the AHB interface of my project.
> AHB slave devices should support burst transfers. If a device can
> support Non-SEQ transfers I can see why it couldn't cope with SEQ
> transfers. You don't need to decode HBURST information, you can
handle
> SEQ transfer just like a Non-SEQ transfer.
Maybe the slave won't ever need to do anything but sparse transfers at
random locations, I can't see why a NONSEQ-only capable device isn't
possible. I repeat, it is possible that I'm missing something as I am
new to AMBA and I haven't apprehended the specs 100% yet, this is why I
asked here.
The fact that the slave should support *only* the NONSEQ transactions
is a project spec. On the other hand, these are only preliminary specs.
But, considering that the above info is correct and stays untouched, a
NONSEQ-only capable slave would mean that it will only do transfers at
random locations of memory, responding with ERROR for any other types
of transfers other that NONSEQ, with the master normally ensuring that
no other transactions that NONSEQ are issued, as I see it.
Anyway, I hope that the specifications stay unchanged, because coding a
fully AHB compliant interface is not such a trivial thing.
Regards,
Calin
|
|
| | From: | Joe | | Subject: | Re: AHB slave design question | | Date: | Tue, 18 Jan 2005 21:27:38 +0000 |
|
|
| Hi Calin,
If the specification don't need SPLIT/RETRY responses then certainly it
make life much easier. 8-) In fact, some AHB masters might not support
SPLIT/RETRY. By making AHB slave simple (only generate OKAY and ERROR)
might make your design more reusable.
If you make your AHB slave ONLY capable of handling Non-SEQ transfers,
the main concerns I have are:
- The CPU bus interface unit and AHB bus infrastructure can
(potentially) merge multiple single transfers into a burst if the
addresses are continuous. Or if it is a cacheable memory region, a read
to a single data location can result in cache line fill (a burst).
- If you need to make the slave response with Error response when the
master attempted a SEQ transfer, it means you will get data abort/prefer
abort, which make the system (both hardware & software) more complex.
By making the AHB slave handle SEQ transfer same way as Non-SEQ, you
might not need to have any need to generate error response (HRESP will
then be always be OKAY, making the design much simpler!).
Therefore I really think you should double check if you really want to
have an AHB slave that cannot handle SEQ transfers. For most simple
designs, you can handled SEQ same as Non-SEQ, and Busy cycle is handled
same way as Idle cycle.
Hope this helps.
regards,
Joseph
|
|
| | From: | Charles Gardiner | | Subject: | Re: AHB slave design question | | Date: | Fri, 21 Jan 2005 00:09:04 +0100 |
|
|
| Hi,
I hope it's not too late to cut in on this thread.
I think it is not too difficult to do what CalinD intends. If a master
attempts a burst, indicated by HTRANS=SEQ, the slave only has to issue a
retry response. The master must then release the bus and repeat the
access with a new (HTRANS = NSEQ) request to the retried address.
If the slave should receive (HTRANS = BUSY) it must (AMBA requirement)
reply with OK and wait until the master changes to HTRANS = SEQ. It can
then respond to this with HRESP = RETRY, forcing the master to restart
the access.
It can happen that the master follows a HTRANS=BUSY with HTRANS = IDLE.
(Yes, a BUSY -> IDLE transition is legal if the master is performing an
incremental burst of unspecified length.) In this case the slave just
responds as to a normal IDLE cycle
Don't forget that the RETRY response is a two-cycle response:
1. cycle: HREADY = low, HRESP = RETRY
2. cycle : HREADY = high, HRESP = RETRY
a small state machine will take care of this.
Basically your slave has to handle the following scenarios
1) HREADY-in = low, => do nothing
2) HREADY-in = high && HTRANS = IDLE, => do nothing but respond with
HRESP = OK and HREADY = high in next cycle
3) (HREADY-in = high) && (HTRANS = NSEQ) && (HSEL = high), => respond
with data, HRESP = OK and HREADY = high in next cycle (or wait states of
course as needed)
4) HREADY-in = high && HTRANS = BUSY, => do nothing but respond with
HRESP = OK and HREADY = high in next cycle (basically same as IDLE but
stay selected)
5) HREADY-in = high && HTRANS = SEQ, => perform two cycle RETRY ( see above)
I don't think I have missed anything but if I have I'm sure somebody
will complain.
By the way, an AMBA master _must_ support RETRY and SPLIT but may treat
both in exactly the same way i.e. release bus and rearbitrate. SPLIT is
really of more concern to SLAVES and Arbiter than to the Master.
Hope this helps.
Charles
|
|
| | From: | Mike Lewis | | Subject: | Re: AHB slave design question | | Date: | Fri, 21 Jan 2005 13:48:41 -0500 |
|
|
|
"Charles Gardiner" wrote in message
news:cspdmh$q9v$03$1@news.t-online.com...
> Hi,
>
> I hope it's not too late to cut in on this thread.
>
> I think it is not too difficult to do what CalinD intends. If a master
> attempts a burst, indicated by HTRANS=SEQ, the slave only has to issue a
> retry response. The master must then release the bus and repeat the access
> with a new (HTRANS = NSEQ) request to the retried address.
> If the slave should receive (HTRANS = BUSY) it must (AMBA requirement)
> reply with OK and wait until the master changes to HTRANS = SEQ. It can
> then respond to this with HRESP = RETRY, forcing the master to restart the
> access.
> It can happen that the master follows a HTRANS=BUSY with HTRANS = IDLE.
> (Yes, a BUSY -> IDLE transition is legal if the master is performing an
> incremental burst of unspecified length.) In this case the slave just
> responds as to a normal IDLE cycle
>
> Don't forget that the RETRY response is a two-cycle response:
> 1. cycle: HREADY = low, HRESP = RETRY
> 2. cycle : HREADY = high, HRESP = RETRY
>
> a small state machine will take care of this.
>
>
> Basically your slave has to handle the following scenarios
>
> 1) HREADY-in = low, => do nothing
> 2) HREADY-in = high && HTRANS = IDLE, => do nothing but respond with HRESP
> = OK and HREADY = high in next cycle
> 3) (HREADY-in = high) && (HTRANS = NSEQ) && (HSEL = high), => respond with
> data, HRESP = OK and HREADY = high in next cycle (or wait states of course
> as needed)
> 4) HREADY-in = high && HTRANS = BUSY, => do nothing but respond with HRESP
> = OK and HREADY = high in next cycle (basically same as IDLE but stay
> selected)
> 5) HREADY-in = high && HTRANS = SEQ, => perform two cycle RETRY ( see
> above)
>
> I don't think I have missed anything but if I have I'm sure somebody will
> complain.
>
> By the way, an AMBA master _must_ support RETRY and SPLIT but may treat
> both in exactly the same way i.e. release bus and rearbitrate. SPLIT is
> really of more concern to SLAVES and Arbiter than to the Master.
>
> Hope this helps.
>
> Charles
Such a complicated work-around ... why not ...
Where ever you have (htrans==nseq) replace it with
(htrans==nseq) || (htrans==seq)
You now have a slave that supports both sequential
and non-sequential accesses.
Mike
|
|
| | From: | Joe | | Subject: | Re: AHB slave design question | | Date: | Fri, 21 Jan 2005 21:36:55 +0000 |
|
|
| Mike Lewis wrote:
> "Charles Gardiner" wrote in message
> news:cspdmh$q9v$03$1@news.t-online.com...
>
>
>
> Such a complicated work-around ... why not ...
>
> Where ever you have (htrans==nseq) replace it with
> (htrans==nseq) || (htrans==seq)
>
> You now have a slave that supports both sequential
> and non-sequential accesses.
>
> Mike
>
>
Exactly! That's why I can't figure out why Calin want to make his/her
AHB slave only support Non-SEQ transfer. The SEQ support don't add
hardware cost.
Charles, I know that "proper" AHB masters should support retry/split,
but I seen some designs that doesn't. ;-) So when you design an AHB
slave, you need to make sure the master can cope with responses
generate from the slave.
Joe
|
|
|
