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
<mailto:casper-requ...@lists.berkeley.edu>> wrote:
Send casper mailing list submissions to
casper@lists.berkeley.edu <mailto: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
<mailto:casper-requ...@lists.berkeley.edu>
You can reach the person managing the list at
casper-ow...@lists.berkeley.edu
<mailto: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
<mailto:silicondiode2...@yahoo.com>>
Subject: [casper] Delays in ADC block have unexpected values
To: casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>
Message-ID: <805159.87634...@web51307.mail.re2.yahoo.com
<mailto: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
<http://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
<mailto:hche...@ssl.berkeley.edu>>
Subject: Re: [casper] Delays in ADC block have unexpected values
To: casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>
Message-ID: <4b7ed4df.1090...@ssl.berkeley.edu
<mailto: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 <http://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
<mailto:apars...@astron.berkeley.edu>>
Subject: Re: [casper] Delays in ADC block have unexpected values
To: Jonathan Landon <silicondiode2...@yahoo.com
<mailto:silicondiode2...@yahoo.com>>
Cc: casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>
Message-ID:
<9af1b1f21002191017r63598909v5145aecc82598...@mail.gmail.com
<mailto: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 <mailto: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 <http://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
<mailto:dav...@astro.berkeley.edu>>
Subject: Re: [casper] Delays in ADC block have unexpected values
To: Aaron Parsons <apars...@astron.berkeley.edu
<mailto:apars...@astron.berkeley.edu>>
Cc: Jonathan Landon <silicondiode2...@yahoo.com
<mailto:silicondiode2...@yahoo.com>>,
casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>
Message-ID: <0bd2748a-011a-49f0-98b6-d760aed16...@astro.berkeley.edu
<mailto: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
**************************************
