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
Satwant Singh (satwant@regulus) wrote:
: Brad Hutchings (hutch@timp.ee.byu.edu) wrote:
: : partial configuration; however, that is not the same thing as
: : "self-modifying" hardware. That would require an internally addressable
: : configuration store. The configuration store of the Atmel device can
: : only be addressed *externally*. Thus all configuration data must come
: : from a source external to the FPGA.
: One may have to wire (on PCB) certain programming pins of
: the FPGA to certain other user pins. In this way, data
: generated inside the FPGA can be fed back to the configuration
: control, which still sees it as data coming from external
: source.
This assumes the FPGA can be reprogrammed while it is "running".
AFAIK, programming usually involves switching the *complete* device
into a programming (Reset, JTag, whatever) mode, which is mutually
exclusive to "normal operation".
So, you'd need an external device that can
- put the FPGA in prog-mode
- download the new configuration
- restart the FPGA
This device could be
- another FPGA, (see **)
- simple RAM/ROM based Sequencer,
- a uC-system running the "adaptive" algorithm
All of these alternatives need some externally accessible
Storage (RAM/ROM) to hold (the initial/template) design.
In Effect, we'd be building a "Meta-FPGA" that has the same
features Brad (hutch@timp.ee.byu.edu) mentioned in his post:
- "partial configuration"
- "internally adressable" configuration storage
(**) A more theoretical Question WRT FPGA-configures-FPGA:
NOTE: the following "#Bit"-Reasoning is by rule of thumb and
purely speculative.
Imagine our FPGA defined by #N Bits of Configuration.
This "Capacity" is divided into
#F Bits defining the "Functional Aspect"
#M bits defining the "Meta-Aspect" (Adaptation & Reprogram)
#U Bits unused (assuming you can define "inert" config)
"M"'s immediate job is providing a "new" version of "F",
but a (complete) reprogramming would also require a copy of "M".
I can't quite see a Statemachine producing a #F+#M(+#U) Bitstream
realized in #M Bits. (ignoring #U >> #F+#M, trivial but useless)
That is, without at least "read" (self-referential) access to the
current configuration. (Meta-FPGA again...)
Am I wrong? (Would "M" be considered a "FPGA Virus" ? ;-)
CU on the Bitstream,
Steffen Kremser
--
Steffen +-------------------------+-------------------------------------+
//// | kremser@igd.fhg.de | Rorschach: None of You understand! |
c-OO +-------------------------| I'm not locked up in here with YOU. |
| -~ | kremser@nukunuku.swb.de | YOU're locked up in here with *ME*. |
Kremser +-------------------------+-------------------------------------+
Article: 126In article <32tnr3$7os@char.vnet.net>, devb@char.vnet.net (David Van den Bout) writes... >At least with every FPGA I have used, you can't wire user pins to >the programming pins in order to have the FPGA reprogram itself because >the user-defined logic of the FPGA is disabled as soon as the FPGA >begins its configuration sequence. No, but presumably there's nothing (except for lack of configuration data specs) preventing me wiring up another circuit (or using a second FPGA :-)) to hold the configuration data. The outputs of the first FPGA are connected to that circuit, set up a suitable configuration stream, and then the FPGA reconfigures itself. I didn't say it _had_ to be all in one chip, just that I'd like to experiment with self-reconfiguring circuits (as would several other posters here). > >|| Dave Van den Bout || >|| Xess Corporation || -tony Bristol University takes no responsibility for the views expressed in this posting. They are the personal views of the user concerned.Article: 127
Just before I throw myself at the mercy of Xilinx tech. support, I was wandering if anyone out there has experienced a similar problem with Xilinx PPR V5.0.0 for HP700 ??? I have three existing Xilinx 3190PQ160-5 designs that I was hoping to rework for 3190APQ160-5 parts so that I could take advantage of the extra routing resources (All 3 designs syffer from only 5% of APR runs routing currently). I've run the designs through the new xnfmerge, xnfprep, and xnfmap. The problem comes when I run the design through PPR (instead of APP). After running apparently happily for ~25mins I get "sqrt: DOMAIN error". PPR aborts it's placement phase and goes proceeds in a futile attempt to route the design with the current best (bad) placement. This has happened with all three designs I've tried. Can anyone please shed any light ? All tools used are the HP700 versions on the XACT 5.0 CD. Thanks, Ian PrattArticle: 128
In article <1994Aug17.183749.5824@neocad.com> ian@neocad.com (Ian McEwen) writes:
>Does this mean that these hackers are not capable of figuring out
>the bitstream format without the vendors' help/blessings, but that
>they could write the rest of the software? I don't think so. If
>there truly is enough interest, these hackers would overcome the
>proprietary nature of the bitstreams just like any other hurdle.
Believe me, some of us have thought about it. Unfortunately, there is
a chicken-and-egg problem: the way to do that is to systematically
experiment, using the manufacturer's programming software. This means,
again, that somebody's got to fork out $$$... and unless I'm very much
mistaken, the licence for that software will include a "no reverse
engineering allowed" clause. This makes any information derived from
such experimenting legally tainted. Spending time and effort to free
up the bitstream encoding is one thing; spending time and effort with
a very good prospect of having the result entangled in legal proceedings,
thereby *not* freeing up the bitstream encoding, is quite another.
If you can suggest a way of overcoming this particular hurdle *without*
incurring legal difficulties, please do.
>If there really is a need and an interest, go do it! If not, it's
>not just because you don't have free access to the bitstream data.
Unfortunately, it *is* just because we don't have free access to the
bitstream data, and can't see any way to get free access to same.
>...the fact that a handful of hobbyists want
>to use their chips too, but can't afford the tools, doesn't have
>much impact. The vendors work to satisfy corporate users, the ones
>which will buy lots of chips. Hobbyists don't drive the market.
Let's be precise here: the vendors work to satisfy Fortune 500 users.
There are lots of corporate users who can't afford the tools either, and
the next Sun Microsystems or Microsoft may be among them. The vendors
are not being realistic about their markets; they are being shortsighted
about their markets.
Otherwise why not give the bitstream generator away (or sell it cheaply)
and save the arm-and-a-leg prices for the fancy CAD tools?
--
"It was blasphemy that made us free." | Henry Spencer
-- Leon Wieseltler | henry@zoo.toronto.edu
Article: 129>Does this mean that these hackers are not capable of figuring out >the bitstream format without the vendors' help/blessings, but that >they could write the rest of the software? I don't think so. If >there truly is enough interest, these hackers would overcome the >proprietary nature of the bitstreams just like any other hurdle. your argument is specious I'll be frank. I've spent some time trying to do this, specifically with Xilinx configuration data for both the 3000 and 4000 series. I generated whole sets of LCA files and ran them through the bitstream generator, developed tools to examine bit patterns assigned against repeating units with special cases for the edges, which would highlight differences between files. I came up with some things, but not nearly enough to be useful. I would estimate the time required to accurately decode the bit format for the Xilinx part as being greater than the time required to write a fair first cut placement package that would sit underneath existing logic generation freeware. One of the reason people who aren't getting specifically paid to do so write code is that it's enjoyable. this was not. Nothing is stopping Xilinx from drastically changing it in future chips either. There's no reason to waste time trying to fight Xilinx. I sincerely hope that someone decides that it's in their best interest to give out the format and support freeware developers. They would have the bulk of my hobby and professional business immediately.Article: 130
In article <CuqKs4.GKs@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1994Aug17.183749.5824@neocad.com> ian@neocad.com (Ian McEwen) writes: >>Does this mean that these hackers are not capable of figuring out >>the bitstream format without the vendors' help/blessings, but that >>they could write the rest of the software? I don't think so. If >>there truly is enough interest, these hackers would overcome the >>proprietary nature of the bitstreams just like any other hurdle. > >Believe me, some of us have thought about it. Unfortunately, there is >a chicken-and-egg problem: the way to do that is to systematically >experiment, using the manufacturer's programming software. This means, >again, that somebody's got to fork out $$$... and unless I'm very much >mistaken, the licence for that software will include a "no reverse >engineering allowed" clause. This makes any information derived from >such experimenting legally tainted. Spending time and effort to free >up the bitstream encoding is one thing; spending time and effort with >a very good prospect of having the result entangled in legal proceedings, >thereby *not* freeing up the bitstream encoding, is quite another. > ---***(text deleted)***--- At one time, (in a universe far, far away) I remember browsing the specification for Xilinx's intermediate netlist format (xxxx.XNF). This was (at the time) a relatively intuitive spec, that did not (far as I could tell) reveal much about any given device's internal arrangement. Also, (if memory serves) x.XNF format files can serve as 'source' for most of the Xilinx P&R and/or PP&R tools. I see nothing to prevent a dedicated/fanatic super-hacker from writing tools that input (ascii) equations and output x.XNF. (Unless, of course, the newer x.XNF netlist specifications are considered to be 'Xilinx Company Confidential'.) Said hacker would still require access to someone's map-place-route tools, but this is something that might be arranged on a time-share basis. Can anyone from Xilinx comment on this? (Are y'all out there?) - michaelt/M6 ----------------------- ----------------------- ----------------------- -- *** <disclaimer> ** Michael R. Tchou ** <disclaimer> *** -- -- My inventions, produce, and the benefits thereof, are my -- -- employer's property. My opinions are my own, and _only_ -- -- my own. All in all, a reasonably equitable arrangement. -- ----------------------- ----------------------- -----------------------Article: 131
steffen kremser (kremser@rbg.informatik.th-darmstadt.de) wrote: : Satwant Singh (satwant@att.com) wrote: : : Brad Hutchings (hutch@timp.ee.byu.edu) wrote: : : : partial configuration; however, that is not the same thing as : This assumes the FPGA can be reprogrammed while it is "running". : AFAIK, programming usually involves switching the *complete* device The FPGAs that support "partial re-configuration", by definition allow re-configuration of one part during the "normal operation" of another part. So, it is possible for such an FPGA to modify itself without an internally addressable configuration memory. As someone else suggested, using an FPGA to partially (or totally) re-configure a second (slave) FPGA may be a more intuitive way to emulate a self-modifying device. I think the major road-block in constructing self-modifying hardware is still the proprietary nature of the bit-stream format of the existing FPGAs. : NOTE: the following "#Bit"-Reasoning is by rule of thumb and : purely speculative. This reasoning is interesting, but given the increased capacity and decreased size of Silicon and Magnetic memory the actual number of bits may not be very important (for example, imagine using 1GB hard-disk to store partial configurations). Satwant SinghArticle: 132
Michael K. Hinazumi (hinazumi@spot.Colorado.EDU) wrote: : > 2) Yes your argument is correct. What I'd suggest is that on the : > "cheap" hobbyist versions you don't provide support. To be honest: : > that's what Quicklogic is (was) doing. We (a few hobbyists) bought a : > "demo version" for $100 that didn't include the simulator. : Yes, QuickLogic still sells "eval. kits". These kits still : cost $99, and it lets you do everything except program a part. : It includes schematic capture, functional simulation, APR, : and timing simulation and analysis. I believe you get a : month's worth of tech support as well. It's a really good : deal, IMHO. : If anyone's interested, send email to one of their Application : Engineers: randyo@qlogic.com : He can answer any questions you may have. : -m No, the evaluation kit form QuickLogic does not include the X-Sim simulator. It only allow you to do capture and P&R and that's all. Best RegardsArticle: 133
Hi everyone, I want to know the contact point to the HARRIS company. Dose anyone know ? Please mail me at fengwct@nontri.ku.ac.th or post here. ThanksArticle: 134
Hello,
I am reading up on Technology mapping and I would really appreciate if
someone could mail me or point out a source of a bibliography for
technology mapping algorithms.
Specifically I am interested in Polynomial time algorithms similar to
or improvements upon Flow-Map ( Cong and Ding, UCLA).
Thanks
Kaustabh Duorah
--
_/ _/ _/_/_/ Kaustabh Duorah
_/_/ _/ _/ Electrical Engineering
_/ _/ _/ _/ University of Maryland
_/ _/ _/ _/_/_/ _/ College Park MD 20742
Article: 135
Recently there have been several postings that discussed the
reconfiguration of FPGAs during the execution of some task. Most of
these postings have referred to this as "self-modifying hardware". As
this is an active research area here at Brigham Young University
(BYU), I thought that I might give a summary of what we are doing in
the area and hopefully provide some useful information to others.
First of all, a little introduction about myself and what is going on
here at BYU. I oversee the Reconfigurable Logic Lab here at BYU. Our
main research focus has been in Run-Time Reconfigurable (RTR) systems.
We also study the more garden variety of FPGA-based systems that are
often reported in the literature. Our research approach has been to
construct *actual* RTR systems with available CAD tools and devices.
We have constructed and tested a variety of different FPGA-based
systems. Some of our work has been reported at FCCM-94 and CICC-94
(see references below).
In our work we have identified two types of Run-Time Reconfigurable
systems: static and dynamic. Static RTR systems do not support
partial reconfiguration at the device or system level and do not
maintain internal state between configuration cycles. Thus each time
the system is reconfigured, all internal state of all devices is
erased and all devices are reconfigured simultaneously. System
execution of such systems follows a process of ``configure and
execute.'' Dynamic systems support partial configuration at the system
or device level and typically maintain internal state between
configuration cycles. Dynamic systems can actively configure
some subsystems while other subsystems continue to operate thus supporting
a much more complex execution profile than static RTR systems.
RRANN is an example of a static RTR system. RRANN is the Run-Time
Reconfiguration Artificial Neural Network. RRANN was implemented as a
proof-of-concept, static RTR system to demonstrate the effectiveness
of RTR for enhancing functional density in neural networks. It
implements the popular backpropagation training algorithm as three
time-exclusive FPGA configurations: feed-forward, backpropagation and
update. System operation consists of sequencing through these three
reconfigurations {\em at run-time}, one configuration at a time. RRANN
has been fully implemented with Xilinx FPGAs, tested and shown to
increase the functional density of a network by 500\% when compared to
FPGA-based implementations that do not use RTR. Overall performance is
improved by this functional density enhancement *even though the
system spends more real time reconfiguring than actually executing*.
RRANN has been reported in FCCM-94 and CICC-94.
We are nearing completion of our first dynamic RTR system. Our
current project is a dynamically reconfigurable hardware sequencer that
automatically modifies its internal configuration during system
execution. We will report more detail when we begin testing the
system.
We have found that RTR can significantly enhance the *functional
density* of FPGA-based systems. By dividing an algorithm into
time-exclusive operations and implementing these operations as
distinct configurations, overall system organization can be modified
*during system operation* to make the best use of the reconfigurable
resource. Circuit modules can be unloaded when idle thereby freeing up
additional circuit resources that can be brought to bear on the more
computationally intensive parts of an algorithm.
*** References ***
@inproceedings{,
author = {J. G. Eldredge and B. L. Hutchings},
title = {{FPGA} Density Enhancement of a Neural Network Using FPGAs
and Run-Time Reconfiguration},
booktitle = {IEEE Workshop on FPGAs for Custom Computing Machines},
year = {1994},
month = {April},
address = {Napa, CA},
pages = {180-188}
}
@inproceedings{,
author = {J. G. Eldredge and B. L. Hutchings},
title = {{RRANN:} The Run-Time Reconfigurable Artificial Neural Network},
booktitle = {IEEE Workshop on FPGAs for Custom Computing Machines},
year = {1994},
month = {May},
address = {San Diego, CA},
pages = {77-80}
}
--
Brad L. Hutchings
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667
Article: 136In article <334a8k$92i@zikzak.apana.org.au>, zik@zikzak.apana.org.au (Zik Saleeba) writes: |> kremser@rbg.informatik.th-darmstadt.de (steffen kremser) writes: |> |> >In Effect, we'd be building a "Meta-FPGA" that has the same |> >features Brad (hutch@timp.ee.byu.edu) mentioned in his post: |> >- "partial configuration" |> >- "internally adressable" configuration storage |> |> I'm doing a PhD thesis on runtime-reconfiguration and |> self-reconfiguration. Some of the architectural features I've |> identified as being useful for these devices are: I am interested in your work. Could you please comment on the questions that I have asked. |> |> * dynamic reconfiguration - by this I mean reconfiguration which can |> occur during operation and is fast enough to be useful. What is "fast enough to be useful"? |> * multiple configurations - adding multiple configuration stores |> doesn't actually cost a huge amount, and it can prove to be a big win. Whether or not this costs a huge amount depends on how many of the chip resources are dedicated to configuration store as compared to how many are used by the routing network and the cell logic. DeHon's DPGA paper (presented at FCCM-94) discusses the potential benefits of a multiple-configuration device. One of the questions that remains to be answered is: Which makes more sense, implementing additional configuration store so you can reuse the available logic, or use the area that would otherwise be consumed by the additional configuration store to implement additional logic and routing resources? Some important work needs to be done here *with actual or existing designs* so that we can answer this question sufficiently. |> * self-reconfiguration - with a fair amount of effort you can dream up |> kinky algorithms optimised for self-reconfiguration. The simulated |> devices I've been working with uses an internal random-access |> self-reconfiguration interface. The prime number generator I've |> mentioned used self-reconfiguration to create new factor checkers at |> runtime. I am not sure I understand what you mean by self-reconfiguration. I would appreciate some more details if possible. Does self-reconfiguration mean that the circuit generates new placements and routing or are the modifications of a simpler nature? Or is the configuration information loaded from an external source? |> In short, runtime reconfiguration and self-reconfiguration are useful |> techniques, and it seems likely to me that we'll be seeing a lot more |> of them in the future. I am curious. What do you specifically find useful about run-time reconfiguration? What do you specifically find useful about self-reconfiguration? And how are these techniques different? I am interested to see how your ideas differ from my own. -- Brad L. Hutchings Brigham Young University - Electrical Engineering Department Reconfigurable Logic Laboratory (801) 378-2667Article: 137
In article <1994Aug26.181002@timp.ee.byu.edu>, hutch@timp.ee.byu.edu (Brad Hutchings) writes:
|>
|>
I apologize for the error in the reference. See the corrected reference below:
|> *** References ***
|>
|> @inproceedings{,
|> author = {J. G. Eldredge and B. L. Hutchings},
|> title = {{RRANN:} The Run-Time Reconfigurable Artificial Neural Network},
|> booktitle = {IEEE Workshop on FPGAs for Custom Computing Machines},
|> year = {1994},
|> month = {May},
|> address = {San Diego, CA},
|> pages = {77-80}
|> }
@inproceedings{,
author = {J. G. Eldredge and B. L. Hutchings},
title = {{RRANN:} The Run-Time Reconfigurable Artificial Neural Network},
booktitle = {Proceedings of the IEEE Custom Integrated Circuits Conference},
year = {1994},
month = {May},
address = {San Diego, CA},
pages = {77-80}
}
--
Brad L. Hutchings
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667
Article: 138To : Doug Thomae <thomae@v3a.ess.harris.com> I can not send mail to you. It returned me every time. So I post my mail here. So please forgive for doing this. :( ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > I doubt that I can help you directly, but if you give me some > idea of what you want to know I can probably find a phone number > for you to call. Thank you very much. I need to buy some product from your company. I will (may be on Monday,22) mail to your sale department for request some detail of products and their price. I include that mail follow this mail. So please hand it to sale department. Thank you again. Wichai Tang. =========================================================================== Dept. of Electrical Engineering Faculty of Engineering Kasetsart University 50 Phaholyothin Rd. Jatujak, Bangkok 10903 Thailand. Fax. no. 66-2-579-8781 Email: fengwct@nontri.ku.ac.th 22 August 1991 To whom it may concerns, First of all, I should introduce myself. My name is Dr.Koarakot Wattavichean, a lecturer at Electrical Engineering Department, Faculty of Engineering, Kasetsart University. My current research is concerning with Analog IC Design which software under using now is called "MAGIC" (version 6). I face some difficulty with full-custom design by using "MAGIC". The problem probably comes from lacking of some experience in design with full-custom of users. So, I try to find some analog design tool with semi-custom design (That is the software should have standard cells of basic analog circuits.) which can help students doing research better. And recently, one of my closed friends recommended that your company has such a software. So,I would like to ask about the details and price list for this thing. It's very kinds of you, if you could send me my request urgently. Also please tell me your fax. no. or Email address in order to be convenient in contact with you quickly next time. Thank you very much for your kind correspondence. Yours sincerely, Koarakot WattanavicheanArticle: 139
Wrong!!!!! We have purchased one eval. kit last year. It does NOT include simulation. Finally, we have purchased a full package. We have checked with our representative a few days ago. They say that the eval. kit does not include simulation. Best Regards, Onmate Technology Ltd.Article: 140
I suggest that noone out in the wide world is going to pay maintenace fees to Xilinx any more for the folowing reasons: - New users did get the release of the version 5.0 (due in May 94) in Aug 94 while we who have been paing annual maintenance fees for years are sill waiting to get the new release (and other users I know as well). - The last update we did get was v1.42 of DS502 in May 93. The PPR of this release has severe errors if you use hard macros. So we wait for more than one year without getting anything for the money we paid. I would be interested to hear your opinion and your experiances with the "total customer satisfaction" made by Xilinx. P.S. If any guy of Xilinx is reading these lines stop reading news and make things happen!!! ***************************************************************************** Swiss Federal Institute of Technology * Email: edi@ife.ee.ethz.ch Electronics Laboratory * High Performance Computing * Edi Hiltebrand * Tel: +41 1 632 27 61 8092 Zurich, Switzerland * Fax: +41 1 262 16 55 *****************************************************************************Article: 141
Hi fpga users, Does anybody know if it is possible to modify partially the configuration RAM cells in XILINX devices (4000 series) ? What i want is to redefine quickly a 'small' part of the fpga, while the remaining is working, eventually controlling the reconfiguration process. I know this can be done with separate fpgas to implement the 'small' reconfigurable part, but i want all in only one circuit. I think this could be possible if the working circuit can have access to the individual ram cells (including those that control the interconnections). In short, what i'm looking for is something like an incremental reconfiguration process, to modify only the changed bits. Any hints are wellcome Jose' Jose' Carlos Alves (jca@inescn.pt) INESC - Porto, Portugal Tel 351.2.2094200Article: 142
In article <deleted> edi@hensley.ethz.ch (Edi Hiltebrand) writes: >Xilinx any more for the folowing reasons: >- New users did get the release of the version 5.0 (due in May 94) > in Aug 94 while we who have been paing annual maintenance fees for years > are sill waiting to get the new release (and other users I know as well). We received our 5.0 update seven weeks ago >- The last update we did get was v1.42 of DS502 in May 93. The PPR of this > release has severe errors if you use hard macros. ... [stuff deleted] I'm still using the old (pre v5) release of PPR on both PCs and SUNs, I use *lots* of hard macros, and they seem to work just fine. In fact, the hard macros are the only things standing between the hell of random place/route and me. >I would be interested to hear your opinion and your experiances with the "total >customer satisfaction" made by Xilinx. I don't want to be in the awkward position of defending Xilinx' reputation for software quality. I've designed lots of Xilinx-based stuff, as well as "normal" gate arrays and full-custom ASICS. The best SW I've seen is for full custom ASICS, and only where the design "process" is constrained to permit only unadventurous designs and design practices. Working with less than ideal toolsets, under less than ideal conditions, (and for less than ideal salary and work hours!) is a fact of life, at least for me. I've found it best to work constructively with the folks at Xilinx, no matter how grievously they have "injured" me. They need your constructive feedback very much. The hardest part is finding someone who will both listen and have enough clout to act. >P.S. If any guy of Xilinx is reading these lines stop reading news and make >things happen!!! On the other hand, there are lots of guys at Xilinx (and other companies) who need to spend less time writing code and more time listening to real- world customers, so they get a clue about real-world problem solving. Bob Elkind, Tektronix TV, speaking for myselfArticle: 143
jca@porto.inescn.pt (Jose Carlos Alves) writes: >Does anybody know if it is possible to modify partially the >configuration RAM cells in XILINX devices (4000 series) ? >What i want is to redefine quickly a 'small' part of the >fpga, while the remaining is working, eventually controlling >the reconfiguration process. I know this can be done with separate >fpgas to implement the 'small' reconfigurable part, but i want >all in only one circuit. I think this could be possible if the working >circuit can have access to the individual ram cells (including >those that control the interconnections). > >In short, what i'm looking for is something like an incremental >reconfiguration process, to modify only the changed bits. > >Any hints are wellcome Partial loads are not possible with current 4K FPGAs. If the "reconfigured" section is small enough, then one possible solution is to include both/all functions/configurations of the logic in question, and select/enable the function desired. This is the brute force method, of course, and is not limited to any particular FPGA (or ASIC) technology. Another possibility is to use the LDC and HDC pins to "do the right thing" to just barely get by during reconfiguration. I've used this approach to maintain the contents of a DRAM buffer, for example. Bob Elkind, Tektronix TVArticle: 144
In article <1994Aug26.182748@timp.ee.byu.edu>, Brad Hutchings <user@machine.domain> wrote: > >In article <334a8k$92i@zikzak.apana.org.au>, zik@zikzak.apana.org.au (Zik Saleeba) writes: >|> kremser@rbg.informatik.th-darmstadt.de (steffen kremser) writes: >|> >|> >In Effect, we'd be building a "Meta-FPGA" that has the same >|> >features Brad (hutch@timp.ee.byu.edu) mentioned in his post: >|> >- "partial configuration" >|> >- "internally adressable" configuration storage >|> >|> I'm doing a PhD thesis on runtime-reconfiguration and >|> self-reconfiguration. Some of the architectural features I've >|> identified as being useful for these devices are: > >I am interested in your work. Could you please comment on the >questions that I have asked. I hope you haven't taken this discussion off-line -- I'm very interested in it. In fact, the area I will probably do my PhD thesis in is compilation techniques for such dynamically, incrementally reconfigurable FPGA's -- and I've been trying to get a good picture in my head of what a reasonable target architecture will look like. My project is looking more towards executing dusty-deck C code directly on such architectures, while this discussion seems to be more along the lines of being able to have configurations that are too big to all fit on the FPGA at one time. However, many of the issues are the same. I haven't been considering self-reconfiguration -- I've been picturing something more along the lines of a simple configuration controller downloading new partial configurations into the FPGA based on feedback from the currently executing configuration. For example, configuration A is grinding away, and at some point (dependent on the data) it will either raise one flag to signal "ok, now download partial configuration B" or raise another flag to signal "ok, now download partial configuration C". Have any of you spec'ed out such an interface? What is the executable file format like? Even more challenging is to define an architecture & executable format so that the same dynamic configuration execution file can run on different-sized FPGA's (and take advantage of the additional resources available in larger ones). A possible file format was described in "A Self-Reconfiguring Processor", French & Taylor, in FCCM'93. In their approach, the executable contains simple RISC-like instructions which are translated into hardware configurations on the fly, and the configurations are cached for later re-use. In this situation, configurations are identified by the address of the first instruction of the code segment they were derived from. This format has obvious benefits for simulation / interpretation and implementation flexibility, but I still feel that pre-compiled configurations will give better performance... Anyone else doing work in this area? Tim Callahan UC Berkeley / International Computer Science InstituteArticle: 145
In article <342s9r$geu@agate.berkeley.edu>, timothyc@ICSI.Berkeley.EDU (Tim Callahan) writes:
|>
|> I hope you haven't taken this discussion off-line -- I'm very interested
|> in it. In fact, the area I will probably do my PhD thesis in is
I haven't taken anything offline. Actually, I was surprised how
silent the newsgroup seemed to become after my last two
postings. Was it something I said? :-)
|> compilation techniques for such dynamically, incrementally reconfigurable
|> FPGA's -- and I've been trying to get a good picture in my head of
|> what a reasonable target architecture will look like.
^^^^^^^^^^^^^^^^^^^
Something that we have been studying as well (the target architecture).
|>
|> My project is looking more towards executing dusty-deck C code
|> directly on such architectures, while this discussion seems to
|> be more along the lines of being able to have configurations that are
|> too big to all fit on the FPGA at one time. However, many of the issues
|> are the same.
To some extent, in static run-time reconfigured systems anyway, it is a matter
of how often the system gets reconfigured. You might view the set of static
RTR systems as a continuum:
Configured Once Configured many
per algorithm ++++++++++++++++++++++++++++++++++++++++++++++ times per algorithm
where systems such as Splash, Prism, PAM are on the left, and systems
such as RRANN are on the right. Of course there are different reasons
for implementing systems with varying frequencies of reconfiguration.
Systems on the left attempt to throw lots of silicon *all at once*
at a problem so as to achieve the highest possible levels of performance.
They amortize the cost of all that silicon by using it to implement many
different algorithms. Systems on the right are most likely
reconfiguring at a high frequency in order to enhance the functional
density of the FPGA for a given algorithm and thus implement the algorithm
with fewer FPGAs. One example of a system that sits somewhere in
the middle of the continuum is some video hardware developed by Radius
that modifies its FPGA configurations to support different bit-depths.
Another example might be a printer that implements its rendering engine
with FPGAs. The FPGAs could be reconfigured each time a different graphics
primitive needed to be rendered (this is not my idea, there was actually
a printer like this designed but I don't think it ever made it to market).
In these latter cases, reconfiguration occurs more often than the
Splash, Prism and PAM systems, but less often than systems like RRANN.
Silicon reuse is the common thread running through all of these systems.
|>
|> I haven't been considering self-reconfiguration -- I've been picturing
^^^^^^^^^^^^^^^^^^
I still haven't quite figured out what people mean by self-reconfiguration.
Maybe there isn't a consensus but how is it different (or like) static
or dynamic run-time reconfiguration as I discussed in an earlier posting?
|> something more along the lines of a simple configuration controller
|> downloading new partial configurations into the FPGA based on feedback
|> from the currently executing configuration. For example, configuration A
The feedback part of this sounds similar to the stuff being proposed in
the Transit project at MIT.
|> is grinding away, and at some point (dependent on the data) it
|> will either raise one flag to signal "ok, now download partial
|> configuration B" or raise another flag to signal "ok, now download
|> partial configuration C". Have any of you spec'ed out such an interface?
|> What is the executable file format like?
The interface on our system has been designed but we are still
coding up the software to do some of the testing. Our current
system uses device bitstreams as the file format.
|>
|> Even more challenging is to define an architecture & executable format
|> so that the same dynamic configuration execution file can run on
|> different-sized FPGA's (and take advantage of the additional resources
|> available in larger ones).
This is an interesting idea. Kind of reminds me of binary compatability
of software. The obvious thing is to reconfigure less often when
you have plenty of silicon, more often when there is less silicon
available. Beyond this it would seem that some additional placing
and routing might be required to use the additional area
(similar to recompilation).
|>
|> A possible file format was described in "A Self-Reconfiguring
|> Processor", French & Taylor, in FCCM'93. In their approach, the
|> executable contains simple RISC-like instructions which are translated
|> into hardware configurations on the fly, and the configurations are
|> cached for later re-use. In this situation, configurations
|> are identified by the address of the first instruction of the code
|> segment they were derived from. This format has obvious benefits for
|> simulation / interpretation and implementation flexibility,
|> but I still feel that pre-compiled configurations will give better
|> performance...
|>
|> Anyone else doing work in this area?
We are working on a target architecture for a dynamic run-time reconfigurable
system. It has been designed and implemented on the National Semiconductor
CLAy device supports many of things you listed above. Circuit modules are
loaded on demand as required by the data. The system model supports partial
reconfiguration, etc. Once we have finished tested our stuff
(a couple of months), we will give some additional info.
--
Brad L. Hutchings (801) 378-2667
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
Reconfigurable Logic Laboratory
Article: 146In article <33v8si$ibi@elna.ethz.ch>, edi@hensley.ethz.ch (Edi Hiltebrand) says: > >I would be interested to hear your opinion and your experiances with the "total >customer satisfaction" made by Xilinx. Bad! I hardly read a Japanese manual in Japan in recent years. (This may be one of the reason why Xilinx is not major in Japan.) >P.S. If any guy of Xilinx is reading these lines stop reading news and make >things happen!!! Japanese stuff can't read them :-<Article: 147
In article <1994Aug31.210514@timp.ee.byu.edu>, Brad Hutchings <user@machine.domain> wrote: >|> I haven't been considering self-reconfiguration -- I've been picturing > ^^^^^^^^^^^^^^^^^^ >I still haven't quite figured out what people mean by self-reconfiguration. >Maybe there isn't a consensus but how is it different (or like) static >or dynamic run-time reconfiguration as I discussed in an earlier posting? I think it means that the FPGA can reconfigure part of itself, say, constant inputs to some function, where the constants themselves are calculated by the FPGA. I don't know if this can be useful though, but you might get smaller circuits using this technique. There are self-modifying algorithms that are an order of magnitude faster and smaller than their "conventional" version. Stefan H-M Ludwig ludwig@inf.ethz.ch Institute for Computer Systems Swiss Federal Institute of Technology (ETH) CH-8092 Zurich, Switzerland Phone: +41-1-632 7301 Fax : +41-1-632 1075Article: 148
Hi, Does anyone know where Intel's ftp site is? I'm trying to get ahold of PLDshell. Thanks, /EdArticle: 149
In <1994Sep1.154114.14217@peavax.mlo.dec.com> arthur@alcor1.mlo.dec.com (Ed Arthur) writes: Intel sold its PLD business to Altera. It probably does not support PLDshell any more. >Hi, >Does anyone know where Intel's ftp site is? I'm trying >to get ahold of PLDshell. >Thanks, >/Ed
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