Re: [casper] Report of experience with KatADC

[Vertatschitsch, Laura E.]

Gary,

Can you confirm the same mlib_devel checkout was used for both compiles?

--Laura


On Thu, Sep 19, 2013 at 11:12 AM, Gary, Dale E. wrote:

> Hi All,
>
> I am not sure how many out there are using or planning to use the KatADC
> boards in their projects, but I thought I would report on our experience,
> which contains a  warning: Do not use Xilinx version 11.x for ROACH2
> development that includes KatADC.  We started with that version, and did
> not want to slow development by upgrading.  However, snap blocks that
> capture the ADC time-domain output showed numerous "glitches" like that
> shown in the attached file.  The top plot shows the histogram of the two
> ADC channels on a single KatADC board, while the middle plot shows the
> time-domain data.  The green channel was behaving well, but the blue
> channel shows many glitches, both positive and negative.  The behavior
> changes whenever the ROACHes are reloaded, so that which channels are
> affected can change, and can be better or worse at different times.
>
> We created a test design to demonstrate the problem, compiled on 11.x, and
> then asked Dave MacMahon to compile the same model again on Xilinx system
> generator 13.3.  We found that when the new bof file is loaded there is no
> sign of the glitches.  We are now upgrading to 14.5, and will report our
> experience with that later.
>
> There may be other reasons not to use 11.x on ROACH2, but we did not see
> any other problems, including earlier tests with iADC boards.  It was only
> when we began using the KatADCs that we saw these anomalies.
>
> Regards,
> Dale
>

Re: [casper] Report of experience with KatADC

[Vertatschitsch, Laura E.]

Nimish,

Thanks.  My colleagues are planning on doing exactly what you mentioned:
programming ROACH2 KatADCs with the 11.5 tools we had used to previously
and successfully program ROACH1.

The advice I would give them after hearing this discussion is as follows:

[*] build the design with their current toolflow, make sure it compiles,
and then observe the internal KatADC snaps to see if the error Dale's error
is recreated.

[*] If so, update the mlib_devel to the latest (simple, fast, may work).

[*] If error persists, upgrade to Xilinx 14.x toolflow which should yield
success (extrapolated from the 13.x success presented in the initial email).

Is that the correct summary?  I can have them try and report back on this
issue as to where they exited this "if/then" statement.

--Laura

PS - my sincere apologies, Dale, for calling you Gary, earlier, I am just
jealous of nice, short last names that are human-readable


On Thu, Sep 19, 2013 at 1:35 PM, Nimish Sane  wrote:

> Hi Laura,
>
> No. The one with 11.5 used an old commit
> 1c2035ed9e4f4bcc98e9f08f2722d34dd4f10872 (Nov 12, 2012) from ska-sa.
>
> I believe Dave M used the latest one from casper-astro (waiting for his
> answer).
>
> So, as a caveat to what Dale has mentioned in his email, the problem could
> be between yellow blocks and not necessarily the toolflow, though I do not
> know if yellow block has changed significantly.
>
> Thanks,
>
> Nimish
>
>
> On Thu, Sep 19, 2013 at 1:03 PM, Vertatschitsch, Laura E. <
> lvertatschit...@cfa.harvard.edu> wrote:
>
>> Gary,
>>
>> Can you confirm the same mlib_devel checkout was used for both compiles?
>>
>> --Laura
>>
>>
>> On Thu, Sep 19, 2013 at 11:12 AM, Gary, Dale E. wrote:
>>
>>> Hi All,
>>>
>>> I am not sure how many out there are using or planning to use the KatADC
>>> boards in their projects, but I thought I would report on our experience,
>>> which contains a  warning: Do not use Xilinx version 11.x for ROACH2
>>> development that includes KatADC.  We started with that version, and did
>>> not want to slow development by upgrading.  However, snap blocks that
>>> capture the ADC time-domain output showed numerous "glitches" like that
>>> shown in the attached file.  The top plot shows the histogram of the two
>>> ADC channels on a single KatADC board, while the middle plot shows the
>>> time-domain data.  The green channel was behaving well, but the blue
>>> channel shows many glitches, both positive and negative.  The behavior
>>> changes whenever the ROACHes are reloaded, so that which channels are
>>> affected can change, and can be better or worse at different times.
>>>
>>> We created a test design to demonstrate the problem, compiled on 11.x,
>>> and then asked Dave MacMahon to compile the same model again on Xilinx
>>> system generator 13.3.  We found that when the new bof file is loaded there
>>> is no sign of the glitches.  We are now upgrading to 14.5, and will report
>>> our experience with that later.
>>>
>>> There may be other reasons not to use 11.x on ROACH2, but we did not see
>>> any other problems, including earlier tests with iADC boards.  It was only
>>> when we began using the KatADCs that we saw these anomalies.
>>>
>>> Regards,
>>> Dale
>>>
>>
>>
>

Re: [casper] Signal Processing Blockset by Matlab 2012b

[Vertatschitsch, Laura E.]

Katty,

The licenses for blocksets and toolboxes that come with Matlab can be
purchased the same way you purchased your Matlab license (varies by
institution).  You can download them from the mathworks website but in
order to use them you must have the licenses in place.


On Mon, Oct 14, 2013 at 6:28 PM, katherine viviana cortes urbina <
kattycort...@gmail.com> wrote:

> Hi all,
>
> where do I can get the Signal Processing Blockset or  DSP System Toolbox
> by matlab 2012b?. This toolbox is required only for "yellow-blocks" . I
> will like to test a spectrometer design witih of adc cards  "asiaa_adc5g".
>
>
> Cheers Katty
>
>
>

Re: [casper] How do you cause the one_GbE to send a packet on a ROACH-2

[Vertatschitsch, Laura E.]

Hey Joe, Casperites,

Can you log into the powerpc and run ifconfig on a roach 2?  I've done this
to troubleshoot 10 gbe on a roach1, and I was able to see that I truly did
enable the ten gbe using tap start, as it is listed in the ifconfig output
and then there is some data about packets sent and received.  I'm assuming
you've probably done this to get the info you provide in your initial
email.  If the buffer overflows on the one gbe, does anyone know the
behavior?

I ran into some issues on a roach 1 where the 10 gbe buffer would fill up
and overflow before i had run tap_start (if I recall correctly).  In that
case, no data would ever be transmitted, and I had to add a software
register to the overflow port to see this was the case.  Executing
tap_start before enabling my logic to send data fixed this.


On Thu, Mar 13, 2014 at 11:33 AM, Kujawski, Joseph wrote:

> Jason,
>
> They are aligned now, but still no dice.  Is the expected behavior that
> the one_GbE will broadcast a UDP packet once the EOF and last valid word
> flags are set?
>
> -Joe Kujawski
>
>
>

[casper] question about casper polyphase filterbank page

[Vertatschitsch, Laura E.]

Hey guys,

I was checking out the polyphase filter bank
page
and I have a question.  There appears to be a difference between the y(m)
mathematical description and the associated diagram in Figure 4.  Namely,
the y(m) claimed by the caption of Figure 4 is still to me a function of n,
rather than m.  There are 2 sums in the y(m) mathematical derivation, but
clearly only 1 summing operation (on each parallel stream) in Figure 4.  It
seems to me that this figure is only illustrating the inner summation of
the mathematics, and in fact summing the outputs is still a necessary step
to produce a signal consistent with y(m) in the math.

If I am missing something I apologize.  My DSP background is from EE, so
actually thinking of this as weighted overlap add was informative to me,
but I still find myself needing to re-derive things carefully to understand
subtle differences between the EE and astronomy signal processing worlds.

--Laura

Re: [casper] adc5g synchronization

[Vertatschitsch, Laura E.]

Weiwei,

Does this 
schematichelp
you out?


On Mon, Apr 7, 2014 at 5:36 PM, Weiwei Sun  wrote:

> Hi Rurik,
>
> An synchronization is required for multiple ADCs. We noticed the sync port
> on the ADC, but we don't know how to use it. For example, from the EV8AQ160
> datasheet, it mentioned the signal for sync is LVDS, but the port is SMA
> type. Could you give me some suggestions or comments on how to make it
> work? We are really appreciated! Thanks!
>
> Weiwei
>
> --
> Weiwei Sun
> Radar Remote Sensing Lab
> Department of Electrical Engineering
> University of Washington (Seattle)
>

Re: [casper] Problem with the overflow

[Vertatschitsch, Laura E.]

Hey Peter,

I'm bumping this up to the listserve.

I am unfamiliar with PAPER.  Perhaps someone with that project can help.

If you haven't yet, you should complete Tutorial 2
 with your toolflow to learn
about the 10 GbE interface and how it is controlled.

I usually build an "enable" signal via a software register into my model
file so that in python I can set up everything as necessary, specifically
set up the 10 GbE port and give it a reset, before "enabling" data to flow
into it.  PAPER may have a different strategy there.

Have you compiled the bitcode from a model file on your system, or have you
simply downloaded the bitcode and tried to run it on a Roach2?  Have you
verified you are using the python software that goes with that particular
bitcode?

I suspect that the correct piece of python software will prevent the
overflow, unless you have made changes to the model file that haven't been
accommodated in software.

Another thought:
If you run the bitcode at a speed faster than it was intended, the 10 GbE
buffer may fill as expected but the 10 GbE interface may not drain it fast
enough.  In other words, you may be running at a clock rate that pushes
data out faster than 10 Gbps.  There will be other problems with the
bitcode there as you are pushing the signals past the timing limitations.

If you compiled a PAPER model file but changed the FPGA rate from Simulink,
then while your bitcode may function logically as expected and compile
without errors, it may be trying to drive the 10 Gbps at a rate near or
over 10 Gbps.  You will have to adjust your model file and signals into the
10 GbE appropriately so that it does not overflow the buffer and the 10
Gbps rate on the link is not exceeded.

--Laura



On Mon, Oct 20, 2014 at 9:13 AM, peter  wrote:

> Hi Laura,
> This is peter from NAOC,We have a problem about the 10Gbe block on roach2.
> We use the PAPER modle for a experiment,But no data comes out to send.
> I find the reason is the overflow of TX,in addition,maybe it is the buffer
> size caused this problem.I know a little about this overflow port,what can
> I do to prevent the overflow?Do you have some good suggestions?
> Thanks for your attention!
> Best Regards!
> peter
>
>
>

Re: [casper] about tut3 input ports

[Vertatschitsch, Laura E.]

Hi Oliver,

It is a bit tough to tell where your signals are coming from with the
picture you have included.  I see a few issues though.  When connecting
Xilinx blocks to Simulink/Matlab blocks, you need to go through a special
block.  Connecting your delay blocks directly to a scope will cause errors,
and you should insert a "Gateway Out" block on each of those 3 wires.  This
would be opposite to the main error you described, namely that the
scope *cannot
*be driven by Xilinx blocks.

Casper has taken care to develop some of these yellow blocks that will take
Xilinx inputs directly, for example the "software register" block.
Unfortunately I don't have a copy of tut3.mdl right now (I'm remote at the
moment) but I would assume this quant0 block needs xilinx/casper blocks
attached to it on the left.  If your "quant_gain" From flag is coming from
a Simulink constant, then this error will occur.  If you replace it with a
Xilinx constant (and be sure and check the box "Sampled Constant") then it
should be ok.

--Laura







On Tue, Oct 21, 2014 at 9:50 AM, Wang Jinqing  wrote:

> Hi,
> I have download the tut3.mdl. And I found than for the inports,such as
> [quant_gain], the sysgen always give out such error "The input ports on
> this block must be driven by other Xilinx blocks" during simulation,see the
> appendix. So then I have change a xilinx constant block,it seem good. But
> the [quant_gain] is an inport, that is an interface to the software, so
> which xilinx is suitable?
>
> Best Regards.
> Oliver Wang
>
>
>
>

Re: [casper] software register

[Vertatschitsch, Laura E.]

Hi Homin,

I have a hunch that the new software registers may need the fixed point
toolset to work.  I can compile fine, but can't simulate and can't change
the parameters.  The fixed point toolset seems to be the main difference
between myself and Rurik's set up, and he seems to have no issues. I'd be
curious to see if the same is true for you.

Laura

On Sunday, November 9, 2014, David MacMahon 
wrote:

> Hi, Homin,
>
> What bad luck did you have?  One thing about the new software registers
> that might be causing you problems is that they require the inputs to be of
> the desired/requested/expected width.  IOW, instead of using a "convert"
> block internally to make the user-supplied input be the expected width, the
> new software register uses an "assert" block to require that the user
> (you!) adds the appropriate convert block before the software register.  I
> think this unfriendly to users, but I think that's the way it is.
>
> You might have to add a "bitbasher" block (or "reinterpret" and "convert"
> blocks) before the software register to make the new software register
> yellow block happy.
>
> HTH,
> Dave
>
> On Nov 9, 2014, at 7:53 PM, Homin Jiang wrote:
>
> > Hi Jack:
> >
> > I followed your instruction, but i didn't have good luck. I am using
> latest version of mlib_devel library from ska-sa, and i guess the latest
> "software register" block has something wrong.
> > There is a "software register_OLD" in the library, is there a command i
> can replace the "software register" by "software register_OLD" ?
> >
> > regards
> > homin
> >
> >
> > On Fri, Nov 7, 2014 at 7:03 PM, Jack Hickish  > wrote:
> > Hi Homin,
> >
> > As Wes says, there's a good chance you need to replace your sw registers
> with new versions from the library. For sanity, you can do this
> automatically from the matlab prompt with the command (open your model
> first so bdroot points to it):
> >
> > >> update_casper_blocks(bdroot, 'Tag', 'xps:sw_reg')
> >
> > You can update *all* casper blocks with:
> > >> update_casper_blocks(bdroot)
> >
> > Cheers,
> > Jack
> >
> > On Fri Nov 07 2014 at 08:30:09 Wesley New  > wrote:
> > Can you elaborate on these errors?
> >
> > A while ago the software registers were updated so you might have to
> replace all of the software registers in you your design with the new on
> from the library.
> >
> > Wesley New
> > South African SKA Project
> > +2721 506 7365
> > www.ska.ac.za
> >
> >
> >
> > On Fri, Nov 7, 2014 at 3:55 AM, Homin Jiang  > wrote:
> > Hello:
> >
> > I am upgrading my system to xilinx 14.7 with Matlab 2012a and up to date
> mlib_devel library.
> > I encountered errors by the "software register" in XPS library. Any one
> can help ?
> >
> > thanks
> > homin
> >
> >
> >
>
>
>

Re: [casper] software register

[Vertatschitsch, Laura E.]

Hi Dave,

Thanks for the information.

I'm using the sma-wideband fork of mlib_devel, and I am at commit 263df71
from Sep 24 this year.

Rurik checked in a design he made with a software register, and when I
attempt to edit it and double click to view the options, I get a popup
error:
-->Error evaluating 'MaskCallback' callback of swreg block (mask)
'r2dbe_top /r2dbe/quantize_0/thresh'. -->Not enough input arguments.
-->Error evaluating 'MaskCallback' callback of swreg block (mask)
'r2dbe_top /r2dbe/quantize_0/thresh'. -->Undefined function
'swreg_maskcheck' for input arguments of type 'char'. -->Error evaluating
'MaskCallback' callback of swreg block (mask) 'r2dbe_top
/r2dbe/quantize_0/thresh'. -->Undefined function 'swreg_maskcheck' for
input arguments of type 'char'. -->Error evaluating 'MaskCallback' callback
of swreg block (mask) 'r2dbe_top /r2dbe/quantize_0/thresh'. -->Undefined
function 'swreg_maskcheck' for input arguments of type 'char'.

Ignoring the obvious names of variables in our particular design, seems
there are callback issues with swreg_maskcheck.  After closing the popup, I
get to the options dialog:
Mode: one value
I/O direction: From Processor
I/O delay: 0
Sample period: 1
Name: gain
Bitwidth: 32
Type: 0
Binary Pt: 0
X Provide sim input/output

When attempting to hit OK even after not changing anything, I get the
following error in a popup:
-->Error in 'r2dbe_top/r2dbe/quantize_0/thresh': Initialization commands
cannot be evaluated. -->swreg block (mask) does not have a parameter named
'numios'

I can just close the error window and options by using the X at the top
right of the windows.

When simulating, I get the error from the sw register we call "thresh"
saying the "Initialization commands cannot be evaluated.  Caused by: swreg
block (mask) does not have a parameter named 'numios'"

I get popup errors when trying to change any of the options, and since
pressing OK results in an error, I actually can never change this block.

Errors are all in simulation and design - I can compile just fine.

--Laura

On Mon, Nov 10, 2014 at 8:01 PM, David MacMahon 
wrote:

> Hi, Laura,
>
> It looks like the software registers end up using the "fixdt" function
> when setup as "From Processor" and the mode is other than "one value".  I'm
> pretty sure the "fixdt" function is from the fixed point toolbox.
>
> Does your problem happen only on software registers with more than one
> output or does it happen on all software registers?  Which mlib_devel
> commit are you using?
>
> Dave
>
> On Nov 9, 2014, at 9:04 PM, Vertatschitsch, Laura E. wrote:
>
> > Hi Homin,
> >
> > I have a hunch that the new software registers may need the fixed point
> toolset to work.  I can compile fine, but can't simulate and can't change
> the parameters.  The fixed point toolset seems to be the main difference
> between myself and Rurik's set up, and he seems to have no issues. I'd be
> curious to see if the same is true for you.
> >
> > Laura
> >
> > On Sunday, November 9, 2014, David MacMahon 
> wrote:
> > Hi, Homin,
> >
> > What bad luck did you have?  One thing about the new software registers
> that might be causing you problems is that they require the inputs to be of
> the desired/requested/expected width.  IOW, instead of using a "convert"
> block internally to make the user-supplied input be the expected width, the
> new software register uses an "assert" block to require that the user
> (you!) adds the appropriate convert block before the software register.  I
> think this unfriendly to users, but I think that's the way it is.
> >
> > You might have to add a "bitbasher" block (or "reinterpret" and
> "convert" blocks) before the software register to make the new software
> register yellow block happy.
> >
> > HTH,
> > Dave
> >
> > On Nov 9, 2014, at 7:53 PM, Homin Jiang wrote:
> >
> > > Hi Jack:
> > >
> > > I followed your instruction, but i didn't have good luck. I am using
> latest version of mlib_devel library from ska-sa, and i guess the latest
> "software register" block has something wrong.
> > > There is a "software register_OLD" in the library, is there a command
> i can replace the "software register" by "software register_OLD" ?
> > >
> > > regards
> > > homin
> > >
> > >
> > > On Fri, Nov 7, 2014 at 7:03 PM, Jack Hickish 
> wrote:
> 

[casper] inverse PFB

[Vertatschitsch, Laura E.]

Hi Ryan,

I have used a method of similar simplicity that involves swapping the real
and imaginary parts of samples before and after the fft, so a mathematical
equivalent of multiplying by j after taking the conjugate of the samples.
For that design I used the fft_direct block and operated only on 32
incoming parallel samples.

The issue is more that we aren't sure which fft block to place in that
algorithm for the case Jonathan describes, or if there is a clever
algorithm to use another block.  We use the fft_wideband_real to generate
half of the full fft, so 16k points coming out over many clock cycles.
This block expects input data that is real and produces output data that is
complex.  It strikes me that this block will not natively slide into the
real/imag-swap algorithm.

We could obviously try and produce the full fft output from the data by
flipping and concatenation (and find the value at pi?), but we are still
left with complex data in need of an fft block that will accept it and
perform a 32k point transform.

Do others use such a block with success?  It was suggested to me that the
wideband real block was much more widely used than the other blocks, thus
it is up to date, tested, and working.

It would be really neat if there was a dsp trick out there that used the
wideband_real as an inverse, but we'd like to go with simplest solution
regardless.

-Laura



On Thursday, December 11, 2014, Ryan Monroe > wrote:

> IIRC, an inverse FFT can be implemented as
> 1. Complex conjugate
> 2. Fft
> 3. Complex conjugate
>
> Which is mathematically identical iirc to an ifft, if slightly less
> efficient computationally.
>
> In general, the output will not be real valued of course
>
> On Tue, Dec 9, 2014, 2:45 PM Jonathan Weintroub <
> jweintr...@cfa.harvard.edu> wrote:
>
>> Thanks to Richard and everyone who responded earlier for the comments,
>> which in some cases are very detailed. It is good to know we are not the
>> only ones worrying about this.  Our DSP group is digesting the material and
>> looking at options, and other followup will likely follow.  I  did not want
>> to delay thanks and acknowledgment.
>>
>> One basic question which did come up is it appears that even an inverse
>> FFT would present some challenges.  We stuff the 32k forward FFT with real
>> time series data and extract 16k complex frequency domain points.   Might I
>> ask if any CASPER folks have experience implementing an inverse FFT
>> relevant to this case, as a real time FPGA bit code?
>>
>> Thanks again.
>>
>> Jonathan Weintroub
>> SAO
>>
>>
>> > On Dec 8, 2014, at 9:50 PM, Richard Shaw 
>> wrote:
>> >
>> > Hi,
>> >
>> > I thought I'd comment as this is a problem we've been having to deal
>> > with recently for some VLBI observations. Fortunately we've had some
>> > success with an offline least-squares inversion of the PFB. This is
>> > probably not the scheme that you want, as it essentially operates on
>> > the whole PFB'd timestream at once, so realistically you need a
>> > cluster to do it. However, there is prototype code available here [1]
>> > if it's useful.
>> >
>> > The rationale for doing this is is that when you look at the whole PFB
>> > timestream very little information is actually lost (essentially only
>> > a few samples at the ends), though it may be spread across frequency
>> > and time samples. For N PFB samples of length M, there are roughly
>> > 2*N*M total numbers measured, which depend on 2*(N+P-1)*M numbers in
>> > the underlying timestream (where P is the number of taps). As
>> > typically P << N, there are very few unmeasured linear combinations,
>> > and so a statistical inversion can be pretty accurate. Fortunately it
>> > turns out this inversion can also be done pretty efficiently.
>> >
>> > The general scheme is this:
>> >
>> > 1. inverse FFT to generate a pseudo-timestream
>> > 2. the coupling matrix between elements in this pseudo-timestream and
>> > the real timestream is sparse diagonal, and is trivially calculable
>> > from the window function
>> > 3. Perform a shuffle on the timstream to turn this into a series of
>> > band diagonal matrices (bandwidth ~ 2*P)
>> > 4. Use a band diagonal least-squares solve to invert the
>> > pseudo-timestream back to the underlying timestream.
>> >
>> > A fuller description is here [2].
>> >
>> > The complexity is O(N), and as the inversion breaks into blocks it
>> > parallelises pretty trivially up to M processes (where M is the number
>> > of samples in the window function).
>> >
>> > We did look at some iterative ways that step through the PFB
>> > timestream, but they seem to accumulate errors as they go, and become
>> > horribly inaccurate very quickly. This avoids it by treating the whole
>> > timestream at once. Your accuracy improves the longer the length you
>> > use at once.
>> >
>> > Juan Mena Parra and Kevin Bandura (cc'd) have also been looking at
>> > what would need to change about the PFB to make it more easily
>> > invertible in a strea

Re: [casper] DRAM on ROACH2?

[Vertatschitsch, Laura E.]

Hi Brad,

Myself and Rurik Primiani did some work on the PPC interface to the DDR3
module over a year ago, but had to stop before completion.  I think I have
some files around in github in the ddr3-devel branch of the sma-wideband
repo, but it is in a state where I was not getting error-free reads (I
think .03% of data was incorrect) and was contemplating starting fresh.  In
the interest of time we adapted our model to use only the FPGA interface
for reads and writes.

Happy to speak more if you want to pick this up.

--Laura

On Fri, Feb 13, 2015 at 12:29 AM, Juan-Pierre Jansen van Rensburg <
jvrensburg...@gmail.com> wrote:

> Hi Brad
>
> I only had time work on the FPGA interface to the DDR3 DRAM... for our
> application the CPU interface was more of a nice to have.
> The only other person that I know of who might have done some work on this
> is Rurik?
>
> MIG (Memory Interface Generator) is a Xilinx tool that allows you to
> generate the memory controller VHDL/Verilog code for various memory
> modules.
>
> Cheers,
> JP
>
> On Fri, Feb 13, 2015 at 5:44 AM, Brad Dober  wrote:
>
>> Hi Casperites,
>>
>> Has anyone implemented the DDR3 DRAM on ROACH2 with a PPC interface?
>> I saw some whispers of work on a DRAM yellow block for ROACH2 by Juan
>> Pierre in 2013 on the mail archive, but I don't think there was ever a PPC
>> interface ever built. (Some mention of a MIG was made, but I'm not sure
>> what that is.)
>>
>> Thanks for the help!
>>
>> Brad Dober
>> Ph.D. Candidate
>> Department of Physics and Astronomy
>> University of Pennsylvania
>> Cell: 262-949-4668
>>
>
>

Re: [casper] Reading many ADC samples from PowerPC/KATCP

[Vertatschitsch, Laura E.]

Danny,

We routinely fill snapshots with 250k ADC samples, then read them out with
the get_snapshot command.

If you are interested I can point you to the R2DBE github design (so you
can see how we use the snapshots) and I can get you some scripts I was
using quite recently in the lab to buffer up 10s to 100s of these snapshots
and compute statistics.

Or did you specifically want to use the QDR?

--Laura

On Tue, Jul 21, 2015 at 11:30 AM, Danny Price 
wrote:

>  Hi all
>
> Does anyone have an example ROACH2 design + readout script to buffer up a
> large amount of ADC samples (around 200,000 would be ideal) in BRAM/QDR,
> then read them out slowly via KATCP? If so, may I please get a copy?
>
> Thanks
> Danny
>