[USRP-users] Question on using ChipScope at X310

Isen I-Chun Chao chao926 at gmail.com
Sat Dec 13 13:30:54 EST 2014


Thanks Ian. Once I can make the debugger work. I will try the debug port.

Hi Ashish,
I tried 2 examples.
1) with the codes:
   wire [35:0] CONTROL0;
   chipscope_icon chipscope_icon_i0
     (
       .CONTROL0(CONTROL0) // inout bus [35:0]
     );

   chipscope_ila_64 chipscope_ila_i0
     (
       .CONTROL(CONTROL0), // inout bus [35:0]
       .CLK(radio_clk),
       .TRIG0(radio0.pps)
     );
and the result in the attached file 1.png.

2). with the codes:
   wire [35:0] CONTROL0;
   chipscope_icon chipscope_icon_i0
     (
       .CONTROL0(CONTROL0) // inout bus [35:0]
     );

   chipscope_ila_64 chipscope_ila_i0
     (
       .CONTROL(CONTROL0), // inout bus [35:0]
       .CLK(radio_clk),
       .TRIG0(pps_del[1])
     );
and the result in the attached file 2.png.

However, I just got similar results. I really have no idea why I can make
it work.
In my case, the trigger and data should be the same, right?




*Best Regards,Isen I-Chun Chao*

On Fri, Dec 12, 2014 at 7:10 PM, Ian Buckley <ianb at ionconcepts.com> wrote:
>
> We would pass the signals through the "debug" port provided on all major
> modules.
> -Ian
>
> On Dec 12, 2014, at 4:06 PM, Isen I-Chun Chao via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
> Hi Ahish,
> Thanks I do not have usrps with me right now. I will try it later today
> and get back to you.
>
> What would you people do if you want to observe the signals in radio.v?
>
> Thanks.
> On Dec 12, 2014 7:02 PM, "Ashish Chaudhari" <ashish.chaudhari at ettus.com>
> wrote:
>
>> Hi Isen,
>>
>> That could be your Verilog code. I'm not fully sure if hierarchical
>> access (radio0.new_rx_framer.sample) is supported by the tools. Can you try
>> looking at a local signal in x300_core.v?
>>
>>    chipscope_ila_64 chipscope_ila_i0
>>      (
>>        .CONTROL(CONTROL0), // inout bus [35:0]
>>        .CLK(radio_clk),
>>        .TRIG0(*radio0.new_rx_framer.sample*)
>>      );
>>
>> Thanks,
>>
>> *Ashish Chaudhari* | Senior Software Engineer | High Frequency
>> Measurements - RF
>> Ettus Research, *A National Instruments Company*
>> ashish.chaudhari at ettus.com
>>
>> On Fri, Dec 12, 2014 at 3:49 PM, Isen I-Chun Chao <chao926 at gmail.com>
>> wrote:
>>>
>>> Hi Ashish,
>>> Thanks for the reply.
>>>
>>> I renamed the DataPort[0] to radio0.new_rx_framer.sample. But nothing
>>> showed up in the waveform windows as attachment. I wonder if I miss
>>> something?
>>>
>>>
>>> *Best Regards,Isen I-Chun Chao*
>>>
>>> On Fri, Dec 12, 2014 at 2:23 PM, Ashish Chaudhari <
>>> ashish.chaudhari at ettus.com> wrote:
>>>>
>>>> Hi Isen,
>>>>
>>>> I am a bit confused about the process of using ChipScope. I thought
>>>>> there are 2 ways to use it.
>>>>> a). First use CoreGen to generate ICON and ILAs (and VIO) with
>>>>> appropriate design in Verilog code,  and then after burning the image to
>>>>> FPGA launch Analyzer to observe signals set in Verilog code.
>>>>> b). Use Inserter (by clicking the .cdc file in ISE) to to generate
>>>>> ICON and ILAs and set up the trigger/data ports, and then after burning the
>>>>> image to FPGA launch Analyzer to observe signals set in Inserter.
>>>>
>>>>
>>>> All of what you said is correct.
>>>>
>>>> Do you mean that I still need to use ChipScope Inserter to manually
>>>>> import the signals I want to observe?
>>>>
>>>>
>>>> No, what you are doing should work and is working as expected. (See my
>>>> response below)
>>>>
>>>> So I am not sure why you mentioned that I have to manually enter the
>>>>> signal I want to observe? and where should I did that? in Inserter? then
>>>>> what is different between a) and b).
>>>>
>>>>
>>>> You have to manually enter the signal in the Chipscope Analyzer GUI.
>>>> The difference between a) and b) is that in the case of b) ISE knows the
>>>> logical names of the nets that you are passing to the ila core in the FPGA
>>>> because you configure that explicitly. The allows the inserter to generate
>>>> a CDC file with all the net names, and that can be imported into the
>>>> analyzer. In the case of a) the mapping from logical signals to DATA or
>>>> TRIG are done in HDL and can be arbitrary. In that case the Xilinx tools
>>>> are not smart enough to infer what is actually connected to the DATA or
>>>> TRIG ports. The only information that the tools have are the widths of
>>>> those buses. So it is not able to generate a cdc file like b) with a logic
>>>> signal mapping. So you have to enter it into the analyzer manually. In your
>>>> example, you would just have to select "DataPort[0]" in the waveform window
>>>> in the analyzer, right-click, rename and change the name to
>>>> "radio0.new_rx_framer.sample". When you have more signals, you will have to
>>>> do the same for all of them.
>>>>
>>>> Hopefully that clears things up.
>>>>
>>>> *Ashish Chaudhari* | Senior Software Engineer | High Frequency
>>>> Measurements - RF
>>>> Ettus Research, *A National Instruments Company*
>>>> ashish.chaudhari at ettus.com
>>>>
>>>> On Tue, Dec 9, 2014 at 10:09 PM, Isen I-Chun Chao <chao926 at gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Ashish,
>>>>> Do you mean that I still need to use ChipScope Inserter to manually
>>>>> import the signals I want to observe?
>>>>>
>>>>> I am a bit confused about the process of using ChipScope. I thought
>>>>> there are 2 ways to use it.
>>>>> a). First use CoreGen to generate ICON and ILAs (and VIO) with
>>>>> appropriate design in Verilog code,  and then after burning the image to
>>>>> FPGA launch Analyzer to observe signals set in Verilog code.
>>>>> b). Use Inserter (by clicking the .cdc file in ISE) to to generate
>>>>> ICON and ILAs and set up the trigger/data ports, and then after burning the
>>>>> image to FPGA launch Analyzer to observe signals set in Inserter.
>>>>>
>>>>> Now I am using method a). Since I found the fpga-src from github
>>>>> repository comes with ICON and ILA cores, I did not actually use CoreGen to
>>>>> generate ICON and ILAs. And I saw there are piece of codes of using ICON
>>>>> and ILA modules in x300_core.v. So I tried to use the exist ICON and ILA
>>>>> module. So I am not sure why you mentioned that I have to manually enter
>>>>> the signal I want to observe? and where should I did that? in Inserter?
>>>>> then what is different between a) and b).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Best Regards,Isen I-Chun Chao*
>>>>>
>>>>> On Tue, Dec 9, 2014 at 6:43 PM, Ashish Chaudhari <
>>>>> ashish.chaudhari at ettus.com> wrote:
>>>>>
>>>>>> Hi Isen,
>>>>>>
>>>>>> I'm glad that you are finally up and running. Regarding the ports not
>>>>>> showing up, that's expected behavior. When you manually put a chipscope
>>>>>> module in the Verilog code, the tools don't parse what is is connected to
>>>>>> the TRIG and DATA ports so you have to manually enter those in the
>>>>>> Chipscope GUI. When you use the Chipscope inserter, the tools export a file
>>>>>> (forgot the extension) that you can import in the Chipscope GUI and
>>>>>> populate the real names of the signals that you are observing. For now
>>>>>> though, you will have to manually enter them in.
>>>>>>
>>>>>> *Ashish Chaudhari* | Senior Software Engineer | High Frequency
>>>>>> Measurements - RF
>>>>>> Ettus Research, *A National Instruments Company*
>>>>>> ashish.chaudhari at ettus.com
>>>>>>
>>>>>> On Tue, Dec 9, 2014 at 12:20 PM, Isen I-Chun Chao <chao926 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> ​Hi Ashish,
>>>>>>> Thank you very much for the help. It works for me.
>>>>>>>
>>>>>>> However, I ​tried to use ChipScope core like what Ettus Research
>>>>>>> used in default code as follow:
>>>>>>>    wire [35:0] CONTROL0;
>>>>>>>    chipscope_icon chipscope_icon_i0
>>>>>>>      (
>>>>>>>        .CONTROL0(CONTROL0) // inout bus [35:0]
>>>>>>>      );
>>>>>>>
>>>>>>>    chipscope_ila_64 chipscope_ila_i0
>>>>>>>      (
>>>>>>>        .CONTROL(CONTROL0), // inout bus [35:0]
>>>>>>>        .CLK(radio_clk),
>>>>>>>        .TRIG0(radio0.new_rx_framer.sample)
>>>>>>>      );
>>>>>>>
>>>>>>> When I launched Xilinx Analyzer, I did not found any waveform for
>>>>>>> radio0.new_rx_framer.sample, as the attachement. Is it because that
>>>>>>> is for trigger port?
>>>>>>> Am I misunderstand how the default code uses ChipScope? If I would
>>>>>>> like to observe radio0.new_rx_framer.sample, what should I set it
>>>>>>> up?
>>>>>>>
>>>>>>> Thank you very much for your time.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Best Regards,Isen I-Chun Chao*
>>>>>>>
>>>>>>> On Mon, Dec 8, 2014 at 9:24 PM, Ashish Chaudhari <
>>>>>>> ashish.chaudhari at ettus.com> wrote:
>>>>>>>
>>>>>>>> Hi Isen,
>>>>>>>>
>>>>>>>> I followed your instructions that I first copied the rebuilt LVBITX
>>>>>>>>> and BIT image with enabling the inserted ChipScope cores to
>>>>>>>>> /opt/uhd-3.8.0/share/uhd/images, and burned the BIT to X310, then launched
>>>>>>>>> the Xilinx Analyzer with using the rebuilt BIT image as the configuration.
>>>>>>>>> However I got the same error code whiling running gnuradio applications or
>>>>>>>>> uhd_usrp_probe.
>>>>>>>>
>>>>>>>>
>>>>>>>> That is not quite what I said. You don't need to burn the BIT to
>>>>>>>> the flash to use the device over PCIe. When you run uhd_usrp_probe or any
>>>>>>>> gnuradio application, UHD will read the FPGA image from the filesystem
>>>>>>>> (/opt/uhd-3.8.0/share/uhd/images/usrp_x310_fpga_HGS.lvbitx) and load it
>>>>>>>> onto the device at runtime. This happens ever time you run a UHD or
>>>>>>>> Gnuradio app. You don't need the BIT file at all; in fact using the BIT
>>>>>>>> file is what is causing the error. Here is what I would do:
>>>>>>>> - Build FPGA image with Chipscope. This should produce a BIN, BIT
>>>>>>>> and LVBITX file.
>>>>>>>> - Copy just the LVBITX file to /opt/uhd-3.8.0/share/uhd/images
>>>>>>>> - Run uhd_usrp_probe. After the comman is done running you have
>>>>>>>> successfully loaded your new bitfile with chipscope on the device
>>>>>>>> - Launch the Analyzer GUI. It should be able to auto-detect your
>>>>>>>> device over JTAG and see that the loaded image has chipscope ILAs.
>>>>>>>> - Now you can use the ILAs normally. You don't ever have to touch
>>>>>>>> the BIT file.
>>>>>>>>
>>>>>>>>
>>>>>>>> *Ashish Chaudhari* | Senior Software Engineer | High Frequency
>>>>>>>> Measurements - RF
>>>>>>>> Ettus Research, *A National Instruments Company*
>>>>>>>> ashish.chaudhari at ettus.com
>>>>>>>>
>>>>>>>> On Mon, Dec 8, 2014 at 1:35 PM, Isen I-Chun Chao via USRP-users <
>>>>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Ashish,
>>>>>>>>> I followed your instructions that I first copied the rebuilt LVBITX
>>>>>>>>> and BIT image with enabling the inserted ChipScope cores to
>>>>>>>>> /opt/uhd-3.8.0/share/uhd/images, and burned the BIT to X310, then launched
>>>>>>>>> the Xilinx Analyzer with using the rebuilt BIT image as the configuration.
>>>>>>>>> However I got the same error code whiling running gnuradio applications or
>>>>>>>>> uhd_usrp_probe.
>>>>>>>>>
>>>>>>>>> A. Running an GnuRadio application:
>>>>>>>>> linux; GNU C++ version 4.8.2; Boost_105400;
>>>>>>>>> UHD_003.008.000-0-unknown
>>>>>>>>>
>>>>>>>>> Using Volk machine: avx_64_mmx_orc
>>>>>>>>> OFDM MAPPER: encoding: 0
>>>>>>>>> set_min_output_buffer on block 10 to 48000
>>>>>>>>> set_min_output_buffer on block 14 to 100000
>>>>>>>>> set_min_output_buffer on block 15 to 10000
>>>>>>>>> set_min_output_buffer on block 17 to 48000
>>>>>>>>> -- X300 initialization sequence...
>>>>>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>>>>>> -- Using LVBITX bitfile
>>>>>>>>> /opt/uhd-3.8.0/share/uhd/images/usrp_x310_fpga_HGS.lvbitx...
>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>   File
>>>>>>>>> "/home/isen/Workspace/src_build/gr-ieee802-11/examples/wifi_transceiver.py",
>>>>>>>>> line 395, in <module>
>>>>>>>>>     tb = wifi_transceiver()
>>>>>>>>>   File
>>>>>>>>> "/home/isen/Workspace/src_build/gr-ieee802-11/examples/wifi_transceiver.py",
>>>>>>>>> line 126, in __init__
>>>>>>>>>     channels=range(1),
>>>>>>>>>   File
>>>>>>>>> "/opt/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
>>>>>>>>> 122, in constructor_interceptor
>>>>>>>>>     return old_constructor(*args)
>>>>>>>>>   File
>>>>>>>>> "/opt/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
>>>>>>>>> 1754, in make
>>>>>>>>>     return _uhd_swig.usrp_source_make(*args)
>>>>>>>>> RuntimeError: RuntimeError: x300_impl: Could not initialize RIO
>>>>>>>>> session. Unknown error. (Error code -63150)
>>>>>>>>>
>>>>>>>>> B. Running uhd_usrp_probe:
>>>>>>>>> linux; GNU C++ version 4.8.2; Boost_105400;
>>>>>>>>> UHD_003.008.000-0-unknown
>>>>>>>>>
>>>>>>>>> -- X300 initialization sequence...
>>>>>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>>>>>> -- Using LVBITX bitfile
>>>>>>>>> /opt/uhd-3.8.0/share/uhd/images/usrp_x310_fpga_HGS.lvbitx...
>>>>>>>>> Error: RuntimeError: x300_impl: Could not initialize RIO session.
>>>>>>>>> Unknown error. (Error code -63150)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ​Hi Jonathon,
>>>>>>>>> Thanks for the reply. I will get it a try to see if it works for
>>>>>>>>> me.​
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Best Regards,Isen I-Chun Chao*
>>>>>>>>>
>>>>>>>>> On Mon, Dec 1, 2014 at 3:28 PM, Jonathon Pendlum <
>>>>>>>>> jonathon.pendlum at ettus.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Isen,
>>>>>>>>>>
>>>>>>>>>> When using the Chipscope inserter tool (approach 1), you should
>>>>>>>>>> set the Synthesis setting "Keep Hierarchy" to "Soft". This will force ISE
>>>>>>>>>> to retain most of the original signal names.
>>>>>>>>>>
>>>>>>>>>> The error "radio remains a blackbox" you are experiencing is due
>>>>>>>>>> to a synthesis error in radio.v. You may have introduced a syntax error ("Module
>>>>>>>>>> radio remains a blackbox,  ***due to errors in its contents***") when
>>>>>>>>>> you added the chipscope module to radio.v.
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 1, 2014 at 12:24 PM, Ashish Chaudhari via USRP-users
>>>>>>>>>> <usrp-users at lists.ettus.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Isen,
>>>>>>>>>>>
>>>>>>>>>>> The error code -63150 is probably being thrown because you are
>>>>>>>>>>> loading your FPGA image with Chipscope over JTAG and then trying to use the
>>>>>>>>>>> device over PCIe. That behavior is not supported by UHD and the underlying
>>>>>>>>>>> kernel driver. UHD will attempt load a new FPGA image (as an LVBITX) over
>>>>>>>>>>> the PCIe bus every time a UHD session is initialized. The operation is
>>>>>>>>>>> optimized to skip the actual load if an image already exists but it will
>>>>>>>>>>> try nonetheless. If you load a .bit file over JTAG and then an LVBITX over
>>>>>>>>>>> PCIe, then you will run into the -63150 error. The only way to recover from
>>>>>>>>>>> that is to reload the kernel modules (or reboot).
>>>>>>>>>>>
>>>>>>>>>>> To facilitate your use case the X3x0 FPGA build tools also
>>>>>>>>>>> export an LVBITX image in addition to a BIT image. I would recommend using
>>>>>>>>>>> that. All you have to do is copy your newly built usrp_x310_fpga_HGS.lvbitx
>>>>>>>>>>> to /opt/uhd-3.8.0/share/uhd/images/ and run UHD normally. When you open a
>>>>>>>>>>> multi_usrp session, UHD will load the new image onto the device and it
>>>>>>>>>>> should have your newly inserted chipscope cores. Then you can just launch
>>>>>>>>>>> the analyzer and your ila's should show up.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Ashish Chaudhari* | Senior Software Engineer | High Frequency
>>>>>>>>>>> Measurements - RF
>>>>>>>>>>> Ettus Research, *A National Instruments Company*
>>>>>>>>>>> ashish.chaudhari at ettus.com
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Nov 28, 2014 at 6:34 PM, Isen I-Chun Chao via USRP-users
>>>>>>>>>>> <usrp-users at lists.ettus.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Sorry I had some typo in last email.
>>>>>>>>>>>> The code I added at the bottom of the x300_core.v is below.
>>>>>>>>>>>>    wire [35:0] CONTROL0;
>>>>>>>>>>>>    chipscope_icon chipscope_icon_i0
>>>>>>>>>>>>      (
>>>>>>>>>>>>        .CONTROL0(CONTROL0) // inout bus [35:0]
>>>>>>>>>>>>      );
>>>>>>>>>>>>
>>>>>>>>>>>>    chipscope_ila_64 chipscope_ila_i0
>>>>>>>>>>>>      (
>>>>>>>>>>>>        .CONTROL(CONTROL0), // inout bus [35:0]
>>>>>>>>>>>>        .CLK(radio_clk),
>>>>>>>>>>>>        .TRIG0(radio0.new_rx_framer.sample)
>>>>>>>>>>>>      );
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *Best Regards,Isen I-Chun Chao*
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Nov 28, 2014 at 5:46 PM, Isen I-Chun Chao <
>>>>>>>>>>>> chao926 at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> I am using Xilinx ChipScope to see if I can observe variables
>>>>>>>>>>>>> and signals inside Verilog code of X310. I learned that there are two ways
>>>>>>>>>>>>> using ChipScope: CoreGen+Analyzer(approach1) and
>>>>>>>>>>>>> Inserter+Analyzer(approach2). The approach1 need to write some verilog code
>>>>>>>>>>>>> inside modules; while the approach2 need to use ISE GUI interface.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1). I first tried to use the approach2 to monitor *sample_rx*
>>>>>>>>>>>>> in *radio.v* of the default FPGA code (to see the sample data
>>>>>>>>>>>>> flow between *ddc_chain*and *new_rx_framer*) by using Xilinx
>>>>>>>>>>>>> ISE 14.7. But I cannot find out the related signal name while setting the
>>>>>>>>>>>>> ILA as the attached figure (set_trigger_in_ILA.png). Does anyone know how
>>>>>>>>>>>>> to find required signal matched the variables in the code? like
>>>>>>>>>>>>> *sample_rx* in *radio.v*.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. After not being able to make the approach2 work, I tried
>>>>>>>>>>>>> the approach1. Since there are icon and ila_64 already placed in system, I
>>>>>>>>>>>>> just added probe code in the bottom of *x300_core.v* as
>>>>>>>>>>>>> below. After successful building and transferring to X310, I launched
>>>>>>>>>>>>> Xilinx analyzer to see if I can observe the data of
>>>>>>>>>>>>> *sample_rx* in *radio*.
>>>>>>>>>>>>>    wire [35:0] CONTROL0;
>>>>>>>>>>>>>    chipscope_icon chipscope_icon_i0
>>>>>>>>>>>>>      (
>>>>>>>>>>>>>        .CONTROL0(CONTROL0) // inout bus [35:0]
>>>>>>>>>>>>>      );
>>>>>>>>>>>>>
>>>>>>>>>>>>>    chipscope_ila_64 chipscope_ila_i0
>>>>>>>>>>>>>      (
>>>>>>>>>>>>>        .CONTROL(CONTROL0), // inout bus [35:0]
>>>>>>>>>>>>>        .CLK(radio_clk),
>>>>>>>>>>>>>        .TRIG0(radio0.new_rx_framer.sample_rx)
>>>>>>>>>>>>>      );
>>>>>>>>>>>>>
>>>>>>>>>>>>> ​However after ​running Xilinx Analyzer (analyzer.png), I
>>>>>>>>>>>>> always got runtime error for GNU Radio application as below. Note that
>>>>>>>>>>>>> since I whenever I launched Xilinx Analyzer, there is UNIT0 can be found
>>>>>>>>>>>>> until I selected a new file in the configuration dialog (configuration.png)
>>>>>>>>>>>>> by right clicking DEV0. So I can not either observe monitored data, nor run
>>>>>>>>>>>>> the GR application.
>>>>>>>>>>>>> ​linux; GNU C++ version 4.8.2; Boost_105400;
>>>>>>>>>>>>> UHD_003.008.000-0-unknown
>>>>>>>>>>>>> Using Volk machine: avx_64_mmx_orc
>>>>>>>>>>>>> -- X300 initialization sequence...
>>>>>>>>>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>>>>>>>>>> -- Using LVBITX bitfile
>>>>>>>>>>>>> /opt/uhd-3.8.0/share/uhd/images/usrp_x310_fpga_HGS.lvbitx...
>>>>>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>>>>>   File
>>>>>>>>>>>>> "/home/isen/Workspace/src_build/gr-ieee802-11/examples/wifi_rx.py", line
>>>>>>>>>>>>> 248, in <module>
>>>>>>>>>>>>>     tb = wifi_rx()
>>>>>>>>>>>>>   File
>>>>>>>>>>>>> "/home/isen/Workspace/src_build/gr-ieee802-11/examples/wifi_rx.py", line
>>>>>>>>>>>>> 130, in __init__
>>>>>>>>>>>>>     channels=range(1),
>>>>>>>>>>>>>   File
>>>>>>>>>>>>> "/opt/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
>>>>>>>>>>>>> 122, in constructor_interceptor
>>>>>>>>>>>>>     return old_constructor(*args)
>>>>>>>>>>>>>   File
>>>>>>>>>>>>> "/opt/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
>>>>>>>>>>>>> 1754, in make
>>>>>>>>>>>>>     return _uhd_swig.usrp_source_make(*args)
>>>>>>>>>>>>> RuntimeError: RuntimeError: x300_impl: Could not initialize
>>>>>>>>>>>>> RIO session. Unknown error. (Error code -63150)
>>>>>>>>>>>>>>>>>>>>>>>>>> ​3
>>>>>>>>>>>>> . There is an extra question using ChipScope. Can I put probe
>>>>>>>>>>>>> code (icon, ila_64)​ in *radio.v*? Because I always met error
>>>>>>>>>>>>> messages like below if I added them in the bottom of*radio.v*.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ​Module radio remains a blackbox, due to errors in its contents
>>>>>>>>>>>>> Module radio remains a blackbox, due to errors in its contents
>>>>>>>>>>>>> Number of errors   :    2 (   0 filtered)
>>>>>>>>>>>>> make[1]: *** No rule to make target `build-X310_HGS/x300.bit',
>>>>>>>>>>>>> needed by `bin'.  Stop.
>>>>>>>>>>>>> make: *** [X310_HGS] Error 2
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Best Regards,Isen I-Chun Chao*
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> USRP-users mailing list
>>>>>>>>>>>> USRP-users at lists.ettus.com
>>>>>>>>>>>>
>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> USRP-users mailing list
>>>>>>>>>>> USRP-users at lists.ettus.com
>>>>>>>>>>>
>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> USRP-users mailing list
>>>>>>>>> USRP-users at lists.ettus.com
>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>   _______________________________________________
> USRP-users mailing list
> USRP-users at 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/20141213/1e302195/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 62439 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141213/1e302195/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.png
Type: image/png
Size: 57690 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141213/1e302195/attachment-0001.png>


More information about the USRP-users mailing list