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 71975

Article: 71975
Subject: Re: Manipulation on netlist for faster simulation.
From: "Kelvin" <kelvin_xq@yahoo.com>
Date: Thu, 5 Aug 2004 10:03:03 +0800
Links: << >>  << T >>  << A >>
Thank you Brian.

The problem was, the netgen always crashed when I attempted to write a
hierarchical netlist.
I was doing some partial reconfigurable design in V2-6000.
I asked this crash question in this ng also but I can't solve that so fat.
Flattening was my
last resort.

Kelvin






"Brian Philofsky" <brian.philofsky@no_xilinx_spam.com> wrote in message
news:cerpdb$li15@xco-news.xilinx.com...
>
>
> Eyck Jentzsch wrote:
> > Hi Kevin,
> >
> > Kelvin wrote:
> >
> >> Hi, there:
> >>
> >> My Xilinx software generated a flattened netlist and SDF each over
> >> 100MB...Now NC_Verilog
> >> takes hundreds of hours to simulate that.
> >>
> >> Now if I write a perl to replace all the long wire names with some
random
> >> 10-alphabet string,
> >> it will probably shrink the file size to 10MB...But will that make my
> >> simulation faster?
> >> ---sample
> >>   wire
> >>
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> >>
> >> 0)/F ;
> >>   wire
> >>
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> >>
> >> 0)/G ;
> >>
> >>
> >> Thanks.
> >> Kelvin
> >>
> >>
> >>
> > This will not help much, it will just speedup the simulation startup
> > because of less file reading.
> > It will help more to check if you used all performance switches (and
> > aviod performance degrading options like +access+rwc or linedebug ;-)).
> > The online documentation (cdsdoc) has a dedicated chapter ('Maximising
> > simulation performance') for it.
> > HTH
> >
> > -Eyck
> >
>
> I agree with what has been said here but offer another possible
> suggestion to help out with this situation.  Why are you flattening the
> netlist?  If you keep some hierarchy (some not all of it), it will
> likely allow you to better manage the simulation in multiple ways.
> First, that will likely shrink many of the signal names you are having
> problems with as the hierarchy is no longer needed to be preserved into
> each individual signal name.  Second, it would allow you to set
> accessibility to separate portions of the design by allowing you to
> specify the optimizing of portions you are not currently debugging and
> allowing visibility to the portions you are.  Third, you can do a full
> timing simulation of part of your design so rather than trying to
> simulate the whole thing at once, you could do it in pieces.  This not
> only makes for smaller and usually faster simulations but also can allow
> the re-use of sub-level testbenches, allow for parallel simulations (if
> you have more licenses available), uses less memory/less machine
> requirements, easier debug since it is smaller and better understood,
> and a handful of other benefits.  Fourth, you could replace the portions
> of the design you are not currently trying to perform a timing
> verification on with behavioral or RTL code thus doing a mixed
> behavioral/RTL/Timing simulation which should perform much better than a
> full structural simulation.
>
> At some point in the design, it is always beneficial to do a full
> netlist timing simulation as it can detect problems that can be easily
> missed in functional simulation and static timing analysis (even in
> fully synchronous designs) however that is generally best done at the
> very end of the design cycle.  Much of the timing verification can many
> times be done more efficiently in pieces by retaining the hierarchy and
> using it in this phase of verification.  For information on hierarchy
> preservation for simulation, look at Chapter 6 in the Synthesis and
> Verification design Guide, the section titled, "Design Hierarchy and
> Simulation":
> http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf
>
> Hope this helps.
>
> --  Brian
>



Article: 71976
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 05 Aug 2004 14:30:13 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
<snip>
> I have one socket on a board that Xilinx could not fill.  I needed 5
> volt compatibility in a relatively low power device.  All of the newer
> (read supported by current software) devices that are 5 volt tolerant
> have a power on current surge that makes it hard to use in a low power
> design without extra circuitry.  So I ended up using an Altera ACEX
> (EP1K) device which is only about 3-4 years old.  Otherwise their newer
> chips are mostly similar.  

.. Perhaps the new Virtex-4 that Peter A. is dying to tell us about also
solves the 5V i/o issues ;)
-jg


Article: 71977
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Thu, 05 Aug 2004 02:46:19 GMT
Links: << >>  << T >>  << A >>
Hi Sumit,

Yes, X vs. A can turn into a holy war, resulting in frustration on all sides
:-)

The easiest way to answer this question is to take your design and compile
it in both Xilinx and Altera's tools.  We both have freely available
versions of our software.  Quartus II Web Edition targets Cyclone and
Stratix devices so that you can try them out.  You'll want to figure out
what the cheapest device is that your design fits into and still meets its
performance target(s).  Don't use the "auto device selection" feature
alone -- use it to get an idea, then try picking a smaller device until your
design no longer fits.  Look at the timing margin you have, and reduce speed
grades if possible.  You'll also want to look at the data sheets to read
about additional features (PLL/DCMs, DSP/Multipliers, memories, etc) that
you think you may need.

And in the end, everything comes down to price and availability.  All that
matters to you is how much the chip will cost you in the volume you need it.
And depending on your risk tolerance, you may want to opt for more mature
families that have ready availability.  For this type of information, you'll
need to contact your distributor or FAE/FSE  from each company.

Word of caution:  Do not use "toy" designs to compare devices or software.
Running 16-bit adders or my_little_cpu.v through two tools will not give you
an accurate picture of how the devices and software behave on "real"
designs.

Regards,

Paul Leventis
Altera Corp.



Article: 71978
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Thu, 05 Aug 2004 03:02:57 GMT
Links: << >>  << T >>  << A >>
> Thanks for your reply Thomas.  I guess I should ask the question in a
> different way: for devices from different vendors with the same number
> of gates, will I get better performance and/or cost from a Flash or a
> SRAM based FPGA ?  Also, I assume that the comment about usability of
> Xilinx cells being low is related to routability ?  Is it any better
> with the Altera/Actel etc parts ?

As another poster has indicated, Flash-based devices are just SRAM FPGAs
with an integrated Flash IP block.  This removes the need for a stand-alone
EEPROM/Flash chip for configuration, and can provide a higher bandwidth
Flash-to-SRAM connection enabling faster configuration times, giving a
"instant-on" capability.

The downside of Flash is that you are stuck on a Flash process.  Flash
processes are behind standard CMOS processes -- I think I've seen 0.13u
Flash talked about somewhere in EETimes, but that's about the best you get
these days, and its immature.

We've opted to include an on-die Flash memory in our Max II family of CPLDs.
These devices can't really take advantage of cutting-edge process technology
due to pad limitation and voltage/power requirements of the target market,
so the process "penalty" isn't an issue.  And CPLD users want a simple,
one-chip solution and instant-on capabilities.

To first order, chips manufactured in smaller process geometries are
faster -- our 90 nm Stratix II family is ~50% faster than our 130 nm Stratix
family.  However, comparing two chips with different architecture (Stratix
vs. Virtex II, Cyclone vs. Spartan 3) by using process technology is not
going to necessarily give the right answer.  For example, we find that
Cyclone is significantly faster than Spartan-3, despite being manufactured
on 130 vs. 90 nm.  This can be due to numerous reasons -- power vs. speed
trade-offs, software quality, architectural advantages, etc.  The bottom
line is you have to try out your design on the chips in question (via the
software) to really know.


As for usability/routability, Altera's FPGAs are designed to be routable at
100% utilization (both LUTs and registers) for all but the hairiest of
designs.  I don't have any first-hand knowledge of the routability of
competitors parts and thus will not comment on that.

Regards,

Paul Leventis
Altera Corp.



Article: 71979
Subject: Re: New WinFilter Digital Filter design freeware tool release available.
From: "Tom" <somebody@knowherex.netgx>
Date: Thu, 5 Aug 2004 15:20:06 +1200
Links: << >>  << T >>  << A >>

"Adrian" <adrian@nospam.com> wrote in message
news:4104F20D.4090004@nospam.com...
> Hi all,
>
>
> I have just made the last release 0.7 of the freeware WinFilter
> available on the web.
> http://www.winfilter.20m.com
>
> WinFilter is a software tool provided as freeware to design digital
> filter. A GUI makes it very user friendly. This software can design as
> well IIR filters as FIR filters and can generate the C and VHDL code.
>
> The filter coefficients are now quantizied in float, 16-bit or 8-bit.
> FIR filter are now synthezis in VHDL (speed or size optimization) with a
> Resources Usage Estimation.
>
> Cheers,
> Adrian
>
>
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

Is this available for download? I cannot see the link on the page for
download?

Thanks


Tom



Article: 71980
Subject: xilinx: non LOC pins causing havoc
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Wed, 4 Aug 2004 23:20:54 -0400 (EDT)
Links: << >>  << T >>  << A >>
Has anyone seen output pins cause a design to randomnly fail?

I have a very solid design that I accidently left two OBUFs with no ucf 
LOC contraint.  depending how much i fill a v2pro device my logic will 
fail seemingly randmonly with these two OBUFs instantiated.

I know that the randomn locations that ISE is choosing is not colliding 
with anything on my board but the design fails consistenly.

Thoughts?

Matt

Article: 71981
Subject: Re: practical Virtex2 output buffer speeds
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Thu, 05 Aug 2004 13:35:04 +1000
Links: << >>  << T >>  << A >>
On Wed, 04 Aug 2004 14:32:06 -0700, Austin Lesea <austin@xilinx.com>
wrote:

>By the way, I found out today that there is a public domain software 
>tool that converts IBIS back into spice, so you could then run the IBIS 
>model under a spice simulator that doesn't already support IBIS (like a 
>public domain spice program).

Hi Austin,

Could you please post a link to this tool?

Thanks,
Allan.

Article: 71982
Subject: Re: Manipulation on netlist for faster simulation.
From: "Kelvin" <kelvin_xq@yahoo.com>
Date: Thu, 5 Aug 2004 12:07:46 +0800
Links: << >>  << T >>  << A >>
Thank you very much Joe! The /tmp idea is interesting.

Kelvin



"Joe" <joe_y@invalid_address.nospam.com> wrote in message
news:cern4o$oua$1$8300dec7@news.demon.co.uk...
> Kelvin wrote:
> > Hi, there:
> >
> > My Xilinx software generated a flattened netlist and SDF each over
> > 100MB...Now NC_Verilog
> > takes hundreds of hours to simulate that.
> >
> > Now if I write a perl to replace all the long wire names with some
random
> > 10-alphabet string,
> > it will probably shrink the file size to 10MB...But will that make my
> > simulation faster?
> > ---sample
> >   wire
> >
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> > 0)/F ;
> >   wire
> >
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> > 0)/G ;
> >
> >
> > Thanks.
> > Kelvin
> >
> >
> >
>
> Hi Kelvin,
>
> In case your data files are store on a file server and the simulation is
> executed by a separate server, the link between the two servers can be a
> bottle neck.
>
> In SDF simulation the simulator access to the compiled binary files a
> lot, so it is better to put all the files in the same machine that you
> run simulation on.
>
> A lot of UNIX machines have /tmp directory that are accessible by
> everyone, and it is possibly not mount to the file server. So you might
> try to copy your files to /tmp directory and run the simulation from
> there.  (But don't tell your sys admin :-> )
>
> Also try run the simulaion in command mode and redirect stdout to a file
> instead of output to display. (messaage display can be another bottle
neck).
>
> Joe
>



Article: 71983
Subject: Re: Compact FPGA Board?
From: soar2morrow@yahoo.com (Tom Seim)
Date: 4 Aug 2004 21:42:32 -0700
Links: << >>  << T >>  << A >>
daragoth@kuririnmail.com (Daragoth) wrote in message news:<317379a8.0408041333.cd5ec11@posting.google.com>...
> Peter Alfke <peter@xilinx.com> wrote in message news:<BD34280A.7CD7%peter@xilinx.com>...
> > I know (from my own experience) that it is tempting to design something
> > small and neat. But I have also seen many failures when there just was not
> > enough room to complete the design properly.
> > My advice is: Think twice ( or thrice) before committing to a very tight
> > footprint.
> > Peter Alfke
> 
> Thanks for the advice Peter, but unfortunately this isn't an option
> for me.  The space that the board must go in has already been
> determined; it must be 40x30x10 mm in volume.

I'm surprised that Peter didn't mention that Xilinx has a Spartan 3 in
a 100 pin thin flat pack that measures 16 mm on a side (maybe Peter
better look at his own data sheets!). The thickness is 1.6 mm, so it
looks like you can do what you want to do (but it will be a custom).

Tom

Article: 71984
Subject: Re: Best tool(s) for filter float->fixed->VHDL flow?
From: Bernhard Holzmayer <holzmayer.bernhard@deadspam.com>
Date: Thu, 05 Aug 2004 07:33:35 +0200
Links: << >>  << T >>  << A >>
That's a very realistic description.
I can verify this from my experience.

Especially, if you're unexperienced with VHDL design,
it will save a lot of time and make the result more reliable.

Bernhard

Article: 71985
Subject: Re: xilinx: non LOC pins causing havoc
From: Marc Randolph <mrand@my-deja.com>
Date: Thu, 05 Aug 2004 01:07:39 -0500
Links: << >>  << T >>  << A >>
Matthew E Rosenthal wrote:
> Has anyone seen output pins cause a design to randomnly fail?
> 
> I have a very solid design that I accidently left two OBUFs with no ucf 
> LOC contraint.  depending how much i fill a v2pro device my logic will 
> fail seemingly randmonly with these two OBUFs instantiated.
> 
> I know that the randomn locations that ISE is choosing is not colliding 
> with anything on my board but the design fails consistenly.

Howdy Matt,

First off, what do you mean by fail?  Does PAR or MAP stop?  Or does it 
make it through the tools and then somehow not work when you put it on 
the board?

I'm assuming you meant MAP or PAR would abort... in which case, I've had 
situations like that before.  It seems like the tool isn't especially 
smart about how it assigns locations of things (especially GBUFs and 
DCMs) and walks itself into a corner it can't get out of.  I seem to 
recall also having some problems with IOBs from time to time - it is as 
if the tools sometimes pick pins but ignore the banking rules.  Then 
later, it detects the rule violation and stops.  Again, this is from 
memory, so I may be remembering the situation incorrectly.

But since you have a board, you want all the pins nailed down, right?

Have fun,

    Marc

Article: 71986
Subject: Re: Guidelines for Timing Closure on FPGAs
From: kirandev@msn.com (Kiran)
Date: 4 Aug 2004 23:27:02 -0700
Links: << >>  << T >>  << A >>
Hi Allan,

> Obviously rules of thumb are based around certain assumptions.  You
> need to know how fast your chip is (w.r.t. your clock rate), whether
> you are doing floorplanning, etc.

You are right.  It depends on device, required clock rate, design etc.

How do you control fan-out?  Is it through a tool-setting or through
coding style itself?
 
> Note that FPGA flip flops are basically free.  Don't be afraid to use
> them to make the routing easier.

This is not very clear. Do you mean that we should insert registers in
the paths in the RTL code?

> This one is fairly good, although floorplanning (good or bad) can make
> a difference.  Note that a tightly packed part will often produce a
> few excessively long delays due to routing congestion.

Is there a thumb rule with respect to device occupancy?  Should it be
restricted to say 75% of the device so that routing does not get
congested?

Thanks,
Kiran.

Article: 71987
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: usenet_10@stanka-web.de (Thomas Stanka)
Date: 5 Aug 2004 00:10:06 -0700
Links: << >>  << T >>  << A >>
Hello,

Peter Alfke <peter@xilinx.com> wrote:
> > - Area (usability of cells, e.g. Xillinx wouldn't allow you to use
> > 100% of the cells)
> This is utter nonsense. There is nothing wrong with using 100% of the logic
> resources, if the routing structure supports this. And that depends on the
> design style. Newer families have considerably more routing than the old
> ones. Whether a design is logic- or routing-limited has nothing to do with
> the particular manufacturer.

Nice to hear, that newer Xilinx Fpgas allow 100% usage. My experience
based on several designs for XC4k to Virtex-E says, that 100% is no
practical number.
I got routing problems at about 66% doing an XCV1000. As unexperienced
beginner I would have said, that a XCV800 should do if I have less
than 70% fpga useage on an XCV1000.
I mentioned Xilinx, because I can't say a word about Altera or other
SRAM based fpgas. But if you choose an fpga, you should have in mind,
that you might end up in mess, if you choose a device because
marketing told you it's big enough.
And reducing the design, just because your design is too big for an
device is a very nasty and errorprone task.

bye Thomas

Article: 71988
Subject: Re: Guidelines for Timing Closure on FPGAs
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Thu, 05 Aug 2004 17:43:04 +1000
Links: << >>  << T >>  << A >>
On 4 Aug 2004 23:27:02 -0700, kirandev@msn.com (Kiran) wrote:

>Hi Allan,
>
>> Obviously rules of thumb are based around certain assumptions.  You
>> need to know how fast your chip is (w.r.t. your clock rate), whether
>> you are doing floorplanning, etc.
>
>You are right.  It depends on device, required clock rate, design etc.
>
>How do you control fan-out?  Is it through a tool-setting or through
>coding style itself?

I use coding style.  For example, if my source code has a signal
feeding eight other LUTs, I know that the fanout is eight.

Note that for most designs (which aren't pushing the technology to the
limits) it's quite reasonable to ignore fanout in your source code and
rely on the fanout limit in your synthesiser.  This should have a
default of 50-100 or so.  It will replicate logic to maintain this
limit.  E.g. if the fanout limit is 100 and you have 200 loads on a
flip flop, the synthesiser will replicate the flip flop (so that there
are two flip flops fed with identical inputs) and each flip flop will
drive 100 loads.

My experience is that automatic replication makes floorplanning
harder.
 
>> Note that FPGA flip flops are basically free.  Don't be afraid to use
>> them to make the routing easier.
>
>This is not very clear. Do you mean that we should insert registers in
>the paths in the RTL code?

Yes.

>> This one is fairly good, although floorplanning (good or bad) can make
>> a difference.  Note that a tightly packed part will often produce a
>> few excessively long delays due to routing congestion.
>
>Is there a thumb rule with respect to device occupancy?  Should it be
>restricted to say 75% of the device so that routing does not get
>congested?

The obvious hard limit is 100% (although I once had Maxplus make some
FFs out of comb. logic in a CPLD so that I actually used more than
100% of the flip flops in the device!).
A practical limit is 50% to 100%.  I've never seen anyone suggest a
utilisation of less than 50%.

There is also a tradeoff with development time.  Lower utilisation
means faster build times.  I've seen projects which have had larger
FPGA on the prototypes (to speed code development) and smaller FPGAs
on the production units (to lower costs).  This is also important if
the requirments for your project are not fully understood- you have
room to manoeuver during development.

A lot depends on your design.  It may end up being flip flop limited
(which would be unusual in an FPGA, but more common in a CPLD), or it
may be block ram limited, etc.

My current chip is using most of the block ram but only about 40% of
the FFs and logic.  YMMV.

Regards,
Allan.

Article: 71989
Subject: Re: nco and phase detector
From: Andreas Schwarz <andreas.schwarz@space.at>
Date: Thu, 05 Aug 2004 09:53:47 +0200
Links: << >>  << T >>  << A >>
D. Kruse wrote:

> I'm an analog engineer who's familiar with analog PLL's but not with
> digital PLL's. I've been searching the internet for the NCO equivalent
> of Kvd of an VCO and the Kphi of an 'exclusive or' phase detector. I
> thought if I had those, I could use the analog transfer functions to
> analyzer a PLL.
> 
> Also, can you point me toward any NCO vendor webpages that would have
> some application note using their product in an DPLL.
> 
> Thanks for any help.
> 
> D. Kruse

Hello,
from my understanding NCO and PLL are two different concepts
for freuqncy synthesis.
There are no feedback loops in an NCO.
  	
http://www.analog.com
	Search for:Direct Digital Synthesis (DDS)

For sure you can combine NCO + PLL in an advanced concept.
http://www.commdesignconference.com/archive/papers/2003/W221.htm

Regards, Andreas

Article: 71990
Subject: Verilog to VHDL conversion
From: viveklk@hotmail.com (Vivek)
Date: 5 Aug 2004 02:35:12 -0700
Links: << >>  << T >>  << A >>
Hi,

Please  let  me know some good Verilog to VHDL conversion tools. 
In case you have tried any please let me know the good/bad part
of it :)

Regards,
Vivek

Article: 71991
Subject: Re: New WinFilter Digital Filter design freeware tool release available.
From: oen_no_spam@yahoo.com.br (Luiz Carlos)
Date: 5 Aug 2004 03:49:15 -0700
Links: << >>  << T >>  << A >>
I can't even open the page. I got the message:

"Could not connect to remote server
http://www.winfilter.20m.com/"

Using Opera or Internet Explorer.

Luiz Carlos

Article: 71992
Subject: i2c controller and Linux driver
From: "Sasa Bremec" <sasa@i-tech.si>
Date: Thu, 5 Aug 2004 15:55:53 +0200
Links: << >>  << T >>  << A >>
Hi !

I need to create a I2C controller in FPGA and  write or rewrite a I2C driver
for linux running on xscale.

Any idea how?

If I use allready written standard  HDL code and rewrite the driver or
rewrite a HDL code and use linux driver in I2C package?


thanks, Sasa



Article: 71993
Subject: Re: i2c controller and Linux driver
From: Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com>
Date: Thu, 05 Aug 2004 16:47:11 +0200
Links: << >>  << T >>  << A >>
Sasa Bremec wrote:
> Hi !
> 
> I need to create a I2C controller in FPGA and  write or rewrite a I2C driver
> for linux running on xscale.
> 
> Any idea how?
> 
> If I use allready written standard  HDL code and rewrite the driver or
> rewrite a HDL code and use linux driver in I2C package?
> 
> 
> thanks, Sasa
> 
> 
Why not simply use two GPIO of the XScale for that ... and the linux driver would already been written.


Sylvain

Article: 71994
Subject: Using ISE flow in EPS
From: paul@miseldine.com (Paul Miseldine)
Date: 5 Aug 2004 07:53:04 -0700
Links: << >>  << T >>  << A >>
Hi

Having recently started using EDK. I have ISE 6.2 and eps 6.2 and an
Avnet virtexII pro developement board. I downloaded the example PPC
example from Xilinx and have yet to get it to work. I have noticed
some errors in the UCF but gave up at that point. So i looked at the
examples supplied with the avnet board. Fine after updating the
projects to 6.2 everything seems to be ok. That is until i change the
flow from xps to ise. Following the instructions presented in the
xilinx example i can not get it working. I have tried most things but
to no avail. Any help would be greatfully recieved

Cheers

Paul

Article: 71995
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 05 Aug 2004 11:26:16 -0400
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> rickman wrote:
> <snip>
> > I have one socket on a board that Xilinx could not fill.  I needed 5
> > volt compatibility in a relatively low power device.  All of the newer
> > (read supported by current software) devices that are 5 volt tolerant
> > have a power on current surge that makes it hard to use in a low power
> > design without extra circuitry.  So I ended up using an Altera ACEX
> > (EP1K) device which is only about 3-4 years old.  Otherwise their newer
> > chips are mostly similar.
> 
> .. Perhaps the new Virtex-4 that Peter A. is dying to tell us about also
> solves the 5V i/o issues ;)

I can assure you that it does not.  The problem is twofold, 1) with the
thinner oxides that are being used, it gets harder and harder to provide
5 volt tolerance without adding processing steps which drives up the
cost and 2) 5 volt tolerance is becomming less and less important as
various standards evolve away from the use of 5 volt interfaces.  

It has been explained to me several times that in the FPGA world, they
had two choices, retain 5 volt tolerance or compete effectively in the
high dollar, most current technology markets.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 71996
Subject: Re: practical Virtex2 output buffer speeds
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 5 Aug 2004 09:46:16 -0700
Links: << >>  << T >>  << A >>
Robert,
The Xilinx LVDS inputs include 2.5V CML signals in their common mode range,
just about. Use a resistor pack or two if you're worried! A lot of CML parts
also have wide common mode range inputs that can handle the Xilinx LVDS
output signals. Check out parts from Micrel and ONsemi.
CML has the problem, like PECL, that the output is referred to Vcc. As the
geometry shrinks in FPGAs, it's harder to support 3.3V. 5V is already dead.
Xilinx have 90nm triple-oxide technology which mitigates some of these
problems, but I'd be very impressed if they build a CML and an LVDS output
on the same pair of IOBs. The Rocket I/Os with their specialist IOs are one
way round the problem.
I'd love to see Xilinx make a super-fast FPGA with the fabric based on CML.
It would only need to be the size of an old 3020, but could open up a world
of possibilities at gigabit rates, when use alongside a large conventional
FPGA.
Cheers, Syms.
"Robert Sefton" <rsefton@nextstate.com> wrote in message
news:2ndhdhFvc98vU1@uni-berlin.de...
> Thanks, Austin. Not the answer I was hoping for, but I'll figure something
out. When will CML be available as a SelectIO
> option? Virtex 4?
>
> Robert



Article: 71997
Subject: What is the price of the micro-blaze, ... ?
From: "Lawrence D. Lopez" <lopez-NOSPAM@mv.mv.com>
Date: Thu, 05 Aug 2004 12:47:18 -0400
Links: << >>  << T >>  << A >>
I was wondering if someone could tell me
what is free and what is not.

I've purchased (and it's on the way) the $99
Spartan-3 development kit and I'm wondering
if any additional expenses are invoked by
using the various IP property on xilinx's web
pages.

	Larry


Article: 71998
Subject: Re: New WinFilter Digital Filter design freeware tool release available.
From: "lawrence Lopez" <lopez-NOSPAM@mv.mv.com>
Date: Thu, 5 Aug 2004 12:58:55 -0400
Links: << >>  << T >>  << A >>
There was a pop up though, perhaps that broke things for you.


"Luiz Carlos" <oen_no_spam@yahoo.com.br> wrote in message
news:3fd8f66b.0408050249.77f78a90@posting.google.com...
> I can't even open the page. I got the message:
>
> "Could not connect to remote server
> http://www.winfilter.20m.com/"
>
> Using Opera or Internet Explorer.
>
> Luiz Carlos



Article: 71999
Subject: NIOS Gnu Tools and Dynamic Memory
From: alessandro.strazzero@virgilio.it (Alessandro Strazzero)
Date: 5 Aug 2004 10:11:42 -0700
Links: << >>  << T >>  << A >>
Dear everybody,

I'm using GNU toolchain for NIOS and I have some problems using the
C++ new
operator. I think my problems depend of my linker script, so I hope
any "guru"
can help me.

I have defined my ".data" section starting at 0xB0000. Once software
is running I'm able to verify that dynamic objects are allocated after
static memory. But,
if I delete one object and allocate it again, the new operator
allocate it at
an address below 0xB0000. 

Is my linker script missing of any directive to define the dynamic
memory area ?
In general, how can I define dynamic memory area using ld ?

Below I have attached my linker script. "nasys_data_mem" is equal to
0x80000

I hope someone can help me.

Best Regards

/Alessandro


ENTRY(_start)

SECTIONS
{
  /* Read-only sections, merged into text segment: */

  . = nasys_data_mem;

  /*
   * Begin the read-only code section here.
   */

  .text      :
  {
    *(.text.prefix) /* Force prefix to be first */
    *(.init)
    *(.init.*)
    *(.text)
    *(.text.*)
    *(.gnu.linkonce.t*)
  } =0

  . = ALIGN(4);
  _etext = .;

  PROVIDE (etext = .);

  /*
   * Begin the read-only but not-relocated section of
   * memory here.
   */

  _nasys_rodata = .;

  .ctors   : 
  {
    _ctors_begin = .;
    KEEP (*(.ctors))
    _ctors_end = .;
  }
   .dtors         :
  {
    _dtors_begin = .;
    KEEP (*(.dtors))
    _dtors_end = .;
  }
  .rodata   :
  {
    *(.rodata)
    *(.rodata.*)
    *(.gnu.linkonce.r*)
  }

  _nasys_rodata_end = .;

  /*
   * --------------------------------------------------
   * the .data section contains initialized and writeable
   * variables. If we have separate code & data, we need
   * to have it load in code area, but have the symbols
   * resolve to the data area.
   */
  
  _nasys_data_source = .;
  /*_nasys_data_destination = (nasys_program_mem == nasys_data_mem) ?
_nasys_data_source : nasys_data_mem;*/
  _nasys_data_destination = nasys_data_mem + 0x30000;

  .data _nasys_data_destination : AT (_nasys_data_source) 
  {
    _data = .;
    *(.data)
    *(.data.*)
    *(.gnu.linkonce.d*)
    SORT(CONSTRUCTORS)

    . = ALIGN(4);
    _edata = .;
    _nasys_data_destination_end = .;
    PROVIDE (edata = .);
  }

  _nasys_data_source_end = _nasys_data_source + SIZEOF(.data);

  /*
   * Lastly, the noninitialized storage area.
   * This will start immediately following
   * the initialized data destination address end.
   * This is either right next to the code,
   * if code address = data address, or out in
   * the data memory, if they're different.
   */

  __bss_start = .;
  _nasys_uninitialized_storage = .;

  .bss       :
  {
    _bss = .;
    *(.dynbss)
    *(.bss)
    *(.bss.*)
    *(COMMON)
    *(.dynsbss)
    *(.sbss)
    *(.sbss.*)
    *(.scommon)
    . = ALIGN(4);
  }
  _nasys_uninitialized_storage_end = .;

  /*
   * "_end" is used as the start of the mallocable memoryarea
   */

  _end = .;
  PROVIDE (end = .);

  /*
   * To see if you've exceeded memory, you can
   * check the symbols "_end" for the end of all static
   * data memory, and "_etext" for the end of the code,
   * against your memory map. -- dvb
   */

  /*
   * ------------------------------------------------------------
   * dvb say: "I'll leave all this stuff down here exactly
   * as I found it, for debugging info, without
   * understanding it."
   */

  /* Stabs debugging sections.  */
  .stab 0 : { *(.stab) }
  .stabstr 0 : { *(.stabstr) }
  .stab.excl 0 : { *(.stab.excl) }
  .stab.exclstr 0 : { *(.stab.exclstr) }
  .stab.index 0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment 0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the
beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  /* These must appear regardless of  .  */
}



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