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 30925

Article: 30925
Subject: Re: Serial UART
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 03 May 2001 09:57:37 -0700
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:

> 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.

One way to do this (assuming you have the source code) 
is to comment and change the register declarations from an
array of signals to an array of constants and comment
out the register process.

This way you keep the options documented, but let
synthesis cut out those functions not being used 
and hard-wire those that are.


 -Mike Treseler

Article: 30926
Subject: Re: Serial UART
From: Jim Poder <Jim.Poder@wireless-networks.com>
Date: Thu, 03 May 2001 10:27:11 -0700
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

> 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.

while this is true, these types of assumptions make me very nervous. 
The second you fix the UART parameters, someone (probably marketing) 
will tell you that your design will talk to another device, which needs 
XX parameters.  If you haven't planed for this from the beginning, you 
might be up shit creek!  Besides, it is much easier from a SW point of 
view to have a standard interface to program (or port code) to.  i.e. 
16550, 16750, etc.  Although the driver that I just finished for a 
TI16C752 under the ThreadX RTOS was quite a bitch.  Makes me wonder if 
anyone thought before designing these parts (several undocumented gotchas).

That having been said, the best (non-standard) UART that I have seen is 
in Atmel's microprocessors (AT91??????)  Rather than putting in FIFOs 
they have pointer and counter registers (kind of a DMA thing).  It is 
really great from a programmers point of view!  Just write a pointer to 
your buffer in memory and away you go!  I don't know what would be 
involved with programming this in an FPGA would be, though, as I am new 
to VHDL and FPGAs, but am climbing the learning curve as fast as I can.

In (limited) answer to the original poster, I noticed several several 
free UART designs in the various "open" web pages such as opencores, and 
freeIP (I think).  Anyway, they were links off of the FAQ.

jim



Article: 30927
Subject: Re: Serial UART
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Thu, 03 May 2001 21:30:49 +0200
Links: << >>  << T >>  << A >>
> while this is true, these types of assumptions make me very nervous.
> The second you fix the UART parameters, someone (probably marketing)
> will tell you that your design will talk to another device, which needs
> XX parameters.  If you haven't planed for this from the beginning, you
> might be up shit creek!

Same problem for building an ASIC. If you keep your frequency programmable
you have only 20 combinations of options left. Some of them even are compatible.
(8S1 and 8N2 for example are  identical, 8N1 can receive 8N2 transmissions...)


> Besides, it is much easier from a SW point of
> view to have a standard interface to program (or port code) to.  i.e.
> 16550, 16750, etc.

There are two options for this:
The first one is to implement a subset with a register interface that is
compatible to the standard chip as long as only a defined subset of options
is set. Write to these configuration bits will just be ignored.
We needed for example a 8255 that is always in Mode 1.

Another option is to keep the part that receives and sends data compatible,
but replace the configuration part. This leaves a well defined portion of the
driver that needs to be rewritted to load multiple configuration into the FPGA.
But most of the driver does not need to be touched.

BTW:.If you have a look a  the verious GETTYs for Unix/Linux/BSD you will
notice that most of them only support a small subset of the UART options.

Kolja Sulimma


Article: 30928
Subject: EEjobs@yahoogroups.com
From: "Compilit" <compilehr@yahoo.com>
Date: Thu, 3 May 2001 12:45:03 -0700
Links: << >>  << T >>  << A >>
All recruiters.

Please do not use this newsgroups to post your job adds.

Please use

http://groups.yahoo.com/group/EEJOBS





Article: 30929
Subject: Re: Shannon Capacity
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Thu, 03 May 2001 20:46:11 GMT
Links: << >>  << T >>  << A >>
Guys, I was hoping for more of a consensus!  I have done a tally, and it
seems that members of the "bits are bits" group (those that believe C refers
to ALL bits per second) number two, namely Austin and Nemo.

The "bits are information" group (those that believe C refers to  bits of
INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my
colleagues Rob and Dr. Bob.

The latter theory has more proponents and seems to be more elegant, though
neither of those are great reasons for taking a side.  I've read textbooks,
which have not been enlightening, so I'll just have to read Shannon's paper
before I make any final conclusions.

-Kevin



Article: 30930
Subject: Re: Shannon Capacity
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 03 May 2001 14:41:10 -0700
Links: << >>  << T >>  << A >>

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

Kevin,

I had no idea Shannon was so misunderstood.

Actually, I am kidding: I know exactly how well misunderstood Shannon is (was).

I know the consultants will continue to make a fortune for their understanding
(or lack of understanding) of this subject.  Caveat Emptor!

I am reminded of the Psychiatrists in "Hitch-Hiker's Guide to the Galaxy" who
have the Earth destroyed to prevent the "answer to the universe and everyhting"
from being found.  If you know the answer, who needs the psychiatrist?

While the answer is being sought in the very beginning, before it was actually
found, two psychiarists realize they and many of their descendents can make a
fortune by continuing the controversy.....

Enjoy

Austin

Kevin Neilson wrote:

> Guys, I was hoping for more of a consensus!  I have done a tally, and it
> seems that members of the "bits are bits" group (those that believe C refers
> to ALL bits per second) number two, namely Austin and Nemo.
>
> The "bits are information" group (those that believe C refers to  bits of
> INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my
> colleagues Rob and Dr. Bob.
>
> The latter theory has more proponents and seems to be more elegant, though
> neither of those are great reasons for taking a side.  I've read textbooks,
> which have not been enlightening, so I'll just have to read Shannon's paper
> before I make any final conclusions.
>
> -Kevin

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Kevin,
<p>I had no idea Shannon was so misunderstood.
<p>Actually, I am kidding: I know <b>exactly</b> how well misunderstood
Shannon is (was).
<p>I know the consultants will continue to make a fortune for their understanding
(or lack of understanding) of this subject.&nbsp; Caveat Emptor!
<p>I am reminded of the Psychiatrists in "Hitch-Hiker's Guide to the Galaxy"
who have the Earth destroyed to prevent the "answer to the universe and
everyhting" from being found.&nbsp; If you know the answer, who needs the
psychiatrist?
<p>While the answer is being sought in the very beginning, before it was
actually found, two psychiarists realize they and many of their descendents
can make a fortune by continuing the controversy.....
<p>Enjoy
<p>Austin
<p>Kevin Neilson wrote:
<blockquote TYPE=CITE>Guys, I was hoping for more of a consensus!&nbsp;
I have done a tally, and it
<br>seems that members of the "bits are bits" group (those that believe
C refers
<br>to ALL bits per second) number two, namely Austin and Nemo.
<p>The "bits are information" group (those that believe C refers to&nbsp;
bits of
<br>INFORMATION per second) number five, namely Bernie, Steve, Klaus, and
my
<br>colleagues Rob and Dr. Bob.
<p>The latter theory has more proponents and seems to be more elegant,
though
<br>neither of those are great reasons for taking a side.&nbsp; I've read
textbooks,
<br>which have not been enlightening, so I'll just have to read Shannon's
paper
<br>before I make any final conclusions.
<p>-Kevin</blockquote>
</html>

--------------58048A6B68A02CA81D8EDEF1--


Article: 30931
Subject: Re: High resolution time measurement?
From: Richard Dungan <postmaster@127.0.0.1>
Date: Thu, 03 May 2001 22:44:11 +0100
Links: << >>  << T >>  << A >>
Jonas Thor <thor.NO@SPAM.sm.luth.se> wrote:

>Hello!
>
>This is a not well defined question, but I'll ask anyway... I want to
>measure, with high precision, the time between two rising edges of two
>pulses. I have a reference clock, frequency F, of about 5-10 MHz, but
>I need measurements much more accurate than 1/F. (The rising edges are
>of course asynchronous to the reference clock.)
>
>What can I do in a FPGA get the best precison? What's the best I can
>do without a DLL and with a DLL?

The following is based on recollections of some equipment that I worked
on several years ago, so I am happy to be corrected:

This system was a microwave pulsed range measuring system, and the
accuracy was improved by making repeated measurements. Effectively a
counter was started when a pulse was transmitted and was stopped when it
was received. The counter was not cleared, but was allowed to count up
again during the next "two way" time. This was done 100 times in all,
then the accumulated count was used in the final range measurement.

I'm sure that such a system is vulnerable to "accidental" synchronous
problems, but it worked very well.

Richard

------------Richard Dungan-------------
Radix Electronic Designs, Orpington, UK
   richardATradix-designDOTcoDOTuk
---------------------------------------

Article: 30932
Subject: Re: Comparison of FPGA and DSP
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Thu, 03 May 2001 21:52:54 GMT
Links: << >>  << T >>  << A >>
For the example of gene-sequence correlation, the accelleration figure given
by Compugen for their hardware is 725.  That is, they say the FPGA solution
correlates a 1-kilobase sequence to the 700 million bases in GenBank in 8
minutes vs. 4 days for a UNIX workstation.

Granted, a UNIX workstation isn't a DSP, but a single 1kilobase correlation
would probably take at least 1000 cycles on a single-ALU DSP and could take
as little as one cycle in a big enough FPGA.

http://compugen.co.il/products/bioxl_tech.htm

-Kevin

"Ray Andraka" <ray@andraka.com> wrote in message
news:3AF1609F.D3DC4481@andraka.com...
>
>
> 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: 30933
Subject: Re: Shannon Capacity
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 03 May 2001 18:19:08 -0700
Links: << >>  << T >>  << A >>
Austin Lesea <austin.lesea@xilinx.com> writes:
> I am reminded of the Psychiatrists in "Hitch-Hiker's Guide to the
> Galaxy" who have the Earth destroyed to prevent the "answer to the
> universe and everyhting" from being found.  If you know the answer,
> who needs the psychiatrist?

Philosophers.

"We demand rigidly defined areas of doubt and uncertainty."
          -- Vroomfondle, philosopher in Douglas Adams'
             _Hitchhiker's Guide to the Galaxy_

> While the answer is being sought in the very beginning, before it was
> actually found, two psychiarists realize they and many of their
> descendents can make a fortune by continuing the controversy.....

They don't realize it.  Deep Thought, the computer tasked
with finding the answer, points it out to them.

Article: 30934
Subject: Re: Shannon Capacity
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 03 May 2001 18:34:30 -0700
Links: << >>  << T >>  << A >>
I wrote:
> "We demand rigidly defined areas of doubt and uncertainty."
>           -- Vroomfondle, philosopher in Douglas Adams'
>              _Hitchhiker's Guide to the Galaxy_

Forgot to mention that "rigidly defined areas of doubt and uncertainty"
is in a sense exactly what Shannon has given us.  :-)

Article: 30935
Subject: BUFG output is constant0 at 200MHz in post timing
From: Roger.chen <chenx@263.net>
Date: Thu, 3 May 2001 19:45:11 -0700
Links: << >>  << T >>  << A >>
My design is quite large,the functional simulation is ok.When doing post timing,I found the output 200MHz clock of my clock module is constant "0", later I tried to do timing simulation of clock module seperately,the problem still exists.
      one of  my clock module input clock CLKIN is 50MHz, a DCM is used to generate CLK1X(50MHz),CLK2X(100MHz),CLK4X (200MHz).CLK4X is  output signal  DCM CLKFX  through a BUFGMUX.the design is quite simple ,however, I met following problem during post timing simulation:
  When  I set CLKIN to 50MHz, CLK4X didn't appear,but CLKFX is ok(200MHz);CLKFX is the output of DCM and input of a BUFGMUX,CLK4X is output of this BUFGMUX and output of clock module.
   but when I set CLKIN to 25MHz, CLK4X is ok, my clock module goes well.
  Device family VitrtexII xc2v1000.
  Developing tool: Foundation iSE 3.1i 
  I think the problem lies in BUFGMUX, but I dont konw what to do with.

Article: 30936
Subject: Re: ccd imaging with fpga
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Fri, 04 May 2001 12:59:30 +1000
Links: << >>  << T >>  << A >>
Erik Widding wrote:
> 
> "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.

IIRC, redundant rows were used in Intel's 2164 64k x 1 DRAM, which came
out before 1984.  The technique was described in the 1983 Intel Memory
data book.

Actually, just as hard disks have a table of bad sectors that the
operating system knows to avoid, is there any theoretical reason why a
list of bad resources on an FPGA die can't be fed to to the back end
tools?
(There are plenty of practical reasons why not, of course.)

Regards,
Allan.

Article: 30937
Subject: Re: FPGA application survey question
From: Anonymous Idiot <anonymous_idiot@nowhere.com>
Date: Thu, 03 May 2001 20:57:26 -0700
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.

Wow, I guess that explains why I see so many questions along the lines
of
optimization.

But would it be fair to say that the 'pre-production' applications don't
all end up in retail products?

Article: 30938
Subject: Re: FPGA based PCI cards
From: Anonymous Idiot <anonymous_idiot@nowhere.com>
Date: Thu, 03 May 2001 21:09:51 -0700
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.

There's the AVNET Virtex Development Kit (http://www.ads.avnet.com).
Has several MBs of ZBT (zero-bus-time) SRAM, 16MB SDRAM, and an onboard
256-color (8-bit CLUT) RAMDAC for VGA-output.  The SDRAM probably won't
interest you unless you already have access to an SDRAM-controller core.

funny, it seems to have disappeared from AVNET's inventory list.
Oh well, the VirtexE develpoment kit is less useful to you, because it
has no external SRAM memory (just the 64MB SDRAM.) It's also a bit
expensive ($1400 USD) oh well...

Insight Electronics (http://www.insight-electronics.com) has a very
inexpensive ($150 USD)  PCI Spartan2-150 board.  It has 8MB SDRAM, but
that's it.

> 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)?

Article: 30939
Subject: Re: Serial UART
From: Klaus_Leiss@ccl.hdpp.de (Klaus-Guenter Leiss)
Date: 4 May 2001 06:51:45 GMT
Links: << >>  << T >>  << A >>
In article <1ALH6.226933$GV2.47295492@typhoon.san.rr.com>, maw@nospam.com says...
>
>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
>
>

----------

at http://www.cmosexod.com/ ( follow  FREE IP )

The micro-UART is a fully functional,
synthesizable, universal asynchronous receiver
transmitter core. The core is configurable and
extremely compact.

a full 16450 Compatible  UART is planned

----------

not verilog but vhdl

at http://www.opencores.org/cores/uart/

fixed 9600 baudrate for this version 
1 start bit, 8 data bits, 1 stop bit data stream format 
both interrupt-based and polling user interface

----------

Desciptions are there own. I have tested neither.


Klaus Leiss


Article: 30940
Subject: Re: FPGA application survey question
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Fri, 04 May 2001 10:14:47 +0200
Links: << >>  << T >>  << A >>


Anonymous Idiot wrote:

> > > 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.
>
> Wow, I guess that explains why I see so many questions along the lines
> of
> optimization.
>
> But would it be fair to say that the 'pre-production' applications don't
> all end up in retail products?

The speaker defined these categories in the preceeding slides.
Emulation is what you are doing: Take a VHDL-design and run it in an FPGA
because your Simulator is to slow.

The distinction to the prototyping catagory can be somewhat fluid, but he meant
this to be FPGAs are used to build
boards or systems as proof of princible, testbeds, system test, etc. In this
case the goal is to emulate a whole system
at working speed.

Pre-Production in his sense are systems that are manufacture with FPGAs to be
replaced by ASICs later, when the
ASICs finally come out of the fab, or when it turns out the system was
successful enough to justify ASIC NREs.
So all these 30% end up in products.

The final 37% are FPGAs that are used in designs that are meant to be FPGA base
throughout there whole lifecycle. (Do a search on eBay. Usualy there are some
offers for SCSI controllers with XILINX chipsets. I also own a highend soundcard
based on XCS40.)

Of course there are much more prototyping DESIGNS done in FPGAs than anything
other, but I am surprised that 30% of the CHIPS sold in a huge market end up in
prototypes.

Kolja Sulimma






Article: 30941
Subject: Re: Translator from Xchecker´s files to PROM´s files.
From: "Mike Johnson" <mikej@freeuk.com>
Date: Fri, 4 May 2001 09:31:39 +0100
Links: << >>  << T >>  << A >>
I assume you targeting Xilinx devices if you are using Xchecker, so
you can use either promgen (command line) or promfmtr (gui) in the xilinx
tool set.


Segis <segisweb@jazzfree.com> wrote in message
news:sjFH6.6090$q7Tm.76677254@news.jazztel.es...
> Hi,
> We´re an University searching team and we´re working on FPGA technology.
> We´ve developed a program to be downloaded into our FPGA desing by the
> Xchecker cable. Now, we´d like to keep our program in a PROM. But,
> unfortunately, we don´t know how to translate our FPGA file into a PROM
file
> to be downloaded to the PROM.
> We´re looking for information about a translator program (SW) and any
useful
> tips related to that. Do you know something about that? Would you mind
> helping us?
>
> Thank you so much for your help!.
>
> Best regards,
>
> Segismundo Alonso
>
>
> P.S. Send your reply to segisweb@jazzfree.com
>
>



Article: 30942
Subject: CompactPCI card with Virtex
From: Steven Sanders <sanders@imec.be>
Date: Fri, 04 May 2001 11:18:33 +0200
Links: << >>  << T >>  << A >>
Hello,

Any pointers where to find a 'simple' CompactPCI card with a 
Xilinx Virtex and a minimum of 32MBit RAM?

thanx,

Steven

Article: 30943
Subject: Configuration Problems: Newbie
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Fri, 4 May 2001 12:48:30 +0200
Links: << >>  << T >>  << A >>
Hi,

I have a Digilab XLA3 with Spartan XL FPGA on board. I've used the test
utility on the digilent site, and the FPGA configures fine. Now, I have used
their test design, and implemented a very simple design of my own, in the
Xilinx Foundation series environment. The designs are fine, but when I try
to program using the JTAG programmer (using parallel cable), it can't
configure the FPGA, saying :

Loading Boundary-Scan Description Language (BSDL) file
'C:/Utils/Xilinx/spartan/data/xcs10_pc84.bsd'.....completed successfully.
Checking boundary-scan chain integrity...ERROR:JTag - Boundary-scan chain
test failed at bit position '2' on instance 'firstled(Device1)'.
 A problem may exist in the hardware configuration.
 Check that the cable, scan chain, and power connections are intact,
 that the specified scan chain configuration matches the actual hardware,
and
 that the power supply is adequate and delivering the correct voltage.
ERROR:JTag - Boundary scan chain has been improperly specified.  Please
check your configuration and re-enter the boundary-scan chain information.
Boundary-scan chain validated unsuccessfully.
ERROR:JTag - : The boundary-scan chain has not been declared correctly.
 Verify the syntax and correctness of the device BSDL files, correct the
files,
 reset the cable and retry this command.
ERROR:JTag - Unable to automatically identify the composition of the
boundary-scan chain.
 A problem may exist in the hardware configuration.
 Check that the cable, scan chain, and power connections are intact,
 that the power supply is adequate and delivering the correct voltage.

HELP!!!!!!!!!!!!!!

Thanks

Adrian




Article: 30944
Subject: Use of record type in a hierarchical architecture
From: Olivier MALLINGER <omallinger@celogic.com>
Date: Fri, 04 May 2001 14:41:53 +0200
Links: << >>  << T >>  << A >>
In an application, we try to use record type in an architecture with
several levels. This record type has to replace several signals that are

assigned at the lowest level of the architecture and go to the highest
level of the architecture, as this :

-level 0 (highest in the architecture)
    -level 01
        -level 011
        -level 012
        -level 013
    -level 02
        -level 021
        -level 022
        -level 023
    -level 03

The new type declared in a package is :

type X is
record
 X1 : std_logic;
 X2 : std_logic_vector(3 downto 0);
 X3 : std_logic;
 X4 : std_logic;
end record;

The goal is that the entity become smaller to be more readable.

We declare new signals of type X in each level of the architecture, as
input and as output (X011 in level 011, X012 in level 012, ...). For
example, I assigned X011.X1 in level 011, X012.X2 in level 012 and
X013.X3 in level 013.
If the signals are input, the use of record type doesn't make any
problem nor in simulation, nor in synthesis.
As ouput, many problem appear. The instantation in level 01 of a X type
signal with X type output signals of level 011, 012 and 013 shows bus
conflicts (whereas each agregate in the signal of level 01 is only
driven by one signal in the sublevels).

In simulation, we found a solution. It's to initialize all the signals
with 'Z', to use the resolution function of std_logic type, which can
resolve these conflicts because 'Z' is the lowest priority in this
function.We use Innoveda Speedwave to simulate our design.

In synthesis, the same problem appear but the bus conflict cannot be
resolved and it's impossible to synthetize our design. We use FPGA
Express to synthetize our design.

Is there another solution to use record in an architecture like this
(don't speak about bus vector to concatenate signal, it's unreadable...)

Thanks.

P.S. : Please, send answer to my email address below too.
----------------------------------------------

Olivier MALLINGER                     CELOGIC
Hardware Design Engineer              http://www.celogic.com
Phone : (33-1) 30 69 15 30            Z.A. de Pissaloup, Rue E. Branly
Fax   : (33-1) 30 69 88 15              BP 33
e-mail : omallinger@celogic.com      78192 TRAPPES cedex - FRANCE



Article: 30945
Subject: Re: CompactPCI card with Virtex
From: "Bill Blyth" <bb@alphadata.co.uk>
Date: Fri, 4 May 2001 13:43:06 +0100
Links: << >>  << T >>  << A >>
Steve,

You could marry our ADM-XRC PMC card with a low cost carrier from Ziatech or
Vmetro.

Bill
http://www.alphadata.co.uk


"Steven Sanders" <sanders@imec.be> wrote in message
news:3AF273E9.86B2D56E@imec.be...
> Hello,
>
> Any pointers where to find a 'simple' CompactPCI card with a
> Xilinx Virtex and a minimum of 32MBit RAM?
>
> thanx,
>
> Steven



Article: 30946
Subject: Re: Shannon Capacity
From: nemo@dtgnet.com (Nemo)
Date: Fri, 04 May 2001 13:26:25 GMT
Links: << >>  << T >>  << A >>
---->PANIC! <-----


Austin Lesea <austin.lesea@xilinx.com> wrote:

>Kevin,
>
>I had no idea Shannon was so misunderstood.
>
>Actually, I am kidding: I know exactly how well misunderstood Shannon is (was).
>
>I know the consultants will continue to make a fortune for their understanding
>(or lack of understanding) of this subject.  Caveat Emptor!
>
>I am reminded of the Psychiatrists in "Hitch-Hiker's Guide to the Galaxy" who
>have the Earth destroyed to prevent the "answer to the universe and everyhting"
>from being found.  If you know the answer, who needs the psychiatrist?
>
>While the answer is being sought in the very beginning, before it was actually
>found, two psychiarists realize they and many of their descendents can make a
>fortune by continuing the controversy.....
>
>Enjoy
>
>Austin
>
>Kevin Neilson wrote:
>
>> Guys, I was hoping for more of a consensus!  I have done a tally, and it
>> seems that members of the "bits are bits" group (those that believe C refers
>> to ALL bits per second) number two, namely Austin and Nemo.
>>
>> The "bits are information" group (those that believe C refers to  bits of
>> INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my
>> colleagues Rob and Dr. Bob.
>>
>> The latter theory has more proponents and seems to be more elegant, though
>> neither of those are great reasons for taking a side.  I've read textbooks,
>> which have not been enlightening, so I'll just have to read Shannon's paper
>> before I make any final conclusions.
>>
>> -Kevin


Article: 30947
Subject: Re: Shannon Capacity
From: nemo@dtgnet.com (Nemo)
Date: Fri, 04 May 2001 13:59:20 GMT
Links: << >>  << T >>  << A >>
Interesting - I see two basic questions in this thread.  The first was (restated
in my own words):

 (1) When we calculate the maximum capacity of a bandlimited channel in the
presence of AWGN does the answer include all bits transmitted on the channel
(payload plus parity, headers, etc.) or not?

The second question raised later in the thread seems to be:

 (2) Do the units indicated in above equation (bits-per-second) represent binary
1's and 0's bits in the conventional sense, or are the units (bits) these
generic information "symbols" that Shannon is always referring to?

Regarding the second question, here is a quote from page 1 of Shannon's paper, A
Mathematical Theory of Communication:

"If the  base 2 is used the resulting units may be called binary digits, or more
briefly bits, a word suggested by
J. W. Tukey."

He clearly defines "bits" to mean binary digits of a base 2 numbering system
(which is just the way we all understand bits).  So when we see "bits per
second" used in one of Shannon's equations, we can be rest assured that we are
talking about good old binary digits.


Regarding Question #1 above, I tried to briefly follow Shannon's development
from general information "symbols" to the capacity equation (in bps) we were
discussing.  In terms of whether these bits include parity and header, or are
only the desired information, well you'll have to read the paper.  But I can say
that in my understanding, this equation represents the maximum capacity of the
*total* number of bits (regardless of what they represent - parity, data,
headers, ...) travelling through the channel. The challenge of the
communications and/or DSP engineer is to implement coding and modulation
techniques that approach this theoretical limit in real-world appplications for
a given bandlimited channel.


"Kevin Neilson" <kevin_neilson@yahoo.com> wrote:

>Guys, I was hoping for more of a consensus!  I have done a tally, and it
>seems that members of the "bits are bits" group (those that believe C refers
>to ALL bits per second) number two, namely Austin and Nemo.
>
>The "bits are information" group (those that believe C refers to  bits of
>INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my
>colleagues Rob and Dr. Bob.
>
>The latter theory has more proponents and seems to be more elegant, though
>neither of those are great reasons for taking a side.  I've read textbooks,
>which have not been enlightening, so I'll just have to read Shannon's paper
>before I make any final conclusions.
>
>-Kevin
>


Article: 30948
Subject: Re: Use of record type in a hierarchical architecture
From: Markus Michel <mmichel@kontronmedical.ch>
Date: Fri, 04 May 2001 16:03:10 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F6D714C7FF8510DF1507B95C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Olivier,

from my experience it is best not to use records for synthesis. One reason
is that you never know exactly how the synthesis tool handles them (as your
problems demonstrate).

Best regards
Markus.

Olivier MALLINGER wrote:

> In an application, we try to use record type in an architecture with
> several levels. This record type has to replace several signals that are
>
> assigned at the lowest level of the architecture and go to the highest
> level of the architecture, as this :
>
> -level 0 (highest in the architecture)
>     -level 01
>         -level 011
>         -level 012
>         -level 013
>     -level 02
>         -level 021
>         -level 022
>         -level 023
>     -level 03
>
> The new type declared in a package is :
>
> type X is
> record
>  X1 : std_logic;
>  X2 : std_logic_vector(3 downto 0);
>  X3 : std_logic;
>  X4 : std_logic;
> end record;
>
> The goal is that the entity become smaller to be more readable.
>
> We declare new signals of type X in each level of the architecture, as
> input and as output (X011 in level 011, X012 in level 012, ...). For
> example, I assigned X011.X1 in level 011, X012.X2 in level 012 and
> X013.X3 in level 013.
> If the signals are input, the use of record type doesn't make any
> problem nor in simulation, nor in synthesis.
> As ouput, many problem appear. The instantation in level 01 of a X type
> signal with X type output signals of level 011, 012 and 013 shows bus
> conflicts (whereas each agregate in the signal of level 01 is only
> driven by one signal in the sublevels).
>
> In simulation, we found a solution. It's to initialize all the signals
> with 'Z', to use the resolution function of std_logic type, which can
> resolve these conflicts because 'Z' is the lowest priority in this
> function.We use Innoveda Speedwave to simulate our design.
>
> In synthesis, the same problem appear but the bus conflict cannot be
> resolved and it's impossible to synthetize our design. We use FPGA
> Express to synthetize our design.
>
> Is there another solution to use record in an architecture like this
> (don't speak about bus vector to concatenate signal, it's unreadable...)
>
> Thanks.
>
> P.S. : Please, send answer to my email address below too.
> ----------------------------------------------
>
> Olivier MALLINGER                     CELOGIC
> Hardware Design Engineer              http://www.celogic.com
> Phone : (33-1) 30 69 15 30            Z.A. de Pissaloup, Rue E. Branly
> Fax   : (33-1) 30 69 88 15              BP 33
> e-mail : omallinger@celogic.com      78192 TRAPPES cedex - FRANCE

--------------F6D714C7FF8510DF1507B95C
Content-Type: text/x-vcard; charset=us-ascii;
 name="mmichel.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Markus Michel
Content-Disposition: attachment;
 filename="mmichel.vcf"

begin:vcard 
n:Michel;Markus
tel;fax:+41 (0)61 336 22 00
tel;work:+41 (0)61 336 22 22
x-mozilla-html:FALSE
org:Kontron Medical AG
version:2.1
email;internet:mmichel@kontronmedical.ch
title:dipl. El'Ing. ETH
adr;quoted-printable:;;Reinacherstr. 131=0D=0AP.O. Box;CH- 4002 Basel;;;Switzerland
x-mozilla-cpt:;5808
fn:Markus Michel
end:vcard

--------------F6D714C7FF8510DF1507B95C--


Article: 30949
Subject: Re: Shannon Capacity
From: nemo@dtgnet.com (Nemo)
Date: Fri, 04 May 2001 14:23:06 GMT
Links: << >>  << T >>  << A >>
This link has a great explanation of the Shannon-Hartley theorem on page 5.
Take careful note of the discussion of Log-base2 and "bits per second".  

http://www.ctr.kcl.ac.uk/Fatincourse/Mobile/fading(mobile).pdf

Hope it helps.
Nemo



nemo@dtgnet.com (Nemo) wrote:

>Interesting - I see two basic questions in this thread.  The first was (restated
>in my own words):
>
> (1) When we calculate the maximum capacity of a bandlimited channel in the
>presence of AWGN does the answer include all bits transmitted on the channel
>(payload plus parity, headers, etc.) or not?
>
>The second question raised later in the thread seems to be:
>
> (2) Do the units indicated in above equation (bits-per-second) represent binary
>1's and 0's bits in the conventional sense, or are the units (bits) these
>generic information "symbols" that Shannon is always referring to?
>
>Regarding the second question, here is a quote from page 1 of Shannon's paper, A
>Mathematical Theory of Communication:
>
>"If the  base 2 is used the resulting units may be called binary digits, or more
>briefly bits, a word suggested by
>J. W. Tukey."
>
>He clearly defines "bits" to mean binary digits of a base 2 numbering system
>(which is just the way we all understand bits).  So when we see "bits per
>second" used in one of Shannon's equations, we can be rest assured that we are
>talking about good old binary digits.
>
>
>Regarding Question #1 above, I tried to briefly follow Shannon's development
>from general information "symbols" to the capacity equation (in bps) we were
>discussing.  In terms of whether these bits include parity and header, or are
>only the desired information, well you'll have to read the paper.  But I can say
>that in my understanding, this equation represents the maximum capacity of the
>*total* number of bits (regardless of what they represent - parity, data,
>headers, ...) travelling through the channel. The challenge of the
>communications and/or DSP engineer is to implement coding and modulation
>techniques that approach this theoretical limit in real-world appplications for
>a given bandlimited channel.
>
>
>"Kevin Neilson" <kevin_neilson@yahoo.com> wrote:
>
>>Guys, I was hoping for more of a consensus!  I have done a tally, and it
>>seems that members of the "bits are bits" group (those that believe C refers
>>to ALL bits per second) number two, namely Austin and Nemo.
>>
>>The "bits are information" group (those that believe C refers to  bits of
>>INFORMATION per second) number five, namely Bernie, Steve, Klaus, and my
>>colleagues Rob and Dr. Bob.
>>
>>The latter theory has more proponents and seems to be more elegant, though
>>neither of those are great reasons for taking a side.  I've read textbooks,
>>which have not been enlightening, so I'll just have to read Shannon's paper
>>before I make any final conclusions.
>>
>>-Kevin
>>




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