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 110375

Article: 110375
Subject: Re: Xilinx documentation typos
From: "rickman" <gnuarm@gmail.com>
Date: 14 Oct 2006 10:47:26 -0700
Links: << >>  << T >>  << A >>
Jeff Cunningham wrote:
> Matthew Hicks wrote:
> > While I like Xilinx and think their docs, if you read enough of them you
> > will find three things
> > 1. Some things that aren't documented enough
> > 2. Some things that aren't documented at all
> > 3. Some things that aren't documented correctly
>
> 4. Some things are documented somewhere, but good luck finding it.

Yes, I went through a discussion in this group a while back about
information that seemed to be missing from the Spartan 3 data sheet,
but in fact was just well hidden.  It was scattered over a large
portion of the document rather than being in one place.  After a lot of
discussion, one of the Xilinx regulars here had the data sheet amended
to help with the problem.  Of course it really needed a thorough review
and much more extensive editing, but that was a start.

I also got Atmel to amend the AT91SAM7S data sheet to include enough
info on the crystal that you can almost spec one to use.

Documentation is often the poor stepchild of a development process.  I
know where I work there are tons of instructions and procedures and
processes on how to prepare documentation.  Then the documents that
result are hard to understand, incomplete and sometimes even wrong.  It
can take forever for them to be updated because there is no incentive
to return to them once they are completed.

Personally I take pride in the documents I prepare.  I never want
anyone to read one of my documents and think it was written by a moron,
even if it was!  ;^)


Article: 110376
Subject: Re: EDIF Design Entry tools
From: Duane Clark <junkmail@junkmail.com>
Date: Sat, 14 Oct 2006 18:07:47 GMT
Links: << >>  << T >>  << A >>
Avion wrote:
> thanks for the help. let me try n i hope it will work. but isn't it
> much easier in schematics to connect signals? is there anyway in
> schematics as well? one way may be to create a schematic of the wrapper
> file u just suggested and then use it. am i right?

After using half a dozen different schematic packages over a period of 
about 20 years, I finally gave up on schematics about 6 years ago. I 
like schematics, but they simply are not portable, and you end up having 
to keep around an old computer and operating system and schematic 
software to support old projects. You really should abandon them; pick 
and use an HDL of some. I personally have never used the Xilinx 
schematic software, so I can give no help on that.

Article: 110377
Subject: Re: FPGA comparision
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 14 Oct 2006 18:26:07 GMT
Links: << >>  << T >>  << A >>
subint wrote:
> Hi,
>         i would like to know which is the best if i want a FPGA ( with
> 150k virtex4 equavalent LUTs) and low cost.
> thanks in advance
> subin

Does your design need to be 150k tightly coupled LUTs running at 400 MHz?

Do you need massive memory?  Any memory?

Consider partitioning your design into several smaller FPGAs, divided up 
per your parallelism or by functional blocks.

You can get 35k LUT FPGAs for a very reasonable price: Lattice ECP2-35, 
Xilinx XC3S1600E, Altera EP2C35.  I choose these parts because I think 
they're more toward the "sweet spot" of the price curve.  You can get 
larger devices in these families from Altera and Lattice or bump up the 
size  in the Xilinx Spartan3 family (as opposed to the 3E just mentioned).

If you need large amounts of on-chip memory or multi gigabit 
communications, the new Lattice ECP2M series warrants serious consideration.

These devices are all designed for cost over speed.  depending on the 
complexity of your system, 66 MHz to 200 MHz system designs are 
achievable, not 400 MHz type speeds.  Typically, higher design speed is 
achieved through careful coding representative of well-seasoned FPGA 
designers.  ASIC designers often don't have the speed pressure that FPGA 
folks have but you can find strong expertise in both camps.

So - how much are you willing to work in order to save money?  Can you 
achieve what you want by improving your design approach (particularly if 
you have a very low system speed) or by creative partitioning into 
multiple FPGAs?

Good luck in your endeavors.

- John_H

Article: 110378
Subject: Re: longest webcase record -- understandably so
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 14 Oct 2006 18:36:32 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
> Funny, I think I understood what you were asking by your second post
> here.  I don't know why Xilinx does not understand.  They seem to want
> to answer the wrong question and then when you tell them they answered
> the wrong question they seem to think *you* are the one that
> misunderstands.
> 
> I have seen this more than once and with more than one person at
> Xilinx.  I don't know if it is a corporate culture thing to not be
> willing to reexamine their thinking or if it is just the individual
> people, but I have seen this on numerous occasions.
> 
> Perhaps if you asked in an extremely detailed way that left no room for
> misunderstanding?  Specify the pin number of the signal you are using
> to keep them from thinking you are using SSTL on the JTAG pins.  Ask
> specifically what the threshold level will be on that pin during
> boundary scan after you have loaded the configuration.  *Do not mention
> any other information that you may think will be helpful if it is not
> required!!!*  Any stray info can result in misinterpretation.  I have
> seen many times that the mention of a piece of information that should
> help to clarify your thinking actually results in alarm bells going off
> on the other side and the discussion goes way off course.
> 
> Good luck!


rickman - I give you kudos for understanding what colin is trying to 
achieve.  I've watched this thread and I'm still confused.  My 
engineering career started in manufacturing where I had extreme interest 
in boundary scan.  Yet, I'm stymied.

The issue of IO standard is external to any registers in an internal 
scan chain.  I couldn't figure out if there was a need to interface to 
the jtag chain in SSTL logic or if there was a perceived internal need 
for the jtag chain to be driven by SSTL to scan SSTL I/O cells.

If the scan was 1) desired before configuration, 2) designed to drive, 
receive, or tristate signals based on the scan chain, or 3) use the 
existing configured design, this casual observer still has no clue.

It seems there are assumptions that aren't discussed in setting up the 
problem that needs to be solved.  Often, assumptions can be determined 
from the context.  If these underlying assumptions are guessed 
incorrectly, the wrong question is answered.

So - any idea what's really needed?

Article: 110379
Subject: Re: FPGA comparision
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 14 Oct 2006 18:45:53 GMT
Links: << >>  << T >>  << A >>
"subint" <subin.82@gmail.com> wrote in message 
news:1160821923.691563.325170@m7g2000cwm.googlegroups.com...
> Hi,
>       Yes i mean 150k LUTs..  i checked all these websites but only
> xilinx is projecting the LUT counts. Altera projecting there features
> with ALM and they saying it's is almost equvalent to 2 slice
> etc.Lattice semiconductors clamming they are better and FAST.
> I am totally confused.
That's because all FPGA/CPLD suppliers use a different 'unit of measure' 
when classifying their devices.  There is currently no good unit of measure 
that can be used to compare across different manufacturers...but read on.

>       By saying low cost i just mean the comparision(if there are more
> than one source with these features).
OK.

>        when i synthesized my project it's taking almost 80% of the
> virtex4(Lx200) ( it have 180kLUTs) . i think lx200 cost about $7000. i
> am looking for a alterative if available....
There are alternatives.  If you have a design and it has been synthesized to 
target Xilinx then 'all you need to do' is take that same design and 
synthesize it to an Altera device family, Lattice device family, Actel, etc. 
When you do this you'll get a report from each synthesis effort that tells 
you how many logic resources of are used.  The units of measure will be in 
whatever units the supplier calls them thus avoiding the generic (and 
sometimes misleading) conversion from brand X units to brand A, brand L, 
brand whatever.

Once you have the tools from the various suppliers (or have something like 
Synplify which can target them all) the process is straight forward.  The 
catch is in the phrase 'all you need to do....'.  If you have taken 
advantage of any Xilinx specific primitives in your design you'll have to 
come up with a vendor neutral approach to eliminate the Xilinx specific 
parts so that you can even run the synthesis to target the other devices.

If you find that you have a 'lot' of Xilinx specific primitives and the 
effort to make the design vendor neutral is too high just to make a 
determination of which device to target than what you can do is come up with 
a vendor neutral design that in some fashion mimics roughly what you want to 
accomplish but maybe doesn't have all of the logic implemented.  Then run 
through the various tools to see how many logic resources get used.  Even 
though what you've synthesized is not your entire design it should be enough 
for you to develop the conversion factors so that you can compare resource 
usage among the various suppliers.

Once you've completed this effort you should be able to say precisely which 
Actel, Altera, Lattice, Xilinx, etc. part your design will fit into and 
compare prices directly.

The other thing to keep in mind when you strip out vendor specific stuff 
though are just what things you're stripping out and if they are 'special' 
to that part.  Things like multipliers and PLLs come immediately to mind 
here.  You'll have to mentally keep track of these 'special' things if the 
other supplier parts don't have them...and what impact that will mean to 
your design if you need them.  For example, multipliers can be synthesized 
with logic cells (but are usually going to be slower than a hard multiplier) 
but PLLs can not be synthesized at all so you're design flat out won't work 
if you need them.

KJ



Article: 110380
Subject: Re: longest webcase record -- understandably so
From: "rickman" <gnuarm@gmail.com>
Date: 14 Oct 2006 11:49:11 -0700
Links: << >>  << T >>  << A >>
John_H wrote:
> rickman wrote:
> > Funny, I think I understood what you were asking by your second post
> > here.  I don't know why Xilinx does not understand.  They seem to want
> > to answer the wrong question and then when you tell them they answered
> > the wrong question they seem to think *you* are the one that
> > misunderstands.
> >
> > I have seen this more than once and with more than one person at
> > Xilinx.  I don't know if it is a corporate culture thing to not be
> > willing to reexamine their thinking or if it is just the individual
> > people, but I have seen this on numerous occasions.
> >
> > Perhaps if you asked in an extremely detailed way that left no room for
> > misunderstanding?  Specify the pin number of the signal you are using
> > to keep them from thinking you are using SSTL on the JTAG pins.  Ask
> > specifically what the threshold level will be on that pin during
> > boundary scan after you have loaded the configuration.  *Do not mention
> > any other information that you may think will be helpful if it is not
> > required!!!*  Any stray info can result in misinterpretation.  I have
> > seen many times that the mention of a piece of information that should
> > help to clarify your thinking actually results in alarm bells going off
> > on the other side and the discussion goes way off course.
> >
> > Good luck!
>
>
> rickman - I give you kudos for understanding what colin is trying to
> achieve.  I've watched this thread and I'm still confused.  My
> engineering career started in manufacturing where I had extreme interest
> in boundary scan.  Yet, I'm stymied.
>
> The issue of IO standard is external to any registers in an internal
> scan chain.  I couldn't figure out if there was a need to interface to
> the jtag chain in SSTL logic or if there was a perceived internal need
> for the jtag chain to be driven by SSTL to scan SSTL I/O cells.
>
> If the scan was 1) desired before configuration, 2) designed to drive,
> receive, or tristate signals based on the scan chain, or 3) use the
> existing configured design, this casual observer still has no clue.
>
> It seems there are assumptions that aren't discussed in setting up the
> problem that needs to be solved.  Often, assumptions can be determined
> from the context.  If these underlying assumptions are guessed
> incorrectly, the wrong question is answered.
>
> So - any idea what's really needed?

I will explain what I think is going on and Colin can correct me if I
am wrong.

They are using a Coolrunner II to interface to an SSTL device.  The
CPLD is first configured, then they want to run boundary scan to test
the board.  In order to assure their customers that boundary scan will
properly verify the connection to the SSTL device, they want to verify
that during boundary scan the CPLD will be using SSTL voltage levels on
the pin that connects to the SSTL device.  This is not one of the JTAG
pins, it is just a general IO pin.

So the question is, will this pin use SSTL signaling during boundary
scan if it is first setup as an SSTL IO during configuration?

Is that clear?

I fully expect the answer is that the pin will be using SSTL voltage
levels during boundary scan.  But I can see where the OP would want to
ask to make sure.  You can never be too sure how chips work internally
regardless of what seems obvious.


Article: 110381
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 14 Oct 2006 12:56:31 -0700
Links: << >>  << T >>  << A >>
Reconfiguration time is measured in ms (especially for a small part).
And, as Austin told you, reconfiguration does not take much current,
probably less than normal operation.
So it all depends on the frequency of reconfiguration (once a minute, a
second, or a ms?) and on the savings in static and dynamic power (and
money) you get from using a smaller part.
No need to generalize, but it should be easy to assess your individual
situation.
Peter Alfke, from home.

On Oct 13, 12:46 pm, pbdel...@spamnuke.ludd.luthdelete.se.invalid
wrote:
> >I've been reluctant recently on envisaging a Virtex-4 device as being
> >operational in a battery-powered situation. The inrush configuration
> >current, high static power consumption, and the non-uniform power
> >exhibited subject to temperature rise are amongst few to name about the
> >shortcomings of SRAM FPGAs in general. Having said that, the
> >unprecedented versatile reconfigurable processing power is yet the
> >decisive factor in prototyping intensive DSP operations. My question
> >is: has any body come across a scenario in which a large FPGA was
> >battery-powered. I'm in the phase of deciding on solutions to employ
> >for my active research so it's quite critical. I don't want to start my
> >research with a major gap in my rationale. Can any veteran in here
> >comment on the topic please. Is it really ridiculous to think about
> >powering a large SRAM FPGA from a battery? Would really appreciate all
> >comments. What's the cheapest price ever a smallest Virtex-4 device was
> >reported?You said Xilinx fpga, but maybe actel's eeprom (?) based fpgas will do better
> for battery applications?


Article: 110382
Subject: Looking for internship near Toronto
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 14 Oct 2006 13:19:16 -0700
Links: << >>  << T >>  << A >>
I am currently in my 3rd year of Electrical Engineering undergrad at
Ryerson University in Toronto, Ontario, Canada. The internship (if
acquired) is slated to start right after this academic year.
This effectively delays my graduation by 1 yr, but I think that is a
really small price to pay for the experience.

Here is a rudimentary list of my skills, a more thorough one will be
submitted w/ my resume:

Programming Languages: C, Java, Visual Basic, Assembly, Win32
programming, Python

Compilers/Environment: GNU tools, Microsoft Visual Studio

Microprocessors/Microcontrollers: M680x0, Z80, x86, 8051, PIC, MSP430,
ARM7, HC11, Renesas SuperH series

proemulator.sf.net

I ported my Z80 emulator to this app some time ago. My M68000 emulator
is working and is tested to be quite accurate, but the author no longer
maintains it or updates it so I decided against porting it (even though
I can still get into the CVS).

Programmable Logic: Xilinx Spartan3 series FPGA w/ Xilinx ISE WebPack

I designed a simple VGA frambuffer 320x240x2-bit and a simplistic
16-bit CPU in VHDL.

Electronics: Basic analog electronics (FET's, OpAmps, BJT's, etc.)
Here all I did was some school projects. Simple stuff: VCO's, FET amps,
etc.

Operating Systems: Linux, MS-DOS, Windows (effective w/ all).
Been doing installs on all OS's for quite some time now. Used MS-DOS
while I was growing up (had it first running on a 16Mhz 386SX).

Most the stuff I have learned was from buying products containing the
previously mentioned items and playing around with them and their
associated tools and reading my dads old college books (he studied
electronics engineering technology at NAIT. They did extensive course
work in digital electronics).

I really do not have any related engineering experience. I did work for
GO Transit this past summer,  a major transportation company here in
Ontario, as general help. I was called on one day to look over some
computer scans of microfilm schematics of the trains (and electrical
systems) to make sure they were up to par.

I would like to shadow some teams in the engineering sector to get a
feel of what you guys do in the industry. I would like to see how you
guys solve problems, tackle issues or shortcomings you come up in
development and the like. I'd also like to learn from the people
working in this industry in general since they have a wealth of
knowledge and experience. Sometthing I think can be invaluable to me in
my career.

They have some listings at my school, but they are not exactly what I
am interested in. Thanks for listening to my story!

Any companys you know of in Toronto?
I know Altera has some offices here. Might try and get a hold of them
later on.

-Isaac

(This is a reposting as suggested by a responder in the previous
posting)


Article: 110383
Subject: Re: Virtex-II Pro Platform FPGA : Assembling the modules
From: "Jens Hagemeyer" <jenze@et.upb.de>
Date: 14 Oct 2006 13:32:42 -0700
Links: << >>  << T >>  << A >>
Hi Thang,

sure you can. Just replace .zip with .exe =).

http://www.xilinx.com/direct/swhelp/ise8/81i_sp1/8_1_01i_win.exe

Sorry for this typo. All other archs using *.zip, only windows use
*.exe =(.

Regards

Jens

Thang Nguyen schrieb:

> Hi Jens,
>
> I use Window. It looks like there is only the Add directory, which includes ISEExamples, and Replace directory, which includes docs. I can not update to the sp1 with these two directories. :(
> 
> Thang Nguyen


Article: 110384
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: Austin Lesea <austin@xilinx.com>
Date: Sat, 14 Oct 2006 13:54:09 -0700
Links: << >>  << T >>  << A >>
Rick,

Configuration does not require a "significant amount of energy."

Not sure where you got that.

Austin

Article: 110385
Subject: Re: 75Mhz Spartan3e microblaze
From: "u_stadler@yahoo.de" <u_stadler@yahoo.de>
Date: 14 Oct 2006 14:26:02 -0700
Links: << >>  << T >>  << A >>
hi

well thanks for all the answers so far.
i 'm still trying to get some more speed out of edk.
well as said before i'm not doing anything fancy. just straight forward
stuff and i was wondering what good the ethernet core is if i can't get
it to synthesize with more than 59 MHz. i have also tried to export it
to ise. i mean there must be a trick somewhere or has nobody used
microblaze with ethernet in a spartan 3e yet?
any suggestions would be very helpful

thanks
urban


Article: 110386
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "rickman" <gnuarm@gmail.com>
Date: 14 Oct 2006 14:47:10 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Rick,
>
> Configuration does not require a "significant amount of energy."
>
> Not sure where you got that.


What exactly does "significant amount of energy" mean to you?  In some
contexts, the energy to configure certainly would be significant.  If
it takes 100 ms to configure and the running time is 10 ms, then
configuration can clearly be very significant.

Of course, if once configured, the FPGA runs for an hour doing very
power intensive work the configuration energy is not significant.  But
then that would not be likely running on a battery, would it?

I simply meant that the configuration engery is enough that you need to
consider it in context, which I don't think you can argue with.


Article: 110387
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 15 Oct 2006 11:28:17 +1300
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Rick,
> 
> Configuration does not require a "significant amount of energy."
> 
> Not sure where you got that.

  He means that during config, there are many clock-buffers active as the
whole device configs. Thus config power is certainly likely to
be higher than static power, and will also likely be higher than locally
clocked functions, with Fclk <= Config speed.
  Battery Apps are NOT going to run a FPGA at >200MHz all the time!

  eg I have a Flash-RAM CPLD here, that is appx 200x more Icc during
Config load, than static icc. To me, that certainly IS significant.

  Sure, config does not last long, but you still have to allow for it.

  That is why you need to decide if (frequent) reloads are worth the gains.

  Now, a vendor that usderstood this, would put this information
in the datasheets, so their customers would be able to make the right
design decisions.

-jg


Article: 110388
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: Austin Lesea <austin@xilinx.com>
Date: Sat, 14 Oct 2006 16:19:48 -0700
Links: << >>  << T >>  << A >>
Rick,

-snip-
> What exactly does "significant amount of energy" mean to you?

In this case, if the minimum current required to configure is 200 mA, 
the current when doing nothing is 100 mA, and the design uses 1000 mA 
when running, then "significant" is pretty small (100 mA or less).

   In some
> contexts, the energy to configure certainly would be significant.  If
> it takes 100 ms to configure and the running time is 10 ms, then
> configuration can clearly be very significant.

Time, yes, but energy, perhaps not?

> Of course, if once configured, the FPGA runs for an hour doing very
> power intensive work the configuration energy is not significant.  But
> then that would not be likely running on a battery, would it?

In my example above, it still doesn't matter.

> I simply meant that the configuration engery is enough that you need to
> consider it in context, which I don't think you can argue with.

Nope.  No argument.  It is all in the numbers.

Look at the quiescent current, and the min current to configure, and 
note the delta difference for the part.  If that delta is a significant 
part of the current for the application, then you are correct.  If it is 
not, then it is not an issue.

In
http://direct.xilinx.com/bvdocs/publications/ds302.pdf
pages 5,6,7 the lx60 is 167 mA typical quiescent, and 300 mA typical to 
configure (actually, to completely power on, clean out and configure).

Re-configuration, while the rest of the device is running, should be 
even less than the min current required, so I am somewhat baffled that 
you think that this (300-167mA) represents a "significant" amount.

Now, if the design takes 200 mA after it is programmed, in addition to 
the quiescent, then you are absolutely correct:  that would be 
"significant."

I suppose that if you have to size the battery, then any extra current 
could be "significant."

Austin



Article: 110389
Subject: Re: EDIF Design Entry tools
From: "Avion" <avionion@gmail.com>
Date: 14 Oct 2006 17:19:59 -0700
Links: << >>  << T >>  << A >>
very valid argument, schematics have this inherent drawback. anyway, i
tried to use vhdl but i was unable to get the .bit file and process
fails with error "NgdBuild:76 - File
"D:\Xilinx\bin\xr16vx\_ngo\xr16vx_1k.ngo" cannot be
   merged into block "ROOT" (TYPE="xr16vx_1k") because one or more pins
on the
   block, including pin "rs232rx_IPAD_IN", were not found in the file.
Please
   make sure that all pins on the instantiated component match pins in
the
   lower-level design block (irrespective of case).  If there are
bussed pins on
   this block, make sure that the upper-level and lower-level netlists
use the
   same bus-naming convention."
i am using webpack 8.2i. i have cross checked the port names by
converting ngd file to vhdl with ngd2vhdl and port names are exactly
the same. but still i am getting above message. any idea where i am
wrong? or how can i confirm port names of an edif design file?

Duane Clark wrote:
> Avion wrote:
> > thanks for the help. let me try n i hope it will work. but isn't it
> > much easier in schematics to connect signals? is there anyway in
> > schematics as well? one way may be to create a schematic of the wrapper
> > file u just suggested and then use it. am i right?
>
> After using half a dozen different schematic packages over a period of
> about 20 years, I finally gave up on schematics about 6 years ago. I
> like schematics, but they simply are not portable, and you end up having
> to keep around an old computer and operating system and schematic
> software to support old projects. You really should abandon them; pick
> and use an HDL of some. I personally have never used the Xilinx
> schematic software, so I can give no help on that.


Article: 110390
Subject: Re: EDIF Design Entry tools
From: Duane Clark <junkmail@junkmail.com>
Date: Sun, 15 Oct 2006 00:33:04 GMT
Links: << >>  << T >>  << A >>
Avion wrote:
> very valid argument, schematics have this inherent drawback. anyway, i
> tried to use vhdl but i was unable to get the .bit file and process
> fails with error "NgdBuild:76 - File
> "D:\Xilinx\bin\xr16vx\_ngo\xr16vx_1k.ngo" cannot be
>    merged into block "ROOT" (TYPE="xr16vx_1k") because one or more pins
> on the
>    block, including pin "rs232rx_IPAD_IN", were not found in the file.
> Please
>    make sure that all pins on the instantiated component match pins in
> the
>    lower-level design block (irrespective of case).  If there are
> bussed pins on
>    this block, make sure that the upper-level and lower-level netlists
> use the
>    same bus-naming convention."
> i am using webpack 8.2i. i have cross checked the port names by
> converting ngd file to vhdl with ngd2vhdl and port names are exactly
> the same. but still i am getting above message. any idea where i am
> wrong? or how can i confirm port names of an edif design file?

edif files are plain text, so they are easy to check. If your starting 
file is edif then look there. I have found that the top level entity 
name in the edif file needs to match the filename (or maybe I have not 
discovered the right flags to use). That is, if the file is 
xr16vx_1k.edf, then the top level entity within it needs to be named 
xr16vx_1k, and that is the name you instantiate within your 
HDL/schematic. It seems to me that when I have run into that error, it 
was not really the right location for the error. Check all the signal 
names and the top level edif entity name.


Article: 110391
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: John_H <newsgroup@johnhandwork.com>
Date: Sun, 15 Oct 2006 01:20:55 GMT
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
<snip>

> I suppose that if you have to size the battery, then any extra current 
> could be "significant."
> 
> Austin


Thanks for recognizing this.  If an engineer is considering a situation 
where a one-week runtime of continuous power-up, run, power-down is 
desired, every power number and duration in that sequence is part of the 
overall budget.  This is, perhaps, where some engineers are more 
sensitive than others.

I love the idea of a keychain-type device that can do an interesting 
amount of RF work in tiny bursts but I haven't been brave enough to step 
into the power analysis to realize the system.  I love FPGAs but I 
recognize there are some things I won't be able to accomplish with them 
given the realities of the task and silicon at hand.

Article: 110392
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "ralphie" <ralphmalph_fred@yahoo.com>
Date: 14 Oct 2006 18:34:32 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Rick,
>
> -snip-
> > What exactly does "significant amount of energy" mean to you?
>
> In this case, if the minimum current required to configure is 200 mA,
> the current when doing nothing is 100 mA, and the design uses 1000 mA
> when running, then "significant" is pretty small (100 mA or less).
>
>    In some
> > contexts, the energy to configure certainly would be significant.  If
> > it takes 100 ms to configure and the running time is 10 ms, then
> > configuration can clearly be very significant.
>
> Time, yes, but energy, perhaps not?

I know you understand the difference between current, time and energy.
If the configuration requires more time than the run duration, then it
is only reasonable that it will consume significant energy.  Using the
current values above of 200 mA for configuration and 1000 mA for
running with my numbers of 100 ms for configuration and 10 ms for
running, the configuration would clearly take more energy than the
processing.

Of course none of these numbers are real, but they are realistic.  The
point is it depends on the application.


> > Of course, if once configured, the FPGA runs for an hour doing very
> > power intensive work the configuration energy is not significant.  But
> > then that would not be likely running on a battery, would it?
>
> In my example above, it still doesn't matter.

Your example is not complete and of course it matters.


> > I simply meant that the configuration engery is enough that you need to
> > consider it in context, which I don't think you can argue with.
>
> Nope.  No argument.  It is all in the numbers.
>
> Look at the quiescent current, and the min current to configure, and
> note the delta difference for the part.  If that delta is a significant
> part of the current for the application, then you are correct.  If it is
> not, then it is not an issue.
>
> In
> http://direct.xilinx.com/bvdocs/publications/ds302.pdf
> pages 5,6,7 the lx60 is 167 mA typical quiescent, and 300 mA typical to
> configure (actually, to completely power on, clean out and configure).
>
> Re-configuration, while the rest of the device is running, should be
> even less than the min current required, so I am somewhat baffled that
> you think that this (300-167mA) represents a "significant" amount.
>
> Now, if the design takes 200 mA after it is programmed, in addition to
> the quiescent, then you are absolutely correct:  that would be
> "significant."
>
> I suppose that if you have to size the battery, then any extra current
> could be "significant."

To be honest I don't get what you are describing.  I thought we were
talking about a situation where the device was powered down to save
energy.  Yes, looking back, that is what I said.  When there is
something to process, the unit would be powered up and the FPGA would
have to be configured.  This configuration energy is a product of the
current and the configuration time.  You seem to be talking about
something different and completely ignoring the time issues.

Regardless of whether the configuration current is a hundred amps or a
microamp, if the duration is long enough the energy becomes
significant.  At a first order of approximation, the configuration
energy is significant if the application current-time product is a
factor of 10 or less greater than the current-time product for
configuration.  In other words, the configuration energy is less than
10% or so.  There may be applications where the energy wasted in
configuration is even more critical as the battery margin is less.

Are we talking about different things?


Article: 110393
Subject: Re: Xilinx documentation typos
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 14 Oct 2006 18:34:52 -0700
Links: << >>  << T >>  << A >>


On Oct 14, 10:47 am, "rickman" <gnu...@gmail.com> wrote:
> Documentation is often the poor stepchild of a development process.... >
> Personally I take pride in the documents I prepare.  I never want
> anyone to read one of my documents and think it was written by a moron,
> even if it was!  ;^)

Same here. Through the XC3000 and XC4000 generations, I put together
every databook, from deciding the format and pagination to writing much
of the text, to negotiating the detailed descriptions and even the
parameter values. It was pretty much a one-man show. But the parts were
simple...
Then Xilinx got bigger and various people had to share the "fun".

Documenting programmable logic may be more difficult than documenting
memories, microprocessors or ASSP dedicated circuits. FPGAs are used in
a myriad of ways by hundred thousands of designers with widely varying
backgrounds and skills.

The person(s) in charge of documentation must be technically savvy in a
wide area, be able to write clear and reasonably tight English
sentences, have the eyes of an eagle, and the patience of Job. They
must be  self-confident and persistent without becoming obnoxious, and
it helps when they have a respected and senior position in the company,
so that they can circumnavigate committees and  get things implemented
or changed. That's a tough job desciption.
No wonder we do not always live up to the highest expectations. But we
are still trying...
Peter Alfke, Xilinx, fom home


Article: 110394
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 14 Oct 2006 18:42:25 -0700
Links: << >>  << T >>  << A >>
Ralphie, let's not sink to kindergarten level. We all can multiply
current and time. Most of use even understand percentages...
The OP did not give any specific values, and the thread has
deteriorated into generalities.

Notealso that there are different degrees of powerdown. As long as you
maintain Vcc, you have leakage current,which (unfortunately) is
significant in state-of-the -art FPGAs.
'nough said.
Peter Alfke

On Oct 14, 6:34 pm, "ralphie" <ralphmalph_f...@yahoo.com> wrote:
> Austin Lesea wrote:
> > Rick,
>
> > -snip-
> > > What exactly does "significant amount of energy" mean to you?
>
> > In this case, if the minimum current required to configure is 200 mA,
> > the current when doing nothing is 100 mA, and the design uses 1000 mA
> > when running, then "significant" is pretty small (100 mA or less).
>
> >    In some
> > > contexts, the energy to configure certainly would be significant.  If
> > > it takes 100 ms to configure and the running time is 10 ms, then
> > > configuration can clearly be very significant.
>
> > Time, yes, but energy, perhaps not?I know you understand the difference between current, time and energy.
> If the configuration requires more time than the run duration, then it
> is only reasonable that it will consume significant energy.  Using the
> current values above of 200 mA for configuration and 1000 mA for
> running with my numbers of 100 ms for configuration and 10 ms for
> running, the configuration would clearly take more energy than the
> processing.
>
> Of course none of these numbers are real, but they are realistic.  The
> point is it depends on the application.
>
> > > Of course, if once configured, the FPGA runs for an hour doing very
> > > power intensive work the configuration energy is not significant.  But
> > > then that would not be likely running on a battery, would it?
>
> > In my example above, it still doesn't matter.Your example is not complete and of course it matters.
>
>
>
> > > I simply meant that the configuration engery is enough that you need to
> > > consider it in context, which I don't think you can argue with.
>
> > Nope.  No argument.  It is all in the numbers.
>
> > Look at the quiescent current, and the min current to configure, and
> > note the delta difference for the part.  If that delta is a significant
> > part of the current for the application, then you are correct.  If it is
> > not, then it is not an issue.
>
> > In
> >http://direct.xilinx.com/bvdocs/publications/ds302.pdf
> > pages 5,6,7 the lx60 is 167 mA typical quiescent, and 300 mA typical to
> > configure (actually, to completely power on, clean out and configure).
>
> > Re-configuration, while the rest of the device is running, should be
> > even less than the min current required, so I am somewhat baffled that
> > you think that this (300-167mA) represents a "significant" amount.
>
> > Now, if the design takes 200 mA after it is programmed, in addition to
> > the quiescent, then you are absolutely correct:  that would be
> > "significant."
>
> > I suppose that if you have to size the battery, then any extra current
> > could be "significant."To be honest I don't get what you are describing.  I thought we were
> talking about a situation where the device was powered down to save
> energy.  Yes, looking back, that is what I said.  When there is
> something to process, the unit would be powered up and the FPGA would
> have to be configured.  This configuration energy is a product of the
> current and the configuration time.  You seem to be talking about
> something different and completely ignoring the time issues.
>
> Regardless of whether the configuration current is a hundred amps or a
> microamp, if the duration is long enough the energy becomes
> significant.  At a first order of approximation, the configuration
> energy is significant if the application current-time product is a
> factor of 10 or less greater than the current-time product for
> configuration.  In other words, the configuration energy is less than
> 10% or so.  There may be applications where the energy wasted in
> configuration is even more critical as the battery margin is less.
> 
> Are we talking about different things?


Article: 110395
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "ralphie" <ralphmalph_fred@yahoo.com>
Date: 14 Oct 2006 19:01:25 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Ralphie, let's not sink to kindergarten level. We all can multiply
> current and time. Most of use even understand percentages...
> The OP did not give any specific values, and the thread has
> deteriorated into generalities.
>
> Notealso that there are different degrees of powerdown. As long as you
> maintain Vcc, you have leakage current,which (unfortunately) is
> significant in state-of-the -art FPGAs.
> 'nough said.
> Peter Alfke

What's up with you?  No one's gotten offensive until you made the
kindergarten comment.  From his post it is clear that he is missing
something about the problem being stated. I didn't get offensive about
this. I just explained with plenty of detail to clear up the point of
confusion.

Of course it is possible that you don't want to clarify the point of
confusion, I can't say. But I don't get what you mean when you say
"there are different degrees of powerdown". Power down to me has always
meant *no* power. Is there some other power state that is called
"powerdown" that I don't know about? How do you mean the term? If you
maintain Vcc, why would you need to reconfigure the FPGA?

What is going on here? I am just trying to discuss a technical issue.
Don't get your knickers in a knot!


Article: 110396
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 14 Oct 2006 19:16:06 -0700
Links: << >>  << T >>  << A >>
No knickers in a knot (interesting analogy). I was just tired of the
endless repetition of very simple calculations.
Regarding power-down: Some people think that sleep mode or idle mode
means powerdown (which it did, 10 years ago. Today you really have to
lower Vcc to a very low value in order to save the leakage current.)
But now I also sank to the kindergarten level.
Just because this is a newsgroup, we do not need to repeat the same
simple statements ad nauseam.
Peter Alfke

On Oct 14, 7:01 pm, "ralphie" <ralphmalph_f...@yahoo.com> wrote:
> Peter Alfke wrote:
> > Ralphie, let's not sink to kindergarten level. We all can multiply
> > current and time. Most of use even understand percentages...
> > The OP did not give any specific values, and the thread has
> > deteriorated into generalities.
>
> > Notealso that there are different degrees of powerdown. As long as you
> > maintain Vcc, you have leakage current,which (unfortunately) is
> > significant in state-of-the -art FPGAs.
> > 'nough said.
> > Peter AlfkeWhat's up with you?  No one's gotten offensive until you made the
> kindergarten comment.  From his post it is clear that he is missing
> something about the problem being stated. I didn't get offensive about
> this. I just explained with plenty of detail to clear up the point of
> confusion.
>
> Of course it is possible that you don't want to clarify the point of
> confusion, I can't say. But I don't get what you mean when you say
> "there are different degrees of powerdown". Power down to me has always
> meant *no* power. Is there some other power state that is called
> "powerdown" that I don't know about? How do you mean the term? If you
> maintain Vcc, why would you need to reconfigure the FPGA?
>
> What is going on here? I am just trying to discuss a technical issue.
> Don't get your knickers in a knot!


Article: 110397
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: John_H <newsgroup@johnhandwork.com>
Date: Sun, 15 Oct 2006 02:34:54 GMT
Links: << >>  << T >>  << A >>
ralphie wrote:
<snip>
> Are we talking about different things?

For some ideas on what "power down" might consist of, take a look at the 
power discussions in the Spartan-3L data sheet.  While the idea of a 
low-power FPGA initially piqued my interest, the method of "deep 
hibernation" (or some similar term) where the configuration is lost but 
still some power is used seemed to me a bit bizarre but this 
functionality might be critical in a system that needs other (milliamp) 
devices operating continuously without the VCCINT==0 FPGA bringing down 
the system.  With the VCCINT==keeperVoltage, the I/Os might now behave 
nicely without the full-voltage quiescent power of the FPGA.

Outside of the 3L data sheet (and possible application notes or 
TechXclusive articles thereof) there isn't a great deal of "low power" 
discussions in the Xilinx literature for modern FPGAs that I'm aware of.

If nothing else, the 3L information can broaden your ideas on possible 
power-down (or power-saving) scenarios.

- John_H

Article: 110398
Subject: Re: Xilinx FPGAs in battery-powered scenarios
From: Austin Lesea <austin@xilinx.com>
Date: Sat, 14 Oct 2006 19:41:10 -0700
Links: << >>  << T >>  << A >>
ralphie,

Perhaps I am missing something?

Rick mentioned "significant" penalty for reconfiguring, and I pointed 
out that a few hundred mA (at the most) is all we are talking about.

It is up to the engineer to decide if a few hundred mA is significant, 
given the benefit (don't reconfigure, need a larger part with more 
leakage, do reconfigure, and you can potentially use a much smaller 
part, more efficiently).

No one mentioned turning things off, or "sleep" modes as far as I know.

Really very simple, and very straightforward.

If you also bring into the mix just turning everything off, then doing 
anything at all, other than leaving everything off, that is infititely 
"significant" (anything more than 0).

Austin


Article: 110399
Subject: Re: 75Mhz Spartan3e microblaze
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Sat, 14 Oct 2006 19:46:53 -0700
Links: << >>  << T >>  << A >>
u_stadler@yahoo.de wrote:
> hi
> 
> well thanks for all the answers so far.
> i 'm still trying to get some more speed out of edk.
> well as said before i'm not doing anything fancy. just straight forward
> stuff and i was wondering what good the ethernet core is if i can't get
> it to synthesize with more than 59 MHz. i have also tried to export it
> to ise. i mean there must be a trick somewhere or has nobody used
> microblaze with ethernet in a spartan 3e yet?
> any suggestions would be very helpful
> 
> thanks
> urban
> 

I was pretty sure someone recently had just that running
on the spartan-3e starter board. Uclinux with networking
and I think it was microblaze. Look in the archives, like
in the last 1-2 months.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture



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