1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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 18800

Article: 18800
Subject: Re: implementing TCP/IP on PLD
From: "David Emrich" <demrich@ihgtech.com.au>
Date: Wed, 17 Nov 1999 11:26:02 +0800
Links: << >>  << T >>  << A >>

> Yes and no.
> What you are trying to do is *very* difficult - to the extent that (AFAIK)
> only one manufacturer is vending TCP/IP on a chip with no legal strings
> attached, and that's a custom uP.
>
> Dirk
>
>
>

And who is that?

David.


Article: 18801
Subject: Re: implementing TCP/IP on PLD
From: "Dirk Bruere" <artemis@kbnet.co.uk>
Date: Wed, 17 Nov 1999 03:54:39 -0000
Links: << >>  << T >>  << A >>

David Emrich <demrich@ihgtech.com.au> wrote in message
news:newscache$e7oblf$1kk@gw.ihg.com...
>
> > Yes and no.
> > What you are trying to do is *very* difficult - to the extent that
(AFAIK)
> > only one manufacturer is vending TCP/IP on a chip with no legal strings
> > attached, and that's a custom uP.
> >
>
> And who is that?

Seiko.

Dirk


Article: 18802
Subject: Orcad 7.0 to Altera MAX?
From: Michal <michal@ERASEmytekdigital.com>
Date: Tue, 16 Nov 1999 20:01:07 -0800
Links: << >>  << T >>  << A >>
We are trying to import from OrCAD 7.0 to MAX+PLUS II a project
originally designed for Motorola MPA.

When we try importing a test project consisting only of standard 7400
gates
(going through  SDT386+ format) everything works fine.

Our project that includes primitives from MPA library can be imported to

MAX but these elements are ommitted even if we added translation to
orcad.lmf i and we have the right library *.lib.

What are we doing wrong?

Thanks for clues,

Michal


Article: 18803
Subject: Re: Q: implementing TCP/IP on PLD
From: edick@hotmail.com (Richard Erlacher)
Date: Wed, 17 Nov 1999 04:59:00 GMT
Links: << >>  << T >>  << A >>
On Wed, 17 Nov 1999 00:09:12 GMT, wavefront@SPAMbigfoot.com (martin
griffith) wrote:

>
>On 16 Nov 99 22:13:32 GMT, sujosep@ecf.toronto.edu (Joseph Su)
>scribbled:
>
>YE GODS THIS GUY HAS AN IEEE.ORG  (expletive deleted) ADDRESS: ( but he is from
>>fellow netters,
>>
>>as a part of our engineering design project, we need to investigate the
>>possibility of implementing TCP/IP on PLDs.
> PLD are VERY SMALL devices, 16R8 etc.they consume a vast amount of
>power , they may do it very quick, but they are power hungry, and you
>try working with PALASM!
>>relatively new to the
>>concept of TCP/IP and PLD, we hope that newsgroups may provide us with
>>some insightful hints and suggestions regarding the topic. the reason of
>>considering TCP/IP on PLD is in hope to concentrate RAM, PROM,
>If  you are still thinking of PROM technology, you are way out of
>date, try and get your money back from the course you are taking
>
>>and
>>microprocessor into one chip, and use such chip to perform simple and
>>speed demanding network applications.
>>
>>the questions raised are:
>>1. how does networking protocols implemented in network products, ie.
>>routers and bridges? do they use microcontrollers or PLDs?
>>2. what are the advantages of using microcontroller (plus RAM, PROM)
>>over PLD in dedicated network applications ? if there are any.
>An AVR/PIC type chip can run at say 10MIPS, are easy to programme.
>>3. if software on PROM can be upgraded via periodic firmware updates,
>>can it is also be done easily on PLD? ie. reprogram PLD on the spot.
>See AVR/ PIC
>>4. what is the minimum TCP/IP function set required to do simple file
>>transfer and etc.?
>a bit of research. not just asking "how do i do this", thats my line.
>>5. are there any resources available on this topic?
>>
>If you have to ask this question, you ought to get a job in Human
>(mis)Resources, maybe you've heard that people are very interested in
>the intenet.
>>we will welcome all comments and suggestions. please feel free to write
>>us at sujosep@ecf.toronto.edu. thank you all.
>>
>>--
>>Chao.
>>+-----------------------------------------------------------------------+
>>|       Email:  sujosep@ecf.toronto.edu         sujosep@ieee.org        |
>>|       Phone:  (905)507-1888                                           |
>>+-----------------------------------------------------------------------+
>>
>M'Lud, I rest my case, and sorry If I've hurt your feelings.
>
>>
>
>Martin
>
>
>
>
>
>
>
This guy thinks everybody lives by HIS definitions, I guess.  A PLD is
a Programmable Logic Device, including everything from a handful of
gates to Cypress' latest offering (4M gates?)  and, if you take it to
the limit, anything else that is any sort of logic device and
programmable, including, at least to some folk, FPGA's since they're
programmable and also logic devices.

Even the small ones are handy, since you can do the whole job in an
hour or two in PALASM, CUPL, ABEL, VHDL, take your pick, and there are
lots of others.  They make nice band-aids for the errors in your gate
array.

Generally, people distinguish between PLD's and PGA's in that PLD's
use the sum-of-products form together with well-defined (in both logic
and timing) macrocell architectures.  That's less true now than in
years past, but still tends to be the case.  CPLD's are "complex"
PLD's in that they are more or less like groups of bundled small
PLD's, e.g. 22V10's.

You can contact me via email if you really want to get me to wachs

However, it seems unlikely to benefit you as much from an extensive
investigation of programmable logic for this task until you
investigate the specific requirements.  Once you've defined all the
possible states, you will probably agree that TCP/IP, first of all
because it's more than one protocol, secondly because it's layered,
and thirdly because the signalling and data get to looking pretty
similar from layers which don't deal with them directly.

It's a task which is probably best suited for a mix of devices,
including an embedded controller, as you've been tasked to consider,
but probably much better suited to a processor like the AVR than for
one of the PIC's.

ATMEL, by the way, has a new FPGA available which contains one of
their AVR cores, so you can do what you have to in 'C' and let the HDL
handle what has to be handled outside the processor.  That's likely,
by the way, to be absolutely nothing.

There is a really marginal and stripped down TCP/IP for a PIC
somewhere on the Microchip site.

What I'd predict is that you can do this in a programmable logic
device(s) with an enormous effort and in a long time.  You can also do
this in a microcontroller, e.g. AVR 68HC302, whatever you like, for
about 10% of the cost for the FPGA development tools required to do
the  job.  What's more, if you take a quick look at the AVNET web
site, and check XILINX device prices, you'll see that a PC costs WAY
less than a high-end FPGA, so you might want to consider one of those

If you do the complete task analysis thoroughly enough BEFORE starting
on a potential design, you'll see that implementing the end product is
much simpler than you thought, whether you do it in programmable logic
or in a microcontroller.

Dick


Article: 18804
Subject: Re: How to connect a Xilinx Virtex FPGA to a TI DSP ?
Date: Tue, 16 Nov 1999 23:43:08 -0800
Links: << >>  << T >>  << A >>
L Horvath <laszlo.horvathNOlaSPAM@swipnet.se.invalid> wrote in message
news:000b8d9b.b08f0641@usw-ex0101-005.remarq.com...
> At work we have a Xilinx Virtex FPGA and a Texas Instruments
> TMS320C6202 DSP that are connected to each other.

Nice combination.  We were intending to build a board like this (although
with a 'C6211), but we ran short on time and went with the "PCI card with
Virtex plus single board Pentium PC" approach instead.

> The DSP communicates with the FPGA using the built in EMIF
> interface in asynchronous mode.  The clock frequency of the
> DSP is 200 MHz.  The FPGA has a clock frequency of 30 MHz.
>
> In the FPGA we have designed a block that clocks in the data,
> address and control signals from the DSP with the clock freq.
> of 60 MHz. ( The signals are down-converted to 30MHz in using a
> number of registers working with 60 MHz to 'strech out' the control
> signals and finally these signals are clocked out to the rest of the
> FPGA using 30MHz registers.
>
> Is there a better way to connect an FPGA to a DSP ?

Can your FPGA can accept data any faster than 30MHz at all?  Perhaps it does
some data processing and can accumulate results in a FIFO, or store input
data in a FIFO and then dole it out at that 30MHz?

If so, I'd make the FPGA look like SDRAM or SBSRAM to the DSP's EMIF and
interface to it that way.  As I recall, this will get you 100MHz (400MBps)
throughput during bursts, and the design is easy enough that it's well worth
doing if the extra 40MHz is going to buy you anything.

Crossing the clock boundaries this way occurs within the FIFOs, which are
one of those FPGA elements you hopefully have code for already (or can adapt
from application notes -- Xilinx does have good app notes for them), which
made their use for me preferable to designing Yet Another Asynchronous
Interface on an FPGA with some custom form of clock domain crossing.


Article: 18805
Subject: Re: Xilinx M2.1i SP2?
Date: Tue, 16 Nov 1999 23:50:51 -0800
Links: << >>  << T >>  << A >>
<dfrevele@li.net> wrote in message news:7vukch$ipu$1@nnrp1.deja.com...
> I am administrator for the engineering tools here and have installed
> this service pack on half a dozen NT machines with no problems like you
> describe. The only problem I encountered, which produced an error
> message, was due to an background process unexpectedly still running and
> locking the file so the installer could not overwrite it.

I believe this is documented; I know I've read about it before.  The
background process takes some 5 or 10 seconds to delete its temporary files
and allow you to run another service pack installatoin program.  You just
have to hurry up and wait...


Article: 18806
Subject: COM1-FPGA communication
From: Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid>
Date: Wed, 17 Nov 1999 03:10:41 -0800
Links: << >>  << T >>  << A >>
Hi friends,
I have implemented the UART in my FPGA. Now I whant to communicate with
com1 port of
my PC. (I have made also level conversion.) Only the problem that I
can't program PC. I do
not know Visual C++ and do not have old good turbo pascal. Do you have
where I could get it.
The program must only send symbol, I give, to COM1 and receive from Com1
when I whant.
Any help will be appreciated

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


Article: 18807
Subject: FPGA to ASIC conversion
From: John F Gostomski <no@spam.com>
Date: Wed, 17 Nov 1999 13:44:00 GMT
Links: << >>  << T >>  << A >>
We are looking at cost reducing a verilog rtl design which currently uses a
Xilinx Virtex XCV1000. The plan is to look at using conversion services from
either AMI, Temic or Chip Express.

One issue we have to deal with is that we have been using Synplify and do not
own a Synopsys Design Compiler seat.  So we are undecided on whether to do an
RTL handoff or lease a Design Compilier seat.  It will come down to cost,
available manpower, and confidence in the RTL handoff process (it may require
less manpower for us to synthesis ourselves rather than interface with the
vendor?).

If anyone has recently gone through a conversion with one of these vendors,
I would like to know how that experience went. If it is similiar to a
standard ASIC handoff, perhaps we will be better off dealing directly with
someone like OKI? Can these vendors add alot of value in areas like test
vectors, DLL conversion, Virtex blockram conversion?

Thanks,
John Gostomski


Article: 18808
Subject: viewing fpga config
From: James Birmingham <shu96jb@rdg.ac.uk>
Date: Wed, 17 Nov 1999 14:28:31 +0000
Links: << >>  << T >>  << A >>

Does anybody know of any software which can read the configuration from a
Xilinx fpga (xc6216) and display it graphically?

Else some software that can read a .cal file and display that
graphically or convert to another useable format?

Can Xchecker be used for this?

Any help is much appreciated :)

jim


Article: 18809
Subject: Re: implementing TCP/IP on PLD
From: "Austin Franklin" <austin@darkr99oom.com>
Date: 17 Nov 1999 15:32:01 GMT
Links: << >>  << T >>  << A >>
Already been done on a PIC (and many other small micros).  Do some web
searching.  Try a product called "WebFerret" available from
www.ferretsoft.com for a great web search program, there are both free and
commercial versions available.

You can not implement a TCP/IP stack in just a PLD, there simply aren't
enough gates, so you must not mean PLD, but something else...possibly
microprocessor, FPGA.

Joseph Su <sujosep@ecf.toronto.edu> wrote in article
<3831D70A.90CDD0A2@ecf.toronto.edu>...
> fellow netters,
>
> as a part of our engineering design project, we need to investigate the
> possibility of implementing TCP/IP on PLDs. relatively new to the
> concept of TCP/IP and PLD, we hope that newsgroups may provide us with
> some insightful hints and suggestions regarding the topic. the reason of
> considering TCP/IP on PLD is in hope to concentrate RAM, PROM, and
> microprocessor into one chip, and use such chip to perform simple and
> speed demanding network applications.
>
> the questions raised are:
> 1. how does networking protocols implemented in network products, ie.
> routers and bridges? do they use microcontrollers or PLDs?
> 2. what are the advantages of using microcontroller (plus RAM, PROM)
> over PLD in dedicated network applications ? if there are any.
> 3. if software on PROM can be upgraded via periodic firmware updates,
> can it is also be done easily on PLD? ie. reprogram PLD on the spot.
> 4. what is the minimum TCP/IP function set required to do simple file
> transfer and etc.?
> 5. are there any resources available on this topic?
>
> we will welcome all comments and suggestions. please feel free to write
> us at sujosep@ecf.toronto.edu. thank you all.
>
> --
> Chao.
> +-----------------------------------------------------------------------+
> |       Email:  sujosep@ecf.toronto.edu         sujosep@ieee.org        |
> |       Phone:  (905)507-1888                                           |
> +-----------------------------------------------------------------------+
>
>
>
>

Article: 18810
Subject: Re: implementing TCP/IP on PLD
From: "Austin Franklin" <austin@darkr99oom.com>
Date: 17 Nov 1999 15:40:02 GMT
Links: << >>  << T >>  << A >>
> Forget 'simple' with a TCP/IP stack.
> The simplest would be using datagrams (UDP protocol), which you might be
> able to squeeze into about 1k of uP code if you are skilful. Full
> implementations you are talking about 25K+ of code on a fast uP.

One of the PIC implementation I have seen is only 512 'bytes' of code.

> What you are trying to do is *very* difficult - to the extent that
(AFAIK)
> only one manufacturer is vending TCP/IP on a chip with no legal strings
> attached, and that's a custom uP.

Most micros (PIC/8051 etc) have TCP/IP stacks freely available.  Also,
there are a number of embedded chips that have TCP/IP stacks ON them that
are available now.  It's just not THAT difficult...but I guess it depends
on what you think is difficult...


Article: 18811
Subject: Re: Q: implementing TCP/IP on PLD
From: ryan@oscsystems.com (ken ryan)
Date: 17 Nov 1999 16:35:02 GMT
Links: << >>  << T >>  << A >>
Joseph Su (sujosep@ecf.toronto.edu) wrote:
: fellow netters,

: as a part of our engineering design project, we need to investigate the
: possibility of implementing TCP/IP on PLDs. relatively new to the

Seiko makes a tiny chip that implements a basic TCP/IP stack (the S7600).
Check out http://www.mycal.net/wsweb/ for info including a board about 1/2
the size of a business card that uses the S7600 and a PIC to make a tiny
webserver.  The chip also includes PPP/PAP for serial comms.

ken

--
Kenneth Ryan
Principal Engineer		ryan@oscsystems.com	M/S: E-15
Orbital Sciences Corp.          (301) 353-1714          20301 Century Blvd.
/ Fairchild Defense          FAX:     -8679          Germantown, MD 20874

Article: 18812
Subject: Foundation configuration
From: Steven Derrien <sderrien@irisa.fr>
Date: Wed, 17 Nov 1999 17:46:35 +0100
Links: << >>  << T >>  << A >>
Hi,

I'm having trouble using Foundation Series 2.1i for Xilinx on my NT box.

After installation, I have the following message from the project
manager :

Lmacs : The Record Manager or Requester is inactive
Lmacs : The Record Manager or Requester is inactive
Lmacs : Btrieve B_VERSION return status '20'
Pcm : Library directory access error

Dpm : No such feature exist
Pcm : Cannot find a valid license for Synopsys synthesis

variable is set accordingly and the PATH and XILINX variables are also
OK...

I've been looking on the documentation provided with the tool and pn
Xilinx WebSite, but I could not found anything related to that ...

Steven


Article: 18813
Subject: Re: implementing TCP/IP on PLD
From: Jamie Lokier <spamfilter.nov1999@tantalophile.demon.co.uk>
Date: 17 Nov 1999 18:14:29 +0100
Links: << >>  << T >>  << A >>
Austin Franklin writes:
> You can not implement a TCP/IP stack in just a PLD, there simply aren't
> enough gates, so you must not mean PLD, but something else...possibly
> microprocessor, FPGA.

I heard it's been done on an FPGA, and not an especially large one either.

-- Jamie

Article: 18814
Subject: Re: COM1-FPGA communication
From: "Carlhermann Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Wed, 17 Nov 1999 19:45:04 +0100
Links: << >>  << T >>  << A >>
Hi Bonio,

Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid> schrieb in im Newsbeitrag:
0a0133f8.7b6c1031@usw-ex0102-009.remarq.com...
> Hi friends,
> I have implemented the UART in my FPGA. Now I whant to communicate with
> com1 port of
> my PC. (I have made also level conversion.) Only the problem that I
> can't program PC. I do
> not know Visual C++ and do not have old good turbo pascal. Do you have
> such program or any links,
> where I could get it.
> The program must only send symbol, I give, to COM1 and receive from Com1
> when I whant.
> Any help will be appreciated
>

If you just have to send a ASCII symbol, why not use the "build-in" Terminal
programm (e.g. Hyperterminal @ WIN) ?
I programmed similar things with a Servocontroller for internal use (ALTERA
FPGA + MAX232) and managed whole communication using Hyperterminal.

B4N, Carlhermann


Article: 18815
Subject: Why not Lucent ORCA FGPAs?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 17 Nov 1999 14:06:37 -0500
Links: << >>  << T >>  << A >>
I have picked the Lucent ORCA FPGAs for the board I am currently
building due to IO count, part cost and support. I have noticed that
there are not many people discussing these devices in this newsgroup,
which I assume is because there are not a lot of people using them. Can
I ask why Xilinx parts are preferred over the Lucent devices? Other than
inertia, why did you pick the Xilinx devices?

--

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

Article: 18816
Subject: Re: COM1-FPGA communication
From: John Larkin <jjlarkin@highlandtechnologySnipThis.com>
Date: Wed, 17 Nov 1999 11:22:12 -0800
Links: << >>  << T >>  << A >>
On Wed, 17 Nov 1999 03:10:41 -0800, Bonio Lopez
<bonio.lopezNOboSPAM@gmx.ch.invalid> wrote:

>Hi friends,
>I have implemented the UART in my FPGA. Now I whant to communicate with
>com1 port of
>my PC. (I have made also level conversion.) Only the problem that I
>can't program PC. I do
>not know Visual C++ and do not have old good turbo pascal. Do you have
>where I could get it.
>The program must only send symbol, I give, to COM1 and receive from Com1
>when I whant.
>Any help will be appreciated
>
>
>
>* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
>The fastest and easiest way to search and participate in Usenet - Free!

Hi,

we do stuff like that in PowerBasic, in a dos box. It's about 100 times easier
and faster than fighting Windows.

John


Article: 18817
Subject: Re: COM1-FPGA communication
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 17 Nov 1999 13:16:59 -0700
Links: << >>  << T >>  << A >>
Bonio Lopez wrote in message
<0a0133f8.7b6c1031@usw-ex0102-009.remarq.com>...
>Hi friends,
>I have implemented the UART in my FPGA. Now I whant to communicate with
>com1 port of
>my PC. (I have made also level conversion.) Only the problem that I
>can't program PC. I do
>not know Visual C++ and do not have old good turbo pascal. Do you have
>where I could get it.
>The program must only send symbol, I give, to COM1 and receive from Com1
>when I whant.
>Any help will be appreciated

Why not use the windows Hyperterminal program (it comes with 95/98 and NT)?
It can send and receive files and text that you type in.

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.


Article: 18818
Subject: Re: implementing TCP/IP on PLD
From: sujosep@ecf.toronto.edu (Joseph Su)
Date: 17 Nov 99 20:47:42 GMT
Links: << >>  << T >>  << A >>
Jamie Lokier wrote:

> I heard it's been done on an FPGA, and not an especially large one either.
>
> -- Jamie

Can you recall the source of your inofrmation? Appreciated.

--
Chao.
+-----------------------------------------------------------------------+
|       Email:  sujosep@ecf.toronto.edu         sujosep@ieee.org        |
|       Phone:  (905)507-1888                                           |
+-----------------------------------------------------------------------+


Article: 18819
Subject: Re: implementing TCP/IP on PLD
From: sujosep@ecf.toronto.edu (Joseph Su)
Date: 17 Nov 99 21:04:10 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:

> Already been done on a PIC (and many other small micros).  Do some web
> searching.  Try a product called "WebFerret" available from
> www.ferretsoft.com for a great web search program, there are both free and
> commercial versions available.
>
> You can not implement a TCP/IP stack in just a PLD, there simply aren't
> enough gates, so you must not mean PLD, but something else...possibly
> microprocessor, FPGA.

My apologies for using the term "PLD" in the original post. It seems that
everybody who responded to the post interpretate it differently (except Dick
Erlacher) as I do.

I took Altera's definition of "PLD", since that is what Altera is referring to
all its products. Altera is appearantly our only resource on PLD/PGA as it is
being used at school.

I sure will try the search engine you mentioned. Thanks.

--
Chao.
+-----------------------------------------------------------------------+
|       Email:  sujosep@ecf.toronto.edu         sujosep@ieee.org        |
|       Phone:  (905)507-1888                                           |
+-----------------------------------------------------------------------+


Article: 18820
Subject: Re: implementing TCP/IP on PLD
From: "Dirk Bruere" <artemis@kbnet.co.uk>
Date: Wed, 17 Nov 1999 21:12:19 -0000
Links: << >>  << T >>  << A >>

Jamie Lokier <spamfilter.nov1999@tantalophile.demon.co.uk> wrote in message
news:m2ogctdoqy.fsf@pcep-jamie.cern.ch...
> Austin Franklin writes:
> > You can not implement a TCP/IP stack in just a PLD, there simply aren't
> > enough gates, so you must not mean PLD, but something else...possibly
> > microprocessor, FPGA.
>
> I heard it's been done on an FPGA, and not an especially large one either.

Not without a CPU core, AFAIK.

Dirk


Article: 18821
Subject: Re: implementing TCP/IP on PLD
From: "Dirk Bruere" <artemis@kbnet.co.uk>
Date: Wed, 17 Nov 1999 21:22:59 -0000
Links: << >>  << T >>  << A >>

Austin Franklin <austin@darkr99oom.com> wrote in message
news:01bf3112$9f49ced0$207079c0@drt1...

> > What you are trying to do is *very* difficult - to the extent that
> (AFAIK)
> > only one manufacturer is vending TCP/IP on a chip with no legal strings
> > attached, and that's a custom uP.

> Most micros (PIC/8051 etc) have TCP/IP stacks freely available.  Also,

Free bugs, and no guarantees as well.

> there are a number of embedded chips that have TCP/IP stacks ON them that
> are available now.  It's just not THAT difficult...but I guess it depends
> on what you think is difficult...

As of April 99 I did a search for free stuff, cheap stuff, single chips sold
with TCP/IP etc and found nothing usable or cost effective for a commercial
product. Plenty of promises of 'soon' and lots of vapourware. In the end we
bought a US Software stack for $7500 and I ported it to a 186ES. Makes you wonder how they can get away with charging all that money:-) Anyway, when it comes to promises I hear that an updated Z80 running at 80MHz and 1 inst per cycle (old code compatible) will have TCP/IP on-board. For really hot vapour check: http://www.zilog.com/about/releases/092099.html Dirk  Article: 18822 Subject: Re: Why not Lucent ORCA FGPAs? From: Rickman <spamgoeshere4@yahoo.com> Date: Wed, 17 Nov 1999 16:46:53 -0500 Links: << >> << T >> << A >> The message I am replying to was received by email, so just in case there is a privacy issue, I am removing the sender's name. My preference is to discuss this publicly as much as people wish to. I agree that in the past the support both before and after the sale has not been stellar from Lucent. But I would never have considered the Lucent parts except for an exceptional FAE from Marshall who gave it the hard sale, got me a free set of tools, a really good price on the chips and has followed up with support (most of the time). Unfortunately, Marshall has been bought by Avnet and will be losing the Lucent product line. However the FAE has gone to a new company, Impact, and will be selling the Lucent parts still. So I am currently a happy camper. I don't believe that Lucent is not intelligent enough to understand the contradiction of "high volume FGPAs". But I believe they have targeted their sales to high volume users, which typically means a company that pumps out a large number of designs. As you point out, it is a rare application (but not unheard of) that uses FPGAs in very large volumes. The one big advantage of FPGAs is the ability to be a different ASIC as your needs change, even in real time! In fact the last design I did used the FPGA exactly that way. It held four different designs depending on whether you were recording, playing, or performing two different types of selftest. This would have been a much more complex design to try to put all that into a single ASIC and would not have been able to perform the selftest as thoroughly as the FPGA did due to clocking issues. But now a small volume user can get the same level of support from Lucent and distribution as they can with Xilinx chips. Certainly this is indicated by the pricing I received for quantity 40 parts. I guess I was expecting people to have concerns about the architecture or other technical issues, or just want to stick with what they are familiar with. At 04:20 PM 11/17/99 , XXX wrote: >Hello Rick > >Momentum is a compelling reason. But where is the momentum coming >from? >My opinion is that the Lucent sales strategy is what is limiting >the success of these ORCA parts. Lucent sales is very focused on extremely >large opportunities. SO you will likely get no field support from sales >if your opportunity is not worth at least 1mill. >And most FPGA opps out there are not high volume (otherwise they will >likely be an ASIC opp). That is why I believe the ORCA parts are >not doing as well as they should. >Let me know what you think about that. > >Rickman wrote: > >> I have picked the Lucent ORCA FPGAs for the board I am currently >> building due to IO count, part cost and support. I have noticed that >> there are not many people discussing these devices in this newsgroup, >> which I assume is because there are not a lot of people using them. Can >> I ask why Xilinx parts are preferred over the Lucent devices? Other than >> inertia, why did you pick the Xilinx devices? >> >> -- >> >> 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 -- 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  Article: 18823 Subject: Actel FPGA prices From: johne@vcd.hp.com (John Eaton) Date: 17 Nov 1999 22:11:03 GMT Links: << >> << T >> << A >> I recently received a mailing from uniqueTechnologies touting the actel sx family over the Altera 7128. One of the points of comparison was price and they listed prices "as low as"$3.90 or $6.90 for the 54sx08,54sx16 actel parts. I then pop open the arrow distributer web page and do a search on those parts and the lowest numbers are about$61 and \$88. Thats 2 orders of
magnitude difference.

Wheres the best place to buy actel parts in quanities of 1-2 hundred
pieces.

John Eaton


Article: 18824
Subject: Re: FPGA to ASIC conversion
From: Jason.Wright@ericsson. (Jason T. Wright)
Date: Thu, 18 Nov 1999 01:20:43 GMT
Links: << >>  << T >>  << A >>
We used AMI last year to convert a Xilinx 4k series device to an asic, and
the process was fairly smooth.  The source design was in VHDL, synthesized
to a 4k part with Synopsys' FPGA Comiler.  We provided XNF files (EDIF
should work as well) and simulation test vectors.  I had used Xilinx's
Logiblox tool to generate the rams (no XNF files for this--Xilinx produced
ngc and ngo files, as well as behavioral models in verilog or VHDL), and
provided the behavioral models to AMI so they could generate their own with
their RAM compiler.

Orbit Semiconductor (I mention them because they were aggressively seeking
this kind of business), along with several other companies, does
conversions also.  Some vendors will require test vectors; some want some;
some don't require any.  It depends on your confidence in your design and
if you will have boundary and internal scan capabilities.

Jason T. Wright

On Wed, 17 Nov 1999 13:44:00 GMT, John F Gostomski <no@spam.com> wrote:

>We are looking at cost reducing a verilog rtl design which currently uses a
>Xilinx Virtex XCV1000. The plan is to look at using conversion services from
>either AMI, Temic or Chip Express.
>
>One issue we have to deal with is that we have been using Synplify and do not
>own a Synopsys Design Compiler seat.  So we are undecided on whether to do an
>RTL handoff or lease a Design Compilier seat.  It will come down to cost,
>available manpower, and confidence in the RTL handoff process (it may require
>less manpower for us to synthesis ourselves rather than interface with the
>vendor?).
>
>If anyone has recently gone through a conversion with one of these vendors,
>I would like to know how that experience went. If it is similiar to a
>standard ASIC handoff, perhaps we will be better off dealing directly with
>someone like OKI? Can these vendors add alot of value in areas like test
>vectors, DLL conversion, Virtex blockram conversion?
>
>Thanks,
>John Gostomski
>