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
"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag news:3DA5B364.F95F9D0C@andraka.com... > Falk, > > I'd be happy to stick with the 'old' tools, unfortunately we get pulled along > by both the customer and Xilinx. I still use 3.3sp8 for virtex and virtexE > designs because it works. In order to do so,however, I had to upgrade to the > timing files for virtexE that were released after 4.1 was. Xilinx doesn't see > fit to make the timing for 3.3sp8 available on the website, so you need to beg > your FAE for them (this, as far as I am concerned is a sin, especially since > those timing files are less optimistic than previous ones which means designs > done with the old files may not meet timing in real life...Xilinx, you > listening? The latest speed files should be made readily available for 3.3 at > a minimum because of the functional problems with later software releases). > > We've hit some bugs in 4.2 that are show stoppers, and which are apparently > going to force us into 5.1 for the virtexII (3.3 doesn't support several > virtexII features, so you are forced to use 4.x or later). Of course 5.1 > introduces new bugs, so we are in limp mode until we get a suitable combination > of tools working. Hmm, what shall I say? You are working on the very first frontline, always pushing hard- and software to the limits. This is a worst case stess test for every component. Maybe you should get paid from Xilinx for this??? (Insider note from a Xilinx VIP, ". . . he knows our devices better than us . . .") And we all know, that this will make ugly bugs to appear. So what to do? I dont know. It is a sad thing that performance of software tools looks to get worse with a new version. :-(( Even to a medium power user like me it happend to get very angy about the new ISE, that has serval HARD bugs up to service pack 2 !!!!! And they look like those kind of bugs that happen in a "huh, just fix this, convert his, ok a simple test is ok, we have a new version" software maintainance practice.!!! Yes I know, pressure is high in this business. Xilinx, do you have a quality assurance problem with your software? There where and are serval bugs in new software that where fixed in older versions. Maybe Xilinx focuses too much on bringing out new software releases instead of fixing the existing version.?? As other noted already, the FPGA Vendos should better NOT try to make everthing a pushbotton designflow, to allow even a farmer to do FPGA stuff. Some pushbotton OPTIONS are nice to get into the business, but when you become familiar with the technology, you should be allowed to look AND act more closer to the hardware, especially when the current tools are know to be limited in performance!! So Iam a lucky (??) guy who works only on medium and low power stuff and can get away with the bug. -- MfG FalkArticle: 48076
Russell wrote: > > > Of course when I say they "can't afford" to self fund the tools, that is > > a relative term. The point is that the tools cost a lot of money to > > maintain and update. The economics are not there to allow open source > > tools to compete. > > All the fpga vendors need to do is make a publicly available API for > the devices, and keep doing whatever tools they have now. Private and > public projects will start up for various reasons such as profit, > academic purposes, or just to improve on what's available. Eventually > the GPL tools will be better than those done by nine-to-fivers that > couldn't give a stuff about fixing bugs. The fpga vendors can then > either support the GPL tools and keep frozen releases for safety, > or just keep doing their own tools but get useful ideas from the > GPL tools. There'd be less problems for everyone if there was a > choice of tools, and savings for the fpga vendors. I don't think you read anything I wrote. First, every copy of open source tools that is used in place of a vendor supplied tool takes away revenue for vendor tool development. Second, no vendor is going to consider any plan that takes the "family jewels" and trusts them to an outside, free ranging band of developers. The tools are a competitive edge for the FPGA vendors. They can not introduce new parts without in house tool support. So they can't afford to lose the revenue that pays for tool development. You only seeing the local picture of "we can do a better job than the FPGA vendors". I am not at all convinced that this is true. FPGA tools are a moving target and very different from software development tools. Every new generation of FPGAs require very different software. No FPGA vendor can sell parts in an environment where the tools are not up to speed with the parts. We can complain about the state of the tools (and I am often in the front row for that!) but this is most likely the best way to "get the job done". Before anyone starts asking the FPGA vendors to hand over the inside info on their parts, how about we get some *good* open source *front end tools*??? That is the easy part and I don't see anything out there that is anywhere near as good or even usable as the commercial tools. Trust me, if there were decent open source tools for FPGA work, there would be a lot of people working with them. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48077
"Mike Treseler" <mike.treseler@flukenetworks.com> schrieb im Newsbeitrag news:3DA5C148.4010502@flukenetworks.com... > Falk Brunner wrote: > > > >>Xilinx tools are not interesting, they don't need to be. Many designers > >>never even run up the gui. The simulator is where the action is. > > > From which planet are you from? > > > I think I live nearby. > Time is more limited than gates. > 90% sim, 5% synth, 5% p+r Hmm, you may be right. BUT why still runnig stone age design flow? No, Iam not a n Icon&GUI fetishist.But AFAIK you in the US are almost all driving cars with automatic transmission, are you? We poor (stone-age) europeans (at least in germany) drive still manual transmission (>95%). ;-) -- MfG FalkArticle: 48078
"MikeJ" <pacman@fpgaarcade.com> schrieb im Newsbeitrag news:1034270260.43696.0@demeter.uk.clara.net... > I can't help you with the rom images, although many software emulator sites > have them. > I am also working on some tools that will convert a binary file to xilinx > block rams which will help. At least, can you tell me what system it is?. I found many places for celebrating old Z80 game systems, but there are many. Which one is it? A binary file is fine, conversion will not be a problem. -- MfG FalkArticle: 48079
Chris Harthan wrote: > > Jens, > > In my previous posting I said that I used the BIT file. Looking at the > project I can see that I used the HEX file output,and I had the "swap > bits" option checked when I created it. > > The only problems we had were at the end of the programming process. > There is a delay between writing the last data bit and the Spartan > asserting the DONE line. We ended up putting in a 5 second timeout loop > that polls the DONE bit. After the DONE bit is asserted, the Spartan > needs three extra CCLK cycles to put it into operate mode. This wasn't > explained well in the documentation. > > Regards, > Chris Partly it is not documented well since the exact number of clocks needed to complete configuration is programmable and the DONE signal does not necessarily indicate that the configuration is totally complete. There is a section of the data sheets and app notes that explains the startup (final) portion of configuration. It requires clocks which can come from either the configuration clock or a user clock defined in the bit stream. The various startup actions timing is programmable within the bit stream as well. It can end up being rather complex if you use anything other than the default. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48080
Falk Brunner wrote: > > "Russell" <rjshaw@iprimus.com.au> schrieb im Newsbeitrag > news:3DA501C5.DE008F33@iprimus.com.au... > > I gave up on doing any fpga design after wasting weeks on discovering > > how broken floor planning with RPMs in 4.2i was, and there's no way i > > can do without manual floorplanning. Altera had even less options and > > the devices had no SRL16 equivalent. If 5.1i is no good, i'll start > > investigating the cyclone devices. It would be good having a tool > > that runs on linux too (wonder if i still need that leonardo with > > the crappy gui bugs?). I was hoping 5.1i would fix everything, but > > i haven't tried it yet. > > I think in many cases it is better to stay with the "old" software and > handle the KNOWN bugs, instead of switching to new software with UNKOWN > bugs. Yes, we all are unpaid BETA testers, but if you can avoid this, you > better should do so. How many people REALLY need the new features (what are > they?) of 5.1?? > Up to now, I dont. So I will not change, especially not while a project is > running. I learned this lesson the hard way once. I started a project with a poor tool and had to switch to get the project moving ahead. So I had to rewrite my code since it was my first VHDL project and was written to the buggy compilier. Then after another month or two a new version of the tool came out and it used a different synthesizer. So I had to "adjust" my code a second time. Support for the old tool ended with the introduction of the new synthesizer. Put me back a total of a month or so with the two rewrites. At least I learned a few things about writing VHDL to be as compiler independant as possible. :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48081
"Falk Brunner" <Falk.Brunner@gmx.de> writes: > "MikeJ" <pacman@fpgaarcade.com> schrieb im Newsbeitrag > news:1034208063.92802.0@dyke.uk.clara.net... > > > Xilinx tools are not interesting, they don't need to be. Many designers > > never even run up the gui. The simulator is where the action is. > > From which planet are you from? I don't use the GUI very much expect for floorplanning. Of course I use a waveform viewer (signalscan in my case) for post simulation analysis. If you work on larger designs with multiple designers involved you will enjoy keeping design and script files in a source code control systems (like CVS). Designer X can check out scripts and reproduce the same FPGA synthesis and PAR result as designer Y did a week ago. I've seen nightmares where source files have been copied from PC to PC and nobody knew where the real source was. I've seen designer X failing to reproduce the steps of designer Y since X had a different button checked off four levels down in a dialog box. I would like the software vendors spending their effort on functionality, performance, and reliability before making a cute chip jumping around on the screen telling you on what it think you should do next. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 48082
rickman <spamgoeshere4@yahoo.com> writes: > Russell wrote: > > > > > Of course when I say they "can't afford" to self fund the tools, that is > > > a relative term. The point is that the tools cost a lot of money to > > > maintain and update. The economics are not there to allow open source > > > tools to compete. Given that they can not[1] stop open source tools, they are going to have to learn to live with them when they arrive (which is just a question of time, nothing else). They can only delay them by not helping (which they will not help, also for liability and support cost reasons, which I fully agree with them). [1] no one less than Peter Alfke said that Xilinx can not, and does not want to. > > All the fpga vendors need to do is make a publicly available API for > > the devices, and keep doing whatever tools they have now. Private and Xilinx has already done that. I have though not heard of any other vendor copying this move. (Thanks Xilinx!) It is called JBits. Mail to jbits@xilinx.com to get an FTP URL and password to download it (its free as in free beer). I presently use Version 2.8 (install Nov 2001), started with 2.4 (late 1999). > > public projects will start up for various reasons such as profit, > > academic purposes, or just to improve on what's available. Or just for the fun of doing it. Or to avoid the frustration which closed source software unavoidably brings with it. > > Eventually > > the GPL tools will be better than those done by nine-to-fivers that > > couldn't give a stuff about fixing bugs. Does not need GPL. Any open source, simply by being open, will get better. Just like science (with all results fully public, no license) with time had to get better then church dogma. > > The fpga vendors can then > > either support the GPL tools and keep frozen releases for safety, > > or just keep doing their own tools but get useful ideas from the That is most likely. They can do their game, and open source does its game. See gcc vs Intel C compiler. > I don't think you read anything I wrote. First, every copy of open > source tools that is used in place of a vendor supplied tool takes away > revenue for vendor tool development. C'est la vie. Every competitor (other chip maker) also does. The best that can happen to an vendor is that when open source arrives, it happens on their chip (and so at cost of their competitors chip sales, both will lose the low-cost end software sales). When my tools arrive, it is going to be Xilinx that profits (because I started from JBits out). And any extra chip they sell because of them will be the best "thanks" (dollars, not words) I can give them for enabling my stuff. > Second, no vendor is going to > consider any plan that takes the "family jewels" and trusts them to an > outside, free ranging band of developers. The tools are a competitive > edge for the FPGA vendors. They can not introduce new parts without in > house tool support. Seems that CPU manufacturers also thought that decades ago. No one expected to sell computers without having the most important compilers (first Assembler. then Fortran and Cobol, later possibly Algol or Basic) for them. Dito also having an own operating system (now that was a costly feature war). Today most CPU makers just cooperate with compiler and operating system makers (see AMD supporting the gcc port to x86-64 and the Linux/x86-64 port). And in the embedded market (more similar to FPGAs than desktop PCs are) we see 8051s from various cloners (with different feature sets) and official Intel tools vs open source ones. > So they can't afford to lose the revenue that pays > for tool development. Unless they change their business model. Adapt or die is the name of the game in business. > You only seeing the local picture of "we can do a better job than the > FPGA vendors". I am not at all convinced that this is true. gcc currently under-perfoms Intels C compiler by about 20%. It is used by way over 10 (or 100 or 1000) times as many users. Because it is a lot easier to use, easier available, more software for it because one can expect it everywhere, no licencing trouble/faillures ... I expect an similar open/wide/basic vs vendor/power/complex split in FPGA tools. And yes, at the prices of top end FPGA tools (5-digit-$), and the cost structure of their paying customers, they should be able to do this. > FPGA tools > are a moving target and very different from software development tools. > Every new generation of FPGAs require very different software. So did every generation of CPUs in the days when every generation had an new instruction set. Today it is less work, because we have binary compatibility and improvement goes into making the existing "bitfiles" (read: binary applications) move faster. I expect FPGAs will have to go the same route: mass market with binary compatibility, cloners[2], etc and an more diversifed "specialist" market where everything goes, for max performance, at high price. The Virtex vs Spartan split already points in that direction. Think of an non-compatible max-power series of Virtex-II, -III, -IV, -V and an Virtex(-I) compatible staying low cost line of Spartan-II, -IIE, -IIEM, -IIX, -II? as an possible future. [2] Think of the next Clearpath with the same size relationship to Altera or Xilinx that AMD has to Intel. And aiming for full pin and bit compatible SRAM based chips (not mask based specials). Drop in replacement, like an AMD K6 (what I am typing this on) fitting an Pentium I socket. And an power/price race ensuing, fought on process technology and feature. > Before anyone starts asking the FPGA vendors to hand over the inside > info on their parts, how about we get some *good* open source *front end > tools*??? They are simply not interesting to program (an important prerequisite for open source programmers, entertainment value), so long the missing back end makes an full-open path impossible. If you are going to do something that requires you to get closed P&R to work, then just use the VHDL/Verilog compiler that comes with it. The "magnet" is a running bitstream, and the shortest path to that is interesting. So the action starts at the back end. > Trust > me, if there were decent open source tools for FPGA work, there would be > a lot of people working with them. They will happen, they are happening. You may remember that 1 year ago said I was planning on doing something, as soon as I get time? I have now got time. I am doing something[3]. I started coding 2.5 months ago. I expect to arrive at 2nd milestone this weekend. About 5th or 6th milestone (these will take longer, and have to share time with other projects that were dormant last 2.5 months) should see bitstreams generated from scratch. Look again in 1 year. [3] http://neil.franklin.ch/Projects/VirtexTools/ -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 48083
Super. Thanks John. -Xanatos "John_H" <johnhandwork@mail.com> wrote in message news:3DA61E31.6042CFCB@mail.com... > Use two registers to store the reset signal. The first register clears after n > clock #1 events and the other register clears after m clock #2 events. A Xilinx > SRL can be configured to give a nice delay so the power-on allows everything to > be ready to go by the time the reset flop deasserts for either time domain. > > The technique should provide the delays you need to use the asynchronous > @negedge or the synchronous logical version. > > > Xanatos wrote: > > > Hey All, > > > > The subject is probably a tad confusing. Anyways, here is my problem: > > > > I have 2 input clocks from an external sources. There is one chip reset, > > which is sync to one of the input clocks. > > > > The reset should be sync'd to the second clock domain (#1 to avoid > > metastability issues). However, while clock #1 always exists, clock #2 may > > not occur until after the reset. > > > > So, when the second clock starts up, the reset has already been negated, and > > I've missed the @negedge of the reset. > > > > Any hints or suggestions? > > > > Cheers, > > Xanatos >Article: 48084
On 11 Oct 2002 00:10:33 +0200, Neil Franklin <neil@franklin.ch.remove> wrote:
>Xilinx has already [made a publicly available API for their devices].
>It is called JBits. Mail to jbits@xilinx.com to get an FTP URL and
>password to download it (its free as in free beer).
Free beer doesn't normally come with an NDA.
>[2] Think of the next Clearpath with the same size relationship to Altera
>or Xilinx that AMD has to Intel. And aiming for full pin and bit compatible
>SRAM based chips (not mask based specials). Drop in replacement, like an
>AMD K6 (what I am typing this on) fitting an Pentium I socket. And an
>power/price race ensuing, fought on process technology and feature.
I think you underestimate the maze of interlocking FPGA patents
that Altera and Xilinx have, that could quickly shut down anyone
who did not approach them on hands and knees with a wad of cash.
>> Before anyone starts asking the FPGA vendors to hand over the inside
>> info on their parts, how about we get some *good* open source *front end
>> tools*???
>
>They are simply not interesting to program (an important prerequisite
>for open source programmers, entertainment value), so long the missing
>back end makes an full-open path impossible. If you are going to do
>something that requires you to get closed P&R to work, then just use
>the VHDL/Verilog compiler that comes with it.
>
>The "magnet" is a running bitstream, and the shortest path to that is
>interesting. So the action starts at the back end.
The newest snapshots of Icarus Verilog have greatly expanded
synthesis capabilities. It needs more debugging before it can
be truly useful as a front end.
I happen to believe that bitstream generation is not interesting
to program, so long as the missing front end makes a full-open path
impossible. ;-)
- Larry
Article: 48085--------------D5A17F20A5C5B2EF921988ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, Xilinx is listening. We treat comments like this very seriously and have great pride in our software. Feedback like this does have an impact on future software releases if it is specific and/or we have a test case to replicate the problem. Let me try to answer some of the comments and questions. Sorry for the length. > If it does show me the error, it is usually at some intermediate > code, not at the source. For example, if there is a section of the > design done in schematic capture, the program will show a VHDL file > with an error, rather than pulling up the schematic and showing the > source of the error. I believe this is only an issue for schematic flows and is planned to be fixed in a future release. > Sometimes the error message will say that something is off grid > (Error point not on primary grid) on the schematic at x=1608 y=1504 > and expect me to open the schematic and hunt for the X,Y location. If > the program knows the location, it should be able to open the > schematic and highlight the error for me. This is fixed in 5.1i. > The schematic program has an error checker (Tool| Check Schematic) > to help find errors in the schematic. After it you correct them you > can run the tool again. Many times it will still show at least one > error after all of them have been fixed. If you exit the schematic > program, then reopen the schematic, and run the error checker it will > show no errors. This is caused by the same off grid problem and should be fixed in 5.1i. > Since the Xilinx Project Navigator is just a collection of separate > programs and third party utilities, they each have a different user > interface. Each program requires different keystrokes to do the same > thing. For example, in the Schematic program, Zoom-in is F8, in the > State Cad program it is CTL+PgUp, in ChipView (F7). We do have plans to make this more consistent. Much of this is due to tool aquisitions. ECS was aquired from MINC and StateCAD was aquired from VSS. Rewriting these applications has been a lower priority than general ease of use and timing closure. > Sometimes when you edit the pins assignments, save them in > Chipview, and then try to recompile the design nothing happens. You > have to remember that as long as Chipview is open, the Project > Navigator will ignore you and not show any reason why. (Oh yeah, I > have to close that program before it will respond). This is planned to be fixed for the Verilog flow in 5.2i. The VHDL flow should already be working (assuming that you save the file in Chipviewer). > As a special gift, xilinx doesn' t support the synopsys fpga compiler > Xilinx does support FPGA Compiler II and has since it's introduction. > And the spartan (4000 architecture) devices aren' t supported any more. > The Spartan and XC4000 devices are supported with 4.2i and with a free web downloadable package that will be available later this month. > Furthermore a xilinx FAE told me that the fpga editor also died because of a > canceled contract with the manufacturer. > FPGA Editor was written by Xilinx and we have no plans to ever discontinue it. You must be talking about FPGA Express which was discontinued when the contract expired and Synopsys discontinued the product. > I can't say that the Xilinx tools are perfect. But when you do tough > designs I find it a lot easier to see what is going on with the P&R and > to find ways to deal with any problems. > Yes, this is a major focus for our tools. > Where is Xilinx's floorplanner for CPLD designs? > Chipviewer allows you to floorplan your pins. Internal CPLD floorplanning has been somewhat lower on our priority list, but is on our roadmap. > The instructor says, "Oh those are the > normal Xilinx warnings. Just ignore them". How come it generates so > many warnings even when its working? > Most warnings are there because the tool encountered something unexpected and it wants to tell the user about it. Over the past year or 2, we have significantly reduced the number of warnings produced and plan to continue, especially with duplicate warnings. > It's really too bad they don't provide you a way to enable/disable the > minor warnings > Minor warnings on one design can be major warnings on another. How about letting you mark the ones you don't want to see again? > Bad news on 5.1. RPMs slow the mapping waaay down, at least big RPMs do. > Yes, on Ray's design with big RPMs, the mapper slowed down. We have 3 people looking into this. > The latest speed files should be made readily available for 3.3 at > a minimum because of the functional problems with later software releases). > Often, speed file changes require changes to the software, so this would not be possible. > Xilinx, do you have a quality assurance problem with your software? > With tens of thousand of active customers, there will always be edge cases which slip through our verification process. We have over 50 engineers testing the software and spend the last few months of our release cycle doing nothing but testing and fixing bugs. Thanks for the feedback and feel free to email me directly with enhancement requests for the Xilinx software. Steve Lass Director, Software Product Marketing Xilinx, Inc.Article: 48086
Hello All, I wanted to post the following requirement for an FPGA Design Engineer in San Jose. If you meet the criteria and would like more information please contact me by phone or email. ericw@terransys.com 408-727-9000 Also, if you know someone who might appreciate a call from me please let me know. Thank you, Job Title: Senior FPGA Designer FPGA design experience: Taking an FPGA project from concept to production. The following skill set is required: At least two FPGA designs with Xilinx Vertex-II devices, with frequencies in the 200+ MHz range A minimum of 7 years of Verilog design experience A minimum of 7 years FPGA design experience Proven ability to floorplan FPGAs for optimized performance Experience with Xilinx ISE Foundation or ISE Alliance tools Good documentation and debugging skills are necessary. Only candidates with a minimum of 7 years of direct FPGA experience will be considered. Candidates should possess a Bachelor's degree in Computer or Electrical Engineering or equivalent, and be able to work with a minimum of supervision.Article: 48087
My $.02... I've found Max+Plus II to be very easy to use for simple to medium complexity designs. I like the schematic editor, I think the waveform simulator is adequate for quick to medium complexity tests (it would be nice to be able to easily pick a buried signal however) and the software doesn't run too slowly even on older hardware. I also agree with previous comments that the Altera software is truly integrated, unlike the Xilinx stuff which is a bunch of tools loosely tied together. That being said, the Xilinx stuff gives you more power if you know how to use it (and where to look). I see the Altera software akin to a 90's era Macintosh where the most commonly used functionality is there and is easy to use but there are still a lot of oversimplifications (i.e. one-button mouse). Xilinx stuff reminds me of a UNIX system which can be powerful for very complicated tasks but can make life hard for some very simple things. Ray Andraka <ray> wrote: > We've hit some bugs in 4.2 that are show stoppers, and which are apparently > going to force us into 5.1 for the virtexII (3.3 doesn't support several > virtexII features, so you are forced to use 4.x or later). Of course 5.1 > introduces new bugs, so we are in limp mode until we get a suitable combination > of tools working. This is what I don't get. Who exactly is the target audience for such versions of these tools? The user who uses 1% of the FPGA and likes to throw away $2k+ on bugs and clutter? Where exactly are the "improvements"? Obviously people from Xilinx read this forum and obviously people like Ray know what the hell they are doing, so how come no one ever fixes these issues, let alone the crappy UI problems that have persisted forever? (And slightly off topic, but still relevant, how come Altera people can't openly read and post? We'd like USEFUL suggestions from them too!) I've used Foundation since 1.3 and I still find the UI of 4.2ISE confusing and amazingly complex. If the facts are true, that Xilinx has more SW people than HW people, what exactly are the SW people doing?! Ok, I'm done. S2.Article: 48088
You need the roms from the original namco / midway arcade machine, which is the hardware thats emulated. try the keyword MAME (multi arcade machine emulator) /MikeJ "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:ao4mk9$je13k$3@ID-84877.news.dfncis.de... > "MikeJ" <pacman@fpgaarcade.com> schrieb im Newsbeitrag > news:1034270260.43696.0@demeter.uk.clara.net... > > > I can't help you with the rom images, although many software emulator > sites > > have them. > > I am also working on some tools that will convert a binary file to xilinx > > block rams which will help. > > At least, can you tell me what system it is?. I found many places for > celebrating old Z80 game systems, but there are many. Which one is it? > A binary file is fine, conversion will not be a problem. > > -- > MfG > Falk > > > >Article: 48089
lass wrote: <snip good response > > It's really too bad they don't provide you a way to enable/disable the > minor warnings > > Minor warnings on one design can be major warnings on another. True. > How about letting you mark the ones you don't want to see again? That's a good idea, and other EDA tools are starting to offer this. A log file should record _all_ warnings, but a scheme to tag ones as 'read and accepted : do not display' is very good. - it means 'clean compile runs' can be possible, and makes new warnings much easier to spot. -jgArticle: 48090
Hey All, The subject is probably a tad confusing. Anyways, here is my problem: I have 2 input clocks from an external sources. There is one chip reset, which is sync to one of the input clocks. The reset should be sync'd to the second clock domain (#1 to avoid metastability issues). However, while clock #1 always exists, clock #2 may not occur until after the reset. So, when the second clock starts up, the reset has already been negated, and I've missed the @negedge of the reset. Any hints or suggestions? Cheers, XanatosArticle: 48091
You mentioned metastability, and that caught my attention. Metastability is a reality, but it (and the fear of it) is highly overrated. We recently tested Virtex-IIPro flip-flops, made on 130 nm technology. You might call that cutting edge technology, but not exotic. When a 330 MHz clock synchronized a ~50 MHz input, there was a 200 ps extra metastable delay ( causing a clock-to-out + short routing + set-up total of 1.5 ns) once every second. That translates into a metastable capture window that has a width of 3 ns divided by 100 million ( since we looked at both edges of the 50 MHz signal). So the window for a 200 ps extra delay is 0.03 femtoseconds. If you can tolerate 500 ps more, the MTBF increases 100 000 times, and the capture window gets that much smaller. Metastability is a real, but highly overrated problem. Peter Alfke, Xilinx Applications Xanatos wrote: > Hey All, > > The subject is probably a tad confusing. Anyways, here is my problem: > > I have 2 input clocks from an external sources. There is one chip reset, > which is sync to one of the input clocks. > > The reset should be sync'd to the second clock domain (#1 to avoid > metastability issues). However, while clock #1 always exists, clock #2 may > not occur until after the reset. > > So, when the second clock starts up, the reset has already been negated, and > I've missed the @negedge of the reset. > > Any hints or suggestions? > > Cheers, > XanatosArticle: 48092
If you want to get the low power, you are in more or less the same boat.
Careful floorplanning can reduce power 20-30% easily. Also, pipelining reduces
power in an FPGA. Turns out a substantial amount of power is due to
combinatorial settling. The deeper the pipelining, the less the glitches can
propagate and the lower the power. A paper at FPGA/2002 discussed this in
detail and attributed some 30+% of the power to that phenomenon, and showed that
pipelining decreased power.
Falk Brunner wrote:
> n performance!!
>
> So Iam a lucky (??) guy who works only on medium and low power stuff and
> can get away with the bug.
>
> --
> MfG
> Falk
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48093
--------------959DEA7D148B5DDE11E14EC3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
In the case of the VIrtexE speed files that got slower with
the release of 4.1, the speed files were produced also for
3.3sp8 and distributed to the FAEs. I have a full set of
them (and had to recall several designs because of the
degraded numbers). I can understand if the speed files
aren't available because it is for an older version that is
no longer supported, but in the case where they have been
produced, what is the reason for not making them available.
Instead, I have to step in and help past customers because
they don't have access to the speed files.
My enhancement request is to get the stuff that is in there
working before adding new stuff or making gratuitous changes
to the GUIs.
lass wrote:
> Often, speed file changes require changes to the software,
> so this would
> not be possible.
>
>> Xilinx, do you have a quality assurance problem with your software?
>>
> With tens of thousand of active customers, there will
> always be edge cases
> which slip through our verification process. We have over
> 50 engineers testing
> the software and spend the last few months of our release
> cycle doing nothing
> but testing and fixing bugs.
>
> Thanks for the feedback and feel free to email me directly
> with enhancement
> requests for the Xilinx software.
>
> Steve Lass
> Director, Software Product Marketing
> Xilinx, Inc.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin
Franklin, 1759
Article: 48094> I think you underestimate the maze of interlocking FPGA patents > that Altera and Xilinx have, that could quickly shut down anyone > who did not approach them on hands and knees with a wad of cash. > Your telling me. At one time Xilinx want me to give up all my patent rights forever to get a copy of JBits. Of course I have the patent on run time generation so no one is going to stop me from what I'm doing. Also there is no guarantee that they will continue the program now that Steve Guccione doesn't work there any more. A small group of hackers could reverse engineer the bitstream. Use xdl to get the info go into the FPGA editor and start turning on pips. You only have to do about 10 or 12 tiles and the whole thing should fall out. Even without the bitstrean you could use xdl and translate that into the U of Toronto place and route tool and you'd be happening. > I happen to believe that bitstream generation is not interesting > to program, so long as the missing front end makes a full-open path > impossible. ;-) This is not a clear picture of what it is all about. By understanding the bit level you can do some very interesting things. You can an algorithm and design it so that when given the data you produce a design just for that data. This is the way to be ASICs. For example there is a DES paper done in JBits where you take the key and generate a DES design just for that key. Sure an ASIC could use the same techniques but who wants to buy a chip that can only encode/decode with one key? If you load constants at the bit level then you save the area you would have to use to mux in the constants so you can put more logic in the same area and thus have a high through-put. The only reason we are still using (say it with me) sucky simulated annealing is everyone treats FPGAs like ASICs and not like CPUs. Imagine have your C code chopped up with no regard for your subroutines and then randomly moved around till its "pretty close to what you want." It is historically hysterical. Some day it will be different. I'm also working on tools that let you manipulate the bit stream and they work with the V1 and V2 parts. You should be able to give a name to some LUT or flop and change it from a command line and have the software generate a partial packet and down load the change live. I'll have that working in a few weeks. SteveArticle: 48095
Use two registers to store the reset signal. The first register clears after n clock #1 events and the other register clears after m clock #2 events. A Xilinx SRL can be configured to give a nice delay so the power-on allows everything to be ready to go by the time the reset flop deasserts for either time domain. The technique should provide the delays you need to use the asynchronous @negedge or the synchronous logical version. Xanatos wrote: > Hey All, > > The subject is probably a tad confusing. Anyways, here is my problem: > > I have 2 input clocks from an external sources. There is one chip reset, > which is sync to one of the input clocks. > > The reset should be sync'd to the second clock domain (#1 to avoid > metastability issues). However, while clock #1 always exists, clock #2 may > not occur until after the reset. > > So, when the second clock starts up, the reset has already been negated, and > I've missed the @negedge of the reset. > > Any hints or suggestions? > > Cheers, > XanatosArticle: 48096
Neil Franklin wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > > Russell wrote: > > > > > > > Of course when I say they "can't afford" to self fund the tools, that is > > > > a relative term. The point is that the tools cost a lot of money to > > > > maintain and update. The economics are not there to allow open source > > > > tools to compete. > > Given that they can not[1] stop open source tools, they are going to have > to learn to live with them when they arrive (which is just a question > of time, nothing else). They can only delay them by not helping (which > they will not help, also for liability and support cost reasons, which > I fully agree with them). > > [1] no one less than Peter Alfke said that Xilinx can not, and does > not want to. They can not in the sense of copyright infringement or patent issues perhaps. But if they don't have the inside scoop on the chips, they will have a long row to hoe. That brings us back to one of my points. The open source tools will *never* be up to date. The chip cycle is just too short for a bunch of freeware guys to keep up with. This point has been discussed here several times before. It always comes down to a few designers who say it won't happen and a few others who say it is inevitable. But we never see the tools... > When my tools arrive, it is going to be Xilinx that profits (because I > started from JBits out). And any extra chip they sell because of them > will be the best "thanks" (dollars, not words) I can give them for > enabling my stuff. And when can we expect this tool? What devices will it support? What will be *better* about it than the tools already in use? > > Second, no vendor is going to > > consider any plan that takes the "family jewels" and trusts them to an > > outside, free ranging band of developers. The tools are a competitive > > edge for the FPGA vendors. They can not introduce new parts without in > > house tool support. > > Seems that CPU manufacturers also thought that decades ago. No one > expected to sell computers without having the most important compilers > (first Assembler. then Fortran and Cobol, later possibly Algol or > Basic) for them. Dito also having an own operating system (now that > was a costly feature war). > > Today most CPU makers just cooperate with compiler and operating system > makers (see AMD supporting the gcc port to x86-64 and the Linux/x86-64 > port). > > And in the embedded market (more similar to FPGAs than desktop PCs > are) we see 8051s from various cloners (with different feature sets) > and official Intel tools vs open source ones. This has also been discussed before. Compilers have become commodity items where one is about as good as another for 99% of the work done with them. FPGA software is still in the stage of being very highly tuned to the chip else it is of little value. If you are doing simple designs in uncrowded chips then you don't care what tools you use, but most FPGA users push their designs if not initially, they do when being upgraded in the field. They need tools that work very well with their chip. > > So they can't afford to lose the revenue that pays > > for tool development. > > Unless they change their business model. Adapt or die is the name of > the game in business. However there is *nothing* to adapt to. There are *no* open source tools that can be used on a production design. > > You only seeing the local picture of "we can do a better job than the > > FPGA vendors". I am not at all convinced that this is true. > > gcc currently under-perfoms Intels C compiler by about 20%. It is used > by way over 10 (or 100 or 1000) times as many users. Because it is a lot > easier to use, easier available, more software for it because one can > expect it everywhere, no licencing trouble/faillures ... > > I expect an similar open/wide/basic vs vendor/power/complex split in > FPGA tools. And yes, at the prices of top end FPGA tools (5-digit-$), > and the cost structure of their paying customers, they should be able > to do this. You can expect what you want, but that won't make it happen. There are very few engineers that are going to start a significant project with open source FPGA tools when their company will pay for the commercial tools. You make a lot of predictions that won't be tested for 10 years or more. Someone correct me if I am wrong, but Xilinx and Altera have NO $5-digit tools (unless you are counting the pennies). The expensive tools are the synthesis and simulation tools. These are third party and they charge so much because they are so good. But this is the first place that open-source tools should show up. All the interfaces are defined in public standards, the functionality is known, all that is needed is the open source code. So where is it??? Where are the open source synthesizers and simulators? I believe there are one or two out there and they *stink*. Hopefully they will improve with time. Certainly they are much more like the gcc target. But the back end tools are very different. *That* is why there are no third party back end tool vendors. > > FPGA tools > > are a moving target and very different from software development tools. > > Every new generation of FPGAs require very different software. > > So did every generation of CPUs in the days when every generation had > an new instruction set. Today it is less work, because we have binary > compatibility and improvement goes into making the existing "bitfiles" > (read: binary applications) move faster. As soon as the x86 came out (~1981, IIRC) the basic instruction set was cast in concrete. About 5 years later compilers matured and by 1991 they had become commodities. > I expect FPGAs will have to go the same route: mass market with binary > compatibility, cloners[2], etc and an more diversifed "specialist" market > where everything goes, for max performance, at high price. Patents will stop cloners. There is no market force driving FPGAs in this direction, just as there is no market force driving all CPU makers to adopt a common instruction set. If Intel could stop them, there would be no AMD or Cyrix chips. But even Intel is smart enough to know that multiple instruction sets are a *good* thing. That is whey they built so many different chips over the years. > The Virtex vs Spartan split already points in that direction. Think of > an non-compatible max-power series of Virtex-II, -III, -IV, -V and an > Virtex(-I) compatible staying low cost line of Spartan-II, -IIE, -IIEM, > -IIX, -II? as an possible future. I'm not sure what you mean by this. Are you talking about a competitor chip? Xilinx won't let that happen... > [2] Think of the next Clearpath with the same size relationship to Altera > or Xilinx that AMD has to Intel. And aiming for full pin and bit compatible > SRAM based chips (not mask based specials). Drop in replacement, like an > AMD K6 (what I am typing this on) fitting an Pentium I socket. And an > power/price race ensuing, fought on process technology and feature. I think you mean Clearlogic... and they have gone the way of the dodo bird because of infringement issues. AMD could make parts that fit the Pentium socket because they had a license for that. After Socket 7 (IIRC) they no longer had that license and they now have to make their own interfaces. No FPGA company is going to let a startup copy their technology. > > Before anyone starts asking the FPGA vendors to hand over the inside > > info on their parts, how about we get some *good* open source *front end > > tools*??? > > They are simply not interesting to program (an important prerequisite > for open source programmers, entertainment value), so long the missing > back end makes an full-open path impossible. If you are going to do > something that requires you to get closed P&R to work, then just use > the VHDL/Verilog compiler that comes with it. Now you understand... :) > The "magnet" is a running bitstream, and the shortest path to that is > interesting. So the action starts at the back end. So you want to do the hardest part first, show the least result and have your work obsoleted most rapidly? > > Trust > > me, if there were decent open source tools for FPGA work, there would be > > a lot of people working with them. > > They will happen, they are happening. > > You may remember that 1 year ago said I was planning on doing something, > as soon as I get time? I have now got time. I am doing something[3]. > > I started coding 2.5 months ago. I expect to arrive at 2nd milestone > this weekend. About 5th or 6th milestone (these will take longer, and > have to share time with other projects that were dormant last 2.5 months) > should see bitstreams generated from scratch. Look again in 1 year. > > [3] http://neil.franklin.ch/Projects/VirtexTools/ I looked at your page and I do not see where you are headed. Once you have built all the parts of the intended toolchain, what will the flow be? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48097
lass wrote: > > Yes, Xilinx is listening. Stop it! You're creeping me out... :-( -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48098
rickman wrote: > > Neil Franklin wrote: > > > ... > They can not in the sense of copyright infringement or patent issues > perhaps. But if they don't have the inside scoop on the chips, they > will have a long row to hoe. That brings us back to one of my points. > The open source tools will *never* be up to date. The chip cycle is > just too short for a bunch of freeware guys to keep up with. The *family* of a chip stays around for a while, and any compilers/fitters can be tuned to each size and architecture with table-driven rules that would be easy to update given a sufficient data sheet. There's also the advantage that you can still maintain old designs easily. > This point has been discussed here several times before. It always > comes down to a few designers who say it won't happen and a few others > who say it is inevitable. But we never see the tools... ... > However there is *nothing* to adapt to. There are *no* open source > tools that can be used on a production design. Linux and open source are only fairly new, and there's a certain learning curve before capable developers appear for more specialized tool development. Also, before jbits, creating open source tools is completely uninteresting if all it involves is making a pretty front-end. > > gcc currently under-perfoms Intels C compiler by about 20%. It is used > > by way over 10 (or 100 or 1000) times as many users. Because it is a lot > > easier to use, easier available, more software for it because one can > > expect it everywhere, no licencing trouble/faillures ... > > > > I expect an similar open/wide/basic vs vendor/power/complex split in > > FPGA tools. And yes, at the prices of top end FPGA tools (5-digit-$), > > and the cost structure of their paying customers, they should be able > > to do this. > > You can expect what you want, but that won't make it happen. There are > very few engineers that are going to start a significant project with > open source FPGA tools when their company will pay for the commercial > tools. You make a lot of predictions that won't be tested for 10 years > or more. I would start with an open source tool if there was one at the time. I'd also be doing bug fixes and adding *useful* features (i'm not quite up to that level on linux yet). > Someone correct me if I am wrong, but Xilinx and Altera have NO $5-digit > tools (unless you are counting the pennies). The expensive tools are > the synthesis and simulation tools. These are third party and they > charge so much because they are so good. Leonardo-spectrum GUI good? Most of the other tools could be improved too. > But this is the first place > that open-source tools should show up. All the interfaces are defined > in public standards, the functionality is known, all that is needed is > the open source code. So where is it??? Where are the open source > synthesizers and simulators? There's no motivation to do it if there's no info available for the low-level control of most fpgas. It would be like doing open source development if the only compilers available had to be bought from microsoft. The opcodes and assembly instructions of microprocessors are freely released by cpu vendors to encourage tool creation. The same should apply to fpgas. FPGAs have a short life cycle because the industry is immature. Process limits will slow this down in a few years, when open-source will be much more common-place.Article: 48099
Steve Casselman wrote: > This is not a clear picture of what it is all about. By understanding the > bit level you can do some very interesting things. You can an algorithm and > design it so that when given the data you produce a design just for that > data. This is the way to be ASICs. For example there is a DES paper done in > JBits where you take the key and generate a DES design just for that key. > Sure an ASIC could use the same techniques but who wants to buy a chip that > can only encode/decode with one key? If you load constants at the bit level > then you save the area you would have to use to mux in the constants so you > can put more logic in the same area and thus have a high through-put. Uh, correct me if I am wrong, but don't the FPGAs have RAM and muxes to do all this??? So you could just as easily put RAM and muxes on your ASIC and accomplish the same task in the same *single key but programmable* way. It would certainly be more expensive to make an ASIC, but there would still be performance gains. The ASIC would have about the same timing on the RAM and logic, but certainly it would have faster routing. > The > only reason we are still using (say it with me) sucky simulated annealing is > everyone treats FPGAs like ASICs and not like CPUs. Imagine have your C code > chopped up with no regard for your subroutines and then randomly moved > around till its "pretty close to what you want." It is historically > hysterical. Some day it will be different. I'm also working on tools that > let you manipulate the bit stream and they work with the V1 and V2 parts. > You should be able to give a name to some LUT or flop and change it from a > command line and have the software generate a partial packet and down load > the change live. I'll have that working in a few weeks. Of course no one treats FPGAs as CPUs... CPUs are so slow compared to logic. Very few FPGAs run C code. But if you goal is to run C code then an FPGA could be the best way to do that using on the fly configured logic. But there is a lot of work that needs to be done that does not require the FPGA tools. It will be hard indeed to see what is happening inside the chip when the chip is programming itself. This would be much better simulated at a higher level and when working well brought down to the bit stream, IMHO. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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