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 22575

Article: 22575
Subject: Re: Do you know xilinx FPGAs well?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 12 May 2000 14:26:39 GMT
Links: << >>  << T >>  << A >>


shahzad2512@my-deja.com wrote:

> I have to implement the following:
> 1. 8032 microcontroller,
> 2. 64kbytes SRAM,
> 3. some 8 latches and two 3x8 decoders,
> 4. 12kHz Generator
> 5. 16kHz detection
> 6. DTMF dialer.
>
> The above is the customized solution for a telephone set for some
> telecom company.
>
> After some initial study, i think that Virtex could give me solution.
> There is also an A/D converter(which i might need) in the Virtex and
> such a large memory could only be implemented in an Virtex.

The A/D is news to me, unless you want to build a delta-sigma converter.
Virtex would be an overkill for this.  With the exception of the memory
and ADC, you could get the rest of this into a spartan or spartanII
device.  True, you could have the 64Kx8 in a large virtex EM, but you'll
pay alot more than you would for a small FPGA and external RAM.  You
might look at the Triscend chip.  It's an 8032 with integrated FPGA
fabric that isn't all that different than the xilinx 4K fabric.  It also
has a fair amount of memory on-chip, but I think that is less than 64Kx8.

>
>
> But then i thought that since Virtex is expensive, this is not a good
> solution. I thought of SPARTAN II but then SRAM is out.
> What do u thing and suggest.
> Any comments........?
> Thanks and Regards,
> SHAH
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
P.S.  Please note the new email address and website url

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com  or http://www.fpga-guru.com


Article: 22576
Subject: Re: asic vs fpga
From: Ray Andraka <ray@andraka.com>
Date: Fri, 12 May 2000 14:29:39 GMT
Links: << >>  << T >>  << A >>
ASIC = Application Specific Integrated circuit.  Generally these are
considered to be chips that are manufactured for one specific
application...they do that task well but are not suited to doing much
anything else.  FPGAs end function is determined by a user program, so
all the FPGAs come off the chip fab looking the same.  The user then
configures them for his application through a bitstream.

Sharp wrote:

> i'm newbie to this field
>
> what is the diff between an asic and fpga?
>
> sharp

--
P.S.  Please note the new email address and website url

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com  or http://www.fpga-guru.com


Article: 22577
Subject: Re: Xilinx Virtex SRL16
From: Ray Andraka <ray@andraka.com>
Date: Fri, 12 May 2000 14:34:42 GMT
Links: << >>  << T >>  << A >>
You need to instantiate the SRL16 rather than infer it to do this.  Then put
an INIT= value attribute on the instance label.  to do the attribute use this
in your architecture declarations:

attribute INIT: string;
attribute INIT of U1:label is "<your ascii hex string here>";

Refer to the libraries guide for details of the INIT usage for SRL16's.



Tim Courtney wrote:

> With SRL16 I am trying to specify an initial value without resorting to
> playing with tools like JBITs. It's really doing my head in. Any ideas
> out there?
>
> --
> Tim Courtney
> Electrical & Electronic Engineering     mobile  : +44 (0)7801 250 903
> The Queen's University of Belfast       tel(wk) : +44 (0)28 9027 4275
> Ashby Building, Stranmillis Road        fax     : +44 (0)28 9066 7023
> Belfast, Northern Ireland, BT9 5AH      e-mail  : t.courtney@ee.qub.ac.uk

--
P.S.  Please note the new email address and website url

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com  or http://www.fpga-guru.com


Article: 22578
Subject: Re: Future of FPGAs?
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 12 May 2000 15:18:53 GMT
Links: << >>  << T >>  << A >>
	FPGAs will continues to replace asics where the FPGA costs end
up being less (FPGAs being much lower NRE and time-to-market).

	FPGA-like logic will become very common in the
System-on-a-chip environment, for undefined at fabrication-time I/O
and operations.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 22579
Subject: Re: Future of FPGAs?
From: Robert Posey <muddy@raytheon.com>
Date: Fri, 12 May 2000 10:20:25 -0500
Links: << >>  << T >>  << A >>


shahzad2512@my-deja.com wrote:
> 
> Forget about what the FPGA vendor says about the future of the FPGAs.
> Let us have discussion from professionals who are and have been working
> in these areas. Discussion might be or may not be limited to the
> following:
> 
> Its true that FPGAs will never replace ASICs but will penetrate the
> ASIC market in one way or the other.
> 
> FPGAs will be used mainly for prototyping and educational environment.

Ignore the vendor, and look what NASA, and other high speed processing users
are doing.  Using FPGA as reconfigable processing units is a function that
cannot be duplicated in ASIC in a meaningful way.  However, there might be
a market for a new form of FPGA that was specialized for various types of
processing.  I think the more likely future would see ASIC getting less and
less share of all but the biggest markets, and FPGA's taking over.  For
most applications FPGA's have more than enough performance, and are 
a much smaller risk.  For my field of Defense the main issues with ASIC are
time and risk.  If you screw up a FPGA design, you down-load again.  If 
you mess up an ASIC, you are looking at weeks of delay. That's just not 
tolerable anymore.  I think FPGA's have a reasonable chance of replacing 
micro-contollers through emulation for applications where you have a 
microcontollers and several Digital Support IC.  So FPGA's are here to 
stay, at least in the high performance processing area, and should 
continue to take market share from ASIC and conventional ICs as even 
commercial products become more and more short run items.  In addition,
as ASIC vendors finally reach maturity, ASIC design won't all that different
from FPGA design.  In both cases it will be a major of hooking together 
your own or someone else's IP in a higher level language, and then giving
it to a program to fit in a device.  So I don't see a lot of difference
between the two job, other than the fact the FPGA designer maybe more
algorithm oriented.

Muddy


> 
> There is going to be a market saturation very soon for the businesses
> providing cores for FPGAs.
> 
> The demand for job market for FPGAs is not very huge.
> 
> The expected growth for PLD industry for the year 2000 is 35%
> 
> Cheers,
> SHAH
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Article: 22580
Subject: Re: OT ANNOUNCE: Embedded Systems Glossary and Bibliography
From: "Arie de Muynck" <not@anywhere.org>
Date: Fri, 12 May 2000 18:06:25 +0200
Links: << >>  << T >>  << A >>
"Johan Kwisthout" <j.kwisthout@observator.com> wrote:
> I recall WP5.1 had a character for that, which (in my experience)
> noone ever used. Everyone types an 'i' and a 'j' instead of the dotted
> y.

And I even stopped using my real name
    de Mu˙nck --> de Muijnck --> de Muynck
just for Internet ease...

(Note: the ˙ character is alt-152 on a PC numeric pad. It may not be visible
on non-PC systems or in other language settings).

Regards,
Arie de Muynck

arie at ademu dot com



Article: 22581
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
From: gneuner@dyn.SPAMMERS.DIE.com (George Neuner)
Date: Fri, 12 May 2000 16:25:59 GMT
Links: << >>  << T >>  << A >>
On Mon, 08 May 2000 16:53:54 -0700, Jon Kirwan
<jkirwan@easystreet.com> wrote:

>I suppose that the term mutex might be applied to any specific
>implementation that guarantees "mutual exclusion," even message-based.
>But most of the use I've heard put to the term relates to this
>obvious, special purpose use of semaphores.

Correct.  "Mutex" [in CS] is a generic term referring to any mechanism
of mutual exclusion.  The simplest using shared memory is the binary
semaphore, the most complicated is Hoare's monitor construct.
Separate memory, IPC implementations have given us distributed
queuing, reservation, blackboarding, priority election, etc.

In the '70s there was an explosion of papers proposing new ways to
provide mutual exclusion under various contexts.  There were so many
papers published in such a short time that I was convinced CS
researchers were doing nothing else.  The '80s brought another round
with network implementations.

The use of "mutex" to refer to a particular implementation
[effectively a binary semaphore] came with MS Windows.  Unix had
binary "mutex" semaphores prior to Windows, but the vast numbers of
Windows programmers [having no other experience] brought the term into
general use. 


George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================
Article: 22582
Subject: Re: Future of FPGAs?
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Fri, 12 May 2000 09:40:01 -0700
Links: << >>  << T >>  << A >>
Quick thoughts:

<shahzad2512@my-deja.com> wrote in message
news:8fgkf4$euq$1@nnrp1.deja.com...
> Its true that FPGAs will never replace ASICs but will penetrate the
> ASIC market in one way or the other.

Yes.  FPGAs, if anything, are advancing in their speed and density faster
than ASICs are.  Although ASICs will always be cheaper for high volume runs,
FPGAs will continue to look more and more attractive for small volumes and
some mid-volume projects.

> FPGAs will be used mainly for prototyping and educational environment.

Nope.

> There is going to be a market saturation very soon for the businesses
> providing cores for FPGAs.

Hard to say.  Cores are a new field, and it's very difficult to make money
with them at the moment.  The market model of IP isn't even really all that
solid yet.  Heck, the market model for EDA tools isn't either.  I do think
that "standard cores" along the lines of data processing, CPUs, bus
interfaces, etc. have a bright future.

> The demand for job market for FPGAs is not very huge.

Compared to what?  Compared to, say, PC programmers for "dot com" companies,
sure.  But compared to, say, RF design engineers, there's lot of FPGA design
jobs out there.  And people who can combine FPGAs with one of these other
"small" -- but technically challenging -- fields, such as digital radio
front ends, video/audio signal processing, etc., are in a very good position
to find themselves continuous employment.  And throw in being able to
program PCs at a decent level, and you can just about write your own
check...

> The expected growth for PLD industry for the year 2000 is 35%

I'd have to refer to some trade magazine for that one.

---Joel Kolstad



Article: 22583
Subject: Re: Future of FPGAs?
From: myself@magma.ca (myself)
Date: Fri, 12 May 2000 16:44:56 GMT
Links: << >>  << T >>  << A >>
All good points however I would be more interested to discuss if the
fpga can move from all digital to a mix of analog and digital with the
addition of a/d converters and configurable op-amps and comparators.
Article: 22584
Subject: Re: Do you know xilinx FPGAs well?
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Fri, 12 May 2000 09:49:08 -0700
Links: << >>  << T >>  << A >>
<shahzad2512@my-deja.com> wrote in message
news:8fglhp$frl$1@nnrp1.deja.com...
> I have to implement the following:
> 1. 8032 microcontroller,
> 2. 64kbytes SRAM,
> 3. some 8 latches and two 3x8 decoders,
> 4. 12kHz Generator
> 5. 16kHz detection
> 6. DTMF dialer.
>
> The above is the customized solution for a telephone set for some
> telecom company.

Sounds a lot like a homework assignment to me...

> After some initial study, i think that Virtex could give me solution.
> There is also an A/D converter(which i might need) in the Virtex and
> such a large memory could only be implemented in an Virtex.

There isn't an A/D converter in a Virtex FPGA, although you can certainly
build crude ones with just a couple of extra components -- but the same
thing can be done with a CPU.  In your case, however, at audio frequencies
you're probably much better off just buying some little ADC chip with
something like a serial interface that'll plug back into your 8032.

> But then i thought that since Virtex is expensive, this is not a good
> solution. I thought of SPARTAN II but then SRAM is out.

You're correct, using a Virtex part just to get the 64KB of (block) RAM is a
very expensive way to go.  If you're bound and determined to use an FPGA, a
Spartan with a small RISC CPU embedded, 64KB of external SRAM (one IC), an
external codec containing an ADC, DAC, and companding circuitry, and a
little bit of analog glue would get you going on the cheap.  But this
assumes you have the high volumes necessary to justify the development or
purchase price of a CPU core.  If you don't, the microcontroller alternative
looks very attractive.  If you're doing this on a small budget and need to
do it reasonably rapidly (in a matter of months), the 8032 approach is
definitely going to be a much lower risk approach than the FPGA one.

You need to determine what your "time and money" constraints are to fully
answer this question.

---Joel Kolstad



Article: 22585
Subject: Help-help
From: "embargo" <noembargo@hotmail.com>
Date: Sat, 13 May 2000 02:19:23 +0900
Links: << >>  << T >>  << A >>
Anyone help me.!!!
I'm a graduate school of keio univ. in japan.
my home work is search,
I am searching a market size of fpga and kasutamu ic.

if anyone has a information. please help me.

my e-mail;embargo1@mag.keio.ac.jp


Article: 22586
Subject: Re: Do you know xilinx FPGAs well?
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Fri, 12 May 2000 19:48:00 +0200
Links: << >>  << T >>  << A >>


> shahzad2512@my-deja.com wrote:
>
> > I have to implement the following:
> > 1. 8032 microcontroller,
> > 2. 64kbytes SRAM,
> > 3. some 8 latches and two 3x8 decoders,
> > 4. 12kHz Generator
> > 5. 16kHz detection
> > 6. DTMF dialer.
> >
> > The above is the customized solution for a telephone set for some
> > telecom company.

Why SRAM?
No Non volatile memory?
Will you execute code from the SRAM?
    If so , how much of the SRAM will be code and how much will be data.
Are You going to write in C?
    If that is that is the case, then you might want to look at the Atmel
FPSLIC.
    This has 40k FPGA gates + a high speed RISC processor.
    YES! we do have first silicon nowadays!!!
The FPSLIC only has 36 kB of SRAM, but the code density is way superior
to the 8051 when you program in C so you might still win.
Check www.atmel.com for Programmable SLI.

If you can live with Flash instead of some of the SRAM,
I think there are better solutions though.
You can get an ARM based controller with
onchip Telephone oriented ADC/DAC = Combo circuit and SRAM
+ DSP doing what you want and more for less than an FPGA solution
would cost.

--
Best regards,
ulf at atmel dot com



Article: 22587
Subject: Re: Future of FPGAs?
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Fri, 12 May 2000 19:54:06 +0200
Links: << >>  << T >>  << A >>

"myself" <myself@magma.ca> wrote in message
news:391c34b6.17313175@news.magma.ca...
> All good points however I would be more interested to discuss if the
> fpga can move from all digital to a mix of analog and digital with the
> addition of a/d converters and configurable op-amps and comparators.

Can be done today in ASIC! Send a Purchase Order  :-)
May be more expensive than discrete alternatives, since
normally the pure CMOS process is available well in advanced of the
mixed signal processes, but since you can integrate both FPGA blocks
and analog blocks in ASIC, there is nothing technical to stop you from doing
it.


--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden



Article: 22588
Subject: Re: Future of FPGAs?
From: husby@fnal.gov (Don Husby)
Date: Fri, 12 May 2000 18:07:28 GMT
Links: << >>  << T >>  << A >>
shahzad2512@my-deja.com wrote:
> FPGAs will be used mainly for prototyping and educational environment.

No, but it might be safe to say that prototyping and education will be done
mainly with FPGAs.  As will many scientific projects that require one-of-a-kind
custom processors and data acquisition.

> There is going to be a market saturation very soon for the businesses
> providing cores for FPGAs.

For two reasons:
  1) More and more free cores will be available from chip vendors and hackers.
  2) Tools will improve significantly, making it almost as easy to create custom
     code as it is to buy and use cores.

My prediction:
  Although I don't like to use buzzwords like "paradigm shift", circuit design
is long overdue for one.  VHDL will bite the dust when someone comes up with a
sensible way of designing, simulating, and synthesizing FPGAs.  (Preferably one
that doesn't mangle signal names :)



--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 22589
Subject: Re: asic vs fpga
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Fri, 12 May 2000 20:09:45 +0200
Links: << >>  << T >>  << A >>

> Sharp wrote:
>
> > i'm newbie to this field
> >
> > what is the diff between an asic and fpga?

I think it is a little bit more complex.

ASIC stands for (As Ray mentions) Application Specific Integrated Circuit.
Some people give it a further interpretation/restricting it to be a gate
array.

Others mean that ASICs are circuits which are designed by a customer
for a specific purpose and if the semiconductor vendor designs the
circuit it is either for a single customer and is then called CSP
(Customer Specific Product) or for a few/many customers in which
it is called an ASSP (Application Specific Standard Product).

I personally think that if the word ASIC should have ANY practical
use, this is the one I'd go for, regardless of the actual meaning of the
words.
I do not need a synonym for gate array, I'd rather just call it a gate
array!!!

Now when a customer can design a circuit for a specific purpose
where one core part is an FPGA block allowing him  some reconfigurability
what do we call that?



> >
> > sharp
>
> --


--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden



Article: 22590
Subject: Re: Future of FPGAs?
From: "Steve Casselman" <sc@vcc.com>
Date: Fri, 12 May 2000 11:23:27 -0700
Links: << >>  << T >>  << A >>
> Its true that FPGAs will never replace ASICs but will penetrate the
> ASIC market in one way or the other.
>

This is wrong. When quatum dots or nanotube FET's come along there will be
no more ASICS or processors or any kind of device that does logic with the
exception of special I/O and power requirements other than reconfigurable
(FPGA like) processors. Processors and digital subsystems will all be in the
same reconfigurable devices because of bandwidth problems created by placing
these things in seperate packages.

Steve Casselman, President
Virtual Computer Corporation


Article: 22591
Subject: CLKing external RAM from FPGA (Virtex E)
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Fri, 12 May 2000 14:42:12 -0500
Links: << >>  << T >>  << A >>
All,
We have 4 SRAMs hanging a Xilinx VirtexE 1000.  We are investigating how
to clock them.  One possible solution gets DRC errors when we run
through the tools and we don't understand why.

Here is the scenario.  We want to use a DLL to generate the clock, send
the output of the DLL to a BUFG, and then the output of the BUFG to
multiple OBUFs.  These would be the clocks for the SRAMs.  The feedback
to the DLL, the CLKFB pin, would come back in from outside the chip, to
an IBUFG, and then to the CLKBF pin of the DLL.  This all works fine and
is standard if we only send the output of the BUFG to "ONE" OBUF, but if
we try to fan this out to multiple OBUFs it doesn't work....we get DRC
errors......why.  Also, if we use internal feedback, instead of going
offchip, we can send the output of the BUFG to multiple OBUFs.  I know
this feedback is worthless, but we tried it just for the heck of it.

Separatly, we can send the output of a BUFG to multiple OBUFs, and the
output of a DLL can go to the input of a BUFG.  Put these together and
you get DRC errors.

I understand that the feedback is supposed to be a delay compensator for
your outside path and the DLL uses this to adjust the outgoing clock.
If we assume that the outside traces and loads for these different
clocks are the same (designed that way), then we should be able to take
the feedback from one of these and hook it to CLKFB, but again, it
doesn't work.

Also, as we haven't gotten this through the tools, we don't know what
the skew would be between the different OBUFs.  We were assuming since
the OBUFs are fed by the BUFG, there would be very little skew???

Any thoughts.  If someone has designed a bank of 4 SRAMs off of a single
FPGA it would be very helpful to see your sceme...both on the FPGA and
at the board level.

We are investigating other ways of doing this, but would like to
understand why this doesn't work.

Her is the error we get......anyone know how to get around the DRC error
and how bad of an idea this is????  Probably not a good one.

ERROR:DesignRules:365 - Blockcheck: Improper DLL feedback loop. Signal
wclk100 is driving pin IN of comp bufg1.  Since pin CLKFB of DLL clkdll2
is
driving by an GCLKIOB, its output must drive the O pin of IOB.

Tom


Article: 22592
Subject: Re: Reccomend an ASIC emulation board
From: "John Gallagher" <johng@synplicity.com>
Date: Fri, 12 May 2000 20:28:17 GMT
Links: << >>  << T >>  << A >>
Hi John -

A good general overview of ASIC prototyping boards using FPGAs can be found
at:
http://www.optimagic.com/boards.html

I also would like to point you to Synplicity's Certify tool, which I am the
marketing director for.  Certify is a point tool specifically for
transforming a single chip ASIC RTL (Verilog or VHDL) into multiple FPGAs
for the purpose of prototyping, including prototype-level timing analysis
and synthesis.  You can check out Certify at our website
(http://www.synplicity.com).  If you contact me directly I can let you know
about other people inside Motorola who are using Certify
(johng@synplicity.com).

Cheers,
John

John Fielden <john.fielden@abcmotorola.com> wrote in message
news:8ffcfm$e9r$1@schbbs.mot.com...
> I need a multi FPGA board to do ASIC verification.  So far, I've looked at
> WildStar (by Annapolis Micro) and RSPE (by Viasat).
>
> Can anyone reccomend another board I should look at?
>
> Thanks,
>
> John
>
>


Article: 22593
Subject: Re: Do you know xilinx FPGAs well?
From: eml@riverside-machines.com.NOSPAM
Date: Fri, 12 May 2000 20:55:59 GMT
Links: << >>  << T >>  << A >>
On Fri, 12 May 2000 14:26:39 GMT, Ray Andraka <ray@andraka.com> wrote:

>> After some initial study, i think that Virtex could give me solution.
>> There is also an A/D converter(which i might need) in the Virtex and
>> such a large memory could only be implemented in an Virtex.
>
>The A/D is news to me, unless you want to build a delta-sigma converter.

Xilinx has been recruiting mixed-signal ASIC people for a long time -
possibly an announcement on the way?

Evan

Article: 22594
Subject: Re: OT ANNOUNCE: Embedded Systems Glossary and Bibliography
From: Jerry Avins <jya@ieee.org>
Date: Fri, 12 May 2000 17:29:44 -0400
Links: << >>  << T >>  << A >>
Was it always written so, or only when it represented the Dutch ij
combination? I believe that I remember that Hilda Conrady Kingslake, in
a biography of her father, implied that y-cum-umlaut was common only in
words and names originally Dutch. Maybe I remember wrong. (I had a
colleague at RCA whose name was Miiller. He said that the family name
was originally Müller, but that some ignoramus at Ellis Island had read
it wrong.)

Jerry
-- 
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Herman wrote:
> 
> In bygone days, the letter 'y' was written with an umlaut (German -
> don't know the English for that one) which is two dots on the 'y', which
> makes it look almost exactly like 'ij', and these characters were in
> fact equivalent.
> 
> Jerry Avins wrote:
> >
> > Johan Kwisthout wrote:
> > >
> > >  ...
> > >
> > > It's Dijkstra (turn the i and j the other way around).   ...
> > >
> > > >>Johan.
> >
> > I remember the order because it looks like the letter "y" (with two
> > tittles) in script. The great British (later, US) optical designer
> > Conrady was born Conradij in The Netherlands.
> >
> > Jerry
Article: 22595
Subject: foundation
From: "Frank Van de Sande" <fvds12@yahoo.com>
Date: Fri, 12 May 2000 21:35:11 GMT
Links: << >>  << T >>  << A >>
hello,

just installed xilinx foundation tool...

when i do a vhdl syntax check, no error report is generated, although there
are errors ...


Any idea what the problem might be?

thank you

fvds12@yahoo.com


Article: 22596
Subject: Cheap Quicklogic parts....
From: oleg@writeme.com
Date: Fri, 12 May 2000 21:54:26 GMT
Links: << >>  << T >>  << A >>
For my school project I need a few (5-10) ql16x24b-()pl84() parts.
Does anybody know where I can buy those?  I used WebASIC program,
but I need to have a few blank parts.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22597
Subject: Re: pipeline shiftreg in virtex
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 12 May 2000 23:17:50 +0100
Links: << >>  << T >>  << A >>

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



Ray Andraka wrote:

> William,
>
> I forgot to mention, there is a second way to keep it as registers without monkeying
> with the reset:  You can use the syn_keep attribute on the intermediate signals to
> keep them from being collapsed into an SRL16.  For example a 10 clock pipeline:
>

Only for us sensible people using Synplify. Do FPGA Express/Compiler & Spectrum have
equivalent option flags ?


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Ray Andraka wrote:
<blockquote TYPE=CITE>William,
<p>I forgot to mention, there is a second way to keep it as registers without
monkeying
<br>with the reset:&nbsp; You can use the syn_keep attribute on the intermediate
signals to
<br>keep them from being collapsed into an SRL16.&nbsp; For example a 10
clock pipeline:
<br><a href="http://www.fpga-guru.com"></a>&nbsp;</blockquote>
Only for us sensible people using Synplify. Do FPGA Express/Compiler &amp;
Spectrum have equivalent option flags ?
<br>&nbsp;</html>

--------------76A992EE203403ECE7446D70--

Article: 22598
Subject: Re: OT ANNOUNCE: Embedded Systems Glossary and Bibliography
From: albaugh@agames.com (Mike Albaugh)
Date: 12 May 2000 22:36:23 GMT
Links: << >>  << T >>  << A >>
(Note trimmed followups. This doesn't even belong there, except for
the amount of stress-relief it seems to be giving us... :-)

Jerry Avins (jya@ieee.org) wrote:
: Was it always written so, or only when it represented the Dutch ij
: combination? I believe that I remember that Hilda Conrady Kingslake, in
: a biography of her father, implied that y-cum-umlaut was common only in
: words and names originally Dutch. Maybe I remember wrong. (I had a
: colleague at RCA whose name was Miiller. He said that the family name
: was originally Müller, but that some ignoramus at Ellis Island had read
: it wrong.)

	Is it not possible that the whole "y-umlaut" issue is the result
of someone mistaking a _ligature_ for a _letter_? Printers often use
ligatures (composite characters representing commonly occuring digraphs
and trigraphs such as 'ff', 'ffl', etc.) An 'ij' ligature could look
an awful lot like a y-umlaut to someone who was making up the PC
character-set and had a few too many Cuba-Libre's at lunch... :-)
( I speak neither German nor Dutch, despite having ancestors from
both, but I have never seen a "y-umlaut" that _wasn't_ a stand-in
for 'ij' ) Compare and contrast to my Japanese teacher whose name
could no longer be properly spelled because 'ye' had been dropped
from the official hiragana :-)

					Mike
: Jerry
: -- 
: Engineering is the art of making what you want from things you can get.
: -----------------------------------------------------------------------
: Herman wrote:
: > 
: > In bygone days, the letter 'y' was written with an umlaut (German -
: > don't know the English for that one) which is two dots on the 'y', which
: > makes it look almost exactly like 'ij', and these characters were in
: > fact equivalent.


							Mike

Article: 22599
Subject: Re: CLKing external RAM from FPGA (Virtex E)
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 12 May 2000 19:18:18 -0400
Links: << >>  << T >>  << A >>
I am not sure that I understand your clocking scheme as it is difficult
to describe clearly. But it sounds like you are trying to generate a
clock inside the FPGA and use the DLL to compensate for the delay
getting the clock off of the chip and distributing it around the board. 

I am not sure, but I don't think the FPGA DLL is designed for that. My
understanding of how it is intended to be used is to synchronize the
clock inside the chip to one coming in from the outside. This is roughly
opposite to how you are trying to do it, but unless you have some really
long board traces it should work for you. 

If you have trouble with the clock delays in the traces on your board,
you should add a multioutput PLL clock chip to the board so that a
separate output feeds each chip clock pin. Keep all of the clock traces
on the board the same length. This will minimize the clock skew on the
board. Then use the FPGA DLL to minimize the clock skew between the
board clock and the internal clock in the FPGA. That should take care of
your skew problems. 


Tom McLaughlin wrote:
> 
> All,
> We have 4 SRAMs hanging a Xilinx VirtexE 1000.  We are investigating how
> to clock them.  One possible solution gets DRC errors when we run
> through the tools and we don't understand why.
> 
> Here is the scenario.  We want to use a DLL to generate the clock, send
> the output of the DLL to a BUFG, and then the output of the BUFG to
> multiple OBUFs.  These would be the clocks for the SRAMs.  The feedback
> to the DLL, the CLKFB pin, would come back in from outside the chip, to
> an IBUFG, and then to the CLKBF pin of the DLL.  This all works fine and
> is standard if we only send the output of the BUFG to "ONE" OBUF, but if
> we try to fan this out to multiple OBUFs it doesn't work....we get DRC
> errors......why.  Also, if we use internal feedback, instead of going
> offchip, we can send the output of the BUFG to multiple OBUFs.  I know
> this feedback is worthless, but we tried it just for the heck of it.
> 
> Separatly, we can send the output of a BUFG to multiple OBUFs, and the
> output of a DLL can go to the input of a BUFG.  Put these together and
> you get DRC errors.
> 
> I understand that the feedback is supposed to be a delay compensator for
> your outside path and the DLL uses this to adjust the outgoing clock.
> If we assume that the outside traces and loads for these different
> clocks are the same (designed that way), then we should be able to take
> the feedback from one of these and hook it to CLKFB, but again, it
> doesn't work.
> 
> Also, as we haven't gotten this through the tools, we don't know what
> the skew would be between the different OBUFs.  We were assuming since
> the OBUFs are fed by the BUFG, there would be very little skew???
> 
> Any thoughts.  If someone has designed a bank of 4 SRAMs off of a single
> FPGA it would be very helpful to see your sceme...both on the FPGA and
> at the board level.
> 
> We are investigating other ways of doing this, but would like to
> understand why this doesn't work.
> 
> Her is the error we get......anyone know how to get around the DRC error
> and how bad of an idea this is????  Probably not a good one.
> 
> ERROR:DesignRules:365 - Blockcheck: Improper DLL feedback loop. Signal
> wclk100 is driving pin IN of comp bufg1.  Since pin CLKFB of DLL clkdll2
> is
> driving by an GCLKIOB, its output must drive the O pin of IOB.
> 
> Tom


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



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

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

Internet URL http://www.arius.com


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