[Top][All Lists]

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

Re: [Discuss-gnuradio] FPGA usage in USRP E100

From: Alexander Chemeris
Subject: Re: [Discuss-gnuradio] FPGA usage in USRP E100
Date: Tue, 25 Jan 2011 00:38:18 +0300

Hi Matt,

On Mon, Jan 24, 2011 at 21:42, Matt Ettus <address@hidden> wrote:
> On 01/24/2011 10:30 AM, Alexander Chemeris wrote:
>> Is there any high-level description of what processing is done in FPGA
>> in E100 and is there any optional blocks which can be removed? I see
>> that even aeMB is present in the project - is it used or it is not
>> compiled in?
> There is no aeMB in the E100, although it is in the Makefiles since we share
> the makefiles among the various projects.  The current E100 FPGA has a
> similar structure to the USRP2 except that the aeMB is replaced by an
> interface to the GPMC.  So there are the usual digital up and
> downconverters, decimators, and interpolators for DSP, and SPI, I2C,
> wishbone, etc. for control.  The u1e_core.v file is the place to look for
> the top level.

Great. So the makefile confused me.

>> I need to understand how much resource is left for custom DSP
>> processing in the FPGA. We're working on an (open-source) WiMAX
>> receiver and want to offload a lot of work to FPGA. But from design
>> summary (below) it looks like FPGA is pretty much crowded already.
> The logic area is 60-70% free.  You should ignore the "number of occupied
> slices" metric as that is not really meaningful.
> 81% of the DSP units and 52% of the memory are free.  The bulk of the memory
> currently used is for buffering and can be trimmed if you need more of it.
> Additionally, in March or April we will have the E110 which is the same
> except that it uses an even bigger FPGA, the -3400 version.

Yes, I know about E110 and I'm looking forward to try it out, but
we'll start with E100 as we don't want to wait until March/April.

We're also looking into using USRP N210 and processing data with
external DSP like Freescale StarCore MSC8156. But we keep this as a
backup plan as it's more expensive and power hungry.

Thank you for your kind answer.

Alexander Chemeris.

reply via email to

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