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
"Kolja Sulimma" <news@sulimma.de> wrote in message news:41daf793$0$29426$9b4e6d93@newsread4.arcor-online.net... > Antti Karttunen (remove .fo from the address) wrote: > >> Kolja Sulimma wrote: >> >>> Xilinx also has an patent on implementing an 8-input AND in a single >>> CLB. Hopefully your Microblaze clone does not use this feature, they >>> could use that patent to come after you. (Peter Alfke stated in this >>> newgroup that they wouldn't) >> >> I guess here you mixed me with Antti Lukats. However, I >> come from the other side of the gulf, and I'm just beginning >> to learn the secrets of EE. > > I did. My apologies. > >>>> I.e. is a Verilog or VHDL-source file just >>>> "a description for hardware device" >>>> or is it yet another (strange) form of software? >> >> Yes, of course. However, what I was striving after here >> was that what happens if the public (and EPO) opinion >> at some point comes to view the writing of Verilog/VHDL-modules >> as a creation of SOFTWARE (for these "massively parallel >> reconfigurable processing chips", i.e. FPGAs), >> instead of viewing it as a description of HARDWARE? >> This view might come more prevalent if the FPGA's >> will be getting more and ASIC's less common, >> and if the data processing/computing applications >> will prevail over more traditional EE-fields. > > Actually that is the trick (the other way around) that is currently used > in the EU to file software patents. You do not patent an algorithm, but > the "idea" to run the algorithm on a processor, claiming that the > combination of algorithm an CPU is a device, the algorithm beeing the > configuration of the hardware. > > But that really is against the words and the meaning of the law. > The idea to run Bresenhams algorithm on a CPU is not a technical > invention. If it is, it is so similar to running Quicksort on a CPU that > the level of innovation is not high enough for a patent. > > But of course you have a big grey area. Because it is hard to distinguish > a new multiplier architecture from a new multiplication algorithm. And the > barrier of where patents get absurd might indeed move more towards > hardware. > > If you look at the discussion about software patents, the core argument > is, that software is relative easy to develop, and as a result, software > projects tend to get huge and incorporate thousands of patentable ideas > (or combination of ideas). To check whether a software project violates > any patents therefore becomes impossible and software development becomes > a gamble. > > To check an RF receiver or a new chemical for patent violation on the > other hand is relatively easy. > > With large FPGA projects with ever improving high level synthesis the > situation begins to look very similar to the process of software > development. > > I believe that the australien view that the patent system in general is > not beneficial for society is right. > > Kolja Sulimma Unfortunately as of the 1st of January 2005 we have adopted the US system Lock, stock and barrel as part of a trade deal with the US. Including copyright and patent law. Fun thing is that some patents that expired here are now back in force (Australian patent expired but the US patent hasn't) A lot of lawyers here and in the US are rubbing their hands in glee. Quite a lot of small businesses are sweating at the moment on their company names. AlexArticle: 77501
Gregory C. Read wrote:
> It would be easier to compare netlist output files.
Yes generate HDL netlists from ISE and diff those.
Ben may need a script to sort the nets for large differences.
This is one of the downsides of using graphical source files.
-- Mike Treseler
Article: 77502Bill, Why didn't you say you were looking for prior art? Consult uspto.gov and do a search for xilinx, hardwire, etc. I am sure our IP lehal folks filed something! Best of luck with your endeavour (invention). If there is something you wish to discuss with Xilinx, I am gappy to direct you to th4e right folks, Austin Austin bill@viasic.com wrote: > Hi, Austin. > > Thank you for your description of the three families. This confirms > what I've heard before. I've checked out about the first 200 links > yielded by Google when searching for 'xilinx hardwire'. Every one is > about the most recent gate-array based family. The first two families > seem to be hard to track down. > > My patent laywer is asking me for public documents on the first two > families, since these are considered strong prior art in the structured > ASIC market. Unfortunately, these families were gone before the web > took off, so there was never any on-line docs, so Google hasn't helped > me. Of course, the devices themselves can still be found, and that's > technically enough. > > Thanks, > Bill >Article: 77503
I'm having a problem printing the state machine generated using Xilinx IDE 6.3.03i to a Samsung ML-1740 printer. The text of the state machine prints but the bubbles of the states and the connecting lines do not print. I've tried printing to a different printer and it appears to work OK there. I've looked at the printer setup options and there is nothing listed that would indicate this kind of control. Has anyone else seen this kind of behavior? Thanks. DaveArticle: 77504
Uwe Bonnes wrote: > Brian Dam Pedersen <brian.pedersen@mail.danbbs.dk> wrote: > >>Hi All > > >>Sorry for this being slightly off-topic, but this was the closest group >>I could find. > > >>I need to configure a xilinx XC9536XL under linux. I've tried using >>naxjp, which can identify the CPLD correctly (sort of - it identifies it >>as being a cs48 when it actually is a pc44 ..), but when I try to >>program it I get > > >>$ ./naxjp -auto >>xc9536xv_pc44:/home/brian/projects/extensionboard/cpld/wiring.jed >>Device position 1. Command 'auto'. Partname 'xc9536xv_pc44'. File >>'pc44:/home/brian/projects/extensionboard/cpld/wiring.jed' >>Plug-in file 'algxc95xl' not found. >>Device error:ISP algorithm is unknown for device 'xc9536xv_pc44' >>Elapsed time: 37 ms > > >>However the algxc95xl IS in the directory. Since all documentation is in >>japanese and the source code not available I'm pretty stuck here. Btw. >>this is running on a Suse 9.1 system. So my questions are: > > > Is is a 95xl versus 95xv Problem. > > Bye > Great- however it did not bring me closer to a solution ;) Any other hints or advices ? -- BrianArticle: 77505
Uwe Bonnes wrote: > Brian Dam Pedersen <brian.pedersen@mail.danbbs.dk> wrote: > >>Hi All > > >>Sorry for this being slightly off-topic, but this was the closest group >>I could find. > > >>I need to configure a xilinx XC9536XL under linux. I've tried using >>naxjp, which can identify the CPLD correctly (sort of - it identifies it >>as being a cs48 when it actually is a pc44 ..), but when I try to >>program it I get > > >>$ ./naxjp -auto >>xc9536xv_pc44:/home/brian/projects/extensionboard/cpld/wiring.jed >>Device position 1. Command 'auto'. Partname 'xc9536xv_pc44'. File >>'pc44:/home/brian/projects/extensionboard/cpld/wiring.jed' >>Plug-in file 'algxc95xl' not found. >>Device error:ISP algorithm is unknown for device 'xc9536xv_pc44' >>Elapsed time: 37 ms > > >>However the algxc95xl IS in the directory. Since all documentation is in >>japanese and the source code not available I'm pretty stuck here. Btw. >>this is running on a Suse 9.1 system. So my questions are: > > > Is is a 95xl versus 95xv Problem. > > Bye > Got the hint - there was a typo in my command line. However fixing this did not fix my problems: $ ./naxjp -port digilent.txt -auto "xc9536xl_pc44:/home/brian/projects/extensionboard/cpld/wiring.jed" Device position 1. Command 'auto'. Partname 'xc9536xl_pc44'. File 'pc44:/home/brian/projects/extensionboard/cpld/wiring.jed' Plug-in file 'algxc95xl' not found. Device error:ISP algorithm is unknown for device 'xc9536xl_pc44' Elapsed time: 43 msArticle: 77506
One problem when i practice the EDK tutorial .....and download the bitstream
into ML310.....
Using Base system builder,I think the platform define, netlist generation,
implementation, software (TestApp.c - LED flash) compilation are all okay.
(No error found)
But when I (for the first time --: ) download (in XPS), I found the problems
below
1. In hyperterminal,
- I see the message
"DDR_SDRAM_32M*64
Running 32bit Test"
and then it is stuck
2. In ML310 board, i see the both of LEDs "OPB_ERR" and "PLB_ERR" are red
!!
(Meanwhile, the LED "DBG 3" is only green, other "DBG" LED does not
flash.
If someone knows what kind of problem this is.....could tell me what is the
problem.....
Article: 77507Brian Dam Pedersen <brian.pedersen@mail.danbbs.dk> wrote: > Got the hint - there was a typo in my command line. However fixing this > did not fix my problems: > $ ./naxjp -port digilent.txt -auto > "xc9536xl_pc44:/home/brian/projects/extensionboard/cpld/wiring.jed" > Device position 1. Command 'auto'. Partname 'xc9536xl_pc44'. File > 'pc44:/home/brian/projects/extensionboard/cpld/wiring.jed' > Plug-in file 'algxc95xl' not found. > Device error:ISP algorithm is unknown for device 'xc9536xl_pc44' > Elapsed time: 43 ms What is the Jtag ID of your chip? Perhaps there is some mismatch between what naxjp knowns and how your chips identifies itself. If you look around for naxjp-079, when source was still available, you may compile a debug version and look with gdb what is going wrong! I can sen you the 79.tgz version on request. Otherwise ask your Xilinx distributor for a 60 day demo of the Linux ISE version. You can use Impact then to program your chips Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 77508
Kubik, Perhaps if I catalog what devices use FPGAs? - servers, routers, switches -- basically all of the internet infrastructure serious network processing is done by FPGAs - cellular basestations (pretty much all of them are Xilinx FPGAs) - instrumentation (scopes, data test sets, network and spectrum analyzers, etc.) - fixed wireline and fiber optic systems, transmission equipments, digital switches, microwave radios, -- pretty much the entire telecom infrastructure is powered by FPGAs - CAT scan, radiology scanners, etc - high end big screen TV's - set top boxes (a small number of them, most have volume where an ASIC is a much better choice) - automotive navigation and entertainment systems - storage systems - extreme DSP processing systems - military and commercial security, encryption, and so on systems - in flight entertainment systems - military control systems for fighter jets - autonomous military vehicles - smart bombs, smart bullets - software defined radio systems - satellite control systems - the Mars Rovers .... oh, and ASIC prototyping. Probably one of the smallest market for FPGAs today. With the IBM 405PPC embedded in our parts, we now have almost half of our customers using the uP in the FPGA for things they used to use a separate uP for as well. Perhaps, the question should ask, is where is NOT a good application for a FPGA? The answer is anything that is fixed, known, defined, and of a huge volume can be done less expesively with a custom ASIC (like a playstation or x-box -- although they used the IBM PPC, too). Also anything that does not need the massive parallel processing power a FPGA can deliver can probably be done cheaper by your uP. So, when a uP just can't handle it (like thousands of simultaenous convesations being received by a base station), that is where FPGAs shine, Austin http://www.xilinx.com/company/success/ kubik wrote: > I'm a beginner in this field so forgive me if what seems interesting > for me can seem stupid for others. > I'm approaching the fpga field cause i' ve read many times that the > fpga can reduce the time to market and reduce the costs of the system > for low volume applications. > Surfing on the web i can find easily PC-104 platform for more or less > 100$ that have a 300MHz cpu clock etc etc. > If i search for an fpga board with the same price i will never reach > comparable performance, or quantity of hardware. > So i would like to know which are the markets or the applications where > an fpga can represent a real gain or be necessary.? > > Are there useful only for that application where the performance is > not a goal? > > Are there useful only for research and prototyping?Article: 77509
I'm a beginner in this field so forgive me if what seems interesting for me can seem stupid for others. I'm approaching the fpga field cause i' ve read many times that the fpga can reduce the time to market and reduce the costs of the system for low volume applications. Surfing on the web i can find easily PC-104 platform for more or less 100$ that have a 300MHz cpu clock etc etc. If i search for an fpga board with the same price i will never reach comparable performance, or quantity of hardware. So i would like to know which are the markets or the applications where an fpga can represent a real gain or be necessary.? Are there useful only for that application where the performance is not a goal? Are there useful only for research and prototyping?Article: 77510
starfire wrote:
> I'm having a problem printing the state machine generated using Xilinx IDE
> 6.3.03i to a Samsung ML-1740 printer. The text of the state machine prints
> but the bubbles of the states and the connecting lines do not print.
Maintaining graphic design sources is a lot of effort
for the few lines of generated code that results.
Consider sketching in your notebook and then
writing your own synth and sim code.
-- Mike Treseler
Article: 77511"kubik" <jackgroups@interfree.it> schrieb im Newsbeitrag news:pan.2005.01.08.19.52.30.244039@interfree.it... > I'm a beginner in this field so forgive me if what seems interesting > for me can seem stupid for others. > I'm approaching the fpga field cause i' ve read many times that the > fpga can reduce the time to market and reduce the costs of the system > for low volume applications. > Surfing on the web i can find easily PC-104 platform for more or less > 100$ that have a 300MHz cpu clock etc etc. So what do you think a 300 MHz CPU can do?? Clock speed isn't everything. A function (algorithm) that may require a 300 MHz CPU can be done in a small 100k gates FPGA running at 50 MHz, consuming only a fraction of power that the CPU requires. > If i search for an fpga board with the same price i will never reach > comparable performance, or quantity of hardware. ??? To say such things, you need a deep(er) understanding how things work. How a function is implemented in a CPU and a FPGA. THEN!!! you can compare. But we all know too good, that so wannabe engineers or marketing or whatever gus just compare some numbers. Hmmm . . . . > So i would like to know which are the markets or the applications where > an fpga can represent a real gain or be necessary.? OK, speaking of my daily work, we use FPGAs to -- connect more or less complex interfaces between ASICs -- implement "advanced" glue logic in digital systems, ranging from plain chip select decoders, over FIFOs, Bus converters etc. -- data encoding/decoding -- ASIC replacement for "old" ICs > Are there useful only for that application where the performance is > not a goal? Define performance. This can be processing power, power consumption, density, time-to-market, development risk/costs. For my company, ASICs are not possible for all the high level glue logic, FPGAs are the only way to do is economical. > Are there useful only for research and prototyping? No, but definitely nice there. Regards FalkArticle: 77512
Howdy kubik, > I'm a beginner in this field so forgive me if what seems interesting > for me can seem stupid for others. > I'm approaching the fpga field cause i' ve read many times that the > fpga can reduce the time to market and reduce the costs of the system > for low volume applications. > Surfing on the web i can find easily PC-104 platform for more or less > 100$ that have a 300MHz cpu clock etc etc. > If i search for an fpga board with the same price i will never reach > comparable performance, or quantity of hardware. Never? Here is but one link: http://www.xilinx.com/prs_rls/silicon_spart/0477_s3starterkit.htm But I suspect that wasn't really your question. The answer to your question is that you need to outline your application, and then determine what the best solution for your application is. If you need a general purpose, software programmable device, chances are you want a microprocessor or microcontroller. If you need to do a lot of signal processing, perhaps you want a DSP. > So i would like to know which are the markets or the applications where > an fpga can represent a real gain or be necessary.? For such a generalized question, I can offer only a generalized answer: FPGA's make sense in any application that there is not already a HIGHLY specialized, high volume chip. Said another way, it seems like you are taking FPGA's, which are hardware devices that can be made into almost anything, and comparing them against a software programmable processors, which are actually highly specialized devices designed to run a few hundred software instructions and nothing more. > Are there useful only for that application where the performance is > not a goal? Absolutely not. Performance is all about how something is designed. Let's play with your 300 MHz number and assume that is as fast as an FPGA can go (which is no longer true... we have a little bit of logic running over 600 MHz). How many of those clock cycles does it take a software processor to perform an operation? 3? 6? more? With an FPGA you have the power to perform an operation every clock cycle if you'd like. And if you need more processing power or throughput, you can make your busses wider, or you can do more parallel processing. Let's say you want to take ten 1 GbE ports and aggregate them up to a single 10 GbE port. An FPGA can do it with ease while a software programmable processor would be swamped with even 1 Gbps, much less then. But guess what, there are highly specialized, high volume chips to do this too... so the FPGA may not be the right choice unless you are wanting to do some other custom stuff. > Are there useful only for research and prototyping? Absolutely not. They are used in an numerous commercial applications... everything from HDTV's to cars to communications systems to aircraft, and everything between. Have fun, MarcArticle: 77513
kubik wrote:
> Surfing on the web i can find easily PC-104 platform for more or less
> 100$ that have a 300MHz cpu clock etc etc.
If you can find a board that does
you need for $100 dollars, buy it,
don't redesign it.
> If i search for an fpga board with the same price i will never reach
> comparable performance, or quantity of hardware.
I expect that that PC-104 platform board
has an fpga on it also.
Comparing the price of a low-volume
development board to the price of a commodity
product is not reasonable.
> So i would like to know which are the markets or the applications where
> an fpga can represent a real gain or be necessary.?
FPGAs are necessary when your job is
to design and produce 1K to 100K boards,
that do *not* already exist, and
finish before your competitors do.
-- Mike Treseler
Article: 77514
Trying to download the webpack from the xilinx server, but again the
message:
Important: To access ISE WebPACK, please use a JavaScript-enabled
browser version equal to or greater than IE 4.0 or Netscape Navigator 4.7.
appears, and nothing happens. I did't change my PC configuration since last
download 2 month ago. However some microsoft updates were installed
automatically.
Java2 Platform edition is installed.
I'm using W2k with IE6 and Mozilla 1.7.3.
Thanks for any hints
MIKE
Article: 77515Bret Wade wrote: > Brian Drummond wrote: > >>> This discrepancy between the original grid and the placement grid is >>> what causes problems when an RPM is not placed in the correct slice >>> type. There are inherent problems anyway wrt shifting logic across >>> CLB boundaries in something other than full CLB increments. >> >> >> >> That may be part of what my test case is exposing. >> >> Incidentally I DID find a recommmendation to place RPMs such that they >> began at R0C0 in the answers database ... but it went on to say "this >> problem will be fixed in 4.2"! > > > This sounds as though you've searched the Answer Archive and found an > old obsolete Answer Record. If not and that's an active Answer Record > please let me know what the number is. Some aspect of this problem > probably was fixed in version 4.2. It's always a challenge to write an > Answer Record that won't be misapplied to similar but different problems. > > Here's one that is applicable to your situation: > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=17217 > > >>> Yes, normalization needs to be taken into account even when there is >>> only one component grid involved if you are using RLOC_ORIGIN. If you >>> don't calculate an offset to compensate for normalization, then the >>> macro won't get placed where you expect it. >> >> >> >> Oh I calculate an offset. The problems are that the tools appear to >> modify that offset in undefined ways or ignore them. > > > I took a look at your test case and do agree that there is some > unexpected behavior resulting from the normalization of your negative > RLOC constraints. Focusing on the macro "I1/hset", You have a number of > instances RLOC'd into column 0 beginning with X0Y0, so far so good. Then > you have some instances RLOC'd to X-2Y8, X-4Y8 and X-5Y8. > > The first two don't cause a problem because they are S0 slices. The last > one does cause a problem because it's an S3 slice and the normalization > pushes every thing else into the wrong slice type. If I disable that > RLOC with the following UCF constraint, the macro starts behaving like a > good citizen again: > > INST "I1/int_delay1" USE_RLOC=FALSE ; # LUT2 at X-5Y8 > >> >>>> Strictly speaking the placer ignores the MACRO LOCATE constraints >>> >>> >>> The placer doesn't often ignore LOCATE constraints. It's more likely >>> that you are just getting unexpected results because of the >>> normalization issue. Note the difference between your RLOC_ORIGIN and >>> the resulting LOCATE constraint. That difference is due to >>> normalization. >> >> >> >> Possible, but I would expect the placer report (.par) file to contain >> "RESOLVED that <x> be placed at <y>" messages, but I only get 6 for 8 >> constraints (this file is included in the testcase), and the >> normalisation for the other two was X20Y22 and X18Y-12, for modules 6x9 >> in size. Seems unlikely that this is just normalisation. >> >> The other 6 were placed within a couple of CLBs of the expected >> location, I am trying to reconcile the differences with what you have >> told me about normalisation. > > > I looked at this and found a messaging issue. All eight macros were > locked, but the "RESOLVED" messages only listed five of them. Note that > there are three macros missing from that list and three macros that > generate the following warning about alignment: > > WARNING:Place:206 - This design contains an RPM macro for which a > specific alignment on the CLB grid was desired. The macro can not be > aligned in this specific way. The placer will disregard this alignment. > > >> >>>> This may be the problem, but I don't see why the limitation exists. >>>> Hand placement of the same components onto the other slice types >>>> (again, >>>> excepting SRL16s in "odd X" locations) seems to work fine, though not >>>> placement of RPMs. >>> >>> >>> The best way to illustrate this is to manually place RPMs in FPGA >>> Editor using different slice types. >> >> >> >> part of this exercise has been to see how far I could get with the free >> tools and the S3/1500, but now I'm convinced it's time to upgrade. > > > I can understand that. I have a Linux PVR project going at home. > > Regards, > Bret Brian, I've looked at these issues closer and found that there are indeed two tool bugs. First the RLOC_ORIGIN of the RPM was being incorrectly translated into a Macro Locate constraint by MAP. Second the Placer was ignoring the bad LOCATE constraint, although it was printing a warning. Happily, both problems are already fixed for version 7.1i. Meanwhile to work around the issue, you can modify the macro (as mentioned above) or you could manually fix the macro constraint in the PCF file. You can make the PCF fix permanent by moving the corrected PCF constraint below the "SCHEMATIC END" line, remove the UCF constraint, and then use the existing PCF as input to map. Map will rewrite the PCF, saving everything below the "SCHEMATIC END" line. I still stand by what I said previously about normalization, but I was incorrect to assume that it applied to your macros which don't require normalization since the X0Y0 slice is the reference comp. The reference comp is the lower left most comp, with lower beating out left most in this case. Regards, BretArticle: 77516
On Fri, 07 Jan 2005 16:47:03 -0700, Bret Wade <bret.wade@xilinx.com> wrote: >> Incidentally I DID find a recommmendation to place RPMs such that they >> began at R0C0 in the answers database ... but it went on to say "this >> problem will be fixed in 4.2"! > >This sounds as though you've searched the Answer Archive and found an >old obsolete Answer Record. Yes, re-checking it (13684), I see "Status:Archive", I had found it on a "whole site" search and hadn't noticed that before. >Here's one that is applicable to your situation: >http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=17217 Incidentally, a minor "wish" would be that searching the answers database for 17217 returns Answer Record 17217. OK, I can edit URLs, but... >I took a look at your test case and do agree that there is some >unexpected behavior resulting from the normalization of your negative >RLOC constraints. [...] >The first two don't cause a problem because they are S0 slices. The last >one does cause a problem because it's an S3 slice and the normalization >pushes every thing else into the wrong slice type. Yes, it's a pathological example! I will look at how USE_RLOC=FALSE changes the behaviour. This was suggested as the (partial) solution to another problem. >>>>Strictly speaking the placer ignores the MACRO LOCATE constraints >>> >>>The placer doesn't often ignore LOCATE constraints. >> Possible, but I would expect the placer report (.par) file to contain >> "RESOLVED that <x> be placed at <y>" messages, but I only get 6 for 8 >> constraints (this file is included in the testcase), and the >> normalisation for the other two was X20Y22 and X18Y-12, [...] >I looked at this and found a messaging issue. All eight macros were >locked, but the "RESOLVED" messages only listed five of them. Note that >there are three macros missing from that list and three macros that >generate the following warning about alignment: > >WARNING:Place:206 - This design contains an RPM macro for which a >specific alignment on the CLB grid was desired. The macro can not be >aligned in this specific way. The placer will disregard this alignment. I agree there are three "Place:206" warnings, which don't count as ignoring constraints in my book - however, they apply to three of the (6, not 5) "RESOLVED" constraints. The two remaining MACRO LOCATE constraints (for I1 and I5) have neither "RESOLVED" nor "ERROR" nor Place:206 warning. As seen in the PAR report in the test case (from 6.3sp2). Which PAR version are you using? >> part of this exercise has been to see how far I could get with the free >> tools and the S3/1500, but now I'm convinced it's time to upgrade. > >I can understand that. I have a Linux PVR project going at home. Though i have to say for free tools, and for the price of the Spartan-3 development kit (Avnet PCI) it does astonishingly well... PVR - what's that, if I may ask? - BrianArticle: 77517
On Sat, 08 Jan 2005 16:19:24 -0700, Bret Wade <bret.wade@xilinx.com> wrote: looks like my last message crossed with this one... >Brian, > >I've looked at these issues closer and found that there are indeed two >tool bugs. First the RLOC_ORIGIN of the RPM was being incorrectly >translated into a Macro Locate constraint by MAP. Second the Placer was >ignoring the bad LOCATE constraint, although it was printing a warning. It still looks to me that the Place:206 warnings are NOT about the "ignored" constraints but 3 that had been "RESOLVED" earlier in the placer and later discovered to be wrong. These ones only move a little step to the right (+/-1 slice), not the huge jump (to the left?) I mentioned earlier. Any light you can shed on the missing 2 (I1 and I5?) If you're getting results different to the ".par.saved" file, which PAR are you using? >Happily, both problems are already fixed for version 7.1i. Excellent! Which will be out ... when? The other issue has been acknowledged as a bug, it'll be my third CR on the floorplanner. >Meanwhile to >work around the issue, you can modify the macro (as mentioned above) or >you could manually fix the macro constraint in the PCF file. I've been modifying PCF constraints as a last resort only. >You can make the PCF fix permanent by moving the corrected PCF >constraint below the "SCHEMATIC END" line, remove the UCF constraint, >and then use the existing PCF as input to map. Map will rewrite the PCF, >saving everything below the "SCHEMATIC END" line. aha! another "trick of the trade" to file away in case I need it... >I still stand by what I said previously about normalization, but I was >incorrect to assume that it applied to your macros which don't require >normalization since the X0Y0 slice is the reference comp. The reference >comp is the lower left most comp, with lower beating out left most in >this case. That was maybe why I was getting confused... I didn't dare try a test case with the reference comp _off_ X0Y0! Maybe one day when I get some time... I know all this may seem like nitpicking... but I've always pretty much used "pushbutton mode" in the past, and re-pipelined if I didn't quite meet targets. This is an exercise to see how much better results I can get from floorplanning, without changing my VHDL coding style to any great extent. I've tried floorplanning in the past (3.1 era!) but while it's looked OK for individually instantiated elements (as per Ray Andraka's classic approach) it got ugly pretty fast from regular VHDL. But the tools seem to have come along to the point where it _almost_ works, though I miss the "Congestion" plot in the old 3.1 floorplanner! Modulo these bugs, (and others I won't mention because I can work round them) and my slow learning... Up till now I've been spending more time trying to get the tools to behave (or looking at it the other way, learning which buttons NOT to touch!) than working, but I can take a substantial block, say several hundred components, (fairly) quickly floorplan it, RPM it, and black box it in the higher levels. If you're floorplanning, hierarchy is your friend... These larger blocks are easily 50% faster than the "pushbutton" flow achieves. Combining several of these into a larger RPM gave some difficulty at first, but seems to work with care. Assembling the whole lot into a completed design without losing some of that extra speed is another matter. So far. But 50% extra speed for (eventually, I hope!) little extra work is pretty worthwhile... - BrianArticle: 77518
> Important: To access ISE WebPACK, please use a JavaScript-enabled >browser version equal to or greater than IE 4.0 or Netscape Navigator 4.7. I generally run with javascript turned off. I just tried to download webpack. Seemed to work OK. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 77519
And to close this issue Installing the Quartus II V4 sp2 resolved the crash and identifies the problem. gmArticle: 77520
Brian Drummond wrote: > On Sat, 08 Jan 2005 16:19:24 -0700, Bret Wade <bret.wade@xilinx.com> > wrote: > > looks like my last message crossed with this one... > > >>Brian, >> >>I've looked at these issues closer and found that there are indeed two >>tool bugs. First the RLOC_ORIGIN of the RPM was being incorrectly >>translated into a Macro Locate constraint by MAP. Second the Placer was >>ignoring the bad LOCATE constraint, although it was printing a warning. > > > It still looks to me that the Place:206 warnings are NOT about the > "ignored" constraints but 3 that had been "RESOLVED" earlier in the > placer and later discovered to be wrong. These ones only move a little > step to the right (+/-1 slice), not the huge jump (to the left?) I > mentioned earlier. > > Any light you can shed on the missing 2 (I1 and I5?) > If you're getting results different to the ".par.saved" file, which PAR > are you using? If I fix all of the MACRO LOCATE statements by hand editing the PCF to lock them to the closest S0 slice, I get the following in the .par file: Resolved that macro <I6/hset> must be placed at site SLICE_X20Y20. Resolved that macro <I8/hset> must be placed at site SLICE_X40Y20. Resolved that macro <I1/hset> must be placed at site SLICE_X10Y10. Resolved that macro <I3/hset> must be placed at site SLICE_X30Y10. Resolved that macro <I5/hset> must be placed at site SLICE_X10Y20. Resolved that macro <I2/hset> must be placed at site SLICE_X20Y10. Resolved that macro <I7/hset> must be placed at site SLICE_X30Y20. Resolved that macro <I4/hset> must be placed at site SLICE_X40Y10. If I change the LOCATE constraint for I1/hset back to SLICE_X9Y10,6.3i will ignore the constraint and I only have seven "Resolved" messages. If I run 7.1i PAR, I get a hard error message with a detailed description of why that constraint won't work. This indicates to me that the bad LOCATE constraints are the root of the problems. 7.1i MAP no longer generates the bad constraints and 7.1i will correctly reject them. > > >>Happily, both problems are already fixed for version 7.1i. > > > Excellent! Which will be out ... when? Currently scheduled for FCS in early March. > > The other issue has been acknowledged as a bug, it'll be my third CR on > the floorplanner. > > >>Meanwhile to >>work around the issue, you can modify the macro (as mentioned above) or >>you could manually fix the macro constraint in the PCF file. > > > I've been modifying PCF constraints as a last resort only. > > >>You can make the PCF fix permanent by moving the corrected PCF >>constraint below the "SCHEMATIC END" line, remove the UCF constraint, >>and then use the existing PCF as input to map. Map will rewrite the PCF, >>saving everything below the "SCHEMATIC END" line. > > aha! another "trick of the trade" to file away in case I need it... Yes. We were just discussing in a meeting the other day about how obsolete this keyword is and whether it should be changed. > > >>I still stand by what I said previously about normalization, but I was >>incorrect to assume that it applied to your macros which don't require >>normalization since the X0Y0 slice is the reference comp. The reference >>comp is the lower left most comp, with lower beating out left most in >>this case. > > > That was maybe why I was getting confused... I didn't dare try a test > case with the reference comp _off_ X0Y0! Maybe one day when I get some > time... > > I know all this may seem like nitpicking... Not at all. > > but I've always pretty much used "pushbutton mode" in the past, and > re-pipelined if I didn't quite meet targets. This is an exercise to see > how much better results I can get from floorplanning, without changing > my VHDL coding style to any great extent. > > I've tried floorplanning in the past (3.1 era!) but while it's looked OK > for individually instantiated elements (as per Ray Andraka's classic > approach) it got ugly pretty fast from regular VHDL. > > But the tools seem to have come along to the point where it _almost_ > works, though I miss the "Congestion" plot in the old 3.1 floorplanner! > Modulo these bugs, (and others I won't mention because I can work round > them) and my slow learning... > > Up till now I've been spending more time trying to get the tools to > behave (or looking at it the other way, learning which buttons NOT to > touch!) than working, but I can take a substantial block, say several > hundred components, (fairly) quickly floorplan it, RPM it, and black box > it in the higher levels. If you're floorplanning, hierarchy is your > friend... > > These larger blocks are easily 50% faster than the "pushbutton" flow > achieves. > > Combining several of these into a larger RPM gave some difficulty at > first, but seems to work with care. Assembling the whole lot into a > completed design without losing some of that extra speed is another > matter. So far. > > But 50% extra speed for (eventually, I hope!) little extra work is > pretty worthwhile... > > - Brian > Glad to hear you're seeing some good results. BretArticle: 77521
On Sat, 08 Jan 2005 22:43:37 -0700, Bret Wade <bret.wade@xilinx.com> wrote: >Brian Drummond wrote: > >Brian Drummond wrote: > >> It still looks to me that the Place:206 warnings are NOT about the >> "ignored" constraints >> Any light you can shed on the missing 2 (I1 and I5?) >If I fix all of the MACRO LOCATE statements by hand editing the PCF to >lock them to the closest S0 slice, I get the following in the .par file: >Resolved that macro <I1/hset> must be placed at site SLICE_X10Y10. as expected... >If I change the LOCATE constraint for I1/hset back to SLICE_X9Y10,6.3i >will ignore the constraint and I only have seven "Resolved" messages. If >I run 7.1i PAR, I get a hard error message with a detailed description >of why that constraint won't work. Excellent news again! >This indicates to me that the bad >LOCATE constraints are the root of the problems. 7.1i MAP no longer >generates the bad constraints and 7.1i will correctly reject them. I had no doubt the constraints were responsible ... but it's not obvious why they are "bad". What I was trying to understand in simple terms, with this test case, is that hand placement "works" for six of the eight possible alignments (4 out of 4 LUT/FF, 2 out of 4 LUT/SRL16/FF) and the failures are easily understood. Yet placement by RLOC_ORIGIN can't reproduce this, and I'm still not clear why not. OK, there are differences (temporarily) down to tools issues, but - beyond that - why not? I naively expected that the mapper would be transparent to RLOC_ORIGIN, (=> MACRO LOCATE) and the placer, in expanding the macro, would translate each BEL appropriately (e.g. for a shift right, S0 -> S1 and S1 -> X+1.S0 rather than X.S2), only failing if that BEL didn't exist (e.g. no SRL16 in S1) or some other conflict occurred. i.e. if it can be done by hand, why don't the tools do it? Or, if it can't be done, why did the hand placement get through PAR? Possible answers are a) "7.1 does exactly that" ... in which case, great! b) "It's a pointless exercise that might satisfy naive floorplanner users but adds complexity and/or bugs to the placer without improving packing or performance" is probably an acceptable answer, but IMO needs health warnings in the floorplanner manual! c) "There's a fundamental flaw you overlooked" ... ok, but where? I thought normalisation might have been it, but apparently not. d) "The simpler translation (S0->S1, S1->S2) is better because" ... from which there's probably something useful to learn about floorplanning. e)??? >> Excellent! Which will be out ... when? >Currently scheduled for FCS in early March. Time to pre-order... >Glad to hear you're seeing some good results. And I'm very glad to hear ... coming back to topic ... that the RPM toolflow is only going to improve. - BrianArticle: 77522
On Sat, 8 Jan 2005 23:02:47 +0100, "M.Randelzhofer" <techseller@gmx.de> wrote: >Trying to download the webpack from the xilinx server, but again the >message: > > Important: To access ISE WebPACK, please use a JavaScript-enabled >browser version equal to or greater than IE 4.0 or Netscape Navigator 4.7. I think there are two ways to download on the website. One is some kind of automatic installer. I had no luck with that one, using Mozilla (Firefox). But the other is a single (240MB) file, to download and install later, and that worked fine for me. Of course, it tied up the phone line for about 18 hours ... - BrianArticle: 77523
kubik <jackgroups@interfree.it> wrote: >I'm a beginner in this field so forgive me if what seems interesting >for me can seem stupid for others. >I'm approaching the fpga field cause i' ve read many times that the >fpga can reduce the time to market and reduce the costs of the system >for low volume applications. >Surfing on the web i can find easily PC-104 platform for more or less >100$ that have a 300MHz cpu clock etc etc. >If i search for an fpga board with the same price i will never reach >comparable performance, or quantity of hardware. The $100 CPU board can do some problems better and easier than the $100 FPGA board: http://www.xilinx.com/products/spartan3/s3boards.htm Then again, for some problems, the $100 FPGA board can blow the doors off that $100 CPU board. The difference is the problem, and how the algorithm is written to solve it. Here is an example that is just a bit overblown: Remember that CPU's do one thing at a time. Some instructions take one clock cycle, some may take more. So a problem might look like: Multiply. Add. Divide. If (this thing) then (do something). FPGAs can do many things at the same time in a pipeline. That is, each function is designed to take one input and deliver one output per clock cycle. While it takes multiple clocks to get the first answer, each answer after that arrives one clock cycle later. Note this will allow the FPGA to do this problem faster than the CPU: Multiply. Add. Divide. If (this thing) then (do something). Also, the $100 FPGA board has twelve multipliers. That means we could do many things in parallel: Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). Multiply. Add. Divide. If (this thing) then (do something). In this example, the CPU takes multiple clocks (5 or more) to produce one answer. The FPGA produces twelve answers per clock. Sure, the CPU's clock is twice as fast. The CPU takes five (or more) instructions to produce an answer. The FPGA is producing 12 answers per clock. The result is the FPGA is producing 30 times more answers per second. There are several reasons why this example is overblown and oversimplified. The first is that it would be a hard problem to get enough data into and out of the FPGA to keep such a calculation supplied with data. The CPU has a similar problem. The second is that I'm not that all this logic would all fit into a 3S200. Might need settle for only 4X to 10X faster than the CPU. Which is very important for some problems, and doesn't matter at all for others. >So i would like to know which are the markets or the applications where >an fpga can represent a real gain or be necessary.? DSP, high speed real time, networking... >Are there useful only for that application where the performance is >not a goal? In my experience, at least, FPGAs are mostly used for applications where performance is the goal. >Are there useful only for research and prototyping? They are useful for that as well. -- Phil Hays Phil-hays at posting domain (- .net + .com) should work for emailArticle: 77524
Attention all gurus, I have a general question regarding constraints and asynchronous interfaces. How do you specify details like "offset in before" when you really have no idea when the signals will be arriving. I ask only because I have an asynchronous interface that I need to get working at a higher frequency and I feel that the only problem lies in the fact that I can't tell the tools that I need this block to meet certain speeds using constraints. I'm new at the constraints aspect of things other than using the basic "period" constraint. Details are: Asynchronous device is a uP running at 40 MHz, I have a set of read/write 32 registers (32 bits wide) that are setup in the FPGA (Spartan II xc2s150 device speed rating is a 5) running at 100 MHz. All transfers where the uP reads from the registers are working perfectly, however the occasional write transfer is not (maybe 1 out of 50 on average). Chip select, write, read, address, and data lines are all the lines that I have available. Thanks Jason jberringer at the domain sympatico dot ca
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