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
It might work, but not reliably. The problem would be that the logic asserting RESET~ would itself be reset, negating RESET~ at a point when the rest of the chip might not be fully reset. A safer scheme would be to latch the output externally, and have that signal cleared by whatever initiates the re-programming sequence (this all depends, of course, on which mode you use to program the chip!). Regards AndyGArticle: 2251
I wrote:
>I've done this. You can implement a flip-flop in combinatorial logic and run
>your system clock to it to provide a full clock cycle's worth of a reset
>pulse.
>
I got some email responses that indicate that this isn't entirely clear.
Here's an example:
It's possible to implement a flip flop using combinatorial CLB logic instead
of the CLB flip-flop. The equations would looks something like this:
Q1 = RESET_IN + Q1*/(CLK*RESET_OUT)
RESET_OUT = Q1*/CLK + RESET_OUT*(CLK+Q1)
Where:
RESET_IN is a synchronous input that changes on the rising edge of CLK.
RESET_OUT drives your external reset pin.
The timing looks something like this
______ ______
CLK ______/ \______/ \__
__________
RESET_IN _____/ \\____________
______________
Q1 ______/ \\_________
_______________
RESET_OUT ____________/ \\_____
This circuit should be put in a single CLB to avoid race problems on the
transition of CLK.
(Note that Xilinx recommends against this kind of combinatorial logic, but
I've used circuits like this before without problems.)
Article: 2252In article <47t1qh$o7m@manitou.cse.dnd.ca>, Paul Brown <pbrown@cse.dnd.ca> wrote: > I am looking for info on the JTAG standard, mainly how it is used for >testing fpga's etc. I would really like an FAQ on this if possible. Can anyone >point me to the place where this info can be found? > > Thanks in advance for the information. > > > Paul Brown..... I maintain a tutorial on JTAG as one of the chapters in "FPGA Workout II". You can get it from ftp.vnet.net in directory pub/users/xess/FPGA_Workout_II. The tutorial uses a simple DOS hypertext format, so you'll have to use a PC to view it. We will convert it to HTML before the end of the year and place it in our Web site http://www.xess.com. -- || Dave Van den Bout -- XESS Corp. || || 2608 Sweetgum Dr., Apex, NC 27502 || || (919) 387-0076 FAX:(919) 387-1302 || || devb@xess.com devb@vnet.net ||Article: 2253
In article <47riv9$615@news-2.csn.net>, caleb@audiologic.com wrote: > Is it possible to configure a Xilinx 30xx IOB connected to RESET~ > to successfully reset the chip? If so, how? Yes, it is possible to connect an output to the active Low RESET pin of any XC3000 device. There is no problem during configuration, since all outputs ( except LDC ) are held High with a week pull-up resistor. When you come to the end of configuration, the output goes active.The internal reset is being released ( as a configuration option ) either one CCLK period before or one CCLK period after the outputs go active. See page 2-29 of the Xilinx data book. The automatic internal reset and the deliberately applied external RESET ( active Low) have exactly the same internal effect. If you drive the RESET input from a combinatorial circuit inside the chip, you will keep ALL internal flip-flops reset as long as this signal is active, and there is no exception. Do not create a "clever" circuit where the output that pulls RESET Low stops pulling Low as soon as a certain flip-flop has been reset. That is a glitch-maker that might work, but can fail because the propagation delay of the RESET signal going to all the many flip-flops can vary by as much as 25 ns, and you might create an unreliable RESET pulse. For more details and ways around such limtations, send me e-mail at peter@xilinx.com Peter Alfke, Xilinx ApplicationsArticle: 2254
acooney@netcom.com (Alan Cooney) writes :- > I'm seriously considering a BP1148 or BP1200 We have two BP1200 programmers on site and have been very happy with them. Cheers, T.H.Article: 2255
Tim Eccles <Tim@tile.demon.co.uk> writes: >But would it not be relatively straightforward for Xilinx to add a few bytes >of non-volatile public key memory (read/write) plus private key memory (write >only) and implement a small decryption engine. The configuration data rates >are so low that a serial arithmetic scheme should be possible. > >Even a simple system would give a huge increase in design security. It seems like this scheme makes a lot of sense for flash based products. It does not seem so simple for SRAM based FPGAs. --- - Bill Wolf, Raleigh NC - My opinions, NOT my employer'sArticle: 2256
I'd like to learn about field programmable gate arrays. Can someone point me to a good reference/FAQ/www page. thanx brett -- Brett Walker |ork @ mundil.cs.mu.oz.au 5th Year Science/Engineer |ork @ ecr.mu.oz.au University of Melbourne |brettw @ ocf.berkeley.edu $$$$ WWW: http//www.cs.mu.oz.au/~ork $$$$Article: 2257
HORSTINK_HMM (iim@ms.philips.nl) wrote: : Derek Chang (dchang@san-jose.ate.slb.com) wrote: : : What do you mean the design is different ? : : You can do anything with an FPGA that discrete ICs : : can do. : : Derek : Yeah! How about speed ? : Harry The Xilinx 2K, 3K and 4K parts are slower than molasses, compared to fast PLDs or discrete logic. Prop delays of >30nS aren't unusual pad-to-pad, but they aren't really designed for high-speed multiple level logic. They're more fitted for synchronous designs where the logic's clocked stage-to-stage, and the fast stuff is best done outside. For price vs. speed, we use the Altera 7K family for the fast stuff, as it was a good compromise, and the Xilinx parts are for the slower bulk logic since it's cheaper per gate. As usual, your mileage may vary.Article: 2258
In article <9531513.2334@mulga.cs.mu.OZ.AU>, Brett Christopher WALKER <ork@mundil.cs.mu.OZ.AU> wrote: >I'd like to learn about field programmable gate arrays. Can someone >point me to a good reference/FAQ/www page. > We keep a short tutorial at http://www.xess.com. Also, I think the University of Idaho keeps an extensive list of FPGA material on their Web site. There's also an engineering library at http://epims1.gsfc.nasa.gov/engineering/ee.html that should have links concerning FPGAs. -- || Dave Van den Bout -- XESS Corp. || || 2608 Sweetgum Dr., Apex, NC 27502 || || (919) 387-0076 FAX:(919) 387-1302 || || devb@xess.com devb@vnet.net ||Article: 2259
Tim Eccles <Tim@tile.demon.co.uk> wrote: >In article <DHFC7I.9Dy@zoo.toronto.edu> > henry@zoo.toronto.edu "Henry Spencer" writes: ><snip> >>> In fairness, there is one tricky problem: customers who want to make >>> their products reverse-engineering-proof. This is hard to do with the >>> Xilinx approach, in which the bit stream to program the FPGA *must* come >>> from an external source and hence is easily tapped. To handle this in the >>> context of an open architecture, the chip needs to have either encryption >>> hardware or on-chip nonvolatile memory, neither of which is trivial. >But would it not be relatively straightforward for Xilinx to add a few bytes >of non-volatile public key memory (read/write) plus private key memory (write >only) and implement a small decryption engine. The configuration data rates >are so low that a serial arithmetic scheme should be possible. >Even a simple system would give a huge increase in design security. ><snip> I seem to recall that Xilinx' whole strategy is to use a "plain vanilla" chip technology, and have their wafers made by several different subcontractors. (I understand Xilinx do not run a wafer-fab themselves). Most EPROM and similar technology is proprietary to each fab; Xilinx would then need a new design for each sub-contractor. -- DaveArticle: 2260
George Noten (garyk@svpal.svpal.org) wrote: : : I prefer the pro-series to the older workview. It's much more pleasant to : : use, and works well with Windows 3.1 (but NOT win95). It doesn't require goofy : : pro-sim and view-sim compare. : I think there is NO difference between DOS WorkView and the PROseries. They : even have the same bugs since ViewLogic never has enough time to fix them : (they release new products with the new bugs instead). It applies both : to schematic entry and simulation. How about the workview plus? Does it better than PROseries? I've heard that it was placed on the higher rank(by viewlogic). Supaket K. -- +-------------------------------------------- | Supaket Katchmart. | Computer And Network System Research Lab. | Dept. Computer Engineering. | Kasetsart University. +-------------------------------------------- | E-Mail : b36skk@nontri.ku.ac.th +--------------------------------------------Article: 2261
Greetings to all, I have some questions regarding the current state of the industry and where it is going. I work for BP Microsystems, a manufacturer of universal device programmers, so I have a rather unique view of what is popular and available among devices of all shapes and sizes. What I would like to know is what everyone else thinks about topics such as in-circuit programmability (both in prototyping and large scale production), usefulness of SRAM devices, functional testing of modern devices, low voltage devices and anything else you might think of as either a God-send or a waste of time. I look forward to seeing your responses. Please feel free to E-Mail me directly at erich@bpmicro.com. Thanks, Erich Wagner BP Microsystems 1000 N. Post Oak Rd. Houston TX. 77055Article: 2262
I developed partition system. It works at XNF, SXNF input. I want to get large circuit for testing my system. Data must be less than 196 Primary I/O. I have ISCAS benchmark already, I need more large circuit. If you are interested in my system, and you have some large circuit with XNF or SXNF form, please send me a mail.Article: 2263
> How about the workview plus? Does it better than PROseries? >I've heard that it was placed on the higher rank(by viewlogic). > > Supaket K. > Hi, after a year of fighting Dos Workview, then Proseries, both supplied as Xilinx locked systems, with VHDL, I'm looking at Workview Office, unlocked. It's not ready yet, but the bits I have are actually usable, quite unlike everything I've had before. It's possible to write VHDL and not have to fight the system, reboot many times, or resort to schematics to get the result I need. Paradise! I honestly couldn't recommend ProSeries if you're on any kind of a deadline, there are _far_ too many undocumented 'gotchas', and it's hard to sell VHDL that doesn't sanely support hierachy, and the only allowable data type is one that no-one else uses..... (And the manuals/sample code, ho bleeding ho....) It's been a bad year, toolwise, although I did manage to extract a nice twin P-90 machine in order to get the tools to at least blow up faster *8-) Still, the future's a vast amount better, Workview Office looks like a win, and, unless I've missed something, there's nothing better in the price range. Still, open to suggestions.... All the best, especially to those struggling to get work done using ProSeries. (Mail me to swap cunning workarounds/bodges/horrors) Steve, speaking for Steve, not SJ.Article: 2264
In article <peter-0911951718340001@149.199.19.143>, peter@xilinx.com (Peter Alfke) says: > >In article <47riv9$615@news-2.csn.net>, caleb@audiologic.com wrote: > >> Is it possible to configure a Xilinx 30xx IOB connected to RESET~ >> to successfully reset the chip? If so, how? > >Yes, it is possible to connect an output to the active Low RESET pin of >any XC3000 device. >There is no problem during configuration, since all outputs ( except LDC ) >are held High with a week pull-up resistor. Is it possible to control the probing of the A12XXs by using 3 outputs connected to the probe control pins (mode,sdi,dclk). This would save the external register and associated address decode pld output required. The local CPU typically has access to some r/w regs inside the design. We tried it once and had to isolate the mode pin to get the design to function. We had other things to work on and never got back around to it. The programable probes have been invaluable. On most boards the fpga(s) connect to everything, so it is often easier to connect the scope leads to the fpga's probe points, and move the probes around on the board in a virtual fashion (saves alot of fine pitch wear&tear). Eric Pearson - sans sigArticle: 2265
In article 1sq@ccsun2.sogang.ac.kr, NAM MIN WOO <esfree> writes: > I developed partition system. > It works at XNF, SXNF input. > I want to get large circuit for testing my system. > Data must be less than 196 Primary I/O. > I have ISCAS benchmark already, > I need more large circuit. > If you are interested in my system, and you have some large circuit > with XNF or SXNF form, please send me a mail. > I have a design with 1778 CLBs. is it interesting ? -mrmArticle: 2266
Hi! I have trouble installing XAct for Windows. The problem is that the dongle can't be found by the software. Any idea?? The printerport works fine with an HP-Laserjet. It's onboard a ASUS PT55XE with 32MB RAM and an 133mhz CPU. Hope on help. Jan.Article: 2267
Erich, SRAM based devices are being used increasingly for "reconfigurable computers". See; http://www.io.com/~guccione/HW_list.html http://www.reconfig.com/ In these applications the devices are reprogrammed in circuit. This is a growing application of SRAM based FPGAs. -- Rocky Awalt The Rockland Group rocky@trg.com 7095 Pyramid Ct. <- shipping http://www.trg.com/~fpga P. O. Box 368 <- snail mail 916.622.7935 <- voice Garden Valley, CA 95633-0368 916.622.7637 <- fax USA "Based in Northern California - TeleConsulting Worldwide"Article: 2268
This is the first time people find major bugs with the Viewlogic! Tell me more and is very interesting. jothi@singnet.com.sgArticle: 2269
This is the first time people find major bugs with the Viewlogic! Tell me more and is very interesting. jothi@singnet.com.sgArticle: 2270
In <488urq$l7j@ixnews5.ix.netcom.com>, fsoehnge@ix.netcom.com (Frank Soehnge) writes: >Greetings to all, > >I have some questions regarding the current state of the industry and >where it is going. I work for BP Microsystems, a manufacturer of >universal device programmers, <snip> I realize you're seeking information about the direction of devices, but some of my major concerns regard device programmers. Every time a new device is announced, the real questions are whose programmer will support it, how many iterations until they get the bugs out (of both the device AND the programmer), and how much the next "upgrade" to the so-called universal programmer will be. (This is not specific to one programmer manufacturer; it applies to most of them). Why does there seem to be a general antipathy between the device and programmer manufacturers? Why so much finger-pointing when things go wrong? I'd like to see new device announcements carry the logos of the programmers that are ready to handle the new parts. Obviously, some of the device manufacturers hate to lose the income from the sales of their proprietary programmers; are they making more on the programmers than on the parts themselves? In-circuit programming is a nice feature; just keep it simple, and the voltages normal. SRAM-based parts can lead to chicken-egg problems in small systems (how do you boot the part when it's responsible for accessing the memory where the boot code resides?). --GeneArticle: 2271
My thesis, entitled "Multi-FPGA Systems", is now available on the World-Wide Web at http://www.eecs.nwu.edu/~hauck/Thesis. It contains overviews of digital logic implementation alternatives, multi-FPGA systems, and other topics that may be of interest to many in this group. I've included the abstract and introductory chapter below. If you have any questions or comments, please let me know. Scott Hauck Assistant Professor - Northwestern University, Dept. of EECS hauck@eecs.nwu.edu Abstract Multi-FPGA systems are a growing area of research. They offer the potential to deliver high performance solutions to general computing tasks, especially for the prototyping of digital logic. However, to realize this potential requires a flexible, powerful hardware substrate and a complete, high quality and high performance automatic mapping system. The primary goal of this thesis is to offer a disciplined look at the issues and requirements of multi-FPGA systems. This includes an in-depth study of some of the hardware and software issues of multi-FPGA systems, especially logic partitioning and mesh routing topologies, as well as investigations into problems that have largely been ignored, including pin assignment and architectural support for logic emulator interfaces. We also present Springbok, a novel rapid-prototyping system for board-level designs. Chapter 1: General Introduction In the mid 1980s a new technology for implementing digital logic was introduced, the field-programmable gate array (FPGA). These devices could either be viewed as small, slow gate arrays (MPGAs) or large, expensive programmable logic devices (PLDs). FPGAs were capable of implementing significantly more logic than PLDs, especially because they could implement multi-level logic, while most PLDs were optimized for two-level logic. While they did not have the capacity of MPGAs, they also did not have to be custom fabricated, greatly lowering the costs for low-volume parts, and avoiding long fabrication delays. While many of the FPGAs were configured by static RAM cells in the array (SRAM), this was generally viewed as a liability by potential customers who worried over the chipıs volatility. Antifuse-based FPGAs also were developed, and for many applications were much more attractive, both because they tended to be smaller and faster due to less programming overhead, and also because there was no volatility to the configuration. In the late 1980ıs and early 1990ıs there was a growing realization that the volatility of SRAM-based FPGAs was not a liability, but was in fact the key to many new types of applications. Since the programming of such an FPGA could be changed by a completely electrical process, much as a standard processor can be configured to run many programs, SRAM-based FPGAs have become the workhorse of many new reprogrammable applications. Some uses of reprogrammability are simple extensions of the standard logic implementation tasks for which the FPGAs were originally designed. An FPGA plus several different configurations stored in ROM could be used for multi-mode hardware, with the functionality on the chip changed in reaction to the current demands. Also, boards constructed purely from FPGAs, microcontrollers, and other reprogrammable parts could be truly generic hardware, allowing a single board to be reprogrammed to serve many different applications. Some of the most exciting new uses of FPGAs move beyond the implementation of digital logic, and instead harness large numbers of FPGAs as a general-purpose computation medium. The circuit mapped onto the FPGAs need not be standard hardware equations, but can even be operations from algorithms and general computations. While these FPGA-based custom-computing machines may not challenge the performance of microprocessors for many applications, for computations of the right form an FPGA-based machine can offer extremely high performance, surpassing any other programmable solution. While a custom hardware implementation will be able to beat the power of any generic programmable system, and thus there must always be a faster solution than a multi-FPGA system, the fact is that few applications will ever merit the expense of creating application-specific solutions. An FPGA-based computing machine, which can be reprogrammed like a standard workstation, offers the highest realizable performance for many different applications. In a sense it is a hardware Supercomputer, surpassing traditional machine architectures for certain applications. This potential has been realized by many different research machines. The Splash system [Gokhale90] has provided performance on genetic string matching that is almost 200 times greater than all other Supercomputer implementations. The DECPeRLe-1 system [Vuillemin95] has demonstrated world-record performance for many other applications, including RSA cryptography. One of the applications of multi-FPGA systems with the greatest potential is logic emulation. The designers of a custom chip need to verify that the circuit they have designed actually behaves as desired. Software simulation and prototyping have been the traditional solution to this problem. However, as chip designs become more complex, software simulation is only able to test an ever decreasing portion of the chipıs functionality, and it is quite expensive in time and money to debug by repeated prototype fabrications. The solution is logic emulation, the mapping of the circuit under test onto a multi-FPGA system. Since the logic is implemented in the FPGAs in the system, the emulation can run at near real-time, yielding test cycles several orders of magnitude faster than software simulation, yet with none of the time delays and inflexibility of prototype fabrications. These benefits have led many of the advanced microprocessor manufacturers to include logic emulation in their validation methodologies. While multi-FPGA systems have great potential to provide high-performance solutions to many applications, there are several problems that hold back current systems from achieving their full promise. Their hardware structures tend to have much too few I/O connections for their logic capacity to be adequately used. This leads to very low logic utilization, with only 10% to 20% of the available capacity usable. While some of these problems may be unavoidable, since we are using FPGAs targeted to single-chip applications to build multi-chip systems, the routing topologies of multi-FPGA systems need to be improved to compensate for this. Also, while there are logic emulation systems that meet the needs of single-chip ASIC prototyping, the domain of system-level or board-level prototyping has largely been ignored. These emulation opportunities are quite different from single chip systems, since multi-chip designs have a heavy reliance on premade components, and have resource demands that vary much more widely than that of a single ASIC. Not only does board-level prototyping demand a flexible and extensible emulation hardware system, one that allows the inclusion of arbitrary premade components, but it also brings into sharper focus the need to support external interfaces. Even in single-chip systems, one of the major benefits of an emulation is that it may be capable of being put into its target environment, thus encountering the true input-output demands of the final implementation. However, an emulation of a circuit will almost always run slower than the final implementation, meaning that it will no longer meet the timing requirements of the external signaling protocols. Current emulation systems have no answer to this problem, forcing the user to develop ad hoc solutions. For board-level prototyping, where a system will be required to meet several signaling protocols at once, this problem becomes an even greater concern. Thus, a general-purpose solution to the logic emulator interface problem is critical to the success of board-level prototyping, and can improve emulations of individual ASICs as well. The problems with current multi-FPGA systems are not solely with the hardware. Automatic mapping software is an important part of any multi-FPGA system that hopes to achieve widespread utility, and is an absolute requirement for any successful logic emulation system. While there are niches for multi-FPGA systems with hand-mapped solutions, very few people are capable and willing to expend the effort to hand-map to a multi-FPGA system, and without software these systems will only realize a small portion of their promise. Unfortunately, todayıs mapping software is inadequate for most potential applications. They deliver quite poor mappings, and can take huge amounts of time to complete. Creating a mapping with current tools can take almost an entire day to finish. Obviously, this is a tremendous disadvantage, since any time savings that could be achieved by running an algorithm on a multi-FPGA system is swallowed up by the time to create the mapping in the first place. Thus, high-quality, high-performance mapping tools are a necessity for realizing the full potential of multi-FPGA systems. Part of the reason why these deficiencies exist in current multi-FPGA systems is that there has been relatively little work done on optimizing the hardware and software structures of these machines. While there are a huge number of multi-FPGA systems proposed and constructed, there are almost no studies investigating what the best architectures really are. The software systems suffer as well, with many individual optimizations proposed, but no real understanding of how to bring these optimizations together to achieve the best possible results. Thus, todayıs systems are largely grab-bags of appealing features with little knowledge of what the systems should really look like. In 1992 we were in the same position as many other potential multi-FPGA system builders. We saw the need for a new system, which in our case was an emulation system optimized for the demands of board-level prototyping. While we knew in general what the system should look like, there was little guidance on exactly what the hardware and software architecture should be. At this point, instead of blindly going forward with our best guesses on how the system should be, we set out to look at the underlying issues and determine what really were the right architectures. By performing a disciplined investigation of multi-FPGA hardware and software systems, we not only would learn how to build our prototyping system correctly, but would also give a better understanding of some of the issues to the multi-FPGA community at large. It is these investigations that form the heart of this thesis. While we have not yet built our prototyping system (the high-level design of which is contained in Chapter 6), our work has yielded insight into many of the problems facing todayıs multi-FPGA systems. Our investigations have focused on several different areas. In the hardware arena, we examined the routing topologies of multi-FPGA systems. Although the FPGAs in a multi-FPGA system are reprogrammable, the connections between the FPGAs are fixed by the circuit board implementing the system. With the main bottleneck in current multi-FPGA systems being the limited bandwidth for inter-FPGA routing, the routing topology of a multi-FPGA system has a significant impact on the capacity, as well as performance, of a multi-FPGA system. In our investigations we examined how best to construct a multi-FPGA system, yielding topologies with significantly lower I/O requirements, faster performance, and higher bandwidth. Since our goal was to construct a prototyping system for board-level designs, we also had to consider the issue of how to support the external interfaces of a logic emulation system. By examining how to solve this problem in general, we have shown that a generic interface transducer, a simple board with FPGAs and memories for filtering the incoming and outgoing datastreams, is capable of supporting many different types of protocols. It has a flexible architecture that enables it to be prefabricated, yet it still allows customization to a specific applicationıs requirements. Also, the required customization is easy to develop, and a small amount of programming in a high-level hardware description language is usually sufficient. We have also spent time investigating the software required to map to a multi-FPGA system. Perhaps the most critical of these algorithms is partitioning, the process of splitting an input mapping into pieces small enough to fit into the individual FPGAs in a multi-FPGA system. While much work has been done on this problem previously, there was little insight into the best possible approach. Many researchers have proposed software solutions, but there was little comparative assessment of different approaches. Thus, one major portion of our work was to sift through the different approaches, and develop an algorithm that brings together the best possible set of optimizations to achieve the best overall results. This produced a survey of many of the different approaches, with each optimization implemented in a common framework, and compared quantitatively on a set of benchmark circuits. We now have an algorithm that produces results significantly better and faster than any other published approach. We also recognized that flexible routing topologies are becoming more common in multi-FPGA systems, with architectures capable of significant customization in their interconnection patterns being proposed. To deal with these systems, it became apparent that the mapping tools not only needed to be fast and high-quality, but they also must be able to adapt to an arbitrary topology. This is not only important for flexible multi-FPGA hardware, but it also results in software that can easily be adapted to different machines. In pursuit of this goal, we have developed partitioning software capable of mapping to an arbitrary multi-FPGA system topology, as well as routing software that can do the same. This routing software has the added advantage that it improves the quality of the mapping over current approaches, yielding both better-quality mappings and faster run-times. This latter benefit is due to the fact that poor routing complicates the following mapping steps, and thus by improving the routing quality we decrease the total mapping time. The result of all of this work is new insights into how best to build and use multi-FPGA systems, as well as solutions to some of the outstanding problems. These results are not just important for building prototyping systems like the one we envisioned, but to multi-FPGA systems in general. The routing topologies are generally useful, offering improved topologies for both emulation and custom-computing. The mapping tools provide fast, high-quality mapping solutions for arbitrary system topologies. Finally, the interface transducers deliver a generic solution for interfacing both current single-chip emulators, as well as future board-level prototyping systems. This thesis details the results of these investigations. It begins with a discussion of the underlying technologies that make multi-FPGA systems practical, including a survey of FPGAs and other logic implementation technologies in Chapter 2, as well as the application domains of multi-FPGA systems in Chapter 3. Chapter 4 delves deeper into one of the most promising application areas for multi-FPGA systems, logic emulation. Chapter 5 then gives an overview of current multi-FPGA system hardware. With the background provided by these chapters, we then present some new investigations and approaches to multi-FPGA system hardware. In Chapter 6 we present a new multi-FPGA system optimized for the prototyping of board-level designs. This system combines the inclusion of arbitrary devices with a flexible and extensible architecture to provide an extremely adaptable prototyping solution. Then, Chapter 7 examines routing topologies for multi-FPGA systems. This yields constructs with lower I/O demands, smaller delays, and higher bandwidth than standard topologies. Finally, Chapter 8 investigates how to support external interfaces for logic emulators, one of the significant problems with current systems. The discussion of multi-FPGA system software begins with a general introduction in Chapter 9. Chapter 10 considers logic partitioning for multi-FPGA systems, presenting a comprehensive investigation into bipartitioning techniques. This results in a combined partitioning algorithm that achieves results better than the current state of the art, in significantly less time. Chapter 11 presents an iterative partitioning algorithm that automatically adapts to an arbitrary topology. This allows bipartitioning to be applied to any multi-FPGA system, as well as multi-sectioning and multi-way partitioning algorithms where appropriate. Finally, Chapter 12 investigates pin assignment algorithms for multi-FPGA systems. This speeds up the placement and routing time for multi-FPGA systems and produces higher quality results. We conclude this thesis with some overall results and potential future work in Chapter 13. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Scott A. Hauck, Assistant Professor | | Dept. of EECS Voice: (708) 467-1849 | | Northwestern University FAX: (708) 467-4144 | | 2145 Sheridan Road Email: hauck@eecs.nwu.edu | | Evanston, IL 60208 WWW: http://www.eecs.nwu.edu/~hauck | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+Article: 2272
Hallo, is there any software to design FPGAs available for the Linux Operating system or planned to be available in the next future? Thanks -- Uwe Bonnes bon@elektron.ikp.physik.th-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 2273
In <48d3vm$945@harry.lloyd.com> Rocky Awalt <rocky@trg.com> writes: >Erich, >SRAM based devices are being used increasingly for "reconfigurable computers". >See; > http://www.io.com/~guccione/HW_list.html > http://www.reconfig.com/ >In these applications the devices are reprogrammed in circuit. This is a growing >application of SRAM based FPGAs. SRAM?? Shouldn't that read EEPROM? Rob -- +------------------------------------+--------------------------------------+ | Rob Janssen rob@knoware.nl | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@wab-tis.rabobank.nl | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU | +------------------------------------+--------------------------------------+Article: 2274
You've done a good job!!!!!!!!!!!!
Xblox changed itself the name of my design.
Fileinput=xc_ram2
Fileoutput=xc_ram2.xg
but the real output was XCRAM2.XG. (oh, oh,....)
Can you speak spanish? (joputa)
Hi de puta , D. Quijote said to Sancho, so don't offend yourself by
what I tell you when angry....
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