BRAM Parallel read

[ahmalk71]

Hi!

I have some questions regarding the use of BRAM. I'm planing to build a beamforming application based on time series. The number of channels are 32 and each channel needs to hold about 2000 samples in order interpolate 180 bearings. Hence there are no build-in array rotation function in FPGA, I'm thinking of using BRAM to store the incoming samples in ascending order and read the BRAM twice for each bearing to interpolate. This means that for every incoming sample I do one write and 180x2 reading operation. This seems to be straight forward for one channels, but I need to to this for all 32 channels, that is 32 memory items that have to be read in parallel. Is that possible? Can I do that in one SCTL or do I need to have a separate SCTL for each channel (memory item). The simplest way is to store all 32 samples in 32 BRAM in one loop and read all the BRAMS in the second loop making sure that the time needed to do all 360 read operation is less than the acquisition cycle. The data rate is 100k 😕   

[Terry_ALE]

BRAM sounds like the right implementation.

I would use VI defined memory (https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgaconcepts/fpga_memory_items/) so you can have one configuration and then use the VI with the memory/logic/etc for the 32 channels.

More generally, I suggest mapping out the various approaches you mention below outside of LabVIEW in a flow chart.  You can then post these for review/discussion.

[ahmalk71]

Something like this? 🙂 

I'm not the documenting type sorry if it's not what you ment.

Cheers

[Terry_ALE]

That helps!  (yep, it's a beamformer!)

Seems like each channel does not need to share data with each other (until the sum function).  In that case I would recommend making a set of VIs that handles one channel (using the VI defined resources, otherwise it is a nightmare to manage their config).  I do not think they will need to be in their own SCTL.  They are at the same rate so moving them to other loops will mean you need FIFOs to get data in/out which at this point seems like overhead.

[Intaris]

You cannot read the entries in BRAM in parallel.

Are you using SCTLs?

We multiplex when using BRAM, raise the clock speed and access the values serially instead of parallel.

[ahmalk71]

Yes, my plan is to use them inside the sctl. The problem with increasing the clock rate is risk of getting timing violation, probably pipelineing will resolve this issue but the question if you will be able to keep up with acquisition rate. Multiplexing will require a total of 180x32x2 readings! am I right?  

[Terry_ALE]

---

@Intaris wrote:

You cannot read the entries in BRAM in parallel.

Are you using SCTLs?

We multiplex when using BRAM, raise the clock speed and access the values serially instead of parallel.

---

Even if they are different BRAM items in the project or VI defined? 

[Intaris]

Any single BRAM, no matter where it's defined can only read one element at a time, unless you've got a ROM BRAM (no writes) in which case you can have two simultaneous reads, not more.

Of course if you have multiple BRAMS, you can read each one simultaneously. In SCTL at least.

[Terry_ALE]

---

@Intaris wrote:

Any single BRAM, no matter where it's defined can only read one element at a time, unless you've got a ROM BRAM (no writes) in which case you can have two simultaneous reads, not more.

Of course if you have multiple BRAMS, you can read each one simultaneously. In SCTL at least.

---

I think in this application, multiple BRAMs could be beneficial.

[ahmalk71]

With other words I can read multiple BRAMS in parallel if insaide a SCTL? Or did I misunderstood your "Of course if you have multiple BRAMS, you can read each one simultaneously. In SCTL at least."?