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 27550

Article: 27550
Subject: Re: hard or soft core for FPGA?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 28 Nov 2000 10:56:58 -0800
Links: << >>  << T >>  << A >>
?????

What was Intel building 10 years ago?  Can you buy it today?

The 2000 series FPGA's were obsoleted just two years ago.  15 years of support!

It may be that a lot of FPGAs won't be available a few years from now: that is
why you need to choose the leading manufacturer of FPGA's.

Xilinx and their partners offer many 'soft' core microprocessors for use in
their FPGA's.

One of my favorites is the 8 bit RISC that is optimized for Virtex FPGA's and is
extremely useful for simple control tasks, and also uses a tiny amount of
resources.

 http://www.support.xilinx.com/xapp/xapp213.pdf

There are larger and more powerful processors as well,

Austin

Muzaffer Kal wrote:

> On Tue, 28 Nov 2000 08:50:09 +0100, "Pierre VERNEL"
> <vernel@ensem.u-nancy.fr> wrote:
>
> >For a product which will be manufactured in medium quantity but over a long
> >period of time (> 10 years) we have to use a System On Chip
> >
> >We plan to use an FPGA and we have the choice to use an hard core (like
> >Triscend or ATMEL FPSLIC) or a soft core (like NIOS)
> >
> >We think that the first solution is less expensive, but the other will
> >garantee us a better availability
> >
> >can you give us your opinion about this choice?
>
> I think one thing is pretty much certain: no fpga available today will
> be available for purchase in 10 years. So you have to buy end-of-life
> parts within three years or so which makes the availability issue
> moot. But if you get the NIOS version, you can make enhancements if
> you need to.
>
> Muzaffer
>
> FPGA DSP Consulting
> http://www.dspia.com


Article: 27551
Subject: Re: hard or soft core for FPGA?
From: "Keith R. Williams" <krw@btv.ibm.com>
Date: Tue, 28 Nov 2000 14:42:32 -0500
Links: << >>  << T >>  << A >>


Austin Lesea wrote:
> 
> ?????
> 
> What was Intel building 10 years ago?  Can you buy it today?

8051 and derivitives are way over 10 years old.  These are still
available, possibly not from Intel. The same goes for the 80186, though
I believe they're still available from Intel's embedded group.  Sure,
these are stone-aged devices, but still useful.

----
  Keith

Article: 27552
Subject: Re: hard or soft core for FPGA?
From: "Ulf Samuelsson" <ulf@atmel.dot.com>
Date: Tue, 28 Nov 2000 21:14:40 +0100
Links: << >>  << T >>  << A >>
Write the program in C.
Write proper drivers for the H/W peripherals.
Create backup H/W peripherals in FPGA technology.
You can then easily port ANY application to a new technology.

A big advantage of a "standard" processor, may be the available support
(compiler, debugger, RTOS, emulator etc).
There may be other advantages like power consumption.
Basically some people need some features and other need other features
which may make them go different directions.



--=20
Best Regards
Ulf at atmel dot com
These comment are intended to be my own personal view
and may or may not be shared by my Employer Atmel Sweden.


"Pierre VERNEL" <vernel@ensem.u-nancy.fr> skrev i meddelandet =
news:8vvoif$igp$1@arcturus.ciril.fr...
> For a product which will be manufactured in medium quantity but over a =
long
> period of time (> 10 years) we have to use a System On Chip
>=20
> We plan to use an FPGA and we have the choice to use an hard core =
(like
> Triscend or ATMEL FPSLIC) or a soft core (like NIOS)
>=20
> We think that the first solution is less expensive, but the other will
> garantee us a better availability
>=20
> can you give us your opinion about this choice?
>=20
> --
> Pierre VERNEL
>=20
> ENSEM - INPL
> 2 avenue de la foret de Haye
> F 54516 VANDOEUVRE les NANCY
> Tel : +33 (0)3 83 59 55 70
> Fax: +33 (0)3 83 59 55 73
> Email:vernel@ensem.u-nancy.fr
>=20
>=20
>=20


Article: 27553
Subject: Re: Fifo design problem
From: murray@pa.dec.com (Hal Murray)
Date: 28 Nov 2000 21:33:58 GMT
Links: << >>  << T >>  << A >>

>                                 (Note that the FIFO specifically allows
> you to assert REn or WEn when the FIFO is empty of full, respectively; it
> internal gates the signals so that they're ignored when neeeded.)

> I'd be curious to know if anybody else has had this experience.

You are not the first one to encounter troubles in that area.

That's a feature/bug that the FIFO manufacturers have been pushing
ever since I started reading their data sheets.


The problem is that it only works if you meet the setup and hold times,
and that's very hard to do if the read and write clocks are asynchronous.

Stop and think about it for a while.  This quickly gets into a
metastability issue.  Xilinx doesn't even publish any data for
their recent chips.  How are you going to evaluate the failure
rate of your FIFO design?

Every time I design in a FIFO, I make sure my design doesn't
write to a full FIFO or read from an empty one.  That's using
my logic that I can understand and get right.

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 27554
Subject: Re: ACEX1K vs FLEX10K
From: "Nick Bruty" <nick.bruty@easynet.co.uk>
Date: Tue, 28 Nov 2000 21:49:15 -0000
Links: << >>  << T >>  << A >>
Yes the power pins are different from the outside the reason being not to
force a board spin but to force a re compile as the internal pad bondings
are different so your expected IO's would appear on different pins.

Regards
Nick

"Carlhermann Schlehaus" <carlhermann.schlehaus@t-online.de> wrote in message
news:8u129n$119$00$1@news.t-online.com...
> Hi,
>
> "Ashok Chotai" <Ashok.Chotai@xilinx.com> schrieb im Newsbeitrag
> news:3A035133.9706DA1D@xilinx.com...
> > Hello Martin,
> > Same features, except the pinout. So, for example, FLEX 10K30E device is
> > NOT pin compatible with ACEX 1K30 device.
> > Ashok
> >
> I recently checked the pinouts of the EP1K100QC208 208pinner
> against the 10KE device. Every I/O pin and configuration pin
> was identically, they just switched some VCCIO / GND / VCCINT
> pins to prevent changing the device. Functionally you wouldn't
> get problems, but a 10K would cause a short between power
> supply in 1K layouts and vice versa...
>
> CU, Carlhermann
>
>



Article: 27555
Subject: Re: Xess - XS40-005XL question
From: "Nick Bruty" <nick.bruty@easynet.co.uk>
Date: Tue, 28 Nov 2000 21:51:03 -0000
Links: << >>  << T >>  << A >>
Nios a great solution for those wanting a 32bit RISC processor and competes
well on speed and cost, have you seen the Altera Nios dev kit, it sells for
under $1000 complete with software and hardware and comes ready for you to
start running C code on.

One cool bit of kit.

Nick

<longwayhome@my-deja.com> wrote in message
news:8vumqu$e52$1@nnrp1.deja.com...
> Hi
> I'm finally going to bite the bullet and buy a board - just want to
> double check that my final selection is ok for what i want to do.
>
> Is a XS40-005XL ( http://www.xess.com/prod004.html ) board suitable for
> hardware evolution, has anyone actually used it for that purpose ? I'd
> like to be able to program it with a C or Java API, is there suitable
> for that ? All suggestions welcome.
>
> Thanks
>
> David
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.



Article: 27556
Subject: Re: hard or soft core for FPGA?
From: "Nick Bruty" <nick.bruty@easynet.co.uk>
Date: Tue, 28 Nov 2000 21:51:53 -0000
Links: << >>  << T >>  << A >>
Nios a great solution for those wanting a 32bit RISC processor and competes
well on speed and cost, have you seen the Altera Nios dev kit, it sells for
under $1000 complete with software and hardware.

One cool bit of kit.

Nick

"Pierre VERNEL" <vernel@ensem.u-nancy.fr> wrote in message
news:8vvoif$igp$1@arcturus.ciril.fr...
> For a product which will be manufactured in medium quantity but over a
long
> period of time (> 10 years) we have to use a System On Chip
>
> We plan to use an FPGA and we have the choice to use an hard core (like
> Triscend or ATMEL FPSLIC) or a soft core (like NIOS)
>
> We think that the first solution is less expensive, but the other will
> garantee us a better availability
>
> can you give us your opinion about this choice?
>
> --
> Pierre VERNEL
>
> ENSEM - INPL
> 2 avenue de la foret de Haye
> F 54516 VANDOEUVRE les NANCY
> Tel : +33 (0)3 83 59 55 70
> Fax: +33 (0)3 83 59 55 73
> Email:vernel@ensem.u-nancy.fr
>
>
>



Article: 27557
Subject: Re: PLL vs DLL
From: "Nick Bruty" <nick.bruty@easynet.co.uk>
Date: Tue, 28 Nov 2000 21:53:01 -0000
Links: << >>  << T >>  << A >>
PLL will give better results

Nick

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



Article: 27558
Subject: Re: Spartan II ?
From: "Nick Bruty" <nick.bruty@easynet.co.uk>
Date: Tue, 28 Nov 2000 22:00:07 -0000
Links: << >>  << T >>  << A >>
You could always move the design to Altera, general lead-time 2 to 4 weeks
try taking a look at 1K30ATC144-3

Nick Bruty
Impact Memec
"Leon Heller" <leon_heller@hotmail.com> wrote in message
news:8tmloj$ode$1@nnrp1.deja.com...
> In article <39EDDC34.E81D3E2E@andraka.com>,
>   Ray Andraka <ray@andraka.com> wrote:
> .> Yep.  Try Nu Horizons or Insight.  We got them from one of the two
> (not sure
> > which now).  We got XC2S50-5FG256
>
> I've just been quoted 14-18 weeks lead-time for some XC2S50-5TQ144C by
> our distributor, Insight Memec, in the UK
>
> Leon
> --
> Leon Heller, G1HSM
> Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824
> Email: leon_heller@hotmail.com
> Web: http://www.geocities.com/SiliconValley/Code/1835
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 27559
Subject: Xilinx Coolrunner going on last time buy?
From: "Nick Bruty" <nick.bruty@easynet.co.uk>
Date: Tue, 28 Nov 2000 22:07:27 -0000
Links: << >>  << T >>  << A >>
I have heard that a UK distributor is telling customers that Xilinx
Coolrunner parts are going obsolete? Any comments Xilinx?

If any customers are in this position many of the parts are pin for pin with
Altera Max 7K & 3K families, it's what Philips used as a selling point for
Coolrunner, at least if your parts are going we can help.

For UK customers please drop me a email and I'll happily help you convert
the designs free.

Regards

Nick Bruty
Altera FAE
Impact Memec

ex Philips Coolrunner FAE




Article: 27560
Subject: Re: Fifo design problem
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Tue, 28 Nov 2000 15:45:26 -0700
Links: << >>  << T >>  << A >>
Joel Kolstad wrote:
> 
> "Jason Daughenbaugh" <jad@aedinc.net> wrote in message
> news:ee6ed1a.2@WebX.sUN8CHnE...
> > Asynchronous FIFOs are quite possibly one of the most difficult modules to
> implement.  In order to get water-mark flags to work properly (half-full,
> etc) you really need to use gray codes.  The Xilinx app notes describe this
> well.
> 
> One problem we had with the Xilinx app note FIFOs is that they use pipelined
> counters -- keeping around what the current gray count is, the next gray
> count, etc., and incrementing them in lock step -- and on a somewhat random
> basis the full and/or empty flags would go active when, indeed, we knew we
> hadn't really overflowed or underflowed the FIFO.  Our best guess as to the
> cause of this was that we were using GSR as the reset input to the FIFO but
> also asserting either REn or WEn just as GSR went inactive, and one of those
> pipelined counters was getting corrupted (i.e., there was a race condition
> between the various counter bits with GSR going inactive and a clock
> arriving with REn or WEn active).  (Note that the FIFO specifically allows
> you to assert REn or WEn when the FIFO is empty of full, respectively; it
> internal gates the signals so that they're ignored when neeeded.)
> 
> I'd be curious to know if anybody else has had this experience.
> 
> We ended up adding additional logic to make darn sure our REn and WEn
> signals were inactive until well after GSR had gone inactive, and that
> appeared to have solved the problem.  I don't consider this as 100% proof
> that we really know what the problem was in the first place, however. :-)

Joel,

Are you sure you weren't being screwed by the simulation model?

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 27561
Subject: Re: PLL vs DLL
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 28 Nov 2000 15:01:33 -0800
Links: << >>  << T >>  << A >>
Nick,

Measuring the jitter on the NIOS pcb coming out of the PLL clock out pin of
the 20KE had us smiling all around,

If you are going to mess with analog PLL's on the same chip as the digital
stuff: caveat emptor!

Austin

Nick Bruty wrote:

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


Article: 27562
Subject: Virtex II DLL at 311MHz on XCV300e-8ES
From: "Pete Dudley" <padudle@sandia.gov>
Date: Tue, 28 Nov 2000 16:44:36 -0700
Links: << >>  << T >>  << A >>
Hello All,

I am trying to use an XCV300e-8ES part to transmit and receive 16bit by
622MHz sonet frames but I think I may be having problems with the DLL's at
that frequency.

The chip has two 311MHz clocks coming into it, one for transmit and one for
receive. In order to indicate that my fpga is alive I am dividing the two
clocks by roughly 311,000,000 and flashing two LED's at about 1Hz. I have
noticed that after a while my LED's will stop flashing even though the
311MHz input clocks are still present.

On the transmit side I don't really care about the clock to Q times because
I'm sending a clock out with the data. This allowed me to eliminate the DLL
on the transmit clock and now my divider never stops flashing on that side.
On the receive side I must retain the DLL because input timing must be
controlled and the receive side LED still stops flashing after a few
minutes.

Does anyone know if the Virtex E DLL's are marginal at 311MHz?

I am working with engineering sample, ES, parts. What is the chance that
these parts are marginal and the problem would go away with real -8 parts?

Any comments along this line would be appreciated.

Thanks,

--
Pete Dudley
Sandia Labs
Albuquerque, NM
padudle@sandia.gov



Article: 27563
Subject: Re: Xilinx Coolrunner going on last time buy?
From: betsy thibault <betsyt@xilinx.com>
Date: Tue, 28 Nov 2000 17:50:35 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------587EF0BA7C3D56D89BBFCA98
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Nick,

It is true that Xilinx has had to shorten the lifecycle of the 'legacy' Philips
parts due to lack of fab capacity.  As you probably know, Xilinx has strategic
partnerships with a couple of fabs, but unfortunately not with the fabs where
these devices are manufactured.  Hence the end of life notice.  It has always
been in the plans to move the newest CoolRunner XPLA3 family to a strategic fab
partner, and that is in the works now.  The XPLA3 family is the next generation
CoolRunner, sporting even lower power consumption than the legacy products, and
a full PLA structure that allows for more logic flexibility and excellent
pin-locking capability. The XPLA3 family is also pin compatible with the parts
going end of life.

If anyone would like more information on the legacy devices, your local Xilinx
sales representative or hotline support personnel would be happy to help you
convert to an even lower power CoolRunner XPLA3 device.

Regards

Betsy Thibault
Xilinx Product Manager

ex Philips Product Manager

Nick Bruty wrote:

> I have heard that a UK distributor is telling customers that Xilinx
> Coolrunner parts are going obsolete? Any comments Xilinx?
>
> If any customers are in this position many of the parts are pin for pin with
> Altera Max 7K & 3K families, it's what Philips used as a selling point for
> Coolrunner, at least if your parts are going we can help.
>
> For UK customers please drop me a email and I'll happily help you convert
> the designs free.
>
> Regards
>
> Nick Bruty
> Altera FAE
> Impact Memec
>
> ex Philips Coolrunner FAE

--------------587EF0BA7C3D56D89BBFCA98
Content-Type: text/x-vcard; charset=us-ascii;
 name="betsyt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for betsy thibault
Content-Disposition: attachment;
 filename="betsyt.vcf"

begin:vcard 
n:Thibault;Betsy
tel;cell:(408) 206-4491
tel;fax:(505) 858-3106
tel;work:(505) 798-4810
x-mozilla-html:FALSE
org:<img src=http://www.xilinx.com/images/xlogoc.gif>
adr:;;7801 Jefferson Street NE;Albuquerque;NM;87109;USA
version:2.1
email;internet:Betsy.Thibault@xilinx.com
title:CoolRunner Marketing
fn:Betsy Thibault
end:vcard

--------------587EF0BA7C3D56D89BBFCA98--


Article: 27564
Subject: Re: Xess - XS40-005XL question
From: Neil Franklin <neil@franklin.ch.remove>
Date: 29 Nov 2000 02:05:29 +0100
Links: << >>  << T >>  << A >>
Jonas Thor <thor@NOSPAMsm.luth.se> writes:

> On Mon, 27 Nov 2000 22:22:32 GMT, longwayhome@my-deja.com wrote:
>
> >Is a XS40-005XL ( http://www.xess.com/prod004.html ) board suitable for
> >hardware evolution, has anyone actually used it for that purpose ?

What do you exactly mean with "hardware evolution". Improving hardware
for some project? Or are you trying to used genetic algorithms to
generate FPGA configurations? Or using FPGAs as co-processors to
compute GAs for something else? Or?

Perhaps if you tried to describe what you are trying to do, people
here could help you in selecting.


> >like to be able to program it with a C or Java API, is there suitable
> >for that ? All suggestions welcome.

Usual thing for programming FPGAs seems to be VHDL or Verilog.

C: exists as Algorithm->FPGA (Handel-C, commercial) which is a
sneered on method around here, and as C++ instantiate FPGA elements
(CNets, open source, but still at beginning of development).

Java: Xilinx has their JBits API/library, which is a low level (direct
bitstrem manipulation) tool.

But this only works with Virtex, not XC4000 nor VirtexE, according to
jbits@xilinx.com. That would need the Xess XSV boards, not XS40
boards. I will be installing JBits tomorrow, now that I have recovered
from the server HD trashed a week ago.

> I supposed you have noticed that there is a JBITs interface avaiable
> for that board? You can download it from XESS 'examples' web page.

JBits for the XS40? Xilinx says JBits is not for XC4000 (it once was,
but this support has been dropped).

Hmmm, I just went to http://www.xess.com/ho03000.html (Example Designs).
There are Jbits XHWIF for XS40-005XL and XSV-100. Does Xilinx not even
know its own software? Looks like tomorrow is going to be interesting.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic

Article: 27565
Subject: Re: Fifo design problem
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 29 Nov 2000 10:13:06 +0900
Links: << >>  << T >>  << A >>

"Joel Kolstad" <JoelKolstad@Earthlink.Net> writes:
 
> One problem we had with the Xilinx app note FIFOs is that they use pipelined
> counters -- keeping around what the current gray count is, the next gray
> count, etc., and incrementing them in lock step -- and on a somewhat random
> basis the full and/or empty flags would go active when, indeed, we knew we
> hadn't really overflowed or underflowed the FIFO.  Our best guess as to the
> cause of this was that we were using GSR as the reset input to the FIFO but
> also asserting either REn or WEn just as GSR went inactive, and one of those
> pipelined counters was getting corrupted (i.e., there was a race condition
> between the various counter bits with GSR going inactive and a clock
> arriving with REn or WEn active).  (Note that the FIFO specifically allows
> you to assert REn or WEn when the FIFO is empty of full, respectively; it
> internal gates the signals so that they're ignored when neeeded.)
> 
> I'd be curious to know if anybody else has had this experience.

Well, to be honest, I studied that app note, and decided that it was just 
too damn complicated.  There was another one there on FIFO design that used a
latch <gasp!>, and I've decided to lean that way.

I have grey counters for read and write pointers; obviously, asserting full is 
synchronous to the write clock, and deasserting it is synchronous to the read 
clock.  And, of course, it's only logic using the write clock that cares if 
it's full.  What I'm doing is latching the Full signal when my write clock 
is 'high'.  That gives me a worst case of a half-clock-cycle for metastability 
events to settle, with the only caveat that Full might be deasserted one clock
cycle late.  But nobody cares about that, right?

And, I'm internally gating the write operation with the Full signal, so that 
if my logic outside the Fifo doesn't want to look at the Full signal, it doesn't 
have to.


If this is a nice and safe way to do it, then you're welcome!  If it isn't, 
somebody please let me know!

-Kent

Article: 27566
Subject: Wide AND function.
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 29 Nov 2000 11:07:05 +0900
Links: << >>  << T >>  << A >>
Hi, everyone.

I'm looking to impement a wide trinary compare 
function (32 bits), in once clock cycle.

The bit-wise compare function consist of three
bits; a Data bit (D), a Comparand bit (C), and
a Mask bit (M).

If the bit is masked with M, then the bit match 
is always a success.  Otherwise it's a success 
only if D = C.  This is easy enough, and takes 
up almost no logic.

If all of the bitwise compare functions are a 
success, then the compare itself is a success,
wheras if one fails, then the compare fails.
This is basically a big 'ole and gate.

Seeing as I want to do this in one clock cycle, 
and *really* don't want to pipeline it, is 
there a fancy way of implementing a wide 
AND-function?  I was thinking of something along
the lines of 32 trisate drivers and a pull-up.
If one of them failes, it drives the common bus 
low; if none of them fail, the bus is pulled high,
and a 'success' is registered.  Unless I'm missing
something (which is entirely possible), there is
nothing like this on the inside of a Virtex/SpartanII
FPGA.

Does anyone have any other ideas or suggestions?

Thanks a bunch,
Kent.




Article: 27567
Subject: question on initial states of FFs and GSR in Virtex
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Date: 28 Nov 2000 18:11:50 -0800
Links: << >>  << T >>  << A >>

Dear all,

after reading the thread

http://x58.deja.com/viewthread.xp?AN=694955633&search=thread&svcclass=dncurrent&ST=PS&CONTEXT=975460744.1523515397&HIT_CONTEXT=975460744.1523515397&HIT_NUM=10&recnum=%3c3A15D7F9.64FAD382@andraka.com%3e%231/1&group=comp.arch.fpga&frpage=viewthread.xp&back=clarinet

entitled "VHDL & Spartan: How to power-up a Register to '1'", I am
still confused. There are clearly two methods to initialize the flops:
either by putting an INIT attribute, like Ray suggested:

  attribute INIT : string;
  attribute INIT of FD1 : label is "S";

or by inferring a register from a process with an async reset driven
by GSR:

 Reg : process (Clk, GSR) 
       begin
         if Reset  = '1'                  -- If asynchronous reset
           then widget <= (others => '1');--  then set flop to one
         elseif  rising_edge(Clk)         -- else if clock
           then                           --  then whatever
         ...
         end if;
       end process;

These methods are obviously equivalent from a logic point of view,
but it's not clear if they turn into the same physical implementation.
The poster who started the thread was looking for a way to ensure that
after the end of FPGA configuration the register would hold the
specified set/reset values independently of any transition on GSR
line. I think that this is a relevant question since the use of GSR
as a driver for Reset has been deprecated in this group and by Xilinx
itself.

Any comments?

Best,
-Arrigo

Article: 27568
Subject: Re: Wide AND function.
From: Duane <junkmail@junkmail.com>
Date: Tue, 28 Nov 2000 19:14:21 -0800
Links: << >>  << T >>  << A >>
Kent Orthner wrote:
> 
> Hi, everyone.
> 
> I'm looking to impement a wide trinary compare
> function (32 bits), in once clock cycle.
> 
> The bit-wise compare function consist of three
> bits; a Data bit (D), a Comparand bit (C), and
> a Mask bit (M).
> 
> If the bit is masked with M, then the bit match
> is always a success.  Otherwise it's a success
> only if D = C.  This is easy enough, and takes
> up almost no logic.
> 
> If all of the bitwise compare functions are a
> success, then the compare itself is a success,
> wheras if one fails, then the compare fails.
> This is basically a big 'ole and gate.
> 
> Seeing as I want to do this in one clock cycle,
> and *really* don't want to pipeline it, is
> there a fancy way of implementing a wide
> AND-function?  I was thinking of something along
> the lines of 32 trisate drivers and a pull-up.
> If one of them failes, it drives the common bus
> low; if none of them fail, the bus is pulled high,
> and a 'success' is registered.  Unless I'm missing
> something (which is entirely possible), there is
> nothing like this on the inside of a Virtex/SpartanII
> FPGA.

Actually, there is. For clues, take a look in the Libraries guide at the
Virtex/SpartanII implementation of the COMPMC8. Basically what you would
do would be to implement the logic for the three bits in the LUT, and
use the output to control the S select of the MUXCY in the ripple carry
chain. This chain is very fast, and should easily handle 32 bits for all
but very fast clocks.

The way I have done almost the exact same thing in one of my designs is
to connect GND to all the DI inputs of the MUXCYs in the chain and
connect VCC to the CI input of the first MUXCY in the chain. The rest
are chained together the standard way with O of one MUXCY going to CI of
the next one. At the top of the chain, the of the last MUXCY is low if
any of the bit tests failed, else the VCC from the first MUX ripples all
the way through and the result is a high.

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

Article: 27569
Subject: Re: question on initial states of FFs and GSR in Virtex
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 28 Nov 2000 22:51:32 -0500
Links: << >>  << T >>  << A >>
Arrigo Benedetti wrote:
> 
> Dear all,
> 
> after reading the thread
> 
> http://x58.deja.com/viewthread.xp?AN=694955633&search=thread&svcclass=dncurrent&ST=PS&CONTEXT=975460744.1523515397&HIT_CONTEXT=975460744.1523515397&HIT_NUM=10&recnum=%3c3A15D7F9.64FAD382@andraka.com%3e%231/1&group=comp.arch.fpga&frpage=viewthread.xp&back=clarinet
> 
> entitled "VHDL & Spartan: How to power-up a Register to '1'", I am
> still confused. There are clearly two methods to initialize the flops:
> either by putting an INIT attribute, like Ray suggested:
> 
>   attribute INIT : string;
>   attribute INIT of FD1 : label is "S";
> 
> or by inferring a register from a process with an async reset driven
> by GSR:
> 
>  Reg : process (Clk, GSR)
>        begin
>          if Reset  = '1'                  -- If asynchronous reset
>            then widget <= (others => '1');--  then set flop to one
>          elseif  rising_edge(Clk)         -- else if clock
>            then                           --  then whatever
>          ...
>          end if;
>        end process;
> 
> These methods are obviously equivalent from a logic point of view,
> but it's not clear if they turn into the same physical implementation.
> The poster who started the thread was looking for a way to ensure that
> after the end of FPGA configuration the register would hold the
> specified set/reset values independently of any transition on GSR
> line. I think that this is a relevant question since the use of GSR
> as a driver for Reset has been deprecated in this group and by Xilinx
> itself.
> 
> Any comments?
> 
> Best,
> -Arrigo

To the best of my knowledge, once you get this working correctly, they
will produce an equivalent circuit in the FPGA. Some people think that
adding the reset to every FF in your code will create a long signal that
snakes through the design. But this signal is replaced by the GSR net in
the FPGA. The GSR net is what puts all the FFs in a defined state when
coming out of configuration. If you wish, you can use this as an
external reset as well by bringing it to a pin. But that is not
required. 


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
URL http://www.arius.com

Article: 27570
Subject: Re: Newsgroup : Accessing through Netscape Navigator
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Tue, 28 Nov 2000 19:57:49 -0800
Links: << >>  << T >>  << A >>
On Tue, 28 Nov 2000 09:43:23 -0800, "Walter Haas"
<walter_haas@pmc-sierra.com> wrote:

>Hi all,
>
>I access this forum through the Xilinx Support page, but I was hoping someone could tell me how I can access it through Netscape Navigator.
>
>Some fairly explicit instructions on what to set up in Navigator would be very helpful. 
>
>Cheers,
>
>Wally

Wally,

you might consider using Forte Agent (or the free version Free Agent)
as a newsreader. It's much better, faster, and more reliable than
Netscape for accessing newsgroups.

John


Article: 27571
Subject: Re: Virtex II DLL at 311MHz on XCV300e-8ES
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 28 Nov 2000 20:35:18 -0800
Links: << >>  << T >>  << A >>
Pete,

Early ES material did not meet our speed targets.  Production material does.

I sent you some comments from the designer of the DLL to figure out if this is
a slow ES part, or some other issue (as a non-newsgroup email).

In future, you might also try the hotline as they could also answer the
question of the actual performance of the lot of ES that you have.  If you have
the date code, I could also do that, but it might take me a little longer,

Austin Lesea
IC DES
Xilinx

Pete Dudley wrote:

> Hello All,
>
> I am trying to use an XCV300e-8ES part to transmit and receive 16bit by
> 622MHz sonet frames but I think I may be having problems with the DLL's at
> that frequency.
>
> The chip has two 311MHz clocks coming into it, one for transmit and one for
> receive. In order to indicate that my fpga is alive I am dividing the two
> clocks by roughly 311,000,000 and flashing two LED's at about 1Hz. I have
> noticed that after a while my LED's will stop flashing even though the
> 311MHz input clocks are still present.
>
> On the transmit side I don't really care about the clock to Q times because
> I'm sending a clock out with the data. This allowed me to eliminate the DLL
> on the transmit clock and now my divider never stops flashing on that side.
> On the receive side I must retain the DLL because input timing must be
> controlled and the receive side LED still stops flashing after a few
> minutes.
>
> Does anyone know if the Virtex E DLL's are marginal at 311MHz?
>
> I am working with engineering sample, ES, parts. What is the chance that
> these parts are marginal and the problem would go away with real -8 parts?
>
> Any comments along this line would be appreciated.
>
> Thanks,
>
> --
> Pete Dudley
> Sandia Labs
> Albuquerque, NM
> padudle@sandia.gov


Article: 27572
Subject: Re: Wide AND function.
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 29 Nov 2000 13:38:31 +0900
Links: << >>  << T >>  << A >>


> Kent Orthner wrote:
> > 
> > Seeing as I want to do this in one clock cycle,
> > and *really* don't want to pipeline it, is
> > there a fancy way of implementing a wide
<snip>
> > nothing like this on the inside of a Virtex/SpartanII
> > FPGA.
> 

Duane <junkmail@junkmail.com> writes:
> Actually, there is. For clues, take a look in the Libraries guide at the
<snip>
> the way through and the result is a high.

Duane,

Thanks.  This is exactly the kind of "Fancy way" that I was looking for.  
In the data book it shown Cin to Cout delay to be 0.2ns max, which should
give me 6.4 ns for the entire thing.  I'm hoping for 9.6ns for everything, 
including the compare, but maybe I'm being too optimistic.  (I'm stuck 
with the cheapest speed grade, after all.)

Maybe I'll run it as a tree of CinCout chains or something; we'll see.

Thanks for the advice.

On a side note, when I look at the CY Muxes, do you know what the 'BX' 
input is, and what it's for?

-Kent

Article: 27573
Subject: Re: Fifo design problem
From: "Joel Kolstad" <JoelKolstad@Earthlink.Net>
Date: Wed, 29 Nov 2000 04:43:55 GMT
Links: << >>  << T >>  << A >>
"Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
news:901ckf$2h1q$1@noao.edu...
> Are you sure you weren't being screwed by the simulation model?

No, it worked fine in simulation, it was the real design PARed on the real
live PCB that had problems!

---Joel




Article: 27574
Subject: Re: Fifo design problem
From: "Jean Nicolle" <jeann17@home.com>
Date: Wed, 29 Nov 2000 04:58:15 GMT
Links: << >>  << T >>  << A >>
why not use an already debugged FIFO core?
Altera has a FIFO wizard/megafunctions, while Xilinx had CoreGen (I
believe).

"j" <j@j.com> wrote in message news:8vrkt0$fk8$1@uranium.btinternet.com...
> Hi,
>      I am new to vhdl/FPGA design, I am designing a FIFO who's read and
> write ports operate on different clocks at different frequencies. I am
> keeping track of how full/empty the FIFO is by using a counter that
> increments during a write and decrements during a read. This presents a
> problem as when a read and write occur simultaneously the counter will not
> function correctly.
> How do I solve this, should I adopt a different approach to keep a count
to
> generate the full and half full flags ?
>
> Thanks
>
> J
>
>





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