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 30900

Article: 30900
Subject: Re: Need info : Training on ASIC/FPGA
From: "Jeff Cunningham" <jcc@sover.net>
Date: Wed, 2 May 2001 15:05:37 -0400
Links: << >>  << T >>  << A >>
> > It would be highly appreciated if anyone can let me know if there is any
> > good training course related to " ASIC/FPGA flow" (I know its huge;
> > still if there is any that covers important aspects) arranged by any
> > Institute around North America.

I think Esperan has some courses in this area. They are not cheap. You might
check their web site.




Article: 30901
Subject: Re: Shannon Capacity
From: "Berni Joss" <berni_13@yahoo.com>
Date: Wed, 2 May 2001 21:37:08 +0200
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3AF027BD.50AFA29B@xilinx.com...
> Wrong.
>
> Go back and re-read his paper.

Austin, I do not agree with your interpretation of Shannon's theorem ...
but I'm convinced that you're right about the value of reading his paper.
Any hints on where I could find a copy?
I don't live close to a library, so an web link would be much appreciated.

Berni.


>
> This is really funny, and sad.
>
> Austin
>
> Steve Rencontre wrote:
>
> > In article <3AEF11CD.CEA6992D@xilinx.com>, austin.lesea@xilinx.com
(Austin
> > Lesea) wrote:
> >
> > > See what I mean?
> > >
> > > Still confused after all these years.
> > >
> > > If the CRC is not information, then you don't need it.
> > >
> > > If the CRC is information, then you need to send it.
> > >
> > > I rest my case.
> > >
> > > Austin
> >
> > I disagree. The CRC (or whatever) is not information, but you do need
to
> > send it! The total message of N+CRC physical bit symbols only carries
> > N bits of /information/, and it's that which Shannon's theorem applies
to.
> >
> > I think the confusion arises because we automatically think that a 1 or
0
> > in the digital domain is a 'bit' in the Shannon sense, but it's not -
it's
> > just a symbol which can be used to encode bits. Adding a CRC increases
the
> > predictability of lost symbols, which means each 0/1 symbol carries
less
> > than one actual bit.
> >
> > Shannon tells us how many bits of genuine information we can transmit,
but
> > we're free to send as many
> > symbols-which-superficially-look-like-bits-but-aren't as we like :-)
> >
> > --
> > Steve Rencontre         http://www.rsn-tech.co.uk
> > //#include <disclaimer.h>
>



Article: 30902
Subject: Re: Shannon Capacity
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 02 May 2001 13:28:15 -0700
Links: << >>  << T >>  << A >>
Berni,

Oh well.  You will have to order it from a bookstore, or Amazon.com.

It is copyright IEEE Press, or Bell Labs, so you will not find it on the web.

The big book by Sloane and Wyner on "Claude Shannon: Collected Papers" is
definitely worth buying.

He not only invented communications theory, but information theory, and
demonstrated many practical results in cryptography as well.

It is really a shame that something so simple is so often mis-interpreted.

The "example" of using phonetics to communicate is a perfect one.  If I speak
"a" "b" "c" etc to spell something in the presence of noise, then the listener
hears "a" "?" "?" etc.  If I speak "alpha" "baker" "charlie" and the listerner
hears "al...."  "ker"  "char..." (50 % of symbols in error, but your matched
filter ears figure it all out with the help of your brain).  Now if the check
characters were not part of the transmission, where the hell were they?  If
they were not required, then you could remove them at the source (you never
received them), and you would have "a" "?" "c" so something was needed....

Shannon also very carefully covers the transmission of the check and correct
symbols by another channel, different from the one used for the original
information.

He covers n-ary symbols, not just binary.  Pretty good for the 1930's.  The
paper was not allowed to be published until well after WWII (1948).

He also very carefully covers channels with a reverse channels, also with
errors (eh?  say again? What?  you want me repeat?  Repeat?  repeat what? ....)

Austin

Berni Joss wrote:

> "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> news:3AF027BD.50AFA29B@xilinx.com...
> > Wrong.
> >
> > Go back and re-read his paper.
>
> Austin, I do not agree with your interpretation of Shannon's theorem ...
> but I'm convinced that you're right about the value of reading his paper.
> Any hints on where I could find a copy?
> I don't live close to a library, so an web link would be much appreciated.
>
> Berni.
>
> >
> > This is really funny, and sad.
> >
> > Austin
> >
> > Steve Rencontre wrote:
> >
> > > In article <3AEF11CD.CEA6992D@xilinx.com>, austin.lesea@xilinx.com
> (Austin
> > > Lesea) wrote:
> > >
> > > > See what I mean?
> > > >
> > > > Still confused after all these years.
> > > >
> > > > If the CRC is not information, then you don't need it.
> > > >
> > > > If the CRC is information, then you need to send it.
> > > >
> > > > I rest my case.
> > > >
> > > > Austin
> > >
> > > I disagree. The CRC (or whatever) is not information, but you do need
> to
> > > send it! The total message of N+CRC physical bit symbols only carries
> > > N bits of /information/, and it's that which Shannon's theorem applies
> to.
> > >
> > > I think the confusion arises because we automatically think that a 1 or
> 0
> > > in the digital domain is a 'bit' in the Shannon sense, but it's not -
> it's
> > > just a symbol which can be used to encode bits. Adding a CRC increases
> the
> > > predictability of lost symbols, which means each 0/1 symbol carries
> less
> > > than one actual bit.
> > >
> > > Shannon tells us how many bits of genuine information we can transmit,
> but
> > > we're free to send as many
> > > symbols-which-superficially-look-like-bits-but-aren't as we like :-)
> > >
> > > --
> > > Steve Rencontre         http://www.rsn-tech.co.uk
> > > //#include <disclaimer.h>
> >


Article: 30903
Subject: Re: VHDL coding question.
From: Colin Marquardt <colin.marquardt@usa.alcatel.com>
Date: 02 May 2001 16:07:47 -0700
Links: << >>  << T >>  << A >>
steve (Steve Rencontre) writes:

> In article <X1TH6.16348$482.81848@newsfeeds.bigpond.com>, 
> murrayal@yahoo.com (auliya) wrote:

> > 2. Use a configuration declaration to specift which of B1 or B2 to use. 
> >  For
> > this you need an entity declaration (B) and the two architectures (B1 
> > and
> > B2).  Basically, a configuration allows you to bind a specific 
> > architecture
> > (out of many options) to an entity.
> 
> 3. Run it through a C preprocessor first :-)

With emacs' VHDL-Mode, you can generate a Makefile from the parsed
VHDL code, respecting hierarchical configurations. With that, you can
support configurations even for tools that do not by themselves (most
synthesis tools e.g.). Kind of 2. and 3. in one.

--> http://opensource.ethz.ch/emacs/vhdl-mode.html

HTH,
  Colin

Article: 30904
Subject: Re: VHDL coding question.
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 02 May 2001 16:11:19 -0700
Links: << >>  << T >>  << A >>
auliya wrote:

> With this you have 2 options:
> 1. Use a generic to pass in a parameter which will specify which of B1 or B2
> to use.  In this case you need to use 'if...generate' statements to
> instantiate each option.  You should the B1 and B2 entity/architecture pairs
> in separate files and use B as a 'wrapper' to choose which one to use.

Option 1 works fine for everything other than 
VITAL delay backannotation where the top level 
is a testbench and the generated statement is 
your design DUT. Here is an example I tried
where the generic WITH_DELAY is a boolean:
------------------------------------------
   fast_sim : if not WITH_DELAY generate
   dut : entity work.xszero(synth)
      port map (clk       => clk,               -- [in]
                rst       => rst,               -- [in]
                dpos      => dpos,              -- [in]
                dneg      => dneg,              -- [in]
                mode_16   => mode_16,           -- [in]
                count_std => count_std,         -- [out]
                overflow  => overflow);         -- [out]
   end generate fast_sim;
          
   delay_sim: if WITH_DELAY generate

   dut : entity work.xszero(\ep1k50fc256-1\)
      port map (clk       => clk,               -- [in]
                rst       => rst,               -- [in]
                dpos      => dpos,              -- [in]
                dneg      => dneg,              -- [in]
                mode_16   => mode_16,           -- [in]
                count_std => count_std,         -- [out]
                overflow  => overflow);         -- [out]        
   end generate delay_sim;

The first case worked fine (no backanno), but in the second,
the generate id gave me an sdf instance of 
/testbench/delay_sim instead of the expected
/testbench/dut  and modelsim complained.

I could not figure out how to get Modelsim to line up the 
.sdf delay file with the associated dut level.

> 2. Use a configuration declaration to specift which of B1 or B2 to use.  For
> this you need an entity declaration (B) and the two architectures (B1 and
> B2).  Basically, a configuration allows you to bind a specific architecture
> (out of many options) to an entity.
> 

Just happen to have an example of this also.
I ended up putting the delay model (.vho)
in a separate library to keep the identical
entity names from clashing.
----------------------------------------

configuration vital of test_xszero is
   for sim
      for dut:socket
         use entity vho.xszero(\ep1k50fc256-1\);
      end for;
   end for;
end configuration vital;

configuration fast of test_xszero is
   for sim      
      for dut:socket 
         use entity work.xszero(synth);
      end for;
   end for;
end configuration fast;
----------------------------------------
Modelsim was happy with both configs:
> vsim fast
  or
> vsim -sdfmax dut=xszero.sdo vital


   -Mike Treseler

Article: 30905
Subject: Re: Serial UART
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 02 May 2001 16:19:54 -0700
Links: << >>  << T >>  << A >>
There is something weird about implementing a standard UART in an FPGA.
A UART is a standard chip, endowed with all the programmable registers to adapt
it to particular requirement. Throwing that design onto an FPGA means that you
are double-programmable, and double inefficient.
The FPGA user knows (usually) whether parity is odd or even, how many stop bits,
how large a FIFO, etc.
Controlling all this with registers doesn't make sense when you use an
inherently programmable technology.

Peter Alfke, Xilinx Applications
=========================
Kevin Neilson wrote:

> Insight Design Services has Verilog source that functions similarly to the
> Mot MC145428, which is a serially-interfaced UART.  Not free, though.
>
> "Mark Walter" <maw@nospam.com> wrote in message
> news:1ALH6.226933$GV2.47295492@typhoon.san.rr.com...
> > Does anyone know of where I can find a free Verilog source code for a
> Serial
> > UART that can be used in a Xilinx XC4005XL FPGA? I am in need of such code
> > to add to a FPGA design I am making for remote access to the FPGA CPU...
> >
> > Thanks,
> > Mark
> >
> >
> >


Article: 30906
Subject: Re: Shannon Capacity
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 02 May 2001 21:19:04 -0700
Links: << >>  << T >>  << A >>

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

.....

It says that for a rate of C bits per second in the presence of No noise power
bandwidth in W hertz, you can have error free operation.

It tells you nothing about how to code it to achieve that rate.

That's the million dollar question: how do you even get close to the Shannon
limit without knowing how?

Austin

Steve Rencontre wrote:

> In article <3af20db4.2149921@news.dtgnet.com>, nemo@dtgnet.com (Nemo)
> wrote:
>
> > C refers the the capacity of a physical band-limited
> > channel.  By definition, C includes *all* the data carried by the
> > channel. This includes the payload data and any overhead (parity bytes,
> > etc) needed for the FEC layer if used.
>
> Sorry, but that doesn't add up. Shannon's Theorem says that you can carry
> C bps /without/ error. In that case, why have you included error detection
> and correction bits with the payload data?!
>
> --
> Steve Rencontre         http://www.rsn-tech.co.uk
> //#include <disclaimer.h>

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
.....
<p>It says that for a rate of C bits per second in the presence of No noise
power bandwidth in W hertz, you <b><i><u>can</u></i></b> have error free
operation.
<p>It tells you <b>nothing</b> about how to code it to achieve that rate.
<p>That's the million dollar question: how do you even get close to the
Shannon limit without knowing how?
<p>Austin
<p>Steve Rencontre wrote:
<blockquote TYPE=CITE>In article &lt;3af20db4.2149921@news.dtgnet.com>,
nemo@dtgnet.com (Nemo)
<br>wrote:
<p>> C refers the the capacity of a physical band-limited
<br>> channel.&nbsp; By definition, C includes *all* the data carried by
the
<br>> channel. This includes the payload data and any overhead (parity
bytes,
<br>> etc) needed for the FEC layer if used.
<p>Sorry, but that doesn't add up. Shannon's Theorem says that you can
carry
<br>C bps /without/ error. In that case, why have you included error detection
<br>and correction bits with the payload data?!
<p>--
<br>Steve Rencontre&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.rsn-tech.co.uk">http://www.rsn-tech.co.uk</a>
<br>//#include &lt;disclaimer.h></blockquote>
</html>

--------------4F6A00D1C44544036B08CCC9--


Article: 30907
Subject: FPGA application survey question
From: Anonymous Idiot <anonymous_idiot@nowhere.com>
Date: Wed, 02 May 2001 21:35:02 -0700
Links: << >>  << T >>  << A >>
...I've had the priviledge of fooling around with some FPGA devices over
the
past few months.  In my case, I wanted to test an ASIC design (Verilog
RTL
code), which I couldn't simulate very well with plain on Verilog
stimulus
files.

I was demodulating a comm-signal.  Running the using Cadence Verilog-XL
on
my workplace's UltraSparc2 300MHz (old, slow by today's standards...), 
the execution time was horrendous ... roughly 5 minutes of "real world
time"
(and thumb twiddling) for a scant 30ms of 'circuit simulation time.'

Anyway, I got the wise idea that maybe I could compile this circuit to
an
FPGA-device, get an ADC, and do a 'live test.'  So that's what I did. 
While
I did encounter a few problems along the way (each problem was
educational
for me), in the end I was very satisfied with my laboratory trial.  I
learned a lot...I uncovered some flaws in my circuit (and corrected
them),
and then the project was cancelled, game over.

(If I could do everything over, I think I would have concurrently
written
 behavioral-level Verilog models along with the actual RTL-code.  Then
 use the behavrioal-models to run 'proof of concept' trials.  I had to
 scrap some of my circuits, and redesigning them at RTL level is more
 time-consuming than at behavioal-level.

 I didn't think to try this, because it would have been a gamble.  I
would
 have gone out of my way to do something extra, which may or may not pay
 off.)

...

My question to you folks out here, how many folks use FPGAs to prototype
ASIC or other digital logic?  I see countless posts relating to
implementing
certain functions on FPGAs...is that what you guys are doing?

Article: 30908
Subject: Re: Shannon Capacity
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 02 May 2001 21:39:55 -0700
Links: << >>  << T >>  << A >>
On Wed, 2 May 2001 21:37:08 +0200, "Berni Joss" <berni_13@yahoo.com> wrote:
>
>Austin, I do not agree with your interpretation of Shannon's theorem ...
>but I'm convinced that you're right about the value of reading his paper.
>Any hints on where I could find a copy?
>I don't live close to a library, so an web link would be much appreciated.
>
>Berni.
>

Here it is:

   http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf

enjoy

Philip



Philip Freidin
Fliptronics

Article: 30909
Subject: Re: ccd imaging with fpga
From: "Austin Franklin" <austin@darkroo87m.com>
Date: Thu, 3 May 2001 00:47:15 -0400
Links: << >>  << T >>  << A >>
Actually, we did this at Micron in 1984...just mounted a DRAM in a clear
plastic package.  Problem is, it is only line art...no gray scale...unless
you did multiple exposures with a different aperture setting.

"Michael Strothjohann" <strothjohann@rheinahrcampus.de> wrote in message
news:3AEFF103.81165A24@rheinahrcampus.de...
> Probably the device is like the one in an
> old BYTE-article ( over one decade ago ):
> an DRAM was opened and the
> precharged C's are decharged by the incoming
> photons. The picture reflects the chip-structure,
> but the low-cost ('home-made') device realy works.
> michael strothjohann
>
>
> Victor Schutte schrieb:
>
> > About a year ago I read an article on a new image device that looks like
RAM
> > (manufactured by HP). You don't need to design high speed CCD circuitry
and
> > device drivers for Windoze.  You can use something as simple as a 8051
uC,
> > scan the device and then send the data to the PC via RS232.
> >
> > Unfortunately I do not know the part number or the price (which can
probably
> > be very high). I know the part exists. If anyone has more details on
this
> > please post.
> >
> > "M.B." <martinb@magma.ca> wrote in message
> > news:3aeeb905.4091345@news.magma.ca...
> > > Hi I have a telescope and some basic experiance with VHDL, FPGAs.
> > > I would like to get a CCD (something common and cheap) and use a FPGA
> > > perhaps a xilinx or atmel with VHDL. and interface to my computer (win
> > > 98.
> > >
> > > Has anyone done somthing like this?
> > > Is there a project in any books or wed sites that you have seen that
> > > could get me started?
> > >
> > > Or is there a development kit from one of the CCD Manufacturers that I
> > > could look into?
> > >
> > >
>



Article: 30910
Subject: Re: Serial UART
From: "Mark Walter" <maw@nospam.com>
Date: Thu, 03 May 2001 05:16:47 GMT
Links: << >>  << T >>  << A >>
Thanks everyone for the info.  I think I have enough now to start with a
simple Serial interface to my CPU design....

Mark




Article: 30911
Subject: FPGA based PCI cards
From: "James Brennan" <s369272@student.uq.edu.au>
Date: Thu, 3 May 2001 15:41:35 +1000
Links: << >>  << T >>  << A >>
I'm a final year engineering honours student, preparing to do some image
processing thesis work on an FPGA.

I'm interested in PCI cards that have been designed for FPGA-based image
processing (e.g. relatively simple PCI interface, substantial amount of
SRAM). I'm probably leaning toward using one of the Xilinx Virtex
architectures.

If you are using such a PCI card and are happy with it, could you reply to
this post with the card's name and manufacturer (and your opinion of the
card)?

Thanks,

James Brennan.
I



Article: 30912
Subject: Re: Shannon Capacity
From: kfalser@REMOVETHISdurst.it (Klaus Falser)
Date: Thu, 03 May 2001 07:03:20 GMT
Links: << >>  << T >>  << A >>
On Wed, 02 May 2001 13:47:50 GMT, nemo@dtgnet.com (Nemo) wrote:

>You may want to get ahold of Shannon's paper, it explains the details better
>than I can.   C refers the the capacity of a physical band-limited channel.  By
>definition, C includes *all* the data carried by the channel. This includes the
>payload data and any overhead (parity bytes, etc) needed for the FEC layer if
>used.  In-line comments below...
>
>"Kevin Neilson" <kevin_neilson@yahoo.com> wrote:
>
>>There's something I've never quite understood about Shannon's Law.  It
>>states something like this:
>>
>>C = W*logbase2(1 + S/N)
>>
>>where C is channel capacity, bits/s
>>    W = bandwidth, Hz
>>    S/N = signal-to-noise ratio
>>
>>Theoretically, if using enough error-correction, you can transmit C bits/s
>>on a channel error-free.
>
>Yes, exactly as it says -  bits are bits, and parity bits are information too.
>>
>>Say you determine that the channel capacity for a particular channel is
>>1Mbit/s.  Does that include the error correction bits or not?  
>
>Yes it includes error correction.
>
>>What if you
>>have a 1/2 rate code, where half of the bits are parity bits.  Does that
>>mean you transmit 2Mbit on that channel (with 1Mbit capacity) for a net data
>>throughput of 1Mbit error-free?  
>
>No, if the Shannon limit is 1Mbps, then thats all you get *including* parity.
>
>>Or does the 1Mbit include the partiy bits?
>Yes.
>
>>
>>-Kevin
>>
>
>
>Hope that helps.
>
>Nemo

In my opinion, most confusion here comes from the fact, that some
people considers the CRC and parity coding/decoding part of the 
channel, and others do not.

Personally I would opt for making the coding/decoding part of the
channels, since it gives you a "better" channel. 
In this case and in the above example you have 1 MBit/s information
rate (Bits you are free to choose), but you have a symbol rate of 2
Msymbols/s (CRC and parity are calculated and do not add any
information).

In the second case CRC and parity are part of the information you
want to send over the channel, but your channel is not 
error free.

Another very wrong statement here was : "bits are bits".
A Bit in a computer is a symbol with 2 possible values.
A Bit in information theory and in Shannons formula is the unit for
information (something new you did not know before).

It seems like a paradoxa. but a bit in a computer can hold 
maximum 1 bit information. 
If a computer bit is always cleared and you know that, it  hold
0 bits of information.

Best rega   
Falser Klaus
R&D Electronics Department
Company	: Durst Phototechnik AG
	Vittorio Veneto Str. 59
	I-39042 Brixen
Voice	: +0472/810235
	: +0472/810111
FAX	: +0472/830980
Email	: kfalser@IHATESPAMdurst.it 

Article: 30913
Subject: Re: FPGA application survey question
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Thu, 03 May 2001 11:15:56 +0200
Links: << >>  << T >>  << A >>
> My question to you folks out here, how many folks use FPGAs to prototype
> ASIC or other digital logic?  I see countless posts relating to
> implementing
> certain functions on FPGAs...is that what you guys are doing?

Here is some data that Xilinx presented at ISPD 2001
http://www.ispd.cc/presentations/13_1.pdf

From Slide 11
  3% Emulation
30% Prototyping
30% Pre-Production
37% Production

This means that 67% of all FPGAs actually end up in products.

Kolja Sulimma


Article: 30914
Subject: Re: FPGA based PCI cards
From: "Marc Faure" <faure@datacube.com>
Date: Thu, 3 May 2001 11:42:27 +0200
Links: << >>  << T >>  << A >>
Check out Datacube's web site (www.datacube.com) for the MaxVideo2000 PCI
board. It includes a large Virtex-E, a lot of memory and it's dedicated to
image processing applications.

Marc

James Brennan <s369272@student.uq.edu.au> wrote in message
news:9cqr2h$gon$1@bunyip.cc.uq.edu.au...
> I'm a final year engineering honours student, preparing to do some image
> processing thesis work on an FPGA.
>
> I'm interested in PCI cards that have been designed for FPGA-based image
> processing (e.g. relatively simple PCI interface, substantial amount of
> SRAM). I'm probably leaning toward using one of the Xilinx Virtex
> architectures.
>
> If you are using such a PCI card and are happy with it, could you reply to
> this post with the card's name and manufacturer (and your opinion of the
> card)?
>
> Thanks,
>
> James Brennan.
> I
>
>



Article: 30915
Subject: Re: FPGA based PCI cards
From: Bhupesh <bhupesh_r@rediffmail.com>
Date: Thu, 3 May 2001 04:06:19 -0700
Links: << >>  << T >>  << A >>
I am interested in downloading configuration bit stream into a FPGA
that resides on a PCI card,through the PCI bus. The PCI interface is implemented outside the FPGA as a seperate chip.But connecting this interfacing chip to the FPGA itself requires some handshaking signals from the FPGA which is not possible as long as the FPGA is configured and i don't want to have a serial
ROM on the card that holds the configuration data. Then how will the FPGA get configured on power up
through the PCI interfacing chip?
Please advice.My email id is bhupesh_r@rediffmail.com.
thanks

Article: 30916
Subject: Re: Exemplar: If-elsif synthesises to Muxcy in virtexE
From: bhupesh_rrediffmail.com <>
Date: Thu, 3 May 2001 04:26:06 -0700
Links: << >>  << T >>  << A >>
This is a reply to the query posted by Nisreen Taiyeby.
In the first place, in the code the use of priority encoder in naming the architecture body is highly misleading and exhibits poor documentation.
Secondly, to the best of my knowledge an if else construct would generate priority hardware as
against a multiplexer which is non priotised hardware. 
A single 4-i/p LUT can implement any function with max. 4 i/ps.
In your case u need to select one of the 4 i/ps at the o/p. which needs 2 select lines making the total number of i/s 6, which consumes two first levels of LUTs.
Also since u require one o/p. the o/ps of the first 2 LUTs has to be 
multiplexed which is implemented in the 3rd LUT being inferred at the 
second level.
Hence i guess the hardware being inferred by your synthesizer is correct in all respects.
Please mail me ur feedback.
My id is bhupesh_r@rediffmail.com

Article: 30917
Subject: Re: Virtex-E HDL -- Possible to clock register directly from ibuf?
From: Bhupesh <bhupesh_r@rediffmail.com>
Date: Thu, 3 May 2001 05:21:07 -0700
Links: << >>  << T >>  << A >>
This is in reply to Matt's query.
Since u r using a global clock signal in ur design it has to essentially be routed through the global buffer, because the global signals have a large fan out and hence need to be buffered.
If u modify ur design so that the global clock signal is not used only then will u be able to skip the global buffer.
best regards
bhupesh
bhupesh_r@rediffmail.com

Article: 30918
Subject: Re: ccd imaging with fpga
From: martinb@magma.ca (M.B.)
Date: Thu, 03 May 2001 12:22:13 GMT
Links: << >>  << T >>  << A >>
Do you have any suggested part# and manufacturers of any drams that
might work.?
I have a simple cct now that can scan a 256k (262,144 cell) dram. but
any avalible size could do.

On Thu, 3 May 2001 00:47:15 -0400, "Austin Franklin"
<austin@darkroo87m.com> wrote:

>Actually, we did this at Micron in 1984...just mounted a DRAM in a clear
>plastic package.  Problem is, it is only line art...no gray scale...unless
>you did multiple exposures with a different aperture setting.
>
>"Michael Strothjohann" <strothjohann@rheinahrcampus.de> wrote in message
>news:3AEFF103.81165A24@rheinahrcampus.de...
>> Probably the device is like the one in an
>> old BYTE-article ( over one decade ago ):
>> an DRAM was opened and the
>> precharged C's are decharged by the incoming
>> photons. The picture reflects the chip-structure,
>> but the low-cost ('home-made') device realy works.
>> michael strothjohann
>>
>>
>> Victor Schutte schrieb:
>>
>> > About a year ago I read an article on a new image device that looks like
>RAM
>> > (manufactured by HP). You don't need to design high speed CCD circuitry
>and
>> > device drivers for Windoze.  You can use something as simple as a 8051
>uC,
>> > scan the device and then send the data to the PC via RS232.
>> >
>> > Unfortunately I do not know the part number or the price (which can
>probably
>> > be very high). I know the part exists. If anyone has more details on
>this
>> > please post.
>> >
>> > "M.B." <martinb@magma.ca> wrote in message
>> > news:3aeeb905.4091345@news.magma.ca...
>> > > Hi I have a telescope and some basic experiance with VHDL, FPGAs.
>> > > I would like to get a CCD (something common and cheap) and use a FPGA
>> > > perhaps a xilinx or atmel with VHDL. and interface to my computer (win
>> > > 98.
>> > >
>> > > Has anyone done somthing like this?
>> > > Is there a project in any books or wed sites that you have seen that
>> > > could get me started?
>> > >
>> > > Or is there a development kit from one of the CCD Manufacturers that I
>> > > could look into?
>> > >
>> > >
>>
>
>


Article: 30919
Subject: Re: Something about the counter
From: Bhupesh <bhupesh_r@rediffmail.com>
Date: Thu, 3 May 2001 05:30:49 -0700
Links: << >>  << T >>  << A >>
Hi 
U've specified that ur ucf file was empty.
An empty ucf file in the Xilinx tool means that the implementation tool will not put in any efforts on its part to improve timing.
Probably u need to enter some timing constraints only on ur clock signal if its a counter design using the TIMESPEC keyword.
As far as the other query regarding the prescalers is concerned there are available with the xilinx tool
certain logiblox available and in fact they can be programmed to divide the input clock by the required amount.
best regards
bhupesh
bhupesh_r@rediffmail.com

Article: 30920
Subject: Re: Shannon Capacity
From: nemo@dtgnet.com (Nemo)
Date: Thu, 03 May 2001 13:21:40 GMT
Links: << >>  << T >>  << A >>
kfalser@REMOVETHISdurst.it (Klaus Falser) wrote:

<<BIG SNIP>>

>
>In my opinion, most confusion here comes from the fact, that some
>people considers the CRC and parity coding/decoding part of the 
>channel, and others do not.

No, I think that the confusion here is that people want to talk about the
Shannon limit (also known as Shannon-Hartley theorem) without actually having
read/studied/digested the source material.  
>
>Personally I would opt for making the coding/decoding part of the
>channels, since it gives you a "better" channel. 
>In this case and in the above example you have 1 MBit/s information
>rate (Bits you are free to choose), but you have a symbol rate of 2
>Msymbols/s (CRC and parity are calculated and do not add any
>information).

It's not up to you to "opt" for making it part of the channel - this is a
discussion of Shannon's work, and we have to go by his definition's, and
assumptions.  The discussion is about the Shannon limit, and the Shannon limit
for a given band-limited channel is very strictly defined. 

>
>In the second case CRC and parity are part of the information you
>want to send over the channel, but your channel is not 
>error free.
>
>Another very wrong statement here was : "bits are bits".
>A Bit in a computer is a symbol with 2 possible values.
>A Bit in information theory and in Shannons formula is the unit for
>information (something new you did not know before).

No, in the formula we are discussiing, bits *are* bits.  Shannon does not define
these any diferently than anyone else.  Shannon *does* use the term *symbol*
extensively to describe a disctrete piece of information transmitted through the
channel.  A symbol can represent any number of bits, or even an entirely
abstract "piece of information", but abstract thinking is something many here
seem to be having trouble with.  

When discussing information symbols, the maximum symbol rate that can be
supported on a given channel is simply 2xB symbols per second (where B is the
bandwidth).   If we consider that each symbol can represent multiple (M) bits of
information, then the equation for maximum capacity of the baseband channel
becomes:

C = 2*B*log2(M)  bps

If we want to consider the effects of AWGN on a band-limited channel (i.e. a
finite S/N), then the equation becomes the one we have been discussing in this
thread:

C = B*log2(S/N+1) bps

In the later two equations, BITS are BITS and symbols have been removed from the
discussion.
>
>It seems like a paradoxa. but a bit in a computer can hold 
>maximum 1 bit information. 
>If a computer bit is always cleared and you know that, it  hold
>0 bits of information.
>

Hope that helps.
Best regards
Nemo

>Best rega   
>Falser Klaus
>R&D Electronics Department
>Company	: Durst Phototechnik AG
>	Vittorio Veneto Str. 59
>	I-39042 Brixen
>Voice	: +0472/810235
>	: +0472/810111
>FAX	: +0472/830980
>Email	: kfalser@IHATESPAMdurst.it 


Article: 30921
Subject: Re: Comparison of FPGA and DSP
From: Ray Andraka <ray@andraka.com>
Date: Thu, 03 May 2001 13:43:43 GMT
Links: << >>  << T >>  << A >>


Steve Bradshaw wrote:
>> As Ray already commented, 1000:1 is at the extreme end of potential
> performance gain. Quoting a 10:1 through 1000:1 performance gain range
> though is a bit on the vague side, don't you think Ray ? [I like the web
> site though, I'll have to check it out when I get back in the office next
> week]

Fact of the matter is the gains really do run this range, and much depends also
on the performance target.  It is very easy to trade hardware for performance in
an FPGA.  If I dig through past conference papers etc, I can cite specific
examples where the gains are more than 1000:1.  As I mentioned, I am typically
applying FPGAs in applications where the requirements dictate somewhere around
100:1 (thus the design point).  Many of these are in smaller FPGAs, and much
higher processing gains can be made with larger parts.  The processing gain I am
quoting is the performance measured as the time required to complete the task as
compared with other solutions.

FPGAs do fit a rathter wide class of problems in the DSP space.  Basically
anything that subjects a large or streaming dta set to the same or similar
processes is suitable for FPGA implementation.


> 
> I'd be careful about comparing GOPS, BOPS, and whatever other clock rate
> multiplied by the number of arithmetic units and the like with logic cells.
> It won't help. Besides, it's really just part of a very sophisticated
> marekting language that doesn't mean very much :^) What you really need to
> do is compare what people are achieving for specific algorithms. I'm not
> really familiar with Intel performance capabilities for DSP but Texas
> Instruments and Xilinx have lots of figures on their web sites, where you
> see what their respective approaches will allow for such things like
> Filters, FFTs, etc... You'll should find some good performance gains on
> anything FIR related, such as decimation, down conversion, etc...
> 
> Rays web site is clearly biased towards the FPGA approach. I certainly go
> along with the FPGA offering some substantial gains over DSPs, but it really
> depends on the situation. In the situations where you can exploit
> parallelism at the logic level, the FPGAs will blow DSPs away. You'll
> probably find that this isn't always the case though, and there are many
> advantages for using a DSP also.
> 
>
-- 
-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

Article: 30922
Subject: Re: ccd imaging with fpga
From: "Erik Widding" <widding@birger.com>
Date: Thu, 03 May 2001 13:57:51 GMT
Links: << >>  << T >>  << A >>
"M.B." <martinb@magma.ca> wrote in message
news:3af14d0a.70056665@news.magma.ca...
> On Thu, 3 May 2001 00:47:15 -0400, "Austin Franklin"
> <austin@darkroo87m.com> wrote:
>
> >Actually, we did this at Micron in 1984...just mounted a DRAM in a clear
> >plastic package.  Problem is, it is only line art...no gray
scale...unless
> >you did multiple exposures with a different aperture setting.
>
> Do you have any suggested part# and manufacturers of any drams that
> might work.?
> I have a simple cct now that can scan a 256k (262,144 cell) dram. but
> any avalible size could do.

This used to work, because back in 1984, DRAMs were much simpler.

In 1984 if a DRAM tested as anything less than "all good", it was considered
bad.  Today, if a DRAM tests as less than all good, it is fixed by swapping
in row(s) from somewhere else on the chip to replace the row(s) with failed
bits.  Process geometries are being pushed so far, that there is
satistically almost zero probability that an "all good" part will be
produced.  If there is a reasonably high probability of producing all good
parts, it is time to shrink your geometry.  This is one of the reasons fabs
look at FPGAs as a better indicator, than DRAM, of a clean process.  Very
few FPGAs (if any) employ redundancy to correct for fab defects.  Very few
tight geometry memory parts do not employ redundancy.

Today, many DRAM manufacturers store true data in some areas of the die, and
complement data in other areas, for a variety of reasons.  If you look at
the data out of a DRAM that has been just powered up, you will see a
somewhat regular pattern.  This is one reason why.  The irregularities in
the patterns, and differences in this pattern from part to part, are in many
cases due to the redundancy having been invoked.

CMOS image sensors have a very similar structure to DRAM.


Regards,
Erik Widding.


--
Birger Engineering, Inc.  --------------------------------  781.481.9233
38 Montvale Ave #260; Stoneham, MA 02180  -------  http://www.birger.com




Article: 30923
Subject: PCI bridge core
From: "Miha Dolenc" <mihad@opencores.org>
Date: Thu, 3 May 2001 16:16:44 +0200
Links: << >>  << T >>  << A >>
Hi!

    I'm a member of OpenCores group and we are designing a free PCI bridge
IP core that would target FPGA and ASICs. If anyone is interested in helping
us out in our effort is very welcome.
You can read more about it on our website

www.opencores.org

where you can also subscribe to our mailing lists.
Any kind of help is welcome - advices, HDL design, verification,
documentation.
Languages we use for our cores are Verilog and VHDL.

We already have a part of specification ready and are still working on it,
so anyone interested can download it from our site (
http://www.opencores.org/cgi-bin/cvsget.cgi/pci/docs/pci_specification.pdf )
. Comments, feedback, advice are welcome.

Regards,
    Miha Dolenc



Article: 30924
Subject: Re: Serial UART
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Thu, 03 May 2001 14:22:56 GMT
Links: << >>  << T >>  << A >>
Peter,
That's all true, but we have to design what the customer wants.  Sometimes,
there are good reasons for putting "doubly programmable" circuitry in the
Xilinx, such as making an ASIC prototype, or, in this case, making a
drop-in-replacement clone for obsoleted chips.

It's surprising though, how many customers just don't get the reconfigurable
aspect of the FPGA.  There are a lot of applications like a UART in which a
customer will only be using it in one configuration to be determined right
after startup, such as 4800baud, 8 data bits, no parity bits, one stop bit.
Variables like this should be set "pre-synthesis" to allow the use of a
smaller part and remove unneeeded logic from the critical path, and then the
appropriate bitfile should be loaded when required.  Yet most customers want
all mutually exclusive modes to be present in the Xilinx at the same time as
though it were an ASIC.

-Kevin, IDS

"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3AF09619.EA685F70@xilinx.com...
> There is something weird about implementing a standard UART in an FPGA.
> A UART is a standard chip, endowed with all the programmable registers to
adapt
> it to particular requirement. Throwing that design onto an FPGA means that
you
> are double-programmable, and double inefficient.
> The FPGA user knows (usually) whether parity is odd or even, how many stop
bits,
> how large a FIFO, etc.
> Controlling all this with registers doesn't make sense when you use an
> inherently programmable technology.
>
> Peter Alfke, Xilinx Applications
> =========================
> Kevin Neilson wrote:
>
> > Insight Design Services has Verilog source that functions similarly to
the
> > Mot MC145428, which is a serially-interfaced UART.  Not free, though.
> >
> > "Mark Walter" <maw@nospam.com> wrote in message
> > news:1ALH6.226933$GV2.47295492@typhoon.san.rr.com...
> > > Does anyone know of where I can find a free Verilog source code for a
> > Serial
> > > UART that can be used in a Xilinx XC4005XL FPGA? I am in need of such
code
> > > to add to a FPGA design I am making for remote access to the FPGA
CPU...
> > >
> > > Thanks,
> > > Mark
> > >
> > >
> > >
>
>





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