Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 47700

Article: 47700
Subject: Help for Altera's FPGAs' pinout
From: izuazua@ikerlan.es (Itsaso Zuazua)
Date: 2 Oct 2002 06:00:25 -0700
Links: << >>  << T >>  << A >>
Hi,

I have heard that, as a general rule on Xilinx chips, data busses
should be
placed on the sides of the chip and control signals should be placed
on the
top and bottom.  This has something to do with routing resources being
used
more efficiently and itīs closely relationated with the internal
architecture of the FPGA. Is this rule valid also for Alteraīs FPGAs?

             Thanks a lot,



                 Regards,

                               Itsaso.

Article: 47701
Subject: Re: AMD9513 Timer Chip
From: "Allen - Celeritous" <alitton@celeritous.com>
Date: Wed, 02 Oct 2002 14:16:12 GMT
Links: << >>  << T >>  << A >>
Robert,

We are the manufacturers of the CTS9513. If you can send me a more complete
description of the problems you are seeing we will do our best to help. We
can
help or find workarounds for these problems in most cases.

There are some bugs in the CTS9513 and minor differences between it and the
original AMD. As you state, the CTS9513 is an ASIC emulation of the original
AM9513 and as ASICs don't particularly like running asynchronusly many of
the problems can be traced back to too amny asynch evenys happening at once.

In the case you describe, where you are updating the counter "on-the-fly"
this
is particularly true.

As Jonathan said, even the original AMD part had its share of problems.
That is the case anytime you have a totally asynchronus part such as this.

We are working on a new revision of the part that is internally synchronus
and
should get rid of the bugs found in the original and current device. We will
also
offer it as an IP core.

Best Regards.

Allen Litton
CEO
Celeritous Technical Services, Corp
http://www.celeritous.com


"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:BYImWoeaCHA.3472@lucy.doulos.com...
> -----Original Message-----
> From: Robert S. Sierk [mailto:rss@appcongroup.com]
> Subject: AMD9513 Timer Chip

> I am desperately looking for someone who is an expert on the
> AMD9513
[...]
> I'm looking for somebody that knows the intricacies of this
> chip.  The data sheet we have is lousy
[...]

When I worked for AMD for a short spell in the late 80s, the
FAEs there were forever tearing their hair out
a) trying to understand the 9513
b) trying to help customers understand it
c) working around the bugs in it

So it's not impossible you've stumbled on a bug.  If your
data sheet is lousy, I wonder if it's worth trying to find
any of the original AMD appnotes and data sheets?  They were
usually pretty well written.

And it might be of interest for you to know that a certain
well-known and somewhat senior Xilinx HQ apps engineer, who
has been known to post here, was with AMD for a while too :-)

Sorry I can't help you myself.  When I get back home this
weekend I'll trawl through the paper databook archives and
see if I can find anything interesting, if you haven't got
an answer by then.
--
Jonathan Bromley
HDL Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 47702
Subject: Moving average filter
From: Arne Burghardt <Arne.Burghardt@NOSPAMdesy.de>
Date: Wed, 02 Oct 2002 16:52:21 +0200
Links: << >>  << T >>  << A >>
Hi,

i want to implement a moving average filter in my FPGA. That's not the 
big problem, but the window size of the filter should be changeable 
during runtime...
Big problem for me, i have no idea how to do it at the moment :-(
Maybe one of the experts in this group have a helpful link or an idea 
for me ?

Here are some more details:
I have a continous input data stream with 14 bits and a data rate of 
approx. 65 MHz. I have to realize a simple filter, which calculates the 
average value of the last n samples, n=[2..1024]. n is not fixed, but 
should be a register, which i can update during runtime. I would like to 
use a Xilinx Virtex2 FPGA for this task.

Thanks a lot for your help !

   Arne


Article: 47703
Subject: Re: Help for Altera's FPGAs' pinout
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 02 Oct 2002 07:57:35 -0700
Links: << >>  << T >>  << A >>
Itsaso,

Designs generally get placed such that the data flow is from left to
right, and from bottom to top.  Why?

This to do with the way the carry chain is architected (a natural bottom
to top feature).

If the design is not doing any arithmetic, then the data flow may not flow
left to right, or bottom to top.

In Xilinx chips (I can not speak for Altera), one could look at the
placement if completely unconstrained, and see if there is any
organization to it.  I imagaine one can do the same for Altera.

Grouping IOs together is also just good practice, as signals of dissimilar
logic levels and standards interfere with one another if placed near each
other.

So for any particular design, there may be a "better" placement of IOs.
It will not follow such a simple rule as IOs on left and right for data,
control on top and bottom.

I would floorplan the IOs to meet your signal integrity requirements,
followed by your skew control (for fast wide busses), followed by your
printed circuit board layout requirements.  I would not floorplan the IOs
to make the internal routing "better."

In Altera's new product offering, not all IOs are the same, so you MUST
floorplan the IOs that you need carefully, as they can ONLY go to those
pins where they exist, or where the rules let you.

Austin

Itsaso Zuazua wrote:

> Hi,
>
> I have heard that, as a general rule on Xilinx chips, data busses
> should be
> placed on the sides of the chip and control signals should be placed
> on the
> top and bottom.  This has something to do with routing resources being
> used
> more efficiently and itīs closely relationated with the internal
> architecture of the FPGA. Is this rule valid also for Alteraīs FPGAs?
>
>              Thanks a lot,
>
>                  Regards,
>
>                                Itsaso.


Article: 47704
Subject: Re: C\C++ to VHDL Converter
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 2 Oct 2002 15:19:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3D9A76DD.453A4B46@andraka.com>,
Ray Andraka  <ray@andraka.com> wrote:
>>    Synthesis from a C/C++ algorithm is absolutely possible and has been in
>> use for some time. Even "plain vanilla C" algorithms can be used with the
>> right synthesis product.
>
>Show me.  Nothing I've seen can handle C code that was not specifically written
>to create hardware.  I think your next sentence probably validates that as
>well.  Plain vanilla C has nothing in it to support concurrency, and I know of
>no product that can infer that concurrency from existing (not written
>specifically to map to hardware, usually using special extensions) code.

Tim Callahan did his thesis on such a compiler for an environment
(GARP) where you had an FPGA coprocessor.  He was able to get speedup
for some loops, but only after heroic effort on the compiler side.
Hand mapping produced far superior results.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 47705
Subject: Re: Moving average filter
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Wed, 2 Oct 2002 16:40:24 +0100
Links: << >>  << T >>  << A >>
> -----Original Message-----
> From: Arne Burghardt [mailto:Arne.Burghardt@NOSPAMdesy.de]
> Subject: Moving average filter
> 
> I have a continous input data stream with 14 bits and a data rate of 
> approx. 65 MHz. I have to realize a simple filter, which 
> calculates the 
> average value of the last n samples, n=3D[2..1024]. n is not fixed, =
but 
> should be a register, which i can update during runtime.

When I read about this sort of thing I am never exactly sure
what is supposed to happen when n changes... should the average
output update instantly to reflect the new n?

If n can change only by +/- 1 on each clock cycle, I think I
understand how to do it.  But if n can be changed arbitrarily on 
any clock cycle, I don't understand because I think you would
need to re-calculate the sum of n past samples within a single
clock tick...  
-- 
Jonathan Bromley
HDL Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project =
Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 =
1AW, UK
Tel: +44 (0)1425 471223                    mail: =
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: =
http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. =
reserves 
all rights of privilege in  respect thereof. It is intended for the use =
of 
the addressee only. If you are not the intended recipient please delete =
it 
from  your  system, any  use, disclosure, or copying  of this  document =
is 
unauthorised. The contents of this message may contain personal views =
which 
are not the views of Doulos Ltd., unless specifically stated.



Article: 47706
Subject: Re: Moving average filter
From: Arne Burghardt <Arne.Burghardt@NOSPAMdesy.de>
Date: Wed, 02 Oct 2002 18:13:28 +0200
Links: << >>  << T >>  << A >>
For clarification:

If n changes, the output is of course invalid for n samples. It doesn't 
matter in my case. I only need a status flag in a register which tells 
me, if the output is valid or not (simple task to do...).

   Arne

Jonathan Bromley wrote:
> When I read about this sort of thing I am never exactly sure
> what is supposed to happen when n changes... should the average
> output update instantly to reflect the new n?
> 
> If n can change only by +/- 1 on each clock cycle, I think I
> understand how to do it.  But if n can be changed arbitrarily on 
> any clock cycle, I don't understand because I think you would
> need to re-calculate the sum of n past samples within a single
> clock tick...  


Article: 47707
Subject: Re: ANN: Embedded processor for Tcl language
From: ptkwt@shell1.aracnet.com (Phil Tomson)
Date: 2 Oct 2002 16:38:47 GMT
Links: << >>  << T >>  << A >>
In article <uplqnffa9droca@corp.supernews.com>,
Scott Thibault <thibault@gmvhdl.com> wrote:
>AcroDesign Technologies has announced results from its work on an embedded
>processor for the Tcl language.  More information, and a recent presentation
>is available at: http://www.gmvhdl.com/acrodesign/research.html#tob
>
>--Scott Thibault
>AcroDesign Technologies

Hmmmm.... so this is basically a FPGA implementation of the Tcl virtual 
machine? (actually, I wasn't aware that Tcl had a bytecode interpreter, 
but I guess it isn't surprising).

Phil

Article: 47708
Subject: Re: Moving average filter
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Wed, 02 Oct 2002 16:42:55 GMT
Links: << >>  << T >>  << A >>
I have a filter in verilog that I designed to work efficiently
off powers of two.  It's got parameterized intensity
(log(1/indec)/log(2)), bitfield lengths, and extra accuracy bits.
Is that something which you could adjust for your use?
Portlist:  module filter(din, dout, shift, clk, rstn);
(Shift may be tied active high for operation at every clock).

BB
============================================

"Arne Burghardt" <Arne.Burghardt@NOSPAMdesy.de> wrote in message
news:anf17i$8q3et$1@claire.desy.de...
> Hi,
>
> i want to implement a moving average filter in my FPGA. That's not the
> big problem, but the window size of the filter should be changeable
> during runtime...
> Big problem for me, i have no idea how to do it at the moment :-(
> Maybe one of the experts in this group have a helpful link or an idea
> for me ?
>
> Here are some more details:
> I have a continous input data stream with 14 bits and a data rate of
> approx. 65 MHz. I have to realize a simple filter, which calculates the
> average value of the last n samples, n=[2..1024]. n is not fixed, but
> should be a register, which i can update during runtime. I would like to
> use a Xilinx Virtex2 FPGA for this task.
>
> Thanks a lot for your help !
>
>    Arne
>



Article: 47709
Subject: Re: Help for Altera's FPGAs' pinout
From: "Jan Gray" <jsgray@acm.org>
Date: Wed, 2 Oct 2002 09:46:49 -0700
Links: << >>  << T >>  << A >>
Without addressing the specific Altera question, here's another historical
perspective on this Xilinx floorplanning rule-of-thumb.

In the good old days of plentiful TBUFs, the TBUF and horizontal long line
structures also made it practical and efficient to run on-chip 3-state buses
left-to-right across the chip.  For example, see p.21 of
http://fpgacpu.org/papers/j32.pdf or (lower resolution)
http://www3.sympatico.ca/jsgray/sld021.htm, which in an XC4010, exhibits two
32-bit wide buses, one with 11 sources.  If you had off-chip data to move
in/out of such buses, the most efficient use of programmable interconnect
led you to employ the I/Os (and IOB-adjacent TBUFs) at the left or right
edges of the device.

Jan Gray, Gray Research LLC




Article: 47710
Subject: Re: ANN: Embedded processor for Tcl language
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 2 Oct 2002 17:10:22 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <anf7en0ct1@enews3.newsguy.com>,
Phil Tomson <ptkwt@shell1.aracnet.com> wrote:
>Hmmmm.... so this is basically a FPGA implementation of the Tcl virtual 
>machine? (actually, I wasn't aware that Tcl had a bytecode interpreter, 
>but I guess it isn't surprising).

Well, TCL is more a ascii string munging hack, based around textual
replacement, so you could treat the program as a (really ugly)
bytecode.

Why you would WANT to however, is beyond me.  Compile scheme or
something to a nice vanilla uP core and have hardware support for
garbage collection.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 47711
Subject: virtex 2 -5i vs -6
From: shparekh@yahoo.com (S P)
Date: 2 Oct 2002 10:14:01 -0700
Links: << >>  << T >>  << A >>
I was told by xilinx that a virtex xc2v1000 -5i (industrial) part is
the same die as the -6 part.  As we only intend to run these parts in
normal temperature range, a -5i should work in place of -6.

Has anyone had this experience and if so can a bitstream generated for
a -6 part work on -5i.

Thanks.
-sanjay

Article: 47712
Subject: Re: Moving average filter
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 2 Oct 2002 19:49:46 +0200
Links: << >>  << T >>  << A >>
"Arne Burghardt" <Arne.Burghardt@NOSPAMdesy.de> schrieb im Newsbeitrag
news:anf17i$8q3et$1@claire.desy.de...
> Hi,
>
> i want to implement a moving average filter in my FPGA. That's not the
> big problem, but the window size of the filter should be changeable
> during runtime...
> Big problem for me, i have no idea how to do it at the moment :-(
> Maybe one of the experts in this group have a helpful link or an idea
> for me ?
>
> Here are some more details:
> I have a continous input data stream with 14 bits and a data rate of
> approx. 65 MHz. I have to realize a simple filter, which calculates the
> average value of the last n samples, n=[2..1024]. n is not fixed, but
> should be a register, which i can update during runtime. I would like to
> use a Xilinx Virtex2 FPGA for this task.

HAve a look at the xilinx homepage, support section. Go for the TechXclusive
sites, there is one about using SRL in clever ways (Regards to Ken Chapman).
One describes a moving average filter wich does NOT need to add (up to )
1024 samples every clock cycle. This can be easyly addapted to use a
BlockRAM as a delay line.
Good luck.

--
MfG
Falk





Article: 47713
Subject: Re: AMD9513 Timer Chip
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 02 Oct 2002 11:06:49 -0700
Links: << >>  << T >>  << A >>
20 years ago, I knew a lot about this chip.
Now I have forgotten most of it.
There were a number of timing issues.
Go to
google.com
and enter
Am9513.
There are 869 entries. I bet one of them will be useful.

Peter Alfke, ex AMD Applications, 14 to 23 years ago...


Article: 47714
Subject: Re: C\C++ to VHDL Converter
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Wed, 2 Oct 2002 14:13:24 -0400
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote in message
news:3D9A76DD.453A4B46@andraka.com...
>
>
> Brett Cline wrote:
>
> > Hi All-
> >
> >    Synthesis from a C/C++ algorithm is absolutely possible and has been
in
> > use for some time. Even "plain vanilla C" algorithms can be used with
the
> > right synthesis product.
>
> Show me.

Yeah, and show me too.  I've yet to see any benchmarks that show any where
near usable performance and size.  From my experience, you are better off
re-writing it in an HDL, then trying to fight with these tools in both the
size and speed arena.

Why do things that supposedly make your life "easier" end up making them
harder?

> >   To take the algorithm to hardware (RTL Verilog or VHDL) my company
offers
> > a product called "Cynthesizer" for high-level synthesis from SystemC.
We've
> > had a number of customers take generic algorithms (some even from the
web)
> > such as filters, encryption, multimedia, etc. and convert them directly
to
> > RTL Verilog and VHDL. The resulting RTL can be put into any FPGA or ASIC
> > synthesis tool as well as any other tool that operates on RTL.
>
> But at what price?  Is the performance and density reasonably close to a
what a
> skilled hardware designer can accomplish?

Of course not, Ray, you know better than to ask that question ;-)

Regards,

Austin



Article: 47715
Subject: Re: Block Ram Timing Issues
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 02 Oct 2002 11:14:23 -0700
Links: << >>  << T >>  << A >>
The BlockRAM is a static design. You can park the clock High or Low as long as
you want. The timing values are min only.

Peter Alfke, Xilinx Apps
======================
Ho Wong wrote:

> Hmm.. I'm looking at the timing diagram for the Block Ram and I've got a
> question about the clock timing. Data sheets say that for single port ram,
> the maximum time for the clock to go high or low is 1.9ns.. which i find
> very fast. That's 263MHz 50%duty... i'm not sure if my external chip can
> even go that fast... So do i have to obey these restrictions to clock my
> ram? Would it fry and die if i clocked my ram whenever i felt like it so
> long as i obey the minimum time before sampling restrictions?(1.4-2.8ns)
> eg. I set my inputs (address, data, we etc..) then a second later decide to
> sample these and write to my ram. then decide to turn the clock back low and
> hour later.?


Article: 47716
Subject: Re: xilinx free logic analyzer?
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Wed, 2 Oct 2002 14:17:11 -0400
Links: << >>  << T >>  << A >>
OK, Austin, I'll keep that in mind ;-)

Austin

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3D9A2F6A.56F92F06@xilinx.com...
> TANSTAAFL:
>
> (There ain't no such thing as a free lunch*).
>
> Austin
>
> *Robert Heinlein's classic SF novel "The Moon is a Harsh Mistress"
>
> luigi funes wrote:
>
> > Austin Lesea ha scritto nel messaggio <3D9A1EB0.BECE83A0@xilinx.com>...
> > > http://www.xilinx.com/prs_rls/0186chipscope.html
> > >
> > >Austin
> >
> > Thank you!
> > But $495 is not exactly free...
> >
> > Luigi
>



Article: 47717
Subject: Re: virtex 2 -5i vs -6
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 02 Oct 2002 11:22:09 -0700
Links: << >>  << T >>  << A >>
Sanjay,

The Industrial part is speed binned at 100C with its own test program to
meet I grade specifications.

The Commercial part is speed binned at 85C with its own test program.

The bitstreams are certainly the same, as the part is the same.

It is not true that every -5I part could be remarked a -6C part.

Austin

S P wrote:

> I was told by xilinx that a virtex xc2v1000 -5i (industrial) part is
> the same die as the -6 part.  As we only intend to run these parts in
> normal temperature range, a -5i should work in place of -6.
>
> Has anyone had this experience and if so can a bitstream generated for
> a -6 part work on -5i.
>
> Thanks.
> -sanjay


Article: 47718
Subject: Re: Moving average filter
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 02 Oct 2002 11:24:12 -0700
Links: << >>  << T >>  << A >>
Here is my first idea:
Write your inputs into a BlockRAM ( 1k x 18) and accumulate the inputs.
Read from the same BlockRAM n positions downstream, and subtract those
values from the accumulator. ( Kind of like a synchronous FIFO)
Your accumulator will contain the running sum, you still have to do the
division by n. Trivial if n is a power of two  :-)

Peter Alfke


Arne Burghardt wrote:

> Hi,
>
> i want to implement a moving average filter in my FPGA. That's not the
> big problem, but the window size of the filter should be changeable
> during runtime...
> Big problem for me, i have no idea how to do it at the moment :-(
> Maybe one of the experts in this group have a helpful link or an idea
> for me ?
>
> Here are some more details:
> I have a continous input data stream with 14 bits and a data rate of
> approx. 65 MHz. I have to realize a simple filter, which calculates the
> average value of the last n samples, n=[2..1024]. n is not fixed, but
> should be a register, which i can update during runtime. I would like to
> use a Xilinx Virtex2 FPGA for this task.
>
> Thanks a lot for your help !
>
>    Arne


Article: 47719
Subject: Re: Moving average filter
From: Sylvain Yon <sylvain.yon@sbcglobal.net>
Date: Wed, 02 Oct 2002 18:25:15 GMT
Links: << >>  << T >>  << A >>
Arne Burghardt <Arne.Burghardt@NOSPAMdesy.de> wrote in news:anf5vm$8pqjt$1
@claire.desy.de:

> For clarification:
> 
> If n changes, the output is of course invalid for n samples. It doesn't 
> matter in my case. I only need a status flag in a register which tells 
> me, if the output is valid or not (simple task to do...).
> 
>    Arne
> 

My first thought is using a delay line of length n : add the input value, 
substract the output value. Reinit the content of the RAM with zeros each 
time you modify n. 
I don't know if other functions have to fit in your PLD, but this fits in a 
small SpartanIIe (XC2S50E should be sufficient)

hth
Sylvain Yon

Article: 47720
Subject: Re: virtex 2 -5i vs -6
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 02 Oct 2002 11:32:48 -0700
Links: << >>  << T >>  << A >>
The assumption that industrial-grad and commercial-grade silicon differs
by just one speed grade is a rough approximation.
It may have had more validity in the olden days when the chips did not
contain very specialized functions ( like DCMs etc).
I would not bet the integrity of my design on such a vague assumption,
although it may be good enough for lab experiments.

Peter Alfke, XilinxApplications



S P wrote:

> I was told by xilinx that a virtex xc2v1000 -5i (industrial) part is
> the same die as the -6 part.  As we only intend to run these parts in
> normal temperature range, a -5i should work in place of -6.
>
> Has anyone had this experience and if so can a bitstream generated for
> a -6 part work on -5i.
>
> Thanks.
> -sanjay


Article: 47721
Subject: Re: Block Ram Timing Issues
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 02 Oct 2002 11:55:24 -0700
Links: << >>  << T >>  << A >>
I meant to say that the clock High and Low timing parameters are min only. The
delay parameters are of course max. Should be obvious.

Peter Alfke



Article: 47722
Subject: Re: Moving average filter
From: Ray Andraka <ray@andraka.com>
Date: Wed, 02 Oct 2002 19:48:17 GMT
Links: << >>  << T >>  << A >>
You should do a search on CIC (cascaded integrator-comb) filters, otherwise
known as Hogenaur filters after Gene Hogenaur.  Basically, on the input
side, the samples are integrated (accumulated) without bound.  Then, a comb
filter, which is simply a difference between the current sample and a sample
delayed by N clocks  is applied to the integrated input.  If you pick up a
copy of Marv Frerking's DSP in Communications Systems (available through the
bookstore on my website), he has a lengthy discussion on CIC filters.  A CIC
is basically just a recursive implementation of a moving average filter.

For the delays, if you are looking for small lengths only, the SRL16s
(cascade them for SR128) are great since they use little resources and are
very easy to adjust for length.  For longer lengths, use a block ram, an
address counter and an adder.  The address counter provides the read
address, the adder sums the read address with the length to get a net delay
of the length.  For the SRL16 case, you can change the length on the fly and
have the correct results on the next clock.  For the block ram, you'd have
to modify the addressing so that the write pointer is the counter and the
read pointer is subtracted from that to make it adjustable without hiccup.

Arne Burghardt wrote:

> Hi,
>
> i want to implement a moving average filter in my FPGA. That's not the
> big problem, but the window size of the filter should be changeable
> during runtime...
> Big problem for me, i have no idea how to do it at the moment :-(
> Maybe one of the experts in this group have a helpful link or an idea
> for me ?
>
> Here are some more details:
> I have a continous input data stream with 14 bits and a data rate of
> approx. 65 MHz. I have to realize a simple filter, which calculates the
> average value of the last n samples, n=[2..1024]. n is not fixed, but
> should be a register, which i can update during runtime. I would like to
> use a Xilinx Virtex2 FPGA for this task.
>
> Thanks a lot for your help !
>
>    Arne

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 47723
Subject: Re: C\C++ to VHDL Converter
From: Ray Andraka <ray@andraka.com>
Date: Wed, 02 Oct 2002 20:53:26 GMT
Links: << >>  << T >>  << A >>
The problem is such software to fpga tools are a disservice to FPGAs.  I am
aware of several firms that have gone through that flow ending up with results
that are not much different than what can be done on a DSP micro, but in a more
expensive device and using "unconventional" tools.  Unfortunately, these folks
usually walk away saying that FPGAs can't compete with DSP micros except in one
or two special cases and that anything said to the contrary is marketing BS from
the FPGA chip vendors.  The fact of the matter is that a DSP design properly
targeted to an FPGA can often result in speed-ups of around 100x over a single
DSP processor.  The key word here is "properly"

Austin Franklin wrote:

> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3D9A76DD.453A4B46@andraka.com...
> >
> >
> > Brett Cline wrote:
> >
> > > Hi All-
> > >
> > >    Synthesis from a C/C++ algorithm is absolutely possible and has been
> in
> > > use for some time. Even "plain vanilla C" algorithms can be used with
> the
> > > right synthesis product.
> >
> > Show me.
>
> Yeah, and show me too.  I've yet to see any benchmarks that show any where
> near usable performance and size.  From my experience, you are better off
> re-writing it in an HDL, then trying to fight with these tools in both the
> size and speed arena.
>
> Why do things that supposedly make your life "easier" end up making them
> harder?
>
> > >   To take the algorithm to hardware (RTL Verilog or VHDL) my company
> offers
> > > a product called "Cynthesizer" for high-level synthesis from SystemC.
> We've
> > > had a number of customers take generic algorithms (some even from the
> web)
> > > such as filters, encryption, multimedia, etc. and convert them directly
> to
> > > RTL Verilog and VHDL. The resulting RTL can be put into any FPGA or ASIC
> > > synthesis tool as well as any other tool that operates on RTL.
> >
> > But at what price?  Is the performance and density reasonably close to a
> what a
> > skilled hardware designer can accomplish?
>
> Of course not, Ray, you know better than to ask that question ;-)
>
> Regards,
>
> Austin

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 47724
Subject: Re: Moving average filter
From: "Helmut Sennewald" <HelmutSennewald@t-online.de>
Date: Wed, 2 Oct 2002 23:03:57 +0200
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag
news:3D9B39CC.430E7CA7@xilinx.com...
> Here is my first idea:
> Write your inputs into a BlockRAM ( 1k x 18) and accumulate the inputs.
> Read from the same BlockRAM n positions downstream, and subtract those
> values from the accumulator. ( Kind of like a synchronous FIFO)
> Your accumulator will contain the running sum, you still have to do the
> division by n. Trivial if n is a power of two  :-)

Hello Peter,
you forgot to mention that this approach needs an
accumulator/adder/subtractor with 24 bits (14+log2(1024).
No LSB is allowed to get lost.
This add/subtract algorithm is very popular in DSP programming too.

Best Regards
Helmut

>
> Peter Alfke
>
>
> Arne Burghardt wrote:
>
> > Hi,
> >
> > i want to implement a moving average filter in my FPGA. That's not the
> > big problem, but the window size of the filter should be changeable
> > during runtime...
> > Big problem for me, i have no idea how to do it at the moment :-(
> > Maybe one of the experts in this group have a helpful link or an idea
> > for me ?
> >
> > Here are some more details:
> > I have a continous input data stream with 14 bits and a data rate of
> > approx. 65 MHz. I have to realize a simple filter, which calculates the
> > average value of the last n samples, n=[2..1024]. n is not fixed, but
> > should be a register, which i can update during runtime. I would like to
> > use a Xilinx Virtex2 FPGA for this task.
> >
> > Thanks a lot for your help !
> >
> >    Arne
>




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search