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 119000

Article: 119000
Subject: Re: Xilinx software quality - how low can it go ?!
From: Manny <mloulah@hotmail.com>
Date: 9 May 2007 03:25:07 -0700
Links: << >>  << T >>  << A >>
In my NVIDIA GPU, I had to disable the transparency feature 'cause it
caused EDK8x to freeze on the BSB wizard. You can imagine the amount
of headache this caused me until I managed to hack my way out
utilizing speculative guess!


Article: 119001
Subject: XILINX ISE 9.1i: DELAYCHAIN by input data
From: uvbaz <uvbaz@stud.uni-karlsruhe.de>
Date: 9 May 2007 04:24:30 -0700
Links: << >>  << T >>  << A >>
Hi,

I am working on an DSP, have problem by data receiving. As listed
below, xilinx ise tools build a "DELAYCHAIN" into the circuit, as a
result, the data needs 7.956ns from PADS to FlipFlops.
My questions are:
1. How can i control the tools, to build or not to build the
"DELAYCHAIN".
2. When the data need 7.956ns, to get to the FFs, will it works, when
the datarate 150MHz (6.6ns) is?

Timing report from XILINX ISE 9.1i
======================================================
Delay type Delay(ns) Logical Resource
Tiopi                 0.943  i_data<2>
                                  i_data_2_IBUF
net (fanout=1)    0.063  i_data_2_IBUF
Tidockd             6.950  instance1/data_int<2>.DELAYCHAIN
                                  instance1/data_int_2
Total 7.956ns (7.893ns logic, 0.063ns route)  (99.2% logic, 0.8%
route)
=======================================================

Thanks
Cheng


Article: 119002
Subject: Re: First MicroBlaze demo design for Spartan-3A Starterkit
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 09 May 2007 12:24:42 +0100
Links: << >>  << T >>  << A >>
On Tue, 8 May 2007 08:37:46 -0700, "John_H" <newsgroup@johnhandwork.com>
wrote:

>"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
>news:dot043d1oc23r5mjr4uco4j24h5n7nnqn5@4ax.com...

>> order, asking only a mere $75 for shipping, on what, a 1kg product?
>> We'll see how long it takes...
>>
>> Hey Xilinx, I'd suggest there's a little room for improvement here.
>>
>> - Brian
>
>If you sign up for X-Fest in Manchester, you might be offered a seminar 
>discount for development boards such as the Spartan-3A.  Heck, the X-Fest I 
>attended even gave one away.  There are a couple X-Fests in the UK, 
>Manchester is just the first of the two at the end of May. 

I wonder if you actually have to attend the X-Fest, or would signing up
qualify? Manchester would be about a 22 hour round trip, or about 10
hours if I fly. 

An expensive way to save $26 + import duty + shipping!

- Brian


Article: 119003
Subject: Re: An Open-Source suggestion for Xilinx
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 09 May 2007 12:40:38 +0100
Links: << >>  << T >>  << A >>
On Tue, 8 May 2007 15:12:39 -0600, <steve.lass@xilinx.com> wrote:

>I have forwarded your comments to our configuration solutiuons
>group. They are working on ideas to solve the issues you listed
>below.
[...]
>There are a few programs that we could open-source, but they
>only have a few engineers working on them, so it would not save
>resources since we have to manage the open-source projects.
>
>The bigger applications like ProjNav and XPS are much more
>device/Xilinx specific than most of you are implying so I don't
>see an easy solution there either.

Another possible [candidate for open-source | starved orphan within the
Xilinx toolchain] is the floorplanner. 

(a) Unless it has GREATLY improved in 9.1, it has major shortcomings
that have not been fixed in several major toolchain releases.

(b) if it properly supported hierarchical RPMs it could be a very useful
tool for high performance design, and/or allow an entry point for Open
Source to add value to component placement.

(c) [conjecture] its interfaces and device specific "knowledge" are less
detailed than ISE or the back end, therefore easier to release to Open
Source than the full tool set. 

- Brian

Article: 119004
Subject: Re: First MicroBlaze demo design for Spartan-3A Starterkit
From: Antti <Antti.Lukats@xilant.com>
Date: 9 May 2007 05:03:53 -0700
Links: << >>  << T >>  << A >>
On 9 Mai, 13:24, Brian Drummond <brian_drumm...@btconnect.com> wrote:
> On Tue, 8 May 2007 08:37:46 -0700, "John_H" <newsgr...@johnhandwork.com>
> wrote:
>
> >"Brian Drummond" <brian_drumm...@btconnect.com> wrote in message
> >news:dot043d1oc23r5mjr4uco4j24h5n7nnqn5@4ax.com...
> >> order, asking only a mere $75 for shipping, on what, a 1kg product?
> >> We'll see how long it takes...
>
> >> Hey Xilinx, I'd suggest there's a little room for improvement here.
>
> >> - Brian
>
> >If you sign up for X-Fest in Manchester, you might be offered a seminar
> >discount for development boards such as the Spartan-3A.  Heck, the X-Fest I
> >attended even gave one away.  There are a couple X-Fests in the UK,
> >Manchester is just the first of the two at the end of May.
>
> I wonder if you actually have to attend the X-Fest, or would signing up
> qualify? Manchester would be about a 22 hour round trip, or about 10
> hours if I fly.
>
> An expensive way to save $26 + import duty + shipping!
>
> - Brian

you only save 26, duty and shipping you have to pay anyway.
but thats not the only special, so its possible to save more (if you
spend more)

Antti






Article: 119005
Subject: Re: An Open-Source suggestion for Xilinx
From: Herbert Kleebauer <klee@unibwm.de>
Date: Wed, 09 May 2007 14:27:49 +0200
Links: << >>  << T >>  << A >>
steve.lass@xilinx.com wrote:
 
> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.
> 
> The bigger applications like ProjNav and XPS are much more
> device/Xilinx specific than most of you are implying so I don't
> see an easy solution there either. XST is very device specific and
> this is one of the applications that starts their work over a year
> ahead of a new device introduction.

Why can't Xilinx make available the complete specification of
the configuration bitstream for a single, already obsolete
device, maybe the original 5/3.3V Spartan XCS40/XCS40XL chip
together with the guarantee to deliver this chips for at least
20 years. Then the open source community had a basis to 
develop their own design tools at least for this FPGA. And I suppose 
there are many smaller projects for which such an old chip is more 
than sufficient.

What would you say, if a CPU manufacturer doesn't make available
the processor documentation (instruction set, instruction encoding).
He only gives you a C compiler to design your software and 
anything below is the secret of the company. Nobody would buy such
a processor, but that's exactly the situation with FPGA's.

Article: 119006
Subject: Re: About memory interface generater 007 tool
From: Paul <pauljbennett@gmail.com>
Date: 9 May 2007 05:33:34 -0700
Links: << >>  << T >>  << A >>
When you create the CoreGen project you need to have verilog selected
(I assume the problem is that you're getting VHDL instead?).  But it's
a project setting, I believe, not a MiG setting.

On May 9, 12:23 am, Gordon Freeman <gordonfreeman1...@gmail.com>
wrote:
> Hi everyone!
> When I use  memory interface generater tool, I select device XC3S400.
> The tool dosen't generate verilog code for me. I don't know why. Can
> you help me to solve it, please?



Article: 119007
Subject: Re: Xilinx software quality - how low can it go ?!
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Wed, 9 May 2007 12:53:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2007-05-09, Ben Jones <ben.jones@xilinx.com> wrote:
> tool flows. Most serious FPGA developers already have their own makefiles 
> and associated infrastructure that eases the portability of their design 
> from one vendor's device to another's. At which point, slapping a sparkly 
> GUI on top of it is not a high priority for them.

Personally I'd rather have effort spent on a high quality emacs-mode for
RTL development. VHDL mode is good, Verilog mode is good, but there is
a _huge_ opportunity to improve the current situation. I'd also like to
see a more "standardized" makefile based build system so that not every
developer has to reinvent that particular wheel. Especially since the
available parts (command line tools) are sometimes cumbersome to fit into
the wheel (makefile).


> An open-source equivalent of the Core Generator (~MegaWizard) could work; 

Opencores would seem like an ideal place for development of something like
this. However, one problem that might bite open source efforts in this area
is patents. While software patents might not be legal in at least some
parts of the world, hardware patents are. So the legal status of a hypothetical
parameterizable hardware library would be less certain than a software
library... Personally I'm curious whether distributing the RTL source
code for lets say an FFT core which is implemented using the "Foo bar method"
infringes upon JBN's patent on a hardware implemention of the "Foo bar method".

As an aside, Opencores actually had a "socbuilder" project, unfortunately
no activity has taken place there for 3 years or so.



> But would it make sense to try and do an open source FPGA floor-planning 

Actually, I think an open source FPGA floorplanning tool could be done. I've
been thinking about it myself at some time and it wouldn't require that much
knowledge of the device. It might even be possible to do a placer as open
source (I've been toying with the idea of writing my own placer algorithm as
a hobby project, just to see how difficult it is to get decent results. I
certainly wouldn't realistically expect to beat the Xilinx placer though :))

Making a good quality router is probably much more difficult. (You could do
probably do a bad router by using a subset of the available wires and not
worry about the timing constraints though.) A good quality router would
not only need access to all routing possibilities in some way but also the
timing properties of the paths.

I could also point out that there actually is source code available on the
net for a place and routing tool (VPR). But the license is not open source
last time I checked (http://www.eecg.toronto.edu/~vaughn/vpr/terms.html).


> programming stuff, as has been pointed out by several others. I would be 
> incredibly happy to see a proper, flexible, standard stack for accessing 
> JTAG devices - and to achieve that, I think an open source effort is pretty 
> much the *only* approach that will work.

Hear hear!


All in all, lots of good thoughts in Ben's posting I think.

Some extra bonus thoughts from me: the open source community probably
don't gain any good will by demanding an arm and a leg from Altera
and Xilinx without showing that we can add significant value to their
bottom line.

For example, if we show that we can build a high quality synthesizer
frontend that has about the same performance as XST, they might seriously
consider contributing to that effort, perhaps even replacing their own
tool with the open source tool. But right now the only open source
synthesizing tool I'm aware of (Icarus) has a much too small user
community to make that happen.

/Andreas

Article: 119008
Subject: Re: Ubuntu and Webpack?
From: Stephen Williams <spamtrap@icarus.com>
Date: Wed, 09 May 2007 07:33:39 -0700
Links: << >>  << T >>  << A >>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cpope wrote:
>> cpope wrote:
>>> Has anyone tried to install xilinx webpack on ubuntu 6.06LTS? If I run
> the
>>> web download tool (sudo ./setup) I get through the questions but it dies
>>> shortly after I click install. If I use the single file download it asks
> for
>>> a registration ID which as far as I can tell doesn't exist for webpack?
> Any
>>> help is appreciated.

> 
> Yes, I've done that. I'm saying that both installation methods are failing.
> The web download method dies after install starts and the single file
> download method asks for a non-existant registration ID. Thanks
> 
> 

I've experienced the web install method not working on SuSE 10.1,
fecora core 6 or RHEL4. It seems to be universally broken and not
just a porting problem.

The "Single File Download" installed on RHEL4 just fine, and
without asking for registration IDs, so that seems like a more
local problem for you.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGQdvDrPt1Sc2b3ikRAuIoAJ9v515JwqO5KthxF3uqrFBmLh+qAACgtjkT
hvIsDEJ9Lzj/8FWl7W6kyRY=
=bG7Y
-----END PGP SIGNATURE-----

Article: 119009
Subject: Re: lwIP RAW mode support for V4 temac
From: Patrick Dubois <prdubois@gmail.com>
Date: 9 May 2007 07:45:01 -0700
Links: << >>  << T >>  << A >>
On May 8, 4:50 am, Guru <ales.gor...@email.si> wrote:
> Why do you need a RAW mode? Do you actually need a TCP/IP stack? If
> not you can write directly to TEMAC and send RAW frames at highest
> speed possible.
>
> Guru

Well, we need to send data using the TCP protocol ideally, but the UDP
protocol could work as well. So my understanding is that a TCP/IP
stack is required in our case. Maybe we could construct our own UDP
packets without a stack though...

RAW mode is simply to acheive better performance than sockets mode and
also to ease the development (we don't want to bother with an OS and
threads).

Thanks.

Patrick



Article: 119010
Subject: Re: ML405 LCD
From: radarman <jshamlet@gmail.com>
Date: 9 May 2007 07:55:37 -0700
Links: << >>  << T >>  << A >>
On May 8, 1:33 pm, Aggie <c.kevin....@gmail.com> wrote:
> How can I display "hello world" onto the Char LCD which is on the
> development board (ML405)?
>
> I realized a similar topic has been posted. But our situation is a
> little different.
>
> I want to do it the "software" way, i.e. write a C program and
> download it to the board.
>
> Here's what I'm using:
> Xilinx Platform Studio 8.2
> Wind River - OS vxwork 6.4
>
> Thanks in advance. Any input help.
>
> Kevin


Since no one else bit, the easiest way is to assign a GPIO port to it,
and connect it to the LCD pins per the schematic. From there, you will
need to write routines that drive the pins according to the datasheet
(practically any HD44780 sheet should do, as they all follow that
spec)


Article: 119011
Subject: Re: lwIP RAW mode support for V4 temac
From: Patrick Dubois <prdubois@gmail.com>
Date: 9 May 2007 07:57:25 -0700
Links: << >>  << T >>  << A >>
On May 8, 4:29 pm, "Paul  Tobias" <PaulTob...@MyWebSite.com> wrote:
> If you browse to my website atwww.paultobias.com/Xilinx, I have posted the
> source to a
> LWIP driver and startup code for a raw API TCP client application that runs
> on the V4fx ML403 board on top of Xilkernel (though it could be just as
> easily standalone at present.)
>
> LWIP using sockets was far too slow for us, so I put this together using the
> Temac sockets code for EDK 8.2/9.1 and the emac raw api driver (I think for
> an older EDK version).
> So far this is tested only for receiving TCPIP packets, which it does at
> 3-400 Mbps, which is in
> line with Ron Wright's presentation at Xfest recently.  Using a good 32 bit
> memory aligned memcpy function instead of the many bytewise packet copies in
> LWIP should be an easy
> first step to improve this rate.
>
> You are welcome to use this as a starting point, but be aware that I am a
> novice at LWIP, TCP/IP internals and Xilinx, and the output routines are
> totally untried or tested, except for
> those used by the lower levels (ARP and ACKs etc.).   More info in the
> ReadMe file on site.
>
> Paul
>
> www.paultobias.com

Thanks a lot Paul. Your XTemacif.c driver is exactly what is needed
(which should have been provided by Xilinx in the first place). I
didn't feel like I had the knowledge to write it myself, thanks for
sharing your code!

Patrick


Article: 119012
Subject: Re: Xilinx software quality - how low can it go ?!
From: Chris <c@c>
Date: Wed, 09 May 2007 17:55:28 +0200
Links: << >>  << T >>  << A >>
Mike Lundy wrote:

> I have a dream where a software-only engineer [namely, most of my
> friends] could simply buy a dev kit and have something nifty working
> within an hour or two of it arriving in the mail. Much like the way
> Lego Mindstorms work- Lego is brilliant with usability. If you design
> your software so a 10-year-old could use it, you're pretty much
> covered all your bases :)

Well I happen to fall in this category, being a software engineer, and
having bought the Spartan-3E Starter kit. Got ISE 8.1, which works just
fine and had my first design running in just a few hours. I wouldn't
say that the learning curve is terribly high, or that the Xilinx board
was expensive (about ~$150). Of course it would be nice to have parts
of ISE being open-source, though. I just can't see what it could provide
that isn't already part of the package.

Article: 119013
Subject: Re: Xilinx software quality - how low can it go ?!
From: fpga_toys@yahoo.com
Date: 9 May 2007 09:06:11 -0700
Links: << >>  << T >>  << A >>
On May 9, 6:53 am, Andreas Ehliar <ehl...@lysator.liu.se> wrote:
> Some extra bonus thoughts from me: the open source community probably
> don't gain any good will by demanding an arm and a leg from Altera
> and Xilinx without showing that we can add significant value to their
> bottom line.

Many of the open source projects that have commercial support (IBM,
SUN, etc) turned out to be useful for those vendors to avoid licensing
fees (SCO/AT&T, Microsoft, etc) for the expensive monopoly products
(UNIX, Microsoft Office, etc). The replacement products (Linux,
OpenOffice, etc) had growing pains as things needed to be rewritten to
remove licensed parts.

In the early days of UNIX (a portable operating system) many of the
vendors laughed hard a long about how poor a performer a high level
language operating systems and applications would be ... while the
dino assembly language OS's, compilers, tools and applications slowly
died away, it became clear the NIH factors were much stronger than the
technical basis for those arguements. We learned that the differences
in server hardware (which are just as great as FPGA internals) could
be abstracted away into hardware architecture layers that were VERY
vendor dependent, yet had very high levels of common code factored
into supporting subsystems.

Complexity wise, there are very common threads in FPGA vendor
tools ... high license costs make FPGA compilers (synthesis, place and
route tools) expensive for wide scale adoption to replace CPU's ...
where software tools are largely free or relatively low cost.  While
Xilinx states that licensing prohibts an OSS migration, it's clear
from the StarOffice to OpenOffice migration that isn't always the
case, and in the end the vendor version with licensed products offers
a proprietary superior supported product for those customers that need
all the features, while leveraging significant OSS advantages for the
base product that expands the market.

Likewise, just as UNIX/LInux have shown portable operating systems in
a high level language are not only possible, but superior for mass
markets, there is a strong likelyhood that similar evolution of
synthesis, place and route tools is also possible. DItto for the GNU
and GCC tool chains which provide broad cross platform solutions, not
always as optimal as proprietary compilers from certain vendors, but
broadly usable by most developers.  Just as there are still some
proprietary highly optimized OS's, compilers, and tool chains for
certain computer applications for both the high end servers and low
end embedded ends, if open source FPGA tools become common, there will
remain proprietary solutions for niche markets too. Linux and GCC are
not the only choice, but certainly the most common in certain high and
low end markets, because they are open, vendor supported, and customer
supported.



Article: 119014
Subject: Re: An Open-Source suggestion for Xilinx
From: Stephen Williams <spamtrap@icarus.com>
Date: Wed, 09 May 2007 09:16:20 -0700
Links: << >>  << T >>  << A >>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I think you may be underestimating the importance of the ancillary
stuff that people use daily and are misinterpreting what people are
asking for...

steve.lass@xilinx.com wrote:
> OpenOffice looks like a good eample of something that fits
> well with the open-source model, but I don't see that good of
> a fit with our tools.

Certainly not all of them, but...

> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.

I hope one of those tools is the programming tool suite. There
are many complaints about impact, and there are many situations
where users would just *love* to be able to customize the programmer
for their hardware.

Where I work, we've pretty much given up on being able to use
impact for anything other then writing ACE files, and it does
a clunky job at that. I suspect that open-sourcing impact would
make a *lot* of folks very very happy.

> The bigger applications like ProjNav and XPS are much more
> device/Xilinx specific than most of you are implying so I don't
> see an easy solution there either. XST is very device specific and
> this is one of the applications that starts their work over a year
> ahead of a new device introduction.

I think no one (or almost no one) thinks it is practical, or even
desirable, for you to open-source xst, map, or par, or similar
tools. And quite frankly, those tools don't have the problems that
all the other fluff has with portability.

What people want is a more open-source friendly attitude with all
the other bits. The programmer is a blatant case where there are
already several open-source programmer projects trying to make your
programmer tools useful in various situations where impact breaks
down. Give these projects active help, or turn impact into an open-
source project, and many people will be happy.

Overall, people want Xilinx to be more cooperative with open-source
up front, instead of fighting it every step on the way. If you start
with an open-source friendly attitude, then you'll surely find many
ways to be more open that *help* your business. It shouldn't be a
battle. We're not out for blood. We want to use Xilinx (or Altera,
or etc.) parts!

For the record, I have generally encountered helpful people within
Xilinx for my own open source project (Icarus Verilog) so I suspect
that this missing the point of open source is not universal within
the sheltered caverns.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGQfPUrPt1Sc2b3ikRAjaoAJ903w6q0cxgtaf+8MtNOFZs9Y9MzwCgyDn5
4EDfChTwUjuVKNysVM1/eNc=
=n5Qr
-----END PGP SIGNATURE-----

Article: 119015
Subject: Re: Open Source (was: Xilinx software quality - how low can it go ?!)
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Wed, 9 May 2007 17:27:48 +0100
Links: << >>  << T >>  << A >>

"Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message 
news:f1sg8l$ats$1@news.lysator.liu.se...

>> An open-source equivalent of the Core Generator (~MegaWizard) could work;
> Opencores would seem like an ideal place for development of something like
> this. However, one problem that might bite open source efforts in this 
> area
> is patents. While software patents might not be legal in at least some
> parts of the world, hardware patents are. So the legal status of a 
> hypothetical
> parameterizable hardware library would be less certain than a software
> library... Personally I'm curious whether distributing the RTL source
> code for lets say an FFT core which is implemented using the "Foo bar 
> method"
> infringes upon JBN's patent on a hardware implemention of the "Foo bar 
> method".

This is true, and it's certainly a concern. Still, at least with patents 
there comes disclosure, so it's possible to work around them to some extent. 
The world survived the .GIF wars, of course. :)

Mostly, since FPGA vendors make their money off silicon sales, anything that 
increases the usability of FPGAs and gets even the smallest of projects off 
the ground is unlikely to be shot down. If you look at the semiconductor 
marketplace as a whole, PLDs are still a relatively small chunk, but with 
enormous growth potential. I don't much care if Altera grows its top line by 
200%, so long as Xilinx is doing the same (or better ;-)).

Some might say that open-source vendor-independent tools would accellerate 
the commoditization of the FPGA. I say, bring it on! (That's because I care 
more about cool technology than I do about gross margins though. Go figure.)

>> But would it make sense to try and do an open source FPGA floor-planning
> Actually, I think an open source FPGA floorplanning tool could be done.

Yes, thinking about it, the idea of a generic tool for laying out your 
circuit on some generic device is not too difficult to grasp. Someone would 
need to establish a standard way to represent the various 
columns/rows/grids/rings of resources on all the world's PLD parts, and work 
out a way of translating the constraints applied by the user into whatever 
the vendor's back-end tools understand.

> Making a good quality router is probably much more difficult.

The main problems with P&R are truly understanding the switch matrices 
(virtually undocumented in the latest devices as far as I know) and having a 
good timing model. Now, within the Xilinx tools (and presumably within brand 
A's as well), the timing details are exposed as a library of API calls, 
because they need to be shared between all the elements of the flow - 
synthesis, map, PAR, trace, FPGA editor etc. This infrastructure works for 
many different device families. There's no reason why a similar architecture 
couldn't be devised to cope with devices from multiple vendors.

> Some extra bonus thoughts from me: the open source community probably
> don't gain any good will by demanding an arm and a leg from Altera
> and Xilinx without showing that we can add significant value to their
> bottom line.

As I've alluded to, I think the main concern is that Brand {A|X} doesn't 
want to lose share to brand {X|A}. It's a game theory thing - the payoff for 
co-operation (via OSS) is potentially huge...

> For example, if we show that we can build a high quality synthesizer
> frontend that has about the same performance as XST, they might seriously
> consider contributing to that effort, perhaps even replacing their own
> tool with the open source tool. But right now the only open source
> synthesizing tool I'm aware of (Icarus) has a much too small user
> community to make that happen.

Also, it uses the wrong language. :-P

I think open source synthesis is a very appealing prospect. In the last 
couple of decades, people have really learned what works and what doesn't. 
It's certainly a challenge, but at least just about everything you need to 
know to write a synthesis tool (or the optimization engine of a synthesis 
tool, which is what really matters) is right there in the device datasheets. 
Plus, in starting from a clean sheet, the open-source community might well 
be able to leapfrog a lot of the legacy support issues.

I guess there are political issues about synthesis tools as well, given that 
commercial third-party synthesis vendors still exist. But the Xilinx focus 
is (nominally) on building an FPGA ecosystem, which means encouraging 
*anything* that will accelerate the adoption of FPGAs. Today's student 
projects and underfunded startups are tomorrow's tier-one customers, after 
all.

Cheers,

        -Ben- 



Article: 119016
Subject: Re: lwIP RAW mode support for V4 temac
From: Jeff Cunningham <jcc@sover.net>
Date: Wed, 09 May 2007 13:16:33 -0400
Links: << >>  << T >>  << A >>
Guru wrote:
> 
> Ave Paul! There is a lack of fast and free TCP/IP stacks which work
> with TEMAC. It would be nice to port your stack to GSRD design
> (www.xilinx.com/ gsrd) to get a maximum speed and royalty free
> reference design. I got this design working on Avnet Virtex-4FX12
> MiniModule, which is a low cost high performance OEM module. 
> Unfortunatelly there are no good reference designs which can exploit 
> this performance. If I were a better SW engineer I could help you on 
> development from which both would benefit.
> 
> Guru


Hi Guru,

I am the hardware engineer who is working with Paul. I'd love to hear
any comments you might have on our approach.

Our application specific IP that must also fit in the FPGA is a PLB
master DMA device that uses about 50% of the BRAM and 25% of the fabric
in the FX12. We originally were going to use the FX12 Minimodule, but
switched to the ML403 to get 2x the DDR bandwidth. We can get by with
400 Mb/s performance for now, but would like to get 800 Mb.

It seemed like all the GSRD examples almost filled a FX12, particularly
with BRAM usage, so we used the EDK supplied PLB TEMAC core and the PLB
DDR controller for now.

Since our app only needs high speed in the receive direction, it seemed
like it should be possible to remove half the GSRD logic (i.e. the
transmit part) and then everything would fit. As someone who has worked
with the GSRD, do you have a feel for how hard this would be? Or would
you guess the full GSRD (both directions) could fit with our IP somehow?
The critical resource seems to be BRAM and it always seemed like the
xilinx IP really used more BRAM that it should.

thanks,
Jeff

Article: 119017
Subject: Re: An Open-Source suggestion for Xilinx
From: Antti <Antti.Lukats@xilant.com>
Date: 9 May 2007 10:29:50 -0700
Links: << >>  << T >>  << A >>
Stephen Williams schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Where I work, we've pretty much given up on being able to use
> impact for anything other then writing ACE files, and it does
> a clunky job at that. I suspect that open-sourcing impact would
> make a *lot* of folks very very happy.
Hi Steve

I just recalled, I have reverse engineered the ACE file format
even written ACE compressor and player, so the work has begun
already :)

ah, yes I can open-source the ACE player.. please remind in a few days
should i forget..

Antti


Article: 119018
Subject: 'EVENT (or rising_edge) static prefix requirement....
From: Paul <pauljbennett@gmail.com>
Date: 9 May 2007 10:30:34 -0700
Links: << >>  << T >>  << A >>
Can't figure it out...  Why cant this compile:

S_chan0_clk  : process (reset_delayed, ch_clk_div_int)
  begin
    for k in 0 to 15 loop
    test_case   :=  ch_clk_div_int(k);
    if  reset_delayed = '1' then
      reset_chan_Q(k)   <=  '1';
      reset_chan_QQ(k)  <=  '1';
    elsif  ch_clk_div_int(k)  = '1' AND ch_clk_div_int(k)'EVENT then
      reset_chan_Q(k)   <=  '0';
      reset_chan_QQ(k)  <=  reset_chan_Q(k);
    end if;
  end process;

It should unroll the loop, and there is therefore nothing undefined
about the clk.... but yet ModelSim says that 'EVENT requires a static
prefix....   anyone know why?  how to get around it?   thanx


Article: 119019
Subject: Re: Where can I find the pass transistor's working curve under 1.2V?
From: Chris <c@c>
Date: Wed, 09 May 2007 19:32:09 +0200
Links: << >>  << T >>  << A >>
austin wrote:

> 1.  Learn spice
> 2.  Use spice.

3.  The spice must flow!


(sorry, couldn't resist ;-)

Article: 119020
Subject: Re: 'EVENT (or rising_edge) static prefix requirement....
From: Paul <pauljbennett@gmail.com>
Date: 9 May 2007 10:34:27 -0700
Links: << >>  << T >>  << A >>
Ignore the
test_case   :=  ch_clk_div_int(k);

that was from something else i was trying... forgot to delete it



On May 9, 1:30 pm, Paul <pauljbenn...@gmail.com> wrote:
> Can't figure it out...  Why cant this compile:
>
> S_chan0_clk  : process (reset_delayed, ch_clk_div_int)
>   begin
>     for k in 0 to 15 loop
>     test_case   :=  ch_clk_div_int(k);
>     if  reset_delayed = '1' then
>       reset_chan_Q(k)   <=  '1';
>       reset_chan_QQ(k)  <=  '1';
>     elsif  ch_clk_div_int(k)  = '1' AND ch_clk_div_int(k)'EVENT then
>       reset_chan_Q(k)   <=  '0';
>       reset_chan_QQ(k)  <=  reset_chan_Q(k);
>     end if;
>   end process;
>
> It should unroll the loop, and there is therefore nothing undefined
> about the clk.... but yet ModelSim says that 'EVENT requires a static
> prefix....   anyone know why?  how to get around it?   thanx



Article: 119021
Subject: Re: Open Source (was: Xilinx software quality - how low can it go ?!)
From: bengineerd <bengineerd@gmail.com>
Date: 9 May 2007 10:42:04 -0700
Links: << >>  << T >>  << A >>
> OSS versions would lag a vendor-proprietary system significantly because
> vendors just won't release early details of their new architectures to the
> general public.

Maybe this isn't such a bad thing.
FPGA vendors could use this lag to maintain an advantage for selling
thier own software tools.
The vendors could license their own tools for the new bleeding edge
parts, which OSS tools would be unable to support right away.
OSS tools would support all of the older, previous generation parts,
which would probably be good enough to help build the community.
Its the same strategy Xilinx is already using with Webpack, only now
you also get OSS tools the the community can rally around.

Consider how this might work in the context of the current generation
of products.
Virtex 4/5 support would only be available from Xilinx since its
relatively new, but a full OSS tool chain would by now be available
for older Virtex II devices.
A lot of people are still using Virtex II chips, so free tools would
be a significant boost for the community.
At the same time, no one who is currently buying Virtex 4/5 chips is
going to stop and wait a year or two for the OSS tools for those to
become available.
Those using these chips are doing so because their applications NEED
their power NOW, and it is worth paying a premium for that power.

FPGA vendors could then time the release of the specs for devices
knowing that in about a year or two, the OSS tools will be complete
for it, and by that time a new, better device will be available with
tools available only from them.  In the end, I think everyone wins.


Article: 119022
Subject: Re: ML405 LCD
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Wed, 09 May 2007 11:15:24 -0700
Links: << >>  << T >>  << A >>
For a standalone example (no VxWorks) in C you can have a look at the 
ML405 reference design:

http://www.xilinx.com/products/boards/ml405/reference_designs.htm
http://www.xilinx.com/products/boards/ml405/files/ml405_emb_ref_ppc_81.zip

In sw/standalone/simon.src you find a xromlcd.h and xromlcd.c that 
implements some functions to write to the LCD. These functions are 
called from simon.c

It should be straight forward to port that code to VxWorks.

- Peter


Aggie wrote:
> How can I display "hello world" onto the Char LCD which is on the
> development board (ML405)?
> 
> I realized a similar topic has been posted. But our situation is a
> little different.
> 
> I want to do it the "software" way, i.e. write a C program and
> download it to the board.
> 
> Here's what I'm using:
> Xilinx Platform Studio 8.2
> Wind River - OS vxwork 6.4
> 
> Thanks in advance. Any input help.
> 
> Kevin
> 

Article: 119023
Subject: Re: Where can I find the pass transistor's working curve under 1.2V?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: 9 May 2007 11:17:21 -0700
Links: << >>  << T >>  << A >>
On May 9, 10:32 am, Chris <c@c> wrote:
> austin wrote:
> > 1.  Learn spice
> > 2.  Use spice.
>
> 3.  The spice must flow!
>
> (sorry, couldn't resist ;-)

Hi Chris,
What does 'flow' mean?

Weng


Article: 119024
Subject: Re: Open Source (was: Xilinx software quality - how low can it go ?!)
From: fpga_toys@yahoo.com
Date: 9 May 2007 11:17:33 -0700
Links: << >>  << T >>  << A >>
On May 9, 10:27 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
> This is true, and it's certainly a concern. Still, at least with patents
> there comes disclosure, so it's possible to work around them to some extent.
> The world survived the .GIF wars, of course. :)

Which is why open source only works well with vendor partnerships to
provide an IP shield and patent pool. It's difficult, if not
impossible to make any open source synthesis tool successful when a
vendor directly targets it for failure. Simply releasing free web pack
ISE with XST makes buying into a less capable Verilog tool an unlikely
success. A Vendor funding the same tool and giving it away, pretty
much assures success. When reverse engineering vendor data formats is
in violation of license NDA's, it's pretty much assured the vendor and
litigate against the developers to block everything (at least in the
US, harder to stop in other countries).

> Mostly, since FPGA vendors make their money off silicon sales, anything that
> increases the usability of FPGAs and gets even the smallest of projects off
> the ground is unlikely to be shot down. If you look at the semiconductor
> marketplace as a whole, PLDs are still a relatively small chunk, but with
> enormous growth potential. I don't much care if Altera grows its top line by
> 200%, so long as Xilinx is doing the same (or better ;-)).
>
> Some might say that open-source vendor-independent tools would accellerate
> the commoditization of the FPGA. I say, bring it on! (That's because I care
> more about cool technology than I do about gross margins though. Go figure.)
> [ ... ]
> I guess there are political issues about synthesis tools as well, given that
> commercial third-party synthesis vendors still exist. But the Xilinx focus
> is (nominally) on building an FPGA ecosystem, which means encouraging
> *anything* that will accelerate the adoption of FPGAs. Today's student
> projects and underfunded startups are tomorrow's tier-one customers, after
> all.

It's always the political issues, both inside and outside the vendor's
staff. Especially the prevailing arguement about supporting the top 50
customers, OR supporting a pure commodity market with tens of
thousands of customers. Something of a chicken and egg problem, that
has a very direct out come on gaining/maintaining market share of a
commodity with open source tools.

The proprietary FPGA tools are unlikely to evolve to support such
commodity markets, as they are not necessary to support the exisiting
top 50 (500) customers that are (likely) already buying (expensive)
3rd party tools too.  Unless of course, a vendor breaks ranks and goes
after the commodity market share by making their tools widely
available and useful for the many commodity markets, by setting the
standard for those tools released in an open source environment.




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