[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] FPGA in USRP

From: Brian Padalino
Subject: Re: [Discuss-gnuradio] FPGA in USRP
Date: Thu, 14 Jun 2007 21:58:41 -0400

On 6/14/07, S Mande <address@hidden> wrote:

Hi All,

 I have worked with VHDL for 3 years and would want to make use my knowledge
to do some research in Software defined Radio.

 I have a very different problem from most of the other postings. I am
actually looking for a 'problem'.

 For the past one month I have been Googling to see the research
problems/constraints of USRP's. There were many different implementation
ideas (of software defined radio's)on the web. But, most of these ideas are
in general (.i.e. different ways to implement software defined radio) and
not related to implementation on USRP. I was looking for research topics
related to USRP. --> But, I didn't find a specific answer as to how FPGA's
power could be harnessed to make USRP a more powerful tool. <--

 I request you members to give your inputs as to what you would want to do
with the existing Altera's Cyclone FPGA on USRP, to make USRP a more
powerful tool!

For all open tickets for the USRP you can check this page:

The inband signaling is already being worked on by Thibaud within the
FPGA.  You can check the inband_lib directory under the usrp/fpga
directory for what he already has working.

There have been a lot of people who want easier access to the digital
IO pins on the daughtercards.

I think Automatic Gain Control within the hardware would probably be a
very good way to figure things out, but I am not sure how daughtercard
dependent that might be.  Matt would have a better idea of the
specifics of how that might want to get done in a generic way.

There have also been a number of people who would like to perform FFTs
within the FPGA instead of bringing the sample stream.  Being able to
mux functionality might be fun, but there probably isn't enough
resources for all of that within the original USRP board.

Moreover, you could always grep for TODO within the Verilog source to
see what features might have to be revisited for optimization.  I
believe the CIC filters are not optimized and can possibly release
maybe 10% of resources if they are optimized.

Obviously other people should chime in as well!  Those are just the
things I can think of off the top of my head.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]