Hi Andres On Mon, 17 Aug 2015 at 08:25 Andres Alvear <[email protected]> wrote:
> Hello CASPER, > > I am implementing one spectrometer with one Shared BRAM yellow block with > the next specifications: > > 1. ROACH 1 > 2. ADC083000: ADC0 (ZDOK0). 8 outputs per clock. > 3. Bw: 500 MHz > 4. N° of channels: 2048 > 5. One Shared BRAM with: > - Address width: 11 > - Data width: 32 bits. > > I've decided implement a mux with delays to pass 4 parallel streams to > serial. Finally the idea is map into memory in a correlative order from 0 > to 2047. > > I have attached snapshot of my simulink model and results. > > https://drive.google.com/file/d/0B9LbvB1SpcjONm5WR0ZZVmRHLUU/view?usp=sharing > > > https://drive.google.com/file/d/0B9LbvB1SpcjOWmZ0cVdGdmRaYUE/view?usp=sharing > > > https://drive.google.com/file/d/0B9LbvB1SpcjONlNwVnh5Qi01clE/view?usp=sharing > > As you see in the picture I am packing the 4 parallel streams in one bram > in order to unpack 2048 channels at once instead 512 per bram (I mean a > design with 4 Shared BRAM). > Does anyone know whether simulations involving the Shared BRAM yellow > block are supposed to work? I'd like to simulate the address into the > memory. I am not pretty sure about the write and read timing for Shared > BRAM. > Simulations of the shared bram should work. If you look under the block mask, you'll see a simulation model which is just a normal bram. By default it has latency 1, but this will increase to 2 or 3 if you turn on one or both of the pipelining options in the shared bram mask. > Does anyone know whether theese z^-511 delays are good enough for this > kind of implementation? I'm doing something wrong? > You certainly can do it this way -- personally for large, wide delays like you're using I would consider using a "bram_delay" block, which will delay your data in bram rather than slices. This block is available in the casper delays library. For what it's worth, the shared bram will support inputs that are 128 bits wide, so you could dispense with your serializer. In this case, you would just concatenate the four 32 bit streams together and save them in a shared bram with width 128 and depth 2^9 (rather than width 32 and depth 2^11). An arrangement like this probably also makes the readout a little simpler, since if you read the bram and interpret the contents as 32 bit words, all your channels will come out in order. If I'm interpreting your screen shots correctly then at the moment your storing channels 0:2048:8, then 1:2048:8, etc, which I'm guessing your separating out and reordering in software(?). Cheers, Jack > > Cheers, > Andrés Alvear > Universidad de Chile >
