Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: unexpected spikes at multiples of 10Mhz in spectrum
(Marcus M?ller)
2. Re: unexpected spikes at multiples of 10Mhz in spectrum
(Andy Walls)
3. Re: Octoclock updating firmware & change ip (Pol Henarejos)
4. Re: [RFNoC] X310 timeout during uhd_usrp_probe (Jonathon Pendlum)
5. Re: How do I turn off one of the radios in rfnoc-radio-redo
and how can I use the debug UART? (Jonathon Pendlum)
6. Re: rfnoc-radio-redo DDC block test (Jonathon Pendlum)
7. Re: How to use DDR memory on E310 RFNOC version (Jonathon Pendlum)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Jun 2016 15:50:02 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] unexpected spikes at multiples of 10Mhz in
spectrum
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Mei Leng,
just for our complete understanding: these spikes are in the spectrum of
everything you /send/ with the USRP, or in everything that you /receive/?
Best regards,
Marcus
On 06/20/2016 08:08 AM, Mei Leng via USRP-users wrote:
> Hi, list:
>
> We recently purchased one new NI-USRP 2953R, and in our tests, we
> found some strange spikes in the signal spectrum at all frequencies
> multiple of 10 MHz (as shown in the attached pic), it looks like some
> kind of harmonics, but we cannot figure out where it came from. Does
> anyone have similar observations?
>
> The specific settings are: NI-USRP 2953R + CBX daughter board, the
> receiving center frequency is 1.6 GHz (we actually tried different
> frequencies from 1.2 GHz to 3 GHz, and they all have similar spikes).
>
>
> Regards,
>
> Mei
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/db510bd6/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 20 Jun 2016 10:13:20 -0400
From: Andy Walls <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] unexpected spikes at multiples of 10Mhz in
spectrum
Message-ID: <1466432000.3024.20.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2016-06-20 at 09:44 -0400, [email protected]
wrote:
> Message: 5
> Date: Mon, 20 Jun 2016 14:08:33 +0800
> Hi, list:
>
> We recently purchased one new NI-USRP 2953R, and in our tests, we
> found
> some strange spikes in the signal spectrum at all frequencies multiple
> of
> 10 MHz (as shown in the attached pic), it looks like some kind of
> harmonics, but we cannot figure out where it came from. Does anyone
> have
> similar observations?
It's probably 10.23 MHz:
https://en.wikipedia.org/wiki/GPS_signals#Frequency_information
*If* you have no qualms about and fully understand the risks of touching
operating electronics equipment:
Put on an ESD wrist strap, touch the metal case of the GPSDO with your
finger, and watch the level of the harmonics change.
At least that's my observation with a B210 exhibiting similar symptoms.
-Andy
> The specific settings are: NI-USRP 2953R + CBX daughter board, the
> receiving center frequency is 1.6 GHz (we actually tried different
> frequencies from 1.2 GHz to 3 GHz, and they all have similar spikes).
>
>
> Regards,
>
> Mei
------------------------------
Message: 3
Date: Mon, 20 Jun 2016 16:39:46 +0200
From: Pol Henarejos <[email protected]>
To: Michael West <[email protected]>
Cc: Nicholas Corgan <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Octoclock updating firmware & change ip
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Dear Nikolas and Michael,
I uploaded the bootloader through Atmel debugger and now the device
works perfectly.
Thank you four your support.
Best regards,
Pol Henarejos
Researcher, MSc
[email protected]
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
El 15/6/2016 a les 19:49, Michael West ha escrit:
> Hi Pol,
>
> If the bootloader is loaded, the internal, external, and status LEDs
> will all be on for one second upon power up. If you only see the
> internal and status LEDs, the bootloader is not loaded and the Octoclock
> is booting directly into the firmware.
>
> Regards,
> Michael
>
> On Jun 14, 2016 11:05 PM, "Pol Henarejos" <[email protected]
> <mailto:[email protected]>> wrote:
>
> Dear Nikolas and Michael,
>
> I guess I do have the bootloader. Indeed, I can ping to 192.168.10.3
> and two LED's in the left column (Internal and Status LED's) are
> turn on. Is it right?
>
> Thank you.
>
>
> Pol Henarejos
> Researcher, MSc
>
> [email protected] <mailto:[email protected]>
>
> Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels, Barcelona (Spain)
> Tel: +34 93 645 29 00 Ext: 2177
> <tel:%2B34%2093%20645%2029%2000%20%20Ext%3A%202177>
>
> Fax. +34 93 645 29 01 <tel:%2B34%2093%20645%2029%2001>
> www.cttc.es <http://www.cttc.es>
>
> El 14/6/2016 a les 22:43, Michael West ha escrit:
>
> Hi Pol,
>
> What Nicholas is asking is if your Octoclock has the
> bootloader. Since
> the image loader reported "-- Resetting into
> bootloader...failed.", it
> seems like your Octoclock is missing the bootloader. Upgrading the
> firmware with uhd_image_loader will not work if the bootloader
> is not
> present. Loading the bootloader requires an AVR programmer and
> avrdude
> (Linux) or WinAVR (Windows). The instructions to load the
> bootloader
> can be found in the UHD manual here
> <http://files.ettus.com/manual/page_octoclock.html#bootloader>.
>
>
> Regards,
> Michael
>
> On Tue, Jun 14, 2016 at 1:30 PM, Nicholas Corgan via USRP-users
> <[email protected] <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
>
> Apologies for the delayed response.
>
> When you power on your OctoClock-G, do all three LED's in
> the left
> column light up, or does only the Internal LED light up?
>
> On Wed, Jun 1, 2016 at 6:30 AM, Pol Henarejos via USRP-users
> <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
>
> Dear all,
>
> Recently we acquired an Octoclock-G. When I try to
> upgrade the
> firmware to the newest image, I get the following error:
>
> phenarejos@pc :/usr/local/lib/uhd/utils$ sudo
> uhd_image_loader
> --args="type=octoclock,addr=192.168.10.3"
> linux; GNU C++ version 4.9.2; Boost_105500;
> UHD_003.009.002-0-gf18abe54
>
> Unit: OctoClock (192.168.10.3)
> Firmware: /usr/local/share/uhd/images/octoclock_r4_fw.hex
> -- Resetting into bootloader...failed.
> Error: RuntimeError: Failed to reset OctoClock.
>
> And no additional messges.
>
> Plus, when I try to change the default IP I get:
>
> phenarejos@pc :/usr/local/lib/uhd/utils$
> ./octoclock_burn_eeprom
> --args="addr=192.168.10.3"
>
> --values="ip-addr=10.1.1.10,netmask=255.0.0.0,gateway=10.1.1.1"
> linux; GNU C++ version 4.9.2; Boost_105500;
> UHD_003.009.002-0-gf18abe54
>
> Creating OctoClock device from args: addr=192.168.10.3
> -- Opening an OctoClock device...
> -- Detecting internal GPSDO...No GPSDO found
>
> UHD Warning:
> Device reports that it has a GPSDO, but we cannot
> communicate
> with it.
>
> -- Detecting external reference...false
> -- Detecting switch position...Prefer external
> -- Device is using internal reference
>
> Fetching current settings from EEPROM...
> EEPROM ["ip-addr"] is "192.168.10.3"
> EEPROM ["netmask"] is "255.255.255.0"
> EEPROM ["gateway"] is "192.168.10.1"
>
> Setting EEPROM ["ip-addr"] to "10.1.1.10"...
> Setting EEPROM ["netmask"] to "255.0.0.0"...
> Setting EEPROM ["gateway"] to "10.1.1.1"...
> Error: RuntimeError: Error writing to OctoClock EEPROM.
>
> Could someone help me to update and change IP of the
> octoclock?
>
> Thank you so much.
>
> --
> Pol Henarejos
> Research Engineer, MSc
> [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
>
>
> Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
> Engineering Unit
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels
> Tel: +34 93 396 71 70 Ext: 2177
> <tel:%2B34%2093%20396%2071%2070%20Ext%3A%202177>
> <tel:%2B34%2093%20396%2071%2070%20Ext%3A%202177>
> Fax. +34 93 645 29 01 <tel:%2B34%2093%20645%2029%2001>
> <tel:%2B34%2093%20645%2029%2001>
> www.cttc.es <http://www.cttc.es> <http://www.cttc.es>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>
>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Nicholas Corgan
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3741 bytes
Desc: Signatura criptogr??fica S/MIME
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/4c94d4c9/attachment-0001.p7s>
------------------------------
Message: 4
Date: Mon, 20 Jun 2016 09:47:53 -0500
From: Jonathon Pendlum <[email protected]>
To: "Collins, Richard" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] X310 timeout during uhd_usrp_probe
Message-ID:
<cagdo0uqa348vmv4e2+peswe4o74ovpzxuilgfh-utroycgz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Richard,
The issue appears to be on the software side. It assumes there are two DDC
chains per DDC block instance. For now, try setting the DDC module
parameter NUM_CHAINS to 2.
Jonathon
On Wed, Jun 15, 2016 at 12:43 PM, Collins, Richard <
[email protected]> wrote:
> Jonathon,
>
> Thanks for the quick reply! That sounds good.
> I was wondering if it would help if I ran a make cleanall first, and
> re-generated. I'm doing that now on one computer, but since it'll take a
> while, I'm going to let it run through.
> Again, thanks for the heads up. I appreciate what you and Martin Braun
> (and whomever else) are doing, and have been wanting to get into using
> RFNoC for some time now.
>
>
> Richard
>
> On Wed, Jun 15, 2016 at 12:39 PM, Jonathon Pendlum <
> [email protected]> wrote:
>
>> Hi Richard,
>>
>> It looks like the DDC RFNoC block may have an issue. I'm looking into it.
>> For now, don't instantiate it in a design. If you run into other issues,
>> let me know.
>>
>>
>>
>> Jonathon
>>
>> On Wed, Jun 15, 2016 at 10:37 AM, Collins, Richard via USRP-users <
>> [email protected]> wrote:
>>
>>>
>>> Hello,
>>>
>>> The error:
>>>
>>> I'm using rfnoc-radio-redo, and here is the header that's printed out
>>> when using uhd:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_003.010.rfnoc-radio-redo-549-geb3036f6
>>>
>>> When I run uhd_usrp_probe, it gets most of the way through listing all
>>> the RFNoC info, waits for a second or two, and times out with this error:
>>>
>>> Error: EnvironmentError: IOError: Radio ctrl (CE_09_Port_192) no
>>> response packet - AssertionError: bool(buff)
>>> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>>> at /home/ninja/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
>>>
>>> The whole output can be found at http://pastebin.com/9rWpk1TP .
>>>
>>> What I did to get here:
>>>
>>> Building a default bitstream (according to
>>> https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started#building-an-image-with-rfnoc
>>> ) was succesful, and ran successfully (I was able to run the
>>> rfnoc_fosphor.grc example just fine). I also wanted to be able to use a
>>> couple different (standard) Noc Blocks. I edited rfnoc_ce_auto_inst_x310.v
>>> with the changes that can be seen by the output of
>>> "*diff rfnoc_ce_auto_inst_x310.v.default rfnoc_ce_auto_inst_x310.v*":
>>> 48c48
>>> < noc_block_null_source_sink inst_noc_block_null_source_sink (
>>> ---
>>> > noc_block_logpwr inst_noc_block_logpwr (
>>> 69c69
>>> < noc_block_vector_iir inst_noc_block_vector_iir (
>>> ---
>>> > noc_block_ddc inst_noc_block_ddc (
>>>
>>> The whole rfnoc_ce_auto_inst_x310.v file that I'm using can be found at
>>> http://pastebin.com/kNYrfRTZ .
>>>
>>> After changing rfnoc_ce_auto_inst_x310.v, I ran "*source setupenv.sh*",
>>> followed by a "*make X310_RFNOC_HGS*" (which completed successfully),
>>> programmed the X310 with: *uhd_image_loader
>>> --args="type=x300,addr=192.168.40.2" --fpga-path="/home/*<user>
>>> */uhd/fpga-src/usrp3/top/x300/build/usrp_x310_fpga_RFNOC_HGS.bit"* ,
>>> and restarted the X310. It responds to pings and uhd_find_devices, but
>>> gives the same error as above when trying to run a gr-ettus rfnoc example.
>>>
>>> Not knowing any better, I also tried re-building uhd and gr-ettus to see
>>> if that would help, as well as rebooting the computer, and I still get the
>>> same error. Any suggestions?
>>>
>>> Richard
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/89bbe4c9/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 20 Jun 2016 10:24:32 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do I turn off one of the radios in
rfnoc-radio-redo and how can I use the debug UART?
Message-ID:
<cagdo0uqre5a6jwjsmg0sggckq-aqwzohzkuzxuh1ylx2kjo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
>From the HDL perspective, setting NUM_CHANNELS = 1 on
noc_block_radio_core.v should work without any issues. However, I haven't
tested it with UHD.
The DELETE_DSP defines will be cleaned up. Since the DSP has been separated
out as part of radio redo, they have no meaning.
The debug UART is for the ZPU. It is useful if you are debugging or write
custom ZPU code.
Jonathon
On Wed, Jun 15, 2016 at 11:41 AM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> I am assuming that I un-comment out one of the lines in the
> /top/x300/Makefile to turn off one of the radios. It says it is
> experimental. Is it more robust now? I think this only applies to the
> DSP's, but not removing the actual radio? I want to remove one of the
> radios to save space for someday moving my code over to the much smaller
> E310.
>
>
> Also I noticed a UART is available for debug. Have you found that useful?
>
> Here is the portion in the Makefile:
>
>
> # Debug Options
> # Uncomment the following lines to build radio's with no DSP's
> (experimental!)
> #OPTIONS += DELETE_DSP0=1
> #OPTIONS += DELETE_DSP1=1
> # Uncomment the following line to add a debug UART on GPIO 10 & 11
> #OPTIONS += DEBUG_UART=1
>
> Here is what I get when I uhd_usrp_probe:
>
> -- ========== Full list of RFNoC blocks: ============
> -- * 0/Radio_0
> -- * 0/Radio_1
> -- * 0/FIFO_0
> -- * 0/MovingAverage_0
> -- * 0/Receiver_0
> ?
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/4bd1a76b/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 20 Jun 2016 10:33:06 -0500
From: Jonathon Pendlum <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-radio-redo DDC block test
Message-ID:
<CAGdo0uSm59m4Ggv=_ouu_yumdkxkhz3zytjk_vcyawc_2op...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Nick,
Try setting NUM_CHAINS to 2 on the DDC module. The software right now
assumes two chains, but by default NUM_CHAINS is set to 1.
On Mon, Jun 13, 2016 at 12:39 PM, Nick Foster <[email protected]> wrote:
> On Mon, Jun 13, 2016 at 10:37 AM Jonathon Pendlum <
> [email protected]> wrote:
>
>> This is a new block and still not officially "released," though it should
>> work. What block settings are you using, just the default ones in the GRC
>> files?
>>
>
> Yep, just vanilla rfnoc_ddc from radio-redo branch of gr-ettus.
>
>
>> Are you using 10GigE or 1GigE?
>>
>
> 1GigE
>
>
>> Was this the first run or a subsequent run?
>>
>
> Both produce identical results.
>
> --n
>
>
>>
>>
>>
>> Jonathon
>>
>> On Thu, Jun 9, 2016 at 10:06 PM, Nick Foster via USRP-users <
>> [email protected]> wrote:
>>
>>> Trying to get the gr-ettus/examples/rfnoc_ddc.grc example working, and
>>> getting the following:
>>>
>>> -- [RFNOC] ------- Block Setup -----------
>>> -- SEND (SID: 00:1f>02:a0)...Setting up NoC-Shell Control for port #0
>>> (SID: 00:1f>02:a0)...OK
>>> -- Port 160: Found NoC-Block with ID DDC0000000000000.
>>> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
>>> -- Reading XML file:
>>> /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
>>> -- SEND (SID: 00:20>02:a1)...Setting up NoC-Shell Control for port #1
>>> (SID: 00:20>02:a1)...OK
>>> -- [RFNoC Factory] block_ctrl_base::make()
>>> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
>>> -- Reading XML file:
>>> /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
>>> -- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
>>> -- block_ctrl_base()
>>> -- base_path = "/home/nick/clabs/target/share/uhd/rfnoc"
>>> -- Reading XML file:
>>> /home/nick/clabs/target/share/uhd/rfnoc/blocks/ddc.xml
>>> -- Found valid blockdef
>>> -- NOC ID: 0xDDC0000000000000 Block ID: 0/DDC_0
>>> -- [0/DDC_0] block_ctrl_base::clear()
>>> -- node_ctrl_base::clear()
>>> -- [0/DDC_0] block_ctrl_base::_clear()
>>> -- [0/DDC_0] block_ctrl_base::_clear()
>>> Traceback (most recent call last):
>>> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
>>> line 281, in <module>
>>> main()
>>> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
>>> line 269, in main
>>> tb = top_block_cls()
>>> File "/home/nick/clabs/clabs_15/gr-ettus/examples/rfnoc/rfnoc_ddc.py",
>>> line 66, in __init__
>>> self.device3 = device3 = ettus.device3(uhd.device_addr_t(
>>> ",".join(("type=x300", "")) ))
>>> File
>>> "/home/nick/clabs/target/lib/python2.7/dist-packages/ettus/ettus_swig.py",
>>> line 1855, in make
>>> return _ettus_swig.device3_make(*args, **kwargs)
>>> RuntimeError: EnvironmentError: IOError: [0/DDC_0] sr_read64() failed:
>>> EnvironmentError: IOError: Radio ctrl (CE_07_Port_160) no response packet -
>>> AssertionError: bool(buff)
>>> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>>> at
>>> /home/nick/clabs/clabs_15/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:203
>>>
>>>
>>> The DDC is a fairly complex block -- any ideas where to look for this
>>> one?
>>>
>>> --n
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/e8cd3b8f/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 20 Jun 2016 10:50:02 -0500
From: Jonathon Pendlum <[email protected]>
To: Weidong Wang <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How to use DDR memory on E310 RFNOC version
Message-ID:
<cagdo0us+iljyoyb7cjy_s5nnuovbhrlmirmf1wb+8w6qcbw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Weidong,
You could use that DDR instantiation as a starting point. You will need to
interface the MIG instance with Noc Shell or AXI Wrapper.
Jonathon
On Fri, Apr 29, 2016 at 2:37 PM, Weidong Wang via USRP-users <
[email protected]> wrote:
> Hi all,
>
> I want to access the DDR memory on E310 to store data in RFNOC blocs. I
> only find these codes for general version of FPGA on this page:
>
>
> https://github.com/EttusResearch/fpga/commit/1e6182463c7bf8ca534d91634f703d5dbfd820d6
>
> Could I just add these codes to the same files of RFNOC to use the DDR
> memory?
>
> Thanks,
>
> Weidong
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/36be9e7f/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 70, Issue 21
******************************************
