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 19125

Article: 19125
Subject: Re: Xilinx FPGA Editor guessing games solved!
From: Ray Andraka <randraka@ids.net>
Date: Tue, 30 Nov 1999 18:03:04 -0500
Links: << >>  << T >>  << A >>
In Peter's defense, The software is not his, nor is it his area of expertise.
No, I'm not defending the software.  In my opinion, they still haven't gotten
back the utility and robustness of the old XACT6 software.  Pity, seeing that it
has been been nearly 2 years since M1 was released.  The Virtex side is still
not really ready for prime time.  I've personally found and reported 2
show-stopper bugs in the last week and a half.

Steve Dewey wrote:

> Isn't it interesting that Peter Alkfe, who regularly gives advice and
> explains the reasoning behind certain xylinx decisions always goes very
> quiet when there is a discussion that highlights the shortcomings of the
> software xylinx sells ?
>
>     In article <01bf395a$df27ca70$207079c0@drt1>, Austin Franklin
> <austin@darkroom098.com> writes
> >> I would guess by the tone of your message that you are pretty frustrated
> >> over this.
> >
> >Frustrated?  HA!  That's an understatement!
> >
> >And they ask me the most STUPID question they can possibly every ask "Why
> >do you want to use that tool anyway?...NO ONE uses it".  DAMN does that
> >piss me off.  I need to use THAT tool because with it, I can fill in the
> >blanks that THEIR documentation leaves out...like what is the best IOB to
> >use for the RESET input, where the hell IS the upper right and left corner
> >of the die, with relation to the package...and just WHAT did the tools do
> >to my logic?
> >
> >These, and many other questions can be answered with this tool...but their
> >attitude is, "hey, the OTHER tools work just fine, so you don't really need
> >that tool, Oh, and by the way, NO ONE uses it anyway"...GRRRRRRRR.
> >
>
> --
> Steve Dewey
> remove 123 to email.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19126
Subject: Here are the BEST and MOST IMPORTANT books on VHDL
From: "Rune Baeverrud" <fpga@iname.com>
Date: Tue, 30 Nov 1999 23:37:06 GMT
Links: << >>  << T >>  << A >>
If you are like me - you really don't have a lot of time trying to figure
out which books to buy. Cost is not that important. You only want to get the
best literature without wasting valuable time.

So - you want to learn VHDL from a book? It's easy. Go to Amazon.com and
search for the VHDL title word, and you will end up with 100+ hits or so.
Get ready to spend a lot of time trying to figure out which one to get. The
good thing at Amazon.com is that they allow their customers to leave a short
review of the book, which can be very useful info for those who come after.
Then - you can search for the individual titles on the Internet, and soon
you will have reduced the number of really interesting titles to 10 or so.

You are in luck today. I just did this job for you. I've spent a lot of time
searching for the best VHDL books. I have not read all of them myself, but
all of these books have been receiving great reviews from users.

To make it really easy for you, I have also for each book provided:

- A direct link to the book's "homepage" at it's publisher's website.
- 4 scripts which will start a search for the lowest price on most online
book stores.
- A direct link to the Customer Reviews at Amazon.com.

If you have any suggestions for new additions, please send me an email. If
you would like to review a book, I suggest you do that at the Amazon.com
website - that would be very convenient for all of us!

My report can be found at http://freecore.com

Rune Baeverrud, November 1999


Article: 19127
Subject: Re: FPGA vs DSP vs PENTIUM MMX
From: "George" <g_roberts75@hotmail.com>
Date: Wed, 1 Dec 1999 00:07:49 -0000
Links: << >>  << T >>  << A >>
When I talked about Pentium MMX, I meant the use of MMX instruction set to
speed up multimedia operations. After all, that's what MMX technology is all
about. It uses SIMD (Single Instruction Mutiple Data) - or pipelining-
technique to process data in parallel. 8 MACs can be performed in one cycle.
As Steven kindly showed, A 500MHz PIII MMX may outperform FPGAs for 3x3
convolutions and I guess for many other small algorithms. I know that when
the parallelism granularity gets bigger, there is nothing better than a
dedicated hardware solution, but still for many applications, a GPP may do
the job if well programmed. Though, MMX is programmed in assembly, it offers
the SW flexibility. Concerning the power consumption, that's a fair point
for FPGAs against GPP, but for ordinary PC users, who cares !! Most PC users
do not care about it. After all, they will not use their PCs as image
processors 24 hours a day. It is the speed they are asking for, in addition
to the ease of use. It is nice to use FPGAs when you have the necessary
support and $$$, but for most people, they stuck in front of a buggy silicon
compiler or a rigid piece of hardware.
I agree entirely with Steven about the communication overheads issue.
Often, the performance is slow down by the lack of fast and flexible onboard
memory, and you cannot do much about it, unless you design your own board
($$$).
Frankly, most people would prefer using their general purpose Pentium
processors, with a nice GUI debugger (if it can do the job of course) rather
than buying an expensive FPGA board and spending weeks if not months
struggling with the tools to make ends meet.
I presume it depends on  the problem you have in hand, I think that people
should  first consider flexible SW solutions before going any further, and
not exlude them from the beginning even for computationaly intensive
algorithms such as DSP.




Article: 19128
Subject: Re: FPGA vs DSP vs PENTIUM MMX
From: Steven Derrien <sderrien@irisa.fr>
Date: Wed, 01 Dec 1999 12:37:33 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> Basically what I was trying to say.  Given enough local memory and the bandwidth (pins) to access it, an FPGA can do
> the processing at the video frame rate, as demonstrated in numerous systems, including the one described in my 1996
> paper " A Dynamic Hardware Video Processing Platform " which did image recognition processing at the frame rate
> using a tiled array of 4 chips similar to the Atmel AT6005s.

But the question is "Will it beat my PIII600 at it". and again for a 3x3 convolution, the answer is not necessary
positive. I'm not saying that FPGA cannot handle real-time constraints, i'm saying that we will not necessary perfeom
better than a good progammed CPU solution.

I think that people forgot the initial question that started this thread, which was "Can i beat an FPGA implementation
of a 2D 3x3 convoluiton with my PII600 "

>
> Arrigo Benedetti wrote:
>
> > Steven Derrien <sderrien@irisa.fr> writes:
> >
> >
> > Not necessarily: the image stream can "flow-through" the FPGA and be processed
> > on the fly.

Yeap. But this takes some time, and even with optimal data reuse, your excecution time will be bounded by the time it
requires for flushin the input and output imega in and out of  the fpga.

Steven

Article: 19129
Subject: Timing constraint not met
From: Nicolas Matringe <nicolas@dotcom.fr>
Date: Wed, 01 Dec 1999 16:37:26 +0100
Links: << >>  << T >>  << A >>
Hi all
I juste implemented a design in a Xilinx Virtex.
The clock constraint is 20ns period, 10ns high.
On one path, the total delay is (copied from the .log file):
Total (4.935ns logic, 5.885ns route)      10.820ns (to clk_BUFGPed)

The tool then tells me the minimum clock period is 21,640 ns (exactly
twice the delay)

Why does it want the delay to be less than half the clock period ? I
thought it needed to be less than the entire period.

Nicolas MATRINGE           DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
Fax 00 33 1 46 67 51 01    FRANCE
Article: 19130
Subject: Re: Timing constraint not met
From: Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid>
Date: Wed, 01 Dec 1999 07:50:59 -0800
Links: << >>  << T >>  << A >>
> Why does it want the delay to be less than half the clock period ?

Hi Nicolas,
 I think you  use in you design the rising and the falling edge of you
clock signal. That's why the
transition delay between the part  that clocked with  rising edge and 
the part that clocked with the
falling edge  of your clock signal must be less than half of your clock
delay.
Hope it is the answer on your question.
with best regards
Bonio




* 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: 19131
Subject: data serializer/decoder FPGA solution
From: "Manfred Kraus" <mkrausnews@cesys.com>
Date: Wed, 1 Dec 1999 17:01:56 +0100
Links: << >>  << T >>  << A >>
I have to transmit data using an optical link (100 MBd).
How can I serialize / encode and deserialize / decode
the data using an FPGA only (no analog solution, no CPU) ?
Are there any  pure digital solutions ?
The way RS232 transmission works is not practicable (would need at least
400 MHz sampling clock)

Where can I find descriptions of encoding technics.


--
Manfred Kraus
mkraus@cesys.com




--
Manfred Kraus



Article: 19132
Subject: Re: Timing constraint not met
From: Nicolas Matringe <nicolas@dotcom.fr>
Date: Wed, 01 Dec 1999 17:15:11 +0100
Links: << >>  << T >>  << A >>
Hi Bonio

Hey! I just checked and you were right!
I'm really confused... I NEVER use falling edges. Must be a stupid
misstype.
Thanks a lot :o)

Bonio Lopez wrote:
> 
> > Why does it want the delay to be less than half the clock period ?
> 
> Hi Nicolas,
>  I think you  use in you design the rising and the falling edge of you
> clock signal.
> Hope it is the answer on your question.
> with best regards
> Bonio


Nicolas MATRINGE           DotCom S.A.
Conception electronique    16 rue du Moulin des Bruyeres
Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
Fax 00 33 1 46 67 51 01    FRANCE
Article: 19133
Subject: Re: FPGA vs DSP vs PENTIUM MMX
From: Ray Andraka <randraka@ids.net>
Date: Wed, 01 Dec 1999 11:21:19 -0500
Links: << >>  << T >>  << A >>
Let's put it this way:  I can design the FPGA 2D 3x3 to run as fast as you can give me the data.  I am not bounded by
resources the way a microprocessor is, instead I am bound by I/O bandwidth (The processor is too), except that in a system
context, I can make my I/O arbitrarily wider to make up for I/O bandwidth limitations.

With a constraint of an identical system interface as the Pentium III, I can make the FPGA process a 3x3 at least as fast
as the Pentium, and probably faster since I have more of an opportunity for parallelism and my control overhead is not
handled by the same logic as my data path.  Most likely, you are doing more than just a 3x3 convolution in your
processing.  I can include that extra processing in the FPGA and not suffer a throughput hit (I may incur a latency hit,
but not throughput).  A microprocessor throughput will suffer as you add more tasks.

Steven Derrien wrote:

> Ray Andraka wrote:
>
> > Basically what I was trying to say.  Given enough local memory and the bandwidth (pins) to access it, an FPGA can do
> > the processing at the video frame rate, as demonstrated in numerous systems, including the one described in my 1996
> > paper " A Dynamic Hardware Video Processing Platform " which did image recognition processing at the frame rate
> > using a tiled array of 4 chips similar to the Atmel AT6005s.
>
> But the question is "Will it beat my PIII600 at it". and again for a 3x3 convolution, the answer is not necessary
> positive. I'm not saying that FPGA cannot handle real-time constraints, i'm saying that we will not necessary perfeom
> better than a good progammed CPU solution.
>
> I think that people forgot the initial question that started this thread, which was "Can i beat an FPGA implementation
> of a 2D 3x3 convoluiton with my PII600 "
>
> >
> > Arrigo Benedetti wrote:
> >
> > > Steven Derrien <sderrien@irisa.fr> writes:
> > >
> > >
> > > Not necessarily: the image stream can "flow-through" the FPGA and be processed
> > > on the fly.
>
> Yeap. But this takes some time, and even with optimal data reuse, your excecution time will be bounded by the time it
> requires for flushin the input and output imega in and out of  the fpga.
>
> Steven



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19134
Subject: Re: Timing constraint not met
From: Ray Andraka <randraka@ids.net>
Date: Wed, 01 Dec 1999 11:22:58 -0500
Links: << >>  << T >>  << A >>
I'll bet that you've got flip-flops clocked on both edges of the clock.
It's an easy mistake to make.

Nicolas Matringe wrote:

> Hi all
> I juste implemented a design in a Xilinx Virtex.
> The clock constraint is 20ns period, 10ns high.
> On one path, the total delay is (copied from the .log file):
> Total (4.935ns logic, 5.885ns route)      10.820ns (to clk_BUFGPed)
>
> The tool then tells me the minimum clock period is 21,640 ns (exactly
> twice the delay)
>
> Why does it want the delay to be less than half the clock period ? I
> thought it needed to be less than the entire period.
>
> Nicolas MATRINGE           DotCom S.A.
> Conception electronique    16 rue du Moulin des Bruyeres
> Tel 00 33 1 46 67 51 11    92400 COURBEVOIE
> Fax 00 33 1 46 67 51 01    FRANCE



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19135
Subject: Re: data serializer/decoder FPGA solution
From: Ray Andraka <randraka@ids.net>
Date: Wed, 01 Dec 1999 11:38:54 -0500
Links: << >>  << T >>  << A >>
What is the bit rate again?  I read that as 100 Megabaud, but without
knowing the length of the transmitted symbol that doesn't tell me the bit
rate.  With careful design you can run a small circuit in the FPGA at 400
MHz, but in this case the design would be difficult at best.

The design difficulty is in the receiver, not in the transmitter.  The
transmitter reduces to nothing more than an encoder (a polynomial
'scrambler' perhaps?) and a shift register clocked at the bit rate.

The easiest way would be to use a commercial ser/deser chip like the AMCC
8401/8501 to recover the data timing and deserialize it, then you can use my
descrambler/framer or scrambler core (see my website) to decode and frame
the data.  The trick is finding a ser/deser chipset designed for your data
rate.

RS232 UARTs generally oversample with a 16x clock, then look at the bit edge
positioning to find the most likely bit center, which it then uses to sample
the clock.  The 16x is required to allow for drift of the receive clock
relative to the transmit clock while still maintaining an acceptable margin
at the last bit.  If your receive and transmit clocks can be spec'd to a
tighter tolerance, you can reduce the oversampling ratio and perhaps make
the design easier.

Another option is to manchester encode the data.  At the receiver, the edges
have to be used to synchronize a clock, which can then be used to recover
the data.  You might find a clever way to use an on-board PLL or DLL to
generate a data clock from manchester encoding.  I haven't looked at that
possibility too closely yet.

Manfred Kraus wrote:

> I have to transmit data using an optical link (100 MBd).
> How can I serialize / encode and deserialize / decode
> the data using an FPGA only (no analog solution, no CPU) ?
> Are there any  pure digital solutions ?
> The way RS232 transmission works is not practicable (would need at least
> 400 MHz sampling clock)
>
> Where can I find descriptions of encoding technics.
>
> --
> Manfred Kraus
> mkraus@cesys.com
>
> --
> Manfred Kraus



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19136
Subject: Re: ALTERA EPC2 Configuration Help needed!
From: "Edwin Grigorian" <edwin.grigorian@jpl.nasa.gov>
Date: Wed, 1 Dec 1999 08:59:33 -0800
Links: << >>  << T >>  << A >>
I'm experiencing the same difficulty with the EPC2LC20 for programming of a
10K200E part.  I also get the 'Unrecognized device or socked empty' message
with MaxPlusII, ver. 9.30.  I would also be very interested to find out the
solution for amking this work.

Edwin Grigorian

"Volker Kalms" <ea0038@uni-wuppertal.de> wrote in message
news:383CBB4B.5D4D@uni-wuppertal.de...
> Hi all,
>
> Since a quarter of a year I discover the beatiful world of
> AHDL and VHDL. Until now everithing worked fine. But now I would
> be very grateful for a little help.
>
> Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured
> by Ing. Buero Lindmeier) in my hands. This evaluation board contains
> an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the
> ALTERA MAX+plusII (v 9.1) software......no problem to this point.
>
> Two weeks ago I purchased an configuration EPROM (EPC2LC20), which
> could optional plugged into my evaluation board.I set up the MAX plus
> JTAG chain due to the requirements (as far as I would say), performed
> an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus
> detected the additional device in the JTAG Chain.
> But when I try to Program the .pof file to the EPROM I get the message:
> Unrecognized device or socked empty.
>
>
> What am I doing wrong????? From my point of view I changed nearly every
> parameter in the MAX plus setup.
>
> I hope there is somebody out there, who could give me a hint how to get
> this EPROM configured.
>
>
> MANY THANKS IN ADVANCE!!!
>
> Best regards,
>
> Volker


Article: 19137
Subject: Re: FPGA vs DSP vs PENTIUM MMX
From: Steven Derrien <sderrien@irisa.fr>
Date: Wed, 01 Dec 1999 17:59:40 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> Let's put it this way:  I can design the FPGA 2D 3x3 to run as fast as you can give me the data.  I am not bounded by
> resources the way a microprocessor is, instead I am bound by I/O bandwidth (The processor is too), except that in a system
> context, I can make my I/O arbitrarily wider to make up for I/O bandwidth limitations.

I completely agree. However you sometime want to use your FPGA as coprocessor board for accelerating some computations, these
boards are usually in the form of a PCI based system
with some local memory. In this case (and this is the kind of system i was considering, which might explain our
misunderstanding) your I/O bandwidth at the system level is set by the PCI bus.(or whetever kind of bus you use)

> With a constraint of an identical system interface as the Pentium III, I can make the FPGA
> > process a 3x3 at least as fast as the Pentium, and probably faster since I have more of an  >opportunity for parallelism
and my control overhead is not handled by the same logic as my    > data path.

For such an app, I'd tend to think that even the PIII exhibits enough instruction level paralleslism and high enaough clock
speed compared to the memory so that its performance is limited by memory accesses (assuming no cache miss) rather than its
computationnal power.

Then perfromances for both implementation should be more or less the same.

>Most likely, you are doing more than just a 3x3 convolution in your

> processing.  I can include that extra processing in the FPGA and not suffer a throughput hit (I may incur a latency hit,
> but not throughput).  A microprocessor throughput will suffer as you add more tasks.

Right. So we need a good computation to communication ratio to get some good speed improvement from an FPGA implementation.

>
>
> Steven Derrien wrote:
>
> > Ray Andraka wrote:
> >
> > > Basically what I was trying to say.  Given enough local memory and the bandwidth (pins) to access it, an FPGA can do
> > > the processing at the video frame rate, as demonstrated in numerous systems, including the one described in my 1996
> > > paper " A Dynamic Hardware Video Processing Platform " which did image recognition processing at the frame rate
> > > using a tiled array of 4 chips similar to the Atmel AT6005s.
> >
> > But the question is "Will it beat my PIII600 at it". and again for a 3x3 convolution, the answer is not necessary
> > positive. I'm not saying that FPGA cannot handle real-time constraints, i'm saying that we will not necessary perfeom
> > better than a good progammed CPU solution.
> >
> > I think that people forgot the initial question that started this thread, which was "Can i beat an FPGA implementation
> > of a 2D 3x3 convoluiton with my PII600 "
> >
> > >
> > > Arrigo Benedetti wrote:
> > >
> > > > Steven Derrien <sderrien@irisa.fr> writes:
> > > >
> > > >
> > > > Not necessarily: the image stream can "flow-through" the FPGA and be processed
> > > > on the fly.
> >
> > Yeap. But this takes some time, and even with optimal data reuse, your excecution time will be bounded by the time it
> > requires for flushin the input and output imega in and out of  the fpga.
> >
> > Steven
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka

Article: 19138
Subject: Re: FPGA vs DSP vs PENTIUM MMX
From: "Joel Kolstad" <JKolstad@Electroglas.Com>
Date: Wed, 1 Dec 1999 12:00:24 -0800
Links: << >>  << T >>  << A >>
George <g_roberts75@hotmail.com> wrote in message
news:821p1o$adu$1@news.qub.ac.uk...
> As Steven kindly showed, A 500MHz PIII MMX may outperform FPGAs for 3x3
> convolutions and I guess for many other small algorithms.

Yes, and if one small algorithm is all you need to run (or at least all you
need to run the bulk of your data through), a GPP may be sufficient.

> I know that when
> the parallelism granularity gets bigger, there is nothing better than a
> dedicated hardware solution, but still for many applications, a GPP may do
> the job if well programmed.

Ever played a 3D game on your PC?  Look at the significant frame rate and
quality differences between a Pentium III-500 doing software rendering and
something like an nVidia GeForce 256 DDR chip using using its entire
pipeline (including the transform and lighting stages) for rendering.  I
think there's about an order of magnitude there.

The constraints of memory bandwidth that you mention are good ones.  A
GeForce 256 DDR has six times the memory bandwidth of a Pentium III-500
(150MHz clock, 128 bits wide, double data rate vs. 100MHz clock, 64 bits
wide).  Of course, with caching the Pentium III does a lot better than this,
but for very large data sets such as those found in image processing, you do
eventually have to look at the raw interface speed to memory.

> It is nice to use FPGAs when you have the necessary
> support and $$$, but for most people, they stuck in front of a buggy
silicon
> compiler or a rigid piece of hardware.

Who's "most people?"  The closest "most people" get to using very
sophisticated hardware data processing probably is when they play their 3D
games on their PC.  The subset of people who are hard-core PhotoShop users
probably have the money to pay for FPGA processing boards.

On the other hand, in order to build "most people" their inexpensive set-top
decoder boxes for their satellite dish receivers, somebody has to sit around
and design a hardware MPEG decoder (usually in an ASIC, but that's due to
the really high volumes possible for set-top boxes).  Although you can do
hardware MPEG decoding in real time at VGA resolutions on a Pentium III, the
price difference would be astronomical.  You won't see Dish Network or
DirectTV handing out Pentium III-based set-top decoders in return for a one
year subscription anytime soon.

In fact, have you tried out the software-only DVD players for PCs?  It's a
good way to suck up a very large percentage of a Pentium III's CPU time on a
system that costs one heck of a lot more than a $199 standalone DVD player,
but hey, if you weren't using your PC for anything else anyway, why not?

> Frankly, most people would prefer using their general purpose Pentium
> processors, with a nice GUI debugger (if it can do the job of course)
rather
> than buying an expensive FPGA board and spending weeks if not months
> struggling with the tools to make ends meet.

Although there's a lot of overlap, FPGAs, ASICs, DSPs, and GPPs each have
their own area that they accel in.  Overkilling a design is not quite as bad
as choosing an underpowered solution, but each is arguably not good design
technique.

> I presume it depends on  the problem you have in hand, I think that people
> should  first consider flexible SW solutions before going any further, and
> not exlude them from the beginning even for computationaly intensive
> algorithms such as DSP.

It's interesting to look at modem developments for PCs.  "Real" modems
usually have two processors on them: a DSP to handle the signal processing
and a general purpose processor to handle the AT command interface and
housekeeping.  WinModems ditch the general purpose processor but keep the
DSP; Host Signal Processing modems (HSPs) ditch the DSP as well (they're
really just a DAC and ADC coupled to a CODEC and your telephone line).
HSPs are kind of an interesting development... they suck a significant
portion of your CPU time, they often have problems on heavily loaded systems
(because the HSP process gets starved for CPU time, hence the output FIFO on
the DAC underflows, and if the other modem doesn't hang up before the HSP
process gets serviced again, at best the modems have to re-train, pausing
your connection for 5-15 seconds), but they are dirt cheap (at Fry's you
sometimes even see them for free -- with the mail-in rebate!).  In my
opinion, it's not a very good compromise, yet I imagine that millions have
been sold this year.  In the same way that these difference modems target
different market demographics, so do FPGAs vs. ASICs vs. GPPs.

---Joel Kolstad





Article: 19139
Subject: Re: data serializer/decoder FPGA solution
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 02 Dec 1999 00:10:32 +0100
Links: << >>  << T >>  << A >>
"Manfred Kraus" <mkrausnews@cesys.com> writes:

> I have to transmit data using an optical link (100 MBd).
> How can I serialize / encode and deserialize / decode
> the data using an FPGA only (no analog solution, no CPU) ?
> Are there any  pure digital solutions ?
> The way RS232 transmission works is not practicable (would need at least
> 400 MHz sampling clock)
> 
> Where can I find descriptions of encoding technics.

May I suggest using 100 Mbit ethernet on fibre. PHYs are available
that do the tricky clock recovery stuff. You can either use them as 4
bit@25 MHz with start/stop (of frame) or as a 5 bit@25 MHz. In the
latter case you must do the enconding yourself so as to include proper
amount of edges for clock recovery.

Have a look at some datasheets, www.tsc.tdk.com, www.level1.com,
www.altima.com etc.

Hope this helps a bit.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se
Article: 19140
Subject: Free Data Management Software
From: Spatel <sanjay@cliosoft.com>
Date: Wed, 01 Dec 1999 15:50:33 -0800
Links: << >>  << T >>  << A >>

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<a href="http://www.cliosoft.com"><img SRC="cid:part1.3845B449.1647E6BD@cliosoft.com" height=75 width=303></a>
<br>&nbsp;
<p><b><font color="#FF0000">Free Data Management Software with Remote-Site
support</font></b>
<p><b><a href="http://www.cliosoft.com">http://www.cliosoft.com</a></b>
<p><b>* Revision control of directories and files for true configuration
management</b>
<br><b>* Import RCS database into SOS</b>
<br><b>* Graphical and easy to use</b>
<br><b>* Increase project visibility</b>
<br><b>* Manage data from remote sites</b>
<br><b>* Tagging, Branching, Visual Diff, Snapshot.....</b>
<p><b>To learn more about SOS <a href="http://www.cliosoft.com">click here</a></b></html>

--------------5CBE6767130FB295445D2FE7
Content-Type: image/gif
Content-ID: <part1.3845B449.1647E6BD@cliosoft.com>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="C:\WINDOWS\TEMP\nsmail5B.gif"

R0lGODlhLwFLANQAAAAAAP8AAP///wAAAEBAQIAAQICAgKCgoMDAwBAQECAgIDAwMFBQUGBg
YHBwcHh4eIiIiJCQkJiYmKioqLCwsLi4uMjIyNDQ0NjY2AAAAAAAAAAAAAAAAAAAAAAAAAAA
ACH/C05FVFNDQVBFMi4wAwEAAAAh/sFodHRwOi8vd3d3LnJ0bHNvZnQuY29tL2FuaW1hZ2lj
CgpDcmVhdGVkIHdpdGggQW5pbWFnaWMgR0lGIFYgMS4wNmIKYnkgUmlnaHQgdG8gTGVmdCBT
b2Z0d2FyZSBJbmMuCgpUbyBzdXBwcmVzcyB0aGlzIG1lc3NhZ2UgaW4gdGhlIHJlZ2lzdGVy
ZWQgdmVyc2lvbgp1bmNoZWNrICJPcHRpb25zIHwgQW5pbWFnaWMgY29tbWVudCBmcmFtZSIK
ACH5BAksAQMALAAAAAAvAUsAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik
cslsOp/QqHRKrVqv2Kx2y+16v+CweCgom83Cc3nM1gXe8Hig3VKrf/Z1HU1ny/+Ac30oemQC
I3wrdk6Fgy2BkH+OJY0ii5ZnJHcmlYWbmIecoZiiiJkAl5+oo5MokCuvk5Wrp3mgp5qslJer
hKyznrV3trStKYCmeYXIjrPFptC9pLu+o3zAm3raus+JwdPGJZK3yp/jdMSN6ofrpSedofCL
2+C54O3S4SNy5OXlIvzQpfplS5kobvlI8UoojV6/e+kQTuLnr+KigGycrcu2MBc8asQYOtzG
MRkuZ44w/xpM8Q+jGI0E30mUGcwaPW+6RsazCdGXPgBx9s3BtWdT0DEw7XXbibCmSZw00Uhl
57Ahz2c/AcLRunWmootbXzYlyFFVtHqqUJb9FPHpN2NBD7lMpvQgmqNgUNolqzYmC71RE9ES
7BHfxK5Az9E9u1du2C+Adaz8isdrVnFdHc8VHDkTXi+Rc3RUEfqykLh3FXO2PDjxG9M0SsOe
gjr1udVFNQua/UI2byiZTzHDyrDamse/kx8eSpSZb7uulUsfFHzW8Mlfj7+ezl1MdYTI/OWO
3r18l9ozw4vP7np3bsIynrMcHaSv+Rrfjyk+mF1z73+xsfYXgIZwA999LlQHy/9+b5GmnXvs
mSSZWfPxRQRRRO1AH2NeKMhSe8gZVg15LmCzy2pVsUVhPSyaJY9eGKJYk4w20ciYjQ/V5UN+
84G4XUKd2fafTG4xNRUo04Sk440ZviiRTkCexEtZSQ60UkRpCUiDhxX6KEgnA/pX4lhnQZki
UyymWdxSGRIXzU1joVnckVW+Oc9OduI5mHwJvtbmiV6qyR5ylLmDz0f5nEmkO6Vgp+aMgira
KE+HrgGnUt84mgOXPQbKp5BjLjpZpSU9SqZbHO55amtRClPmMHcOVOeVV625A6fGeRrfg0Ma
2lGDKqa65oxQFXagYcRKiiVJUs46Za18woBrrsPBAOr/HqKeCiWjSXELbU616gjsVW9lauCT
elqK7qun+XlgVJ7Kdu2A/FmV7r3NuplmsYnCKiyM31apZy+yYmWmnPai2sO0Durm7rsekUgv
Nf0YqVOp9lFcsbGqruotxjVmUtCzzgYr0p83MPzIOCjTRaiDhXEsoUJ+hbYRuC3nqDGjqkaq
JLM1U/XUkkeo3KVzQYr5Xs5jbmjcisL6xPPORDes5KJfGG0JoPFaNm9/EO8a9tPR+lB2hWdz
YTSKQlHk1deFVpE2glWsjRMrkgAGN918N6G1MLrk3bDEfRe+BHpop7cfoJ8Z7jgSWnd8R7WM
//j45UbwmLgtlN9COOagBxF5/8V4z4Xky6GnvvDDZS+z2d4xUOj0rlLjoHepokF9GXqs4cYV
Xp6hHnubs9tab8QTd9pYVTZoOhviEdaDtG4T1iWvljGWdrZTPHAvHfSkcYKZ2+1p6BfB4Br7
toxRI2oqxe6Tg3WdjSksv87GA8H7puQ33vz56trZ1exEMya16HxVO6D6zqU89K3lGlbyHeS+
oyUVjMN//7Oe0HIEQW3hqUFWUVi3sFawOc2kHeWiFPdoVEE3UBAHeBFeDZC1QYOI6FWSop8N
LQYw0t3QeCgklwrhxxem7SgsxftQWDB4A+8FkEM/7FcOQwhFHmYMLQN8VxAJWEBMMdBvvHuO
Z0BUmfTF0EmB/wJguJgXv5gJsIh9MRE0UjjH9JnwCW4b4AIdBoQO1hCBUZrfuLy4pNuJKIq5
MiAEkeRAM37RCQGxSEV+B6EeBPCJN3vi+2qXsFadUYNrxBIJSdWxjZVyX7ojwm0kmYjFWVJo
mMSZJod1QjjOck+01OCJCCQuW4ZkIVkKDB5XSaDOVeZIzBslJ6kmsg020ICCGpogZckqqi3H
lSSIRRH8aC0B9TB5w0tiOFO5yaxE4pyWMwI3kzC3MI0tQEYs5+7QiU0lvBMpLZxBO8tzTtWZ
zxD+DKhAB0rQghr0oAhNqEIXytCGOvShEI2oRCea0BAAACH5BAlkAAEALAAAAAAvAUsAAAX/
ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikMiVoOp/QqHRKrVqv2Kx2W116vzmu
eEwum8/RXWK0FrUB7zh7rpK76XA8zJ6/+/uAbzJohIWGh1tgioswiI6PkGg5a5R5lZeWmZV/
JJiemqAun6OgmJwvkamqq1M+pK8zsKY1sqU6rLi5kLFztb6htpcJlMPBeHK/v6csus3OZzjE
w9PU1dbVmX/S19zYmynb3eLU2YPP5+hYMaPTCgnu8O/y8fTkr+3z+fXu08bCw/v0CeRX7JOL
dAgTQrFhTYHDhxAjSnTIDc61iRghyvOmqVrGjxo5xjhToKTJkmNO/6o8aWblypYux7xABoDe
wwUKcOJ0uDOnz571ttnk+bOozqLxSA01ipTpw3wGV5BxSZVLVUMvYVI1mUiGx5s5F4gdG1bn
WLJAKX69ebat27Yhu0E0CxetW59PsaGyylKKSjF9EQVOOVhAVnWiLM37uYBA48eOHYuNDPnx
0YBEJ1emzLny5Y34Mm/2PJryZ36AmG0p7BclX9eCuU6V3Zq2Fa/twhLYzbs378a+fZ/NOJk3
AwLHjwdP3nv4U3hsg0sHLn23c3J7s7CuDdg2Vu9atj/5e2UFTejFmTNYj9y4e/XtJTONjHw9
gwb27ddfj18/A8t4vcPYbuqxBx+B7TEXWf+As6gQHnhUwPaghN9RqB2EUYi30EwA8QQcf/c1
0J+BCeZnonJv9cafiCziN6KLLYrInmRisUUdiCyeWOKJM5LVT3ZXaJhhAd1ZSIiQERo5BZIC
tCCMh7vB6EADU7qY3373ZdlffJvVJ+KUYFIpo5Rihrnlf/KlRwCZVWppoH1WnlkjPOU4iAWT
UBD5mp6xKVkFnk0wmViHk/HnwKEOPIBojifGKKN+y4V46AOUUnqoo4hWquilW3LmJZWZLtqi
iY52Oid2qgWJYYRF8nkIoOOtOqSsTdahGJRrgmrArrtSKmacWv46ZoIlTknprhAYAIGlYYLp
ALLK7srpjCV++Sz/rwb42iawX47Z4wIbpcaEqn6+Suts5dbm6p20ikIogVQ+oGwEENS77Kaj
YjqqfyHGqywEEQRcb7aIZooswAIT/Cip/gLs8L2cjhljlTJap1YxLbCbbiGwrnZunh/Hmq55
typAIAOH1itBBCtLUK+23rL5q5vW7hqwBBIcgPPLmyKKLMs440yvtm4a+4DKLLP8sgHTxlnm
o9btVJC4Jmi8LiQdT3i1FVkj6a6HhiqL8wFkC71sxKWaGbOuAOd8wARl00uwwW27TfYBcuNr
rbxt363zysnqXWqM7En9Y6p/hkyS4h5vDLLjIm/9BMlruFOoiGJLMMEEFGy+89nCUtzs/9qH
7orz5p1TELe0k/J9Ouecr860s/IGTDbqnrscAessij4ziuCiJsi4XDNeRtYXQu5E1+1SLmBj
9z3LMucVUGA93C7PTXGL20987fTUV6864MwmOu/b1ouPfd7Hnn9A+tZ3/vfugnM/qsUEDU98
4sprJfni/TOM8bxmK0ItYD0pi8DmKlABBDBQfi5b1uyeNjrumQ98DHRg9SaAM9Yl6mgQyFn6
GshAz9ErWTZj2fsokMEHwg1vu5vg6NqknJyES38nsBorkKfDxv1vSc2rQzuAI6KjaS6DCEji
BnUmt2z1bFHda1jOJoBEDcJtaD2rneZYmEQlVmB99uob9bqoxP/Ora9XT/xd1C6GwxyS64cV
giO65Pg4OkbuNgV83gFR9gCWWS+JFghkEq3HxAjKK1EFC128APY2BloAAY9EACElwLtjQYBs
LHykJkvIQd0BbYEVCKQoB/nFvy0NkWDKEpooIryM9TAVPHzjnuwowI2xIDfQw1wEGglJC1xA
kA5UXdxQWCko9u5ZIXxfA0X5yOrhDWKTMsD0KNDLUS5RaGMboy8v8MtIcpKJxBQc8NTSiFdG
IpbFC2AtaSmoPIKNj34M5TZ/eYFBmpFsAkMhKst0wS0mkZvddGb2LpWyS1KxlwC1Z9nGhj5A
ztOXkHQhPk/Iu06xsk77458696QdH7b/akKIESJAiNgAIx7UlxgA6C81eL35hbNgH2TkSVX6
SNUNrWBanClAmym/v02Ri9tM6U4j2VKzzW1LpzqcVJJHyzneiaMflWV53BkWBDoghJyDJDdT
KtRAkvCLL0xY+SwpQnly1avj413pDNrArV4AA14Fa87mCspAuvWs9bRiWOlHpRmxcmqIkyq7
oMo1wvoQjoC6pUV4ghwqSVOZdsWAZLtqzaI2UVM282dQuVnTZz4xp8t8q2RX6kyf3g6oW53s
aLsZTAjSb0ooIieQrCbHAZ4rgLEkj7q04DzLkVRZjTSraLnKWW/KNYK9SiEvU5tSCwhUrchc
7nC56cDcAQ2T/9REwC+5OlrKevGKEVCUiNbYysDSdms8RJI60XmY5THuazmpT6JkGtrhTpam
etXZwH5W1siOtrM3Ndj0zHpfnk70uisEJHPvu1Mreha28kHVUme5FcJs5Spa26h7LywGytVE
QPBK1DSXGVTVrjau1qUXvU6XXeb+8rkyjO5BXVzP4zpsZdh16F1VW9wSPvNQ60kq1dw4x9xe
mMPnbS+FNaxYA4b4aLtMMELfat/m8hR7LftpKO27UpueTcBHhCSPm4m9/f5LhZzLrigBamLS
XpFp+JEPalypkDqjw8MGXBHfohy+f7K5u9SVpDCFdlo/FxjGBJVxW4cbV3wS82C2Q/8fEu06
Xbg6twL6fcB4CUDOb6DAzqB+BnzTE709Z5OLUyYua5doWur5l7OSfDCYZ3piSXKQfe1D2KlZ
WF9V83Rl4j2O4Q4S6mLjwsPoOWCuoqkyt43wnxbw9aU9pzOdjfGuaNUZdIE7YypbWqA8Q2Su
Q+g21LU42lTO6+Z2VzGxAHbIIjC2vFXRZD2ebG97RnOa69tgQS/U2dScJ3WdicVZBxy/pbys
ohZeqXkhWJs0dW5aIWw4jNlp3qvQrajdCeI94od28gKh7VBHYnqiuJMIRm2Px5csmNYruHaF
qK0B50SYMjxb9bqZpBEq887Ri+LBe/enMX5O40Xilrj8kKT/QNW6n1kbqMwM5vpupuVqktmz
WZSmP6tZRv1CE6Y4lde/WExiQT6X4rI1L9E51lRW9NYn9+4dBc2na1ACUqEwvLHmqBhKSCqU
khO0JCYb6PdgOlpaaZzhBzNr94gmHM7CDl4gMqoLJcOy7bF6BNLf9Sm5W5BSOZ9iCyWazzOL
nvBSf6b2csr3Ll4zhuWDqffWiubRdw7YaM+f2nfoGg0XycK7oCqpu6W2brUPgyxsacCSK3YM
MpCTHWQaw1W2wucrH/YLT2Txj8l4KiY/rZpuwG4u6ukTHPn86E+/+tfP/va7/8ibf0eh+iWs
tClqXj/d3BlXj3/0xQ+MY3U+afZ//0yERmCXSINDe/l3RkCXdhOWC0Z3JBsVgVnwdqRWQTTD
T5lzOxOlVroiTXy2OR04O4undbcjgjDkgc7SLDQjKcjEUADoAIXTaXQGgRrGPJYHRDkIDebR
IfG1Iiu4L/RHd1RHc+IlMcymQndjhFkEQgzlUkdFfGAnhFKSb0FzU3HmGBdDbDa4XihhW5hX
S6kADiVTHDKzLcFSRM33METzIihTUk6YNCfELKDCNyEkhzxTfxT0NNwSIsfHhlVCXlPTRiPg
DB0DG4xDgRRYgT3IeUMohPlxTGLHK0dILXFnPv8yMLFHN2HUK9uThkwHiXCyN9iiMHGWVBb3
gF1oR4iIW/8T6HuMSIaEYjKfYiaqlIG0s0+mQh9AuHghhy/N4otONDNnkiUY6IZAWIe6GGRS
owAYNXTNgCcSkog3CIshJYv21nmiGIly94nAMxbGcUxTiCnjCDUqsiKOwiPoyIcj4iNKtXsZ
Ryu2QY1huIi8xXG4giOqRCyRmIYGAiBHwYtLZ4tOQ5Ak4in9aCXwkRwZKCeclhTwRmTRKI+t
2FSKaI3XKFK4giX+4RsMySNRMydzQWr6qI7AAikpYhw6ohzvoY7kRRDmYIjpMo9tF4H2eI+y
uFgJYBYIciDUwY/Ekib6EB3KtpBA6ZNpMiAfApT04RhGOU4QyQcXd3kgQy7u9Rr/6CJAY+gk
uKQbP/kbntKUliGS+bMYZ1EdaNkcZCERZ/mV1hGW1DGWFUeIqvgIffExsuGFYbhOe4mTBaST
R6EZppEichkgrQQQ8hCYpbGYl/FX6FEWo/EWpHEagxiRVaMKMcFUr3g8N5mR2OiDNnIXihmY
cSEObCmZkikRHiEgovEWRlEjjal7dDmVa9cdtVkrk3cHmLAUpEkUvmmYUBEMi/GbpBmbULGa
0JEZeLGcPdGMwTkLfDA8tzkbt7kHFkENyQkSEQEa/fAN4TCc2nmc4wCe2vkc1vCMXDidDzKd
/iCcmDEQAtGd7Ymd8BkQHOEJ9ZmfSVGZyQAI6ukx6jko/9c5ngR6n8JZoAg6oAi6oOUwmxL5
n4nzn/N5oKBBEBaKD9IwoRlKn4jpDfxZChhaoSEqPB/an/EGocUDoRtaECz6nQtKoNcZoy9a
oDI6owzanS1ao4KAourSl+mgoR1ho+eZDC16o/4gpEMKpFHBo0xKBUj6pFAapVI6pTB6ok16
pU4wolraoSLKpRfqpVvapWL6pWMapmR6pmaapmD6BljapgKApmtapnEKp3Jap3R6p2pqp3mK
poXopleqn4D6noIaqIQ6qIZaqIh6qPvQp37KpOX5qJAaqZI6qZRaqZbqjIyQqYzAFMXJqZ7a
qaD6qaIaqqQ6qqZaqqh6qpq6qg+s2qqu+qqwGquyOquaGgIAIfkECcgAAQAsAAAAAC8BSwAA
Bf8gII5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKQyJWg6n9CodEqtWq/YrHZbXXq/
Oa54TC6bz1Gweg1Du9/w+JZNr5/k+Lwebe/b94CBglN+hWuDiIl6hoxeio+QZ42TSJGWl1mU
mkSYnZ5Qm6FAZwWlpqVjp6qnZqurra5jorM8ZK63XLhwr7C3pnO0wTdiqlPFub94rGXHTrxY
wtE0yKhWyVvLctnE11HNVtLhbVrbVN1Z5W/p6Ofe62lBTiNNo/Qi8j34APZC5O3mBbhV0/bv
yjsoB5/4kDIPVEMBMRjec1hD4j6KFyHi8DfQYEBqHwl25MgxJJVahCb/gnNxUiXGFy0zdtmI
JaEUk+xGqitYxeYTnztmyoy5gqjQFkKh0fSo05pAnDubWuPpjqrGpfBMHEWxdehLJim1Eq3I
FGoen6msVjXb02qYsFwtxoVLoqtYuXfwTis7CO1TkIDtRqQ7VyHYsQ8J11V81/AwvoL8Bi45
mTFMxIX5NWZ8JfNXz2+nShXJlpRahKd/urUhePNV11lLKJWNOa9j1pADScaW2lnvJjYfW97s
Wa9LzK2JYwU4Os5uyryb31y9NzltzYkFZ1psnftrsqJLO/8NvXxO8d8Hr2RxO3vt7e6N204/
oyZ5W/ftS19bWT5L+Ielp0VxcA1YlD645bbH/3PngYSeavslaGBc8613XWfxWSiWDg3qlp+C
Her3oITAXDbbhRaSwYmID5q2H3DRtYjai8C9SKIY/53oXYpmxBOiHmjJ6BuNM7aI1o2yqFAi
iuu58UOM/vRnjJQshgdgfU4SyNmEXqmIUkkPkucTkTWSCeFokgnHR4UaZljgG1+CaRaDAthk
Zp0f4pnObsv1CNt7XHbpZWgx+iLkmYZ+w+Kha+myZHVZ7tjmcRrGwSEzsaSVqKPhcergh4Su
6aZ8jwo6KJKfpKrIpXCOGpukdlmqpqq0JhJUq5RqF6irpcpQ66+2xumnqaTuCmuS4AGr7CIL
SZIroFeyiSOqyypDJ/8cuAU47bPFnojdsdGqV+1ZecqR7IFcgPsqr/q09+ek44xrba3nsrek
scRS5K603aELyTORMapaHvXmyKOO7PKzr7a1mfhIMnfiJ7CezGKJoL2VIswtRp8x7J8Lm4Ys
8sgkl2zyySiXkix9SnYVbr4IduzxwvEmUi6mE9/cL2g1rwszyzr63PJwBiPy4XOeMqdopL4K
rSV9Gv/MJMtP9+nhnb+IGbHOO0vbM80Yvntxl1+PbbHNvw2UdsQU77Gy2QT6261iRB/LqiJ+
qW1mflx3LTbGMqtbNb/f/nnrw6d1tPbEbbsNqX8N/z013PnOTPXZeFvVzeKaCvJ2WPAObVG9
cvCF/jja0l3DeeeBFDx63ZZnCHh8bj4ZieaKM8o32+mSpRzZoV7l9IYo0l6Ph6gx5Rs1EuMJ
iI8P9SP85XtFvyIgyyReDdZsL22uOODLTa73xpA/Fc6M9xr++j/LC5D71LMvDfz4wS///RvT
Xz79+N+vP2/665/8/seO/wmQfQT0CAEPuL4ETqdvj2Bg+BxIwchJMBQVzGDgLrgJDXowfhyc
xAc1GML5jbCCJUyhClfIwha68IUwjKEMkRACADs=
--------------5CBE6767130FB295445D2FE7--

Article: 19141
Subject: Re: HDL editor?
From: rajesh52@hotmail.com
Date: Thu, 02 Dec 1999 00:55:50 GMT
Links: << >>  << T >>  << A >>
Greetings
Please visit Verilog FAQ
http://www.angelfire.com/in/verilogfaq/index.html
In part 1 under "Editors which support Verilog" topic
6 editors are listed and most of them are free.

Hope this helps
Rajesh
(Verilog Center : http://www.angelfire.com/in/rajesh52/verilog.html )

In article <81ltfs$l59$1@sun27.hrz.tu-darmstadt.de>,
  "Ahmad A." <aa939788@oak.cats.ohiou.edu> wrote:
> Hi..
> Can any one tell me where can I find Free, Student edition, or
Shareware HDL
> editor?
>
> Thank you in advanced.
> Ahmad.
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 19142
Subject: Verilog FAQ
From: rajesh52@hotmail.com
Date: Thu, 02 Dec 1999 00:56:36 GMT
Links: << >>  << T >>  << A >>
Greetings
This is semimonthly announcement of Verilog FAQ.

Verilog FAQ is located at
http://www.angelfire.com/in/verilogfaq/

Alternate Verilog FAQ is an attempt to gather the answers
to most Frequently Asked Questions about Verilog HDL in
one place. It also  contains list of publications, services,
and products.

Alternate Verilog FAQ is divided into three logical parts.

Part 1 : Introduction and misc. questions
Part 2 : Technical Topics
Part 3 : Tools and Services

What's New section outlines the changes in different versions
and announcements. Links connects you to related
informative
links in internet.

Your suggestions to make this FAQ more informative are
welcome.

Rajesh Bawankule
(Also Visit Verilog Center :
http://www.angelfire.com/in/rajesh52/verilog.html )



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19143
Subject: Re: ALTERA EPC2 Configuration Help needed!
From: "Edwin Grigorian" <edwin.grigorian@jpl.nasa.gov>
Date: Wed, 1 Dec 1999 17:23:35 -0800
Links: << >>  << T >>  << A >>
Problem resolved by calling Altera Tech Support (they were great!).  In my
case, I have 3 devices on the JTAG chain: 1 10k200E and 2 EPC2's.
When making up the JTAG chain list, you should have all three devices
defined but only reference the two .POF files and leave out the SOF file for
the FPGA.  On the file list, it should just say <none> for the 10k200E
device.  Device order is important so make sure that the FPGA is the last
device listed in the JTAG chain.  Select "Detect JTAG Chain info".  After
that, you can start programming the EPC2s by hitting the PROGRAM button.  It
programs the two EPC2s one after the other.  I can now cycle power to the
board and the FPGA is almost instantaneously configured.

Hope this helps others,

Edwin Grigorian

"Edwin Grigorian" <edwin.grigorian@jpl.nasa.gov> wrote in message
news:823k5o$6jo@netline.jpl.nasa.gov...
> I'm experiencing the same difficulty with the EPC2LC20 for programming of
a
> 10K200E part.  I also get the 'Unrecognized device or socked empty'
message
> with MaxPlusII, ver. 9.30.  I would also be very interested to find out
the
> solution for amking this work.
>
> Edwin Grigorian
>
> "Volker Kalms" <ea0038@uni-wuppertal.de> wrote in message
> news:383CBB4B.5D4D@uni-wuppertal.de...
> > Hi all,
> >
> > Since a quarter of a year I discover the beatiful world of
> > AHDL and VHDL. Until now everithing worked fine. But now I would
> > be very grateful for a little help.
> >
> > Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured
> > by Ing. Buero Lindmeier) in my hands. This evaluation board contains
> > an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the
> > ALTERA MAX+plusII (v 9.1) software......no problem to this point.
> >
> > Two weeks ago I purchased an configuration EPROM (EPC2LC20), which
> > could optional plugged into my evaluation board.I set up the MAX plus
> > JTAG chain due to the requirements (as far as I would say), performed
> > an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus
> > detected the additional device in the JTAG Chain.
> > But when I try to Program the .pof file to the EPROM I get the message:
> > Unrecognized device or socked empty.
> >
> >
> > What am I doing wrong????? From my point of view I changed nearly every
> > parameter in the MAX plus setup.
> >
> > I hope there is somebody out there, who could give me a hint how to get
> > this EPROM configured.
> >
> >
> > MANY THANKS IN ADVANCE!!!
> >
> > Best regards,
> >
> > Volker
>
>


Article: 19144
Subject: Re: backup fifo's
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Wed, 1 Dec 1999 18:11:49 -0800
Links: << >>  << T >>  << A >>
So, Xilinx does require a backup fifo (just not a fast one :>)).

Assuming that I am bus mastering a write....Isn't the problem with the fifo
being out of sync at the end of a transaction eliminated by the fact that
the transaction can only be terminated by a stop (unless I end it), which
will take the data just saved in the hidden register?  It's hard for me to
see how (if I am writing) I can be out of sync after the transaction
completes.

Bruce

Eric Crabill wrote in message <3842D3BF.B9407981@xilinx.com>...
>Hi Bruce,
>
>The Xilinx PCI64 and PCI32 cores do not require FIFOs that back up
>during a bus transfer.  Depending on the type of transfer, we may require
>the user to back up the FIFO when the bus transaction terminates.
>
>The situation you describe is never an issue when the core is the target of
>a write or the initiator of a read.  In cases where the core is the target
>of a read, or the initiator of a write, it can occur if the other bus agent
>inserts wait states in the middle of a burst.
>
>Our implementation contains the necessary "shadow" registers as a buffer
>for the cases where it can be an issue.  In situations where the core needs
>to use this buffered data, it does so automatically and transparent to the
user.
>
>In cases where it can be in issue, the "shadow" registers may still hold
valid
>data at the end of a transfer, depending on how the transfer terminated.
>We ask the user to back up their FIFO at this time.  There are two main
>reasons for this:
>
>1.  It forces a FIFO state consistent with what took place on the bus.
>2.  It allows the next transfer on the user side to be unrelated to the
first.
>
>The largest issue is item two.  Many designs have more than one target
>address space (multiple base address registers) and have more than one
>"channel" as an initiator.  To assume otherwise would seriously limit the
>flexibility of our implementation.
>
>Hope that clarifies,
>Eric Crabill
>
>Bruce Nepple wrote:
>
>> One thing you might look at when you consider PCI cores is whether you
need
>> a "backup fifo" or is it implemented in the core.  When you get a late
>> TRDY-false does the core save the data in a hidden register or do you
have
>> to backup your fifo pointer to send it (there is no way you will be able
to
>> stop the fifo from advancing since the signal comes so late).  My
impression
>> is that Xilinx requires a backup fifo.
>


Article: 19145
Subject: Re: data serializer/decoder FPGA solution
From: Mark Summerfield <m.summerfield@ieee.org>
Date: Thu, 02 Dec 1999 14:29:33 +1100
Links: << >>  << T >>  << A >>
Manfred Kraus wrote:
> 
> I have to transmit data using an optical link (100 MBd).
> How can I serialize / encode and deserialize / decode
> the data using an FPGA only (no analog solution, no CPU) ?
> Are there any  pure digital solutions ?
> The way RS232 transmission works is not practicable (would need at least
> 400 MHz sampling clock)

I doubt that this is something you really want to try to do in an
FPGA.  Can I suggest that you look at:
    http://www.cypress.com/cypress/prodgate/datacom/cy7c9689.html
for a single-chip addition to your system that you could easily interface
to an FPGA to do the serialise/encode and deserialise/decode functions.

Mark
Article: 19146
Subject: Re: data serializer/decoder FPGA solution
From: Klaus Falser <kfalser@durst.it>
Date: Thu, 02 Dec 1999 08:27:03 GMT
Links: << >>  << T >>  << A >>
In article <823gqf$bgk$1@thetenth.astat.de>,
  "Manfred Kraus" <mkrausnews@cesys.com> wrote:
> I have to transmit data using an optical link (100 MBd).
> How can I serialize / encode and deserialize / decode
> the data using an FPGA only (no analog solution, no CPU) ?
> Are there any  pure digital solutions ?
> The way RS232 transmission works is not practicable (would need at
least
> 400 MHz sampling clock)
>
> Where can I find descriptions of encoding technics.
>
> --
> Manfred Kraus
> mkraus@cesys.com
>
> --
> Manfred Kraus
>
>
Cypress has 2 serializer/deserializer devices like the CY7B923 and
CY/B933 which operates at 25 MByte/sec and interface with FibreChannel
transmitters/receivers.
Really easy to use.

Best regards
--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19147
Subject: Command line for FPGA Express
From: "Mark van de Belt" <mark@nospam.bs>
Date: Thu, 2 Dec 1999 09:46:00 +0100
Links: << >>  << T >>  << A >>
Hello,

Is there a possibility to use a command line option for FPGA express for
checking, synthesis and optimalisation?
I presume that Xilinx foundation also calls FPGA express with a command line
option.

Thanks in advance
Mark


Article: 19148
Subject: Re: data serializer/decoder FPGA solution
From: "Manfred Kraus" <mkrausnews@cesys.com>
Date: Thu, 2 Dec 1999 12:12:52 +0100
Links: << >>  << T >>  << A >>
>You might find a clever way to use an on-board PLL or DLL to
>generate a data clock from manchester encoding.


That sounds great. I'll check out whether I can make
improper use of the XILINX DLL.

Thanks a lot
Manfred Kraus




Article: 19149
Subject: Re: FPGA vs DSP vs PENTIUM MMX
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Thu, 02 Dec 1999 14:55:28 +0000
Links: << >>  << T >>  << A >>
Steven Derrien wrote:
> Right; but total execution time will always be bounded by the time it takes to transfer the
> orginal image into the FPGA plus the time to transfer the resulting image out of the FPGA.
> 
> What I wanted to say is that in many cases the maximum speed-up that you can expect from an
> FPGA solution is strongly limited by communication time.

What a curious discussion! Steven Derrien seems to want to limit the
universe
of problems-that-are-worth-solving to be the same as the universe of
problems-that-are-memory-bandwidth-limited, because that way he can show
that
the P3 MMX is faster (or more cost-effective, or less hassle, or
something) than
an FPGA.  But if I use an FPGA I can do all kinds of things about memory
and 
processing bandwidth that are physically impossible with a CPU
regardless of cache:

* have multiple, physically separate memories being accessed
simultaneously
* have very, very wide datapaths to modest amounts of local memory
  (hundreds of bits wide, if appropriate)
* perform bit position manipulations and even some simple arithmetic as
part
  of the process of transferring to/from memory
* put arbitrary different ALUs in parallel, not just the SIMD stuff that
  the CPU manufacturer happened to think was sexy at the time

If I have multiple *separate* memories, then I can still get real-time
processing with an FPGA even if the image data rate is so high that it
fully occupies the bandwidth of one of my memories!  Why do you think 
FPGAs are pushing the pin-count envelope so hard?

CPUs are getting faster and more ingenious all the time, but for any
given 
application I would say you can *always* get higher performance from 
dedicated hardware if you are prepared to pay/work for it.  Despite
this assertion, it may well be possible to do in software some 
operation that has traditionally been hardware-only, because the
GPP is now so fast that the software approach is *fast enough*.
But your "fast enough" may be slug-like in the eyes of the
guy around the corner, and he'll need a dedicated hardware
solution.

Another major issue when using clever GPPs to do compute-intensive
pipelined tasks is the question of context switching.  You may be
happy for Windoze to take half a second to respond to a mouse
click, but some real-time applications are less forgiving and
need some events to interrupt the CPU for prompt service.  This
tends to require the CPU state to be saved and then restored
later, a disaster for any GPP with intensely pipelined internal
processing hardware.  Using a dedicated processor for the
compute pipelines frees-up the GPP for the stuff it does best-
complex control and branching - without those things
screwing the performance of the computation through
repeated flushes of pipelines and cache because of task
switching.

Jonathan Bromley



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