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 27100

Article: 27100
Subject: Re: Leonardo for Altera
From: steve (Steve Rencontre)
Date: Fri, 10 Nov 2000 18:45 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <8uh03g$v80$1@nnrp1.deja.com>, flavioas@my-deja.com () wrote:

>      I am using Leonardo Spectrum for altera, trying to use a
> synthesizer better than maxplus2 for VHDL. But despite of
> checking 'setup maxplus2( create ACF file)option at Place&Route menu,
> it didn´t generate any ACF. So every time it runs maxplus2 to P&R it
> loses family, device and all information.
>       Any answer/suggestion is welcome,

Run MaxPlusII interactively to create your ACF. After the first time, you 
can run it in batch mode thereafter (but I personally prefer to fire up 
the GUI).

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 27101
Subject: Re: Non routable design
From: Mujtaba Hamid <mujtaba.hamid@xilinx.com>
Date: Fri, 10 Nov 2000 12:00:46 -0700
Links: << >>  << T >>  << A >>
Hello Fred,

        You are justified in expecting that a design with a 7 %
utilization should not give problems
while routing. However it's not just the density of the design that
causing routing problems. There might
an invalid route somewhere, or maybe there are a few CLBs which are so
densely packed that routing them is becoming a problem.

        There are infinite possible combinations of design size /
routing, and we try to verify as many as possible. However, there are
always newer design algorithms that have not been taken into account.
That's why Tim suggested to submit the design into Xilinx support, so
that it can be verified that the new tools have already fixed the
problem, before requesting an upgrade.

Best Regards,
Mujtaba
Xilinx Applications

fred wrote:

> Tim,
>
> I hope you will forgive an immediate deep-end response, but
> I am frankly appalled by your reply. You admit you have not
> seen the user's design but immediately suggest he shells out
> for an upgrade. I can only hope that you did not notice that
> the user has only a 7% utilisation within his device.
>
> Irrespective of his design type, a failure to route a <any?>
> design with 7% utilisation is a likely tool bug or fault.
> Your suggestion that he upgrade to get round the problem is
> IMNSHO a major cop out and unworthy of you as a
> representative of Xilinx. I am unaware whether this guy is
> in maintenance or not but if it turns out he is not, and the
> solution is indeed that he upgrade to get round a bug, may I
> suggest he be provided with the upgrade for nowt as the F2.1
> he was sold is 'not fit for purpose'.
>
> I notice Ray has provided what may be a more constructive
> reply.
>
> Regards,
>
> D McLeod
> XEC
>
> Disclaimer: I have assumed that Stephen's design does not
> contain a fatal error which has caused the tools to give a
> misleading error message (that never happens). My comments
> on the 'upgrade regardless' approach remain.
>
> "Tim Jaynes" <tim.jaynes@xilinx.com> wrote in message
> news:3A0B11F4.E0AAD7AA@xilinx.com...
> > Hi Steven,
> > Better PAR performance on routing pwr/gnd nets was one of
> the major
> > enhancements contained in the 3.1i tools and it's
> associated service packs.
> > Without seeing the design and without knowing your
> budgetary constraints I'd
> > recommend a software upgrade (assuming that that's a
> possibility).
> > What I'd do is contact the support hotline (submit a case
> on the web-
> > support.xilinx.com) to open a case.  An engineer here at
> xilinx could easily
> > run your design in the 3.1i tools to see if that migration
> fixes the
> > problem- that way you can make sure that an upgrade would
> be beneficial.
> > Regards,
> > Tim
> >




Article: 27102
Subject: Re: VHDL: FFS in IOBs
From: Vikram Pasham <Vikram.Pasham@xilinx.com>
Date: Fri, 10 Nov 2000 11:09:39 -0800
Links: << >>  << T >>  << A >>

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

Harry,

For Spartan/ 4k family you can instantiate IFD or OFD flops in VHDL.
Check the Unisim library for component declaration of these components.
In Virtex/Spartan-II family you can use IOB=TRUE constraint on the
flops  to pack  them into IOBs..

Alternatively you can also use Map option "-pr" to pack all the IO FFs
into IOBs.

Hope this help !!!

Vikram
Xilinx Applications



Harry wrote:

> Hi,
> How to instantiate FFs in Xilinx IOBs in VHDL?? Please advise.
> Harry

--------------113AD88D53B438442FC583FC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Harry,
<p>For Spartan/ 4k family you can instantiate IFD or OFD flops in VHDL.
Check the Unisim library for component declaration of these components.
In Virtex/Spartan-II family you can use <a href="http://toolbox.xilinx.com/docsan/3_1i/data/common/lib/chap12/lib12006.htm#X83760">IOB=TRUE
</a>constraint on the flops&nbsp; to pack&nbsp; them into IOBs..
<p>Alternatively you can also use <a href="http://toolbox.xilinx.com/docsan/3_1i/data/common/dev/chap08/dev08004.htm">Map
option "-pr"</a> to pack all the IO FFs into IOBs.
<p>Hope this help !!!
<p>Vikram
<br>Xilinx Applications
<br>&nbsp;
<br>&nbsp;
<p>Harry wrote:
<blockquote TYPE=CITE>Hi,
<br>How to instantiate FFs in Xilinx IOBs in VHDL?? Please advise.
<br>Harry</blockquote>
</html>

--------------113AD88D53B438442FC583FC--


Article: 27103
Subject: Re: FFT LogiCore
From: Vikram Pasham <Vikram.Pasham@xilinx.com>
Date: Fri, 10 Nov 2000 11:32:52 -0800
Links: << >>  << T >>  << A >>
Dirk,

Generally these warning can be ignored as the synthesis tool is just
informing that it cannot find the lower level FFT core module. Sometimes
synthesis tools optimize these black box cores and sometimes they
don't optimize these lower level cores.

In order to eliminate these warnings use a black box declaration for the FFT
core in HDL. Here is an example of black box declaration in VHDL

attribute fpga_dont_touch : string;
attribute fpga_dont_touch of your_component_name : component is "true";

Verilog:
 synopsys attribute fpga_dont_touch "true"
 synopsys attribute fpga_dont_touch of YourInstanceName is "true"

These "don't touch" attributes will prevent the synthesis tools from
optimizing these black box cores.

Hope this helps !!!

Vikram
Xilinx Applications




Dirk Galda wrote:

> I am trying to include a LogiCore 64-FFT into my VHDL design. But when
> synthesizing the design with Foundation I am getting a warning:
>
> Dpm: Warning: Cannot link cell 'fft_top/fft_core' to its reference
> design 'vfft64'. (FPGA-LINK-2)
> Dpm: Warning: The cell '/ver1/fft_core' is not linked to any design.
> (FPGA-CHECK-4)
>
> The process finishes without errors, but it seems (from the number of
> slices during implementation) that the core is not included. Can anybody
> give an advice what's going wrong ?
>
> --
> +----------------------------------+----------------------------------+
> | Dirk Galda                       |                                  |
> |                                  |                                  |
> | TU Hamburg-Harburg               |                                  |
> | Department of Telecommunications | Phone:  (++49)-40-42878-2745     |
> | Eißendorfer Straße 40            | Fax:    (++49)-40-42878-2281     |
> | 21073 Hamburg                    | mailto:galda@tu-harburg.de       |
> | Germany                          | http://www.et2.tu-harburg.de     |
> +----------------------------------+----------------------------------+


Article: 27104
Subject: Virtex 32x1 RAM - Prevent usage
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 10 Nov 2000 15:28:27 -0500
Links: << >>  << T >>  << A >>
Hi all;

My apologies if this has been covered before. I searched this group at
deja.com, but didn't find anything.

To the question: I have a design which infers memory when synthesized with
Synplify. I would like to force it to use multiple 16x1s RAM primitives
instead of 32x1s primitives. I've looked through the various synthesis
directives pertaining to inferred memory, but there doesn't seem to be
anything which is appropriate.

I'm also open to other solutions which accomplish the same end - replacing
or preventing the usage of 32x1s memories while maintaining the same
functionality. Note that some of the memories are inferred using parameters,
so a black box (coregen) approach would be less than ideal.

Cheers,
Jamie



Article: 27105
Subject: Re: Virtex 32x1 RAM - Prevent usage
From: Ray Andraka <ray@andraka.com>
Date: Fri, 10 Nov 2000 20:56:09 GMT
Links: << >>  << T >>  << A >>
YOu can segment out the memory with intermediate signals to get 16xN, then use a
keep buffer (syn_keep) on those intermediate signals.

attribute syn_keep of ramhi:signal is true;
attribute syn_keep of ramlo:signal is true;
begin


ramhi<= ram(16+(addr mod 16));
ramlo<= ram(addr mod 16);
ramout<= ramhi when addr/16=1 else ramlo;




Jamie Sanderson wrote:
> 
> Hi all;
> 
> My apologies if this has been covered before. I searched this group at
> deja.com, but didn't find anything.
> 
> To the question: I have a design which infers memory when synthesized with
> Synplify. I would like to force it to use multiple 16x1s RAM primitives
> instead of 32x1s primitives. I've looked through the various synthesis
> directives pertaining to inferred memory, but there doesn't seem to be
> anything which is appropriate.
> 
> I'm also open to other solutions which accomplish the same end - replacing
> or preventing the usage of 32x1s memories while maintaining the same
> functionality. Note that some of the memories are inferred using parameters,
> so a black box (coregen) approach would be less than ideal.
> 
> Cheers,
> Jamie

-- 
-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  or http://www.fpga-guru.com

Article: 27106
Subject: Re: Leonardo for Altera
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 10 Nov 2000 13:12:01 -0800
Links: << >>  << T >>  << A >>
flavioas@my-deja.com wrote:
> 
>      Hi people,
> 
>      I am using Leonardo Spectrum for altera, trying to use a
> synthesizer better than maxplus2 for VHDL. But despite of
> checking 'setup maxplus2( create ACF file)option at Place&Route menu,
> it didn´t generate any ACF. So every time it runs maxplus2 to P&R it
> loses family, device and all information.

Leonardo uses it's own constraints file for pin information, not
an existing .acf file.

Rather than making a leo constraints file, 
it's less trouble to let maxplus make the .acf and
just edit that for the pins you really want.

Keep a copy of the .acf as maxplus likes to overwrite it.


--    mike.treseler at flukenetworks dot com

Article: 27107
Subject: Re: ViewLogic ViewDraw questions
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 10 Nov 2000 13:28:46 -0800
Links: << >>  << T >>  << A >>
On Sun, 5 Nov 2000 19:44:37 -0800, Tobin Fricke <tobin@pulsar.CS.Berkeley.EDU>
wrote:

>
>What is the proper way to do these things in ViewLogic's ViewDraw?
>
>  o Merge multiple buses.  Eg, say that I have A[31:0] and B[31:0].
>    I'd like to form C[31:0] from A[31:16] concatenated with B[15:0].
>    Is there an elegant way of doing this without making a VHDL block?

No need for VHDL.

You need just 3 things to do this, the BUF symbol, the $ARRAY
attribute, and compound signal labels.

Place a single BUF on your page, and attach a short bus stub on each
end.

Label the input bus stub: "A[31:16],B[15:0]"
Label the output stu:  "C[31:0]"
Attach an attribute to the BUF: "$ARRAY=32"

>
>  o Set a bus to a constant value.  Say I want F[31:0] to be set to
>    the constant value 0xDEADBEEF.  How is this done in the schematic
>    editor without resorting to a VHDL block?

No need for VHDL here either. I do this all the time. On every page of
my schematics, in the bottom left corner, I have the following:

A VCC symbol connected to the input of a BUF, and a net stub on
the output that is labeled "H"

A GND symbol connected to the input of a BUF, and a net stub on
the output that is labeled "L"

To create a constant,
Place a single BUF on your page, and attach a short bus stub on
each end.

Attach an attribute to the BUF: "$ARRAY=32"
Label the input stub (without the spaces):
"H,H,L,H,   H,H,H,L,   H,L,H,L,   H,H,L,H,
  H,L,H,H,   H,H,H,L,   H,H,H,L,   H,H,H,H"

Label the output "CONST_DEAFBEEF_[31:0]"

If you are going to do this a lot, you may want to create a small
library of 16 symbols that are labeled C0 thru CF, and each have
a 4 bit output. Use these to do it in hex rather than in binary as
above.

>Thanks,
>Tobin

you are welcome


Philip Freidin
Fliptronics

Article: 27108
Subject: Re: Non routable design
From: Ray Andraka <ray@andraka.com>
Date: Sat, 11 Nov 2000 00:03:26 GMT
Links: << >>  << T >>  << A >>
Unless you are placing the logic, you won't run into a routing problem in virtex
with this low a utilization.  Even when placing logic, it is difficult to block
routing to the point where it won't route (making timing is a different story). 
Most likely, he's got an invalid placement that is preventing a route, in which
case I've only seen carry chain elements and the f5 and f6 muxes cause this sort
of problem.  He already mentioned that he's not using F5, F6 muxes, so I
surmised it is improper carry chain usage or placement.  His follow on comments
seem to collaborate my speculation.  If he's not on current maintenance (which
is probably the case since he's using 2.1) then I can understand his reluctance
to try the hotline.

Mujtaba Hamid wrote:
> 
> Hello Fred,
> 
>         You are justified in expecting that a design with a 7 %
> utilization should not give problems
> while routing. However it's not just the density of the design that
> causing routing problems. There might
> an invalid route somewhere, or maybe there are a few CLBs which are so
> densely packed that routing them is becoming a problem.
> 
>         There are infinite possible combinations of design size /
> routing, and we try to verify as many as possible. However, there are
> always newer design algorithms that have not been taken into account.
> That's why Tim suggested to submit the design into Xilinx support, so
> that it can be verified that the new tools have already fixed the
> problem, before requesting an upgrade.
> 
> Best Regards,
> Mujtaba
> Xilinx Applications
> 
> fred wrote:
> 
> > Tim,
> >
> > I hope you will forgive an immediate deep-end response, but
> > I am frankly appalled by your reply. You admit you have not
> > seen the user's design but immediately suggest he shells out
> > for an upgrade. I can only hope that you did not notice that
> > the user has only a 7% utilisation within his device.
> >
> > Irrespective of his design type, a failure to route a <any?>
> > design with 7% utilisation is a likely tool bug or fault.
> > Your suggestion that he upgrade to get round the problem is
> > IMNSHO a major cop out and unworthy of you as a
> > representative of Xilinx. I am unaware whether this guy is
> > in maintenance or not but if it turns out he is not, and the
> > solution is indeed that he upgrade to get round a bug, may I
> > suggest he be provided with the upgrade for nowt as the F2.1
> > he was sold is 'not fit for purpose'.
> >
> > I notice Ray has provided what may be a more constructive
> > reply.
> >
> > Regards,
> >
> > D McLeod
> > XEC
> >
> > Disclaimer: I have assumed that Stephen's design does not
> > contain a fatal error which has caused the tools to give a
> > misleading error message (that never happens). My comments
> > on the 'upgrade regardless' approach remain.
> >
> > "Tim Jaynes" <tim.jaynes@xilinx.com> wrote in message
> > news:3A0B11F4.E0AAD7AA@xilinx.com...
> > > Hi Steven,
> > > Better PAR performance on routing pwr/gnd nets was one of
> > the major
> > > enhancements contained in the 3.1i tools and it's
> > associated service packs.
> > > Without seeing the design and without knowing your
> > budgetary constraints I'd
> > > recommend a software upgrade (assuming that that's a
> > possibility).
> > > What I'd do is contact the support hotline (submit a case
> > on the web-
> > > support.xilinx.com) to open a case.  An engineer here at
> > xilinx could easily
> > > run your design in the 3.1i tools to see if that migration
> > fixes the
> > > problem- that way you can make sure that an upgrade would
> > be beneficial.
> > > Regards,
> > > Tim
> > >

-- 
-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  or http://www.fpga-guru.com

Article: 27109
Subject: Re: Leonardo for Altera
From: Georg Berliner <gberlin@worldonline.dk>
Date: Sat, 11 Nov 2000 01:40:32 +0100
Links: << >>  << T >>  << A >>
On Fri, 10 Nov 2000 14:18:30 GMT, flavioas@my-deja.com wrote:

After entering Leonardo just save the project . Doing this you save
both the file(s) and contrains.
When running leonardo again just open the previously saved project

Georg

>



>
>
>     Hi people,
>
>     I am using Leonardo Spectrum for altera, trying to use a
>synthesizer better than maxplus2 for VHDL. But despite of
>checking 'setup maxplus2( create ACF file)option at Place&Route menu,
>it didn´t generate any ACF. So every time it runs maxplus2 to P&R it
>loses family, device and all information.
>      Any answer/suggestion is welcome,
>
>      Thanks in advance,
>
>      Flávio
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.


Article: 27110
Subject: Re: Configuring Xilinx FPGA using PIC16F84
From: "John Janusson" <null@null.com>
Date: Sat, 11 Nov 2000 00:45:46 GMT
Links: << >>  << T >>  << A >>
http://www.fpgaconfigurator.com/

I think it uses a PIC.

Independently, I've used a PIC for FPGA configuration, and it works quite
well, although it's a little slow for serial bit bang operations...

John

Kang Liat Chuan <kanglc@cyberway.com.sg> wrote in message
news:3a0ad556@news.starhub.net.sg...
> Hi,
>
> Has anyone done it? Is it possible? Target FPGA: Xilinx XC4005E-4
> I remember reading a web page on using Atmel AT89C2051 to configure the
> FPGA, but can't find any using PIC.
>
> Regards,
> LC
> kanglc@agilis.st.com.sg
>
>
>



Article: 27111
Subject: CRC, LFSR and scramblers
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 10 Nov 2000 21:48:54 -0500
Links: << >>  << T >>  << A >>
I posted this message earlier from the office, but it does not seem to
be showing up now, so I will ask again.

I am working on a CRC calculation which is similar to other calculations
that I need to do in an FPGA. Because we want to be target independant,
we will not be able to use any target specific optimizations. My problem
is that in performing CRC calculations for 32 bit parallel, the
equations end up being rather complex with up to about 20 inputs. This
is too many for the speeds we are trying to use (>=80 MHz). So we are
looking for alternative ways to reduce the complexity of the logic. 

One way that I have heard is to use a higher order polynomial which is a
multiple of the one desired. This can have the effect of spreading the
calculations over more bits so that each bit uses fewer inputs and can
be calculated at a faster rate. Then to get the correct result, a
polynomial division is done. The trick seems to be trying to find a
polynomial that makes the calculation simpler. 

Anyone heard of this and have any idea of how to find such a polynomial?


-- 

Rick "rickman" Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 27112
Subject: Number Format in DSP implementations
From: Saqib <saqib_03@hotmail.com>
Date: Sat, 11 Nov 2000 06:23:42 GMT
Links: << >>  << T >>  << A >>
During the hardware implementation of DSP algorithms like FIR/IIR
filters .. the most unclear thing is the binary number format used to
represent the input/output data and coefficients...to be specific about
this ..i have some questions which specially refer to the
implementation of FIR/IIR filters using the DISTRIBUTED ARITHMETIC
technique in FPGAs...

1)How to choose a specific number format for a given filter design..
meaning that how to decide that i should choose INTEGER 2's COMPLIMENT
format or FRACTIONAL 2's COMPLIMENT format or the MIXED 2's COMPLIMENT
format...while keeping in mind that in real filters most of the
coefficients are real ... fractions or mixed ...I think that the filter
response must be the same what ever format u choose?

2)Suppose one chooses the INTEGER 2's COMPLIMENT format ..then does it
mean that the filter input is REALLY an INTEGER or what does it mean..?
or is there any kind of NORMALIZATION required? an example would be
plus..

3)Using the same INTEGER 2's COMPLIMENT format...how do we deal with
the real valued coefficients..? Is any type of QUANTIZATION and
NORMALIZING is required here..? an example would be plus...

4)Suppose we do SOMETHING to the coefficients or input data...then how
to predict the filter OUTPUT...? If suppose we scaled all coefficients
by the value of 2^4 ..then does it mean that output should be divided
by 2^4 to get the correct value?...or whats the proper way..?

5)Do the bit combinations of the output remain same if we change the
number format or otherwise?

6)Where i can get some useful material on this fixed point binary
number theory..?
--
--saqib yaqub--


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27113
Subject: Webpack 3.2WP3.x from Xilinx is useless
From: jaypt123@my-deja.com
Date: Sat, 11 Nov 2000 06:43:33 GMT
Links: << >>  << T >>  << A >>
I downloaded Webpack release version Webpack 3.2WP3.x from Xilinx.
The installation was OK. However, when I run the software there is
error as follows.

-------------------------------------------------------------------

Starting: 'ngdbuild -f ngdbuild.rsp '


Release WebPACK 3.2WP3.x - ngdbuild D.22
Copyright (c) 1995-2000 Xilinx, Inc.  All rights reserved.

Command Line: ngdbuild -dd __ngo -nt timestamp -sd
D:\Xilinx_WebPACK\Spartan2\data\map -p 2S200-FG456-5 stopwatch.edn
stopwatch.ngd

Launcher: "stopwatch.ngo" is up to date.
Reading NGO file "D:/Xilinx/watchvhd/__ngo/stopwatch.ngo" ...
Reading component libraries for design expansion...

Checking timing specifications ...

Checking expanded design ...

  The XML Parser environment is incorrectly set up, preventing it from
  finding its text transcoding files. Normally these will be located
  via the ICU_DATA environment variable, or located relative to the
  XML4C2 DLL (or SharedLib.) Please check your installation
EXEWRAP detected a return code of '9999' from program 'ngdbuild'

Done: failed with exit code: 9999.
------------------------------------------------------------

Since this is a free software, I don't know if Xilinx is willing
to answer any question. For now, it is a useless software.


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27114
Subject: Re: Anything wrong with Xilinx website?
From: "Robert Sturm" <roberts@xilinx.com>
Date: Sat, 11 Nov 2000 00:16:55 -0700
Links: << >>  << T >>  << A >>
Hi all-

We are currently looking into this issue and will try and implement a remedy as quickly as possible.  You can keep us apraised of any immediate issues you might be having by sending us<a href="http://support.xilinx.com/support/asksxc.htm">Feedback</a> or by opening a WebCase with our Technical Support Hotline.

Thanks for your help.

Robert Sturm~
Manager - support.xilinx.com

Article: 27115
Subject: Re: Configuring Xilinx FPGA using PIC16F84
From: "Berni Joss" <berni_13@yahoo.com>
Date: Sat, 11 Nov 2000 12:55:31 +0100
Links: << >>  << T >>  << A >>
Using the 16F84 alone will probably not work as it has only 1k word of flash
ROM both for tables & code. I guess you will need an external memory EEPROM,
Flash, FRAM, or other?

Hope this helps,
Berni.

"Kang Liat Chuan" <kanglc@cyberway.com.sg> wrote in message
news:3a0ad556@news.starhub.net.sg...
> Hi,
>
> Has anyone done it? Is it possible? Target FPGA: Xilinx XC4005E-4
> I remember reading a web page on using Atmel AT89C2051 to configure the
> FPGA, but can't find any using PIC.
>
> Regards,
> LC
> kanglc@agilis.st.com.sg
>
>
>



Article: 27116
Subject: Re: Non routable design
From: Steven Derrien <sderrien@irisa.fr>
Date: Sat, 11 Nov 2000 14:10:55 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> Unless you are placing the logic, you won't run into a routing problem in virtex
> with this low a utilization.  Even when placing logic, it is difficult to block
> routing to the point where it won't route (making timing is a different story).
> Most likely, he's got an invalid placement that is preventing a route, in which
> case I've only seen carry chain elements and the f5 and f6 muxes cause this sort
> of problem.  He already mentioned that he's not using F5, F6 muxes, so I
> surmised it is improper carry chain usage or placement.  His follow on comments
> seem to collaborate my speculation.  If he's not on current maintenance (which
> is probably the case since he's using 2.1) then I can understand his reluctance
> to try the hotline.

Actually, i've just openened a support case, and updgrading to 3.2 isn't
a problem 
since I already have both versions installed on my machine. 

What I am concerned with now, is to understand the very exact nature for
the use of MUXCY_L XORCY_L primitive and their impact on the routing
strategy.

> 
> Mujtaba Hamid wrote:
> >
> > Hello Fred,
> >
> >         You are justified in expecting that a design with a 7 %
> > utilization should not give problems
> > while routing. However it's not just the density of the design that
> > causing routing problems. There might
> > an invalid route somewhere, or maybe there are a few CLBs which are so
> > densely packed that routing them is becoming a problem.
> >
> >         There are infinite possible combinations of design size /
> > routing, and we try to verify as many as possible. However, there are
> > always newer design algorithms that have not been taken into account.

In this case the problem appears in a pipelined floating point
multiplier, and more preciseliy in the integer multiplier which handles
Mantissas. I don't see this as a very "exotic" design, since the
structure is very regular there shouldn't be any routing difficulty !


> > That's why Tim suggested to submit the design into Xilinx support, so
> > that it can be verified that the new tools have already fixed the
> > problem, before requesting an upgrade.

See above ...

BTW, I didn't meant to start a flame war :))

Steven

Article: 27117
Subject: Re: Alliance under Linux?
From: "Kasper Pedersen" <kasper@traceroute.dk>
Date: Sat, 11 Nov 2000 15:36:51 +0100
Links: << >>  << T >>  << A >>

"Zoltan Kocsi" <root@127.0.0.1> wrote in message
news:m31ywpzgf4.fsf@tade.bendor.com.au...
> Ray Andraka <ray@andraka.com> writes:
> If you always contribute the bugfixes and improvements back to the
> community then all changes get merged in and the incompatibity will
> not cause nightmares. Instead of having incompatible versions, you
> end up with incremental improvements. Also, as long as the tool is
> free (as in speech) and is under some public source control facility,
> you (or your client) can re-create any given version of the tool, if
> your solution actually depends on the existence of some bug.

Yup. I use open source compilers and other tools, and it happen to me around
once every two months: I am working on some project, and a bug shows up. Now
what to do?
I have the source, so I can see what's going on. The source is usually
complex, I don't understand it all, and I haven't got the time to get to
know it thoroughly. But in  few hours I've usually got a clue, and
eventually I find the place where it's going wrong.

Now I have two options:
1) patch the code, and mail the suggested fix to the maintainer. If the fix
is large, it might be dangerous and I won't fix it myself, but I can deliver
an outstanding bug report to the maintainer. In an average of 2.5 days I've
got either an approval for the fix, a modified fix, or a complete rewrite.

2) Work around it. Known bugs don't bite.

When it's a closed-source app, it usually takes longer. The average fix-time
I've experienced is two months, the customers don't like that, and my boss
certainly doesn't like that.
For things that don't change much, closed-source works. For things that
can't sit still, open source helps.

/Kasper


Article: 27118
Subject: Re: Number Format in DSP implementations
From: Ray Andraka <ray@andraka.com>
Date: Sat, 11 Nov 2000 15:29:46 GMT
Links: << >>  << T >>  << A >>


Saqib wrote:
> 
> During the hardware implementation of DSP algorithms like FIR/IIR
> filters .. the most unclear thing is the binary number format used to
> represent the input/output data and coefficients...to be specific about
> this ..i have some questions which specially refer to the
> implementation of FIR/IIR filters using the DISTRIBUTED ARITHMETIC
> technique in FPGAs...
> 
> 1)How to choose a specific number format for a given filter design..
> meaning that how to decide that i should choose INTEGER 2's COMPLIMENT
> format or FRACTIONAL 2's COMPLIMENT format or the MIXED 2's COMPLIMENT
> format...while keeping in mind that in real filters most of the
> coefficients are real ... fractions or mixed ...I think that the filter
> response must be the same what ever format u choose?

In most cases, the filter coefficients are signed so you use 2's complement
(there are some filters such as a gaussian filter tha have all positive
coefficients so you can save a little by using unsigned).  As you pointed out,
the distributed arithmetic filters are fixed point designs.  This requires you
to quantize your real signal as well as real coefficients.  As far as fractional
vs integer format goes, the hardware knows no difference.  These formats merely
imply the position of the radix point, and as it turns out, you really can put
it any where you like.  The filter hardware is dealing with integers, but you
can apply an implied power of two scaling to fit your needs.  Normally, one
would select the coefficient scaling such that the largest coefficient fills the
available bits, and same with the input.  In the case of distributed arithmetic
filters, the output has enough bits to represent the sum of the products of all
coefficients with a maximum magnitdue input.  You put an implied radix point in
the output based on it's position in the inputs.

> 
> 2)Suppose one chooses the INTEGER 2's COMPLIMENT format ..then does it
> mean that the filter input is REALLY an INTEGER or what does it mean..?
> or is there any kind of NORMALIZATION required? an example would be
> plus..
> 
> 3)Using the same INTEGER 2's COMPLIMENT format...how do we deal with
> the real valued coefficients..? Is any type of QUANTIZATION and
> NORMALIZING is required here..? an example would be plus...
> 
> 4)Suppose we do SOMETHING to the coefficients or input data...then how
> to predict the filter OUTPUT...? If suppose we scaled all coefficients
> by the value of 2^4 ..then does it mean that output should be divided
> by 2^4 to get the correct value?...or whats the proper way..?
> 
> 5)Do the bit combinations of the output remain same if we change the
> number format or otherwise?
> 
> 6)Where i can get some useful material on this fixed point binary
> number theory..?

Randy Yates has some on-line material discussing fixed point FIR filters at you
might also get a copy of Isreal Koren's computer artihmetic algorithms text,
which has a pretty good treatment of fixed point number theory. There's a link
to his page on my website 'links' page.


> --
> --saqib yaqub--
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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  or http://www.fpga-guru.com

Article: 27119
Subject: Re: Alliance under Linux?
From: Duane <junkmail@junkmail.com>
Date: Sat, 11 Nov 2000 09:43:04 -0800
Links: << >>  << T >>  << A >>
Kasper Pedersen wrote:
> 
> "Zoltan Kocsi" <root@127.0.0.1> wrote in message
> news:m31ywpzgf4.fsf@tade.bendor.com.au...
> > Ray Andraka <ray@andraka.com> writes:
> > If you always contribute the bugfixes and improvements back to the
> > community then all changes get merged in and the incompatibity will
> > not cause nightmares. Instead of having incompatible versions, you
> > end up with incremental improvements. Also, as long as the tool is
> > free (as in speech) and is under some public source control facility,
> > you (or your client) can re-create any given version of the tool, if
> > your solution actually depends on the existence of some bug.

Oops, careful with our quotes. Just to be clear, Ray Andraka didn't
write that.

> 
> Yup. I use open source compilers and other tools, and it happen to me around
> once every two months: I am working on some project, and a bug shows up. Now
> what to do?
> I have the source, so I can see what's going on. The source is usually
> complex, I don't understand it all, and I haven't got the time to get to
> know it thoroughly. But in  few hours I've usually got a clue, and
> eventually I find the place where it's going wrong.
> 
> Now I have two options:
> 1) patch the code, and mail the suggested fix to the maintainer. If the fix
> is large, it might be dangerous and I won't fix it myself, but I can deliver
> an outstanding bug report to the maintainer. In an average of 2.5 days I've
> got either an approval for the fix, a modified fix, or a complete rewrite.
> 
> 2) Work around it. Known bugs don't bite.
> 
> When it's a closed-source app, it usually takes longer. The average fix-time
> I've experienced is two months, the customers don't like that, and my boss
> certainly doesn't like that.
> For things that don't change much, closed-source works. For things that
> can't sit still, open source helps.

Yep. A couple months back, when service pack three was released for the
Xilinx M3.1 tools, it triggered a bug in Wine. A few days later, the
Wine gurus got together with the finder of the bug in an extended online
chat session and tracked it down and fixed it. Now that's service!

--
My real email is akamail.com@dclark (or something like that).

Article: 27120
Subject: Re: PLL vs DLL
From: "Steve Fair" <sfair6@home.com>
Date: Sat, 11 Nov 2000 18:14:00 GMT
Links: << >>  << T >>  << A >>
Anshuman -

I saw the Xilinx marketing response re:  PLL vs. DLL - if you want the
Altera marketing material, please look at:

http://www.altera.com/document/tb/tb60.pdf

Contrary to Xilinx's marketing material, PLL's do have a number of
advantages (jitter, accuracy, multiply/divide capabilities, and speed).
Also contrary to the information in the Xilinx response, PLL's are not as
hard to manufacture as listed - most ASIC houses have PLLs available as
cores.  The PLLs are manufacturable enough that Altera is including them at
no extra cost in their low-cost ACEX family (-1 and -2 speed grades).
Enough marketing . . .

As mentioned, PLLs and DLLs need an accurate source clock in order to lock -
wide ranging source clock PLLs are available but you'll have to go external
to the FPGA world at this time.  One note - PLLs/DLLs will not improve
internal timing by a great deal - the dedicated clocks in FPGAs do a pretty
good job of minizing skew.  PLLs/DLLs are useful for clock multiplication
and division (PLLs rule this area) or improving clock to out (my favorite
use) or internal performance (again, no panacea).

If you're really fighting I/O timings, the Altera APEX PLLs have a nice
clock skew capability on the output (I don't think the Xilinx part has this
capability??) - you can skew the clock to the data or use clock feedback to
deskew the board delay.  This can be handy for things like SDRAM
interfaces - just realize that nothing's free - you're usually stealing time
from somewhere else if you do this.

Bottom line, both PLLs and DLLs are both useful depending on the
application.  Altera has a good app note on various applications - happy
reading!!

http://www.altera.com/document/an/an115.pdf

Steve





"Anshuman Sharma" <gte600f@prism.gatech.edu> wrote in message
news:8uahch$91$1@news-int.gatech.edu...
> I'm working on designing a low level packet filter on an FPGA. Since it
> needs run at very high speeds, which would be more advisable to use, PLL
> or a DLL?
>
> --
> Anshuman Sharma
> Georgia Institute of Technology



Article: 27121
Subject: Re: CoolRunner news :(
From: "Steve Fair" <sfair6@home.com>
Date: Sat, 11 Nov 2000 18:28:49 GMT
Links: << >>  << T >>  << A >>
Peter -

Try an Altera EPM3032ALC44-10, $1 single piece pricing
EPM3064ALC44-10, $1.95 single piece pricing.  EEPROM based,
non-volatile.  Supported by JTAG ISP.

Steve

>
> The Philips 22V10, almost zero power, was a great solution at the
> right price, about $2 (1k+). If you can do an FPGA for that price, or
> even $3, with on-chip config FLASH, then I will eat my words.
>



Article: 27122
Subject: Re: CRC, LFSR and scramblers
From: Mohammed Ishaq <ishaq@my-dejanews.com>
Date: Sat, 11 Nov 2000 18:43:19 GMT
Links: << >>  << T >>  << A >>
hi,

You have not mentioned which CRC you are using. I guess it is CRC-32. To
reduce the complexity of the CRC, you should use a lower order
polynomial CRC, say in your case CRC-16 or CRC-CCITT and pass the 32 bit
data in serially. I suggest you use CRC-CCITT since it is widely used
(serial communications, floppy controller etc) and the psedu-code is
also available in the web, if you search for CRC-CCITT.

If you are not happy with your search results, I can post the URLs I
have.

good luck

ishaq

ps: Please reduce your posting footer to perhaps 2lines. Its just a
waste if space. If you would like to advertise, as you have done, all
you need is your URL, The rest of the address is redundant.


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27123
Subject: Re: CRC, LFSR and scramblers
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 11 Nov 2000 15:42:34 -0500
Links: << >>  << T >>  << A >>
I have no choice in the polynomial to be used. This is specified in the
different specs I am working with. I also can not perform the
calculation serially. We are processing 32 bits of data on each clock
cycle. So I must perform the calculation on all 32 bits at once. I have
calculated the logic to do this, but it requires as many as 20 inputs
for one bit. This uses too many levels of logic in an FPGA to calculate
in one clock cycle. So I am looking for ways to reduce the complexity of
the calculation. 

I have already rejected pipelining the calculation since we have to have
the result from one calculation to start the next calculation on the
next clock cycle. 

So I am looking for a way to transform the problem into one I can
pipeline such as calculating a different CRC which can be divided by a
polynomial to get the result of the CRC I am looking for. I am not
trying to solve a single CRC calculation. I am trying to solve the
general case. 

I would be happy to see any CRC URLs that you might have. 


Mohammed Ishaq wrote:
> 
> hi,
> 
> You have not mentioned which CRC you are using. I guess it is CRC-32. To
> reduce the complexity of the CRC, you should use a lower order
> polynomial CRC, say in your case CRC-16 or CRC-CCITT and pass the 32 bit
> data in serially. I suggest you use CRC-CCITT since it is widely used
> (serial communications, floppy controller etc) and the psedu-code is
> also available in the web, if you search for CRC-CCITT.
> 
> If you are not happy with your search results, I can post the URLs I
> have.


-- 

Rick "rickman" Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 27124
Subject: Re: PLL vs DLL
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sat, 11 Nov 2000 14:08:04 -0800
Links: << >>  << T >>  << A >>
Let me correct some misconceptions below:

Steve Fair wrote:  <snip>

> As mentioned, PLLs and DLLs need an accurate source clock in order to lock -
> wide ranging source clock PLLs are available but you'll have to go external
> to the FPGA world at this time.  One note - PLLs/DLLs will not improve
> internal timing by a great deal - the dedicated clocks in FPGAs do a pretty
> good job of minizing skew.

I disagree. Yes, clock skew is determined ( and kept reasonably low ) by the
strong dedicated clock driver tree structure.
It is the inherent clock DELAY that can be eliminated by a PLL or DLL. And on
large chips, eliminating the basic clock delay ( and only having to worry about
the much smaller clock skew ) lets you achieve considerably higher performance.

> PLLs/DLLs are useful for clock multiplication
> and division (PLLs rule this area) or improving clock to out (my favorite
> use) or internal performance (again, no panacea).
>
> If you're really fighting I/O timings, the Altera APEX PLLs have a nice
> clock skew capability on the output (I don't think the Xilinx part has this
> capability??)

Xilinx DLLs have exactly the same capabilty, we call it "clock mirroring". You
can use the FPGA to be your zero-delay clock driver. Considering the multitude
of I/O standards supported in Virtex FPGAs, this feature can be quite handy.

> - you can skew the clock to the data or use clock feedback to
> deskew the board delay.  This can be handy for things like SDRAM
> interfaces - just realize that nothing's free - you're usually stealing time
> from somewhere else if you do this.

You are not stealing anything, you are using a trick, introducing additional
delay on a repetitive clock signal, so that it looks as if you reduced the
delay to nothing ( even to a negative value, if you are clever ).  Obviously,
this trick works only on a free-running clock.

Peter Alfke, Xilinx Applications




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