Hey Michael I am not sure that I understand your use case correctly. It seems that you want to generate snap shots of the spectrum being generated?
The way we generally use the circular capture snapshot mode is to start capturing data, and then to trigger a stop signal on some event. The snapshot block finishes capturing the current buffer of data and then stops so that the user can read out the data associated with the stop event. The tr_en_cnt register can be used to monitor how much time has elapsed between the trig event that started capture, and the stop event stopping it. If you tie the stop input to 0, the block will never stop. You might gate the en input, and then read the data back, but you might find yourself off by a few samples, Basically, it is being used in a way that was not envisaged when it was designed. I would recommend a trigger event generated by a counter with a period of one second, and a software loop monitoring the 'done' bit in the status register to know when this has happened, read out the data, and restart the data capture. You would also need the trig input controlled by a counter that ensured that capture started at the start of a spectrum, otherwise you might start (and end) capture with an offset. Not sure if all of that made sense. Regards Andrew On Wed, Jul 27, 2016 at 4:19 PM, Michael D'Cruze < michael.dcr...@postgrad.manchester.ac.uk> wrote: > Dear all, > > > > During debugging for the new ROACH2 Lovell spectrometer, I’ve found a > potential issue with the snapshot block that I’m hoping is a control issue. > > The snapshot block is intended to take a 4096-channel slice of spectrum, > and display it via a GUI at intervals around 1 second. The spectrum appears > to “dance” around by a few channels, and in particular on larger designs > the spectrum seems to scroll across the screen. After ruling out issues > with the Python interface, I found that the snapshot block itself seemed to > be generating the address incorrectly. In simulation, the address was > lagging behind the data and write enable by a few clocks per acc, which > created the scrolling behaviour. > > > > Now, since circular capture is enabled and 0 are inserted to both the trig > and stop inputs, I’m writing 0b1011 to snap_control. According to the > instructions (and, on examination, the logic), this should enable repeated > capture, ignoring both the stop and trig inputs, but obeying the > write_enable. Can I check that this input is correct? > > > > Actually writing a block to do only what I need it to do is not difficult, > but I’d prefer to avoid recompiling everything if it is simply a control > issue. > > > > Thanks > > Michael >
