Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Thanks Jack and Dan. Regarding the qdr_transpose block, I am still confused. I have set up some simple models to figure out how this block works, but they just lead me to a greater confusion. One of the models is like this: https://www.dropbox.com/s/dwhukesqqhdgllf/Screenshot%20from%202015-04-24%2018%3A26%3A33.png?dl=0 . The parameters of the counter are https://www.dropbox.com/s/hboym3amfbrcom9/Screenshot%20from%202015-04-24%2018%3A26%3A51.png?dl=0 . And the parameters of the qdr_transpose block are https://www.dropbox.com/s/o9ke9wpur5bucwt/Screenshot%20from%202015-04-24%2018%3A27%3A20.png?dl=0 . What I expect to do is to transpose the matrix like this https://www.dropbox.com/s/cogwtc3sk0cnuem/Screenshot%20from%202015-04-24%2019%3A09%3A27.png?dl=0. I have no idea whether the model is doing the same thing as I expect it to finish, since the execution of the simulation results in this https://www.dropbox.com/s/c28ya7koy5nyisi/Screenshot%20from%202015-04-24%2018%3A21%3A52.png?dl=0 in the scope, which seems quite chaotic and intractable. I hope you can give me some more details on how to use the qdr_transpose block. Thanks! On Thu, Mar 26, 2015 at 4:38 PM, Chenwei Cai caichenwei1...@gmail.com wrote: Dear CASPER, My name is Chenwei Cai, and I am constructing the Mega-Channel Spectrometer with ROACH II. To achieve that, two corner turners are required before we implement FFTs, which means I may use qdr_transpose or qdr_ct blocks. Since I cannot find any explanations on these blocks anywhere, could you provide me some details about the functions of these two blocks and what kind of data do those ports receive/export? Look forward to hearing from you! -- Best Regards Chenwei CAI Mobile: +86-152-0147-9411 Email: caichenwei1...@pku.edu.cn -- Best Regards Chenwei CAI Mobile: +86-152-0147-9411 Email: caichenwei1...@pku.edu.cn
Re: [casper] Skewed data samples
I think they do but am not sure. I didn't have time to download firmware from JPL (I'm in Canberra) to get actual data samples. We shoved the signal into a DSN data processor. It has a display, reports rms but no mean. (After all, RF data is always zero mean, right?) I'm wondering about the fiber-optic links. You have some experience with that. Tom From: G Jones [glenn.calt...@gmail.com] Sent: Friday, April 24, 2015 4:34 PM To: Kuiper, Thomas (3266) Cc: Casper Lists Subject: Re: [casper] Skewed data samples Hi Tom, Wouldn't that just cause extra power in the DC bin? Or do the samples still have zero mean? Glenn On Fri, Apr 24, 2015 at 7:32 PM, Kuiper, Thomas (3266) kui...@jpl.nasa.govmailto:kui...@jpl.nasa.gov wrote: Does any have an idea what might happen to a PFB if the data samples have a slight skewness towards negative values? Maybe someone has the answer before I start modeling. Thank Tom
Re: [casper] Skewed data samples
Hi Tom, Wouldn't that just cause extra power in the DC bin? Or do the samples still have zero mean? Glenn On Fri, Apr 24, 2015 at 7:32 PM, Kuiper, Thomas (3266) kui...@jpl.nasa.gov wrote: Does any have an idea what might happen to a PFB if the data samples have a slight skewness towards negative values? Maybe someone has the answer before I start modeling. Thank Tom
[casper] Skewed data samples
Does any have an idea what might happen to a PFB if the data samples have a slight skewness towards negative values? Maybe someone has the answer before I start modeling. Thank Tom
Re: [casper] Skewed data samples
hi tom, if you are using casper adcs: all the casper adc boards are AC coupled (they have baluns and coupling capacitors), so even if your input signal has a DC offset, it won't couple into the ADC. however, there are slight DC offsets in the ADC, so there will be a small spike in the DC bin, but probably not from the signal your are injecting. best wishes, dan On Fri, Apr 24, 2015 at 4:38 PM, Kuiper, Thomas (3266) kui...@jpl.nasa.gov wrote: I think they do but am not sure. I didn't have time to download firmware from JPL (I'm in Canberra) to get actual data samples. We shoved the signal into a DSN data processor. It has a display, reports rms but no mean. (After all, RF data is always zero mean, right?) I'm wondering about the fiber-optic links. You have some experience with that. Tom From: G Jones [glenn.calt...@gmail.com] Sent: Friday, April 24, 2015 4:34 PM To: Kuiper, Thomas (3266) Cc: Casper Lists Subject: Re: [casper] Skewed data samples Hi Tom, Wouldn't that just cause extra power in the DC bin? Or do the samples still have zero mean? Glenn On Fri, Apr 24, 2015 at 7:32 PM, Kuiper, Thomas (3266) kui...@jpl.nasa.govmailto:kui...@jpl.nasa.gov wrote: Does any have an idea what might happen to a PFB if the data samples have a slight skewness towards negative values? Maybe someone has the answer before I start modeling. Thank Tom
Re: [casper] New CASPER toolflow features for planAhead
Hi Dave, All These (useful) changes have been pushed to the repo at ska-sa as well. Regards Andrew On Fri, Apr 24, 2015 at 12:26 AM, David MacMahon dav...@astro.berkeley.edu wrote: I pushed a few changes to the casper-astro mlib_devel repository to make life easier when working with Pblocks and planAhead on CASPER designs. ## casper_create_ppr.sh The casper_create_ppr.sh shell script has been added to the ROACH2 base package (XPS_ROACH2_base). After completing a build (typically one that failed to meet timing) you can cd into the design's XPS_ROACH2_base directory and run the casper_create_ppr.sh script to create and populate a planAhead project (i.e. a .ppr file) that can be used to explore the results of the build and then perhaps define Pblocks. See the log message for more details: https://github.com/casper-astro/mlib_devel/commit/a949c9d * UPDATE: The log's example invocation of planAhead is not quite right. It shows planAhead ../planahead/foo-g1234567.ppr, but it should be planAhead ./planahead/foo-g1234567.ppr (i.e. it should be ./ not ../). The name of the actual ppr file will depend on your design name and its git status. ## Auto-include of user-provided UCF snippets With the new changes, the toolflow now provides the ability to automatically include UCF snippets, such as one might use to define Pblocks and assign various components to them. Once you have created a UCF snippet that defines Pblocks and assigns components to them, all you need to do is store that UCF snippet in the model_name/ucf subdirectory. For example, if your model file is named .../foo.mdl, then you would place your UCF snippet(s) in .../foo/ucf/. When the toolflow next creates the overall system.ucf file (e.g. on the next build), it will automatically include these UCF snippet(s) in the overall system.ucf file. This provides a convenient way to apply previously defined Pblocks to future builds as well as to version control the user-defined UCF snippet(s). The location of the UCF snippets can be overridden by environment variables (if desired). For more details, see the commit log message: https://github.com/casper-astro/mlib_devel/commit/057d65b Thanks go to Rurik Primiani for the original environment-variable-specified-auto-include feature upon which this auto-include feature is based! Note that this new auto-include feature is 100% backwards compatible with Rurik's, so if you are using that already, this new one will not break anything for you. Enjoy, Dave P.S. AFAICT, these changes have not yet been pushed to the ska-sa mlib_devel repository. If you cloned your mlib_devel from there then you will have to wait until these changes get there.
Re: [casper] Skewed data samples
Rick. Carlson, 42 Pinhey St, Ottawa ON, K1Y 1T2Home 613-728-2074, cell 613-697-2669 From: Dan WerthimerSent: Friday, April 24, 2015 8:35 PMTo: Kuiper, Thomas (3266)Cc: Casper ListsSubject: Re: [casper] Skewed data sampleshi tom,if you are using casper adcs:all the casper adc boards are AC coupled(they have baluns and coupling capacitors),so even if your input signal has a DC offset, it won't coupleinto the ADC. however, there are slight DC offsets in the ADC,so there will be a small spike in the DC bin, but probablynot from the signal your are injecting.best wishes,danOn Fri, Apr 24, 2015 at 4:38 PM, Kuiper, Thomas (3266) kui...@jpl.nasa.gov wrote:I think they do but am not sure. I didn't have time to download firmware from JPL (I'm in Canberra) to get actual data samples. We shoved the signal into a DSN data processor. It has a display, reports rms but no mean. (After all, RF data is always zero mean, right?) I'm wondering about the fiber-optic links. You have some experience with that. Tom From: G Jones [glenn.calt...@gmail.com] Sent: Friday, April 24, 2015 4:34 PM To: Kuiper, Thomas (3266) Cc: Casper Lists Subject: Re: [casper] Skewed data samples Hi Tom, Wouldn't that just cause extra power in the DC bin? Or do the samples still have zero mean? Glenn On Fri, Apr 24, 2015 at 7:32 PM, Kuiper, Thomas (3266) kui...@jpl.nasa.govmailto:kui...@jpl.nasa.gov wrote: Does any have an idea what might happen to a PFB if the data samples have a slight skewness towards negative values? Maybe someone has the answer before I start modeling. Thank Tom
Re: [casper] Skewed data samples
Yeah that'll just be some power showing up in the DC bin (which you should throw away anyways) --Ryan On Fri, Apr 24, 2015 at 5:38 PM, Kuiper, Thomas (3266) kui...@jpl.nasa.gov wrote: Thanks, Dan. Yes, we're using KAT ADCs. I'm not worried about a DC offset and I know about the slight ADC bias. It's the skewness I'm wondering about. It's just barely detectable by eye in a histogram. Tom From: dan.werthi...@gmail.com [dan.werthi...@gmail.com] on behalf of Dan Werthimer [d...@ssl.berkeley.edu] Sent: Friday, April 24, 2015 5:34 PM To: Kuiper, Thomas (3266) Cc: G Jones; Casper Lists Subject: Re: [casper] Skewed data samples hi tom, if you are using casper adcs: all the casper adc boards are AC coupled (they have baluns and coupling capacitors), so even if your input signal has a DC offset, it won't couple into the ADC. however, there are slight DC offsets in the ADC, so there will be a small spike in the DC bin, but probably not from the signal your are injecting. best wishes, dan
[casper] Roach2 dac_mkid_4x
Folks I generated a new yellow block for the mkid dac 4x. The one in my xps_library would not compile, and seemed to be designed for roach1, V5 chips. The existing block uses DCM instead of MMCM for clocking, which is illegal on Virtex 6. The new module uses MMCM. I can compile the thing in MATLAB. I checked the pinouts and they match all the way from firmware to ZDOK on the DAC board. IMPORTANT I have not tested on the ROACH2 hardware yet.*** Testing will happen soon. Here is the location: https://github.com/argonnexraydetector/RoachFirmPy.git Tim Madden Argonne Laboratory
