Indeed I've implemented a separating out and reordering in a python script,
however rightnow I just trying to get an spectrum with a quite normal value
of the noise floor and a good dinamic range.
Anyways for this spectrometer i need the bram with depth 2^11 and 32 bits
each channel because I am sending out spectrums to my PIC32 microcontroller.
I've used to recibe data with a python script as the tutorial 3:
data=struct.unpack('>2048I',fpga.read('bram0',2048*4,0))
I've implemented the delay_bram as you can see in the picture, but the
results still are the same (I've tryed with 32bits too):
https://drive.google.com/file/d/0B9LbvB1SpcjOLXpfV0pLSzdVblU/view?usp=sharing
./s12_simple_32bits_1bram.py 192.168.1.11 -g 1000 -l 65536
https://drive.google.com/file/d/0B9LbvB1SpcjOTEV4ckFuUjlTQzQ/view?usp=sharing
I have injected a -3dBm tone signal @250MHz in the Bw=500MHz, but the data
seems intractable or maybe corrupted. I've noticed that something wrong my
models experience intermittent time outs on shared bram reads with ROACH 1.
or Maybe I can not extend the write and address time? this extra time
generate bad results? Has anyone else seen anything like this?
Regards,
AndrésEl lun., 17 ago. 2015 a las 14:52, Jack Hickish (<jackhick...@gmail.com>) escribió: > Hi Andres > > On Mon, 17 Aug 2015 at 08:25 Andres Alvear <andres.alve...@gmail.com> > 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 >> >
