Re: [USRP-users] Creating RFNOC block that changes stream rate

[Andrew Danowitz via USRP-users]

Hi all,

Thanks for all of your help. Once I annotated the signals to debug, Vivado
started failing on creating a bitstream. It turns out I had labeled the
wrong direction for the master tready signal which in default synthesis was
driven to 0.

Thanks,
Andrew

On Fri, Dec 21, 2018 at 11:33 AM Andrew Danowitz 
wrote:

> Hi all,
>
> I tried building a control block like the one on github, but still no
> luck. I have a jtag kit on the way, so I'll keep you posted.
>
> Thanks!
> Andrew
>
> On Wed, Dec 19, 2018 at 7:15 PM Jon Pendlum  wrote:
>
>> Hi Andrew,
>>
>> You'll need to have a Xilinx USB programmer (or Digilent JTAG-HS3
>> probably works too), purchase this kit
>> https://www.ettus.com/product/details/E-JTAG-4, and follow these
>> instructions:
>> https://www.ettus.com/content/files/E-Series_JTAG-AVR_Cable_Getting_Started_Guide_.pdf.
>> For setting up the ILA and debugging, see:
>> https://kb.ettus.com/Debugging_FPGA_images.
>>
>> Jonathon
>>
>> On Thu, Dec 20, 2018 at 7:47 AM Andrew Danowitz <
>> and...@whitefoxdefense.com> wrote:
>>
>>> Hi John,
>>>
>>> Is there any documentation on using the ILA on an e310 that's running
>>> gnuradio directly?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum 
>>> wrote:
>>>
 Hi Andrew,

 Have you tried using Chipscope to see where the issue is at in your
 code? You want to look at the tvalid and tready AXI stream control signals
 to pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0).
 Once you know where the stall is located, I can provide more advice.

 Jonathon

 On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Thanks for the reply. I do set simple_mode and I propagate tuser into
> and out of axi_rate_change the same way noc_block_ddc does. I also have my
> block running properly in Vivado simulation. Is there anything else I
> should check? I also included axi_tag_time. Could that be causing an 
> issue?
>
> Thanks!
> Andrew
>
> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar 
> wrote:
>
>> Hi Andrew,
>>
>> Quick thoughts:
>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>> - Are you propagating tuser into and out of the axi_rate_change block?
>>
>> The axi_rate_change block updates tuser, which the axi_wrapper uses
>> to create output packets when SIMPLE_MODE is disabled.
>>
>> Also, have you run in a simulation testbench? Simulation should be
>> able to expose these issues before targetting hardware to make debugging 
>> a
>> bit easier.
>>
>> EJ
>>
>>
>>
>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to create an rfnoc block that takes in a stream of data
>>> at Sample rate n, does some processing to turn i-q values into real
>>> samples, and outputs data at a rate of n/2 by packing real values into 
>>> both
>>> i and q channels of the output stream. I've tried to incorporate the
>>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>>> whenever I try to run it I keep getting a timeout error. If I take out 
>>> the
>>> channel packing block and keep the rate n-to-n, the module works fine.
>>>
>>> Does anyone have any advice?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> --
>>> Information contained, linked, or attached to this email and all
>>> verbal communications from WhiteFox Defense to your entity in the prior 
>>> 30
>>> days constitute proprietary and confidential information unless 
>>> otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for 
>>> the
>>> use of the individual or entity to whom they are addressed. If you are 
>>> not
>>> the intended recipient and this message has been addressed to you in 
>>> error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all
>>> copies of the message and any attachments. This email and attachments 
>>> may
>>> contain technical data as defined in the International Traffic In Arms
>>> Regulations (ITAR) 22 CFR 120.10 or the Export Administration 
>>> Regulations
>>> (EAR) 15 CFR Parts 730 – 780.  Export of this material may be 
>>> controlled by
>>> these regulations and may not be exported or transferred to non-U.S.
>>> persons without prior written approval from the U.S. government.
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
> 

Re: [USRP-users] Creating RFNOC block that changes stream rate

[Andrew Danowitz via USRP-users]

Hi all,

I tried building a control block like the one on github, but still no luck.
I have a jtag kit on the way, so I'll keep you posted.

Thanks!
Andrew

On Wed, Dec 19, 2018 at 7:15 PM Jon Pendlum  wrote:

> Hi Andrew,
>
> You'll need to have a Xilinx USB programmer (or Digilent JTAG-HS3 probably
> works too), purchase this kit
> https://www.ettus.com/product/details/E-JTAG-4, and follow these
> instructions:
> https://www.ettus.com/content/files/E-Series_JTAG-AVR_Cable_Getting_Started_Guide_.pdf.
> For setting up the ILA and debugging, see:
> https://kb.ettus.com/Debugging_FPGA_images.
>
> Jonathon
>
> On Thu, Dec 20, 2018 at 7:47 AM Andrew Danowitz <
> and...@whitefoxdefense.com> wrote:
>
>> Hi John,
>>
>> Is there any documentation on using the ILA on an e310 that's running
>> gnuradio directly?
>>
>> Thanks,
>> Andrew
>>
>> On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum 
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> Have you tried using Chipscope to see where the issue is at in your
>>> code? You want to look at the tvalid and tready AXI stream control signals
>>> to pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0).
>>> Once you know where the stall is located, I can provide more advice.
>>>
>>> Jonathon
>>>
>>> On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Thanks for the reply. I do set simple_mode and I propagate tuser into
 and out of axi_rate_change the same way noc_block_ddc does. I also have my
 block running properly in Vivado simulation. Is there anything else I
 should check? I also included axi_tag_time. Could that be causing an issue?

 Thanks!
 Andrew

 On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar 
 wrote:

> Hi Andrew,
>
> Quick thoughts:
> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
> - Are you propagating tuser into and out of the axi_rate_change block?
>
> The axi_rate_change block updates tuser, which the axi_wrapper uses to
> create output packets when SIMPLE_MODE is disabled.
>
> Also, have you run in a simulation testbench? Simulation should be
> able to expose these issues before targetting hardware to make debugging a
> bit easier.
>
> EJ
>
>
>
> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm trying to create an rfnoc block that takes in a stream of data at
>> Sample rate n, does some processing to turn i-q values into real samples,
>> and outputs data at a rate of n/2 by packing real values into both i and 
>> q
>> channels of the output stream. I've tried to incorporate the
>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>> whenever I try to run it I keep getting a timeout error. If I take out 
>> the
>> channel packing block and keep the rate n-to-n, the module works fine.
>>
>> Does anyone have any advice?
>>
>> Thanks,
>> Andrew
>>
>> --
>> Information contained, linked, or attached to this email and all
>> verbal communications from WhiteFox Defense to your entity in the prior 
>> 30
>> days constitute proprietary and confidential information unless otherwise
>> indicated and is therefore subject to obligations in any executed
>> confidentiality agreements. Further, this email is intended solely for 
>> the
>> use of the individual or entity to whom they are addressed. If you are 
>> not
>> the intended recipient and this message has been addressed to you in 
>> error,
>> please promptly notify i...@whitefoxdefense.com and destroy all
>> copies of the message and any attachments. This email and attachments may
>> contain technical data as defined in the International Traffic In Arms
>> Regulations (ITAR) 22 CFR 120.10 or the Export Administration Regulations
>> (EAR) 15 CFR Parts 730 – 780.  Export of this material may be controlled 
>> by
>> these regulations and may not be exported or transferred to non-U.S.
>> persons without prior written approval from the U.S. government.
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
 --
 Information contained, linked, or attached to this email and all verbal
 communications from WhiteFox Defense to your entity in the prior 30 days
 constitute proprietary and confidential information unless otherwise
 indicated and is therefore subject to obligations in any executed
 confidentiality agreements. Further, this email is intended solely for the
 use of the individual or entity to whom they are addressed. If you are not
 the intended recipient 

Re: [USRP-users] Creating RFNOC block that changes stream rate

[Jon Pendlum via USRP-users]

Hi Andrew,

You'll need to have a Xilinx USB programmer (or Digilent JTAG-HS3 probably
works too), purchase this kit https://www.ettus.com/product/details/E-JTAG-4,
and follow these instructions:
https://www.ettus.com/content/files/E-Series_JTAG-AVR_Cable_Getting_Started_Guide_.pdf.
For setting up the ILA and debugging, see:
https://kb.ettus.com/Debugging_FPGA_images.

Jonathon

On Thu, Dec 20, 2018 at 7:47 AM Andrew Danowitz 
wrote:

> Hi John,
>
> Is there any documentation on using the ILA on an e310 that's running
> gnuradio directly?
>
> Thanks,
> Andrew
>
> On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum  wrote:
>
>> Hi Andrew,
>>
>> Have you tried using Chipscope to see where the issue is at in your code?
>> You want to look at the tvalid and tready AXI stream control signals to
>> pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once
>> you know where the stall is located, I can provide more advice.
>>
>> Jonathon
>>
>> On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Thanks for the reply. I do set simple_mode and I propagate tuser into
>>> and out of axi_rate_change the same way noc_block_ddc does. I also have my
>>> block running properly in Vivado simulation. Is there anything else I
>>> should check? I also included axi_tag_time. Could that be causing an issue?
>>>
>>> Thanks!
>>> Andrew
>>>
>>> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>>>
 Hi Andrew,

 Quick thoughts:
 - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
 - Are you propagating tuser into and out of the axi_rate_change block?

 The axi_rate_change block updates tuser, which the axi_wrapper uses to
 create output packets when SIMPLE_MODE is disabled.

 Also, have you run in a simulation testbench? Simulation should be able
 to expose these issues before targetting hardware to make debugging a bit
 easier.

 EJ



 On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to create an rfnoc block that takes in a stream of data at
> Sample rate n, does some processing to turn i-q values into real samples,
> and outputs data at a rate of n/2 by packing real values into both i and q
> channels of the output stream. I've tried to incorporate the
> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
> whenever I try to run it I keep getting a timeout error. If I take out the
> channel packing block and keep the rate n-to-n, the module works fine.
>
> Does anyone have any advice?
>
> Thanks,
> Andrew
>
> --
> Information contained, linked, or attached to this email and all
> verbal communications from WhiteFox Defense to your entity in the prior 30
> days constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in 
> error,
> please promptly notify i...@whitefoxdefense.com and destroy all
> copies of the message and any attachments. This email and attachments may
> contain technical data as defined in the International Traffic In Arms
> Regulations (ITAR) 22 CFR 120.10 or the Export Administration Regulations
> (EAR) 15 CFR Parts 730 – 780.  Export of this material may be controlled 
> by
> these regulations and may not be exported or transferred to non-U.S.
> persons without prior written approval from the U.S. government.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

>>> --
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material 

Re: [USRP-users] Creating RFNOC block that changes stream rate

[Andrew Danowitz via USRP-users]

Hi John,

Is there any documentation on using the ILA on an e310 that's running
gnuradio directly?

Thanks,
Andrew

On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum  wrote:

> Hi Andrew,
>
> Have you tried using Chipscope to see where the issue is at in your code?
> You want to look at the tvalid and tready AXI stream control signals to
> pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once
> you know where the stall is located, I can provide more advice.
>
> Jonathon
>
> On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Thanks for the reply. I do set simple_mode and I propagate tuser into and
>> out of axi_rate_change the same way noc_block_ddc does. I also have my
>> block running properly in Vivado simulation. Is there anything else I
>> should check? I also included axi_tag_time. Could that be causing an issue?
>>
>> Thanks!
>> Andrew
>>
>> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>>
>>> Hi Andrew,
>>>
>>> Quick thoughts:
>>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>>> - Are you propagating tuser into and out of the axi_rate_change block?
>>>
>>> The axi_rate_change block updates tuser, which the axi_wrapper uses to
>>> create output packets when SIMPLE_MODE is disabled.
>>>
>>> Also, have you run in a simulation testbench? Simulation should be able
>>> to expose these issues before targetting hardware to make debugging a bit
>>> easier.
>>>
>>> EJ
>>>
>>>
>>>
>>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi all,

 I'm trying to create an rfnoc block that takes in a stream of data at
 Sample rate n, does some processing to turn i-q values into real samples,
 and outputs data at a rate of n/2 by packing real values into both i and q
 channels of the output stream. I've tried to incorporate the
 axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
 whenever I try to run it I keep getting a timeout error. If I take out the
 channel packing block and keep the rate n-to-n, the module works fine.

 Does anyone have any advice?

 Thanks,
 Andrew

 --
 Information contained, linked, or attached to this email and all verbal
 communications from WhiteFox Defense to your entity in the prior 30 days
 constitute proprietary and confidential information unless otherwise
 indicated and is therefore subject to obligations in any executed
 confidentiality agreements. Further, this email is intended solely for the
 use of the individual or entity to whom they are addressed. If you are not
 the intended recipient and this message has been addressed to you in error,
 please promptly notify i...@whitefoxdefense.com and destroy all copies
 of the message and any attachments. This email and attachments may contain
 technical data as defined in the International Traffic In Arms Regulations
 (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
 Parts 730 – 780.  Export of this material may be controlled by these
 regulations and may not be exported or transferred to non-U.S. persons
 without prior written approval from the U.S. government.
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

>>>
>> --
>> Information contained, linked, or attached to this email and all verbal
>> communications from WhiteFox Defense to your entity in the prior 30 days
>> constitute proprietary and confidential information unless otherwise
>> indicated and is therefore subject to obligations in any executed
>> confidentiality agreements. Further, this email is intended solely for the
>> use of the individual or entity to whom they are addressed. If you are not
>> the intended recipient and this message has been addressed to you in error,
>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>> of the message and any attachments. This email and attachments may contain
>> technical data as defined in the International Traffic In Arms Regulations
>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>> Parts 730 – 780.  Export of this material may be controlled by these
>> regulations and may not be exported or transferred to non-U.S. persons
>> without prior written approval from the U.S. government.
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless 

Re: [USRP-users] Creating RFNOC block that changes stream rate

[Jon Pendlum via USRP-users]

Hi Andrew,

Have you tried using Chipscope to see where the issue is at in your code?
You want to look at the tvalid and tready AXI stream control signals to
pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once
you know where the stall is located, I can provide more advice.

Jonathon

On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks for the reply. I do set simple_mode and I propagate tuser into and
> out of axi_rate_change the same way noc_block_ddc does. I also have my
> block running properly in Vivado simulation. Is there anything else I
> should check? I also included axi_tag_time. Could that be causing an issue?
>
> Thanks!
> Andrew
>
> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>
>> Hi Andrew,
>>
>> Quick thoughts:
>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>> - Are you propagating tuser into and out of the axi_rate_change block?
>>
>> The axi_rate_change block updates tuser, which the axi_wrapper uses to
>> create output packets when SIMPLE_MODE is disabled.
>>
>> Also, have you run in a simulation testbench? Simulation should be able
>> to expose these issues before targetting hardware to make debugging a bit
>> easier.
>>
>> EJ
>>
>>
>>
>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to create an rfnoc block that takes in a stream of data at
>>> Sample rate n, does some processing to turn i-q values into real samples,
>>> and outputs data at a rate of n/2 by packing real values into both i and q
>>> channels of the output stream. I've tried to incorporate the
>>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>>> whenever I try to run it I keep getting a timeout error. If I take out the
>>> channel packing block and keep the rate n-to-n, the module works fine.
>>>
>>> Does anyone have any advice?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> --
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material may be controlled by these
>>> regulations and may not be exported or transferred to non-U.S. persons
>>> without prior written approval from the U.S. government.
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> 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] Creating RFNOC block that changes stream rate

[EJ Kreinar via USRP-users]

Some more thoughts...

Are you programming the axi_rate_change SR_N, SR_M, and SR_CONFIG registers
when you run on hardware? You might be able to do this with the XML
definition, but you may also need a block controller like the
ddc_block_ctrl_impl in uhd. Don't forgot the config register-- this seems
to latch in the N & M values.

I probably wouldn't worry about the axi_tag_time unless timed commands are
really important to your application... For most "run of the mill" rfnoc
applications with gnuradio it's usually safe to ignore timed commands, so
you might be able to simplify some logic if you wanted to take out the
axi_tag_time.


As another example you can reference, see this unmerged PR from a month or
so ago that combines a DUC and DDC into a single rfnoc block:
https://github.com/EttusResearch/fpga/pull/32 Also the corresponding uhd PR
with the software controller:
https://github.com/EttusResearch/uhd/pull/219/files

(These PRs didn't make it into the main branches but they will live on,
soon, in a new consolidated OOT repo)

EJ

On Tue, Dec 18, 2018, 6:19 PM Andrew Danowitz  Thanks for the reply. I do set simple_mode and I propagate tuser into and
> out of axi_rate_change the same way noc_block_ddc does. I also have my
> block running properly in Vivado simulation. Is there anything else I
> should check? I also included axi_tag_time. Could that be causing an issue?
>
> Thanks!
> Andrew
>
> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>
>> Hi Andrew,
>>
>> Quick thoughts:
>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>> - Are you propagating tuser into and out of the axi_rate_change block?
>>
>> The axi_rate_change block updates tuser, which the axi_wrapper uses to
>> create output packets when SIMPLE_MODE is disabled.
>>
>> Also, have you run in a simulation testbench? Simulation should be able
>> to expose these issues before targetting hardware to make debugging a bit
>> easier.
>>
>> EJ
>>
>>
>>
>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to create an rfnoc block that takes in a stream of data at
>>> Sample rate n, does some processing to turn i-q values into real samples,
>>> and outputs data at a rate of n/2 by packing real values into both i and q
>>> channels of the output stream. I've tried to incorporate the
>>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>>> whenever I try to run it I keep getting a timeout error. If I take out the
>>> channel packing block and keep the rate n-to-n, the module works fine.
>>>
>>> Does anyone have any advice?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> --
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material may be controlled by these
>>> regulations and may not be exported or transferred to non-U.S. persons
>>> without prior written approval from the U.S. government.
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from 

Re: [USRP-users] Creating RFNOC block that changes stream rate

[Andrew Danowitz via USRP-users]

Thanks for the reply. I do set simple_mode and I propagate tuser into and
out of axi_rate_change the same way noc_block_ddc does. I also have my
block running properly in Vivado simulation. Is there anything else I
should check? I also included axi_tag_time. Could that be causing an issue?

Thanks!
Andrew

On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:

> Hi Andrew,
>
> Quick thoughts:
> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
> - Are you propagating tuser into and out of the axi_rate_change block?
>
> The axi_rate_change block updates tuser, which the axi_wrapper uses to
> create output packets when SIMPLE_MODE is disabled.
>
> Also, have you run in a simulation testbench? Simulation should be able to
> expose these issues before targetting hardware to make debugging a bit
> easier.
>
> EJ
>
>
>
> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm trying to create an rfnoc block that takes in a stream of data at
>> Sample rate n, does some processing to turn i-q values into real samples,
>> and outputs data at a rate of n/2 by packing real values into both i and q
>> channels of the output stream. I've tried to incorporate the
>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>> whenever I try to run it I keep getting a timeout error. If I take out the
>> channel packing block and keep the rate n-to-n, the module works fine.
>>
>> Does anyone have any advice?
>>
>> Thanks,
>> Andrew
>>
>> --
>> Information contained, linked, or attached to this email and all verbal
>> communications from WhiteFox Defense to your entity in the prior 30 days
>> constitute proprietary and confidential information unless otherwise
>> indicated and is therefore subject to obligations in any executed
>> confidentiality agreements. Further, this email is intended solely for the
>> use of the individual or entity to whom they are addressed. If you are not
>> the intended recipient and this message has been addressed to you in error,
>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>> of the message and any attachments. This email and attachments may contain
>> technical data as defined in the International Traffic In Arms Regulations
>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>> Parts 730 – 780.  Export of this material may be controlled by these
>> regulations and may not be exported or transferred to non-U.S. persons
>> without prior written approval from the U.S. government.
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Creating RFNOC block that changes stream rate

[EJ Kreinar via USRP-users]

Hi Andrew,

Quick thoughts:
- Are you setting SIMPLE_MODE(0) in the axi_wrapper?
- Are you propagating tuser into and out of the axi_rate_change block?

The axi_rate_change block updates tuser, which the axi_wrapper uses to
create output packets when SIMPLE_MODE is disabled.

Also, have you run in a simulation testbench? Simulation should be able to
expose these issues before targetting hardware to make debugging a bit
easier.

EJ



On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to create an rfnoc block that takes in a stream of data at
> Sample rate n, does some processing to turn i-q values into real samples,
> and outputs data at a rate of n/2 by packing real values into both i and q
> channels of the output stream. I've tried to incorporate the
> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
> whenever I try to run it I keep getting a timeout error. If I take out the
> channel packing block and keep the rate n-to-n, the module works fine.
>
> Does anyone have any advice?
>
> Thanks,
> Andrew
>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> 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