USRP-users Digest, Vol 52, Issue 15

[usrp-users-request]

Send USRP-users mailing list submissions to
        usrp-users@lists.ettus.com

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
        usrp-users-requ...@lists.ettus.com

You can reach the person managing the list at
        usrp-users-ow...@lists.ettus.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. Strange behavior of N210 with timed commands (LOUF Laurent)
   2. Re: UHD and Thread Safety (Perelman, Nathan)
   3. UHD timestamp synchronization for multiple USRPs connected to
      an unlocked Octoclock-G (Urban Hakansson)
   4. Re: Question on using ChipScope at X310 (Ashish Chaudhari)
   5. Re: Question on using ChipScope at X310 (Isen I-Chun Chao)
   6. Re: Question on using ChipScope at X310 (Ashish Chaudhari)
   7. Re: Question on using ChipScope at X310 (Isen I-Chun Chao)
   8. Re: Question on using ChipScope at X310 (Ian Buckley)


----------------------------------------------------------------------

Message: 1
Date: Fri, 12 Dec 2014 14:58:22 +0100
From: LOUF Laurent <laurent.l...@thalesgroup.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Strange behavior of N210 with timed commands
Message-ID:
        
<25389_1418392704_548af480_25389_3826_1_5eb8adb6498522479c5e7381a2c8cf354aae3f7...@thsonea01cms10p.one.grp>
        
Content-Type: text/plain; charset="iso-8859-1"

Hello,

I'm not quite sure how to use this mailing list so do not hesitate to redirect 
me to a better place or to someone that may know the answer to my question.

That being said, I'm currently working with an USRP N210 at work and observed a 
strange behavior on which I would like to have your input. I use the USRP to 
receive a signal, apply a channel simulation on it and transmit the signal 
obtained. I have absolutely no problem on the receive part but one little on 
the transmit part. The signal I use is sampled at 2Msamples / second, and I 
work on frames of 1250 samples, so frames of 625?s. So the whole process goes 
that way, I receive a frame, apply the channel simulation and then transmit it, 
at a fixed interval.

The problem occurs now : I do some calculations based on the time when I 
receive the first frame, add the latency of my system and a number of times 
625?s corresponding to the number of frames sent, which makes the time to 
transmit the frame, that is sent to the USRP along with the current frame. If I 
put an interval of exactly 625?s, I get a fastpath message "L" every two 
frames, and I can see that the data of the second frame is not transmitted. If 
I put an interval of 625,1?s, everything seems to work fine and I don't get any 
error. The metadata I send along with the frame are : start_of_burst = true , 
end_of_burst = true , has_time_spec = true and the time spec I got from my 
calculations. That feels strange to me since I don't even have to add the time 
corresponding to one sample to get it to work (0,5?s). Could it be something 
related to the burst mode that I'm using ? I did not fully get that part 
reading the documentation, so feel free to enlighten me on that subject.

Thanks in advance for any answer,
Laurent Louf.

[@@OPEN @@]



-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/d30f56dd/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 12 Dec 2014 18:02:54 +0000
From: "Perelman, Nathan" <nperel...@lgsinnovations.com>
To: Balint Seeber <balint.see...@ettus.com>, Andy Walls
        <a...@silverblocksystems.net>
Cc: Ben Hilburn via USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID: <a3e840e010ce4216abbed5733429c...@lgs-ex01.lgsdirect.com>
Content-Type: text/plain; charset="utf-8"

Thanks for the details. Sounds like everything I?m doing should be ok, although 
I?m doing it with N2x0s. Are there any significant differences for the N2x0?

-Nathan

 

From: Balint Seeber [mailto:balint.see...@ettus.com] 
Sent: Thursday, December 11, 2014 7:07 PM
To: Andy Walls
Cc: Ben Hilburn; Ben Hilburn via USRP-users; Perelman, Nathan
Subject: Re: [USRP-users] UHD and Thread Safety

 

Hi all,

Apologies - I advised Ben a little too soon before double checking all the code 
paths.

The following applies to third generation radios (B2x0, E310 & X3x0) - these 
use radio_ctrl_core_3000 so send control/configuration packets to the radios on 
these devices:

Settings bus registers are updated in/results are read back from each radio 
core in the FPGA by performing a peek or poke. peek32, peek64 and poke32 are 
provided by radio_ctrl_core_3000, and each of these individual operations are 
thread safe (there is a mutex in each function). These calls are also blocking, 
so they will wait for an ACK to come back from the core (this contains the 
result in the case of a peek). As a side note, if you have a transport failure, 
then you'll see the standard 'timed out waiting for ACK' exception thrown from 
radio_ctrl_core_3000.

Now to those specific functions:

*       get_time_now (from time_core_3000): a single peek64, so it is thread 
safe (you can call this from any thread, and probably will in complex 
applications that might have a main app thread, a thread for RX, another for 
TX, and perhaps something to handle TX asynchronous messages and/or other 
device status like PLL/ref lock, GPS, etc). Same applies to 'get_time_last_pps'.

set_time_now/set_time_next_pps are implemented as three poke32 calls, and those 
calls are not in a mutex, so you wouldn't want to call them from different 
threads - but then again you probably would never do this anyway, since it 
doesn't make sense to do so (you generally would call one of the two once 
during device init).
*       Anything to do with the GPS is not thread safe. You should synchronise 
calls to the sensors API only if you're doing this from different threads. If 
you know you'll only be doing this from one thread only, then it's not 
necessary to synchronise (i.e. you don't need to synchronise all accesses to 
any function in one multi_usrp instance).

Moreover, since much of multi_user actually sets/gets items on the device 
instance's property tree, it's worth noting that manipulating the structure of 
the property is thread safe, but actually setting/getting node values (i.e. 
triggering publishers/subscribers/coercers) is not thread safe (i.e. thread 
safety relies on the underlying implementation(s) that get(s) called).

Andy, when you say 'complain' you mean UHD output a log message, but didn't 
throw an exception? I imagine this had to do with the last received RMC not 
being considered 'fresh' any more, and perhaps a new one has not arrived yet in 
the buffer due to delays on the transport. You might want to match the message 
up with uhd/host/lib/usrp/gps_ctrl.cpp.

Hope that helps and doesn't cause any race conditions for you!

Kind regards,
Balint

 

On Thu, Dec 11, 2014 at 12:27 PM, Andy Walls via USRP-users 
<usrp-users@lists.ettus.com> wrote:

FWIW, I use a custom GNURadio block for closed loop monitoring of GPSDO and 
USRP time between the host and the USRP. Polling every two seconds, 25 msec 
after the PPS, I occasionally see UHD gripe about the GPRMC message not being 
available. I never bothered to track down the cause.

-Andy

 

On December 11, 2014 3:16:41 PM EST, Ben Hilburn via USRP-users 
<usrp-users@lists.ettus.com> wrote:

Okay, we are debating the safety of polling for sensor data here within the R&D 
team. At this point, we have flip-flopped several times.

 

Balint will respond shortly with our final guidance =)

 

Cheers,

Ben

 

On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn <ben.hilb...@ettus.com> wrote:

Actually, what I just said is wrong, because calling those functions will 
result in packets being sent from the device.

 

So, no. Nothing is thread safe, and even polling for sensor data could cause 
issues.

 

Cheers,

Ben

 

On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn <ben.hilb...@ettus.com> wrote:

Hi Nathan -

 

Generally, any UHD function that doesn't involve streaming is not thread-safe. 
So if you called "get_time_now" from two separate threads at the same time, 
that is not a thread-safe operation.

 

If all you are doing is polling sensors from a thread that is different from 
the thread in which you started streaming, you should be OK. But, it is not 
technically thread safe.

 

Cheers,

Ben

 

On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users 
<usrp-users@lists.ettus.com> wrote:

I?ve been assuming that calls to UHD functions that don?t change settings on 
the USRP are generally thread safe and can be called from another thread even 
while a capture is ongoing. Is this an accurate assumption? The functions I?m 
calling are get_mboard_sensor() (for GPS information and ref_locked) and 
get_time_now(). Thanks.

-Nathan Perelman


_______________________________________________
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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/36c64a49/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4327 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/36c64a49/attachment-0001.p7s>

------------------------------

Message: 3
Date: Fri, 12 Dec 2014 14:06:56 -0500 (EST)
From: Urban Hakansson <uhakans...@tecore.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] UHD timestamp synchronization for multiple USRPs
        connected to an unlocked Octoclock-G
Message-ID: <1671892823.120828.1418411216600.javamail.r...@tecore.com>
Content-Type: text/plain; charset="utf-8"

Hi everybody, 

First I thought that by getting an Octoclock-G and connecting all my USRPs to 
the Octoclock-G (unlocked mode) would ensure UHD timestamp synchronization 
amongst the USRPs. 

However, after I have read http://files.ettus.com/manual/page_sync.html and 
thought about it carefully I still cannot figure out how to guarantee time 
stamp UHD sycnhronization with just the 1PPS and the 10MHz reference signals. 
The fact that the 1PPS signals are perfectly aligned in time amongst the USPRs 
don't seem to be sufficient. 

Method 1, poll USRP registers only ensures that you set the time on the next 
1PPS pulse 


const uhd::time_spec_t last_pps_time = usrp->get_time_last_pps(); 
while (last_pps_time == usrp->get_time_last_pps()){ 
//sleep 100 milliseconds (give or take) 
} 
usrp->set_time_next_pps( uhd::time_spec_t (0.0)); 
How do I know for sure that all the USRPs trigger on the same 1PPS pulse? 

Even if the USRPs boot-up just slightly slower/faster than each other I can see 
it easily happening that the USRPs could set t = 0.0, for two different 1PPS 
pulses, which is not good. 

Method 2 - query the GPSDO for seconds 
Can I query the Octoclock-G for an NMEA string? The Octoclock-G does not have a 
serial interface. 

//call user's function to wait for NMEA message... 
usrp->set_time_next_pps( uhd::time_spec_t (0.0)); 
Is there a sure-fire method for achieving time-stamp synchronization? It does 
not have to be absolute, UTC time etc.. I just want the USRPs to start counting 
time at the same time, preferably by calling usrp->set_time_next_pps( 
uhd::time_spec_t (0.0)) for the same 1PPS pulse. 

Thanks for your consideration. 


Urban Hakansson 
Senior Software Engineer 
Tecore Networks 
Phone: +1 410 872 6315 
Fax: +1 410 872 6010 
Email: uhakans...@tecore.com 


                                                                                
                                                                                
                                                                       This 
e-mail may contain privileged, confidential, copyrighted or other legally 
protected information, and is intended exclusively for the intended recipient.  
If you are not the intended recipient (even if the e-mail address above is 
yours), you may not review, store, use, copy, disclose or retransmit it in any 
form.  If you are not the intended recipient or otherwise have received this by 
mistake, please immediately notify the sender by return e-mail (or 
sysad...@tecore.com), then delete the message in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/cc7931f6/attachment-0001.html>

------------------------------

Message: 4
Date: Fri, 12 Dec 2014 11:23:14 -0800
From: Ashish Chaudhari <ashish.chaudh...@ettus.com>
To: Isen I-Chun Chao <chao...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Question on using ChipScope at X310
Message-ID:
        <caozxt+aycem+o1zs2-1ns6ojsqmhuprvokdi-u67st3mq60...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.chaudh...@ettus.com

On Tue, Dec 9, 2014 at 10:09 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>
>> On Tue, Dec 9, 2014 at 12:20 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>>>
>>>> On Mon, Dec 8, 2014 at 1:35 PM, Isen I-Chun Chao via USRP-users <
>>>> usrp-users@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.pend...@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@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.chaudh...@ettus.com
>>>>>>>
>>>>>>> On Fri, Nov 28, 2014 at 6:34 PM, Isen I-Chun Chao via USRP-users <
>>>>>>> usrp-users@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 <
>>>>>>>> chao...@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@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
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/6f9b8703/attachment-0001.html>

------------------------------

Message: 5
Date: Fri, 12 Dec 2014 18:49:18 -0500
From: Isen I-Chun Chao <chao...@gmail.com>
To: Ashish Chaudhari <ashish.chaudh...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Question on using ChipScope at X310
Message-ID:
        <caeg73kpnm5m2q4-g7re6+odzez6co_mp8u9q22aekolqf11...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.chaudh...@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.chaudh...@ettus.com
>
> On Tue, Dec 9, 2014 at 10:09 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>>
>>> On Tue, Dec 9, 2014 at 12:20 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>>>>
>>>>> On Mon, Dec 8, 2014 at 1:35 PM, Isen I-Chun Chao via USRP-users <
>>>>> usrp-users@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.pend...@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@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.chaudh...@ettus.com
>>>>>>>>
>>>>>>>> On Fri, Nov 28, 2014 at 6:34 PM, Isen I-Chun Chao via USRP-users <
>>>>>>>> usrp-users@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 <
>>>>>>>>> chao...@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@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/266e6139/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: analyzer_2.png
Type: image/png
Size: 89575 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/266e6139/attachment-0001.png>

------------------------------

Message: 6
Date: Fri, 12 Dec 2014 16:02:00 -0800
From: Ashish Chaudhari <ashish.chaudh...@ettus.com>
To: Isen I-Chun Chao <chao...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Question on using ChipScope at X310
Message-ID:
        <caozxt+dfafsuzd54tgagxejcnhysfmowpw6auwvg3j9ytmg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.chaudh...@ettus.com

On Fri, Dec 12, 2014 at 3:49 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>
>> On Tue, Dec 9, 2014 at 10:09 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>>>
>>>> On Tue, Dec 9, 2014 at 12:20 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>>>>>
>>>>>> On Mon, Dec 8, 2014 at 1:35 PM, Isen I-Chun Chao via USRP-users <
>>>>>> usrp-users@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.pend...@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@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.chaudh...@ettus.com
>>>>>>>>>
>>>>>>>>> On Fri, Nov 28, 2014 at 6:34 PM, Isen I-Chun Chao via USRP-users <
>>>>>>>>> usrp-users@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 <
>>>>>>>>>> chao...@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@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/99516e33/attachment-0001.html>

------------------------------

Message: 7
Date: Fri, 12 Dec 2014 19:06:48 -0500
From: Isen I-Chun Chao <chao...@gmail.com>
To: Ashish Chaudhari <ashish.chaudh...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Question on using ChipScope at X310
Message-ID:
        <CAEG73KqoHZX9_H3Agr5BTK1X9oOVyhfFOt1+GnO6O5=zmbn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.chaudh...@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.chaudh...@ettus.com
>
> On Fri, Dec 12, 2014 at 3:49 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>>
>>> On Tue, Dec 9, 2014 at 10:09 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>>>>
>>>>> On Tue, Dec 9, 2014 at 12:20 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
>>>>>>>
>>>>>>> On Mon, Dec 8, 2014 at 1:35 PM, Isen I-Chun Chao via USRP-users <
>>>>>>> usrp-users@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.pend...@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@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.chaudh...@ettus.com
>>>>>>>>>>
>>>>>>>>>> On Fri, Nov 28, 2014 at 6:34 PM, Isen I-Chun Chao via USRP-users
>>>>>>>>>> <usrp-users@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 <
>>>>>>>>>>> chao...@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@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/67efcf13/attachment-0001.html>

------------------------------

Message: 8
Date: Fri, 12 Dec 2014 16:10:13 -0800
From: Ian Buckley <i...@ionconcepts.com>
To: Isen I-Chun Chao <chao...@gmail.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Question on using ChipScope at X310
Message-ID: <f2e8945d-2a58-4d84-8cb0-66dfe85cb...@ionconcepts.com>
Content-Type: text/plain; charset="utf-8"

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@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.chaudh...@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.chaudh...@ettus.com
> 
> On Fri, Dec 12, 2014 at 3:49 PM, Isen I-Chun Chao <chao...@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.chaudh...@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, y
 ou 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.chaudh...@ettus.com
> 
> On Tue, Dec 9, 2014 at 10:09 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
> 
> On Tue, Dec 9, 2014 at 12:20 PM, Isen I-Chun Chao <chao...@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.chaudh...@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.chaudh...@ettus.com
> 
> On Mon, Dec 8, 2014 at 1:35 PM, Isen I-Chun Chao via USRP-users 
> <usrp-users@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.pend...@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@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.chaudh...@ettus.com
> 
> On Fri, Nov 28, 2014 at 6:34 PM, Isen I-Chun Chao via USRP-users 
> <usrp-users@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 <chao...@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_chainand 
> 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 ofradio.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@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
> 
> 
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> 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/20141212/63bde6d7/attachment-0001.html>

------------------------------

Subject: Digest Footer

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


------------------------------

End of USRP-users Digest, Vol 52, Issue 15
******************************************