Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 114, Issue 33

[Ian Buckley]

The Verilog source code for the various USRP's is included in the UHD git 
repository under uhd/fpga.
DIfferent models of USRP use different mechanisms to upload new FPGA designs, 
the N2x0 for example burn their images via ethernet, the USRP2 uses an SDcard 
etc. All USRP's can also be programmed via the JTAG interface, but this would 
not be a normal design flow for adding incremental changes to the existing 
designs.
You will also need the appropriate Xilinx (or Altera for USRP1) tools to build 
and simulate FPGA designs from Verilog source. These are freely downloadable 
from the manufacturer for the smaller FPGA models, but you will need to by a 
commercial license for the bigger FPGA sizes (for example the N210 uses an FPGA 
that need purchased tools)
-Ian

On May 31, 2012, at 6:07 PM, Derrick Ho wrote:

> The usrp has an fpga with some extra room in it.  I would like to use that 
> space.
> 
> However I do no know which port is used to program this.
> 
> Further more, where can I get the source code that was used to program my 
> fpga ? I don't want to risk getting the wrong
> Source code and breaking the devices functionality.
> 
> Derrick Ho
> 
> On May 31, 2012, at 9:00 AM, address@hidden wrote:
> 
>> Send Discuss-gnuradio mailing list submissions to
>>   address@hidden
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>   https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> or, via email, send a message with subject or body 'help' to
>>   address@hidden
>> 
>> You can reach the person managing the list at
>>   address@hidden
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Discuss-gnuradio digest..."
>> 
>> 
>> Today's Topics:
>> 
>>  1. Re: [USRP-users] what is the largest data    transfer rate
>>     between fpga and overo in e100 (Marcus D. Leech)
>>  2. Re: [USRP-users] what is the largest data transfer rate
>>     between fpga and overo in e100 (Philip Balister)
>>  3. File sink file size mismatch problem. (Josh Stevens)
>>  4. How to dynamically stop the host PC receiving samples from
>>     USRP and restart it again without touching the top block? (Alex Zhang)
>>  5. QAM Mod and QAM Demod block in GRC (jiajue ou)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Wed, 30 May 2012 13:03:34 -0400
>> From: "Marcus D. Leech" <address@hidden>
>> To: address@hidden
>> Subject: Re: [Discuss-gnuradio] [USRP-users] what is the largest data
>>   transfer rate between fpga and overo in e100
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> 
>>> There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 
>>> signal and 2 clock pins all free to be used in the FPGA. Searching for 
>>> "mictor" in the archive of this forum will find other posts about this.
>>> 
>>> However I do want to drive home the point  that you are unlikely to 
>>> find an ARM processor currently that is capable of doing anything 
>>> useful directly with RF data at bandwidths greater than which the E100 
>>> is capable or indeed one with a flexible physical interface that can 
>>> support 60MB/s....you're clearly in the realm of high-end DSP 
>>> processors at those rates.
>>> 
>> Well, keep in mind that if the goal is really 60MB/s, rather than 
>> 60Msps, that's only about a factor of 5 beyond what an ARM can resonably
>>  do for lightweight processing.
>> 
>> 
>> 
>> 
>> -- 
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>> 
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Wed, 30 May 2012 13:19:29 -0400
>> From: Philip Balister <address@hidden>
>> To: Ian Buckley <address@hidden>
>> Cc: discuss-gnuradio <address@hidden>,
>>   address@hidden
>> Subject: Re: [Discuss-gnuradio] [USRP-users] what is the largest data
>>   transfer rate between fpga and overo in e100
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> On 05/30/2012 11:46 AM, Ian Buckley wrote:
>>> There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 
>>> signal and 2 clock pins all free to be used in the FPGA. Searching for 
>>> "mictor" in the archive of this forum will find other posts about this.
>>> 
>>> However I do want to drive home the point  that you are unlikely to find an 
>>> ARM processor currently that is capable of doing anything useful directly 
>>> with RF data at bandwidths greater than which the E100 is capable or indeed 
>>> one with a flexible physical interface that can support 60MB/s....you're 
>>> clearly in the realm of high-end DSP processors at those rates.
>> 
>> If you need to do the processing on an ARM, you should research this
>> company:
>> 
>> http://www.calxeda.com/products/energycards/quadnode
>> 
>> Philip
>> 
>>> 
>>> 
>>> On May 30, 2012, at 8:02 AM, Almohanad Fayez wrote:
>>> 
>>>> I don't believe there's a document for this it's more of an exercise left 
>>>> for the motivated user.
>>>> 
>>>> On May 30, 2012 6:27 AM, "Page Jack" <address@hidden> wrote:
>>>> Hi Almohanad ,
>>>> thanks for this information, can you provide more detail or is there any 
>>>> doc?
>>>> 
>>>> On 5/30/12, Almohanad Fayez <address@hidden> wrote:
>>>>> If memory serves correctly the n200 or the usrp 2 has an fpga expansion
>>>>> interface to some xilinx development platform which you might be able to
>>>>> use to create a custom solution to serve your needs.
>>>>> 
>>>>> Al
>>>>> On May 29, 2012 6:17 PM, "Page Jack" <address@hidden> wrote:
>>>>> 
>>>>>> I don't want to using a ethernet wire to connect N series to an ARM
>>>>>> board.
>>>>>> anyone have tried
>>>>>> build N series with ARM or DSP in one board which means the ethernet line
>>>>>> between N and
>>>>>> the processor is on PCB.
>>>>>> 
>>>>>> On Wed, May 30, 2012 at 6:24 AM, Philip Balister
>>>>>> <address@hidden>wrote:
>>>>>> 
>>>>>>> On 05/25/2012 09:18 PM, Page Jack wrote:
>>>>>>>> Hi Philip,
>>>>>>>> How does the conclusion be made that ARM can not swallow the current
>>>>>>>> max data transfer rate? I need to build a project that need to process
>>>>>>>> 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or
>>>>>>>> use dsp on the omap?
>>>>>>> 
>>>>>>> 60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We
>>>>>>> have worked hard on configuring the GPMC interface and this figure is
>>>>>>> basically an order of magnitude more then the hardware will support.
>>>>>>> 
>>>>>>> You need to look at the N series with Gig-E, or do the high rate
>>>>>>> processing in the FPGA.
>>>>>>> 
>>>>>>> Philip
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> On 5/25/12, Philip Balister <address@hidden> wrote:
>>>>>>>>> On 05/24/2012 09:46 PM, Page Jack wrote:
>>>>>>>>>> Thanks Ben,
>>>>>>>>>> does e100 use EMIF to transfer sample data between FPGA and ARM? If
>>>>>>>>>> so
>>>>>>>>>> the
>>>>>>>>>> data rate should be able to improved.
>>>>>>>>>> Anyone have tried to improve the data rate?
>>>>>>>>> 
>>>>>>>>> EMIF is basically identical to GPMC. The interface uses DMA to move
>>>>>>> data
>>>>>>>>> in 2K chunks between the FPGA and memory. This is the largest
>>>>>>>>> transfer
>>>>>>>>> possible due to how we connected the address and data lines
>>>>>>>>> 
>>>>>>>>> My impression of the current limiting factor is interrupt response
>>>>>>> time.
>>>>>>>>> There is probably some room for small improvements, but as Ben notes,
>>>>>>> we
>>>>>>>>> are already collecting data faster than the ARM can swallow it.
>>>>>>>>> 
>>>>>>>>> Philip
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Regards
>>>>>>>>>> 
>>>>>>>>>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn <address@hidden>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> The CPU sets up the initial DMA parameters, but from then on, it's
>>>>>>> pure
>>>>>>>>>>> DMA.  No CPU is required.
>>>>>>>>>>> 
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ben
>>>>>>>>>>> ----------------------------
>>>>>>>>>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research,
>>>>>>>>>>> LLC<http://www.ettus.com/>
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, May 23, 2012 at 5:55 PM, Page Jack <address@hidden>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Thanks, does the ARM memory bus use DMA or it eat cpu?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
>>>>>>>>>>>> <address@hidden>wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Page -
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The memory bus to the ARM provides 40 MBytes / second.  This is
>>>>>>> used
>>>>>>>>>>>>> for
>>>>>>>>>>>>> streaming samples, as controlled via software.  Currently, UHD
>>>>>>> supports
>>>>>>>>>>>>> 16
>>>>>>>>>>>>> bit and 8 bit samples for TX & RX.  The GPMC can only going to
>>>>>>> talk to
>>>>>>>>>>>>> one
>>>>>>>>>>>>> slave at a time; the possible slaves are TX, RX, and ethernet.
>>>>>>>>>>>>> So
>>>>>>> you
>>>>>>>>>>>>> can
>>>>>>>>>>>>> only be sending TX samples, receiving RX samples, or
>>>>>>>>>>>>> communicating
>>>>>>> via
>>>>>>>>>>>>> ethernet.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thus, doing the math with the numbers above, you can stream:
>>>>>>>>>>>>> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps
>>>>>>>>>>>>> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps
>>>>>>>>>>>>> 
>>>>>>>>>>>>> What you choose to do with this data is obviously up to you. It
>>>>>>>>>>>>> is
>>>>>>>>>>>>> very
>>>>>>>>>>>>> easy to try to do more processing than the ARM can handle, in
>>>>>>>>>>>>> which
>>>>>>>>>>>>> case
>>>>>>>>>>>>> samples will start getting thrown out by UHD.  Thus, you can
>>>>>>> typically
>>>>>>>>>>>>> process between 4 and 8 MHz of baseband bandwidth, depending on
>>>>>>> your
>>>>>>>>>>>>> application.  If you are willing to dig deep into the code to
>>>>>>>>>>>>> make
>>>>>>> NEON
>>>>>>>>>>>>> and
>>>>>>>>>>>>> C64 optimizations, you can improve the performance dramatically.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Ben
>>>>>>>>>>>>> ----------------------------
>>>>>>>>>>>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research,
>>>>>>>>>>>>> LLC<http://www.ettus.com/>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, May 22, 2012 at 7:47 PM, Page Jack
>>>>>>>>>>>>> <address@hidden>wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> I want to know the overo model used in e100 and the largest data
>>>>>>>>>>>>>> transfer rate between fpga  and overo in e100.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Regards!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> USRP-users mailing list
>>>>>>>>>>>>>> address@hidden
>>>>>>>>>>>>>> 
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> USRP-users mailing list
>>>>>>>>>> address@hidden
>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> address@hidden
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> address@hidden
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>> 
>>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> address@hidden
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> 
>>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Wed, 30 May 2012 15:04:48 -0400
>> From: Josh Stevens <address@hidden>
>> To: address@hidden
>> Subject: [Discuss-gnuradio] File sink file size mismatch problem.
>> Message-ID:
>>   <address@hidden>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> Hello All,
>> 
>>     A couple of days ago i had installed a GNURadio digital image
>> processing block that makes an image source and sink block available as
>> displayed in the image below.
>> *Resource* : https://github.com/a-w-s/GNURadio-DIP
>> *Flowgraph* : http://i.imgur.com/1lJzD.png
>> 
>> The output of the image source and the input to the image sink are "floats"
>> only and nothing else. I tried to collect pixel information into a file
>> sink and i am successful at that but the problem comes in when the size of
>> the input file size is not the same as the size of the file sink output.
>> 
>> The image is a basic black and white test image called lena.bmp whose file
>> size is 65.0 KB. The link to which is also provided below ,
>> *Resource to Image :*
>> https://www.google.com/search?q=lena+256+x+256&hl=en&prmd=imvns&source=lnms&tbm=isch&ei=_G7GT7vkC4rs8wSG99SaBg&sa=X&oi=mode_link&ct=mode&cd=2&sqi=2&ved=0CD8Q_AUoAQ&biw=1280&bih=827
>> 
>> The file size of the received file (file sink) is 76.0 KB.
>> 
>> The reason why I pay more attention to this is because i intend to
>> calculate BER / Pixel Error Rate which would take into account a reference
>> stream which in this case would be the file with the extra bits , and Image
>> sink output ( or the demodulated output) .
>> 
>> Please feel free to ask me any questions that one might have .
>> 
>> Thanks and regards,
>> Josh.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120530/02e0b9e0/attachment.html>
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date: Wed, 30 May 2012 20:33:26 -0500
>> From: Alex Zhang <address@hidden>
>> To: gnuradio mailing list <address@hidden>
>> Subject: [Discuss-gnuradio] How to dynamically stop the host PC
>>   receiving samples from USRP and restart it again without touching the
>>   top block?
>> Message-ID:
>>   <address@hidden>
>> Content-Type: text/plain; charset="windows-1252"
>> 
>> Hi,
>> 
>> In my applications, after the flow graph is initialized, I need to
>> dynamically control the receiving of the USRP samples, i.e, at time T1, I
>> want the USRP to transfer the received samples to PC, while in T2, I do not
>> allow the PC to receive these samples.
>> Stop receiving the unusing packets from USRP can save the traffic over
>> ethernet and decrease the demands of processing resource on host PC.
>> 
>> the gr_mute block seems only suppress the incoming packets to further
>> processing, but these unusing samples can still come into the flow graph.
>> 
>> Also, the tb.run and tb.wait can be executed more than twice as wish, but
>> it seems to be not so flexible. It would be good if there some commands
>> called to control the block of uhd.usrp_source to achieve such purpose?
>> -- 
>> 
>> Alex,
>> *Dreams can come true ? just believe.*
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120530/c78fba1c/attachment.html>
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date: Thu, 31 May 2012 14:41:36 +0800
>> From: "jiajue ou" <address@hidden>
>> To: <address@hidden>
>> Subject: [Discuss-gnuradio] QAM Mod and QAM Demod block in GRC
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> Hi all, 
>> 
>> 
>> 
>> I'm working on an experiment which needs to modify qam modulation block in
>> gnuradio. But I cannot find the source C++ file the qam blocks use. e.g.,
>> OFDM demod block uses digital_ofdm_frame_sink in
>> gnuradiobuild/gnuradio/gr-digital/lib. What about qam blocks? 
>> 
>> Thank you for your help!
>> 
>> 
>> 
>> Best,
>> 
>> jia
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120531/3cf4a81d/attachment.html>
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> 
>> End of Discuss-gnuradio Digest, Vol 114, Issue 33
>> *************************************************
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio