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
"Austin Lesea" <austin@xilinx.com> wrote in message news:dochlk$85d5@xco-news.xilinx.com... > jg, > > I'll probably regret putting in my 2 cents, but here goes: > > > It is true that "significant gains" are still (often, not always) realized > by some careful hand placement, and some careful partitioning. > > That suggests that the design languages lack something important, as the > intent of the designer is not being communicated to the tools. <snip> I appreciate the quality of the tools over where they were years ago. I regularly curse the software, however, because the design intent that "I want to achive 200 MHz performance" can make it through the synthesis tools after some coaxing but ends up coming through the place & route software with brain-dead 2.5 ns nets on both sides of a single LUT. This is the extreme example of when good routes go bad. I've tried to push the idea that a "critical path routing" approach can make the designs run as fast as n-levels of logic with appropriate primitive-specific delays can go. The tool shows no signs that it looks at what is possible before deciding how to throw everything together. My opinion is that the process of mapping separate from place & route is archaic (to use kind words) and that spreading the logic out so each slice has just one LUT is *not* the way to alleviate the problem. The tools should have the intelligence to unbundle and rebundle unrelated logic as necessary to keep the logic "tight" (delays low) even in a low-utilization design. The tools *can* do so much more; the evolutionary development of the tools has hampered true progress. The silicon is *amazing* in what can be accomplished. "Pushing the rope" to improve results with synthesis is bad enough. Having place & route software that can't understand what it takes to produce good results every time is sad. I can pass with total timing compliance then lose by 1.5 nanoseconds after changing non-critical logic. I prefer not to curse my tools. Respectfully, - John_HArticle: 93426
Reza - I suggest you do some studying on your own rather than asking this group to design your circuit. On your tri-state question, try Google "verilog tristate", then do some reading. John ProvidenzaArticle: 93427
Sanjay, if you are talking about Look-Up-Table logic, there is no difference between the approaches. In your case of three inputs, abc, you must define the output for all 8 possible input codes in the Table (or call it a ROM). Whether you think of "consensus" has no relevance. LUT logic is a brute-force implementation. You get no glitch on the output when you change one input, (well, you may get a change, but no glitch !) and you also get no glitch when you change two inputs, provided all 4 permutations of these two iputs create the same output (not true in your specific example). Peter Alfke, Xilinx ApplicationsArticle: 93428
Anshat wrote: > iam new this grp sole reason to join this group is that i am finding > myself unable to find a suitable algorithm for the mouse . I have > P89LPC922 microcontroller This isn't really the right newsgroup for algorithms for microcontrollers. > i am contantly searching net for an algorithm > to solve maze but it only gives me a hint towards Bellmans algorithm. I did a Google search for "Bellman's algorithm", and the first several hits had useful information on it. I wasn't previously aware of Bellman's algorithm. It appears that this algorithm is only going to help you if your software already has a complete map of the maze. For instance, if such a map is provided in advance, or if your mouse has a vision system that can see the whole maze from above. Otherwise you're much better off using a conventional search algorithm. Surely your instructor provide you some advice on algorithms? Even if not, developing a maze-solving algorithm is not hard. It can be as simple as tracking where you've already been and what choices have been tried, choosing randomly whenever you have a new choice, and backtracking when you reach a dead end. What kind of sensor information your mouse gets also influences the type of algorithm you would want to use.Article: 93429
Jim Granville wrote: > Jon Elson wrote: > >> >> > > Maybe tiny Zilog really does have Microchip scared - but I would > have thought Microchip could safely ignore Zilog, and find many better > areas for their energies and funds ? Zilog is actually bigger than a lot of people realize. They are not terribly big in microprocessors, (they once were) but they sell a LOT of network interface chips and such stuff. > >> But, the guys who invented the intermitent windshield wiper >> and the capillary blood sample tube both went to their graves after 20+ >> years of litlgation, only to win the cases AFTER they died! > > > Examples like these serve to confirm that patents are simply feeding > troughs for lawyers. Yeah, I used to know what the legal fees racked up in these cases were, and they were ASTRONOMICAL! A complete travesty. There are THOUSANDS of wildly invalid patents on all sorts of things, including perpetual motion machines cleverly disguised under different names. JonArticle: 93430
Antti Lukats wrote: > the only FPGA with hardcore processor and PCIe capabilities is the xilinx > Virtex4FX, Altera PCIe ready devices do not have hardcore processors Virtex II Pro devices also have PPCs and are PCI-E capable. (Good luck getting a V4-FX :) ) JeremyArticle: 93431
On Wed, 21 Dec 2005 22:44:22 GMT, "John_H" <johnhandwork@mail.com> wrote: >My opinion is that the process of mapping separate from place & route is >archaic (to use kind words) and that spreading the logic out so each slice >has just one LUT is *not* the way to alleviate the problem. Yes. Xilinx has added "map -timing" to do just that. Mappping logic is now with placement, and the result works rather better. -- Phil HaysArticle: 93432
Can anyone who have it share it?Article: 93433
John, I'm just trying to use the usenet as a resource to learn. In reading other sources, it seems that I could output a 'z' in order to achieve a tri-state -- however, as I've found out, there is a lot of strange behaviour in actually going from verilog syntax to application and implementation. I wanted to see if there were any gotcha's in this approach. I also wanted to know if it was possible for a physical input to read 'z' if I configure the microcontroller's pin as an input (putting it in tri-state), or if I would have to add another pin (say, enable_Z) to specify when I want the output to be equal to 'z'. I'm also not sure about the implementation differences - say, between xilinx and altera, and if one supports a certain mode of opperation that the other does not. I'll do some more googling on verilog and tristate, however, I also find that there are people willing to help answer questions, which I greatly appreciate. I'm not asking anyone to design my circuit - though people have helped with some of the debugging issues which has been invaluable. Another aspect of my questions is trying to understand the strange behaviour. I still don't see why the synthesizer has a problem equating these two constructs : If A do a else do b If !A do b else do a they seem identical to me, and I'll have to do some more research and re-read some of the replies to this thread to try to figure it out. In any case, thanks, RezaArticle: 93434
Both Altera and Xilinx give the ability to look at the RTL schematic which will show you what the synthesizer did with your code. I don't know if the free versions give you this ability???? Your question about whether or not your microprocessor can read a 'z' clearly tells us that you're not an engineer working in industry. "Reza Naima" <google@reza.net> wrote in message news:1135219926.957661.32390@g47g2000cwa.googlegroups.com... > John, > > I'm just trying to use the usenet as a resource to learn. In reading > other sources, it seems that I could output a 'z' in order to achieve a > tri-state -- however, as I've found out, there is a lot of strange > behaviour in actually going from verilog syntax to application and > implementation. I wanted to see if there were any gotcha's in this > approach. I also wanted to know if it was possible for a physical > input to read 'z' if I configure the microcontroller's pin as an input > (putting it in tri-state), or if I would have to add another pin (say, > enable_Z) to specify when I want the output to be equal to 'z'. I'm > also not sure about the implementation differences - say, between > xilinx and altera, and if one supports a certain mode of opperation > that the other does not. > > I'll do some more googling on verilog and tristate, however, I also > find that there are people willing to help answer questions, which I > greatly appreciate. I'm not asking anyone to design my circuit - > though people have helped with some of the debugging issues which has > been invaluable. > > Another aspect of my questions is trying to understand the strange > behaviour. I still don't see why the synthesizer has a problem > equating these two constructs : > > If A do a else do b > If !A do b else do a > > they seem identical to me, and I'll have to do some more research and > re-read some of the replies to this thread to try to figure it out. > > In any case, thanks, > Reza >Article: 93435
Hi We are using Cypress FX2 in our project and we have our own windows(xp & 2000)driver, we are getting a data rate of 73 M Bits/sec without any problem. we have an FPGA interface which pumps data to FX2 fifo, and we are using Bulk data transfer. rgds bpArticle: 93436
Austin Lesea wrote: > > It is true that "significant gains" are still (often, not always) > realized by some careful hand placement, and some careful partitioning. > > That suggests that the design languages lack something important, as the > intent of the designer is not being communicated to the tools. > ... > The software folks here at Xilinx are amazing: they have managed to > improve every generation the performance while reducing the time to > compile the designs; all the while we in IC design follow Moore's law > and double the density. Not to mention we add more custom IP, and > customers are getting more demanding. > Austin, What is missing is geographic relationships between parts of the circuit. Perhaps the biggest piece missing in the current tools is utilization of the hierarchy in a design. The current xilinx tools flatten the design before they even start on the place and route problem, and that greatly increases the workload and time to complete while also degrading performance. The tools have an opportunity to use the hierarchy in the design to treat each hierarchical layer as a mini-design, essentially breaking the problem into smaller problems in a way that is consistent with the way the designer broke up the design. Going to a true hierarchical place and route would improve both the quality of results as well as the run times. Now, I do disagree with your assertion that each generation of the tools improves both run time and quality of results. I have indeed seen improvements in run time, but more often than not the quality of results has taken a step backwards with each major release of ISE. Yes, I suppose for flat RTL only designs, the results have gotten somewhat better, but that is mostly due to large improvements in synthesis, and small incremental improvements in the automatic placement (which BTW, still does a dismal job with placing non-LUT resources, with placing data paths, and with placing logic that has multiple levels of LUTs between FFs). In the mean time, the routing algorithms have gotten lazy, apparently in the interest of speeding up run times. For designs with poor placement, the effects of poor routing are not as apparent as they are for well placed (eg carefully floorplanned) designs. For my floorplanned designs, I have seen a steady erosion in the max speeds attainable by the tools on each new release since 4.1. One of the biggest steps backward came from eliminating delay based clean-up (IIRC that happened in 5.2). The result there is that the tools just stop as soon as all routes meet timing. Every route in the design is potentially a critical route. The routes to nearby destinations often take circuitous routes that congest the routing resources and unnecessarily drive the power dissipation up considerably. With the current emphasis on power dissipation, I would think that the Xilinx team would be looking at reinstituting the delay based clean-up. Based on my empirical observations, that could pick up a 15-20% improvement in power dissipation for designs that are clocked in the upper half of the performance envelope.Article: 93437
Reza Naima wrote: > Before I start replying to people, I was just wondering, how is it > possible such that I can assign a high-impedence state to an output > using the code I wrote? Can I do it using the same number of inputs, > or do I have to add another input and implement it in this way.. > > always @(posedge clear) > out[index] <= z > > or something like that? > > Jason - > > Yep, this did the trick, and managed to piss me off at the same time. > I don't see how this code is logically any different from the code that > I posted! Several people posted about hints and priorities for > coding, but in my reading, I never came across references to these > things. Does anyone have any good pointers or references? > > Ray - > > Is it acceptible to use asynchronous code in fpga's/cpld's if you are > going to be working at very low speeds? I'm not looking for a high > performance design, rather, a super-low-power deisgn that'll save me > pins on a microcontroller. I just want the ability to program one of > 32 outputs using a minimal set of microcontroller pins. > > With regards to switch bouncing, as it'll be switched from a > microcontroller, I dont have to deal with debounce, right? > > Finally, I'm not sure what the reset/startup up hazards are -- I'll do > some googling after I post this. The reset I use is just to reset the > counter to zero. Will this be problematic? > > Generally, you should avoid async logic. By using it, you are making your job a lot harder, and substantially increasing the risk of making a grave design error that may not show up until the device is fielded. Yes, asynchronous designs are possible in FPGAs and CPLDs, but it takes a considerable amount of additional design evaluation and verification effort to make sure you did it right. Often times, it also involves hand routing to maintain control of the path delays, and it certainly includes timing analysis by hand because the static timing tools are not suited to async circuit evaluation. I would certainly strongly discourage someone who is having trouble understanding the advantages of a synchronous design taking an asynchronous approach to the design. The issue is not the speed of the design, it is the numerous hazards present in an async design that are eliminated by synchronous design techniques. The fact that the wires connecting the elements have delay in an FPGA and that delay varies significantly for each routing solution makes the analysis of an async design in an FPGA extremely tedious, error prone, and difficult. As soon as you have to make a modification to the design, you basically have to start over on the analysis. If you don't have time to learn how to do a basic synchronous design, you don't have the time to do the async design properly either. The reset/start up hazards in a synchronous design with async reset is that unless the release of reset is done synchronously, you can't guarantee that all affected logic is going to see the release of reset on the same clock cycle, so it can wind up leaving the reset state in an unknown condition. Your reset to zero is OK as long as you can guarantee all of the counter flip-flops will not be clocked until the set-up times to all the flip-flops have been satisfied. Finally, an FPGA or CPLD is generally NOT suitable for an implantable device. Even the static current greatly exceeds the current draw needed for a reasonable battery life, regardless of what the dynamic currents are in your design. The FPGA or CPLD is fine for a prototype, but not for the actual implant. Finally, if speed is not a consideration and power is, there is no reason you can't make the design synchronous and slow the clock down to the minimum clock you need. A 32KHz digital watch crystal will provide a dynamic power that is barely detectable over the static ICC in most FPGAs and CPLDs. Also, the power savings for an async design in and FPGA is largely a mirage. By using synchronous techniques you take advantage of purpose built structures in the FPGA such as the optimized clock tree and fast logic for carry chains, and other arithmetic. Async logic often has to use LUT resources and general purpose routing instead, and because the routing is actually a network of powered switches, the power dissipation is quite a bit higher than you might expect. Also, there have been papers showing that a heavily pipelined (ie very little logic between flip-flops) design shows significant power reductions (on the order of 20-30%) over the same design with fewer pipeline stages. The difference is the flip-flops stop the propagation of glitches, which in turn dissipates a significant amount of power not only in the logic but also in the active routing resources. I strongly encourage you to take a bit of time to learn synchronous design. I'd pick up a basic logic text such as Morris Mano and start reading up on synchronous logic.Article: 93438
Phil Hays wrote: > On Wed, 21 Dec 2005 22:44:22 GMT, "John_H" <johnhandwork@mail.com> > wrote: > > >>My opinion is that the process of mapping separate from place & route is >>archaic (to use kind words) and that spreading the logic out so each slice >>has just one LUT is *not* the way to alleviate the problem. > > > Yes. Xilinx has added "map -timing" to do just that. Mappping logic > is now with placement, and the result works rather better. The map -timing is still done ONLY in the map phase WITHOUT iterative back & forth with place & route. The attempt is made to group related logic together to get "tighter" logic but this little user-selectable switch doesn't make up for the rest of the problems with disjunct mapper and P&R.Article: 93439
A simple algorithm is to chose one side and just follow that wall. For example if you chose the left side, you put your left hand on the wall and walk, always keeping it on the wall. Eventually you will get to the destination. On average, you'll visit half the maze before reaching it.Article: 93440
Ray Andraka wrote: > Austin Lesea wrote: > >> >> It is true that "significant gains" are still (often, not always) >> realized by some careful hand placement, and some careful partitioning. >> >> That suggests that the design languages lack something important, as >> the intent of the designer is not being communicated to the tools. >> > ... > >> The software folks here at Xilinx are amazing: they have managed to >> improve every generation the performance while reducing the time to >> compile the designs; all the while we in IC design follow Moore's law >> and double the density. Not to mention we add more custom IP, and >> customers are getting more demanding. >> > > > Austin, > > What is missing is geographic relationships between parts of the > circuit. Perhaps the biggest piece missing in the current tools is > utilization of the hierarchy in a design. The current xilinx tools > flatten the design before they even start on the place and route > problem, and that greatly increases the workload and time to complete > while also degrading performance. The tools have an opportunity to use > the hierarchy in the design to treat each hierarchical layer as a > mini-design, essentially breaking the problem into smaller problems in a > way that is consistent with the way the designer broke up the design. > Going to a true hierarchical place and route would improve both the > quality of results as well as the run times. > > Now, I do disagree with your assertion that each generation of the tools > improves both run time and quality of results. I have indeed seen > improvements in run time, but more often than not the quality of results > has taken a step backwards with each major release of ISE. Yes, I > suppose for flat RTL only designs, the results have gotten somewhat > better, but that is mostly due to large improvements in synthesis, and > small incremental improvements in the automatic placement (which BTW, > still does a dismal job with placing non-LUT resources, with placing > data paths, and with placing logic that has multiple levels of LUTs > between FFs). In the mean time, the routing algorithms have gotten > lazy, apparently in the interest of speeding up run times. Hmm.. seems the real world is rather removed from that of Xilinx employees - Engineers should know better than to believe their own marketing fluff ? Peter, What Ray suggests sounds very sensible and not what I'd call "a very unconventioanl way" Austin, perhaps if you used engineering measurements for SW results, rather than the words like "wizards" and "magic", then the SW might have a chance to really improve with each release ? For designs > with poor placement, the effects of poor routing are not as apparent as > they are for well placed (eg carefully floorplanned) designs. For my > floorplanned designs, I have seen a steady erosion in the max speeds > attainable by the tools on each new release since 4.1. Yikes! One wonders how _CAN_ SW make a carefully floorplanned design go backwards ? By how much ? Is that the lazy routing, being so bad, it actually finds a longer path, than earlier SW ? > > One of the biggest steps backward came from eliminating delay based > clean-up (IIRC that happened in 5.2). The result there is that the > tools just stop as soon as all routes meet timing. Every route in the > design is potentially a critical route. The routes to nearby > destinations often take circuitous routes that congest the routing > resources and unnecessarily drive the power dissipation up considerably. > With the current emphasis on power dissipation, I would think that the > Xilinx team would be looking at reinstituting the delay based clean-up. > Based on my empirical observations, that could pick up a 15-20% > improvement in power dissipation for designs that are clocked in the > upper half of the performance envelope. I did wonder how Altera suddenly found power savings in SOFTWARE - perhaps they now do exactly this, clean up messy, but timing legal, routes ? Anyone in Altera comment ? PCB routing software has for years used cleanup and optimise passes, and only rarely (these days) goes outside a bounding rectangle on paths. PCB routers also routinely route the 'most obvious' traces first, and so are very unlikely to go backwards on carefully floorplanned designs. They also allow net priority, where important nets can get first bite at resources. Q: Does Xilinx SW scan floorplanned areas, and tag those nets as (probably) being important, and thus should have first-bite-privilages in Routing ? Given the enomous investment the companies claim, these field results seem rather abysmal - seems the HW is carrying the SW ?. Still, it does seem there is indeed a lot of 'fat' in Place & Route SW, so we can expect further 'double digit improvement' claims.... :) -jgArticle: 93441
"bp" <pbijoy@rediffmail.com> schrieb im Newsbeitrag news:ee92276.11@webx.sUN8CHnE... > Hi We are using Cypress FX2 in our project and we have our own windows(xp > & 2000)driver, we are getting a data rate of 73 M Bits/sec without any > problem. > > we have an FPGA interface which pumps data to FX2 fifo, and we are using > Bulk data transfer. > > rgds bp 73M BITS ???? With the Cesys Spartan3e-500 board we sustained 35MBYTE/second AnttiArticle: 93442
"Jeremy Stringer" <jeremy@_NO_MORE_SPAM_endace.com> schrieb im Newsbeitrag news:43a9f9fa$1@clear.net.nz... > Antti Lukats wrote: >> the only FPGA with hardcore processor and PCIe capabilities is the xilinx >> Virtex4FX, Altera PCIe ready devices do not have hardcore processors > > Virtex II Pro devices also have PPCs and are PCI-E capable. (Good luck > getting a V4-FX :) ) > > Jeremy well, yes both V2P and V4FX are can be used for PCIe when exeternal clock recovery is used. I think Xilinx claimed a little better confirmance to the PCIe spec for Virtex-4, but very strictly taken none of the FPGA serdes currently on market is 100% PCIe specification compliant, some features are missing or out of required range AnttiArticle: 93443
Anyone know why these two smaller CPLDs seem to have vanished from the Xilinx Webstore ? Other parts show 'out of stock' tags, so they do not remove on nil stock, - do they not want these going into new designs ? -jgArticle: 93444
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:43aa55a5$1@clear.net.nz... > Anyone know why these two smaller CPLDs seem to have vanished from the > Xilinx Webstore ? > Other parts show 'out of stock' tags, so they do not remove on nil > stock, - do they not want these going into new designs ? > > -jg > thats weird, XC2C32A are the latest Xilinx PLDs !! So if those are not recommended than nothing is. Doesnt make sense to take them off from online. Xilinx is currently the only company having made no new PLD announcements for some time (except the "A" version of the XC32C32/64), so it makes one really wonder what Xilinx policy about the flash/PLD business is. MAX2 and MachXO are really cool flash-PLDs, or well better to say they are Xilinx XC2K with onchip flash :) Antti Jim we have some XC2C32 in stock if you need some immediatlyArticle: 93445
Hallo, I would to try this core. Where I could find the documentation for 8051 interface? Has anyone ever used it? Many Thanks Marco ToschiArticle: 93446
"Marco" <marcotoschi@nospam.it> schrieb im Newsbeitrag news:dodl6j$nie$1@nnrp.ngi.it... > Hallo, > I would to try this core. Where I could find the documentation for 8051 > interface? > > Has anyone ever used it? > > Many Thanks > Marco Toschi > So go ahead and try. GRLIB from (LEON3 Sparc SoC system) has wrapper around the opencores can and I am sure they have used it. AnttiArticle: 93447
Ray Andraka <ray@andraka.com> writes: > A simple algorithm is to chose one side and just follow that wall. > For example if you chose the left side, you put your left hand on the > wall and walk, always keeping it on the wall. Eventually you will get > to the destination. On average, you'll visit half the maze before > reaching it. Doesn't work if the goal is in an "island" in the maze, which is allowed in most Micromouse rules.Article: 93448
> Anyone know why these two smaller CPLDs seem to have vanished from the >Xilinx Webstore ? > Other parts show 'out of stock' tags, so they do not remove on nil >stock, - do they not want these going into new designs ? A month or so ago, they carried the non-A versions. The data sheet linked to on the same line had a not-recommended-for-new-designs note. I assume they fixed that but adding the -A version fell through the cracks. Anybody know where to get them in small quantities? Digikey doesn't carry any of the CoolRunner parts. (Or any other modern low power CPLDs.) > MAX2 and MachXO are really cool flash-PLDs, or well better to say they are > Xilinx XC2K with onchip flash :) Lattice won't let me see their data sheets without signing up and getting spammed. (The spam might be optional.) -- 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: 93449
Rob, I never asked if a microprocessor could read a 'z', I asked if a CPLD could determine if an input was floating or not - though I doubt it could. And as I've stated, I'm a graduate student, so I'm obviously not working in industry. I take it you like to skim. I found the RTL schematic viewer - though I sitll am not sure what RTL stands for. Reza
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