Re: [USRP-users] X310 calibration with WBX

[Nick Foster via USRP-users]

Following up on this, I have an additional question: is there any plan to
expose the DC offset and IQ balance API through device3? Currently it
appears as though the legacy interface can make use of these functions to
manually set IQ balance and DC offset, while device3-based programs (i.e.,
anything using RFNoC) cannot. Am I correct in this?

Nick

On Thu, Jun 28, 2018 at 6:22 PM Nick Foster  wrote:

> Hi all,
>
> I haven't looked at daughterboard calibration in a long time, and picking
> it up, it sure looks broken to me. I'm using X310 + WBX on rfnoc-devel as
> of March. Let's assume for the moment I'm running a stock FPGA image -- I'm
> not, but for testing I replicated the same results on the stock image.
>
> I ran TX DC offset cal as follows:
> uhd_cal_tx_dc_offset --args=addr=192.168.10.2 --freq_start=70e6
> --freq_stop=150e6 --freq_step=1e6
>
> And I ran TX IQ imbalance cal as follows:
> uhd_cal_tx_iq_balance --args=addr=192.168.10.2 --freq_start=70e6
> --freq_stop=150e6 --freq_step=1e6
>
> Both DC offset and IQ imbalance are significantly worse after running
> calibration. DC offset is 30dB higher and IQ imbalance is 27dB worse.
>
> I also tried default parameters in case the frequency step is sensitive to
> the TX offset setting, with no change (it actually got somewhat worse...).
>
> Is there anything I should know about the calibration utilities which
> prevents them from being used on relatively recent UHD releases? Did
> someone cross up the I and Q channels in the correction registers?
>
> Nick
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC On B210

[Robin Coxe via USRP-users]

Hi Dan.  Such a product is in the works.  It was mentioned in Manuel Uhm's
presentation at GRCon 2017-- the USRP E320.
Single board approximately the size of a B210, AD9361, RFNoC-capable with
larger Zynq FPGA than E310 (XC7Z045).

Ettus Research intends to demo the E320 at GRCon 2018, so sign up today
(early bird registration ends tomorrow)!
https://www.eventbrite.com/e/gnu-radio-conference-2018-tickets-42793672025

-Robin



On Fri, Jun 29, 2018 at 11:40 AM, Dan CaJacob via USRP-users <
usrp-users@lists.ettus.com> wrote:

> What I meant and didn't explain well enough is a potential new Ettus
> product would be a Zynq-based B2X0 clone. That would be RFNOC-capable.
>
> On Fri, Jun 29, 2018 at 2:32 PM Ian Buckley via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Er no.
>>
>> B200 has approximately the same number of FPGA logic gates as E310, B210
>> twice that amount.
>> The current design is simply larger than it needs to be because it shares
>> all it’s code with X300, I could have made it much smaller had there been a
>> good reason to.
>>
>> The FPGA was simply chosen because it was the biggest and newest
>> available when that project was begun.
>> The Vivado/ISE split wasn’t customer visible at that point in time,
>> remember X300 was also ISE based at initial release.
>>
>> It remains a potent platform for capable FPGA designers to do custom
>> stuff on, just not RFNoC.
>> -Ian
>>
>>
>> > On Jun 29, 2018, at 1:35 AM, Marcus Müller 
>> wrote:
>> >
>> > To give an uplifting spin to all this:
>> >
>> > Now, also, although larger than the one on the B200, the B210's FPGA
>> > isn't really large unoccupied, so the amount of logic that you could
>> > even hypothetically put in there is limited. Why's that uplifiting?
>> >
>> > That FPGA was chosen for the board because there's usually little need
>> > to do anything but the hardware interfacing and the DDC/DUC in the
>> > FPGA. The B210 can, with good USB3 controllers, pretty much directly
>> > hand through its analog bandwidth to a computer. So, unless you have a
>> > workload that your PC including GPU and whatnot can't achieve, you
>> > don't even have to think about implementing things on the B210's FPGA –
>> > and frankly, I've got no idea what'd be easy to do on the free space of
>> > a B210 but impossible on a high-end PC. And a high-end PC is still
>> > cheaper than a ISE14 license.
>> >
>> > Only thing that comes into mind is the latency restrictions you incur
>> > with USB; that's really something that no amount of computing power on
>> > the host computer side could solve.
>> >
>> > So, maybe, if I can encourage you to discuss your specific application,
>> > we can find a sensible solution on what to put on the SDR peripheral
>> > device itself, and what to do on your PC?
>> >
>> > Best regards,
>> > Marcus
>> >
>> > On Thu, 2018-06-28 at 15:56 -0700, Peter Sanchez via USRP-users wrote:
>> >> Thank you
>> >>
>> >> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley 
>> >> wrote:
>> >>> There is no conceptual reason why you can’t build an RFNoC design
>> >>> on B210, it uses the same USRP3 base architecture and FPGA source
>> >>> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all
>> >>> the implementation work for RFNoC is done using Xilinx’s Vivado
>> >>> design tools which support only the newer FPGA architectures like
>> >>> Zynq (Artix) and Kintex…Spartan6 users are stuck with ISE14
>> >>> forever, so in practical terms, no, it’s not possible without you
>> >>> completely recreating all that infrastructure.
>> >>>
>> >>> -Ian
>> >>>
>>  On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users > >>> s...@lists.ettus.com> wrote:
>> 
>>  Hi All,
>>  Is it possible to generate RFNoC blocks for the B210? I can't
>> >>> find a lot of information about it. Can some one show me the URL if
>> >>> there  is a website talking about it?
>> 
>>  Cheers
>>  ___
>>  USRP-users mailing list
>>  USRP-users@lists.ettus.com
>>  http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co
>> >>> m
>> >>>
>> >>
>> >> ___
>> >> USRP-users mailing list
>> >> USRP-users@lists.ettus.com
>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC On B210

[Dan CaJacob via USRP-users]

What I meant and didn't explain well enough is a potential new Ettus
product would be a Zynq-based B2X0 clone. That would be RFNOC-capable.

On Fri, Jun 29, 2018 at 2:32 PM Ian Buckley via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Er no.
>
> B200 has approximately the same number of FPGA logic gates as E310, B210
> twice that amount.
> The current design is simply larger than it needs to be because it shares
> all it’s code with X300, I could have made it much smaller had there been a
> good reason to.
>
> The FPGA was simply chosen because it was the biggest and newest available
> when that project was begun.
> The Vivado/ISE split wasn’t customer visible at that point in time,
> remember X300 was also ISE based at initial release.
>
> It remains a potent platform for capable FPGA designers to do custom stuff
> on, just not RFNoC.
> -Ian
>
>
> > On Jun 29, 2018, at 1:35 AM, Marcus Müller 
> wrote:
> >
> > To give an uplifting spin to all this:
> >
> > Now, also, although larger than the one on the B200, the B210's FPGA
> > isn't really large unoccupied, so the amount of logic that you could
> > even hypothetically put in there is limited. Why's that uplifiting?
> >
> > That FPGA was chosen for the board because there's usually little need
> > to do anything but the hardware interfacing and the DDC/DUC in the
> > FPGA. The B210 can, with good USB3 controllers, pretty much directly
> > hand through its analog bandwidth to a computer. So, unless you have a
> > workload that your PC including GPU and whatnot can't achieve, you
> > don't even have to think about implementing things on the B210's FPGA –
> > and frankly, I've got no idea what'd be easy to do on the free space of
> > a B210 but impossible on a high-end PC. And a high-end PC is still
> > cheaper than a ISE14 license.
> >
> > Only thing that comes into mind is the latency restrictions you incur
> > with USB; that's really something that no amount of computing power on
> > the host computer side could solve.
> >
> > So, maybe, if I can encourage you to discuss your specific application,
> > we can find a sensible solution on what to put on the SDR peripheral
> > device itself, and what to do on your PC?
> >
> > Best regards,
> > Marcus
> >
> > On Thu, 2018-06-28 at 15:56 -0700, Peter Sanchez via USRP-users wrote:
> >> Thank you
> >>
> >> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley 
> >> wrote:
> >>> There is no conceptual reason why you can’t build an RFNoC design
> >>> on B210, it uses the same USRP3 base architecture and FPGA source
> >>> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all
> >>> the implementation work for RFNoC is done using Xilinx’s Vivado
> >>> design tools which support only the newer FPGA architectures like
> >>> Zynq (Artix) and Kintex…Spartan6 users are stuck with ISE14
> >>> forever, so in practical terms, no, it’s not possible without you
> >>> completely recreating all that infrastructure.
> >>>
> >>> -Ian
> >>>
>  On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users  >>> s...@lists.ettus.com> wrote:
> 
>  Hi All,
>  Is it possible to generate RFNoC blocks for the B210? I can't
> >>> find a lot of information about it. Can some one show me the URL if
> >>> there  is a website talking about it?
> 
>  Cheers
>  ___
>  USRP-users mailing list
>  USRP-users@lists.ettus.com
>  http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co
> >>> m
> >>>
> >>
> >> ___
> >> USRP-users mailing list
> >> USRP-users@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Very Respectfully,

Dan CaJacob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC On B210

[Ian Buckley via USRP-users]

Er no.

B200 has approximately the same number of FPGA logic gates as E310, B210 twice 
that amount.
The current design is simply larger than it needs to be because it shares all 
it’s code with X300, I could have made it much smaller had there been a good 
reason to.

The FPGA was simply chosen because it was the biggest and newest available when 
that project was begun.
The Vivado/ISE split wasn’t customer visible at that point in time, remember 
X300 was also ISE based at initial release.

It remains a potent platform for capable FPGA designers to do custom stuff on, 
just not RFNoC.
-Ian


> On Jun 29, 2018, at 1:35 AM, Marcus Müller  wrote:
> 
> To give an uplifting spin to all this:
> 
> Now, also, although larger than the one on the B200, the B210's FPGA
> isn't really large unoccupied, so the amount of logic that you could
> even hypothetically put in there is limited. Why's that uplifiting?
> 
> That FPGA was chosen for the board because there's usually little need
> to do anything but the hardware interfacing and the DDC/DUC in the
> FPGA. The B210 can, with good USB3 controllers, pretty much directly
> hand through its analog bandwidth to a computer. So, unless you have a
> workload that your PC including GPU and whatnot can't achieve, you
> don't even have to think about implementing things on the B210's FPGA –
> and frankly, I've got no idea what'd be easy to do on the free space of
> a B210 but impossible on a high-end PC. And a high-end PC is still
> cheaper than a ISE14 license.
> 
> Only thing that comes into mind is the latency restrictions you incur
> with USB; that's really something that no amount of computing power on
> the host computer side could solve. 
> 
> So, maybe, if I can encourage you to discuss your specific application,
> we can find a sensible solution on what to put on the SDR peripheral
> device itself, and what to do on your PC?
> 
> Best regards,
> Marcus
> 
> On Thu, 2018-06-28 at 15:56 -0700, Peter Sanchez via USRP-users wrote:
>> Thank you
>> 
>> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley 
>> wrote:
>>> There is no conceptual reason why you can’t build an RFNoC design
>>> on B210, it uses the same USRP3 base architecture and FPGA source
>>> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all
>>> the implementation work for RFNoC is done using Xilinx’s Vivado
>>> design tools which support only the newer FPGA architectures like
>>> Zynq (Artix) and Kintex…Spartan6 users are stuck with ISE14
>>> forever, so in practical terms, no, it’s not possible without you
>>> completely recreating all that infrastructure.
>>> 
>>> -Ian
>>> 
 On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users >> s...@lists.ettus.com> wrote:
 
 Hi All,
 Is it possible to generate RFNoC blocks for the B210? I can't
>>> find a lot of information about it. Can some one show me the URL if
>>> there  is a website talking about it?
 
 Cheers
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co
>>> m
>>> 
>> 
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Synchronizing multiple B205 mini radios

[Chintan Patel via USRP-users]

Ian,

It turns out the B210s were not phase aligned  (contrary to my earlier
report)- we had not done our measurements correctly. So, need to get the
MCS proof-of-concept working on two B210s i.e. just prove on the scope that
the baseband RX sample clocks are indeed aligned. Currently we call a uhd
FFT function to initialize/tune the AD9361 and check the RX sample clocks
coming to the FPGA on the scope (obviously any UHD function that configures
the AD9361 to recv samples will suffice for our setup).

Coming to the MCS changes, I understand the FPGA piece of it (driving the
sync_in to the AD9361), but needed some hand-holding on finding the minimum
and easiest path for the MCS software/firmware. Conceptually I understand
the change needed - need to add the  ad9361_multipchip_sync function
provided in the IIO Library (libad9361-iio), but not sure how to go about
it. (I have not rebuilt UHD source code before). I am specifically looking
for details on which source files will I need to change and which files
will I have to rebuild if I want to make sure that when the UHD FFT or UHD
stream samples type function is sent from the host, the MCS function is
called underneath. Once again, I am trying to keep the software footprint
of this effort to bare minimum.

 Any pointers will be much appreciated.

Thanks
Chintan


On Wed, Jun 27, 2018 at 10:28 AM, Chintan Patel  wrote:

> Ian,
>
> We are using multiple B210 radios. We are monitoring two PPS signal (one
> per radio) reclocked in the radio/sample clk domain on the scope. So
> essentially, we are indirectly monitoring the radio clk/sample clk from two
> different B210s, which always seem phase aligned over multiple reboots.
>
> But given everything I now know about MCS, I am beginning to doubt the
> measurements and will repeat.
>
> Thanks
> Chintan
>
>
> On Tue, Jun 26, 2018 at 2:09 PM, Ian Buckley  wrote:
>
>> Chintan,
>> When you refer to lab trial’s with B210…I’m assuming you were using
>> multiple B210’s rather than demonstrating coherence of the 2 channels on a
>> singe B210?
>> How were you verifying that the sample clocks were aligned? Can you share
>> your rough configuration?
>> If you are using a common PPS to sync time on multiple REF locked B210’s
>> then the FPGA’s will be operating coherently with the caveat that they are
>> clocked with the divided BBPLL clock (a.k.a master_clock_rate). If you are
>> running master_clock_rate at a relatively high value and doing significant
>> decimation to the ultimate sample_rate on B210, then a residual phase
>> ambiguity on the BBPLL might start to be hard to observe just looking at
>> output samples.
>> -Ian
>>
>> On Jun 26, 2018, at 2:42 AM, Chintan Patel  wrote:
>>
>> Hi Ian, Robin, Marcus
>>
>> Thanks a lot for your help so far. Three more questions/clarifications:
>>
>> 1. For the B205 Multi-chip sync (MCS), we are trying to achieve, we are
>> actually providing an external stable 40MHz clock common to both B205s.
>> i.e. we have re-worked the boards so that the DPLL is not being used at all
>> to drive the CLK_40MHz_FPGA to the FPGA input - instead a shared
>> very-stable 40MHz clock input it.
>>
>> 2. Sounds like along with this, the sync_in pin into the AD9364/9361
>> needs to be driven correctly to both B2xx radios. I see that for the
>> B205mini this pin is grounded, while the B210 it goes to the FPGA - which
>> would explain the MCS capability of the B210. What confuses me, is that the
>> stock FPGA image for B210 drives the sync_in input to 0. So, I don't
>> understand why we see phase aligned  sample clocks on the B210 in our lab
>> trials. I think the FPGA changes Ian refers to that he needed to make MCS
>> work for B210 must be related to driving this sync_in pin - but we are just
>> using the stock FPGA image, so scratching my head on that one.
>>
>> 3. Lastly, seems like there is a software routine to be called too, for
>> the AD936 MCS. ( ad9361_multichip_sync.c
>> 
>>  per https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5
>> -ebz/multi-chip-sync). Theoretically, if one is able to rework the
>> B205mini so that the sync_in pin goes to the FPGA (not practical I know), I
>> assume there will be a similar routine needed for ad9364_multichip_sync.
>>
>> Thanks again for your continued guidance.
>>
>> Chintan
>>
>>
>>
>> On Tue, Jun 26, 2018 at 12:31 AM, Ian Buckley via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Robin,
>>> that ADI support thread is not applicable to B2x0, it’s for AD9361
>>> external LO mode which isn’t used by Ettus products.
>>>
>>> In internal LO mode there is always a phase ambiguity in the RF
>>> synthesizers that requires higher level S/W to calibrate and correct for.
>>> The baseband synthesizer can be made phase coherent between multiple
>>> AD936x’s if you use the MCS mechanism, however that’s not included in the
>>> factory FPGA image, (though I have 

Re: [USRP-users] RFNoC On B210

[Dan CaJacob via USRP-users]

I think what would be more useful is a low-end USRP (low price like B200)
that is RFNOC-capable. I guess that might be something like an E310 in a
white case?

On Fri, Jun 29, 2018 at 9:12 AM GhostOp14 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I second RFNoC for the B series would be great.  They're an incredibly
> popular and affordable series and I feel a little left out of the
> capabilities of RFNoC due to the Spartan6.  Bringing the Artix to the
> B-series or supporting the Spartan6 could both be options I'd love to see.
> (Just a community vote :) )
>
> On Thu, Jun 28, 2018 at 6:56 PM, Peter Sanchez via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Thank you
>>
>> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley 
>> wrote:
>>
>>> There is no conceptual reason why you can’t build an RFNoC design on
>>> B210, it uses the same USRP3 base architecture and FPGA source
>>> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all the
>>> implementation work for RFNoC is done using Xilinx’s Vivado design tools
>>> which support only the newer FPGA architectures like Zynq (Artix) and
>>> Kintex…Spartan6 users are stuck with ISE14 forever, so in practical terms,
>>> no, it’s not possible without you completely recreating all that
>>> infrastructure.
>>>
>>> -Ian
>>>
>>> > On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>> >
>>> > Hi All,
>>> > Is it possible to generate RFNoC blocks for the B210? I can't find a
>>> lot of information about it. Can some one show me the URL if there  is a
>>> website talking about it?
>>> >
>>> > Cheers
>>> > ___
>>> > USRP-users mailing list
>>> > USRP-users@lists.ettus.com
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Very Respectfully,

Dan CaJacob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Add AXI Uartlite to E310 FPGA

[Gorur, Anisha - 0662 - MITLL via USRP-users]

Hi,
I'm trying to add an AXI Uartlite 
(https://www.xilinx.com/support/documentation/ip_documentation/axi_uartlite/v2_0/pg142-axi-uartlite.pdf)
 module to the E310 and will be using two GPIO pins for the serial TX/RX. I've 
added the IP to e310.v, and hooked it up to twp GPIO pins and the AXI 
Interconnect, and the project seems to build fine.  
The problem is that there is no block diagram for the E310 FPGA project, so I'm 
not sure where to assign the base address for the AXI Uartlite. If there were a 
block diagram, there is a tab where you can assign the address, and then that 
address is what goes into the device tree. Is there somewhere else I can assign 
the address? Or is it automatically assigned and I've missed it somewhere?
Thanks,
Anisha


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

[Brian Padalino via USRP-users]

On Fri, Jun 29, 2018 at 9:57 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> I missed that, thanks for the heads up.  I replaced the
> two chdr_deframer_2clk functions with the old chdr_deframer, but that
> didn't seem to fix things for me.  Guess I will have to do a deep dive into
> the block with chipscope and try to see how things flow.  My gut is really
> telling me it has something to do with how the block is setup at start-up
> time and the changes that occurred, I just am not sure what changes to
> clear_tx_seqnum would cause these issues.
>

If you're working with the 2017.4 stuff, you'll want to use the new
chdr_deframer_2clk and ditch all the old stuff.


>
> Did you end up having to modify the axi_wrapper to get your stuff back to
> working temporarily?
>

I was able to start communicating with my block via register accesses by
just adding the bus_clk and bus_rst to the instantiation of the
axi_wrapper.  It was only after some weird digging that I noticed the
clear_tx_seqnum wasn't acting like it used to be.

Now, if you're working off the latest rfnoc-devel as of today, I believe
all you need to do to port from a 2015.4 to 2017.4 design is:

  - add bus_clk and bus_rst to the axi_wrapper instantiation if you use it
  - use the chdr_framer_2clk/chdr_deframer_2clk versions instead since CHDR
operations changed clock domains

If you can't run uhd_usrp_probe and see your block listed after just adding
the bus_clk/bus_rst to axi_wrapper, then something else beyond what I've
had to debug is probably happening.

Hope this helps.

Brian

>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

[Jason Matusiak via USRP-users]

I missed that, thanks for the heads up.  I replaced the two chdr_deframer_2clk 
functions with the old chdr_deframer, but that didn't seem to fix things for 
me.  Guess I will have to do a deep dive into the block with chipscope and try 
to see how things flow.  My gut is really telling me it has something to do 
with how the block is setup at start-up time and the changes that occurred, I 
just am not sure what changes to clear_tx_seqnum would cause these issues. 
 
Did you end up having to modify the axi_wrapper to get your stuff back to 
working temporarily?
 
- Original Message - Subject: Re: [USRP-users] RFNoC FPGA 
clear_tx_seqnum behavior
From: "Brian Padalino" 
Date: 6/28/18 3:35 pm
Cc: "USRP-users@lists.ettus.com" 

 Hey Jason, 
  On Thu, Jun 28, 2018 at 3:31 PM Jason Matusiak via USRP-users 
 wrote:
  I know this is an older thread, but I too am struggling to bring a block that 
someone else designed for us in 2015.4 to work in 2017.4. I dug around but I 
don't see any of our custom blocks using clear_tx_seqnum in their sub-modules 
or their config registers. They do use the config registers quite a bit to set 
things up, so I am thinking that it might be related to this.

Is there a list of other changes that might have happened in RFNoC so I can 
comb through it? I am guessing I am getting tripped up on something like this, 
but it would help to narrow down the places to look. 
  
There was an addition of bus_clk and bus_rst to the axi_wrapper that is a major 
change as well between 2015.4 and 2017.4.
 
Did you catch that one?
 
Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC On B210

[GhostOp14 via USRP-users]

I second RFNoC for the B series would be great.  They're an incredibly
popular and affordable series and I feel a little left out of the
capabilities of RFNoC due to the Spartan6.  Bringing the Artix to the
B-series or supporting the Spartan6 could both be options I'd love to see.
(Just a community vote :) )

On Thu, Jun 28, 2018 at 6:56 PM, Peter Sanchez via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thank you
>
> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley  wrote:
>
>> There is no conceptual reason why you can’t build an RFNoC design on
>> B210, it uses the same USRP3 base architecture and FPGA source
>> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all the
>> implementation work for RFNoC is done using Xilinx’s Vivado design tools
>> which support only the newer FPGA architectures like Zynq (Artix) and
>> Kintex…Spartan6 users are stuck with ISE14 forever, so in practical terms,
>> no, it’s not possible without you completely recreating all that
>> infrastructure.
>>
>> -Ian
>>
>> > On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> >
>> > Hi All,
>> > Is it possible to generate RFNoC blocks for the B210? I can't find a
>> lot of information about it. Can some one show me the URL if there  is a
>> website talking about it?
>> >
>> > Cheers
>> > ___
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC On B210

[Marcus Müller via USRP-users]

To give an uplifting spin to all this:

Now, also, although larger than the one on the B200, the B210's FPGA
isn't really large unoccupied, so the amount of logic that you could
even hypothetically put in there is limited. Why's that uplifiting?

That FPGA was chosen for the board because there's usually little need
to do anything but the hardware interfacing and the DDC/DUC in the
FPGA. The B210 can, with good USB3 controllers, pretty much directly
hand through its analog bandwidth to a computer. So, unless you have a
workload that your PC including GPU and whatnot can't achieve, you
don't even have to think about implementing things on the B210's FPGA –
and frankly, I've got no idea what'd be easy to do on the free space of
a B210 but impossible on a high-end PC. And a high-end PC is still
cheaper than a ISE14 license.

Only thing that comes into mind is the latency restrictions you incur
with USB; that's really something that no amount of computing power on
the host computer side could solve. 

So, maybe, if I can encourage you to discuss your specific application,
we can find a sensible solution on what to put on the SDR peripheral
device itself, and what to do on your PC?

Best regards,
Marcus

On Thu, 2018-06-28 at 15:56 -0700, Peter Sanchez via USRP-users wrote:
> Thank you
> 
> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley 
> wrote:
> > There is no conceptual reason why you can’t build an RFNoC design
> > on B210, it uses the same USRP3 base architecture and FPGA source
> > files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all
> > the implementation work for RFNoC is done using Xilinx’s Vivado
> > design tools which support only the newer FPGA architectures like
> > Zynq (Artix) and Kintex…Spartan6 users are stuck with ISE14
> > forever, so in practical terms, no, it’s not possible without you
> > completely recreating all that infrastructure.
> > 
> > -Ian
> > 
> > > On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users  > s...@lists.ettus.com> wrote:
> > > 
> > > Hi All,
> > > Is it possible to generate RFNoC blocks for the B210? I can't
> > find a lot of information about it. Can some one show me the URL if
> > there  is a website talking about it?
> > > 
> > > Cheers
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co
> > m
> > 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B 200mini RX2 SMA

[Marcus Müller via USRP-users]

Dear Brad,

wiggle-ability and subsequent change of properties point to a hardware
defect.

Can you please contact supp...@ettus.com with your device's serial
number, if you have, your NI invoice number, and if possible, a closeup
photo of the soldering or the plug, whatever seems wiggly?

Thanks!
Marcus

On Thu, 2018-06-28 at 20:51 -0700, Brad Forker via USRP-users wrote:
>Hello group this is my first time posting has anyone seen the RX 2
> SMA bad or out of spec?  I can wiggle the cable and my NF drops 15db.
> It does not do this on the TRX sma. It also seems strange they didnt
> put a nut on the SMA to hold it to the case. Thanks
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com