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 118975

Article: 118975
Subject: Re: First MicroBlaze demo design for Spartan-3A Starterkit
From: Antti <Antti.Lukats@xilant.com>
Date: 8 May 2007 08:41:44 -0700
Links: << >>  << T >>  << A >>
> > - 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.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

I think for all X-Fest attendees there is 199USD discount offer for
Spartan-3A kit
that is valid for orders placed within 90 days
(and also several other special prices for other boards and-or
bundles)

Antti


Article: 118976
Subject: Xilinx VHDL Attribute syntax error
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 8 May 2007 09:02:16 -0700
Links: << >>  << T >>  << A >>
Hello,

I was switching UCF lines to VHDL attributes
when I came into this syntax error.
Can someone suggest what the problem is?

#UCF file works fine
INST cam2_x0_ibufd_inst DIFF_TERM = TRUE;
INST cam1_x0_obufds IOSTANDARD=LVDSEXT_25;

-- VHDL
attribute DIFF_TERM : boolean;
attribute DIFF_TERM of cam2_x0_ibufd_inst:label is true; -- works
attribute IOSTANDARD : string;
attribute IOSTANDARD of cam1_x0_obufds:label is LVDSEXT_25; -- syntax error

begin

The syntax error is -- Undefined symbol 'LVDSEXT_25'

Thanks,

Brad Smallridge
AiVision



Article: 118977
Subject: Re: Xilinx software quality - how low can it go ?!
From: Mike Lundy <novas0x2a@gmail.com>
Date: 8 May 2007 09:03:02 -0700
Links: << >>  << T >>  << A >>
I had a very long post in response, and Usenet or Google apparently
ate it, since it didn't post. Doh. Bob said most of what I was going
to, so I'll respond here.

On May 7, 8:03 pm, Bob <bob36...@yahoo.com> wrote:
> On May 7, 2:05 pm, <steve.l...@xilinx.com> wrote:
>
> > - We have a fair amount of 3rd party software that we ship with
> > ours and we have no rights to distribute that source.
>
> The same thing was said about Netscape, and now Mozilla/Firefox is
> a big Open Source success story. The 3rd party software is gone,
> along with the licensing fees.

OpenOffice.org is another great example of this system; the project is
maintained entirely in the open, by a community made up of both Sun
employees and outsiders. When it becomes time for a new release of
StarOffice (Sun's branded version of OpenOffice.org) Sun takes the
current snapshot, adds in the functionality they cannot release as
open-source, and releases it. If a company wants a support contract,
they need to use StarOffice, but OpenOffice is acceptable to everyone
else.

> > - Most of our time is spent doing new device support (and this
> >   in not just within the map and par groups). How do we get
> >   these "volunteers" to deliver new devices when we need them?
> > - We start the software for new devices about 2 years before the
> >   software for that family is released. Making the details of a
> >   new architecture public at that time is not an option.

I really couldn't have stated my case better than this. If most of
your man hours are spent doing new device support, who is fixing bugs?
Who is testing? No offense intended, but it seems like the answer is
"not enough people." (How does a bug like CR 437985 slip through?) If
you had outside help fixing bugs, more of your internal time could be
devoted to adding device support. In the case of the cable drivers,
you should read this[note 1] link. If you contact Greg KH
(gregkh@suse.de), a member of the Linux Kernel team, I believe you
would be pleasantly surprised.

> >  - Going open source is like handing our source code over to our
> > competitors.

This is true. However- what would they do with it? (Note that we are
talking about pieces that are not trade secrets here, since I am not
arguing that you should compromise your hardware IP.) If you open-
sourced the ISE and EDK (and the eclipse packages for the SDK), Altera
could then take them, improve them, and release them, this is true.
However, this would help you both. If you release under the GPL[note
2], Altera would be held by the same rules- any improvements they made
and released would have to be open-source as well. If there was one
free GUI tool that supported both Altera and Xilinx, I can't see this
as being anything but a win for Xilinx. As I see it, Xilinx has the
edge in hardware design, and Altera has the edge in software design.
If you improve your software by opening it up while maintaining the
edge in hardware, /and/ make it easier to switch from Altera to Xilinx
by removing the need to learn new software, that is a clear win!

> >  - The only other open source program for FPGAs failed:
> >http://www.pldesignline.com/news/164900514
>
> This failed for some obvious reasons. A company can't just
> "stone soup" an Open Source project without putting something
> into the pot. It also wasn't really open. If it was, then
> ST wouldn't be able to just cancel it unilaterally.

In addition, open-source hardware projects don't tend to do
particularly well (though I'm hoping the video card/ GPU project will
succeed) but that's definitely not what we're talking about here.

> > Regarless of the negative comments we receive on this newsgroup,
> > most customer comments on ISE 9.1i have been extremely positive.
>
> My experience with ISE 9.1i has been almost entirely positive. It
> is a solid improvement over 8.2. But don't get too defensive about
> the negative comments. Positive comments are worth little. It is
> the negative feedback that helps us improve and progress. If no
> one ever complained, we would still be living in caves.

I'm going to be a little harsher than Bob here. What you're seeing is
a clear example of selection bias.

Many customers are already your customers, and you have been making
slow but steady improvements in the software. ISE 9 is certainly a
vast improvement over the dark ages of ISE 6 and 7. Kudos are due for
that, certainly. If you ask regular customers what they think of
recent versions of your software, of course they will be positive.  Do
you have statistics on the number of people who considered FPGAs for a
project and decided not to? Do you have numbers on small webpack-only
projects that jumped ship due to the software quality?  How about
internal R&D projects that have failed due to Xilinx bugs?  I have
experience with that last one myself- we're probably going to be going
with an outside micro coupled with a small FPGA rather than using an
FX-series chip w/ PPC due to the sheer number of problems I've had
with it. And I know what I'm doing!

Your customers are primarily hardware companies, so any improvement is
gravy to them. They judge your software against others in the EE
domain, and find it usable. However, I'm not comparing your software
to software in the domain, I'm comparing it to software in other
industries. Why do I do that? The FPGA market doesn't /have/ to be
this way- there doesn't have to be a hazing ritual for every new user.
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 :)

Most people are probably going to laugh at the preceding paragraph.
But I'm completely serious. Why do I feel so strongly about this? A
lot of people in the FPGA industry seem to think the status quo is
just fine. But not me. I want FPGAs to become ubiquitous. I want my PC
to have an FPGA /instead/ of a processor. And I don't see that
happening unless it becomes easier for software people to become FPGA
people. Right now, most software people I know flee back to a
microprocessor when they see the state of the FPGA industry. And that
makes me sad.

1) http://lkml.org/lkml/2007/1/29/345
2) There are many frightening things said about the GPL, most of which
are not true. If you've heard some of those things, let me know and I
will attempt to address them in a future mail.


Article: 118978
Subject: Re: Xilinx software quality - how low can it go ?!
From: Antti <Antti.Lukats@xilant.com>
Date: 8 May 2007 09:20:53 -0700
Links: << >>  << T >>  << A >>
On 8 Mai, 18:03, Mike Lundy <novas0...@gmail.com> wrote:
> I had a very long post in response, and Usenet or Google apparently
> ate it, since it didn't post. Doh. Bob said most of what I was going
> to, so I'll respond here.
[]
> In addition, open-source hardware projects don't tend to do
> particularly well (though I'm hoping the video card/ GPU project will
> succeed) but that's definitely not what we're talking about here.

Mike
are you referring this board?

http://wiki.duskglow.com/tiki-index.php?page=OGPN17

Antti


Article: 118979
Subject: Re: Xilinx VHDL Attribute syntax error
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 8 May 2007 17:25:52 +0100
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:13417q5sjcofc44@corp.supernews.com...
> attribute IOSTANDARD : string;
> attribute IOSTANDARD of cam1_x0_obufds:label is LVDSEXT_25; -- syntax 
> error
>

attribute IOSTANDARD of cam1_x0_obufds:label is "LVDSEXT_25";

Is it that you need quotes?

Dunno, try it!
HTH, Syms. 



Article: 118980
Subject: Re: Xilinx software quality - how low can it go ?!
From: Mike Lundy <novas0x2a@gmail.com>
Date: 8 May 2007 09:29:28 -0700
Links: << >>  << T >>  << A >>
On May 8, 9:20 am, Antti <Antti.Luk...@xilant.com> wrote:
> On 8 Mai, 18:03, Mike Lundy <novas0...@gmail.com> wrote:
>
> > I had a very long post in response, and Usenet or Google apparently
> > ate it, since it didn't post. Doh. Bob said most of what I was going
> > to, so I'll respond here.
> []

Yeah. If you thought the one that actually /posted/ was long, you
should have seen the original!

> > In addition, open-source hardware projects don't tend to do
> > particularly well (though I'm hoping the video card/ GPU project will
> > succeed) but that's definitely not what we're talking about here.
>
> Mike
> are you referring this board?
>
> http://wiki.duskglow.com/tiki-index.php?page=OGPN17

I think I am, yeah. Wow. It's been a while since I looked at it- I
didn't realize they were as far as they are!


Article: 118981
Subject: Re: Xilinx VHDL Attribute syntax error
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 8 May 2007 09:36:43 -0700
Links: << >>  << T >>  << A >>
> Is it that you need quotes?

That's it! Argh!

Thanks,

Brad



Article: 118982
Subject: Re: V5 LVPECL Inputs
From: Test01 <cpandya@yahoo.com>
Date: Tue, 8 May 2007 11:25:45 -0700
Links: << >>  << T >>  << A >>
We are designing separate transmitter and receiver hardware. We would like to utlize the GTP transceivers for transmitter portion to minimize the complexity. For receiver we do not have a choice but to use the descrete devices in order to run at 3.2 GHz. Our protcol is such that it can not be supported by the GTP transceivers.

Thus for transmitter we would like to use the GTPs and for the receiver we would like to use Select I/Os. It will be separate FPGAs.

Article: 118983
Subject: ML405 LCD
From: Aggie <c.kevin.lam@gmail.com>
Date: 8 May 2007 11:33:56 -0700
Links: << >>  << T >>  << A >>
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: 118984
Subject: SelectMap or serial: How does the PROM know?
From: eli.billauer@gmail.com
Date: 8 May 2007 11:57:44 -0700
Links: << >>  << T >>  << A >>
Hello,

I am in the midst of reviewing a board design, which is based upon a
(Xilinx) Virtex-4 XC4VSX35 which will configure itself as a master
from a (Xilinx) XCF32P flash.

The related schematics was heavily inspired by a reference design,
which allows loading the configuration either in serial mode or
SelectMap. A jumper changes the mode bits accordingly, so the FPGA
knows what we want. In order to make this work, the ROM's D0 output
goes both to FPGA's D_IN_0 and the D0 pin. D1-D7 go, of course, to the
respective places on the FPGA. This way, both data channels are
possible.

In our design, the mode bits are hardwired to SelectMap, so I have to
make sure that things will work in this mode. And what puzzles me, is
how the PROM knows whether it should send out a single bit for each
CCLK as necessary in serial mode, as opposed to a full 8-bit word per
CCLK as needed in SelectMap. The mode pins don't reach the PROM
directly, and it has no way to know whether we're listening to one bit
or eight. Still, it has to increment its bit address by one or eight,
depending on the configuration mode.

It's not that I care all that much about the internals, as I want to
make sure that we don't miss a critical wire or pullup/down resistor.
Or something.

Does the FPGA send a hint regarding the mode in some way at powerup?
Is it somehow given in the PROM data? I've read the configuration
guides back and forth, and found no clue about this simple question.

Anyone?

Thanks,
    Eli


Article: 118985
Subject: Re: SelectMap or serial: How does the PROM know?
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 8 May 2007 16:08:30 -0400
Links: << >>  << T >>  << A >>
<eli.billauer@gmail.com> wrote in message 
news:1178650664.159573.225080@p77g2000hsh.googlegroups.com...
>
> In our design, the mode bits are hardwired to SelectMap, so I have to
> make sure that things will work in this mode. And what puzzles me, is
> how the PROM knows whether it should send out a single bit for each
> CCLK as necessary in serial mode, as opposed to a full 8-bit word per
> CCLK as needed in SelectMap.
<skip>
> Is it somehow given in the PROM data? I've read the configuration
> guides back and forth, and found no clue about this simple question.

When you program the PROM with Impact you are given a choice of the Parallel 
Mode under the PROM Specific Properties. So, essentially, I believe the 
information is stored in the PROM itself.

/Mikhail



Article: 118986
Subject: Re: lwIP RAW mode support for V4 temac
From: "Paul Tobias" <PaulTobias@MyWebSite.com>
Date: Tue, 8 May 2007 16:29:39 -0400
Links: << >>  << T >>  << A >>

"Patrick Dubois" wrote:

> Does anyone know of an example using lwIP in RAW mode with the
> Virtex-4 temac? From what I understand, the lwIP temac port seemingly
> only supports lwIP in sockets mode with xilkernel.

If you browse to my website at www.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 


Article: 118987
Subject: Re: SelectMap or serial: How does the PROM know?
From: "davide" <davide@xilinx.com>
Date: Tue, 8 May 2007 13:47:19 -0700
Links: << >>  << T >>  << A >>
Eli,

There are a couple of points to touch on here.  On power-up (or when INIT 
transitions), the MODE pins are sampled.  If the MODE pins are set such that 
you are in a serial mode, only the D0 pin is used as the configuration 
input.  Pins D1-D7 are treated as a dual purpose pins and in this case are 
standard IO, tri-stated during configuration.  Likewise if the MODE pins are 
set to a SelectMAP configuration (assuming 8-bit), D0-D7 are all active 
configuration pins.

There is no secret communication from the FPGA to the PROM that lets the 
PROM know what configuration mode the FPGA is set to.  This information is 
embedded in the MCS file.  It is possible to have multiple bitstream 
revisions in the Platform Flash and each of these revisions could be either 
a serial or SelectMAP configuration.  By doing this you will also need to 
change the MODE pins on the FPGA dynamically to support the type of 
configuration being driven from the PROM.

-David

<eli.billauer@gmail.com> wrote in message 
news:1178650664.159573.225080@p77g2000hsh.googlegroups.com...
> Hello,
>
> I am in the midst of reviewing a board design, which is based upon a
> (Xilinx) Virtex-4 XC4VSX35 which will configure itself as a master
> from a (Xilinx) XCF32P flash.
>
> The related schematics was heavily inspired by a reference design,
> which allows loading the configuration either in serial mode or
> SelectMap. A jumper changes the mode bits accordingly, so the FPGA
> knows what we want. In order to make this work, the ROM's D0 output
> goes both to FPGA's D_IN_0 and the D0 pin. D1-D7 go, of course, to the
> respective places on the FPGA. This way, both data channels are
> possible.
>
> In our design, the mode bits are hardwired to SelectMap, so I have to
> make sure that things will work in this mode. And what puzzles me, is
> how the PROM knows whether it should send out a single bit for each
> CCLK as necessary in serial mode, as opposed to a full 8-bit word per
> CCLK as needed in SelectMap. The mode pins don't reach the PROM
> directly, and it has no way to know whether we're listening to one bit
> or eight. Still, it has to increment its bit address by one or eight,
> depending on the configuration mode.
>
> It's not that I care all that much about the internals, as I want to
> make sure that we don't miss a critical wire or pullup/down resistor.
> Or something.
>
> Does the FPGA send a hint regarding the mode in some way at powerup?
> Is it somehow given in the PROM data? I've read the configuration
> guides back and forth, and found no clue about this simple question.
>
> Anyone?
>
> Thanks,
>    Eli
> 



Article: 118988
Subject: Re: An Open-Source suggestion for Xilinx
From: <steve.lass@xilinx.com>
Date: Tue, 8 May 2007 15:12:39 -0600
Links: << >>  << T >>  << A >>
I have forwarded your comments to our configuration solutiuons
group. They are working on ideas to solve the issues you listed
below.

I'm going on vacation for a week, so won't be able to respond to
all of the interesting suggestions regarding open source. Here's
my take.

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.

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.

Steve

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1178620460.648853.311240@o5g2000hsb.googlegroups.com...
> An Open-Source suggestion for Xilinx
>
> In generic the decision about to use Open-Source strategies
> is very complex, but there is an easy and low risc way to
> at least make the first step, the portion that could be
> tried as Open-Source is related to programming cable support
> as first step the firmware for USB Platform Cable or at least
> the protocol information could be released to the public -
> the development that follows (or doesnt) could be used as
> indicator if there is change for success for larger parts
> of the tools to go Open-Source.
>
> The current programming support is bad, this both on the
> PC side software (impact), the host drivers and and the
> embedded firmaware in platform cable(s).
>
> There is already some effort done, I list it here
>
> 1) Impact TCP protocol has been reverse engineered
> and there is open-source cable-server
> 2) I have tried to make software support for Cable IV high
> speed mode, even made special FPGA-PCI design that emulates
> LPT port + Cable IV. There is no final result on that yet.
> 3) I have written Coolrunner disassembler in order to reverse
> engineer the Cable IV code
> 4) There is 3rd party replacement firmware for USB platform cable
> 5) possible more projects that we dont know about.
>
> ALL THOSE efforts have been done to improve the Support
> for the programming hardware manufactured by Xilinx Inc.
>
>
> Xilinx Cable IV - it very seldomly works in high speed mode
> Xilinx has not been able fix the driver issues, and I guess never will
>
> Xilinx USB Cable (and embedded USB Cable) is "kinda working" but
> it is only useable as download cable and XMD debug, but it can not
> be used as user communucation channel to user IP cores in Xilinx FPGA.
>
> Those issues (bad support for Xilinx programming hardare) could be
> done
> by "Open-Source" initiative WITHOUT Xilinx support, as the reverse
> engineering needed is not complicated at all. The thing is that there
> is not enough interest, so everybody keeps using the existing
> solutions
> the way they work, not releasing the full potential.
>
>
> There is lots of open-source software that supports Cable III, and
> NONE
> that would support Cable IV, or Platfrom USB Cable.
>
>
> just me 2 eurocents.
>
> Antti Lukats
> 



Article: 118989
Subject: Re: SelectMap or serial: How does the PROM know?
From: "davide" <davide@xilinx.com>
Date: Tue, 8 May 2007 14:51:21 -0700
Links: << >>  << T >>  << A >>
Correction:

What Mikhail said is correct.  The MCS does not have the information.  When 
loading the MCS file to the PROM, iMPACT has a setting to select a parallel 
mode.  Here is the question:  Can each revision selection also have it's own 
configuration width?  I believe that the answer is yes and am doing a quick 
experiment to verify.  Results to follow...

-David

"davide" <davide@xilinx.com> wrote in message 
news:f1qnko$omf1@cnn.xsj.xilinx.com...
> Eli,
>
> There are a couple of points to touch on here.  On power-up (or when INIT 
> transitions), the MODE pins are sampled.  If the MODE pins are set such 
> that you are in a serial mode, only the D0 pin is used as the 
> configuration input.  Pins D1-D7 are treated as a dual purpose pins and in 
> this case are standard IO, tri-stated during configuration.  Likewise if 
> the MODE pins are set to a SelectMAP configuration (assuming 8-bit), D0-D7 
> are all active configuration pins.
>
> There is no secret communication from the FPGA to the PROM that lets the 
> PROM know what configuration mode the FPGA is set to.  This information is 
> embedded in the MCS file.  It is possible to have multiple bitstream 
> revisions in the Platform Flash and each of these revisions could be 
> either a serial or SelectMAP configuration.  By doing this you will also 
> need to change the MODE pins on the FPGA dynamically to support the type 
> of configuration being driven from the PROM.
>
> -David
>
> <eli.billauer@gmail.com> wrote in message 
> news:1178650664.159573.225080@p77g2000hsh.googlegroups.com...
>> Hello,
>>
>> I am in the midst of reviewing a board design, which is based upon a
>> (Xilinx) Virtex-4 XC4VSX35 which will configure itself as a master
>> from a (Xilinx) XCF32P flash.
>>
>> The related schematics was heavily inspired by a reference design,
>> which allows loading the configuration either in serial mode or
>> SelectMap. A jumper changes the mode bits accordingly, so the FPGA
>> knows what we want. In order to make this work, the ROM's D0 output
>> goes both to FPGA's D_IN_0 and the D0 pin. D1-D7 go, of course, to the
>> respective places on the FPGA. This way, both data channels are
>> possible.
>>
>> In our design, the mode bits are hardwired to SelectMap, so I have to
>> make sure that things will work in this mode. And what puzzles me, is
>> how the PROM knows whether it should send out a single bit for each
>> CCLK as necessary in serial mode, as opposed to a full 8-bit word per
>> CCLK as needed in SelectMap. The mode pins don't reach the PROM
>> directly, and it has no way to know whether we're listening to one bit
>> or eight. Still, it has to increment its bit address by one or eight,
>> depending on the configuration mode.
>>
>> It's not that I care all that much about the internals, as I want to
>> make sure that we don't miss a critical wire or pullup/down resistor.
>> Or something.
>>
>> Does the FPGA send a hint regarding the mode in some way at powerup?
>> Is it somehow given in the PROM data? I've read the configuration
>> guides back and forth, and found no clue about this simple question.
>>
>> Anyone?
>>
>> Thanks,
>>    Eli
>>
>
> 



Article: 118990
Subject: Re: FPGA software quality - how low can it go ?!
From: Adam Megacz <megacz@cs.berkeley.edu>
Date: Tue, 08 May 2007 18:52:31 -0700
Links: << >>  << T >>  << A >>

Mike Lundy <novas0x2a@gmail.com> writes:
> 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.

Funny, I've been having the exact same dream lately.

> Most people are probably going to laugh at the preceding paragraph.

If they do, it's a very good sign.

  http://www.youtube.com/watch?v=coKqOGV4Pbo

(watch from 2:20 on if you're in a hurry).

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Article: 118991
Subject: Re: An Open-Source suggestion for Xilinx
From: "Marty Ryba" <martin.ryba.nospam@verizon.net>
Date: Wed, 09 May 2007 02:48:16 GMT
Links: << >>  << T >>  << A >>

<steve.lass@xilinx.com> wrote in message 
news:f1qp4e$omc2@cnn.xsj.xilinx.com...
> 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.
That's usually not the point...it's that the overall quality of the result 
can go up.

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

I think an excellent example of how open source is managed for "bigger 
applications" with some "device specific" issues is the Analog Devices 
Blackfin uCLinux project. ADI is basically getting away from their 
proprietary VisualDSP development environment and is getting excellent 
uptake of this quite impressive capability from such a small cheap 
processor. The DSP library is ported over, so I can get excellent FIR and 
FFT performance from this 500-600 MHz chip in a modern OS and language (C++) 
development environment. It's been a pleasure to develop in it. ADI appears 
to have a team of roughly 20 engineers supporting/managing the effort, 
dozens of active contributors, and thousands of users. Now, there isn't a 
big set of GUIs to manage, but a lot of application libraries exist.

Check out http://blackfin.uclinux.org

Marty Ryba 



Article: 118992
Subject: ISE : Linux - coregen, compxlib errors
From: ashwin <ashwinks@gmail.com>
Date: Tue, 8 May 2007 20:14:11 -0700
Links: << >>  << T >>  << A >>
Hi

I have installed ISE 8.2i on a AMD64 Linux machine running Ubuntu 7.04. ISE works fine, and Ican generate cores, HDL simulation libraries, etc from within ISE. But, my problem is the tools do not work standalone, on the command line.

E.g. running compxlib gives an error stating "error while loading shared libraries: libPersonalityModule.so: cannot open shared object file: No such file or directory" And, coregen gives the error "error while loading shared libraries: libPortability.so: cannot open shared object file: No such file or directory"

How do I solve this? thanks ~ashwin

Article: 118993
Subject: About memory interface generater 007 tool
From: Gordon Freeman <gordonfreeman1983@gmail.com>
Date: 8 May 2007 21:23:09 -0700
Links: << >>  << T >>  << A >>
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: 118994
Subject: Re: An Open-Source suggestion for Xilinx
From: Eric Smith <eric@brouhaha.com>
Date: 08 May 2007 23:22:03 -0700
Links: << >>  << T >>  << A >>
Steve Lass wrote:
> I have forwarded your comments to our configuration solutiuons
> group. They are working on ideas to solve the issues you listed
> below.

I think what is fundamentally needed is a well-defined protocol
that the tools use to talk to the programming/configuration hardware.
This could be either an API, or an "on-the-wire" network protocol.
Ideally the same protocol or API would be supported by both Impact
and ChipScope, though having two separate protocols (as is apparently
true today) would be OK.

If such protocols/APIs existed and were documented, there would be even
more free software solutions for configuring/programming/debugging
Xilinx-based target systems.

At that point it would be less important for Xilinx to release
the source code of their own implementation of the cable side of
those protocols, but if they did, it would be useful as a
reference implementation.

From the outside, it is hard to see how this could have any
significant drawbacks for Xilinx.  Certainly not enough to
outweigh the benefits.

One justification that companies sometimes give for NOT documenting
their APIs and protocols is that they are subject to change.  However,
this is readily handled by versioning.  If Xilinx publishes version 1
of an API or protocol, and discovers that a change or addition is
necessary to support a new feature in the future, version 2 of the
API or protocol can be released.  Open Source and Free Software is
generally very quick to adapt to such changes.

Best regards,
Eric

Article: 118995
Subject: Re: ISE : Linux - coregen, compxlib errors
From: Eric Smith <eric@brouhaha.com>
Date: 08 May 2007 23:40:38 -0700
Links: << >>  << T >>  << A >>
ashwin <ashwinks@gmail.com> writes:
> But, my problem is the tools do not work standalone, on the command line.
> "error while loading shared libraries: libPersonalityModule.so: cannot
> open shared object file: No such file or directory"

That's typically a sign that your environment variables aren't set up.
Did you source the config script before trying to run the program?

I use a wrapper shell script to do that.  Edit for your tool
locations.  I put it in ~/bin/xil91, and invoke it like:

    xil91 ise           # for ISE project navigator
    xil91 impact
    xil91 fpga_editor
    xil91 xps           # for EDK Platform Studio
    xil91 analyzer.sh   # for ChipScope analyzer

    etc.



#!/bin/bash
rel=91
sixtyfour=64    # leave empty for 32-bit
export CHIPSCOPE=/usr/local/xilinx/chipscope${rel}

# Following is to use the third-party driver instead of the Jungo
# windrvr:  http://www.rmdir.de/~michael/xilinx/
export LD_PRELOAD=$HOME/src/usb-driver/libusbdriver.so

. /usr/local/xilinx/ise${rel}/settings.sh
. /usr/local/xilinx/edk${rel}/settings.sh
export PATH=$CHIPSCOPE/bin/lin${sixtyfour}:$PATH
prog=$1
shift
$prog $*


Article: 118996
Subject: Re: SelectMap or serial: How does the PROM know?
From: eli.billauer@gmail.com
Date: 9 May 2007 01:37:40 -0700
Links: << >>  << T >>  << A >>
Thank you for the answers. Indeed, I found the following sentence in
the help page for configuration options:

"Parallel Mode

Sets the parallel mode bit in the XC18V00 device. The PROM uses the DO-
D7 pins for SelectMap programming of the target FPGA."

That's good enough for going ahead with the board. But I still wonder
if this is written somewhere in the official docs. After all, this is
a major issue, and still I couldn't find a word about this in the data
sheet (ds123.pdf) nor the user guide (ug161.pdf). Is the info out
there in a place I don't look?

Thanks again,
    Eli




Article: 118997
Subject: Re: Xilinx software quality - how low can it go ?!
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Wed, 9 May 2007 10:16:21 +0100
Links: << >>  << T >>  << A >>

"Mike Lundy" <novas0x2a@gmail.com> wrote in message 
news:1178640182.911706.234880@e65g2000hsc.googlegroups.com...

> If most of your man hours are spent doing new device support, who
> is fixing bugs?

Steve said that the majority of >200 developers' time is spent on coding up 
support for new devices and silicon features. He was not suggesting that 
they are too busy to fix bugs.

> Who is testing? No offense intended, but it seems
> like the answer is "not enough people."

There are never enough people testing software! :)

The developers test their modules as they develop new code. They test when 
they integrate their modules. The software verification group test the 
software at many levels. The IP developers do a lot of alpha testing since 
we usually need bleeding edge tools for the latest families. The FAEs test 
the software. And so on.

Could we do better? Yes, I think so. Do we just ship it as soon as it 
compiles (as seems to be commonly implied around here)? No, we really don't.

I'm a big fan of open source software and I'd love to see more OSS projects 
surrounding FPGA technology. But I'm not quite sure about the feasibility of 
what's being suggested in this thread.

First of all, what exactly is the scope of this "open source ISE" supposed 
to be? If it's just a vendor-agnostic IDE for designing FPGAs, then it 
sounds like a trivial wrapper around the proprietary synthesis and back-end 
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.

Now taking it up a level, an open-source implementation of something like 
EDK (~SOPC builder) would be interesting. The idea of FPGA design as the 
convenient stitching together of prefab building blocks, either from a 
standard library or custom-made for the current project, has a lot of 
mileage in it. And it's an ideal way to factor out vendor dependencies.

An open-source equivalent of the Core Generator (~MegaWizard) could work; 
all these things help to hide the low-level implementation details and focus 
on the system level. A free and open-source solution for managing libraries 
of parameterizable IP would really help people to create portable designs 
while still making efficient use of the target architecture. (I'm not 
talking about people instantiating shift registers and counters here, but 
higher-level processing blocks.)

But would it make sense to try and do an open source FPGA floor-planning 
tool? I don't think so. The level of dependence on the device internals is 
prohibitive. For the same reason, mapping, packing, placement and routing 
algorithms look destined to remain proprietary, at least for the time being. 
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. They need to retain a competitive advantage or they will go 
out of business. I cannot see that changing; at least not until there is one 
single company's architecture dominating the FPGA landscape (a la Intel in 
the late 1990s).

There are obvious parallels here with the software world and general-purpose 
processors, but there are differences too. The EDA back-end is significantly 
more complex than (say) the GCC back-end, because the FPGA feature set - as 
exposed to the "programmer" - is considerably more complicated too. It's 
tempting to argue that because GCC was possible, that an open-source 
vendor-independent HDL-to-gates compiler is possible too. But this is proof 
by analogy.

My conclusion is that the only parts of the FPGA toolchain that vendors will 
likely be willing to open-source are the bits that the open-source community 
would not be interested in anyway. A notable exception is the JTAG 
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.

Cheers,

        -Ben- 



Article: 118998
Subject: Re: FPGA software quality - how low can it go ?!
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 9 May 2007 11:11:48 +0100
Links: << >>  << T >>  << A >>
"Adam Megacz" <megacz@cs.berkeley.edu> wrote in message 
news:x36472pxuo.fsf_-_@nowhere.com...
>
> If they do, it's a very good sign.
>
>  http://www.youtube.com/watch?v=coKqOGV4Pbo
>
This advert irritated me. It's message seems to be that because _some_ 
people made _some_ bad predictions, it must be that _all_ predictions are 
wrong, therefore Linux will be a success because _some_ people say it will 
fail. That logic is bollocks. ;-)
There are plenty of reasons why, IMHO, open source is a 'good thing', but 
that ad didn't present them.
Cheers, Syms. 



Article: 118999
Subject: Re: lwIP RAW mode support for V4 temac
From: Guru <ales.gorkic@email.si>
Date: 9 May 2007 03:21:34 -0700
Links: << >>  << T >>  << A >>
On May 8, 10:29 pm, "Paul  Tobias" <PaulTob...@MyWebSite.com> wrote:
> "Patrick Dubois" wrote:
> > Does anyone know of an example using lwIP in RAW mode with the
> > Virtex-4 temac? From what I understand, the lwIP temac port seemingly
> > only supports lwIP in sockets mode with xilkernel.
>
> 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

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





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