Could it be that the "Odd" delays , as described by Johnathan, are due to "Routing" of the Xilinx FPGA in order to equalize paths, since the delays associated with specific routes is a function of specific cell utilization and associated placement as well as internal routes selected(?)
-Daniel Blakley Brigham Young University Physics and Astronomy Department On Fri, Feb 19, 2010 at 1:58 PM, <casper-requ...@lists.berkeley.edu> wrote: > Send casper mailing list submissions to > casper@lists.berkeley.edu > > To subscribe or unsubscribe via the World Wide Web, visit > > https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu > > or, via email, send a message with subject or body 'help' to > casper-requ...@lists.berkeley.edu > > You can reach the person managing the list at > casper-ow...@lists.berkeley.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of casper digest..." > > > Today's Topics: > > 1. Delays in ADC block have unexpected values (Jonathan Landon) > 2. Re: Delays in ADC block have unexpected values (Henry Chen) > 3. Re: Delays in ADC block have unexpected values (Aaron Parsons) > 4. Re: Delays in ADC block have unexpected values (David MacMahon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 19 Feb 2010 10:04:04 -0800 (PST) > From: Jonathan Landon <silicondiode2...@yahoo.com> > Subject: [casper] Delays in ADC block have unexpected values > To: casper@lists.berkeley.edu > Message-ID: <805159.87634...@web51307.mail.re2.yahoo.com> > Content-Type: text/plain; charset="iso-8859-1" > > Inside the adc block with interleave mode on, the decimate-by-8 downsample > blocks have offsets of 1,3,5,7 on channels i0-i3, and offsets of 0,2,4,6 on > channels q0-q3, for 800MHz sampling, and sample time = 0.25.? This all seems > reasonable, but the delays seem inconsistent -- for the i-channels the > delays are all 1, but for the q-channels the first is 2 and the rest are 1.? > When I uncheck the "ADC interleave mode" box, the downsample blocks change > to decimate by 4, and the i- and q-channel delays are both set with the > first at 2 and the rest 1.? These delays seem strange to me -- I expect them > to all be the same and have the downsample blocks take care of the delays, > or have successively longer delays while keeping the downsample blocks the > same.? So having one delay set at 2 and the rest at 1 seems strange, and > having the i-channels and q-channels behave differently for interleave-mode > on vs. off seems strange.? When interleave mode is turned off, > the downsample blocks are running the function sdspdsamp2, but since > they're all running the same version of that function, shouldn't the delays > be set as 1,2,3,4, instead of 2,1,1,1? > > I didn't find an explanation for this in the CASPER memos, and Jason says > he didn't exped the adc block to be set up like this.? Does anyone else know > why the delays are set up like this?? (I'm using the 10.1 tools on > otto.eecs.berkeley.edu, in case it helps) > > Thanks, > Jonathan Landon > > > > > > -------------- next part -------------- > An HTML attachment scrubbed and removed. > HTML attachments are only available in MIME digests. > > ------------------------------ > > Message: 2 > Date: Fri, 19 Feb 2010 10:13:51 -0800 > From: Henry Chen <hche...@ssl.berkeley.edu> > Subject: Re: [casper] Delays in ADC block have unexpected values > To: casper@lists.berkeley.edu > Message-ID: <4b7ed4df.1090...@ssl.berkeley.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Jonathan, > > There's probably some peculiarity to Simulink that necessitated > that kind of weirdness. Since the bulk of the components inside > the ADC yellow block are just a simulation model, those delay > values were probably found empirically. > > Thanks, > Henry > > Jonathan Landon wrote: > > Inside the adc block with interleave mode on, the decimate-by-8 > > downsample blocks have offsets of 1,3,5,7 on channels i0-i3, and offsets > > of 0,2,4,6 on channels q0-q3, for 800MHz sampling, and sample time = > > 0.25. This all seems reasonable, but the delays seem inconsistent -- > > for the i-channels the delays are all 1, but for the q-channels the > > first is 2 and the rest are 1. When I uncheck the "ADC interleave mode" > > box, the downsample blocks change to decimate by 4, and the i- and > > q-channel delays are both set with the first at 2 and the rest 1. These > > delays seem strange to me -- I expect them to all be the same and have > > the downsample blocks take care of the delays, or have successively > > longer delays while keeping the downsample blocks the same. So having > > one delay set at 2 and the rest at 1 seems strange, and having the > > i-channels and q-channels behave differently for interleave-mode on vs. > > off seems strange. When interleave mode is turned off, the downsample > > blocks are running the function sdspdsamp2, but since they're all > > running the same version of that function, shouldn't the delays be set > > as 1,2,3,4, instead of 2,1,1,1? > > > > I didn't find an explanation for this in the CASPER memos, and Jason > > says he didn't exped the adc block to be set up like this. Does anyone > > else know why the delays are set up like this? (I'm using the 10.1 > > tools on otto.eecs.berkeley.edu, in case it helps) > > > > Thanks, > > Jonathan Landon > > > > > > > > ------------------------------ > > Message: 3 > Date: Fri, 19 Feb 2010 10:17:17 -0800 > From: Aaron Parsons <apars...@astron.berkeley.edu> > Subject: Re: [casper] Delays in ADC block have unexpected values > To: Jonathan Landon <silicondiode2...@yahoo.com> > Cc: casper@lists.berkeley.edu > Message-ID: > <9af1b1f21002191017r63598909v5145aecc82598...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > I think that there's a weird corner-case with offsets of 0 whereby it shows > up a clock early in the downsampling (because 0 offset falls right on the > downsample boundary). That's why there's a special delay for the 0-offset > case. > > Of course, you know this is just a simulation-level part of the block. It > does not get mapped into hardware at all--it's just to give some basic > simulation functionality to the block. So if the output looks like what > you > expect, the details of the simulation model aren't terribly important. > > On Fri, Feb 19, 2010 at 10:04 AM, Jonathan Landon < > silicondiode2...@yahoo.com> wrote: > > > Inside the adc block with interleave mode on, the decimate-by-8 > downsample > > blocks have offsets of 1,3,5,7 on channels i0-i3, and offsets of 0,2,4,6 > on > > channels q0-q3, for 800MHz sampling, and sample time = 0.25. This all > seems > > reasonable, but the delays seem inconsistent -- for the i-channels the > > delays are all 1, but for the q-channels the first is 2 and the rest are > 1. > > When I uncheck the "ADC interleave mode" box, the downsample blocks > change > > to decimate by 4, and the i- and q-channel delays are both set with the > > first at 2 and the rest 1. These delays seem strange to me -- I expect > them > > to all be the same and have the downsample blocks take care of the > delays, > > or have successively longer delays while keeping the downsample blocks > the > > same. So having one delay set at 2 and the rest at 1 seems strange, and > > having the i-channels and q-channels behave differently for > interleave-mode > > on vs. off seems strange. When interleave mode is turned off, the > > downsample blocks are running the function sdspdsamp2, but since they're > all > > running the same version of that function, shouldn't the delays be set as > > 1,2,3,4, instead of 2,1,1,1? > > > > I didn't find an explanation for this in the CASPER memos, and Jason says > > he didn't exped the adc block to be set up like this. Does anyone else > know > > why the delays are set up like this? (I'm using the 10.1 tools on > > otto.eecs.berkeley.edu, in case it helps) > > > > Thanks, > > Jonathan Landon > > > > > > > > > -- > Aaron Parsons > > 510-406-4322 (cell) > Campbell Hall 523, UCB > -------------- next part -------------- > An HTML attachment scrubbed and removed. > HTML attachments are only available in MIME digests. > > ------------------------------ > > Message: 4 > Date: Fri, 19 Feb 2010 10:40:45 -0800 > From: David MacMahon <dav...@astro.berkeley.edu> > Subject: Re: [casper] Delays in ADC block have unexpected values > To: Aaron Parsons <apars...@astron.berkeley.edu> > Cc: Jonathan Landon <silicondiode2...@yahoo.com>, > casper@lists.berkeley.edu > Message-ID: <0bd2748a-011a-49f0-98b6-d760aed16...@astro.berkeley.edu> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Feb 19, 2010, at 10:17 , Aaron Parsons wrote: > > > So if the output looks like what you expect, the details of the > > simulation model aren't terribly important. > > ...so long as the simulation model's output is consistent with > reality. :-) > > One can always build a small test design to verify that simulation > matches reality. It's important to have confidence in the simulation > results, otherwise simulation is kind of pointless. > > Dave > > > > > End of casper Digest, Vol 27, Issue 17 > ************************************** >
