Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST


Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | DSP designs that exceed provided embedded arithmetic hardware

There are 4 messages in this thread.

You are currently looking at messages 0 to 4.

DSP designs that exceed provided embedded arithmetic hardware - Ken - 2005-03-23 11:41:00

Hi folks,

This question is aimed at those who have created designs including DSP using 
a device family containing dedicated arithmetic silicon (e.g. Xilinx 
DSP48/18x18s/Altera DSP blocks):

On what % of designs you have completed did you run out of dedicated 
arithmetic blocks and have to implement filters in the main logic fabric?

Thanks very much for your time,

Ken






Re: DSP designs that exceed provided embedded arithmetic hardware - Symon - 2005-03-23 12:17:00

Hey Ken,
It's often the other way round for me, sometimes I'd run out of fabric and 
BRAMs for distributed arithmetic DSP unless I used the multipliers for 
boring 'normal' DSP. Of course, all my designs are carefully planned, so I 
never actually run out of resource. Ahem.
Anyway, why do you ask?
Cheers, Syms.
"Ken" <a...@NOSPAM.yahoo.co.uk> wrote in message 
news:d1s68b$u73$02$1...@news.t-online.com...
> Hi folks,
>
> This question is aimed at those who have created designs including DSP 
> using a device family containing dedicated arithmetic silicon (e.g. Xilinx 
> DSP48/18x18s/Altera DSP blocks):
>
> On what % of designs you have completed did you run out of dedicated 
> arithmetic blocks and have to implement filters in the main logic fabric?
>
> Thanks very much for your time,
>
> Ken
>
>
> 


______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: DSP designs that exceed provided embedded arithmetic hardware - Ken - 2005-03-23 15:14:00

> Hey Ken,
> It's often the other way round for me, sometimes I'd run out of fabric and 
> BRAMs for distributed arithmetic DSP unless I used the multipliers for 
> boring 'normal' DSP. Of course, all my designs are carefully planned, so I 
> never actually run out of resource. Ahem.
> Anyway, why do you ask?
> Cheers, Syms.

Hi Syms,

Thanks for your reply.

The general consenus as far as I am aware seems to be that designers will 
want to use dedicated FPGA silicon blocks that will accomplish a given task 
before implementing such tasks on the generic fabric.

I am just curious to see exactly how designers are using the "lego blocks" 
they have available to them hence I thought I would see what the inhabitants 
of this ng do.

Cheers,

Ken








Re: DSP designs that exceed provided embedded arithmetic hardware - info_ - 2005-03-26 08:18:00

Ken wrote:

> Hi folks,
> 
> This question is aimed at those who have created designs including DSP using 
> a device family containing dedicated arithmetic silicon (e.g. Xilinx 
> DSP48/18x18s/Altera DSP blocks):
> 
> On what % of designs you have completed did you run out of dedicated 
> arithmetic blocks and have to implement filters in the main logic fabric?

We've some big DSP applications on VirtexIIs with 100% of multipliers or 100% of Ram 
blocks used (and over 90% of logic used).
In VIIs, this sometimes is tricky since they share ressource, and this can put some 
restrictions on how the blocks (DSP+Ram) can be parameterized to coexist.
You may also find difficult to partition the operators between dedicated and logic 
since the synthesis tool may have a global flag... Manual inference is often the 
solution.
Globally, we've been pleasantly surprised by the routability of very dense arithmetic 
(DSP) designs (both in Xilinx and Altera parts btw).
Last, we're not using (well almost not) ready-made IPs, so we retain control of how 
the operators are inferred (and which variant), so it's probably a safer situation.

Bert Cuzeau