question on design problem.. bram or lut for arrays?

[Leow Yuan Yeow]

Hi there! Currently I am facing a design problem for shared resources of
large 32-bit integer arrays. If, say, a 20 by 20 32-bit integer array is to
be written by multiple processes, some kind of multiplexing and
handshaking(i.e. process do a 'req' to the manager process for an array
location, and gets an ack) is needed to choose a certain process to write to
the shared sources based on some priority scheme(e.g. round robin). If I
implement the array in bram with 1 read and write port, only 1 manager
process is needed, but it will limit the speed at which the array can be
accessed since only 1 location can be read and written in 1 clock cycle. If
I want the whole array to be able to be written and read in parallel, 400
manager processes is needed for the 20*20 locations to manage the reading
and writing from the processes.
My questions are: will this greatly increase the amount of hardware
resources needed using the 2nd scheme, and which is the better method to
use? Is there a 3rd method to handle this? Unfortunately I have to use
parallelism in this problem so shared resources cannot be avoided.
Thanks in advance!

 

[Mike Treseler]

Leow Yuan Yeow wrote:

If I
implement the array in bram with 1 read and write port, only 1 manager
process is needed, but it will limit the speed at which the array can be
accessed since only 1 location can be read and written in 1 clock cycle.

That's just the way it is for a shared resource.
Arbitration takes time and gates,
and the loser has to wait.
The alternative is separate registers per process.

If
I want the whole array to be able to be written and read in parallel, 400
manager processes is needed for the 20*20 locations to manage the reading
and writing from the processes.

If you actually have 400 interfaces waiting for access,
local registers make more sense than a shared BRAM.

-- Mike Treseler

 

[Leow Yuan Yeow]

Pardon me, but does "interface" means "ports"?
Also, for local registers accessed and written by local processes, I still
need the 400 manager processes for the 400 locations right?
I was thinking that by using BRAM I would reduce the number of ports and
manager processes needed for accessing the resource,
which can possibly by accessed by different components. Is this correct?
Thanks!

Yuan Yeow

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:40m2a5F1b4k4kU1@individual.net...

Leow Yuan Yeow wrote:

If I implement the array in bram with 1 read and write port, only 1
manager process is needed, but it will limit the speed at which the array
can be accessed since only 1 location can be read and written in 1 clock
cycle.

That's just the way it is for a shared resource.
Arbitration takes time and gates,
and the loser has to wait.
The alternative is separate registers per process.

If I want the whole array to be able to be written and read in parallel,
400 manager processes is needed for the 20*20 locations to manage the
reading and writing from the processes.

If you actually have 400 interfaces waiting for access,
local registers make more sense than a shared BRAM.

-- Mike Treseler

 

[Mike Treseler]

Leow Yuan Yeow wrote:

Pardon me, but does "interface" means "ports"?

An interface could be
at the entity port level or
at the architecture signal level or
at the process variable level.
This a matter of coding style.

Also, for local registers accessed and written by local processes, I still
need the 400 manager processes for the 400 locations right?

I expect that you can do whatever it is
that you want to do in a single process.

I was thinking that by using BRAM I would reduce the number of ports and
manager processes needed for accessing the resource,
which can possibly by accessed by different components. Is this correct?

This question is not fully formed.
I suggest that you code up an example or two
and simulate them before posting again.

-- Mike Treseler