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 35550

Article: 35550
Subject: Re: CoreGenerator and WebPack ISE
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Wed, 10 Oct 2001 17:36:48 +0200
Links: << >>  << T >>  << A >>
WebPack Projects are not accepted by CoreGen.
Maybe I miss something.
Anyway... I hope to get Foundation ISE 4.1 soon

THX
-Manfred



Article: 35551
(removed)


Article: 35552
Subject: 155MHz to a DLL in Spartan II
From: "Ulises Hernandez" <ulisesh@ecs-telecom.removeplease.co.uk.invalid>
Date: Wed, 10 Oct 2001 17:02:31 +0100
Links: << >>  << T >>  << A >>
Hello,

I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which I
can use, I have to count an external recovered clock of 155MHz in a 32 bit
counter and set the result in a register and when software requires the
value can read it.

I would like to connect the 155 MHz clock to an IBUFG and then to a DLL
(CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which I
can read with my 33.33 MHz clock.
The other possibility is avoiding this "high" frequency using an external
divider by 4 i.e. and get a 38.75 clock to a DLL (CLKDLL) and divide by 2
i.e.

Any suggestions? In the Spartan II Datasheets the maximum frequency for a
CLKDLLHF is 180 MHz. Is it too close? My previous experience with Spartan II
DLL is quite good so I trust it, but I would like if someone could give some
idea.

Thank you in advance.

Ulises Hernandez
ECS Technology






Article: 35553
Subject: Re: Virtex-2 maximum clock speed
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 10 Oct 2001 09:05:26 -0700
Links: << >>  << T >>  << A >>

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

Himanshu,

I agree that data sheets don't answer the question so ----

Virtex II circuits support clocks running at 420 MHz on the global buffers.

That does not mean that you can make the entire design run that fast, but
small selected portions can certainly operate that fast.

Two techniques used commonly with the Virtex II are the use of the DCM to
provide clock multiplication, so the external clock is lower than the
internal clock, and the use of the duty cycle correction features (DCM
outputs CLK0 and CLK180 are duty cycle corrected if selectted, and CLKFX and
CLKFX180 are always duty cycle corrected) allow for Double Data Rate (DDR)
internal design techniques, doubling the work per clock cycle (using both
edges of the clock).

Thus selected portions of the chip may process information at 840 Mb/s.

Typical larger designs are running in the ~300 MHz range without too much
effort, as compared to ~ 180 MHz for Virtex E, and ~ 100 MHz for Virtex.

(Typical driver, typical course, no special instructions required:  your
results may vary with effort and expertise!)

Getting the data in and out is the next problem after the internal
processing, and the LVDS IO allows for data buses of ~16 bits running at
~700 Mb/s DDR rates, and the 840 Mb/s rates with some careful placement.

One major warning is that this is now a microwave world!  Signal integrity
at these frequencies is serious business, and I warn all developers to make
a concerted effort to get smart fast by reading Howard Johnson's book on
signal integrity, taking a class, and then simulating and learning.  These
classes and books are the best we have, but remember, they are teaching, and
they have not been designing with 400 MHz clocks, as we are now, so some of
their information is out of date, obsolete, and just plain wrong -- but most
is very useful!

As well, the quality of results from the software has been steadily
improving, with the latest clock speeds getting easier to implement as the
tools get better.  4.1i has set a new performance watermark, and re-running
old Virtex E designs has led to significant performance (>10%, or a speed
grade) improvements for some customers.

Again, it all depends on your design, and how it is architected, but Virtex
II has been very well accepted, and I continually hear from customers how
"Virtex II now makes life interesting as it competes with the ASICs I was
planning on having to design."

Austin

Speedy Zero Two wrote:

> Do they not provide that in the datasheet?
>
> "himanshu" <himan_2000@indiatimes.com> wrote in message
> news:adf7cebe.0110080015.832fe8d@posting.google.com...
> > Hi,
> >   can any body tell me what is the maximum clock speed at which xilinx
> > virtex-2 fpga can work?? It has got 8 DLLs..what is the maximum clock
> > rate they can provide. do i have to divide that frequency for clock
> > stability?
> > Thanks in advance
> > Himanshu

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Himanshu,
<p>I agree that data sheets don't answer the question so ----
<p>Virtex II circuits support clocks running at 420 MHz on the global buffers.
<p>That does not mean that you can make the entire design run that fast,
but small selected portions can certainly operate that fast.
<p>Two techniques used commonly with the Virtex II are the use of the DCM
to provide clock multiplication, so the external clock is lower than the
internal clock, and the use of the duty cycle correction features (DCM
outputs CLK0 and CLK180 are duty cycle corrected if selectted, and CLKFX
and CLKFX180 are always duty cycle corrected) allow for Double Data Rate
(DDR) internal design techniques, doubling the work per clock cycle (using
both edges of the clock).
<p>Thus selected portions of the chip may process information at 840 Mb/s.
<p>Typical larger designs are running in the ~300 MHz range without too
much effort, as compared to ~ 180 MHz for Virtex E, and ~ 100 MHz for Virtex.
<p>(Typical driver, typical course, no special instructions required:&nbsp;
your results may vary with effort and expertise!)
<p>Getting the data in and out is the next problem after the internal processing,
and the LVDS IO allows for data buses of ~16 bits running at ~700 Mb/s
DDR rates, and the 840 Mb/s rates with some careful placement.
<p>One major warning is that this is now a <b>microwave world!</b>&nbsp;
Signal integrity at these frequencies is serious business, and I warn all
developers to make a concerted effort to get smart fast by reading Howard
Johnson's book on signal integrity, taking a class, and then simulating
and learning.&nbsp; These classes and books are the best we have, but remember,
they are teaching, and they have not been designing with 400 MHz clocks,
as we are now, so some of their information is out of date, obsolete, and
just plain wrong -- but most is very useful!
<p>As well, the quality of results from the software has been steadily
improving, with the latest clock speeds getting easier to implement as
the tools get better.&nbsp; 4.1i has set a new performance watermark, and
re-running old Virtex E designs has led to significant performance (>10%,
or a speed grade) improvements for some customers.
<p>Again, it all depends on your design, and how it is architected, but
Virtex II has been very well accepted, and I continually hear from customers
how "Virtex II now makes life interesting as it competes with the ASICs
I was planning on having to design."
<p>Austin
<p>Speedy Zero Two wrote:
<blockquote TYPE=CITE>Do they not provide that in the datasheet?
<p>"himanshu" &lt;himan_2000@indiatimes.com> wrote in message
<br><a href="news:adf7cebe.0110080015.832fe8d@posting.google.com">news:adf7cebe.0110080015.832fe8d@posting.google.com</a>...
<br>> Hi,
<br>>&nbsp;&nbsp; can any body tell me what is the maximum clock speed
at which xilinx
<br>> virtex-2 fpga can work?? It has got 8 DLLs..what is the maximum clock
<br>> rate they can provide. do i have to divide that frequency for clock
<br>> stability?
<br>> Thanks in advance
<br>> Himanshu</blockquote>
</html>

--------------A34FA2E82DD47EF2394C7588--


Article: 35554
Subject: Re: Linking components in VHDL
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 10 Oct 2001 09:21:04 -0700
Links: << >>  << T >>  << A >>
Andrew Gray wrote:

> When I compile the project Maxplus generates the error:
> Warning: Ignored unneccessary INPUT pin 'Data_Train'
> 

Sounds like there is a missing signal 
declaration and/or assignment.
Post your code.

Consider using simulation before synthesis.

    --Mike Treseler

Article: 35555
Subject: Re: qpsk clock recovery
From: "Bhaskar Thiagarajan" <bhaskart@my-deja.com>
Date: Wed, 10 Oct 2001 09:28:24 -0700
Links: << >>  << T >>  << A >>
Clock recovery is a very important part of receivers and is discussed pretty
much in every communications text. There are various methods to perform this
function, but some of the common methods are well described (Ray just
described one using PLLs).
If you want to perform this block in real time at that kind of data
rates...FPGAs/ASICs are your only choice. But if you can store a large
amount of data and post process this, you can probably do this on a DSP.
Search for key words like clock recovery, Costas Loop, etc. I doubt if you
will find detailed examples of implementation other than descriptions on how
this is typically done.
--
Cheers
Bhaskar
Note: I do *not* check the listed email address.

"eas" <eas@bi.net.tr> wrote in message
news:99802a4d.0110100621.43365016@posting.google.com...
> Dear All,
>  I have obtained the  I and Q signals using a qpsk demodulator IC.
> What I need is to derive the clock from the I Q data. This must be a
> simple task, but could not find any examples. The data rate is
> >10Mbps. What kind of DSP-FPGA combination is needed? Are there any
> DSP or VHDL sources?
>
> Thanks



Article: 35556
Subject: Re: FPGA reset
From: tom_systek@msn.com (Tom Seim)
Date: 10 Oct 2001 09:46:15 -0700
Links: << >>  << T >>  << A >>
Peter,

I think I talked to you when we were having the problem about 10 years
ago. All of our designs have a reset controller anyhow, so this was a
mod with only moderate pain (figuring it out, however, is a different
level of pain). I drive the DONE pin with the reset controller thru a
Shottky diode. This, in turn, is the reset input to the rest of the
logic/processor, guaranteeing that the FPGA is configured before the
processor starts running.

Tom

Peter Alfke <palfke@earthlink.net> wrote in message news:<3BC3AC3C.3007C379@earthlink.net>...
> Did you make the recommended connection: INIT driving the SPROM Reset ?
> Xilinx has promoted this as the only reasonable and safe method for at least the past eight years, way
> back in the XC3000 data sheet.  ( I remember, I was the one putting it in, and even explaining the reason
> 
> why ). Without that connection you can encounter all sorts of grief...
> With this connection, you would only have a problem if the power-on reset is longer in the SPROM than it
> is in the FPGA. To the best of my knowledge, that has been the case only in certain Atmel SPROMs.
> But I am listening...One never stops learning.
> 
> Peter Alfke, Xilinx Applications
> ===============================
> 
> Tom Seim wrote:
> 
> > My greatest grief with Xilinx (right after the blunder Xilinx made
> > switching suppliers of the serial proms - the new supplier couldn't
> > deliver as scheduled and the old one had been axed) has been the
> > power-up sequencing. The FPGAs and serial proms have internal power-up
> > sequencing circuitry so you think: "I'm ok using that". Wrong.
> > I have seen the serial prom & FPGA get out of sync due to either too
> > fast/slow Vcc rise time and/or a small spike on Vcc at the wrong
> > moment. The serial prom's address counter will keep going & eventually
> > recycle, but this takes forever! I've ALWAYS used a seperate power
> > reset circuit after that.
> >
> > "Austin Franklin" <austin@darkroom88.com> wrote in message news:<ts62seat66qg87@corp.supernews.com>...
> > > Just a note on using GSR-not using GSR with synthesis.  GSR routing is free,
> > > it is dedicated copper...and can be used for nothing else.  If you do NOT
> > > use GSR, and have a reset in your design (as you probably should) you are
> > > using regular routing resources for this possibly very prolific global net.
> > > In order for synthesis to use GSR (at least Synplicity) EVERY flop must be
> > > attached to GSR, or it will use regular routing resources.
> > >
> > > Why are using regular routing resources bad?  If your design is quite full,
> > > it can significantly impact timing and tool run time.  One design I had in
> > > an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR.
> > >
> > > As Philip's post suggests (hell, says), it is VERY easy to still use the GSR
> > > and design such that this does not create any problems with your design.  It
> > > just takes a little understanding of how your design works, and a bit of
> > > engineering.
> > >
> > > "jas" <jasjasjasjas@hotmail.com> wrote in message
> > > news:fe3da0d7.0110082249.42642566@posting.google.com...
> > > > Hi,
> > > >
> > > > Are there timing issues on a Spartan device if the reset is
> > > > asynchronous to the system clock, i.e could a problem occur where by
> > > > the device is taken out of reset on the active clock edge, hence
> > > > certain registers in the device remain in reset and the others are
> > > > not. If so how is this solved, by registering the reset and not
> > > > reseting that register?.
> > > >
> > > > Thanks
> > > >
> > > > jon

Article: 35557
Subject: Re: Synplicity/Leonardo License Agreement Information
From: tom_systek@msn.com (Tom Seim)
Date: 10 Oct 2001 09:51:37 -0700
Links: << >>  << T >>  << A >>
Maybe we can make the lawyers do logic design & we can dream up
contracts to make their collective lives miserable.

"Austin Franklin" <austin@dar87kroom.com> wrote in message news:<ts7f3mcvi2r3e5@corp.supernews.com>...
> I know this is "controversial" but this kind of crap just really "irks"
> me...
> 
> > I have been advised that the sharing of benchmark data concerning at
> > least one of these two products is a violation of the license agreement of
> > that product, and this may be true of the other product.
> 
> I am curious who "advised" you?
> 
> I'm also curious as to the actual enforceable legality of such an inclusion
> into the license agreement.  An agreement can contain anything it wants
> (they can even ask you to agree to not pick your nose while using their
> tools), but whether it's legally enforceable is another matter entirely.
> 
> This is my take on it...and is only my opinion.  If this purported violation
> even has any legal grounds...  It's certainly not a criminal activity...and
> not being such, it has to fall into civil litigation.  In civil cases, you
> have to prove damages...and as far as I know, stating something that is
> factually true, unless done maliciously, does not give grounds for damages.
> 
> Can you imagine a company suing someone because they published a benchmark
> that showed that their product actually sucked?
> 
> Anyone know anything about this...aside from that it's childish to even put
> such a clause in a license agreement in the first place...
> 
> Imagine buying a car (or a pencil for that matter) that came with a "license
> agreement" that you could not "share" the comparison of your car (or pencil)
> with any other car...think about how, well, just plain silly (and pathetic)
> that is.

Article: 35558
Subject: Re: Virtex-2 maximum clock speed
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 10 Oct 2001 19:07:43 +0200
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:
> 
> Himanshu,
> 
> I agree that data sheets don't answer the question so ----
> 
> Virtex II circuits support clocks running at 420 MHz on the global
> buffers.
> 
> That does not mean that you can make the entire design run that fast,
> but small selected portions can certainly operate that fast.

Hmm, but If I have a design, heavy pipelined, well floorplanned (its
getting theoretical ;-), just 2 LUT levels between FFs, can this run
@400 MHz? Or even 500, when just 1 LUT is used between FFs?
 
> Two techniques used commonly with the Virtex II are the use of the DCM
> to provide clock multiplication, so the external clock is lower than
> the internal clock, and the use of the duty cycle correction features
> (DCM outputs CLK0 and CLK180 are duty cycle corrected if selectted,
> and CLKFX and CLKFX180 are always duty cycle corrected) allow for
> Double Data Rate (DDR) internal design techniques, doubling the work
> per clock cycle (using both edges of the clock).

Hmm, very good point. Does anybody here has informationas about DDR
basics, design and common pitfalls (and how to avoid them).
Also DDR Xmission on board level?

> 
> Thus selected portions of the chip may process information at 840
> Mb/s.

No problem with a 64 bit bus inside, its just 13 MHz ;-)
 
 
> One major warning is that this is now a microwave world!  Signal
> integrity at these frequencies is serious business, and I warn all
> developers to make a concerted effort to get smart fast by reading
> Howard Johnson's book on signal integrity, taking a class, and then
> simulating and learning.  These classes and books are the best we
> have, but remember, they are teaching, and they have not been
> designing with 400 MHz clocks, as we are now, so some of their
> information is out of date, obsolete, and just plain wrong -- but most
> is very useful!

Hmm, I got the Johnson & Graham Book, VERY nice stuff ;-) But how about
an new issue, updated with todays devices (and their problems) ??
 
> As well, the quality of results from the software has been steadily
> improving, with the latest clock speeds getting easier to implement as
> the tools get better.  4.1i has set a new performance watermark, and
> re-running old Virtex E designs has led to significant performance
> (>10%, or a speed grade) improvements for some customers.

Hmm but this is getting into the marketing stuff . . . .;-)
Even the new software cant beat an engineer with real understanding of
the FPGA structures, and much worse it cant fix the problems caused by
an really unexpierienced designer.
Or am I wrong?

> Again, it all depends on your design, and how it is architected, but
> Virtex II has been very well accepted, and I continually hear from
> customers how "Virtex II now makes life interesting as it competes
> with the ASICs I was planning on having to design."

He did it AGAIN. Marketing alert ;-)

Serious, I can believe that the Virtex-II is a very nice device
althrough up to now I had no possibility to use one for a design :-(

-- 
MFG
Falk



Article: 35559
Subject: Re: 155MHz to DLL in Spartan II
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 10 Oct 2001 19:19:25 +0200
Links: << >>  << T >>  << A >>
Ulises Hernandez schrieb:
> 
> Hello,
> 
> I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which I
> can use, I have to count an external recovered clock of 155MHz in a 32 bit
> counter and set the result in a register and when software requires the
> value can read it.
> 
> I would like to connect the 155 MHz clock to an IBUFG and then to a DLL
> (CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which I
> can read with my 33.33 MHz clock.

Why do you want to divide it down? As far as I can see, you want some
kind of frequncy counter?
Ok, a 32 bit counter on 155 MHz cant be directly created in a Spatan-II,
you have to use some kind of pipelining/carry bit registering.
But the 155 Mhz inside the Spartan-II for such a simple task is
Non-critical to me. Just use a global clock buffer to avoid pitfalls.

-- 
MFG
Falk


Article: 35560
Subject: Re: 155MHz to DLL in Spartan II
From: Kolja Sulimma <kolja@sulimma.de>
Date: Wed, 10 Oct 2001 19:36:37 +0200
Links: << >>  << T >>  << A >>


Falk Brunner wrote:

> Ulises Hernandez schrieb:
> >
> > Hello,
> >
> > I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which I
> > can use, I have to count an external recovered clock of 155MHz in a 32 bit
> > counter and set the result in a register and when software requires the
> > value can read it.
> >
> > I would like to connect the 155 MHz clock to an IBUFG and then to a DLL
> > (CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which I
> > can read with my 33.33 MHz clock.
>
> Why do you want to divide it down? As far as I can see, you want some
> kind of frequncy counter?
> Ok, a 32 bit counter on 155 MHz cant be directly created in a Spatan-II,
> you have to use some kind of pipelining/carry bit registering.
> But the 155 Mhz inside the Spartan-II for such a simple task is
> Non-critical to me. Just use a global clock buffer to avoid pitfalls.

As I understand it, the problem is how to interface values that are computed using
the 155 MHz Clock to logic running at the PCI Clock that is
asynchronous to the fast clock.
There are some metastability wizards in this newsgroup that propably can better
explain the possible solutions than I can.

Kolja Sulimma



Article: 35561
Subject: Re: FPGA reset
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 10 Oct 2001 11:46:40 -0700
Links: << >>  << T >>  << A >>
You are now describing something different, and it seems to work well.
I was addressing your original complaint about SPROM and FPGA getting out of sync with respect to each other.
That should never occur if INIT resets the SPROM.

Peter Alfke, Xilinx Applications
===============================
Tom Seim wrote:

> Peter,
>
> I think I talked to you when we were having the problem about 10 years
> ago. All of our designs have a reset controller anyhow, so this was a
> mod with only moderate pain (figuring it out, however, is a different
> level of pain). I drive the DONE pin with the reset controller thru a
> Shottky diode. This, in turn, is the reset input to the rest of the
> logic/processor, guaranteeing that the FPGA is configured before the
> processor starts running.
>
> Tom
>
> Peter Alfke <palfke@earthlink.net> wrote in message news:<3BC3AC3C.3007C379@earthlink.net>...
> > Did you make the recommended connection: INIT driving the SPROM Reset ?
> > Xilinx has promoted this as the only reasonable and safe method for at least the past eight years, way
> > back in the XC3000 data sheet.  ( I remember, I was the one putting it in, and even explaining the reason
> >
> > why ). Without that connection you can encounter all sorts of grief...
> > With this connection, you would only have a problem if the power-on reset is longer in the SPROM than it
> > is in the FPGA. To the best of my knowledge, that has been the case only in certain Atmel SPROMs.
> > But I am listening...One never stops learning.
> >
> > Peter Alfke, Xilinx Applications
> > ===============================
> >
> > Tom Seim wrote:
> >
> > > My greatest grief with Xilinx (right after the blunder Xilinx made
> > > switching suppliers of the serial proms - the new supplier couldn't
> > > deliver as scheduled and the old one had been axed) has been the
> > > power-up sequencing. The FPGAs and serial proms have internal power-up
> > > sequencing circuitry so you think: "I'm ok using that". Wrong.
> > > I have seen the serial prom & FPGA get out of sync due to either too
> > > fast/slow Vcc rise time and/or a small spike on Vcc at the wrong
> > > moment. The serial prom's address counter will keep going & eventually
> > > recycle, but this takes forever! I've ALWAYS used a seperate power
> > > reset circuit after that.
> > >
> > > "Austin Franklin" <austin@darkroom88.com> wrote in message news:<ts62seat66qg87@corp.supernews.com>...
> > > > Just a note on using GSR-not using GSR with synthesis.  GSR routing is free,
> > > > it is dedicated copper...and can be used for nothing else.  If you do NOT
> > > > use GSR, and have a reset in your design (as you probably should) you are
> > > > using regular routing resources for this possibly very prolific global net.
> > > > In order for synthesis to use GSR (at least Synplicity) EVERY flop must be
> > > > attached to GSR, or it will use regular routing resources.
> > > >
> > > > Why are using regular routing resources bad?  If your design is quite full,
> > > > it can significantly impact timing and tool run time.  One design I had in
> > > > an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR.
> > > >
> > > > As Philip's post suggests (hell, says), it is VERY easy to still use the GSR
> > > > and design such that this does not create any problems with your design.  It
> > > > just takes a little understanding of how your design works, and a bit of
> > > > engineering.
> > > >
> > > > "jas" <jasjasjasjas@hotmail.com> wrote in message
> > > > news:fe3da0d7.0110082249.42642566@posting.google.com...
> > > > > Hi,
> > > > >
> > > > > Are there timing issues on a Spartan device if the reset is
> > > > > asynchronous to the system clock, i.e could a problem occur where by
> > > > > the device is taken out of reset on the active clock edge, hence
> > > > > certain registers in the device remain in reset and the others are
> > > > > not. If so how is this solved, by registering the reset and not
> > > > > reseting that register?.
> > > > >
> > > > > Thanks
> > > > >
> > > > > jon


Article: 35562
Subject: Re: 155MHz to DLL in Spartan II
From: Ray Andraka <ray@andraka.com>
Date: Wed, 10 Oct 2001 19:13:53 GMT
Links: << >>  << T >>  << A >>
The Spartan II DLL will indeed run at 155MHz, although you may find you are
better off supplying a 1/2x clock externally and doubling it with the PLL.  You
may have trouble getting a 155MHz board level clock into the chip cleanly.

Once inside, I am assuming you are dealing with a 155 mbit serial stream which
you need to somehow capture and reliably sync to your PCI clock at 33.33 MHz.
Use a shift register clocked at the 155 Mbits to turn that into a 16 bit
parallel word, copying it to a parallel register every 16th cycle of the 155 MHz
clock.  Toggle a T flip-flop at the same time you load the register, synchronize
that toggle signal to the 33 mHz domain, then with a state machine running at
33MHz, use the edges of the synchronized toggle signal to enable a transfer of
data from the holding register in the 155 to a second register in the 33 mHz
domain.  You may need a pipeline register in the data path to make sure the data
is stable around the 33 MHz enable signal.  That enable signal, delayed by 1
clock becomes your data valid out.

Alternatively, you can use a block RAM to do your rate matching.  You won't get
the BRAM to run at 155, but you can write two bits at a time so that it runs at
the 76MHz on the write side.  On the read side, you can pull data out 16 bits at
a time easily on the PCI clock.  YOu'll need some logic to generate your status
flags.  IIRC, the Xilinx async fifos have the same width on both sides of the
fifo so you can't use them directly.  You can however use bit 2 of your write
pointer, synchronize it to the 33 MHz domain to generate a 1 cycle wide pulse
that increments an up down counter to track how many words are in the buffer.

Ulises Hernandez wrote:

> Hello,
>
> I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which I
> can use, I have to count an external recovered clock of 155MHz in a 32 bit
> counter and set the result in a register and when software requires the
> value can read it.
>
> I would like to connect the 155 MHz clock to an IBUFG and then to a DLL
> (CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which I
> can read with my 33.33 MHz clock.
> The other possibility is avoiding this "high" frequency using an external
> divider by 4 i.e. and get a 38.75 clock to a DLL (CLKDLL) and divide by 2
> i.e.
>
> Any suggestions? In the Spartan II Datasheets the maximum frequency for a
> CLKDLLHF is 180 MHz. Is it too close? My previous experience with Spartan II
> DLL is quite good so I trust it, but I would like if someone could give some
> idea.
>
> Thank you in advance.
>
> Ulises Hernandez
> ECS Technology

--
--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: 35563
Subject: Re: Virtex-2 maximum clock speed
From: Ray Andraka <ray@andraka.com>
Date: Wed, 10 Oct 2001 19:22:15 GMT
Links: << >>  << T >>  << A >>
That 10% is definitely a marketing number.  4.1 does that, and perhaps even
a little more for a design that is, well... average (perhaps mediocre would
be a better word).  For well executed, floorplanned designs, it seems to not
do quite as well as 3.3sp8, although that is a very small sample set at the
moment.  So the initial indication is that perhaps it has improved
placement, but perhaps something got degraded in routing as part of the
compile time vs. results trade.  Overall, the 4.1 seems to be a sizable
improvement for the average user.

Falk Brunner wrote:

> Austin Lesea schrieb:
> >
> > Himanshu,
> >
> > I agree that data sheets don't answer the question so ----
> >
> > Virtex II circuits support clocks running at 420 MHz on the global
> > buffers.
> >
> > That does not mean that you can make the entire design run that fast,
> > but small selected portions can certainly operate that fast.
>
> Hmm, but If I have a design, heavy pipelined, well floorplanned (its
> getting theoretical ;-), just 2 LUT levels between FFs, can this run
> @400 MHz? Or even 500, when just 1 LUT is used between FFs?
>
> > Two techniques used commonly with the Virtex II are the use of the DCM
> > to provide clock multiplication, so the external clock is lower than
> > the internal clock, and the use of the duty cycle correction features
> > (DCM outputs CLK0 and CLK180 are duty cycle corrected if selectted,
> > and CLKFX and CLKFX180 are always duty cycle corrected) allow for
> > Double Data Rate (DDR) internal design techniques, doubling the work
> > per clock cycle (using both edges of the clock).
>
> Hmm, very good point. Does anybody here has informationas about DDR
> basics, design and common pitfalls (and how to avoid them).
> Also DDR Xmission on board level?
>
> >
> > Thus selected portions of the chip may process information at 840
> > Mb/s.
>
> No problem with a 64 bit bus inside, its just 13 MHz ;-)
>
>
> > One major warning is that this is now a microwave world!  Signal
> > integrity at these frequencies is serious business, and I warn all
> > developers to make a concerted effort to get smart fast by reading
> > Howard Johnson's book on signal integrity, taking a class, and then
> > simulating and learning.  These classes and books are the best we
> > have, but remember, they are teaching, and they have not been
> > designing with 400 MHz clocks, as we are now, so some of their
> > information is out of date, obsolete, and just plain wrong -- but most
> > is very useful!
>
> Hmm, I got the Johnson & Graham Book, VERY nice stuff ;-) But how about
> an new issue, updated with todays devices (and their problems) ??
>
> > As well, the quality of results from the software has been steadily
> > improving, with the latest clock speeds getting easier to implement as
> > the tools get better.  4.1i has set a new performance watermark, and
> > re-running old Virtex E designs has led to significant performance
> > (>10%, or a speed grade) improvements for some customers.
>
> Hmm but this is getting into the marketing stuff . . . .;-)
> Even the new software cant beat an engineer with real understanding of
> the FPGA structures, and much worse it cant fix the problems caused by
> an really unexpierienced designer.
> Or am I wrong?
>
> > Again, it all depends on your design, and how it is architected, but
> > Virtex II has been very well accepted, and I continually hear from
> > customers how "Virtex II now makes life interesting as it competes
> > with the ASICs I was planning on having to design."
>
> He did it AGAIN. Marketing alert ;-)
>
> Serious, I can believe that the Virtex-II is a very nice device
> althrough up to now I had no possibility to use one for a design :-(
>
> --
> MFG
> Falk

--
--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: 35564
Subject: Re: 155MHz to DLL in Spartan II
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 10 Oct 2001 21:25:28 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma schrieb:
> 
> > Non-critical to me. Just use a global clock buffer to avoid pitfalls.
> 
> As I understand it, the problem is how to interface values that are computed using
> the 155 MHz Clock to logic running at the PCI Clock that is
> asynchronous to the fast clock.
> There are some metastability wizards in this newsgroup that propably can better
> explain the possible solutions than I can.

This is another thing, but for a frequency counter its not too hard,
even for Non-Metastability Wizzards ;-)

My proposal. Use a counter on the 33 MHz clock to generate a gate pulse
(lets say 1 second).
Drive this gate pulse directly with a FF to the 155 Mhz circuty. Use 1
two or three cascaded FF on the 155 MHz clock to sychronize the gate
pulse to the 155 Mhz clock. Use it thereafter as an clock enable for the
155 MHz counters.
Thats almost all. When the gate pulse on the 33 MHz clock goes low, wait
some more cycles (lets say 10) to be sure the 155 MHz counter is really
stopped. Now read the content of the 155 Mhz counter.

-- 
MFG
Falk


Article: 35565
Subject: Re: Synplify vs. Leonardo
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 10 Oct 2001 20:34:43 +0100
Links: << >>  << T >>  << A >>


"S. Ramirez" wrote:

> Dear Newsgroup Members,
>      I have been advised that the sharing of benchmark data concerning at
> least one of these two products is a violation of the license agreement of
> that product, and this may be true of the other product.
>      Please do not send me any benchmarking data that you may have obtained
> in any manner from these products.
>      Thank you very much.
> Simon Ramirez, Consultant
> Synchronous Design, Inc.
> Oviedo, FL  USA
>
>

That's outrageous and I sympathise. From the way your email's been phrased, the
lawyers for X or Y have told you not even to identify which of the two is
behaving in this appalling fashion so we can ``name & shame''.  Do they share a
law firm with R****S ?

What company apparachiks like this don't realise is that the information will
come out anyway but in a much more damaging fashion.



Article: 35566
Subject: Re: Synplicity/Leonardo License Agreement Information
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 10 Oct 2001 20:42:56 +0100
Links: << >>  << T >>  << A >>


Tom Seim wrote:

> Maybe we can make the lawyers do logic design & we can dream up
> contracts to make their collective lives miserable.
>
>

You would end up with FFs that have to be paid $100's for each toggle.


Article: 35567
Subject: Re: Synplicity/Leonardo License Agreement Information
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 11 Oct 2001 08:50:29 +1300
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> Tom Seim wrote:
> 
> > Maybe we can make the lawyers do logic design & we can dream up
> > contracts to make their collective lives miserable.
> >
> >
> 
> You would end up with FFs that have to be paid $100's for each toggle.

Close, but incorrect :-)

 You would end up with FFs that have to be paid $100's for each side
of the toggle/not toggle argument, but an actual toggle would 
not necessairly result.

-jg

Article: 35568
Subject: Re: Synplicity/Leonardo License Agreement Information
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 10 Oct 2001 21:17:18 +0100
Links: << >>  << T >>  << A >>


Jim Granville wrote:

> Rick Filipkiewicz wrote:
> >
> > Tom Seim wrote:
> >
> > > Maybe we can make the lawyers do logic design & we can dream up
> > > contracts to make their collective lives miserable.
> > >
> > >
> >
> > You would end up with FFs that have to be paid $100's for each toggle.
>
> Close, but incorrect :-)
>
>  You would end up with FFs that have to be paid $100's for each side
> of the toggle/not toggle argument, but an actual toggle would
> not necessairly result.
>
> -jg

Closer :-))

Definition: Metastable - That state in which lawyers tend to remain for as
long as the money holds out.


Article: 35569
Subject: High level synthesis will never work well :)
From: husby_d@yahoo.com (Don Husby)
Date: 10 Oct 2001 13:32:53 -0700
Links: << >>  << T >>  << A >>
More wacky synthesis results from Synplicity:

(Note that this sort of thing isn't specific to
Synplicity.  Leonardo does a lot of wacky things too.
Sadly, Synplicity is probably the better tool.)

You'd think a simple 56-bit counter would be no
problem.  The code below should synthesize to
1 logic level using 56 LUTs, 56 FFs and a carry chain.
Instead, Synplicity adds an extra 57 LUTs and an extra
level of logic.

  module Cnt56(K, CE, R, Out);
    input         K, CE, R;
    output [55:0] Out;
    reg    [55:0] Q;
    assign Out= Q;
    always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
    // if (R)       Q <= 0;    // This doesn't work either
    // else if (CE) Q <= Q+1;
  endmodule

Why?  Instead of running the R signal directly to the
reset pin of the flip flop, Synplicity merges it into
the equations for Q and CE.  So we get:

  module Cnt56(K, CE, R, Out);
    input         K, CE, R;
    output [55:0] Out;
    reg    [55:0] Q;
    assign Out= Q;

    wire [55:0] Q_plus_1 = Q+1;
    wire [55:0] Q_and_R = R ? Q_plus_1 : 0; 
    wire        CE_or_R = CE | R;

    always @(posedge K) if (CE_or_R) Q <= Q_and_R;
  endmodule

Workaround?  I guess I have to instantiate an array of
56 flip flops and connect the signals the correct way.
This is really ugly, and makes my design Xilinx-specific.
If I want to use an Altera chip, I have to re-write the
code.

Which brings me to my point:
  High level, abstract synthesis will never work well.  I realize
this is an extreme statement, but if today's synthesizers can't
do better than a factor of 2 for really simple code, it's
hard to imagine a synthesizer in the near future that can
compile complex code efficiently.

Article: 35570
Subject: Re: High level synthesis will never work well :)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 10 Oct 2001 23:18:08 +0100
Links: << >>  << T >>  << A >>


Don Husby wrote:

> More wacky synthesis results from Synplicity:
>
> (Note that this sort of thing isn't specific to
> Synplicity.  Leonardo does a lot of wacky things too.
> Sadly, Synplicity is probably the better tool.)
>
> You'd think a simple 56-bit counter would be no
> problem.  The code below should synthesize to
> 1 logic level using 56 LUTs, 56 FFs and a carry chain.
> Instead, Synplicity adds an extra 57 LUTs and an extra
> level of logic.
>
>   module Cnt56(K, CE, R, Out);
>     input         K, CE, R;
>     output [55:0] Out;
>     reg    [55:0] Q;
>     assign Out= Q;
>     always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
>     // if (R)       Q <= 0;    // This doesn't work either
>     // else if (CE) Q <= Q+1;
>   endmodule
>
> Why?  Instead of running the R signal directly to the
> reset pin of the flip flop, Synplicity merges it into
> the equations for Q and CE.  So we get:
>
>   module Cnt56(K, CE, R, Out);
>     input         K, CE, R;
>     output [55:0] Out;
>     reg    [55:0] Q;
>     assign Out= Q;
>
>     wire [55:0] Q_plus_1 = Q+1;
>     wire [55:0] Q_and_R = R ? Q_plus_1 : 0;
>     wire        CE_or_R = CE | R;
>
>     always @(posedge K) if (CE_or_R) Q <= Q_and_R;
>   endmodule
>
> Workaround?  I guess I have to instantiate an array of
> 56 flip flops and connect the signals the correct way.
> This is really ugly, and makes my design Xilinx-specific.
> If I want to use an Altera chip, I have to re-write the
> code.
>
> Which brings me to my point:
>   High level, abstract synthesis will never work well.  I realize
> this is an extreme statement, but if today's synthesizers can't
> do better than a factor of 2 for really simple code, it's
> hard to imagine a synthesizer in the near future that can
> compile complex code efficiently.

On the specific point you are right in that Synplify doesn't appear to
be using resources efficiently in this case. Esp since it does the reset
function by first inverting the reset input and then feeding the
inverted value into the adder LUTs - missing a clear opportunity to
optimise. The MAP program may do this for you later on.

A work-around is to use an async reset.

On the more general case IMO you are missing some of the idea behind
synthesis from HDLs. This is to get the results you need from the most
portable/maintainable/reuseable/retargetable source format. This is very
much in the spirit of the `C' vs. Assembler debate of long ago. Memory
got bigger and cheaper, uPs got faster, and compilers got better =>
Assembler went Dodo for all but a handful of special cases. Similarly
FPGA and ASICs are getting bigger and faster so the inefficiencies of
synthesised code will become less important [synth tools are getting
better as well, as are FPGA/ASIC P&R tools].

Again IMO the question you need to ask is whether the synth'ed result
meets your needs in terms of speed/timing. If not then the second level
question is whether, in a time2market dominated industry, going up a
speed grade is better than spending a lot of time hand-tuning the logic.
Its always possible to hand-craft technology specific logic that goes
faster - the question is whether its worth it. YMMV.


Article: 35571
Subject: I need free PCI-Core (vhdl)!!
From: "Ras Sim" <simsek@rhrk.uni-kl.de>
Date: Wed, 10 Oct 2001 23:18:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi folks!
I'm a student and i need a free PCI-Core wich is written in vhdl.
Where could I download it ?

Greets
Rasit


-- 
Posted from alcatraz148.wohnheim.uni-kl.de [131.246.107.157] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 35572
(removed)


Article: 35573
Subject: Re: 155MHz to DLL in Spartan II
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 10 Oct 2001 16:30:30 -0700
Links: << >>  << T >>  << A >>
I never saw the original question, but when Falk mentions frequencycounter,it caught my
attention.

The best way to count a frequency is a ripple counter with the first flip-flop
count-enabled by the gate signal. Don't even use the carry chain, it serves no purpose
in this scheme. It also makes more sense to concatenate dibits, since the two
flip-flops in a slice share a common clock.
After the end of the gate time ( 1 sec?) wait a little ( 16 ripples might take 50 ns )
Then the counter outputs are stable and there are no metastability issues when you read
it at any frequency.

Reading a running counter on-the-fly with a different clock from its count clock is
almost impossible, but that does not seem to be the problem here.

Peter Alfke  ( working on a 1-GHz frequency-counter design )

.

The only synchronization "problem" is in the counter LSB. But since that is a single
flip-flop, it either toggles or it does not, and that represents the unavoidable LSB
uncertainty.

Falk Brunner wrote:

> Kolja Sulimma schrieb:
> >
> > > Non-critical to me. Just use a global clock buffer to avoid pitfalls.
> >
> > As I understand it, the problem is how to interface values that are computed using
> > the 155 MHz Clock to logic running at the PCI Clock that is
> > asynchronous to the fast clock.
> > There are some metastability wizards in this newsgroup that propably can better
> > explain the possible solutions than I can.
>
> This is another thing, but for a frequency counter its not too hard,
> even for Non-Metastability Wizzards ;-)
>
> My proposal. Use a counter on the 33 MHz clock to generate a gate pulse
> (lets say 1 second).
> Drive this gate pulse directly with a FF to the 155 Mhz circuty. Use 1
> two or three cascaded FF on the 155 MHz clock to sychronize the gate
> pulse to the 155 Mhz clock. Use it thereafter as an clock enable for the
> 155 MHz counters.
> Thats almost all. When the gate pulse on the 33 MHz clock goes low, wait
> some more cycles (lets say 10) to be sure the 155 MHz counter is really
> stopped. Now read the content of the 155 Mhz counter.
>
> --
> MFG
> Falk


Article: 35574
Subject: Re: Virtex-2 maximum clock speed
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 10 Oct 2001 17:32:03 -0700
Links: << >>  << T >>  << A >>
Falk,

I will comment below,

Austin

Falk Brunner wrote:

> Austin Lesea schrieb:
> >
> > Himanshu,
> >
> > I agree that data sheets don't answer the question so ----
> >
> > Virtex II circuits support clocks running at 420 MHz on the global
> > buffers.
> >
> > That does not mean that you can make the entire design run that fast,
> > but small selected portions can certainly operate that fast.
>
> Hmm, but If I have a design, heavy pipelined, well floorplanned (its
> getting theoretical ;-), just 2 LUT levels between FFs, can this run
> @400 MHz? Or even 500, when just 1 LUT is used between FFs?

Hand placement leads to wonderful performance, but it leads to
unmaintainable designs.

>
>
> > Two techniques used commonly with the Virtex II are the use of the DCM
> > to provide clock multiplication, so the external clock is lower than
> > the internal clock, and the use of the duty cycle correction features
> > (DCM outputs CLK0 and CLK180 are duty cycle corrected if selectted,
> > and CLKFX and CLKFX180 are always duty cycle corrected) allow for
> > Double Data Rate (DDR) internal design techniques, doubling the work
> > per clock cycle (using both edges of the clock).
>
> Hmm, very good point. Does anybody here has informationas about DDR
> basics, design and common pitfalls (and how to avoid them).
> Also DDR Xmission on board level?

All good points, and we are woefully behind on the supporting applications
notes.  They are in progress, but late.  Basically, duty cycle is as
important as jitter (because it directly affects the eye sampling point),
jitter must be minimized on the incoming clock signal, all signals must be
matched receivers and drivers, as any reflections will kill your timing
budget, cross talk induced delay is importnat as it creates inter-symbol
inteference in busses, and skew int eh bus must be kept under control
(probably the easiest requirement as this is just physical distance).

One really neat feature is the variable phase shift, which one uses to
verify the eye opening!  Oops, I'm sorry, that sounded like marketing....but
I plead that it is still a really neat engineering feature to verify the eye
opening without having to buy a $$$$$$$ instrument.

>
>
> >
> > Thus selected portions of the chip may process information at 840
> > Mb/s.
>
> No problem with a 64 bit bus inside, its just 13 MHz ;-)
>

Per wire.

>
>
> > One major warning is that this is now a microwave world!  Signal
> > integrity at these frequencies is serious business, and I warn all
> > developers to make a concerted effort to get smart fast by reading
> > Howard Johnson's book on signal integrity, taking a class, and then
> > simulating and learning.  These classes and books are the best we
> > have, but remember, they are teaching, and they have not been
> > designing with 400 MHz clocks, as we are now, so some of their
> > information is out of date, obsolete, and just plain wrong -- but most
> > is very useful!
>
> Hmm, I got the Johnson & Graham Book, VERY nice stuff ;-) But how about
> an new issue, updated with todays devices (and their problems) ??
>

We are working on selected critical issues:  advanced bypassing techniques,
control of jitter, high speed bus issues (alluded to above), living with
extremely low voltage Vccint vs high voltage IO's (1.5 vs 3.3 and getting
"worse").

As an example, Johnson says that if 8 capacitors are adequate at 100 MHz, at
twice the frequency, you need to multiply by FOUR the capacitance to
bypass.  Well, people have run out of places to bypass the parts.  There are
other ways to design bypass than brute force.

>
> > As well, the quality of results from the software has been steadily
> > improving, with the latest clock speeds getting easier to implement as
> > the tools get better.  4.1i has set a new performance watermark, and
> > re-running old Virtex E designs has led to significant performance
> > (>10%, or a speed grade) improvements for some customers.
>
> Hmm but this is getting into the marketing stuff . . . .;-)
> Even the new software cant beat an engineer with real understanding of
> the FPGA structures, and much worse it cant fix the problems caused by
> an really unexpierienced designer.
> Or am I wrong?

A really good engineer who knows the structure may (only may) get a better
result.  That is because the engineer does not really know the structure.  A
good example is the FPGA editor view which is a simplistic representation of
the chip -- not at all how it is really implemented.  The synthesis tools
now know all of the tricks and truly know the structures, and their costs.

A really bad designer can have a terrible result from the tools....garbage
in, garbage out.  The tools are deesigned for the vast number of
VHDL/verilog coders who do a decent professional job, look at the quality of
results, read a little, check out structual improvements, and generally do a
quality job.  We allow these designers to have an excellent result by not
burdening them with special knowledge.  OOPS Marketing Alert!  But again, if
95% of the designs are HDL, and they are successful, haven't we targeted the
right market?

>
>
> > Again, it all depends on your design, and how it is architected, but
> > Virtex II has been very well accepted, and I continually hear from
> > customers how "Virtex II now makes life interesting as it competes
> > with the ASICs I was planning on having to design."
>
> He did it AGAIN. Marketing alert ;-)

No, worse than that, a sales pitch.

>
>
> Serious, I can believe that the Virtex-II is a very nice device
> althrough up to now I had no possibility to use one for a design :-(

I hope you (soon) encounter a requirement where Virtex II is a suitable
choice.

>
>
> --
> MFG
> Falk




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