Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
> > - 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) AnttiArticle: 118976
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 AiVisionArticle: 118977
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
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 AnttiArticle: 118979
"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
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
> Is it that you need quotes? That's it! Argh! Thanks, BradArticle: 118982
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
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. KevinArticle: 118984
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<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. /MikhailArticle: 118986
"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.comArticle: 118987
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
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
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
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 C380Article: 118991
<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 RybaArticle: 118992
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 ~ashwinArticle: 118993
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
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, EricArticle: 118995
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
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
"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"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
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:
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