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 95775

Article: 95775
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 26 Jan 2006 17:01:06 +1300
Links: << >>  << T >>  << A >>
yyqonline wrote:

> I have found that there is "clock high time violation" while timing
> verification using Altera QuartusII, with device "flex10K". I wonder
> whether this is caused by the pulse width, depending on gate delay, not
> long enough for driving FSM.
> Best Regards, 
> YuQing, Youth

Yes, see my earlier comment about CLK_min, that meant not FREQ,
but the HI and LOW minimum times that all clocks have.
Such a circuit will generate needle pulse clocks, so you will
need to watch the Min pulse widths.

-jg



Article: 95776
Subject: Re: Xilinx padding LC numbers, how do you feel about it?
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 25 Jan 2006 20:07:43 -0800
Links: << >>  << T >>  << A >>
Kevin Morris wrote:
> So, I have a question regarding the assertion that the datasheet LUT
> count is "important information."
>
> Why?  What is the real-world utility of that number?  Do some people
> know up-front how many LUTs their design is gonna use, and then they
> just need an accurate LUT count to pick the best FPGA?
>
> The problem with programmable logic datasheets is that it's almost
> impossible to put any real, relevant information on them.  A FEW things
> -  number of SerDes transceivers, maybe user pin count, marginally
> available block RAM...  are kinda useful, but for everything else,
> don't you really need to just do the design and see what device the
> tools tell you to use?
>
> I've written a couple of articles on/around this topic.  My favorite
> was:
> http://www.fpgajournal.com/articles/20040706_tango.htm
>
> and people also seem to like:
> http://www.fpgajournal.com/articles_2005/20050510_worldsbest.htm

You may not know how large your designs are until you finish them, but
there are many users who both have reusable IP with known sizes and
need to actually *plan* their work rather than just letting it happen.
Even if you don't know the size before you start, you can estimate it.
I have never done a design without some form of estimate before I
started.  Kinda like the software guys estimating SLOCs.  So why would
I want to work with numbers that are already off by 12.5% when
estimating a design?

In reality I decided to ask what others thought about the inflation
factor because the inflation factor ticked me off.  I was comparing X
to A and I couldn't just look at the data sheet, I had to do the
calculations to get the accurate numbers for X.  I am tired of vendors
making more work for me with no point other than boosting the ego of
some marketeer.  I was curious about what others thought.  Some don't
mind it, others seem to hate it like I do.

I have posted to this newsgroup about the inflation factor before and
the response from the X guys was far less than supportive.  Although
many seemed to feel the inflated numbers are not appropriate for a data
sheet, the only favorable response from X was to get the footnote added
to the new data sheets so that you know they are making it up.  But it
seems that now the X guys have seen the light and are 100% behind truth
in data sheets!  Hazzah!!!

Actually, it is good for X that we have a separate department for FPGAs
under software.  I am designing the board and would likely use a
Cyclone II because of the simpler power supply required.  But the FPGA
guy is a former FAE and wants to use X, so we'll use X.  This is such a
simple design it doesn't matter much which way we go.  Heck, we could
do without the FPGA if we didn't want to use a DSP.  We are doing CVSD
on voice and they already have the code for a DSP.  The DSP doesn't
have UARTs, so we are adding an FPGA for some UART interfaces.  If we
were willing to port the CVSD code we could do it all in an MCU with 6
UARTs and a small CPLD since one interface is Manchester encoded.  Or
we could drop the DSP and do it all in the FPGA.

The really ironic part is that everyone on the project is acting like
this job is even remotely difficult.  I had forgotten what it was like
to work for a defense contractor, the only hard part is figuring out
what the real requirements are...   anyone have some spare work to
throw my way?  I need something to keep my mind active :-)


Article: 95777
Subject: Re: OT:Shooting Ourselves in the Foot
From: Joseph2k <joseph2k@lanset.com>
Date: Thu, 26 Jan 2006 04:52:57 GMT
Links: << >>  << T >>  << A >>
Joerg wrote:

> Hello Chris,
> 
>>>
>>>Laws, regulations, more laws. One trait of engineers is or at least
>>>should be that they know where their limits are. Not because they are
>>>told by bureaucrats
>> 
>> You keep going on about bureaucrats setting the rules and every reply
>> has told you that the rules are set by qualified and experienced
>> ENGINEERS.
>> 
> 
> Huh? Maybe in the UK, not so much here.
> 
> 
>> You seem to have a problem of being judged by your peers.
> 
> 
> I don't. I do have a problem with overly restrictive regulations and so
> does our industry.
> 
> Regards, Joerg
> 
> http://www.analogconsultants.com
I wish i understood what you are complaining about.
BSEE, PE (Electrical CA, USA)
-- 
JosephKK


Article: 95778
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 25 Jan 2006 20:53:36 -0800
Links: << >>  << T >>  << A >>
If you really need to clock a flip-flop on both clock edges, the
circuit described in the recent posting by Bob Perlman (and apparently
originated by Gabor, whom I have contacted and congratulated) is really
much better and cleaner than my frequency doubler. Maybe a bit more
expensive, but flip-flops and XORs are cheap, and headaches are
expensive.
Peter Alfke, from home


Article: 95779
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "yyqonline" <yyqonline@gmail.com>
Date: 25 Jan 2006 22:02:36 -0800
Links: << >>  << T >>  << A >>
Thanks!
I use the circuit posted by Bob Perlman to construct a FSM just now and
the performance of timing verification via QuartusII seems to be good.
I think this may be a solution, but I whether I made the best choice to
construct the module.
Requirement:
*the work freq is 640Khz
*the expected datarate is 640K, 320K, 160K
*since this chip will be passive (without battery), power consumption
is very important
*when datarate is 640K, either higher freq (at the cost of higher power
consumption) or det(at the cost of larger area) have to be introduced;
while datarate is lower than 640K, neither is needed.
Then, I have three ways to choose from:
*a whole module using det-FSM
advantage: only one Fsm
disadvantage: extra control part, to decide whether negedge of clk is
active
*a module consisting of a det-FSM part and a set-FSM
(single-edge-trigged FSM) part
advantage: easy to realize
disadvantage:  two groups of state registers
*a module using higher freq, esp. 1.28Mhz
advantage: small area
disadvantage: higher power consumption
I am now making a module consisting of a det and a set FSM, but I am
not sure whether I am making the best choice.
Every advice would be highly appreciated.
Best Regards,
Yuqing Youth


Article: 95780
Subject: Re: How to handle the "gate count" issue?
From: "int19h" <tirath@replacethispartwithmynickname.com>
Date: Thu, 26 Jan 2006 17:14:10 +1100
Links: << >>  << T >>  << A >>
> Flip-flop count,
> I/O count (including required standards including bidirectional LVDS,)
> gigabit serial I/O.
> on-chip memory (width and depth),
> multipliers/accumulators,
> potential need for an on-chip microcontroller.

That seems like a very reasonable approach. Thanks Peter.




Article: 95781
Subject: Re: So what happened to JHDLBits?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 22:33:27 -0800
Links: << >>  << T >>  << A >>

Ed McGettigan wrote:
> I take umbrage to your assertion that Xilinx is a leach and doesn't
> contribute back to the open source communities. Xilinx has been a
> contributing Corporate Patron of Free Software Foundation for many
> years now https://www.fsf.org/donate/patron/index_html funding many
> open source projects through the FSF with our donations.

The value of open source tools to Xilinx, as compared to implementing
your own GPL free tools and maintaining them is something in the ball
park of $10-30M in NRE and an additional $1-3M/yr to maintain them.
If Xilinx's contributions to open source are a significant fraction of
that
then clearly you have contributed back to the community.

> In addition we funded, supported and developed the Virtex-II Pro and
> Virtex-4 PowerPC405 ports that are the parent post of this thread and
> then push for their release into the official Linux 2.4.x and 2.6.x
> PowerPC trees so that everyone will have access to them easily.

That hardly counts, as the PPC port project existed before Xilinx
included
PPC's in the Pro's, and the Xilinx platform specific work is self
serving
to press your own hardware sales.

Nothing in your post, or any other Xilinx employees response, describes
why Xilinx allowed several man years of open source development in the
JHDLBits project to be simply squashed.

Let's just say that trashing a half dozen young engineers expectations
of contributing to the open source community with great pride in their
support of Xilinx product, is pretty damn low.  Umbrage in that would
be an understatement.


Article: 95782
Subject: Re: So what happened to JHDLBits?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 22:40:24 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> Seems those who keep yelling for open bit streams aren't bothering to
> look at what is available, or try working with pieces.  They all seem to
> want full open bitstream without even understanding what all it entails
> to be able to successfully work with it.  You could do pretty much
> everything they seem to be looking to do within the existing XDL
> framework, and it gives the ability to use parts of the existing tools
> so you don't have to develop the entire tool chain from soup to nuts.
> Pick a piece of it and plug it into the existing tools.

It's not clear that XDL is in fact an official interface that will
avoid a
C&D order from Xilinx .... if it were completely documented, and the
parts data bases behind it completely documented, then your assertion
would be clearly true ... however, it isn't. Some reverse engineering
in unavoidable to use it fully, and that has clear restrictions from
Xilinx.

So, given that the JHDLBits project bit the dust at Xilinx's hands, and
it creaps into the same technology, and that Xilinx doesn't offically
bless
this interface to the degree of openess you suggest, let's just say it
would
be prudent to go a LOT slower in addopting it as the golden technology
you suggest.


Article: 95783
Subject: Re: So what happened to JHDLBits?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 22:51:30 -0800
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> So, given that the JHDLBits project bit the dust at Xilinx's hands, and
> it creaps into the same technology, and that Xilinx doesn't offically
> bless
> this interface to the degree of openess you suggest, let's just say it
> would
> be prudent to go a LOT slower in addopting it as the golden technology
> you suggest.

Prudent to the degree of if you are young or have any assets, stay the
hell clear of it for open source projects - as you may not be able to
work
long enough in your life to pay off a judgement against you.


Article: 95784
Subject: Re: open source fpga programmer programs
From: "Alex Gibson" <news@alxx.org>
Date: Thu, 26 Jan 2006 18:14:14 +1100
Links: << >>  << T >>  << A >>

"Larry Doolittle" <ldoolitt@localhost.localdomain> wrote in message 
news:slrndtfapv.u3t.ldoolitt@localhost.localdomain...
> On 2006-01-25, Eli Hughes <emh203@psu.edu> wrote:
>> Dave Feustel wrote:
>>> Are there any open source programs for programming fpgas?
>>
>> Don't waste your time.  Vendor's spend a *VERY* long time working out
>> bugs in their software.
>
> "There are two ways of constructing a software design. One way is
> to make it so simple that there are obviously no deficiencies
> and the other is to make it so complicated that there are no
> obvious deficiencies."
>    - C A R Hoare
>
>> With the level of complexity of an FPGA, you
>> don't want to waste time with buggy software that is developed in
>> someone else's spare time.  All of the actually chip programming,
>> routing stuff is vendor locked(for good reason), so your out of luck on
>> that.
>
> In other words, "shut up and get back on the couch".
>
>> That being said, Xilinx does offer their software for Linux. It is not
>> opensource but it does give you a non-windows alternative.
>
> "I won't run software written by cowards."
>    - Adam Stiles, referring to software provided without source code
>
>      - Larry

You obviously don't  develop using any fpga or most dsps then ? 



Article: 95785
Subject: Re: porting linux on ml403
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 23:20:46 -0800
Links: << >>  << T >>  << A >>

Ed McGettigan wrote:
> I take umbrage to your assertion that Xilinx is a leach and doesn't
> contribute back to the open source communities. Xilinx has been a
> contributing Corporate Patron of Free Software Foundation for many
> years now https://www.fsf.org/donate/patron/index_html funding many
> open source projects through the FSF with our donations.

First, if Xilinx had not been so heavy handed with the JHDLBits
project,
trashing the efforts of a half dozen young engineers, your umbrage
might
be half way valid. But the reality is that the economic value of gcc,
GNU,
and Linux is significantly more than $10M-30M NRE and $1m-3m/yr as
the UNIX licenses and royalities would have cost you more. The real
value
of GPL tools that you ship, if the company had developed GPL free
version
is an order of magnitude or two more than that.

*IF* your contributions to open software are a significant fraction of
the
equivalent UNIX license fees, then sure, Xilinx is paying it's way.

> In addition we funded, supported and developed the Virtex-II Pro and
> Virtex-4 PowerPC405 ports that are the parent post of this thread and
> then push for their release into the official Linux 2.4.x and 2.6.x
> PowerPC trees so that everyone will have access to them easily.

That is completely self serving to generate revenues from the hardware
sales. the PPC port existed long before Xilinx started shipping the IBM
core in Pro's.


Article: 95786
Subject: Re: Xilinx padding LC numbers, how do you reeeeellly feel about it?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 23:30:22 -0800
Links: << >>  << T >>  << A >>

austin wrote:
> They weave a web of untruths and half whispers with convenient
> coincidences to explain their troubles.

Xilinx's ommissions and the quest for that data is not a cultish
movement.

You still haven't explained just what the max currents are for the
various
power and ground rails are. Or the max power the chip can actually
safely
disappate without violating the die limits or seriously impacting the
life of
the die due to migration problems.

There are a lot more undocumented things to discuss after these basics,
like the dynamic power for LUT's, FF's, local routing, long routing,
BRAM's
and the like to get a handle at the front end of the design
partitioning what
the power requirements will be.

These are serious engineering issues for anyone that wishes to actually
USE a significant portion of the chips resources, rather than expect
that
85% of the die will be idle.

Not even on die measuring is enough without this data, as we can easily
create a hot spot away from the diode that exceeds die temp specs by
a factor of two or more.

This is not a regligous debate ... this is real engineering up front
for worst
case loads, not tinking in the lab with missguided retrofit cooling.


Article: 95787
Subject: Re: open source fpga programmer programs
From: "GEO" <v2geo@hotpop.com>
Date: 25 Jan 2006 23:45:33 -0800
Links: << >>  << T >>  << A >>
My guess is that, Xilinx is more afraid of their tools being used by
other FPGA vendors. Probably they don't want ISE to support Altera
devices and the like!, if it is opensourced. That may be the biggest
risk for them - not reverse engineering.


Article: 95788
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 23:49:00 -0800
Links: << >>  << T >>  << A >>

Jim Granville wrote:
> So that indicates that 100% fabric usage is not an impossible task ?

I certainly don't think it's impossible for some designs, it is however
"difficult" with present tools.

> It seems one 'stub' of an opensource project could be to handle this
> Xilinx-User interface. Rather than try and rebuild their tools from the
> ground-up, why not work with them to improve the tools ?
> Yes, this is done a small detail at a time.

something of a chicken and the egg problem. Getting major changes into
the par design are VERY LIKELY to dribble out slowly over 5 years to
avoid
a major upset for the existing customer base.

> Anyone doing an RC-FPGA array, should have strong thermal management,
> even up to the copper heat pipe schemes of the extreme gamers ! :)

Yep, in each of the large system design proposals I have made for the
last year that is a milled 1/4" copper plate heat sink in direct
contact with the fpga array, connected integral with a chilled water
heat exchanger. Just can not handle the heat density of a large RC
array with air. Austin may think that needing the max parameters for
these devices is a joke, but when you propose to put several thousand
of them in a 1M cube, your customers actually demand thermal and power
data as diligent engineering. While the lack of these specs for the
Xilinx product may sit will for some, it's a critical road block for
serious hit the ceiling hard designs. Putting a significant fraction of
a megawatt into a desktop box isn't childs play, or even a hobby
project, it starts with a lot of engineering before the software design
even is a dream.


Article: 95789
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: David Brown <david@westcontrol.removethisbit.com>
Date: 26 Jan 2006 09:21:09 +0100
Links: << >>  << T >>  << A >>
yyqonline wrote:
> Thanks!
> I use the circuit posted by Bob Perlman to construct a FSM just now and
> the performance of timing verification via QuartusII seems to be good.
> I think this may be a solution, but I whether I made the best choice to
> construct the module.
> Requirement:
> *the work freq is 640Khz
> *the expected datarate is 640K, 320K, 160K
> *since this chip will be passive (without battery), power consumption
> is very important
> *when datarate is 640K, either higher freq (at the cost of higher power
> consumption) or det(at the cost of larger area) have to be introduced;
> while datarate is lower than 640K, neither is needed.
> Then, I have three ways to choose from:
> *a whole module using det-FSM
> advantage: only one Fsm
> disadvantage: extra control part, to decide whether negedge of clk is
> active
> *a module consisting of a det-FSM part and a set-FSM
> (single-edge-trigged FSM) part
> advantage: easy to realize
> disadvantage:  two groups of state registers
> *a module using higher freq, esp. 1.28Mhz
> advantage: small area
> disadvantage: higher power consumption
> I am now making a module consisting of a det and a set FSM, but I am
> not sure whether I am making the best choice.
> Every advice would be highly appreciated.
> Best Regards,
> Yuqing Youth
> 

What is your design actually doing?  And is an FPGA actually the correct 
solution?  When you are talking about relatively low frequencies, and 
very low power requirements, you might be better off using a 
microcontroller - depending of course on what the data is, and what you 
are trying to do with it.

Article: 95790
Subject: Re: How to handle the "gate count" issue?
From: fpga_toys@yahoo.com
Date: 26 Jan 2006 00:29:23 -0800
Links: << >>  << T >>  << A >>

int19h wrote:
> > Flip-flop count,
> > I/O count (including required standards including bidirectional LVDS,)
> > gigabit serial I/O.
> > on-chip memory (width and depth),
> > multipliers/accumulators,
> > potential need for an on-chip microcontroller.
>
> That seems like a very reasonable approach. Thanks Peter.

yep, a reasonable approach to writing your proposal to be X vendor
locked.

Your customer may not be high enough up the food chain to get delivery
of
the product in a shortage, and doing a design specifically including
sole
sourced technology that goes on allocation is called Chapter 7.

First, consider each of these functions carefully, are they a MUST HAVE
for
the product, and if so are there two vendors with parts that fit the
bill. If they
are MUST HAVE, do they need to be on chip ... would a multi-device
design
be safer for the product. Is the talent to actually complete the
project inhouse
already, or is it a specialized field that you may not be able to hire
to meet
schedule.

The basic question about FPGA's, is there enough LUT/FF's to realize
the
design. Everything past that, needs to be carefully considered in
regards
to multi-source availablity should there be high demand and allocation
for
the parts.


Article: 95791
Subject: Re: ISE8.1 on Linux, first impressions
From: "hutzelbutz" <joachim.becker@imtek.uni-freiburg.de>
Date: 26 Jan 2006 00:34:02 -0800
Links: << >>  << T >>  << A >>
:-)

Back to the problem:

I think I forgot to mention that I am running the tools on dual-core
machines, which seems to be part of the problem.
When I watch the _pn processes while starting in "top", I see that with
one call of ise, there are two _pn started on the same CPU. One has a
bit of CPU usage for a short time, the splash screen shows and then
they both stand with 0.1 % CPU. After 4 Minutes, one _pn is moved to
the other CPU and this process then takes 1% CPU. 10 seconds later the
GUI is there. Still both processes take exactly the same amount of
memory and live happily ever after.

I don't know enough about multi-processor load distribution in Linux,
but this behavior is reproducable. Could it be that those 4 minutes
come from the time, the OS needs to find out that one process should be
switched to the other CPU???

I would be curious to hear the experts about this topic!

Cheers,
 Joachim


Article: 95792
Subject: Re: open source fpga programmer programs
From: "Alex Gibson" <news@alxx.org>
Date: Thu, 26 Jan 2006 19:55:09 +1100
Links: << >>  << T >>  << A >>

<fpga_toys@yahoo.com> wrote in message 
news:1138206477.465109.299250@g47g2000cwa.googlegroups.com...
>
> Eli Hughes wrote:
>> Don't waste your time.  Vendor's spend a *VERY* long time working out
>> bugs in their software.  With the level of complexity of an FPGA, you
>> don't want to waste time with buggy software that is developed in
>> someone else's spare time.  All of the actually chip programming,
>> routing stuff is vendor locked(for good reason), so your out of luck on
>> that.
>>
>> That being said, Xilinx does offer their software for Linux. It is not
>> opensource but it does give you a non-windows alternative.
>
> Eli ... the open source community does as well. It's rather an insult
> against those of us that do volunteer our time toward open source
> project to brashly brand open source that way.

Open source is great for a lot of things and I use it where possible
but for other areas its a long way from useable.

> Consider that Xilinx believes the Linux is a stable platform for it
> tools,
> is it not? Consider thart Xilinx uses the GCC compiler for it's PPC
> support, does it not? Consider that Xilinx uses the GNU libraries on
> the PPC, does it not?

Just wondering who did a lot of the work on the original ppc gcc ?

IBM or freescale empoyees ?

> The only thing here that is wrong, is that Xilinx leaches off the backs
> of open source developers, then asserts prioprietary rights to open
> source efforts to do a BETER job at place, route, and bit steam
> generation. At least other mainstream corporations have the good
> sense to both embrace open source in their product offerings, and
> give back to the open source community at the same time.
>
> See the what happened to JHDLBits thread.
>
> John
> FpgaC developer

The JHDLbits ending so far isn't good.
But I'd be very wary of doing any thesis project with a company
I wasn't an empoyee of and even then I'd still be careful.

You need to have a legal agreement on paper before you start,
may take time and a lot of effort but these days if you do not cover
your arse you are asking for trouble.

Surely one problem is by the time you have the whole tool working correctly 
with a part,
(or at least the initial part or two)
there is a good chance that one or two new parts have been introduced
and the people who may want to use that tool want to use the latest part.

What tool is cray using for their reconfigurable computing systems ?

If the parts are very similar it shouldn't be to much of a problem.

How is a company using an open source compiler leaching from open source ?
If the software is placed in/under license where it can be used, what is the 
problem
as long as the company follows the license ?

If you don't like it don't put the software under that license.

Rather than openly attacking and abusing xilinx in a public forum,
surely a better move would be to sit down and talk to them ?

Alex



Article: 95793
Subject: Re: Stop. Go. Yield.
From: fpga_toys@yahoo.com
Date: 26 Jan 2006 01:03:03 -0800
Links: << >>  << T >>  << A >>

Kevin Morris wrote:
> Group disclaimer:  After three years of carefully avoiding using this
> group to gather article input, I've now done it twice in less than a
> month.  I promise not to make it a habit.  In both cases, I needed
> information beyond the reach of our normal PR and design team channels.
>  If you object, please let me know and I'll take your opinion into
> consideration.

Don't worry about it ... the other vendors here are pretty in your face
anyway.


Article: 95794
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "yyqonline" <yyqonline@gmail.com>
Date: 26 Jan 2006 01:04:27 -0800
Links: << >>  << T >>  << A >>
Thanks!
At the end we will implement our design to a chip by asic tech, and now
we are designing and verifying via Fpga.
That is why the freq and power are always on our list.
Best Regards,
YuQing Youth


Article: 95795
Subject: Re: So what happened to JHDLBits?
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 26 Jan 2006 10:05:47 +0100
Links: << >>  << T >>  << A >>
<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1138257624.935300.25730@o13g2000cwo.googlegroups.com...
>
> Ray Andraka wrote:
>> Seems those who keep yelling for open bit streams aren't bothering to
>> look at what is available, or try working with pieces.  They all seem to
>> want full open bitstream without even understanding what all it entails
>> to be able to successfully work with it.  You could do pretty much
>> everything they seem to be looking to do within the existing XDL
>> framework, and it gives the ability to use parts of the existing tools
>> so you don't have to develop the entire tool chain from soup to nuts.
>> Pick a piece of it and plug it into the existing tools.
>
> It's not clear that XDL is in fact an official interface that will
> avoid a
> C&D order from Xilinx .... if it were completely documented, and the
> parts data bases behind it completely documented, then your assertion
> would be clearly true ... however, it isn't. Some reverse engineering
> in unavoidable to use it fully, and that has clear restrictions from
> Xilinx.
>
> So, given that the JHDLBits project bit the dust at Xilinx's hands, and
> it creaps into the same technology, and that Xilinx doesn't offically
> bless this interface to the degree of openess you suggest, let's just say 
> it
> would be prudent to go a LOT slower in addopting it as the golden 
> technology
> you suggest.
>

1) XDL is official interface, any tools that parse and/or generate/modify 
XDL for any purpose are OK.
2) Xilinx can not make anyone or ar project to 'bit the dust' as you are 
saing.

If some entity developes something that has real value, then Xilinx will buy 
that entity (not kill!).

If some open source project has no interest and no funding then it dies 
eventually, all by itself. So that what has happened.

All RE needed can arranged to be done by some untouchable entity if it 
really comes to it.

But for Xilinx bitstream support there is a lot that can be done without any 
RE

first as Ray has also said the XDL contains pretty much 100% of the physcial 
design info.
the .LL files contains pretty much bit locations for purposes like post 
bitgen bitstream patching, etc..

there are so far no tools that actually do something useful with XDL and LL 
files, and I am sure Xilinx would welcome such open source projects.

-- 
Antti Lukats
http://www.xilant.com








Article: 95796
Subject: Re: Stop. Go. Yield.
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 26 Jan 2006 22:34:50 +1300
Links: << >>  << T >>  << A >>
Kevin Morris wrote:
> I'm finishing up an FPGA Journal article called "Stop. Go. Yield. -
> Dude!  Where's my Chip?"

Hmm.. Not a title that travels internationally very well...
-jg


Article: 95797
Subject: Re: Webpack 8.1i size
From: "GEO" <v2geo@hotpop.com>
Date: 26 Jan 2006 01:55:36 -0800
Links: << >>  << T >>  << A >>
I got a reply back from Xilinx, it turns out that they are making a
DVD available soon ( from the download page ).  But no hope on getting
a splitted download!

I juest happened to visit QuickWorks (Quicklogic) download page,  they
nicely put a install.bat, p1,p2,p3,p4 (77MB x 4files).


Article: 95798
Subject: Re: Stop. Go. Yield.
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 26 Jan 2006 10:04:40 -0000
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:43d897a9$1@clear.net.nz...
> Kevin Morris wrote:
>> I'm finishing up an FPGA Journal article called "Stop. Go. Yield. -
>> Dude!  Where's my Chip?"
>
> Hmm.. Not a title that travels internationally very well...
> -jg
>
Hi Jim,
Not sure it even travels out of CA! But I like it. I can see Jeff Bridges 
out of "The Big Lebowski" waiting for FPGAs.
Maude Lebowski: What do you do for recreation?
The Dude: Oh, the usual. I bowl. Drive around. Wait for V4 MGTs. The 
occasional acid flashback.

As for delivery problems, I ask my FAE. He's pretty good at translating the 
'official' availability into real numbers.

HTH, Syms.



Article: 95799
Subject: Re: How to handle the "gate count" issue?
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 26 Jan 2006 10:29:34 GMT
Links: << >>  << T >>  << A >>
On Wed, 25 Jan 2006 12:38:18 +1100, "int19h" <tirath@replacethispartwithmynickname.com> wrote:
>Hi all,
>
>I need some advice on how to treat the "equivalent gate count" issue. I have 
>to make a presentation on something soon, where FPGAs are the initial 
>foundation of the project, and I anticipate having to provide some 
>correlation between "slices" and "gates" as an estimate to the capacity of 
>current-generation FPGAs.
>
>Ideally I would provide a slice and logic area estimate for the specific 
>design, but the design is not nearly complete enough to provide such 
>reliable estimates. For now, I have to arm-wave it. I don't need it to be 
>vendor-neutral though, I can be Xilinx specific. Any suggestions anyone?
>
>-int

Since you don't mind being Xilinx specific, the following link:

    http://www.fpga-faq.org/compare/build_form.cgi

may be of some help, as it allows comparisons of different devices,
and different product families, it does not have the insane Xilinx
logic cell inflation factor, it gives the formulas for converting
from LUTs/FFs to vendor neutral "Dog Gates" (sort of like Dog Years  :-) .


Philip



===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG



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