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 47200

Article: 47200
Subject: Re: Xilinx ISE5.1 and Windows NT
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 20 Sep 2002 11:46:30 +0100
Links: << >>  << T >>  << A >>


Kamal Patel wrote:

> Giuseppe,
>
> This is correct.  Windows XP and Windows 2000 will
> be the only supported Microsoft operating systems
> for 5.1i, although 5.1i should still install and
> run fine on Windows NT.
>
> Regards,
> Kamal Patel
> Xilinx Apps

Oh bloody brilliant :-((! Drop support for the only (nearly) reliable
O/S MS have ever managed to produce in 20 years of hacking [and only got
there 'cos DEC were using it as well]. That W2K sign on ``built on NT
technology'' makes me spit with anger every time I see it.



Article: 47201
(removed)


Article: 47202
Subject: Re: XCV600 Version and Firmware
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Sep 2002 12:20:27 GMT
Links: << >>  << T >>  << A >>
http://www.xilinx.com/partinfo/ds003.htm

John wrote:

> I'm having difficulty finding information on XCV600's on the Xilinx site.  Part of the problem is I know nothing about this type of part, including terminology.  I have two boards with this part, but do not know how to check if they are the same revision, whether the firmware (?) is the same, or where to get the firmware, if it is compatible.  Any constructive suggestions would be appreciated.

--
--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: 47203
Subject: Re: Multiple divide by 10
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Fri, 20 Sep 2002 13:17:43 GMT
Links: << >>  << T >>  << A >>
Ahhhh, that would be why you guys are paying a million bucks for an ASIC!
When your design is fully synchronous, timing closure is nearly automatic.


"Muzaffer Kal" <kal@dspia.com> wrote in message
news:l7mlou47nfvldqko1fn4lg2ddv4q7sreod@4ax.com...
> On Fri, 20 Sep 2002 03:55:02 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >In Peter's defense, I see several designs a year that claim to have
intention
> >to move to an ASIC.  Few if any ever do.  Worse, if you code for an easy
> >transition to an ASIC, you leave many of the FPGA features on the table,
> >resulting in a design that is both bigger and slower than it would be for
a
> >design specifically targeted to the FPGA.  My advice if you intend to go
that
> >route is to design specifically to the FPGA, then later if you decide to
go to
> >ASIC start fresh.
>
> Actually there is no reason to start fresh with the ASIC. Anything you
> can do with any FPGA, you can do in standard cell easily (maybe except
> the 16 bit memory blocks, larger size SRAM is relatively easy). So it
> makes sense to use all features of the FPGA and then map them to
> standard cell. I'd bet one can do better with a .25u standard cell
> ASIC than any optimized FPGA at .13u process. One exception maybe the
> multipliers in Virtex-II or better the DSP block in Stratix.
> Especially the latter takes advantage of fully custom hard macro in a
> .13u 8LM copper process so it would be difficult to do better with
> .25u. But having the full flexibility of having all the metal layers
> only to the routing of hard wired gates still might be an advantage.
>
> Muzaffer Kal
>
> http://www.dspia.com
> ASIC/FPGA design/verification consulting specializing in DSP algorithm
implementations



Article: 47204
Subject: Re: Multiple divide by 10
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Fri, 20 Sep 2002 13:22:05 GMT
Links: << >>  << T >>  << A >>
This is my last note on this thread.  Chip express doesn't
say it takes 30 masks.  Sounds like he's getting the
bendover special if he's paying a million for a fully
synchronous, pure digital asic, even if you had a million
asic gates, it shouldn't cost that much.  IMHO.

BB
=============================================
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3D8AB923.2A77F16D@yahoo.com...
> Peter Alfke wrote:
> >
> > Blackie Beard wrote:
> >
> > > Keep your design synchronous, or it will be
> > > a real beach to get an ASIC made later. <snip>
> >
> > How many people can still afford an ASIC?
> >
> > I don't want to start a flame, am just curious.
> > At 130 nm just the mask set (~30 masks) is close to a million dollars,
> > excluding design and verification efforts (That's a basic fact, we pay
this all
> > the time)...
> > Is this irrelevant?
> > Just asking, I may be living in a biased environment. Please no flames !
> >
> > Peter Alfke
>
> So just go with a 210 nm process where they are begging you to use their
> fabs.  Maybe they are having a special and will give the masks away for
> free!!!  B^)
>
> The OP was using an XCS05!  I don't think that is done in anything close
> to a 130 nm process, is it?  What are we talking, 250 nm or bigger,
> right?
>
> --
>
> 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      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 47205
Subject: Re: Multiple divide by 10
From: Andrew MacCormack <andrewm@cadence.com>
Date: Fri, 20 Sep 2002 14:29:32 +0100
Links: << >>  << T >>  << A >>
Blackie Beard wrote:
> 
> Ahhhh, that would be why you guys are paying a million bucks for an ASIC!
> When your design is fully synchronous, .
> 
Anything complicated enough to make an ASIC out of would tend to have
multiple clock domains, etc. It would tend to be synchronous within each
domain, but if "timing closure is nearly automatic" were true then why
do we at Tality get paid piles of dosh to do the layout for so many
designs?


-- 
  ___#---   Andrew MacCormack               andrewm@tality.com
  L_   _|   Senior Design Engineer
    | |     Tality, Alba Campus, Livingston EH54 7HH, Scotland
    ! |     Phone: +44 1506 595360        Fax: +44 1506 595959
             
T A L I T Y                http://www.tality.com

Article: 47206
Subject: Re: ieee.math_real for presynthesis table calculation in vhdl
From: hamish@cloud.net.au
Date: 20 Sep 2002 13:32:47 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote:
> I think synplicity does now too.  My point is I'd like to see it in the LRM so
> that the code can be made portable between tools.

7.2.0 seems to accept reals for constants; previous versions didn't,
unfortunately.

I'm constantly amazed at how badly these tools support data types that
are only used to generate constants.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 47207
Subject: Re: Multiple divide by 10
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Sep 2002 13:35:59 GMT
Links: << >>  << T >>  << A >>
Umm, I didn't mean to imply that the FPGA designs are not synchronous...We do
all of our designs strictly synchronous.  The design rules are basically ASIC
design rules.  The trouble comes in when we instantiate FPGA primitives, which
is something we do to put placement in the code and enforce use of specific FPGA
features in order to reduce the time to a design that works at the top end of
the performance and density envelope for FPGAs.  An FPGA design is generally
pipelined much deeper than an ASIC, uses ripple carry logic in all the
arithmetic and uses internal memory that may be expensive to implement in an
ASIC (we make extensive use of the dynamic delay feature of the SRL16 element to
optimize the design, for example).   Even at a strictly RTL level coding, the
FPGA architectures tend to favor much deeper pipelining and no gated clocks in
an FPGA, which is no good for low power ASICs.

Blackie Beard wrote:

> Ahhhh, that would be why you guys are paying a million bucks for an ASIC!
> When your design is fully synchronous, timing closure is nearly automatic.
>
> "Muzaffer Kal" <kal@dspia.com> wrote in message
> news:l7mlou47nfvldqko1fn4lg2ddv4q7sreod@4ax.com...
> > On Fri, 20 Sep 2002 03:55:02 GMT, Ray Andraka <ray@andraka.com> wrote:
> >
> > >In Peter's defense, I see several designs a year that claim to have
> intention
> > >to move to an ASIC.  Few if any ever do.  Worse, if you code for an easy
> > >transition to an ASIC, you leave many of the FPGA features on the table,
> > >resulting in a design that is both bigger and slower than it would be for
> a
> > >design specifically targeted to the FPGA.  My advice if you intend to go
> that
> > >route is to design specifically to the FPGA, then later if you decide to
> go to
> > >ASIC start fresh.
> >
> > Actually there is no reason to start fresh with the ASIC. Anything you
> > can do with any FPGA, you can do in standard cell easily (maybe except
> > the 16 bit memory blocks, larger size SRAM is relatively easy). So it
> > makes sense to use all features of the FPGA and then map them to
> > standard cell. I'd bet one can do better with a .25u standard cell
> > ASIC than any optimized FPGA at .13u process. One exception maybe the
> > multipliers in Virtex-II or better the DSP block in Stratix.
> > Especially the latter takes advantage of fully custom hard macro in a
> > .13u 8LM copper process so it would be difficult to do better with
> > .25u. But having the full flexibility of having all the metal layers
> > only to the routing of hard wired gates still might be an advantage.
> >
> > Muzaffer Kal
> >
> > http://www.dspia.com
> > ASIC/FPGA design/verification consulting specializing in DSP algorithm
> implementations

--
--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: 47208
Subject: Re: Multiple divide by 10
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Sep 2002 13:47:28 GMT
Links: << >>  << T >>  << A >>
The point is that a design for maximum FPGA performance/density includes architectural
decisions that may not map very efficiently to an ASIC.  Take a DSP design for example.
In the FPGA, we add pipeline stages as much as possible before and after arithmetic in
order to minimize the delays added onto the carry chain.  In an ASIC, you don't have
built-in carry chains, and you don't have the rigid routing delay structure so it often
makes sense to use things like Wallace trees where it didn't in the FPGA.  The design
constraints, and cost functions for different structures are different for an ASIC than
they are for an FPGA.

Sure, you can port a design for one to the other but it is not a free lunch.  ASIC to FPGA
will usually wind up much larger and slower than is possible with a design specifically
targeted to the FPGA.  FPGA to ASIC can also be done, but it may require limits on the
FPGA primitives allowed or construction of special library elements to map those
primitives to.  Not a problem for basic logic (although it may be pipelined much deeper
than necessary), more of a problem for the arithmetic just from an area and speed
perspective, and a bigger problem for clock DLLs, CLBRAMs, SRL16's and dual ported
memories.  I'm not saying that it can't be done, just that in the long run I think the
cost of the reengineering effort is negligable and provides benefits worth more than the
cost for those who can truely justify going to an ASIC.

Muzaffer Kal wrote:

> On Fri, 20 Sep 2002 03:55:02 GMT, Ray Andraka <ray@andraka.com> wrote:
>
> >In Peter's defense, I see several designs a year that claim to have intention
> >to move to an ASIC.  Few if any ever do.  Worse, if you code for an easy
> >transition to an ASIC, you leave many of the FPGA features on the table,
> >resulting in a design that is both bigger and slower than it would be for a
> >design specifically targeted to the FPGA.  My advice if you intend to go that
> >route is to design specifically to the FPGA, then later if you decide to go to
> >ASIC start fresh.
>
> Actually there is no reason to start fresh with the ASIC. Anything you
> can do with any FPGA, you can do in standard cell easily (maybe except
> the 16 bit memory blocks, larger size SRAM is relatively easy). So it
> makes sense to use all features of the FPGA and then map them to
> standard cell. I'd bet one can do better with a .25u standard cell
> ASIC than any optimized FPGA at .13u process. One exception maybe the
> multipliers in Virtex-II or better the DSP block in Stratix.
> Especially the latter takes advantage of fully custom hard macro in a
> .13u 8LM copper process so it would be difficult to do better with
> .25u. But having the full flexibility of having all the metal layers
> only to the routing of hard wired gates still might be an advantage.
>
> Muzaffer Kal
>
> http://www.dspia.com
> ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations

--
--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: 47209
Subject: Re: Feasibility of 100 tap adaptive FIR design on FPGA
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Sep 2002 14:06:22 GMT
Links: << >>  << T >>  << A >>
At that low (10 Hz is almost glacial) sample rate, it seems you could use a DSP micro
instead.  Our rule of thumb is that if you can do it in a single DSP microprocessor, don't
use an FPGA.  The design talent for a software solution is cheaper and easier to find than
hardware designers who understand DSP.  That said, if you do do this in an FPGA,  you can
use a single multiplier plus EAB memories (I believe you stated a preference for Altera)
in a structure that is not much different than what you would do in the microprocessor.
In effect what you are doing is time multiplexing all the taps through a single
multiplier.  If not fast enough, you can duplicate the multiplier as needed.

At much faster sample rates, you would want to shift to a distributed arithmetic type
architecture provided you had a way to update the coeficients at the desired rate.  In
Altera parts that is tough because you don't have a wayto update the LUT equations.  In
xilinx, you can replace the DA LUTs with SRL16 shift register elements, which when not
shifting behave exactly like a LUT.  This provides a reload mechanism for the LUTs that
takes 16 clocks to reload each LUT.  Using this method, it is possible to build adaptive
DA filters in Xilinx parts.

Dongho wrote:

> Actually I'm trying to implement LMS FIR filter with 100 input
> channels.
> So there will be 100 adaptive FIR filters(with 10 taps) and
> adder(which will sum the 100 FIR output and subtract the desired input
> from there).
> And I need to update the weights(coef) of each 100 FIR filter.
> sampling rate : 10Hz(100ms) so I need to update weights within 100ms.
> precision : input(16bits), coefficient(24bits)
>
> thanks
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3D88F8FE.C559AC67@andraka.com>...
> > You don't mention the required performance.  It makes a huge difference.
> > Particularly, you need to state the sample rate as well as the
> > coefficient update rate.  It would also help to know the precision (bits)
> > of the inputs and coefficients.  There are ways to do this, subject to
> > certain restrictions.  Let's see what your requirements are first.
> >
> > Dongho wrote:
> >
> > > Hi,
> > >
> > >    I'd like to implement adaptive FIR filter with 100 tap in FPGA.
> > >    To implement this, I need 100 multiplier to multiply weight.
> > >    How to measure the area(or gate?) to measure this filter so that I
> > > can find appropriate chip?
> > > Thanks in advance for your response.
> > >
> > > -Regards
> > >
> > > dongho
> >
> > --
> > --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: 47210
Subject: Question on Spartan2E maximum toggle frequency
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Fri, 20 Sep 2002 10:08:59 -0400
Links: << >>  << T >>  << A >>
Hi,
    I am looking at the specifications for the spartan2e in a dash 7 speed
grade part.  The spec sheet says maximum toggle frequency (for export
control) is 400MHz.  What is the intent of the "for export control"
statement.  Is that a US government requirement or does it mean "export" as
in "off-chip"?  I suspect the former is the case.

My high-speed pulse width timer design uses a pair of DLL's in the
high-speed mode.  The first acts as a doubler, the second just generates
clean 0 and 180 degree outputs.  I then buffer these two outputs and use
them to drive a pair of 2 bit pre-scalers.  Currently, the pre-scalers run
at 204.8 MHz with the initial input at 102.4 MHz.  I am considering the
possibility of doubling the input clock to 204.8 MHz and running the
prescalers at 409.6 MHz.

By the way, I know I could have used 4 counters with the 0, 90, 180, and 270
outputs from the first DLL.  The problem was in selecting and routing the
appropriate buffers for the 4 phases.  By the time I got them routed, the
phase delays were no longer identical.  The two phase system works much
better.

Thanks,
Theron Hicks



Article: 47211
Subject: Re: GCLK pin used like an standard input
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Sep 2002 14:12:36 GMT
Links: << >>  << T >>  << A >>
BUFGs drive the clock networks only and can't be used for anything else.  These have inputs inside
the part, so they can be driven by anything in the FPGA.

IBUFGs are the input buffers on the 4 GCLK pins.  They are special I/O to the device that are
optimized for clock.  Unlike the other I/O they do not have registers and are input only.  These are
normally associated with clocks, but can also be used for general purpose inputs, subject to the
limitation that you can't register in the IOB.



Laurent Gauch wrote:

> Rajeev,
>
> (1) Fro me , the IBUFG drives the global clock. These global clock may
> come from an internal FPGA signal or from the 4 specific GCLK pads (for
> XCV). But a IBUFG is dedicated for each GCLK pads, also each GCLK pads
> can ONLY be routed to the IBUFG.
>
> Maybe : if 3 GCLK pads are used as clock inputs, in this case 3
> corresponding IBUFGs are used. IF I use the last IBUFG for an internal
> clock source, the Reset signal (or other asynchronous signal) on the
> corresponding last GCLK pad can not be routed!
>
> Is that true?
>
> Laurent Gauch, Amontec
>
> Rajeev wrote:
>
> > Laurent,
> >
> > As I understand it,
> > (1) IBUFG does not drive a global clock net (that's BUFG's job)
> > (2) IBUFG output can drive non-clock inputs
> > so you can use IBUFG for your enable signal, as I did with an eval
> > board where the reset button was wired to a GCLK pin.  You get a
> > warning message (IBUFG driving non-clock inputs) which may be ignored.
> >
> > Hope this helps,
> > -rajeev-
> > ------------------
> > Laurent Gauch <laurent.gauch@amontec.com> wrote in message news:<3D8825C8.90009@amontec.com>...
> >
> >>Hi all,
> >>
> >>I am designing on XCV600 and I have to use an GCLK input as a standard
> >>input.
> >>
> >>On VCV600 we have 4 IBUFG
> >>My design uses 3 GCLK pins for 3 different clocks, these 3 GCLK pins are
> >>directly connected to 3 IBUFG.
> >>I divide one of my 3 Clocks by two via a Flip-flop (I cannot use DLL
> >>part because I have to produce an ASIC of this design and the customer
> >>don't want specific logic). The result of this division is connected to
> >>a IBUFG too.
> >>Now my problem is to connect and to use my last GCLK pin like a standard
> >>input.
> >>Is There a way to use a GCLK pin without passing through an IBUFG. If
> >>yes, which constraint will do that for me.
> >>
> >
> > <...>
> >

--
--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: 47212
Subject: Re: ieee.math_real for presynthesis table calculation in vhdl
From: Ray Andraka <ray@andraka.com>
Date: Fri, 20 Sep 2002 14:15:06 GMT
Links: << >>  << T >>  << A >>
Me too.   I think 7.1 also supports math_real for constants.  We're still using
7.0.3 because of the funky things 7.1 did to our instantiated carry chains...we
applied the patch for that, but it also sticks in an extra lut because of the
syn_keep we have on the luts to prevent earlier versions of Synplify wrecking the
carry chains.

hamish@cloud.net.au wrote:

> Ray Andraka <ray@andraka.com> wrote:
> > I think synplicity does now too.  My point is I'd like to see it in the LRM so
> > that the code can be made portable between tools.
>
> 7.2.0 seems to accept reals for constants; previous versions didn't,
> unfortunately.
>
> I'm constantly amazed at how badly these tools support data types that
> are only used to generate constants.
>
> 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: 47213
Subject: Re: Multiple divide by 10
From: "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com>
Date: Fri, 20 Sep 2002 14:33:46 GMT
Links: << >>  << T >>  << A >>
I'm not sure about the first statement, since if I had a chip with
custom DSP, custom DPLL, and say, 50-100K gates, and 1
clock, and I was going to sell 10 Million of them, and it only used
1 clock, why would I not make an ASIC?  We shouldn't need to
break out the calculator to make my point.

Also, the design should take into place the transition between
multiple domains, and force synchronization between them.
I suppose if you couldn't use FIFO bucket for data transfer
between two domains, then you'd have big timing concerns,
because depending upon a race condition not occuring would
be just plain old hokey.

BB

======================================================

> Anything complicated enough to make an ASIC out of would tend to have
> multiple clock domains, etc. It would tend to be synchronous within each
> domain, but if "timing closure is nearly automatic" were true then why
> do we at Tality get paid piles of dosh to do the layout for so many
> designs?
>




Article: 47214
Subject: Re: Question on Spartan2E maximum toggle frequency
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 20 Sep 2002 14:41:18 GMT
Links: << >>  << T >>  << A >>


Theron Hicks wrote:

> Hi,
>     I am looking at the specifications for the spartan2e in a dash 7 speed
> grade part.  The spec sheet says maximum toggle frequency (for export
> control) is 400MHz.  What is the intent of the "for export control"
> statement.  Is that a US government requirement

Yes. There used to be (are?) restrictions on exporting very sophisticated ICs
to certain countries. And the government agency in charge used the max
frequency as a criterion. Since FPGA speed is a bit difficult to classify, we
added this parameter.

Peter Alfke


Article: 47215
Subject: Re: Xilinx ISE5.1 and Windows NT
From: hamish@cloud.net.au
Date: 20 Sep 2002 14:44:58 GMT
Links: << >>  << T >>  << A >>
Kamal Patel <kamal.patel@xilinx.com> wrote:
> This is correct.  Windows XP and Windows 2000 will
> be the only supported Microsoft operating systems
> for 5.1i, although 5.1i should still install and
> run fine on Windows NT.

Is this the simple solution to some of the bugs in 4.2i ? :-|

I've found 4.2i to be significantly more stable on Windows 2000 (SP2)
than Windows NT (SP6a).

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 47216
Subject: Functional VHDL Simulation Problem with Xilinx Coregen Async FIFOs
From: Alan Raphael <alraphael@yahoo.com>
Date: Fri, 20 Sep 2002 11:03:30 -0400
Links: << >>  << T >>  << A >>
I have been having a problem for a long time now when I try to functionally 
simulate a VHDL design of a Xilinx Virtex II FPGA which uses several asynchronous 
FIFOs generated via the Coregen tool.  I use Modelsim 5.6d but had similar problems 
with 5.5 as well.  When the simulation tries to read all the data from one of the 
asynchronous FIFOs, the empty flag is not asserted and it is not possible to read 
the last word in the FIFO.  This problem does not show up in the post-routed 
gate-level simulation.  We sort of got around the problem by compiling the verilog 
Coregen async FIFOs with the +delay_mode_zero (an option not available in VHDL) and 
the empty flag works, although other parts of the FIFO look broken.  The write 
clock is 125 MHz and the read clock is 33 MHz (again, this is a functional 
simulation with no delays).

Has anyone seen a problem like this or can they suggest some obscure mode of 
Modelsim that might need to be invoked to cure the problem?  I have submitted a web 
case to Xilinx on this issue, but so far they can't reproduce my problem even 
though I've seen it on several different installations of Modelsim and the Xilinx 
libraries.


Article: 47217
Subject: Re: Modelsim XE question
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 20 Sep 2002 08:17:30 -0700
Links: << >>  << T >>  << A >>
tony wrote:
> Duane:
> 
> Thanks for your reply.
> 
> 
>>In any case, wherever you have the Xilinx software installed, there 
>>should be a library xilinx\vhdl\src\unisims that contains the correct 
>>libraries to use for your simultation.
> 
> 
> I checked and the libraries are there. But they are in a VHDL directory
> and I am trying to use verilog.

Similarly, there is a xilinx\verilog\src\unisims directory. I don't use 
verilog, so I don't know how to use them.

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


Article: 47218
Subject: Xilinx logiCore PCIX controller issues w/ Virtex2
From: "Brannon King" <bking@starbridgesystems.com>
Date: Fri, 20 Sep 2002 09:46:52 -0600
Links: << >>  << T >>  << A >>
I've been working with Xilinx's PCIX core (5.0) on a Virtex2 for a few weeks
now. Maybe some of you have seen the following issues and could post a
comment.

The biggest issue is that only one in twenty of my builds are even
consistently detected by the BIOS.

I only use the *_x stuff (with the 100MHz settings). My motherboard (Tyan
S2720) only sees the board in the 66MHz slots when I put the bus speed on
Auto on the BIOS. It only sees it in the high speed slots when I put the bus
speed at 100MHz in the BIOS.

Several things I had to do to get the thing to ever be seen: There is a lose
plug in the userapp.vhd (FPGA_RTR) that I had to tie down to keep it from
showing up on a clock pin or other random places. Second, I had to make all
my select/when statements in the userapp.vhd anally mutually exclusive.
Third, I had to use standard OBUFs on the pads running to programming pins
on other chips and OFDDRTCPE/IFDDRCPE on the data pins to the other chips.
If I change the standard OBUFs to OFDX to be consistent with the DDRs, the
whole thing fails to be recognized by the BIOS. Same problem if I change my
DDRs to IOBUFs.

So here's the questions:
What the heck do the buffer types in the userapp.vhd have to do with the PCI
controller being recognized by the BIOS?

Do I need to put any IOBDELAY on the PCI registers or the buffers that carry
the data from the registers to the other chips? Or is there some other
net/inst attribute I should use?

When I include the userapp.vhd data pads in the timing spec, it only routes
at 60MHz. Is this causing a problem? I don't seem to have trouble with the
data at 100MHz, but of course I don't send data through every clock cycle
either.

Is there something I need to do with data ins/outs in the controller on
reboot that I'm not doing and, hence, causing some good builds and some bad
builds? I understand there is a bit of randomness in the PAR, but there's
definately something wrong with having to run that until I find a working
build.

Does OFDX with a tied high CE work significantly different from OBUF?

Sorry for the long post. Maybe this can help somebody else.



Article: 47219
Subject: Re: XCV600 Version and Firmware
From: Ryan Laity <ryan.laity@xilinx.com>
Date: Fri, 20 Sep 2002 10:02:45 -0600
Links: << >>  << T >>  << A >>
Hi John,
   In addition to the datasheet that Ray pointed you to, you may also 
want to check out: 
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=1067 

Solution 2 has the information that you'll need to check to see if the 
parts themselves are the same silicon revision.  As for firmware, these 
are completely programmable chips so they could have any design in the 
world in them.  There isn't an easy way to tell whether or not they're 
the same design either.  For that, you'll have to check with the 
manufacturer and/or designer of the boards.

Best regards,
Ryan

John wrote:
> I'm having difficulty finding information on XCV600's on the Xilinx site.  Part of the problem is I know nothing about this type of part, including terminology.  I have two boards with this part, but do not know how to check if they are the same revision, whether the firmware (?) is the same, or where to get the firmware, if it is compatible.  Any constructive suggestions would be appreciated.


Article: 47220
Subject: Re: Apex unused pins voluntarily assigned by Quartus?
From: Christoph Fritsch <christoph_fritsch@gmx.de>
Date: Fri, 20 Sep 2002 18:31:22 +0200
Links: << >>  << T >>  << A >>
Hi Mikhail,

please read carefully through the pin-file you get from Quartus.
It says:

 -- GND+   : Unused input. This pin should be connected to GND. It may
also
 --          be connected  to a  valid signal  on the board  (low, high,
or
 --          toggling)  if that signal is required for a different
revision
 --          of the design.
 -- GND*     : Unused  I/O  pin.   This pin can either be left
unconnected or
 --          connected to GND.  Connecting this pin to GND will improve
the
 --          device's immunity to noise.

This should answer the question on "what it means"

To resever the FAST pins as input's (beeing tri-stated) go into the
compiler settings dialog -> chips&devices -> assign pins. 
Select the pin and use a name you like (dummy1...3) and select "reseve
pin even if it does not exist in the design"

HTH
Christoph

--

Mikhail Matusov schrieb:
> 
> Thanks for your quick reply, Rene!
> 
> However, pins marked with GND+ are not configuration pins in my case. They
> are either dedicated Fast I/O or clock related pins. The one that bothers me
> the most is actually a Fast I/O. I have a customer who has this pin
> connected to something on his board and the board doesn't work. So, I need
> to know whether I am driving it by any chance... The design is proven to
> work on our own card and on other customer's card, so I know it should
> work...
> 
> /Mikhail
> 
> "Rene Tschaggelar" <tschaggelar@dplanet.ch> wrote in message
> news:3D8A1D3E.9010404@dplanet.ch...
> > I had a discussion about exactly that subject today.
> >  From MaxPlus2 :
> > ^ means dedicated pin
> > + means reserved configuration pin, which is tristated
> >    during user mode
> > * means reserved configuration pin, which drives out in
> >    user mode
> >
> > I guess it means you have to connect them to GND.
> >
> > Rene
> > --
> > Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> > & commercial newsgroups - http://www.talkto.net
> >
> > Mikhail Matusov wrote:
> > > Hi all,
> > >
> > > I am looking into a report file generated by Quartus for an Apex design
> and
> > > I see several unused in the design pins to be called GND+ and GND*. I
> asked
> > > the tools to tri-state all the unused pins and it worked for 95% of them
> but
> > > there are these 7 pins assigned to GND+ and 2 to GND*. Three of them are
> > > dedicated Fast pins, the forth Fast pin is actually used in the design.
> > > Others are dedicated clock pins such as CLK4p, CLKLK_FB1p, etc. So, does
> > > anyone know why this is happening and what the hell GND+ and GND* is
> > > supposed to mean? I can't find this explained anywhere...
> >

Article: 47221
Subject: Re: Apex unused pins voluntarily assigned by Quartus?
From: "jakab tanko" <jtanko@ics-ltd.com>
Date: Fri, 20 Sep 2002 12:50:24 -0400
Links: << >>  << T >>  << A >>
Hello,

If you have a large number of simultaneously switching IOs
it is a good practice to connect the unused IO pins to GND,
it helps reduce "ground bounce"; Still, that should be left to the
designer to decide not the par software....right??

jakab

Rene Tschaggelar <tschaggelar@dplanet.ch> wrote in message
news:3D8A1D3E.9010404@dplanet.ch...
> I had a discussion about exactly that subject today.
>  From MaxPlus2 :
> ^ means dedicated pin
> + means reserved configuration pin, which is tristated
>    during user mode
> * means reserved configuration pin, which drives out in
>    user mode
>
> I guess it means you have to connect them to GND.
>
> Rene
> --
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> & commercial newsgroups - http://www.talkto.net
>
> Mikhail Matusov wrote:
> > Hi all,
> >
> > I am looking into a report file generated by Quartus for an Apex design
and
> > I see several unused in the design pins to be called GND+ and GND*. I
asked
> > the tools to tri-state all the unused pins and it worked for 95% of them
but
> > there are these 7 pins assigned to GND+ and 2 to GND*. Three of them are
> > dedicated Fast pins, the forth Fast pin is actually used in the design.
> > Others are dedicated clock pins such as CLK4p, CLKLK_FB1p, etc. So, does
> > anyone know why this is happening and what the hell GND+ and GND* is
> > supposed to mean? I can't find this explained anywhere...
>



Article: 47222
Subject: Re: Overheat with XCV-600E
From: Farhad Abdolian <farhad_abdolian@removethis_first_hotmail.com>
Date: Fri, 20 Sep 2002 16:54:21 GMT
Links: << >>  << T >>  << A >>
Can you give more informaiton of the package type and how all the "not used"
pins are connected. Looking into your mapping file, and compare the old one with
the new one can help, even though it may not be the answer, but it is worth
looking into.

Would like to know when you find the answer,
/Farhad
pierrotlafouine@hotmail.com (Pierre Lafrance) wrote:

>Hi all
>I respined a product, changing the old Xilinx XV-300 with a XCV-600E.
>Of course, I had to change voltage regulator from 2.5 to 1.8 volts,
>and few 5 volts CPLD to 3.3v.
>
>The problem is : the XCV-600E overheat, and 1 of the prototype just
>died.
>I tried to find any hardware signal that would exceed voltage but
>couldn't.  Hardware seems to be just fine.  I suspect the chips itself
>to overheat.  I just put a heatseak temporarly, but would like to
>solve the problem if I can.
>
>Simulation with XPower estimate the chips temperature to be 50C, but I
>measure up to 65C.
>
>The disign use 75% of BRAM, and 75% of FF of the XCV-600E.
>Clock is 82MHz.
>
>Anybody experienced overheat with 600E ?
>
>Cheers !
>
>Pierre


Article: 47223
Subject: Re: Functional VHDL Simulation Problem with Xilinx Coregen Async FIFOs with Modelsim
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 20 Sep 2002 10:17:31 -0700
Links: << >>  << T >>  << A >>
Alan Raphael wrote:

> We sort of got around the problem by compiling 
> the verilog Coregen async FIFOs with the +delay_mode_zero (an option not 
> available in VHDL) and the empty flag works, although other parts of the 
> FIFO look broken.  The write clock is 125 MHz and the read clock is 33 
> MHz (again, this is a functional simulation with no delays).


Sounds more like a logic race than a modelsim problem.
Consider synchronizing the 33 Mhz controls to 125 Mhz
and use a synchronous fifo.

  -- Mike Treseler


Article: 47224
Subject: Re: Xilinx ISE5.1 and Windows NT
From: emanuel stiebler <emu@ecubics.com>
Date: Fri, 20 Sep 2002 11:28:22 -0600
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> Speaking of MS, anyone know what little tricks they are using to get
> companies to switch from 98, ME, NT and 2000 to XP? 

Bike chains ?
;-)

>  I just can't belive
> they are going to sit by and let everyone keep using the old OS with
> licences that can't be well enforced.
> 
They are probalbly sitting there, while we walk to linux ;-)
As soon, as xilinx ports all the stuff as native applications ...

cheers



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