Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: RFNoC and Vivado versions (Adam Bacon)
2. Re: USRP-users] Using Chipscope on the E310 (Jason Matusiak)
3. Re: USRP-users] Using Chipscope on the E310 (Jonathon Pendlum)
4. Re: USRP-users] Using Chipscope on the E310 (Jason Matusiak)
5. Re: USRP-users] Using Chipscope on the E310 (Jonathon Pendlum)
6. Re: USRP-users] Using Chipscope on the E310 (Jason Matusiak)
7. ADC of B210 (john liu)
8. Re: ADC of B210 (Marcus M?ller)
9. Re: ADC of B210 (liu Jong)
10. Re: ADC of B210 (Marcus M?ller)
11. Re: ADC of B210 (Marcus M?ller)
12. Re: ADC of B210 (Dan CaJacob)
13. Re: USRP-users] Using Chipscope on the E310 (Jason Matusiak)
14. Re: USRP-users] Using Chipscope on the E310 (Jonathon Pendlum)
15. Re: USRP-users] Using Chipscope on the E310 (Jason Matusiak)
----------------------------------------------------------------------
Message: 1
Date: Thu, 13 Apr 2017 16:14:55 +0000
From: Adam Bacon <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC and Vivado versions
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Jonathan,
The main feature that we are looking for that 2015.4 lacks is support for IEEE
1735 Encrypted IP modules. This support was added in 2016.3. This way Vendors
can provide encrypted/protected IP that can be wrapped and used in RFNoC blocks.
Best Regards,
Adam Bacon
Sales Engineer
AHA Products Group
Comtech EF Data Corp
www.aha.com
Office: +1 208 892 5658
Mobile: +1 509 432 6899
Skype: adam.bacon6
From: Sumit Kumar [mailto:[email protected]]
Sent: Thursday, April 13, 2017 8:27 AM
To: Jonathon Pendlum
Cc: [email protected]
Subject: Re: [USRP-users] RFNoC and Vivado versions
No no... till yesterday, the admin people at my institute said they have only
2016.4 .. but today we found 2105.4 also.
Thanks :)
On Wed, Apr 12, 2017 at 6:50 PM, Jonathon Pendlum
<[email protected]<mailto:[email protected]>> wrote:
Hi Sumit,
Yes, it is a hard constraint. We plan on upgrading Vivado versions (likely to
2016.4), but I can't give a timeline. Is there a particular feature you need
that 2015.4 does not have?
Jonathon
On Wed, Apr 12, 2017 at 7:46 AM, Sumit Kumar via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
For using RFNoC, is the Vivado version 15.4 for uhd 3.10 a hard constraint.
Wont it work with 16+ versions ?
Has anyone tried that ?
Regards
Sumit
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
________________________________
NOTICE TO RECIPIENT: This email, including attachments, may contain information
which is confidential, proprietary, attorney-client privileged and/or
controlled under U.S. export laws and regulations and may be restricted from
disclosure by applicable State and Federal law. Nothing in this email shall
create any legal binding agreement between the parties unless expressly stated
herein and provided by an authorized representative of Comtech
Telecommunications Corp. or its subsidiaries. If you are not the intended
recipient of this message, be advised that any dissemination, distribution, or
use of the contents of this message is strictly prohibited. If you received
this message in error, please notify us immediately by return email and
permanently delete all copies of the original email and any attached
documentation from any computer or other media.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170413/9585a27c/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 13 Apr 2017 12:33:51 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP-users] Using Chipscope on the E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Jonathon (or Philip),
How can I do this debugging from within chipscope? I am just doing some
free-running testing (ie I am not using GNURadio or a binary to run
signals through the system) on the system clocks and had no issues with
the X310. Now I created a new bitfile with my chipscope stuff included,
but I can't seem to get it to work from within Chipscope.
When working with the X310, I would connect to the unit from Chipscope,
download the new image, run uhd_usrp_probe to get the clocks running,
and then refresh the device from within Chipscope to get it ready for my
captures.
I can connect via JTAG to the E310, but if I try to download the new
image, I get the shutdown that Philip mentioned further up in this chain.
>Hi Ed,
>
>An approach I use when running chipscope is to specify the bitstream I
want
>to use with --args="fpga=<path to my bitstream>" and to set a breakpoint
>(via gdb) before the recv call in benchmark_rate or other utility app I am
>using. The breakpoint is useful because radio_clk is not running until the
>AD9361 has been setup. In many cases your chipscope instance will be
>probing nets using radio_clk and without that clock running Vivado
won't be
>able to find the ILA.
------------------------------
Message: 3
Date: Thu, 13 Apr 2017 10:25:00 -0700
From: Jonathon Pendlum <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP-users] Using Chipscope on the E310
Message-ID:
<cagdo0urzu2v6f30egac1s5pjqjg0aw065t_hnpxtt6g0iod...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jason,
Try loading the image manually using "cat bitstream.bit > /dev/xdevcfg"
Jonathon
On Thu, Apr 13, 2017 at 9:33 AM, Jason Matusiak <
[email protected]> wrote:
> Jonathon (or Philip),
> How can I do this debugging from within chipscope? I am just doing some
> free-running testing (ie I am not using GNURadio or a binary to run signals
> through the system) on the system clocks and had no issues with the X310.
> Now I created a new bitfile with my chipscope stuff included, but I can't
> seem to get it to work from within Chipscope.
>
> When working with the X310, I would connect to the unit from Chipscope,
> download the new image, run uhd_usrp_probe to get the clocks running, and
> then refresh the device from within Chipscope to get it ready for my
> captures.
>
> I can connect via JTAG to the E310, but if I try to download the new
> image, I get the shutdown that Philip mentioned further up in this chain.
>
>
> >Hi Ed,
> >
> >An approach I use when running chipscope is to specify the bitstream I
> want
> >to use with --args="fpga=<path to my bitstream>" and to set a breakpoint
> >(via gdb) before the recv call in benchmark_rate or other utility app I am
> >using. The breakpoint is useful because radio_clk is not running until the
> >AD9361 has been setup. In many cases your chipscope instance will be
> >probing nets using radio_clk and without that clock running Vivado won't
> be
> >able to find the ILA.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170413/bdda476f/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 13 Apr 2017 13:56:40 -0400
From: Jason Matusiak <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP-users] Using Chipscope on the E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
hmmmmm. I ran that and then did a probe and then a refresh in
chipscope, but nothing happened.
I will say that the prompt returned VERY quickly after running the cat
command, I thought it would take longer...
On 04/13/2017 01:25 PM, Jonathon Pendlum wrote:
> Hi Jason,
>
> Try loading the image manually using "cat bitstream.bit > /dev/xdevcfg"
>
>
>
> Jonathon
>
> On Thu, Apr 13, 2017 at 9:33 AM, Jason Matusiak
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Jonathon (or Philip),
> How can I do this debugging from within chipscope? I am just
> doing some free-running testing (ie I am not using GNURadio or a
> binary to run signals through the system) on the system clocks and
> had no issues with the X310. Now I created a new bitfile with my
> chipscope stuff included, but I can't seem to get it to work from
> within Chipscope.
>
> When working with the X310, I would connect to the unit from
> Chipscope, download the new image, run uhd_usrp_probe to get the
> clocks running, and then refresh the device from within Chipscope
> to get it ready for my captures.
>
> I can connect via JTAG to the E310, but if I try to download the
> new image, I get the shutdown that Philip mentioned further up in
> this chain.
>
>
> >Hi Ed,
> >
> >An approach I use when running chipscope is to specify the
> bitstream I want
> >to use with --args="fpga=<path to my bitstream>" and to set a
> breakpoint
> >(via gdb) before the recv call in benchmark_rate or other utility
> app I am
> >using. The breakpoint is useful because radio_clk is not running
> until the
> >AD9361 has been setup. In many cases your chipscope instance will be
> >probing nets using radio_clk and without that clock running
> Vivado won't be
> >able to find the ILA.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170413/f91ca706/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 13 Apr 2017 11:11:01 -0700
From: Jonathon Pendlum <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP-users] Using Chipscope on the E310
Message-ID:
<cagdo0utanzsaktwygdx6iaw63mp0ooekhsqmz2wb-6bu0kx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Are you using radio_clk as the clock for your chipscope ILA?
On Thu, Apr 13, 2017 at 10:56 AM, Jason Matusiak <
[email protected]> wrote:
> hmmmmm. I ran that and then did a probe and then a refresh in chipscope,
> but nothing happened.
>
> I will say that the prompt returned VERY quickly after running the cat
> command, I thought it would take longer...
>
>
> On 04/13/2017 01:25 PM, Jonathon Pendlum wrote:
>
> Hi Jason,
>
> Try loading the image manually using "cat bitstream.bit > /dev/xdevcfg"
>
>
>
> Jonathon
>
> On Thu, Apr 13, 2017 at 9:33 AM, Jason Matusiak <
> [email protected]> wrote:
>
>> Jonathon (or Philip),
>> How can I do this debugging from within chipscope? I am just doing some
>> free-running testing (ie I am not using GNURadio or a binary to run signals
>> through the system) on the system clocks and had no issues with the X310.
>> Now I created a new bitfile with my chipscope stuff included, but I can't
>> seem to get it to work from within Chipscope.
>>
>> When working with the X310, I would connect to the unit from Chipscope,
>> download the new image, run uhd_usrp_probe to get the clocks running, and
>> then refresh the device from within Chipscope to get it ready for my
>> captures.
>>
>> I can connect via JTAG to the E310, but if I try to download the new
>> image, I get the shutdown that Philip mentioned further up in this chain.
>>
>>
>> >Hi Ed,
>> >
>> >An approach I use when running chipscope is to specify the bitstream I
>> want
>> >to use with --args="fpga=<path to my bitstream>" and to set a breakpoint
>> >(via gdb) before the recv call in benchmark_rate or other utility app I
>> am
>> >using. The breakpoint is useful because radio_clk is not running until
>> the
>> >AD9361 has been setup. In many cases your chipscope instance will be
>> >probing nets using radio_clk and without that clock running Vivado won't
>> be
>> >able to find the ILA.
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170413/4bd2ab49/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 13 Apr 2017 15:09:49 -0400
From: Jason Matusiak <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP-users] Using Chipscope on the E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I don't know how, but I've seem to have gotten it working now. It
definitely had to do with your "cat" trick though, so thank you!
On 04/13/2017 02:11 PM, Jonathon Pendlum wrote:
> Are you using radio_clk as the clock for your chipscope ILA?
>
> On Thu, Apr 13, 2017 at 10:56 AM, Jason Matusiak
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> hmmmmm. I ran that and then did a probe and then a refresh in
> chipscope, but nothing happened.
>
> I will say that the prompt returned VERY quickly after running the
> cat command, I thought it would take longer...
>
>
> On 04/13/2017 01:25 PM, Jonathon Pendlum wrote:
>> Hi Jason,
>>
>> Try loading the image manually using "cat bitstream.bit >
>> /dev/xdevcfg"
>>
>>
>>
>> Jonathon
>>
>> On Thu, Apr 13, 2017 at 9:33 AM, Jason Matusiak
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Jonathon (or Philip),
>> How can I do this debugging from within chipscope? I am just
>> doing some free-running testing (ie I am not using GNURadio
>> or a binary to run signals through the system) on the system
>> clocks and had no issues with the X310. Now I created a new
>> bitfile with my chipscope stuff included, but I can't seem to
>> get it to work from within Chipscope.
>>
>> When working with the X310, I would connect to the unit from
>> Chipscope, download the new image, run uhd_usrp_probe to get
>> the clocks running, and then refresh the device from within
>> Chipscope to get it ready for my captures.
>>
>> I can connect via JTAG to the E310, but if I try to download
>> the new image, I get the shutdown that Philip mentioned
>> further up in this chain.
>>
>>
>> >Hi Ed,
>> >
>> >An approach I use when running chipscope is to specify the
>> bitstream I want
>> >to use with --args="fpga=<path to my bitstream>" and to set
>> a breakpoint
>> >(via gdb) before the recv call in benchmark_rate or other
>> utility app I am
>> >using. The breakpoint is useful because radio_clk is not
>> running until the
>> >AD9361 has been setup. In many cases your chipscope instance
>> will be
>> >probing nets using radio_clk and without that clock running
>> Vivado won't be
>> >able to find the ILA.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170413/5245e451/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 14 Apr 2017 15:53:39 +0800
From: john liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] ADC of B210
Message-ID:
<caf6nntldc2hd6dax1box0pw-zhdzq8laqawade3cuffbk5o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,all,
>From the datasheet of B210,we know the ADC is 12bit,But the OTW is 16bit(or
12bit),so there is a conversion process.Is it directly add zero after the
data?
Thank you.
best regards
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/c49955b6/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 14 Apr 2017 11:02:28 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] ADC of B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi John,
there's digital downconversion happening between the ADC's sample rate
(which coincides with the rate we call Master Clock Rate) and your
sampling rate, which inherently is a bit-widening operation.
Thus, under sufficient oversampling due to above process, all your 16
bits might be significant.
Best regards,
Marcus
On 14.04.2017 09:53, john liu via USRP-users wrote:
> Hi,all,
> From the datasheet of B210,we know the ADC is 12bit,But the OTW is
> 16bit(or 12bit),so?there is a conversion process.Is it directly add
> zero after the data?
> Thank you.
>
> best regards
> John
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/bd9570b0/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 14 Apr 2017 17:37:22 +0800
From: liu Jong <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ADC of B210
Message-ID:
<CAEui2n3=x9sv6bw6m+tv5cfnntwbddvdbsnih7rmuqugv+s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI,Marcus,
thank you for your reply.
So it is not a simply add zero after the data?Maybe add some "0101" at some
where.
2017-04-14 17:02 GMT+08:00 Marcus M?ller via USRP-users <
[email protected]>:
> Hi John,
>
> there's digital downconversion happening between the ADC's sample rate
> (which coincides with the rate we call Master Clock Rate) and your sampling
> rate, which inherently is a bit-widening operation.
>
> Thus, under sufficient oversampling due to above process, all your 16 bits
> might be significant.
>
> Best regards,
>
> Marcus
>
> On 14.04.2017 09:53, john liu via USRP-users wrote:
>
> Hi,all,
> From the datasheet of B210,we know the ADC is 12bit,But the OTW is
> 16bit(or 12bit),so there is a conversion process.Is it directly add zero
> after the data?
> Thank you.
>
> best regards
> John
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/ebe305ea/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 14 Apr 2017 13:03:10 +0200
From: Marcus M?ller <[email protected]>
To: Ian Buckley <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] ADC of B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Ian,
ah right; on the B2xx, the MCR is just the rate with which the AD936x
and the FPGA exchange samples, right?
(John: the following is not related to your question)
So, what I've been actually wondering about: 12 bit ?? ADC means that
the impulse counter has 12 bits, ie. can count 0?2047 impulses per
sample period.
Now, if we assume that ADC outputs one sample every 1/(640 MHz), and
that sample is the count of pulses, and let's say it's the value 1000,
than that means that the pulse rate going into that counter is 640 GHz ?
and that feels a bit high for "cheap silicon"; now, if we instead assume
that 640 MHz is the max pulse rate, then we get a sample rate of 640 MHz
/ 2048 ? 300 kHz, which obviously too little.
So, I might be a bit confused at this point :)
Cheers,
Marcus
On 14.04.2017 11:25, Ian Buckley wrote:
> FWIW The actual ADC is a sigma-delta design and a clock rate thats an
> integer multiple of the master clock rate. For example (using UHD)
> when master_clock_rate is 40MHz, the ADC clock is 640MHz
> -Ian
>
>
>> On Apr 14, 2017, at 2:02 AM, Marcus M?ller via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi John,
>>
>> there's digital downconversion happening between the ADC's sample
>> rate (which coincides with the rate we call Master Clock Rate) and
>> your sampling rate, which inherently is a bit-widening operation.
>>
>> Thus, under sufficient oversampling due to above process, all your 16
>> bits might be significant.
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 14.04.2017 09:53, john liu via USRP-users wrote:
>>> Hi,all,
>>> From the datasheet of B210,we know the ADC is 12bit,But the OTW is
>>> 16bit(or 12bit),so?there is a conversion process.Is it directly add
>>> zero after the data?
>>> Thank you.
>>>
>>> best regards
>>> John
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/6e21722e/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 14 Apr 2017 13:04:22 +0200
From: Marcus M?ller <[email protected]>
To: liu Jong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ADC of B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi John,
> So it is not a simply add zero after the data?Maybe add some "0101" at
> some where.
No! It's more complicated than that.
Imagine the samples coming from the ADC entering a FIR filter.
In that FIR filter, they get multiplied with fixed-point filter
coefficients, so the resulting products have more "valid" bits than the
ADC samples have.
These filter states get added up to the FIR output ? which thus has more
bits than the products.
There's multiple digital filters in the B210's DSP chain.
The output of the filters is rounded to the most significant 16 bit.
So, there's no "padding" in the sense of "adding some constant bits to
the end" anywhere, here, unless you chose the case of MCR=sampling rate.
Best regards,
Marcus
On 14.04.2017 11:37, liu Jong wrote:
> HI,Marcus,
> thank you for your reply.
> So it is not a simply add zero after the data?Maybe add some "0101" at
> some where.
>
>
> 2017-04-14 17:02 GMT+08:00 Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>>:
>
> Hi John,
>
> there's digital downconversion happening between the ADC's sample
> rate (which coincides with the rate we call Master Clock Rate) and
> your sampling rate, which inherently is a bit-widening operation.
>
> Thus, under sufficient oversampling due to above process, all your
> 16 bits might be significant.
>
> Best regards,
>
> Marcus
>
>
> On 14.04.2017 09:53, john liu via USRP-users wrote:
>> Hi,all,
>> From the datasheet of B210,we know the ADC is 12bit,But the OTW
>> is 16bit(or 12bit),so?there is a conversion process.Is it
>> directly add zero after the data?
>> Thank you.
>>
>> best regards
>> John
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> _______________________________________________ USRP-users mailing
> list [email protected]
> <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/0657dbc1/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 14 Apr 2017 14:10:37 +0000
From: Dan CaJacob <[email protected]>
To: Marcus M?ller <[email protected]>, liu Jong
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ADC of B210
Message-ID:
<CAMOmJOCab45QDpdZpjar-agZNu3XaKTouAifBV2e=gxtey5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
I am deferring to you as the expert on this, but I am surprised as well. I
thought (at least on older Ettus products) that similar 12-bit ADCs truly
did return 12 bits of data and that the extra 4 bits to pad out to 16
could/were used for streaming control of things like GPIO, etc.
- Dan
On Fri, Apr 14, 2017 at 7:05 AM Marcus M?ller via USRP-users <
[email protected]> wrote:
> Hi John,
>
>
> So it is not a simply add zero after the data?Maybe add some "0101" at
> some where.
>
> No! It's more complicated than that.
>
> Imagine the samples coming from the ADC entering a FIR filter.
>
> In that FIR filter, they get multiplied with fixed-point filter
> coefficients, so the resulting products have more "valid" bits than the ADC
> samples have.
>
> These filter states get added up to the FIR output ? which thus has more
> bits than the products.
>
> There's multiple digital filters in the B210's DSP chain.
>
> The output of the filters is rounded to the most significant 16 bit.
>
> So, there's no "padding" in the sense of "adding some constant bits to the
> end" anywhere, here, unless you chose the case of MCR=sampling rate.
>
> Best regards,
>
> Marcus
>
> On 14.04.2017 11:37, liu Jong wrote:
>
> HI,Marcus,
> thank you for your reply.
> So it is not a simply add zero after the data?Maybe add some "0101" at
> some where.
>
>
> 2017-04-14 17:02 GMT+08:00 Marcus M?ller via USRP-users <
> [email protected]>:
>
>> Hi John,
>>
>> there's digital downconversion happening between the ADC's sample rate
>> (which coincides with the rate we call Master Clock Rate) and your sampling
>> rate, which inherently is a bit-widening operation.
>>
>> Thus, under sufficient oversampling due to above process, all your 16
>> bits might be significant.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 14.04.2017 09:53, john liu via USRP-users wrote:
>>
>> Hi,all,
>> From the datasheet of B210,we know the ADC is 12bit,But the OTW is
>> 16bit(or 12bit),so there is a conversion process.Is it directly add zero
>> after the data?
>> Thank you.
>>
>> best regards
>> John
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________ USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Very Respectfully,
Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/83e80ff5/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 14 Apr 2017 11:01:37 -0400
From: Jason Matusiak <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP-users] Using Chipscope on the E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Jonathon,
I made some changes and then was unable to get chipscope to work
again... I am not sure how I stumbled upon it using your "cat" command
before, but obviously I need to do something in a particular order.
So what do you think the process is?:
*Boot up E310,
*connect to E310 via JTAG's "open target" option
*run cat e310 > /dev/xdevcfg
*click refresh in the chipscope debug menu to get the marked debug nets
to appear
Those are the steps that seem logical to me, but obviously I am missing
something. Are you able to spot what?
On 04/13/2017 02:11 PM, Jonathon Pendlum wrote:
> Are you using radio_clk as the clock for your chipscope ILA?
>
> On Thu, Apr 13, 2017 at 10:56 AM, Jason Matusiak
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> hmmmmm. I ran that and then did a probe and then a refresh in
> chipscope, but nothing happened.
>
> I will say that the prompt returned VERY quickly after running the
> cat command, I thought it would take longer...
>
>
> On 04/13/2017 01:25 PM, Jonathon Pendlum wrote:
>> Hi Jason,
>>
>> Try loading the image manually using "cat bitstream.bit >
>> /dev/xdevcfg"
>>
>>
>>
>> Jonathon
>>
>> On Thu, Apr 13, 2017 at 9:33 AM, Jason Matusiak
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Jonathon (or Philip),
>> How can I do this debugging from within chipscope? I am just
>> doing some free-running testing (ie I am not using GNURadio
>> or a binary to run signals through the system) on the system
>> clocks and had no issues with the X310. Now I created a new
>> bitfile with my chipscope stuff included, but I can't seem to
>> get it to work from within Chipscope.
>>
>> When working with the X310, I would connect to the unit from
>> Chipscope, download the new image, run uhd_usrp_probe to get
>> the clocks running, and then refresh the device from within
>> Chipscope to get it ready for my captures.
>>
>> I can connect via JTAG to the E310, but if I try to download
>> the new image, I get the shutdown that Philip mentioned
>> further up in this chain.
>>
>>
>> >Hi Ed,
>> >
>> >An approach I use when running chipscope is to specify the
>> bitstream I want
>> >to use with --args="fpga=<path to my bitstream>" and to set
>> a breakpoint
>> >(via gdb) before the recv call in benchmark_rate or other
>> utility app I am
>> >using. The breakpoint is useful because radio_clk is not
>> running until the
>> >AD9361 has been setup. In many cases your chipscope instance
>> will be
>> >probing nets using radio_clk and without that clock running
>> Vivado won't be
>> >able to find the ILA.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/30135bac/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 14 Apr 2017 08:28:08 -0700
From: Jonathon Pendlum <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP-users] Using Chipscope on the E310
Message-ID:
<cagdo0uqfam8zokuvsy_ohdi7q1oqpkl8afvh2uwjo+0q9ay...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Try decreasing the JTAG clock rate in chipscope. Depending on the quality
of your cabling and adapter, the default value might be too high
On Apr 14, 2017 8:02 AM, "Jason Matusiak" <[email protected]>
wrote:
> Jonathon,
>
> I made some changes and then was unable to get chipscope to work again...
> I am not sure how I stumbled upon it using your "cat" command before, but
> obviously I need to do something in a particular order.
>
> So what do you think the process is?:
> *Boot up E310,
> *connect to E310 via JTAG's "open target" option
> *run cat e310 > /dev/xdevcfg
> *click refresh in the chipscope debug menu to get the marked debug nets to
> appear
>
> Those are the steps that seem logical to me, but obviously I am missing
> something. Are you able to spot what?
>
>
> On 04/13/2017 02:11 PM, Jonathon Pendlum wrote:
>
> Are you using radio_clk as the clock for your chipscope ILA?
>
> On Thu, Apr 13, 2017 at 10:56 AM, Jason Matusiak <
> [email protected]> wrote:
>
>> hmmmmm. I ran that and then did a probe and then a refresh in chipscope,
>> but nothing happened.
>>
>> I will say that the prompt returned VERY quickly after running the cat
>> command, I thought it would take longer...
>>
>>
>> On 04/13/2017 01:25 PM, Jonathon Pendlum wrote:
>>
>> Hi Jason,
>>
>> Try loading the image manually using "cat bitstream.bit > /dev/xdevcfg"
>>
>>
>>
>> Jonathon
>>
>> On Thu, Apr 13, 2017 at 9:33 AM, Jason Matusiak <
>> [email protected]> wrote:
>>
>>> Jonathon (or Philip),
>>> How can I do this debugging from within chipscope? I am just doing some
>>> free-running testing (ie I am not using GNURadio or a binary to run signals
>>> through the system) on the system clocks and had no issues with the X310.
>>> Now I created a new bitfile with my chipscope stuff included, but I can't
>>> seem to get it to work from within Chipscope.
>>>
>>> When working with the X310, I would connect to the unit from Chipscope,
>>> download the new image, run uhd_usrp_probe to get the clocks running, and
>>> then refresh the device from within Chipscope to get it ready for my
>>> captures.
>>>
>>> I can connect via JTAG to the E310, but if I try to download the new
>>> image, I get the shutdown that Philip mentioned further up in this chain.
>>>
>>>
>>> >Hi Ed,
>>> >
>>> >An approach I use when running chipscope is to specify the bitstream I
>>> want
>>> >to use with --args="fpga=<path to my bitstream>" and to set a breakpoint
>>> >(via gdb) before the recv call in benchmark_rate or other utility app I
>>> am
>>> >using. The breakpoint is useful because radio_clk is not running until
>>> the
>>> >AD9361 has been setup. In many cases your chipscope instance will be
>>> >probing nets using radio_clk and without that clock running Vivado
>>> won't be
>>> >able to find the ILA.
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/5739c975/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 14 Apr 2017 11:30:59 -0400
From: Jason Matusiak <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP-users] Using Chipscope on the E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Unfortunately I tried that, I had taken it down to the lowest speed
(750k) with still no luck. What is frustrating is that I got it to work
once yesterday, so /somehow/ this is doable in my current setup....
On 04/14/2017 11:28 AM, Jonathon Pendlum wrote:
> Try decreasing the JTAG clock rate in chipscope. Depending on the
> quality of your cabling and adapter, the default value might be too high
>
> On Apr 14, 2017 8:02 AM, "Jason Matusiak"
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Jonathon,
>
> I made some changes and then was unable to get chipscope to work
> again... I am not sure how I stumbled upon it using your "cat"
> command before, but obviously I need to do something in a
> particular order.
>
> So what do you think the process is?:
> *Boot up E310,
> *connect to E310 via JTAG's "open target" option
> *run cat e310 > /dev/xdevcfg
> *click refresh in the chipscope debug menu to get the marked debug
> nets to appear
>
> Those are the steps that seem logical to me, but obviously I am
> missing something. Are you able to spot what?
>
>
> On 04/13/2017 02:11 PM, Jonathon Pendlum wrote:
>> Are you using radio_clk as the clock for your chipscope ILA?
>>
>> On Thu, Apr 13, 2017 at 10:56 AM, Jason Matusiak
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> hmmmmm. I ran that and then did a probe and then a refresh
>> in chipscope, but nothing happened.
>>
>> I will say that the prompt returned VERY quickly after
>> running the cat command, I thought it would take longer...
>>
>>
>> On 04/13/2017 01:25 PM, Jonathon Pendlum wrote:
>>> Hi Jason,
>>>
>>> Try loading the image manually using "cat bitstream.bit >
>>> /dev/xdevcfg"
>>>
>>>
>>>
>>> Jonathon
>>>
>>> On Thu, Apr 13, 2017 at 9:33 AM, Jason Matusiak
>>> <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Jonathon (or Philip),
>>> How can I do this debugging from within chipscope? I am
>>> just doing some free-running testing (ie I am not using
>>> GNURadio or a binary to run signals through the system)
>>> on the system clocks and had no issues with the X310.
>>> Now I created a new bitfile with my chipscope stuff
>>> included, but I can't seem to get it to work from within
>>> Chipscope.
>>>
>>> When working with the X310, I would connect to the unit
>>> from Chipscope, download the new image, run
>>> uhd_usrp_probe to get the clocks running, and then
>>> refresh the device from within Chipscope to get it ready
>>> for my captures.
>>>
>>> I can connect via JTAG to the E310, but if I try to
>>> download the new image, I get the shutdown that Philip
>>> mentioned further up in this chain.
>>>
>>>
>>> >Hi Ed,
>>> >
>>> >An approach I use when running chipscope is to specify
>>> the bitstream I want
>>> >to use with --args="fpga=<path to my bitstream>" and to
>>> set a breakpoint
>>> >(via gdb) before the recv call in benchmark_rate or
>>> other utility app I am
>>> >using. The breakpoint is useful because radio_clk is
>>> not running until the
>>> >AD9361 has been setup. In many cases your chipscope
>>> instance will be
>>> >probing nets using radio_clk and without that clock
>>> running Vivado won't be
>>> >able to find the ILA.
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/dec66d18/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 80, Issue 14
******************************************
