AMBA AHB Slave interface questions

[Johnny]

Hi all,

I have some questions about implementing an AHB slave interfce. If
anyone out there had ran into these similar problems before, any
suggestion and help would be greatly appreciated. I am trying to
create a AHB slave in VHDL to interface with the AMBA bus, which has a
ARM7 processor as the master. HDATA and HADDR buses are bidirectional.
I have read from many sources stating that HREADY from the slave
should be held HIGH when is inactive. When I do that, I will not be
able do download software code to the processor that performs simple
read/write operation. On the other hand, if I keep HREADY Low and only
assert it HIGH when the data is ready (for write operation), it works.
So what I mean is I can perform a write operation from the processor
to the register on the slave though the bus. However, when I perform a
read operation, I constantly getting wrong data. The wrong data seems
to be coming from a few cycles before even the control signals from
the processor arrive at the bus. It is very odd. I am not sure if I
describe the problems clearly but basically I can write and I can't
read (although the simulated waveform looks fine compares to the AMBA
spec). Any help would be great. Thanks

Johnny

 

[Marcus Harnisch]

HDATA and HADDR buses are bidirectional.

Never heard of that. AHB is an on-chip bus system that certainly
doesn't use bidirectional signals. In fact, read and write data are
divided into HWDATA and HRDATA (for read and write respectively).[1]
HADDR is always driven by the bus master(s) and definitely not
bidirectional either.

I have read from many sources stating that HREADY from the slave
should be held HIGH when is inactive.

The normal state of HREADY is HIGH. If a slave is not capable of
completing a transfer in a single clock cycle it can assert LOW to
extend the transfer by a limited[2] number of cycles.

When I do that, I will not be able do download software code to the
processor that performs simple read/write operation. On the other
hand, if I keep HREADY Low and only assert it HIGH when the data is
ready (for write operation), it works.

[...]

The wrong data seems to be coming from a few cycles before even the
control signals from the processor arrive at the bus.

Let me guess. Your AHB has registers between master and slaves to work
around timing issues. The slave sees the transfer a couple of cycles
after the master has submitted it. On its way back to the master the
slave response (including HRDATA, HREADY, HRESP) has to go through
registers again. The bus multiplexer has not been designed to support
a registered bus and opens the path between master and slave. The
master sees that HREADY is HIGH (the slave response hasn't arrived,
yet). It samples what it thinks is the slave response, which is in
fact a view into the history of our universe.

Is that correct?

If your slave keeps HREADY low, everythings works because HREADY has
to go through the registers alog with HRDATA. Both will arrive at the
same clock edge. But that is not the Right Way(tm) to solve the issue.
The slave shouldn't care whether it is on a registered bus or
not. Neither should the master. The bus multiplexer/arbiter (or
whatever you call it in your design) should have sole control over the
choreography of transfers. It should hold HREADY low while data is
`in-flight' and release it at the right time.

Best regards,
Marcus

Footnotes:
[1] from the bus-master's point of view

[2] A maximum of 16 wait cycles is recommended

 

[Johnny]

HDATA and HADDR buses are bidirectional.

Never heard of that. AHB is an on-chip bus system that certainly
doesn't use bidirectional signals. In fact, read and write data are
divided into HWDATA and HRDATA (for read and write respectively).[1]
HADDR is always driven by the bus master(s) and definitely not
bidirectional either.

I have read from many sources stating that HREADY from the slave
should be held HIGH when is inactive.

The normal state of HREADY is HIGH. If a slave is not capable of
completing a transfer in a single clock cycle it can assert LOW to
extend the transfer by a limited[2] number of cycles.

When I do that, I will not be able do download software code to the
processor that performs simple read/write operation. On the other
hand, if I keep HREADY Low and only assert it HIGH when the data is
ready (for write operation), it works.

[...]

The wrong data seems to be coming from a few cycles before even the
control signals from the processor arrive at the bus.

Let me guess. Your AHB has registers between master and slaves to work
around timing issues. The slave sees the transfer a couple of cycles
after the master has submitted it. On its way back to the master the
slave response (including HRDATA, HREADY, HRESP) has to go through
registers again. The bus multiplexer has not been designed to support
a registered bus and opens the path between master and slave. The
master sees that HREADY is HIGH (the slave response hasn't arrived,
yet). It samples what it thinks is the slave response, which is in
fact a view into the history of our universe.

Is that correct?

If your slave keeps HREADY low, everythings works because HREADY has
to go through the registers alog with HRDATA. Both will arrive at the
same clock edge. But that is not the Right Way(tm) to solve the issue.
The slave shouldn't care whether it is on a registered bus or
not. Neither should the master. The bus multiplexer/arbiter (or
whatever you call it in your design) should have sole control over the
choreography of transfers. It should hold HREADY low while data is
`in-flight' and release it at the right time.

Best regards,
Marcus

Footnotes:
[1] from the bus-master's point of view

[2] A maximum of 16 wait cycles is recommended

Marcus,

First, lets me thanks for your response. I really appricate your help.

Let me guess. Your AHB has registers between master and slaves to work
around timing issues. The slave sees the transfer a couple of cycles
after the master has submitted it. On its way back to the master the
slave response (including HRDATA, HREADY, HRESP) has to go through
registers again. The bus multiplexer has not been designed to support
a registered bus and opens the path between master and slave. The
master sees that HREADY is HIGH (the slave response hasn't arrived,
yet). It samples what it thinks is the slave response, which is in
fact a view into the history of our universe.

Is that correct?

If your slave keeps HREADY low, everythings works because HREADY has
to go through the registers alog with HRDATA. Both will arrive at the
same clock edge. But that is not the Right Way(tm) to solve the issue.
The slave shouldn't care whether it is on a registered bus or
not. Neither should the master. The bus multiplexer/arbiter (or
whatever you call it in your design) should have sole control over the
choreography of transfers. It should hold HREADY low while data is
`in-flight' and release it at the right time.

When you mention about the registers between the master and slave,
where are these registers are you talking about? Also, what are the
timing issues? Another thing that I didn't mention before is that all
the buses (HRDATAs) from the slaves are ORed together, instead of
multiplexed. Again, thanks so much for your response. Anymore
suggestion/idea would be great.

Johnny

 

[Charles]

Johnny,

from your mail I am going on the assumption that you have just one AHB
master (the ARM7) and a number of slaves. There is no real problem with
just ORing the slave outputs if all your slaves are designed carefully.
I connect them up that way myself often. The HREADY outputs from the
slaves must of course be ANDed. By designed carefully I mean that when
not selected, all slaves must output '0' on all signals except of course
HREADY.

Don't forget that the Slaves need HREADY as an input and an output. If
you look at the data-sheets to any of the PrimeCells on the ARM web
site, you will see that this is so. It's maybe not so clear from the
spec. A slave may only accept selection when it sees it's address and
the previous slave has finished it's last cycle. The combined (ANDed)
HREADY is fed back as an input to all Slaves as well as to the master.
The only situation you could probably do without the extra input is if
you know for sure that none of your slaves ever insert wait states.

Another problem I see surprisingly often is that people don't always pay
attention to keeping address-phase and data-phase separate. My advice
is, there should be no combinational path from the HADDR, HTRANS etc at
the master which terminate at the HREADY on the AHB bus. (i.e. come into
the slave and go back out again). At best HREADY should come from a
flip-flop in the slave with as little logic as possible between this FF
and the AHB bus. Simply put, this FF would usually be set but would go
inactive if the slave is selected and currently has no data/can receive
no more data.

I must admit I do find it a bit difficult to actually visualise your
problem, so maybe nothing I have said is of much use. Are you working on
an FPGA here? What frequency are you using? Are you designing all the
slaves? If not, is it possible one of the others is messing things up
here (particularily since you are not using muxes)?

Good luck,
Charles

 

[Marcus Harnisch]

I think this is getting somewhat off-topic since it has nothing to do
with VHDL.

^^^^^^^^^^^^

Everything I said was based on assumptions since you did't provide a
whole lot of details about what your system looks like. I don't know
whether you actually have these registers. From your problem
description it looked like that could be the problem.

When you mention about the registers between the master and slave,
where are these registers are you talking about? Also, what are the
timing issues?

If the bus clock is very fast and you have too many components hooked
up, you will get timing problems. Inserting registers as "repeaters"
into the path between master and slave can help mitigating the
situation.

Another thing that I didn't mention before is that all the buses
(HRDATAs) from the slaves are ORed together, instead of
multiplexed.

Doesn't matter (if implemented correctly).