[SOLVED] SRAM arbitration between AHB and another interface

Status
Not open for further replies.
K

keyboardcowboy

Member level 3
Joined
Mar 4, 2010
Messages
55
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,715
Consider a design below


UART read/write to the SRAM takes multiple cycle. Lets assume the minimum number is 7. What can be done if an AHB read/write request comes during those 7 cycles?. I am unable to find a mechanism in AHB that tells the CPU to not send a request while UART is reading/writing to the SRAM. Any ideas?
 

Sort by date Sort by votes
I know nothing about AHB, but here goes:

I looked up AHB Lite and found this:

AHB-Lite bus protocol​

The main system bus uses the AHB-Lite protocol. This is a version of the AHB system bus aimed at single-master system designs. The ARM core is the only master permitted

This would indicate to me that you're violating a basic premise of AHB-Lite by letting the UART be a 'master'.

But, to be honest, I'm not even sure how the UART can write directly to the RAM, UARTs don't work that way. They can set a flag when data is available, or when their write buffer is empty, but they don't actively control reads and writes, that's left up to the processor. (Unless you've found a UART that can actually read and write autonomously).
 

Upvote 0 Downvote
Thanks for the response. This is a custom design on an FPGA. A block has a some SRAM and a UART interface. When data is received over the UART interface it has to be written to the SRAM. Logic exists to do that. UART is not a master on the AHB bus. Another requirement is that the SRAM should be accessible by the CPU (this block connects to the CPU via AHBLite bus). When the CPU wants to access the SRAM it will issue an AHB READ/WRITE transaction
 

Upvote 0 Downvote
Maybe I'm misunderstanding, but youve got an AHB bus which has a RAM, a UART and some 'master' on it. It SOUNDS like the UART, along with its associated logic, is taking control.of the bus. That makes it a master, doesn't it?
 

Upvote 0 Downvote
Hi,

Sadly I can´t help you with AHB either.
But the usual way for perifieral communication is to use buffers. This may be single bytes (registers), FIFO, or dual port RAM.
These buffers may be added to what you call (single port) RAM to relax communication.

Klaus
 
Upvote 0 Downvote
AHB protocol support inserting wait state to master via HREADY. You can drive HREADY to CPU low while UART is writing to buffer.
 
Upvote 0 Downvote
ARM AHB lite spec has comments about multi-master implementation. Basically a wrapper component is required to schedule requests.
 
Upvote 0 Downvote
barry said:
Maybe I'm misunderstanding, but youve got an AHB bus which has a RAM, a UART and some 'master' on it. It SOUNDS like the UART, along with its associated logic, is taking control.of the bus. That makes it a master, doesn't it?
Click to expand...
AHB Bus does not have a RAM. The design calls for a AHB Slave peripheral that can do UART communication and also has an internal SRAM. SRAM is single port and can save data if AHB writes to the peripheral (special address). SRAM should also be able to save data received via the UART interface
 

Upvote 0 Downvote
You're losing me. Your initial drawing shows a UART and a RAM both connected through some magic "arbiter" to the bus.

Regardless, if you follow what Morris said about using HREADY, won't that solve the problem?
 

Upvote 0 Downvote
barry said:
You're losing me. Your initial drawing shows a UART and a RAM both connected through some magic "arbiter" to the bus.

Regardless, if you follow what Morris said about using HREADY, won't that solve the problem?
Click to expand...
Yes, that solves the issue
 

Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…