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
2017JanFebMarApr2017

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 38525

Article: 38525
Subject: Re: Leonardo + Xilinx tools help
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 16 Jan 2002 10:33:34 -0800
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> Check the Xilinx GUI for EDIF writer settings.

                 Make that EDIF *reader* settings.

Article: 38526
Subject: Re: Audio time delay circuit
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 16 Jan 2002 11:13:42 -0800
Links: << >>  << T >>  << A >>
Let's say you need a delay of 1 sec max. That means 32k samples of 32 bits each.

Store them in an SRAM ( 1 Mbit is cheap) and use an FPGA or CPLD to manipulate
the two FIFO address pointers (  one 15-bit counters and a 15-bit adder and a
15-bit register).
The design is fully synchronous, so the FIFO control is trivial.
I suppose that somebody has already implemented an I2S interface.
Total: 2 chips plus a Xtal oscillator ( plus SPROM for the FPGA configuration)

Peter Alfke
=============================
Simon Fisher wrote:

> Hi, I'm new to all this, so please bear with me.
>
> I need to implement a variable time delay for digital audio signals of
> several hundred milliseconds. The data comes in and out of an I2S
> interface using 32khz sample rate, stereo 16 bit samples. The device
> also needs to be controlled (ie precise time delay selected) via an
> I2C slave interface.
>
> Any ideas please?
>
> Cheers
> Simon Fisher


Article: 38527
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 16 Jan 2002 11:19:47 -0800
Links: << >>  << T >>  << A >>


If the two clocks are unrelated, you WILL have set-up time violations, sooner or
later even metastability problems.

I published something a while ago ( they even put my picture in there ;-).

http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm

Peter Alfke
=======================
hamish@cloud.net.au wrote:

> Peter Alfke <peter.alfke@xilinx.com> wrote:
> > I have a simple, quick-and-dirty method of transferring data between unrelated
> > clock domains:
> > Transfer twice in a row, and then compare the two values. If they are identical,
> > the data is good. If they differ, discard the data.
>
> A robust solution but it has quite a bit of overhead (duplicate signal,
> comparison logic etc). Especially since I can guarantee that my
> circuit works as long as I don't violate any setup times -- for
> which I need the timing constraints.
>
> cheers,
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



Article: 38528
Subject: Re: Audio time delay circuit
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 16 Jan 2002 20:27:04 +0100
Links: << >>  << T >>  << A >>
"Simon Fisher" <Simon.Fisher@hitachi-eu.com> schrieb im Newsbeitrag
news:2cbcf39d.0201160940.7eec6579@posting.google.com...
> Hi, I'm new to all this, so please bear with me.
>
> I need to implement a variable time delay for digital audio signals of
> several hundred milliseconds. The data comes in and out of an I2S
> interface using 32khz sample rate, stereo 16 bit samples. The device
> also needs to be controlled (ie precise time delay selected) via an
> I2C slave interface.

Take a small FPGA (or a big CPLD) and build some state machines that get the
data from the incomming audio device, stores it on an SRAM and read it back
from the SRAM. The read/write operation uses some kind of circular pointer
to the SRAM (similar to a FIFO). The difference of the pointers times the
data transfer rate (I want to aviod the term sampling rate) gives the time
delay. This difference can be easyly adjusted to the needs of the user.

--
MfG
Falk





Article: 38529
Subject: I2C multiplexer
From: Andrew Ha <akha@cisco.com>
Date: Wed, 16 Jan 2002 11:33:46 -0800
Links: << >>  << T >>  << A >>
Is there verilog code available in public domain that will multiplex an
I2C bus among multiple I2C busses?

Thanks,

Andy




Article: 38530
Subject: Re: Core Generator
From: a_darabiha@yahoo.com (a_darabiha)
Date: 16 Jan 2002 11:34:31 -0800
Links: << >>  << T >>  << A >>
Thanks a lot for your guide,
It really helped to solve my problem, 
As you said synplicity looks at the core as a black box.

Ahmad Darabiha 

"Angel Pino" <escorpiontale@hotmail.com> wrote in message news:<EBq%7.30659$_j6.3312171080@newssvr14.news.prodigy.com>...
> You need to make sure that the .edn file generated by CoreGen is in the same
> directory as the .edf file generated by Symplicity. Simplicity only
> considers the core as a black box and ignores whats in it. In ourder to
> place and route you need both the .edf ( netlist from Symplicity ) and .edn
> ( netlist from CoreGen ).
> Hope this helps
> Angel Pino
> 
> "a_darabiha" <a_darabiha@yahoo.com> wrote in message
> news:88a1211d.0201081317.13f3a1f1@posting.google.com...
> > Hi all,
> > can one Xilinx ISE tools experts help me please!
> > I have gone through the Core Generator guide but
> > still confused! :(  here is the story:
> >
> > As a new user of Xilinx Core Generator I am trying
> > generate a very simple core (16bit comparator)  and then
> > instantiate it in my vhdl design and finally synthesize and
> > implement it on a virtexII platform.
> >
> > The Core Generator works fine and produces .vho, .edn and
> > .vhd files. I then cut and paste from the .vho file to instantiate
> > the component in my own design with the proper port map names...
> >
> > I synthesize the desing by Synplicity  VHDL compiler v6.2.0 and it seems
> > there is not any problem but after that in ngdbuid I get this error
>  message:
> >
> > ****************************************************************
> > .
> > .
> > .
> > WARNING:NgdBuild:329 - Line number 5: Invalid PART record value "4003pc84"
> >    ignored.  Please consult the Xilinx Programmable Logic Data Book for
>  valid
> >    part/package/speed conbinations.
> >    Writing NGO file "my_adder_coregen_ports.ngo" ...
> > Loading design module
> >
> "/jayar/q/q6/ahmadd/tm3/coregen/test_5/tm3a/xilinx/fpga0/my_adder_coregen_po
> rts.
> > ngo"...
> >
> > Annotating constraints to design from file "virtex0.ucf" ...
> >
> > Checking timing specifications ...
> >
> > Checking expanded design ...
> > ERROR:NgdBuild:604 - logical block
> >
> 'wrapped_my_adder_coregen_inst/my_adder_coregen_inst/your_instance_name'
> with
> >    type 'new_comp' is unexpanded. Symbol 'new_comp' is not supported in
>  target
> >    'virtexe'.
> > WARNING:NgdBuild:454 - logical net 'GND' has no load
> > WARNING:NgdBuild:454 - logical net 'VCC' has no load
> >
> > NGDBUILD Design Results Summary:
> >   Number of errors:     1
> >   Number of warnings:   2
> >
> > .
> > .
> > .
> > ****************************************************************
> >
> > Has any friend had this problem before?
> >
> > I have some guesses in my mind that might also help you
> > to figure out the problem:
> >
> > 1- I have not compiled the XilinxCore Lib. Is that the problem ?
> >       There were several reasons for that:
> > - it seems compiling VHDL behavioral library requires
> > MTI ModelSim and in our package ModelSim is only supported
> > for PC and not for Solaris...
> >
> > - in fact at this time I do not need to do any simulation
> > and want to synthesize it directly, so I dont feel
> >         any need for simulation. and It should be possible
> > to generate a core and synthesize it without any simulation in
> > between...
> >
> > So, is it really neccessary to compile XilinxCoreLib for synthesis?
> > if so, could someone help how to do that? (the info in Xilix Core
> > Generator guide for compile_hdl.pl is too short not clear :( )
> >
> > 2- in page 4-33 of Core generator guide for Synplicity synthesis tool it
>  says:
> >   "do not read in a separate .vhd file or EDIF file for Core Generator
>  mudule"
> >   what dose that mean !?
> >
> >
> >
> > I would really appreciate any help,
> > and please let me know if the problem is not described clearly,
> > thanks,
> > a_darabiha@yahoo.com

Article: 38531
Subject: Re: Audio time delay circuit
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Wed, 16 Jan 2002 19:40:55 +0000 (UTC)
Links: << >>  << T >>  << A >>


"Simon Fisher" <Simon.Fisher@hitachi-eu.com> wrote in message
news:2cbcf39d.0201160940.7eec6579@posting.google.com...
> Hi, I'm new to all this, so please bear with me.
>
> I need to implement a variable time delay for digital audio signals of
> several hundred milliseconds. The data comes in and out of an I2S
> interface using 32khz sample rate, stereo 16 bit samples. The device
> also needs to be controlled (ie precise time delay selected) via an
> I2C slave interface.
>
> Any ideas please?
>
> Cheers
> Simon Fisher

A circular buffer will do this for you. You will need a fair mount of RAM,
depending on how much delay you want.

Leon
--
Leon Heller, G1HSM leon_heller@hotmail.con
http://www.geocities.com/leon_heller
Low-cost Altera Flex design kit: http://www.leonheller.com





Article: 38532
Subject: Image Processing on FPGAs. Dose System Generator help??
From: a_darabiha@yahoo.com (a_darabiha)
Date: 16 Jan 2002 11:49:09 -0800
Links: << >>  << T >>  << A >>
Hi All,

I'm trying to implement a Computer Vision Algorithm 
on Xilinx Vitex2000E fpgas. I am now using CoreGen for some blocks 
of my system. We are thinking of switching to System Generator to do
the simulation in the highest level and then translate the system
to VHDL. I hope it would make the life much easier!

So does anybody have experience of using SysGen for Image Processing
applications? how easy is that compared with the standard method of
writing the whole VHDL myself? what are the major problems that 
might be in the way? ...


Any coment would be helpful,

Thanks,
Ahmad Darabiha

Article: 38533
Subject: SysGen on PC / Unix ?
From: a_darabiha@yahoo.com (a_darabiha)
Date: 16 Jan 2002 12:02:11 -0800
Links: << >>  << T >>  << A >>
Hi All,

Currently SysGen is only available for PC. The problem is that
the implementation of my designto on FPGA board can be done only 
from Unix machine. 

So if I start from SysGen on PC then at some intermediate point 
of the design flow I need to transfer the files to Unix. I have heared
that
the files are fully PC/Unix compatible. ( for instance send the
NGDBUild
results from PC to Unix and continue the Place and Route on Unix)

But On the other hand I heared that sometimes Unix can not read the
encription code on the file headers written by PC...

So is there ay experience? any comment or suggestion?   

Thanks,
Ahmad Darabiha

Article: 38534
Subject: Signal processing using FPGAs
From: "Amit Thakar" <athakar@uwaterloo.ca>
Date: Wed, 16 Jan 2002 20:11:11 GMT
Links: << >>  << T >>  << A >>
Hi,

I was hoping someone could answer questions I had regarding digital signal
processors vs. FPGAs for implementing computationally intensive signal
processing algorithms:

1. Can FPGAs (especially newer ones) achieve better performance than DSPs?
2. If so, then why do ppl use DSPs as opposed to FPGAs?
3. Which is more flexible in terms of reprogrammability (I would think they
would be the same in this regard).
3. What are other (dis)advantages of using FPGAs vs. DSPs.

In general, I understand that DSPs provide a low cost solution due to high
volume of generic products, but performance tends to fall short for many
applications.

Any input would be greatly appreciated.
Thanks!

-Amit




Article: 38535
Subject: Re: Signal processing using FPGAs
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 16 Jan 2002 13:00:06 -0800
Links: << >>  << T >>  << A >>
See below,

Austin

Amit Thakar wrote:

> Hi,
>
> I was hoping someone could answer questions I had regarding digital signal
> processors vs. FPGAs for implementing computationally intensive signal
> processing algorithms:
>
> 1. Can FPGAs (especially newer ones) achieve better performance than DSPs?

Yes.  70 to over 100 times better performance.

>
> 2. If so, then why do ppl use DSPs as opposed to FPGAs?

Tools.  Hard to create DSP structures for FPGAs as opposed to writing C code.
Hard to simulate.  The Xtreme DSP (tm) program is addressing these issues with
better tools (ie CoreGen, interface to MatLab (Simulink), etc).

>
> 3. Which is more flexible in terms of reprogrammability (I would think they
> would be the same in this regard).

Easy to reprogram either, but you need the program!  FPGAs can change their
hardware, not just the algorithm, so they are more flexible (potentially).

>
> 3. What are other (dis)advantages of using FPGAs vs. DSPs.

Tools.  Hard to design, hard to simulate.  Cost.  If you need 100X performance,
the cost is low.  If you look to do what a simple DSP chip can do, the cost is
high (in comparison).

>
>
> In general, I understand that DSPs provide a low cost solution due to high
> volume of generic products, but performance tends to fall short for many
> applications.

FPGAs are also mass produced, so their cost is low (see Spartan for example).

>
>
> Any input would be greatly appreciated.
> Thanks!
>
> -Amit


Article: 38536
Subject: Re: Signal processing using FPGAs
From: Ray Andraka <ray@andraka.com>
Date: Wed, 16 Jan 2002 22:17:26 GMT
Links: << >>  << T >>  << A >>


Amit Thakar wrote:

> Hi,
>
> I was hoping someone could answer questions I had regarding digital signal
> processors vs. FPGAs for implementing computationally intensive signal
> processing algorithms:
>
> 1. Can FPGAs (especially newer ones) achieve better performance than DSPs?

Yes,  We typically see just under 100:1 performance advantage in our designs
(mostly radar and imaging).  That ratio hasn't change much over the last 10
years.

>
> 2. If so, then why do ppl use DSPs as opposed to FPGAs?

Obtaining that performance from FPGAs requires a relatively rare skill set:  The
FPGA DSP designer needs to be skilled in logic design, specifically FPGA design,
and also has to be familiar enough with Hardware based DSP to be able to
optimize the algorithm implementation for a hardware,  make that FPGA,
implementation.  Most DSP algorithms in use today are geared toward a software
solution.  The efficient hardware solution often requires a quite different
approach.  Most people doing DSP work these days are software types (which makes
sense seeing the DSP field has been dominated by the microprocessor for the past
quarter century), so it follows that DSP designs will continue to use
microprocessors as the preferred platform as long as the project requirements
are met.

>
> 3. Which is more flexible in terms of reprogrammability (I would think they
> would be the same in this regard).

The microprocessors still hold an edge on flexibility, mostly because of the
state of the tools.  Microprocessor code typically takes seconds to compile
changes where the FPGA code can take hours.  The tools, especially when it comes
to evaluation of algorithms, are also much better for the software side.

>
> 3. What are other (dis)advantages of using FPGAs vs. DSPs.

The biggest disadvantage to using FPGAs is the relative scarcity of expertise
needed for the performance gains I noted above.  FPGAs also cost more per device
than typical DSP micros, but when you consider dollars for a specific
performance then the PFGAs get cheaper as soon as performance drives you over
one or two DSPs.

I tell my customers that if it can be done in a (single or at most two) DSP
micro, then they should do it there rather than in an FPGA because it is a lot
easier (and somewhat cheaper) to find expertise on the processors.

>
>
> In general, I understand that DSPs provide a low cost solution due to high
> volume of generic products, but performance tends to fall short for many
> applications.
>
> Any input would be greatly appreciated.
> Thanks!
>
> -Amit

--
--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: 38537
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 16 Jan 2002 22:29:20 GMT
Links: << >>  << T >>  << A >>

--------------8CF0AA49EAE5C084DF6A8496
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Right.

For coherent clocks you need the skew included in the timing analysis to make
sure your data crossing domains does not violate the setup/hold of the
reciever.   Constraints covering the path between the domains are critical in
this case to ensure proper operation.  I'm with Hamish on this one, no need for
the overhead indicated by Peter if you can guarantee the condition won't occur
through the use  of contraints.

The other case, where clocks are async to each other, it is still a good idea to
constrain the path because you want to minimize the transport time from the
flip-flop in one domain to the flip-flop in the other domain so as to maximize
the metastability settle time.  A from:to constraint is needed here so that the
tools do this.  So even though intuition might indicate that a timing constraint
is not needed here since you *will* go metastable at some time, the truth is a
constraint is vital here to keep from eating up your metastability resolution
time with propagation delay.  In this case, the skew doesn't matter much, so it
probably doesn't hurt to include it (it is meaningless anyway).  I usually
floorplan the flops on each side of a crossing like this so that they are in
adjacent slices within a CLB.  That alone doesn't guarantee use of the fast
connect, but it at least makes it possible.



Peter Alfke wrote:

> If the two clocks are unrelated, you WILL have set-up time violations, sooner
> or later even metastability problems.
>
> I published something a while ago ( they even put my picture in there ;-).
>
> http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
>
> Peter Alfke
> =======================
> hamish@cloud.net.au wrote:
>
>> Peter Alfke <peter.alfke@xilinx.com> wrote:
>> > I have a simple, quick-and-dirty method of transferring data between
>> unrelated
>> > clock domains:
>> > Transfer twice in a row, and then compare the two values. If they are
>> identical,
>> > the data is good. If they differ, discard the data.
>>
>> A robust solution but it has quite a bit of overhead (duplicate signal,
>> comparison logic etc). Especially since I can guarantee that my
>> circuit works as long as I don't violate any setup times -- for
>> which I need the timing constraints.
>>
>> cheers,
>> Hamish
>> --
>> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
>
--
--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: 38538
Subject: Re: Leonardo + Xilinx tools help
From: Ray Andraka <ray@andraka.com>
Date: Wed, 16 Jan 2002 22:34:32 GMT
Links: << >>  << T >>  << A >>
Mike,

I don't recall ever seeing settings in the Xilinx tools for the edif reader.
Sounds to me like a problem with the way leo is writing the edif.  I think there
may be settings in leo for the edif output format.  Also, the tri_state warnings
indicate that it couldn't find a matching component.  If it is not a primitive
for the device you are using, it better have an edif file for the component or
you get the error.

Mike Treseler wrote:

> Mike Treseler wrote:
>
> > Check the Xilinx GUI for EDIF writer settings.
>
>                  Make that EDIF *reader* settings.

--
--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: 38539
Subject: Re: Signal processing using FPGAs
From: "Amit Thakar" <athakar@uwaterloo.ca>
Date: Wed, 16 Jan 2002 22:36:31 GMT
Links: << >>  << T >>  << A >>

Thanks a lot Austin and Ray, your responses were really helpful.

-Amit

"Amit Thakar" <athakar@uwaterloo.ca> wrote in message
news:z7l18.253991$KT.59135022@news4.rdc1.on.home.com...
> Hi,
>
> I was hoping someone could answer questions I had regarding digital signal
> processors vs. FPGAs for implementing computationally intensive signal
> processing algorithms:
>
> 1. Can FPGAs (especially newer ones) achieve better performance than DSPs?
> 2. If so, then why do ppl use DSPs as opposed to FPGAs?
> 3. Which is more flexible in terms of reprogrammability (I would think
they
> would be the same in this regard).
> 3. What are other (dis)advantages of using FPGAs vs. DSPs.
>
> In general, I understand that DSPs provide a low cost solution due to high
> volume of generic products, but performance tends to fall short for many
> applications.
>
> Any input would be greatly appreciated.
> Thanks!
>
> -Amit
>
>
>



Article: 38540
Subject: Re: Virtex-2 Frequency Synhtesis
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 17 Jan 2002 00:39:32 +0000
Links: << >>  << T >>  << A >>


Austin Lesea wrote:

> Rick,
>
> The part was never intended to support M and D values to 4095.  The intent was to
> find out just where it did work to.
>
> The measured performance was such that with values > 32, the jitter became too large
> as a % of the period, making the feature much less useful.
>
> As well, to verify M and D values for {1,32} requires thousands of patterns to be
> run over hundreds of frequencies (over hundreds of parts) to characterize, not to
> mention production test.  In keeping with our commitment to the customer to provide
> a quality part, we decided to limit the M and D values to less than what the part
> was capable of to be sure all values worked in actual designs with other resources
> in a production environment.
>
> Future silicon is not intended to operate at any values greater than 32.  The basic
> issue is the Q of the oscillator, or resonator used.  In silicon, with devices, this
> is limited to a practical value of about 100.  Thus, the oscillator can not for very
> long before it accumulates a phase error (jitter) from the desired phase.  Perhaps
> with integrated inductors, we could achieve a Q of 200, but even that is beyond the
> technology.  Maybe MEMS?  Tuning forks?
>
> I apologize for not catching the 4095 in the original information.  I was
> responsible for checking the info, and preventing just that kind of slip.  I missed
> it.  The bits are free in the memory, and thus they are there for future use.  It
> was never intended that we actually support such values.  It is also true that such
> M and D values require a quartz crystal for stability, so I am surprised anyone took
> those numbers seriously when they were first published ... (they were impossible to
> achieve  -- at least to anyone skilled in the art of frequency synthesis).
>

Not a problem. I must admit that I was a little suspicious but such is my belief that
all Xilinx designers have been trained at the Hogwarts School of Silicon Wizzardry that
I sort of thought o.k. well these guys just might ...

<snip>

Just one question: What does ICAP stand for ?

BTW: The new CoolRunner-2 looks really nice but only the '64 is showing yet - what's the
roll out plan for the bigger devices ? I need the '256 in particular.




Article: 38541
Subject: Re: Virtex-2 Frequency Synhtesis
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 16 Jan 2002 17:25:57 -0800
Links: << >>  << T >>  << A >>
Rick,

Funny you mention "Hogwarts School of FPGA Design" .....there was a certain little Holiday
Play that had various characters like "Alteramort" in it, and the three headed management
monster ..... (all in good fun).

ICAP = Internal Configuration Access Port.

Austin

Rick Filipkiewicz wrote:

> Austin Lesea wrote:
>
> > Rick,
> >
> > The part was never intended to support M and D values to 4095.  The intent was to
> > find out just where it did work to.
> >
> > The measured performance was such that with values > 32, the jitter became too large
> > as a % of the period, making the feature much less useful.
> >
> > As well, to verify M and D values for {1,32} requires thousands of patterns to be
> > run over hundreds of frequencies (over hundreds of parts) to characterize, not to
> > mention production test.  In keeping with our commitment to the customer to provide
> > a quality part, we decided to limit the M and D values to less than what the part
> > was capable of to be sure all values worked in actual designs with other resources
> > in a production environment.
> >
> > Future silicon is not intended to operate at any values greater than 32.  The basic
> > issue is the Q of the oscillator, or resonator used.  In silicon, with devices, this
> > is limited to a practical value of about 100.  Thus, the oscillator can not for very
> > long before it accumulates a phase error (jitter) from the desired phase.  Perhaps
> > with integrated inductors, we could achieve a Q of 200, but even that is beyond the
> > technology.  Maybe MEMS?  Tuning forks?
> >
> > I apologize for not catching the 4095 in the original information.  I was
> > responsible for checking the info, and preventing just that kind of slip.  I missed
> > it.  The bits are free in the memory, and thus they are there for future use.  It
> > was never intended that we actually support such values.  It is also true that such
> > M and D values require a quartz crystal for stability, so I am surprised anyone took
> > those numbers seriously when they were first published ... (they were impossible to
> > achieve  -- at least to anyone skilled in the art of frequency synthesis).
> >
>
> Not a problem. I must admit that I was a little suspicious but such is my belief that
> all Xilinx designers have been trained at the Hogwarts School of Silicon Wizzardry that
> I sort of thought o.k. well these guys just might ...
>
> <snip>
>
> Just one question: What does ICAP stand for ?
>
> BTW: The new CoolRunner-2 looks really nice but only the '64 is showing yet - what's the
> roll out plan for the bigger devices ? I need the '256 in particular.


Article: 38542
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 17 Jan 2002 01:36:43 GMT
Links: << >>  << T >>  << A >>
On Wed, 16 Jan 2002 22:29:20 GMT, Ray Andraka <ray@andraka.com> wrote:

>
>--------------8CF0AA49EAE5C084DF6A8496
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Right.
>
>For coherent clocks you need the skew included in the timing analysis to make
>sure your data crossing domains does not violate the setup/hold of the
>reciever.   Constraints covering the path between the domains are critical in
>this case to ensure proper operation.  I'm with Hamish on this one, no need for
>the overhead indicated by Peter if you can guarantee the condition won't occur
>through the use  of contraints.
>
>The other case, where clocks are async to each other, it is still a good idea to
>constrain the path because you want to minimize the transport time from the
>flip-flop in one domain to the flip-flop in the other domain so as to maximize
>the metastability settle time.  A from:to constraint is needed here so that the
>tools do this.  So even though intuition might indicate that a timing constraint
>is not needed here since you *will* go metastable at some time, the truth is a
>constraint is vital here to keep from eating up your metastability resolution
>time with propagation delay.  In this case, the skew doesn't matter much, so it
>probably doesn't hurt to include it (it is meaningless anyway).

I get the feeling that Hamish's clock is running at 350MHz or so
(based on the contents of previous posts).  The skew ends up being a
significant part of the timespec (about one third).

It would be much more satisfactory if the tools gave the option of not
including the skew in the timing analysis, on a timespec by timespec
basis.

Regards,
Allan.

>  I usually
>floorplan the flops on each side of a crossing like this so that they are in
>adjacent slices within a CLB.  That alone doesn't guarantee use of the fast
>connect, but it at least makes it possible.
>
>
>
>Peter Alfke wrote:
>
>> If the two clocks are unrelated, you WILL have set-up time violations, sooner
>> or later even metastability problems.
>>
>> I published something a while ago ( they even put my picture in there ;-).
>>
>> http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
>>
>> Peter Alfke
>> =======================
>> hamish@cloud.net.au wrote:
>>
>>> Peter Alfke <peter.alfke@xilinx.com> wrote:
>>> > I have a simple, quick-and-dirty method of transferring data between
>>> unrelated
>>> > clock domains:
>>> > Transfer twice in a row, and then compare the two values. If they are
>>> identical,
>>> > the data is good. If they differ, discard the data.
>>>
>>> A robust solution but it has quite a bit of overhead (duplicate signal,
>>> comparison logic etc). Especially since I can guarantee that my
>>> circuit works as long as I don't violate any setup times -- for
>>> which I need the timing constraints.
>>>
>>> cheers,
>>> Hamish
>>> --
>>> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
>>
>--
>--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: 38543
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 17 Jan 2002 04:54:28 GMT
Links: << >>  << T >>  << A >>
Exactly.  I mentioned that in an earlier post, because there are times when to skew or not to skew is not in question.

Allan Herriman wrote:

> On Wed, 16 Jan 2002 22:29:20 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >
> >--------------8CF0AA49EAE5C084DF6A8496
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >
> >Right.
> >
> >For coherent clocks you need the skew included in the timing analysis to make
> >sure your data crossing domains does not violate the setup/hold of the
> >reciever.   Constraints covering the path between the domains are critical in
> >this case to ensure proper operation.  I'm with Hamish on this one, no need for
> >the overhead indicated by Peter if you can guarantee the condition won't occur
> >through the use  of contraints.
> >
> >The other case, where clocks are async to each other, it is still a good idea to
> >constrain the path because you want to minimize the transport time from the
> >flip-flop in one domain to the flip-flop in the other domain so as to maximize
> >the metastability settle time.  A from:to constraint is needed here so that the
> >tools do this.  So even though intuition might indicate that a timing constraint
> >is not needed here since you *will* go metastable at some time, the truth is a
> >constraint is vital here to keep from eating up your metastability resolution
> >time with propagation delay.  In this case, the skew doesn't matter much, so it
> >probably doesn't hurt to include it (it is meaningless anyway).
>
> I get the feeling that Hamish's clock is running at 350MHz or so
> (based on the contents of previous posts).  The skew ends up being a
> significant part of the timespec (about one third).
>
> It would be much more satisfactory if the tools gave the option of not
> including the skew in the timing analysis, on a timespec by timespec
> basis.
>
> Regards,
> Allan.
>
> >  I usually
> >floorplan the flops on each side of a crossing like this so that they are in
> >adjacent slices within a CLB.  That alone doesn't guarantee use of the fast
> >connect, but it at least makes it possible.
> >
> >
> >
> >Peter Alfke wrote:
> >
> >> If the two clocks are unrelated, you WILL have set-up time violations, sooner
> >> or later even metastability problems.
> >>
> >> I published something a while ago ( they even put my picture in there ;-).
> >>
> >> http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
> >>
> >> Peter Alfke
> >> =======================
> >> hamish@cloud.net.au wrote:
> >>
> >>> Peter Alfke <peter.alfke@xilinx.com> wrote:
> >>> > I have a simple, quick-and-dirty method of transferring data between
> >>> unrelated
> >>> > clock domains:
> >>> > Transfer twice in a row, and then compare the two values. If they are
> >>> identical,
> >>> > the data is good. If they differ, discard the data.
> >>>
> >>> A robust solution but it has quite a bit of overhead (duplicate signal,
> >>> comparison logic etc). Especially since I can guarantee that my
> >>> circuit works as long as I don't violate any setup times -- for
> >>> which I need the timing constraints.
> >>>
> >>> cheers,
> >>> Hamish
> >>> --
> >>> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
> >>
> >--
> >--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
> >
> >


--
--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: 38544
Subject: Re: Signal processing using FPGAs
From: Steve Underwood <steveu@dis.org>
Date: Thu, 17 Jan 2002 13:42:43 +0800
Links: << >>  << T >>  << A >>
Amit Thakar wrote:

> Hi,
> 
> I was hoping someone could answer questions I had regarding digital signal
> processors vs. FPGAs for implementing computationally intensive signal
> processing algorithms:
> 
> 1. Can FPGAs (especially newer ones) achieve better performance than DSPs?


It depends what you mean by performance. If you mean speed, then yes. An 
FPGA solution can generally be 1 to 2 orders of magnitude faster. If you 
means capable of implementing extremely complex algorithms well, then 
no. The complexity of handling, say, a CELP vocoder in dedicated 
hardware makes it a poor choice.


> 2. If so, then why do ppl use DSPs as opposed to FPGAs?


Use dedicated hardware solutions for simple things - if you need a 
simple filter in a CD player, nothing will beat a bit serial solution in 
hardware.

Use dedicated hardware solutions for speed - if you do real time radio 
channel processing you generally have a high throughput requirement, but 
the algorithms aren't too complex. Doing this with programmable DSPs 
would require a large bank of the, splitting up the work. FPGAs are 
ideal here.

Use programmable DSPs where the algorithms are complex - things like 
vocoders can be a nightmare to implement in an FPGA.

Use programmable DSPs where the requirements change frequently - FPGA 
may be reprogrammable, but minor changes in requirements tend to become 
major changes in an FPGA DSP solution. In a programmable solution they 
may be just a few lines of code.

Use programmable DSPs for low volume - this is not a clear cut thing, as 
  FPGAs are the right things for a lot of low volume uses. However, your 
chances of being able to use, say, a standard PCI card solution are far 
better with the programmable approach.

> 3. Which is more flexible in terms of reprogrammability (I would think they
> would be the same in this regard).


Depends what flexibility you need. If you got the board layout wrong you 
are more likely to be able to fix that by reprogramming an FPGA, than a 
programmable DSP. You you want to make algorithm changes its usually 
much quicker with programmable DSPs.


> 3. What are other (dis)advantages of using FPGAs vs. DSPs.



I think these issues are too application dependent to generalise.

> In general, I understand that DSPs provide a low cost solution due to high
> volume of generic products, but performance tends to fall short for many
> applications.


What does "performance fall short" mean? Nothing will match the current 
consumption of the programmable solutions in my GSM phone. If battery 
life if your overriding criteria, that very current consumption focussed 
solution will beat anything a more general purpose FPGA can do. In terms 
of mere processing speed, in most DSP applications some specific level 
is enough and you can't take any real advantage of any left over compute 
resources. You can never have too low a level of battery consumption, 
though. No solution will maximise all performance parameters - pretty 
much like any other area of engineering.

Regards,
Steve


Article: 38545
Subject: How to set PROM package in ISE 4.1 ?
From: David A Hand <hand@corestar-corp.com>
Date: Thu, 17 Jan 2002 03:27:23 -0500
Links: << >>  << T >>  << A >>
I have a XC18V02 PROM in a VQ44 package connected to an XCV300 FPGA in
slave serial mode. I'm trying to program the PROM via JTAG via parallel
cable. In Foundation 3.1, it used to ask me for the PROM family
(XC18V02) and the package (VQ44). In ISE, I can't seem to find any place
to set the package. When I program the PROM via iMPACT, it says it did
it successfully and verify confirms that it got to the PROM. But the
FPGA does not seem to receive the program on reset.

An .mcs file created via Foundation 3.1 downloads and runs as expected,
so the hardware and all connections are fine. The same simple program
created via ISE 4.1 does nothing.

Any ideas would be appreciated. I have a feeling I need to set the PROM
package somehow.




Article: 38546
Subject: Re: Signal processing using FPGAs
From: "Bert Cuzeau" <bertrand.cuzeau@worldonline.fr>
Date: Thu, 17 Jan 2002 09:06:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello Amit,

You have received indeed an enthusiastic feedback about
implementing D.S.Processing in FPGA. (is this a surprise ? ;-)

One issue you may soon face is getting/building a hardware
platform, and how to interface it with the real world.

For some of these designs, we now use a superb platform
made by a UK company named Hunt Engineering.
http://www.hunteng.co.uk

This architecture is real clever, and you can freely
mix FPGA(s) and DSP(s) in your system and get the
best of both worlds. The control by the PC is also a breeze.

Hope this helps,

Bert Cuzeau
Technical Manager ALSE rance
 - Digital Design
 - VHDL + Verilog
 - Training Courses



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 38547
Subject: Virtex2 ICAP
From: Christian Plessl <plessl@remove.tik.ee.ethz.ch>
Date: Thu, 17 Jan 2002 10:58:59 +0100
Links: << >>  << T >>  << A >>
Hi

Incidentally, I just stumbled over the Virtex2 ICAP (Internal configuration 
access port) primitive. Just looking at the name of the component this 
sounds very interessting. Is it possible to access/modify the Virtex2 
configuration from a circuit within the FPGA itself using this component?

Unfortunately I could not find any documentation ICAP on the Xilinx webpage.

Does anybody know, what this component is good for? Is there any  
documentation on this?

Thanks for any hints.

Christian



Article: 38548
Subject: Re: PCI Solution: LogiCore?
From: kleins@web.de (Stefan Klein)
Date: 17 Jan 2002 03:13:20 -0800
Links: << >>  << T >>  << A >>
Hi,

sorry, this doesn't really concern this posting, but an old posting of
yours in comp.sys.laptops concerning the use of a DVD in a Digital
Hinote Ultra 2000. Your email address in that posting just doesn't
seem to work, so I thought I'd try to track you down this way, since I
might be having the same problem.

Assuming that the connectors were pretty much standardized, I bought a
TEAC CD-RW to go as replacement for the existing Toshibar CD-ROM, but,
same in your case, it won't boot when the drive is plugged in.

However, one single time I managed to get it running by booting
Windows98 without the drive, plugging in the drive (it's supposed to
be hot-swappable, anyway, although it usually doesn't work) and
restarting Windows. Everything worked fine and I could burn an CD, but
I haven't managed to get it working again ever since.

Do you have any idea how that can be and do you think it is the same
problem? If so, could you please send me the extra information on how
to do the changes (I am able to put computers together, but not very
experienced with subtle changes of the elec like these -
alternatively: were would I have to ship it to? I am in Scotland).
Please email.

Your help is greatly appreciated. And sorry again for this misplaced
posting.
Stefan Klein

Article: 38549
Subject: how should i change it?
From: hoothsb <xnsiewk@rut.adsh>
Date: Thu, 17 Jan 2002 03:19:44 -0800
Links: << >>  << T >>  << A >>
The reference design (ftp://ftp.xilinx.com/pub/applications/xapp/xapp205.zip) is a (16x255 write-1020x4 read)'s fifo.Now,my request is (32x64 write-16x128 read)
how should i change it?



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
2017JanFebMarApr2017

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