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
Michael A. Terrell wrote: > It was either do the work or be fired. I didn't do it to help him, > in any way. I needed the job, because there was nothing else available > in my field at the time. The only open job I could find was chief > engineer at WRGT TV, Ch 45 in Dayton, Ohio which was an even longer > drive. They were only offering minimum wage for a 40 hour a week > salary, and you would be on call 24/7. They also demanded that I live > no more than 2 miles from the studio and transmitter sites which didn't > have any reasonably priced homes. Would you take a loss on the sale of > your home and buy one at five times the price, while taking a 70% cut in > pay? I couldn't, and I didn't. I just suffered though another of his > messes, and made a lot in overtime. Hopefully it'll even out. The higher ups will probably be aware of the extra overtime they needed to spend to solve this problem. Ideally they'll know who to blame for the problem. Often if you care for the overall health of the company, you need to solve a crisis and in so doing bail out some incompetent. C'est la vie. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108351
hi i was thinking hardwired reset of device sets up via reset and set as a i2c microprocessor, which serial loads from something like a 256Kbit (or larger) 24AA256/24LC256/24FC256 EEPROM. after the load, the circuit is clocked in to configure the fpga, and it provides automatic on chip i2c interface. which along with a few fast comparator inputs, and some RAM blocks, LUTS and a few mul blocks would be a nice two chip solution for many applications. having a manufacturer specific load up chip with resulting larger area may not be good for an efficient bootstrap, and you loose the option to have user code and data in the EEPROM, and a high level macro specification of the logic interconnect. having such a low cost standard boot would be a boon for fpga demand. cheers. p.s. don't forget the electron bolus on chip which extracts power potential from inward spiral corriolis acceleration of high mobility electrons in n-type spiral, using substrate zener effect for voltage stabilization. (They work better when smaller)Article: 108352
David, http://www.itrs.net/ It is a bit hard to swallow, but if you really are interested, you have to read their entire plan (conspiracy theory is a good analogy -- it really is a plain in view world wide conspiracy!). And, not just Xilinx must follow: the equipment Intel, ST Micro, TI, IBM, UMC, TSMC, etc all buy comes from the same "roadmap." If it isn't in the roadmap, well, it has no support, and eventually, it will not exist. Now, that may be too harsh, as some technology variants (such as 3-D circuits, a la Matrix Semi, purchased by SanDisk) did make use of the existing roadmap, with some minor tweaks. Even there, is this profitable? The jury is still out. As for what to invest in? Wow. As an engineer I made a rule for myself: let someone else do the investing! My judgment in that regard has been proven to be absolutely TERRIBLE. Any engineer who thinks they are a good investor, I haven't seen one yet! It is hard enough to stay current and be an expert in what I am supposed to be an expert in, let alone deciding to be an expert in something unrelated. Good luck, AustinArticle: 108353
David Ashley wrote: > > Michael A. Terrell wrote: > > It was either do the work or be fired. I didn't do it to help him, > > in any way. I needed the job, because there was nothing else available > > in my field at the time. The only open job I could find was chief > > engineer at WRGT TV, Ch 45 in Dayton, Ohio which was an even longer > > drive. They were only offering minimum wage for a 40 hour a week > > salary, and you would be on call 24/7. They also demanded that I live > > no more than 2 miles from the studio and transmitter sites which didn't > > have any reasonably priced homes. Would you take a loss on the sale of > > your home and buy one at five times the price, while taking a 70% cut in > > pay? I couldn't, and I didn't. I just suffered though another of his > > messes, and made a lot in overtime. > > Hopefully it'll even out. The higher ups will probably be aware of the > extra overtime they needed to spend to solve this problem. Ideally > they'll know who to blame for the problem. > > Often if you care for the overall health of the company, you need to > solve a crisis and in so doing bail out some incompetent. > C'est la vie. > > -Dave > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architecture That was 20 years ago, and Ernie was forced to quit over sexual harassment charges, filed by then current and former female employees. I always worked my ass off at any job. The big bosses weren't stupid. When major problems go away right after someone new is hired, they know it's not a long term employee who suddenly started working harder, smarter, or both. After the sudden changes the owner came for a visit to see what had happened. Of course, Ernie tried to take the credit. The owner turned to me and said, Great! Now tell me exactly what you did to fix the problems Ernie couldn't. I described what I had done to take us from the lowest customer service rated CATV system in the area, to the number one in under six months. Ernie was quite pissed! -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 108354
Antti, I am sure that there are those who try to make money by buying and selling (called "horse traders" in English). And I am sure that they are a headache for just about anyone who is trying to meet all their obligations, warranties, etc. as a supplier. Even more of a headache if you are trying to buy from one. As for what is legal, and what is not, I will leave that to the lawyers (as it varies by country, region, etc.). I am not a lawyer. My only point was that if someone did find a source of Xilinx FPGAs, not through an authorized distributor, the "worst" that can happen is that they get bogus parts. The best that can happen, is that they really are as marked, and they work. Our only concern is that if someone wants to send one back on an RMA for analysis and replacement, they will get a "gee, you have been had" if it turns out to be a part from someone else, with its markings sanded off, and counterfeit Xilinx markings painted on...(something I have seen!). If it is our part, but it has passed out of the authorized chain of control (we do check on RMAs), then we can not honor the warranty. 'Pop-corn' packages are often the result of mis-handling as I described, and we are not going to replace the parts under warranty! AustinArticle: 108355
Austin Lesea schrieb: > Antti, > > I am sure that there are those who try to make money by buying and > selling (called "horse traders" in English). And I am sure that they > are a headache for just about anyone who is trying to meet all their > obligations, warranties, etc. as a supplier. Even more of a headache if > you are trying to buy from one. > > As for what is legal, and what is not, I will leave that to the lawyers > (as it varies by country, region, etc.). I am not a lawyer. > > My only point was that if someone did find a source of Xilinx FPGAs, not > through an authorized distributor, the "worst" that can happen is that > they get bogus parts. The best that can happen, is that they really are > as marked, and they work. > > Our only concern is that if someone wants to send one back on an RMA for > analysis and replacement, they will get a "gee, you have been had" if it > turns out to be a part from someone else, with its markings sanded off, > and counterfeit Xilinx markings painted on...(something I have seen!). > If it is our part, but it has passed out of the authorized chain of > control (we do check on RMAs), then we can not honor the warranty. > 'Pop-corn' packages are often the result of mis-handling as I described, > and we are not going to replace the parts under warranty! > > Austin so PLEASE PLEASE open up again online shop :) for those who are in a hurry to get prototypes done! AnttiArticle: 108356
> > Analyzing file TestApp_Peripheral/executable.elf... > WARNING:MDT - Elf file TestApp_Peripheral/executable.elf does not > reside > completely within BRAM memory of processor microblaze_0. > WARNING:MDT - The sections of ELF residing outside BRAMs must be > initialized > separately using a debugger, a bootloader, or an ACE file > INFO:MDT - BRAM lmb_bram will be initialized with ELF of processor > microblaze_0 This means that your program is bigger than the amount of BRAM you have. So you have store your program in external memory. TestApp_Peripheral is usually bigger than TestApp_Memory, so it is not surprising that one fit into BRAM while the other doesn't. To fix this you should create a design with external memory, and generate a linker script where you say that all sections reside in external memory. Then download the program to external memory and run. For how to use ethernet, take a look at some of the examples here: http://www.xilinx.com/ise/embedded/edk_examples.htm -SivaArticle: 108357
Austin Lesea schrieb: > And, not just Xilinx must follow: the equipment Intel, ST Micro, TI, > IBM, UMC, TSMC, etc all buy comes from the same "roadmap." Actually the semiconductor roadmap is the best example of a selffulfilling prophecy that I ever encountered. It is a widely accepted estimate of how fast semiconductor technology will progress. The cost with semicon manufacturing is almost completely in R&D and building the fab and the livetime of a technology node is very short. This means that progressing faster than the competitors is EXTREMELY expensive. For beeing faster you need more R&D and at the same time you have less time to pay for the R&D of your previous technology. On the other hand, beeing slower than you competitors can also be very expensive because the same chip can be manufactured cheaper in the newer technolgy and at the same time will be faster. This situation is similar for many technologies, and technology progress will vary from company to company because nobody knows the speed of the competitors. But for semicon the costs are extreme, and there is this convenient roadmap that everybody seems to have agreed on. For that reason semiconductor progress is more or less in sync between all manufacturers. Kolja SulimmaArticle: 108358
David Ashley wrote: > KJ wrote: > >>Would be workable/advisable to instead just have each device > >>control the ddr itself, and use the ddr's own interface directly? > >> > > > > Probably not. Arbitration by nature needs 'global' knowledge of the scope > > of what it is arbitrating in order to be effective: Some things needed are > > - It needs to know about the 4 (or however many) users > > - Preferred burst sizes for each port > > - How long the other ports should wait while they're waiting for their turn > > (i.e. how important is latency). > > - Arbitration scheme (round robin, etc.) > > KJ > > The arbitration is separate from the interface. We may not be meaning the same thing when we say 'interface'. In your example, you have four 'users' who need to share a common resource, the DDR. Maybe you're seeing this as all one 'interface' but in reality it consists of several of what I would call 'interfaces'. One way to approach this problem would be to use a single DDR controller code and arbitrate access to the input. In that scenario you would have 11 interfaces: #1-4 are the individual master interfaces out of each of the four 'users'. #5-8 are the individual slave interfaces that are single, individual targets of #1-4. #9 is a single master interface that connects to #10. #10 is the slave side interface of a DDR controller code. #11 is the master side interface from your DDR controller that is intended to hook up to the actual DDR itself. The task then would be to... - Implement the function Arb() performs the translation from interfaces #5-8 to create #9. - Connect up all of what are now point to point connections. Now, there is some function that I'll call f() that implements whatever is necessary to go from interface #10 to interface #11. Presumably this is simply the OpenCores DDR controller or some other commercial controller. In any case, those cores all fit the basic interface structure that I've defined above to get from #10 to #11. They don't fit mapping more than one input to the DDR directly. What I thought you were suggesting is that you take this function f() and replicate it 4 times and then add the arbitration between the outputs of those four f() functions before applying it to the physical DDR and putting this code in with the four users. You could implement it this way, but if you do I'm confident that you'll be chewing up many more logic resources than you would if you instead focused on creating the arbitration function Arb() which performs the magic to connect interfaces #5-8 to interface #9. > Wishbone probably already > has an arbitor capability built in, I'd guess. Guess again. Wishbone is strictly a point to point interface. By that I mean that it simply defines the signals to/from the master, the signals to/from the slave and how those signals accomplish data transfer. The logic for multiple masters off a slave or multiple slaves off of a master is outside of the Wishbone specification. What Wishbone brings to the table is a common interface. This is handy since by my definition of 'interface' that are 11 of them in play...with the exception of #11, all can be Wishbone or any other standard you want to code to. Wishbone doesn't bring a lot of baggage so that IF you need to have multiple masters/slaves that you don't have cumbersome extra logic. Altera's 'Avalon' and OpenCores 'SimpCon' interfaces are all similar in that regard. They are all point to point but can be used in a multi-master/multi-target system quite easily. My point was that, viewed in this light, the arbitration function which connects #5-8 to #9 can be both somewhat generic (i.e. could be used to arbitrate other devices besides DDR) and yet still be parameterized to handle the pecularities for your particular application (i.e. bursting whenever possible to DDR). <snip> > Actually the arbitration logic is not really *in* the chain, it just > selectively allows the USER to access the next stage on the other > side. Again, considering what I consider to be an 'interface' puts this directly into the chain. If you go the route of implementing multiple f() functions inside the four users you still end up with the same 11 interfaces but now some of them are buried inside each of the four users so they are only going away in the sense that you're drawing the border line around a slightly bigger area. Now you would have four 'users' that do not have native Wishbone interfaces but instead have a native DDR interface that then needs to be arbitrated and translated into the same final output interface to the DDR. > > It's critical that bursts be handled well. DDR effectively has a minimum > burst of 2, and the 2 addresses are always at A and A+1. Probably A > is even also, but I don't remember at the moment. > > Also a burst within DDR can't cross a row. Then there is arbitrary > CAS latency. > > Wishbone supports bursting, but there probably aren't any restrictions. > That is, bursts probably don't need to start on an even address, and > they don't have to end before they cross some arbitrary boundary. > Still using the approach that I suggested, all of that can be handled with the Arb() function as well. > But I can easily make the 4 users of the DDR work within the DDR's > limitations. At the expense of now making those 4 users tuned specifically to the nuances of DDR. If you migrate this to some other memory technology then you have to retune each of these four for the new nuances of that memory. > With the wishbone approach I get a generic piece of logic I can reuse > with other DDR's. But at what cost? Good question. I can't really give details, but I'll say that I've implemented the approach that I mentioned for interfacing six masters to DDR and the logic resources consumed were less than but roughly comparable to that consumed by a single DDR controller. I had all the same issues that you're aware of regarding how you need to properly control DDR to get good performance and all. The Arb() function that I implemented is also paramterized so that I could use it to interface effectively with a PCI bridge as well without changing any code (only the parameter settings when instantiating the entity). > > Complications: > 1) To support bursting, it needs to have some sort of fifo. An easy way > would be the core stores up the whole burst, then transacts it to the > DDR when all is known. I'd suggest keeping along that train of thought as you go forward but keep refining it. > But to reduce latency, the DDR transaction > probably ought to start while the USER is still pushing data into the > wishbone interface. The whole goal is to get as close to 2 memory > accesses per clock, since that's what DDR supports. Here is where Wishbone lets you down a bit. There was a discussion on this newsgroup called 'JOP on Avalon' or something like that. It was primarily between myself and two others where we discussed the relative merits of Wishbone, Avalon and SimpCon. You might want to peruse that a bit since with Wishbone you have to go a bit outside of the normal spec by using what Wishbone calls 'tags' to get the full performance on the DDR. It's not really violating Wishbone, it's just not built into it as cleanly as it is with Avalon or (from my limited knowledge of) SimpCon. The issue is that 'tags' are not required to be implemented in any specific way but Wishbone has sort of set aside a particular way of tagging that will help you get the full performance. The key in any of this though is the realization that the address phase and the data phase of any transaction are independent. A master device can initiate a second command on the address bus even before the first has completed. Even if you're not considering Altera's Avalon as a bus for your design, their documentation of that bus and how those two phases of a bus cycle are treated is very good and worth the read. Pay attention to the section regarding 'slave side read latency' and then compare that to Wishbone. It's good reading and may give you a somewhat different perspective and can certainly help with this arbitration function even if you don't implement using Avalon. > > 2) The wishbone core must deal with page crossing bursts somehow. Nope, that's up to the arbitrator...if it has been given the knowledge of the concept of 'bursts' and further parameterized by 'burst sizes' and 'address boundaries'. > This would mean breaking up a burst into 2 ddr bursts. Otherwise > if I impose address/burst restrictions on the wishbone core, it's > not 100% compliant, I'd expect. Shouldn't need to go that way though....crossing a page boundary should at worst cause wait states on the user's master side if it is hammering memory. If the user is lightly touching it then it shouldn't even cause that. > > The disadvantages of involving wishbone are > 1) More complicated, more work, later time to market > 2) Almost certainly will introduce latency in pipeline > 3) To implement, I've got to learn wishbone AND ddr, > as opposed to just ddr now and perhaps wishbone at > a later date. > > The advantages are > 1) Single logic driving DDR pins, so supposedly clock timing can > be met easier. > 2) More general for code reuse, since lots of things already > support wishbone. > It will probably consume more logic resources your way which could impact price. > > Also of note that the end result of all this is a system meant > to be released as open source. That's why if I were going to > use wishbone I'd feel compelled to do it right. Guess I'm confused a bit. If it's needs to be 'open source' than it would seem that standarding on Wishbone would be a good thing and having tuned the 'users' to a DDR interface would be less flexible. This might be just a case of where you draw the boundary around the 'box'. Maybe from the perspective of someone using your widget they don't care directly about 'user1'...'user4' just that there are 4 of them and they can all talk to DDR and whether or not you use a standard interface to implement them is about as relevant as whether you code your state machines in the 'two process' template or the 'one process' template. What I've found though is that using a logically complete handshaking protocol does not impose much if any extraneous logic resource usage, and using that protocol even on internal interfaces that nobody really cares about is actually an aid in getting everything debugged and workng properly with the added benefit being that other people can more readily understand those internal interfaces (if needed) since it conforms to an established protocol. > > Anyway it still isn't clear to me the wishbone approach is > automatically right for this particular application. > It may not be given your particular constraints. > Thanks for everyone's input on this so far. > You're welcome. Good luck on your design KJArticle: 108359
Hi, In article <45007526$0$21146$7a628cd7@news.club-internet.fr>, jfhasson@club-internet.fr says... > Hi, > > I work on a board with an Altera 7128S part (5V quite old but still used > ...). It seems the part is most of the time working just fine but > depending on when it is powered on it overheats a lot and does not seem > to be well configured : an input acts as an output, and the component is > not working fine at all. Does anyone havea clue as to what could be > going wrong ? It does not happen all the time. I read some errata from Altera's site about a MAX3k family. I had a MAX3128 do something like what you're experiencing -- it was a power sequencing issue. As someone else suggested, check the power sequence and perhaps avoid driving the 7128S's inputs if it's not fully up yet. John.Article: 108360
hi in/out busses: low-master, high-master, bottleneck-chain and you would need three instances. cheersArticle: 108361
I agree with Kolja and Austin: technology moves ahead synchronously and on rails, and everybody has access to the same technology. That makes creative architecture and circuit design an ever more important distinction between us competitors... Long live creative ideas, for they are not shackled by the roadmap! Peter Alfke, Xilinx ========================== Kolja Sulimma wrote: > Austin Lesea schrieb: > > > And, not just Xilinx must follow: the equipment Intel, ST Micro, TI, > > IBM, UMC, TSMC, etc all buy comes from the same "roadmap." > > Actually the semiconductor roadmap is the best example of a > selffulfilling prophecy that I ever encountered. > It is a widely accepted estimate of how fast semiconductor technology > will progress. > > The cost with semicon manufacturing is almost completely in R&D and > building the fab and the livetime of a technology node is very short. > This means that progressing faster than the competitors is EXTREMELY > expensive. For beeing faster you need more R&D and at the same time you > have less time to pay for the R&D of your previous technology. > > On the other hand, beeing slower than you competitors can also be very > expensive because the same chip can be manufactured cheaper in the newer > technolgy and at the same time will be faster. > > This situation is similar for many technologies, and technology progress > will vary from company to company because nobody knows the speed of the > competitors. But for semicon the costs are extreme, and there is this > convenient roadmap that everybody seems to have agreed on. > For that reason semiconductor progress is more or less in sync between > all manufacturers. > > > Kolja SulimmaArticle: 108362
<dhruvakshad@gmail.com> wrote in message news:1157728453.205266.321290@d34g2000cwd.googlegroups.com... >I am using virtes II pro pci card .The card has a pci bridge with a bus > linking processor in the bridge to the fpga. The constraints on the > processor bus signals were givent by the vendor. My design gives me a > negative slack on 2 of the signals on the processor bus. Will this > affect the design ? I am doing dma from the fpga to the host RAM along > the bus. The transfer rate is low. > I was googling for links to read on negative slacks but could not find > good ones for a starter. Not knowing what tool you're using that is reporting the slack makes it impossible to be certain but the basic defintion of 'slack is roughly.... 'Slack' is the amount of time you have that is measured from when an event 'actually happens' and when it 'must happen' .. The term 'actually happens' can also be taken as being a predicted time for when the event will 'actually happen'. When something 'must happen' can also be called a 'deadline' so another defintion of slack would be the time from when something 'actually happens' (call this Tact) until the deadline (call this Tdead). Slack = Tdead - Tact. Negative slack implies that the 'actually happen' time is later than the 'deadlin' time...in other words it's too late and a timing violation....you have a timing problem that needs some attention. KJArticle: 108363
Hi all, can a FPGA work like a microprocessor ? If yes upto what extent ? Please suggest.Article: 108364
Hi! I've tried to explore the BPI (Byte Peripheral Interface) configuration mode on the Spartan-3E starter kit without success. I've followed the "EDK Flashwriter.ppt" I got from Xilinx and I've managed to burn uClinux images and bin-files anywhere I want in the StrataFlash, but my Spartan-3E Starter boards (rev c) never configure themselves from the Intel StrataFlash device: - I have strapped MODE(2:0) to "010" (BPI/UP) as well as "011" (BPI/DOWN). - I have stored my BIN-files generated from my bit-files with the "promgen -p bin -c FF -o output.bin -u 0x0 input.bit" and "promgen -p bin -c FF -o output.bin -d 0xFFFFF input.bit" commands at offset 0x2000 (BPI/UP) as well as offset 0xFBAA9F (BPI/DOWN) in the StrataFlash. - When I configure the FPGA with bit-files via JTAG the MicroBlaze starts executing the bootloader application from internal BRAM, moving the uClinux image from the StrataFlash to the DDR SDRAM and then starts to execute from there, but this never succeeds with my design stored in StrataFlash. There is a small CPLD (XC2C64) on the board connected to XC-A(23:20), XC-DONE, etc. I believe this device has to drive A(24:20) high or low during FPGA configuration in order to have the FPGA fetch the bitstream from the top/bottom of the StrataFlash. I don't have access to sourcecode for this CPLD, but obviously have relied on it to do it's job. I guess that the question is if it does so on a std revC Spartan-3E Starter board? I've read the S3E/StrataFlash article (http://www.xilinx.com/publications/xcellonline/xcell_54/xc_pdf/xc_strata54.pdf) and compared to the Spartan-3E Starter schematics: It appears as if the S3E-kit has too weak pulldown (4.7 kohm instead of 340 ohm) on the LDC2 signal so that the StrataFlash might not have time to swap between *16 mode to *8 mode (takes up to 1000 ns) before the S3E starts to fetch data from it. However both workaround #2 and #3 ought to make sure that the FPGA configures once it finds the right "initialization sequence". Regarding the configrate setting I haven't changed it since I believe that the default configrate=6 => 1,5 MHz should be ok with the 110 - 150 ns accesstime of the StrataFlash. I guess that offset 0x2000 and 0xFBAA9F applies for XC3S500E devices. What offset values applies for XC3S1200E and XC3S1600E devices ..... or can I use almost any offset in the StrataFlash since an S3E-device in BPI-mode will search the StrataFlash until it finds the right "initialization sequence" and then successfully configure from there? The board: http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3E-SK-US I'm using EDK8.2i (SP1) and ISE8.2i (SP2) and Rev C boards. Please help.Article: 108365
Some FPGA's like the Xilinx Virtex-4 (FX - PowerPC) come with a hard(always there) processor within the programmable fabric. There are also soft core microprocessors that use the general FPGA fabric for their implementation like MicroBlaze. In both cases the microprocessor cores generally can do what their standalone equivalents can do. The difference comes in that unused FPGA fabric can be used to implement the any digitial function or interface you like within the bounds of the device size and speed. Some interfaces will need external buffering depending on the voltage levels e.g. a transceiver for CAN bus. The one weak area is replacing a microcontroller that has analogue interfaces. Currently there is virtually no analogue support in FPGA's so any analogue functions like A to D tend to need add on devices. John Adair Enterpoint Ltd. Srinu wrote: > Hi all, can a FPGA work like a microprocessor ? If yes upto what extent > ? Please suggest.Article: 108366
I found the discussion "Why No Process Shrink On Prior FPGA Devices" interesting and would like to add some words regarding working stability of devices with shrinked geometry: Beeing a consultant engineer, I work for various companies and in different fields of application and thus often come across problems with modern devices like RAM, FPGA and MCUs regarding their stability: One can observe that smaller process geometrie quickly leads to a lower tolerance against beam- and radiation influences, causing e.g. EMC problems. Therefore, some companies have to spend much time and money in searching for devices which are resistant enough to meet their requirements. Doing so, "older" families of devices with a larger scaling are sometimes prefered! Do we run into problems when continously shrinking technologie and finally remove older devices (her maybe FPGAs) from the market ?Article: 108367
Free S1 core with Linux tools (gcc) emu runs on iverilog: http://www.srisc.com/?s1 This is a RISC with 64 bit address and data bus, and Wishbone intereface. Have not tried it, may be of interst to some here. <quote> The OpenSPARC T1 microprocessor (codename Niagara) features 8 SPARC CPU Cores and several peripherals; the S1 Core takes only one 64-bit SPARC Core from that design and adds a Wishbone bridge, a reset controller and a basic interrupt controller, to make it easy for a system engineer to integrate the design. <end quote>Article: 108368
"Antti" <Antti.Lukats@xilant.com> wrote: >Austin Lesea schrieb: > >> Antti, >> >> I am sure that there are those who try to make money by buying and >> selling (called "horse traders" in English). And I am sure that they >> are a headache for just about anyone who is trying to meet all their >> obligations, warranties, etc. as a supplier. Even more of a headache if >> you are trying to buy from one. >> >> As for what is legal, and what is not, I will leave that to the lawyers >> (as it varies by country, region, etc.). I am not a lawyer. >> >> My only point was that if someone did find a source of Xilinx FPGAs, not >> through an authorized distributor, the "worst" that can happen is that >> they get bogus parts. The best that can happen, is that they really are >> as marked, and they work. >> >> Our only concern is that if someone wants to send one back on an RMA for >> analysis and replacement, they will get a "gee, you have been had" if it >> turns out to be a part from someone else, with its markings sanded off, >> and counterfeit Xilinx markings painted on...(something I have seen!). >> If it is our part, but it has passed out of the authorized chain of >> control (we do check on RMAs), then we can not honor the warranty. >> 'Pop-corn' packages are often the result of mis-handling as I described, >> and we are not going to replace the parts under warranty! >> >> Austin > >so PLEASE PLEASE open up again online shop :) >for those who are in a hurry to get prototypes done! It would be even better if Xilinx would supply all of their devices through distributors like Farnell, Digikey, etc, etc, etc. I prefer to buy from these type of companies (one stop shopping) or manufacturors directly. Distributors usually aren't any cheaper when you buy large quantities. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108369
Digikey do have some Virtex-4 and Spartan-3. They are even a reasonable place to buy Platform Flash. There are a number of grey market suppliers. We get them regularly trying to sell to us but do take heed of Austin's comments in the previous post. As to legal the biggest problem is actually export control regarding onward shipping. This is especially true if you are a company that either is US based or has subsiduary within US control. If you fall foul of EAR (someone please in the exact words) there can be very severe finacial penalties and I believe even jail for office holders. Not supplying to the wrong persion or organisation does take some sorting out. There is a document, in very small text and 500 pages or so, of names of people and organisations that are deemed dubious to supply anything to. John Adair Enterpoint Ltd. Nico Coesel wrote: > "Antti" <Antti.Lukats@xilant.com> wrote: > > >Austin Lesea schrieb: > > > >> Antti, > >> > >> I am sure that there are those who try to make money by buying and > >> selling (called "horse traders" in English). And I am sure that they > >> are a headache for just about anyone who is trying to meet all their > >> obligations, warranties, etc. as a supplier. Even more of a headache if > >> you are trying to buy from one. > >> > >> As for what is legal, and what is not, I will leave that to the lawyers > >> (as it varies by country, region, etc.). I am not a lawyer. > >> > >> My only point was that if someone did find a source of Xilinx FPGAs, not > >> through an authorized distributor, the "worst" that can happen is that > >> they get bogus parts. The best that can happen, is that they really are > >> as marked, and they work. > >> > >> Our only concern is that if someone wants to send one back on an RMA for > >> analysis and replacement, they will get a "gee, you have been had" if it > >> turns out to be a part from someone else, with its markings sanded off, > >> and counterfeit Xilinx markings painted on...(something I have seen!). > >> If it is our part, but it has passed out of the authorized chain of > >> control (we do check on RMAs), then we can not honor the warranty. > >> 'Pop-corn' packages are often the result of mis-handling as I described, > >> and we are not going to replace the parts under warranty! > >> > >> Austin > > > >so PLEASE PLEASE open up again online shop :) > >for those who are in a hurry to get prototypes done! > > It would be even better if Xilinx would supply all of their devices > through distributors like Farnell, Digikey, etc, etc, etc. I prefer to > buy from these type of companies (one stop shopping) or manufacturors > directly. Distributors usually aren't any cheaper when you buy large > quantities. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108370
Further, The hard IBM 405 PowerPC in Virtex II Pro, and Virtex 4 is optimized for low power, not for high speed. Generally speaking, the FPGA will get hot from doing all of the other things it needs to do, that having a uP on the same die requires that uP to be low power, not super high speed. The soft uP (PicoBlaze, MicroBlaze) which is a uP optimized to be built from the fabric of the Xilinx architectures is optimized for area, and speed. But the area may be reasonably small, the the performance is perhaps 4 or 5 times slower than the hard processor, and many times slower than a speed optimized uP in its own package. Regardless, since the 405 PowerPC exisits as up to two cores in a single part, and you may stuff as many PicoBlazes, or MicroBlazes as will fit in a part, the need for performance or speed may be addressed by multiprocessing. However, if there is something needed to be done fast, then use of the raw gates to implement a massively parallel logic solution is superior. For example, a uP DSP program may be able to execute 100 times faster in logic, as opposed to on the uP. Interfacing to the uP is done with the auxiliary processor unit interface (build your own coprocessor to do exactly what you need) on the Virtex 4 FX parts. In the earlier parts, the hardened functions can be added to the interface buses (but are not as fast as the APU bus). Generally speaking, if a uP solves the problem, then it is unlikely you would consider a FPGA. The reason to use a uP in a FPGA must have some other justification. For example, an automotive electronics supplier decided that providing maintenance for a new uP every year (that is subsequently obsoleted in less than 5 years) was far more expensive thaqn using an entirely soft uP solution in a Spartan device. Speed is no issue, cost is no issue (in fact the Spartan device soft processor combined with other functions they required was similar in per socket cost). This way the design is in HDL and c code, and can be ported to any new FPGA. And we also maintain a supply for our components for much much longer than the merchant uP industry. We have supplied components for 20 years before last time buy notices. Austin Austin John Adair wrote: > Some FPGA's like the Xilinx Virtex-4 (FX - PowerPC) come with a > hard(always there) processor within the programmable fabric. There are > also soft core microprocessors that use the general FPGA fabric for > their implementation like MicroBlaze. > > In both cases the microprocessor cores generally can do what their > standalone equivalents can do. The difference comes in that unused FPGA > fabric can be used to implement the any digitial function or interface > you like within the bounds of the device size and speed. Some > interfaces will need external buffering depending on the voltage levels > e.g. a transceiver for CAN bus. > > The one weak area is replacing a microcontroller that has analogue > interfaces. Currently there is virtually no analogue support in FPGA's > so any analogue functions like A to D tend to need add on devices. > > John Adair > Enterpoint Ltd. > > Srinu wrote: > >>Hi all, can a FPGA work like a microprocessor ? If yes upto what extent >>? Please suggest. > >Article: 108371
Todays generation of FPGAs are significantly better than yesteryears in beam and radiation tolerance. As geometries shrink, the EMC toloerance should be improved by smaller "antenna" loop area. Beeeing someone who has seen poor designs in the past hurt by improved chips, are you sure these problems weren't due to shoddy design? alterauser wrote: > I found the discussion "Why No Process Shrink On Prior FPGA Devices" > interesting and would like to add some words regarding working > stability of devices with shrinked geometry: > > Beeing a consultant engineer, I work for various companies and in > different fields of application and thus often come across problems > with modern devices like RAM, FPGA and MCUs regarding their stability: > One can observe that smaller process geometrie quickly leads to a lower > tolerance against beam- and radiation influences, causing e.g. EMC > problems. Therefore, some companies have to spend much time and money > in searching for devices which are resistant enough to meet their > requirements. Doing so, "older" families of devices with a larger > scaling are sometimes prefered! > > Do we run into problems when continously shrinking technologie and > finally remove older devices (her maybe FPGAs) from the market ?Article: 108372
Hello All,
I am writing a VHDL design for a Xilinx FPGA using
ISE ver 8.2.02i (8.2 SP 2) and I'm trying to get
post-map simulating correctly now that I have
post-translate simulating correctly. I put "keep"
attributes on every single signal, including those
in the ports (editor keystroke macros help a lot).
I also ran the following command line in a command
(DOS) window: (just run the following three lines
together with spaces at the line breaks; it is a
copy from the DOS window): Note the added -u to
try to prevent logic removal, which is why I had
to run this in the command window; it's not
available as a setting in map properties.
map.exe -ise ppcaesh.ise -intstyle ise -p xc4vfx12-ff668-10 -cm speed
-detail
-pr b -k 4 -c 100 -u -o user_logic_map.ncd user_logic.ngd
user_logic.pcf
I have the map optimization now set for speed in
my project, reflected in this command. I tried
setting "no optimization" as well as all the other
optimization choices. The above command made the
post map files for me. Now, at least all the red
is gone from Post-Map simulation and some of the
bytes are right in my first section of output. I
think this is due to all the "keep" attributes I
added. My removed "redundant logic" list was made
a little smaller. Here is the syntax for "keep":
signal mysignal : std_logic; -- declare a signal
attribute keep : string; -- you just need this once
-- then you can do the next line for each signal you want.
attribute keep of mysignal : signal is "true";
-- this goes in the architecture section after the signal
declarations and
-- before the "begin".
(Thanks to the thread "Looking for ways to keep
diagnostic signal from being optimized out
(Xilinx)" here in comp.arch.fpga)
This syntax is found in the Constraints Guide,
cgd.pdf.
Here is a partial list of the removed logic:
Section 5 - Removed Logic
-------------------------
Optimized Block(s):
TYPE BLOCK
GND XST_GND
VCC XST_VCC
Redundant Block(s):
TYPE BLOCK
LOCALBUF u0/my_sub_mod_128_0_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_10_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_12_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_11_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_13_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_14_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_15_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_16_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_17_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_18_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_19_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_1_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_20_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_21_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_22_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_23_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_24_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_25_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_26_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_27_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_28_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_29_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_2_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_30_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_31_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_3_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_4_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_5_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_6_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_7_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_8_xo<1>1/LUT3_D_BUF
LOCALBUF u0/my_sub_mod_128_9_xo<1>1/LUT3_D_BUF
LUT1 myrst_inv1
LUT1 dcnt_Msub__sub0000_xor<0>11
INV Bus2IP_Clk_inv_INV_0
LOCALBUF Mxor__xor0019_Result1/LUT3_L_BUF
LOCALBUF Mxor__xor0055_Result1/LUT3_L_BUF
LOCALBUF Mxor__xor0127_Result1/LUT3_L_BUF
LOCALBUF Mxor__xor0083_Result1/LUT3_L_BUF
LOCALBUF user_logic_010_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_012_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_014_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_018_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_019_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_01_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_020_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_022_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_023_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_024_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_028_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_02_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_032_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_033_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_035_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_036_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_039_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_03_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_040_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_043_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_044_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_045_xo<2>1/LUT4_L_BUF
LOCALBUF user_logic_046_xo<2>1/LUT4_L_BUF
etc... (93 more lines)
As you can see from this list from the file
user_logic_map.mrp in the project directory, there
is still logic being removed. The optimized blocks
are still removed if you set "no optimization" and
the "redundant" blocks are still being removed
even with -u "Do Not Remove Unused Logic" command.
Could we have a "Do Not remove Any Logic" option?
-and have the "no optimization" setting respected
fully (when set)?
The key, I have learned, is to use the correct
Xilinx VHDL style, which is different for FPGAs
and ASICs. Once you follow that, you won't have
any more problems. Can someone advise me on this
correct syntax from this list of "optimized" and
"redundant" logic? Meanwhile I am reading the
xst.pdf manual, section on VHDL style to try some
things. The style to avoid latches I already used,
which really worked. Also the style to clock ROMs
so that they won't be optimized away as
asynchronous RAMs I already used, which did the
trick in post- translate.
Best regards,
-James
Article: 108373alterauser, On the contrary, the smaller geometries also result in a smaller cross section, and less probability of upset. The "problem" is that the device size may shrink, but then people put on more devices! Thus, the susceptibility to upset MUST (by design -- there are ways to lessen the cross section that designers need to use now, and geometry) be kept smaller than the increase in memory or logic size. For example, if at 0.15u, you have ~365 FIT/Mb for the configration memory (real numbers, by the way, for Virtex II xc2v6000), and the device is ~ 20 Mb, that makes for a total of 365 X 20 = 7300 failures per billion hours (really upsets, not every upset causes a "failure" so it is better than that --- see all the stuff we have on SEUs on our website). Then, at 90nm, we have ~50 FIT/Mb for the configuration memory (again, real number), but we now have 60 Mb for the largest device (xc4vfx140, or xc4vlx200). That is again 50 X 60 = 3000 FIT/device. Bottom line, we are "winning" the race to reduce soft failures due to cosmic ray upsets faster than the technology allows more density. This is the Xilinx pledge: we MUST get better faster than the shrink allows us to get worse. And, if you problem is solved by a 2V2000, or 2VP20, or 4VLX25, then your actually failure rates per device are getting much smaller, as these devices are all about the same density. Virtex 4 is ~ 6 to 8 times better than Virtex II in soft error failure rate (less failures). Then, as a totally different subject, there is "Total Dose" which is only a concern to devices that experience ionizing radiation all the time (medical equipment, nuclear reactors, space, etc.). Total dose is an area I really don't want to talk about. The total dose issue is a bit touchy, as the US governement realizes that most (perhaps all) 90nm technology is very tolerant of total dose, and they need to change their rules in order to deal with reality. I suggest you do some research, and follow up with RADECS, SELSE, MAPLD, and other conferences, and the papers that are being published. EMI/RFI was not, and is not an issue in terms of affecting the devices as far as I am able to learn. We have our FPGAs in MRI machines, and railroad engine controls: both extreme magnetic and electric field applications. Just don't create a loop in the external pcb wiring that is a problem, and the device takes care of itself (too small!). The rest of the industry is having a hard time keeping their soft failure rate below 1,000 FIT/Mb, so that is why we are so willing to publish our results. Austin (virtexicdesigner)Article: 108374
I guess the most obvious question I would have for you first off is "Why are you bothering with this?" Let the tool do it's job which is to turn VHDL/Verilog design source files into the properly formatted bitstream needed to program the device. Don't waste your time trying to prevent the tool from optomizing your code...trust me even the best code written by an experience person can be optomized to target a specific device. I realize that doesn't address your question, just thought I'd save you what seems to me to be a fruitless exercise on your part. KJ
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