1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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

Custom Search

Messages from 125

Article: 125
Subject: Self-Programming Devices (was Re: Proprietary Configuration Data)
Date: 18 Aug 1994 08:48:02 GMT
Links: << >>  << T >>  << A >>
Satwant Singh (satwant@regulus) 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
- 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"

(**) 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)

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: 126
Subject: Re: Proprietary Configuration Data
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Date: Thu, 18 Aug 1994 10:30:00 GMT
Links: << >>  << T >>  << A >>
In 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 Subject: ppr bug? Xilinx 3100A From: iap10@cl.cam.ac.uk (Ian Pratt) Date: 18 Aug 1994 12:33:48 GMT Links: << >> << T >> << A >> 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 Pratt Article: 128 Subject: Re: FPGA Hobbyist and their software/programmer/hardware From: henry@zoo.toronto.edu (Henry Spencer) Date: Thu, 18 Aug 1994 15:09:39 GMT Links: << >> << T >> << A >> 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 Subject: Re: FPGA Hobbyist and their software/programmer/hardware From: yuri@shimari.cmf.nrl.navy.mil (Yuri Trifanov) Date: 18 Aug 1994 16:22:41 GMT Links: << >> << T >> << A >> >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 Subject: Re: FPGA Hobbyist and their software/programmer/hardware From: michaelt@ssd.intel.com (Michael Tchou) Date: Thu, 18 Aug 1994 18:36:43 GMT Links: << >> << T >> << A >> 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
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
Subject: Re: Self-Programming Devices (was Re: Proprietary Configuration Data)
From: satwant@regulus (Satwant Singh)
Date: Thu, 18 Aug 1994 22:44:03 GMT
Links: << >>  << T >>  << A >>
: 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

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 Singh

Article: 132
Subject: Re: QuickLogic (was Re: FPGA Hobbyist...)
From: onmate@iohk.com (Onmate)
Date: 25 Aug 1994 01:05:07 GMT
Links: << >>  << T >>  << A >>
: > 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 Regards

Article: 133
Subject: I wnat to contact Harris
From: fengwct@ku.ac.th (Wichai Tang)
Date: 26 Aug 1994 05:00:24 GMT
Links: << >>  << T >>  << A >>
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.
Thanks

Article: 134
Subject: Technology Mapping Bibliography..
Date: 26 Aug 1994 11:55:47 -0400
Links: << >>  << T >>  << A >>
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
Subject: Density Enhancement via Run-Time Reconfiguration
Date: 26 Aug 1994 18:11:30 -0600
Links: << >>  << T >>  << A >>

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},
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},
pages = {77-80}
}

--
Brigham Young University - Electrical Engineering Department
Reconfigurable Logic Laboratory (801) 378-2667

Article: 136
Subject: Re: Self-Programming Devices (was Re: Proprietary Configuration Data)
Date: 26 Aug 1994 18:53:53 -0600
Links: << >>  << T >>  << A >>

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. |> |> * 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-2667 Article: 137 Subject: Re: Density Enhancement via Run-Time Reconfiguration From: hutch@timp.ee.byu.edu (Brad Hutchings) Date: 26 Aug 1994 18:59:10 -0600 Links: << >> << T >> << A >> 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: 138 Subject: About harris From: fengwct@ku.ac.th (Wichai Tang) Date: 29 Aug 1994 06:21:19 GMT Links: << >> << T >> << A >> To : 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 Wattanavichean Article: 139 Subject: Re: QuickLogic (was Re: FPGA Hobbyist...) From: onmate@iohk.com (Onmate) Date: 30 Aug 1994 02:33:03 GMT Links: << >> << T >> << A >> 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 Subject: Xilinx slow on distribution of r5.0 From: edi@hensley.ethz.ch (Edi Hiltebrand) Date: 30 Aug 1994 12:32:18 GMT Links: << >> << T >> << A >> 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 Subject: Incremental reconfiguration ? From: jca@porto.inescn.pt (Jose Carlos Alves) Date: 30 Aug 1994 09:06:41 -0500 Links: << >> << T >> << A >> 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.2094200 Article: 142 Subject: Re: Xilinx slow on distribution of r5.0 From: bobe@soul.tv.tek.com (Bob Elkind) Date: 30 Aug 1994 17:56:44 GMT Links: << >> << T >> << A >> 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 myself Article: 143 Subject: Re: Incremental reconfiguration ? From: bobe@soul.tv.tek.com (Bob Elkind) Date: 30 Aug 1994 18:03:48 GMT Links: << >> << T >> << A >> 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 TV Article: 144 Subject: Dynamic Incremental Reconfiguration From: timothyc@ICSI.Berkeley.EDU (Tim Callahan) Date: 31 Aug 1994 21:22:03 GMT Links: << >> << T >> << A >> 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:
>|>
>|> >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

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
from the currently executing configuration.  For example, configuration A
is grinding away, and at some point (dependent on the data) it
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
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 Institute

Article: 145
Subject: Re: Dynamic Incremental Reconfiguration
Date: 31 Aug 1994 22:07:55 -0600
Links: << >>  << T >>  << A >>

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: 146 Subject: Re: Xilinx slow on distribution of r5.0 From: maxima@den.fujifilm.co.jp (Sugio Maxima) Date: Thu, 1 Sep 1994 07:30:27 GMT Links: << >> << T >> << A >> In 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

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
Subject: Re: Dynamic Incremental Reconfiguration
From: ludwig@inf.ethz.ch (Stefan Ludwig)
Date: 1 Sep 1994 08:42:20 GMT
Links: << >>  << T >>  << A >>
In article <1994Aug31.210514@timp.ee.byu.edu>,

>|> 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 1075

Article: 148
Subject: PLDshell/Intel ftp site
From: arthur@alcor1.mlo.dec.com (Ed Arthur)
Date: Thu, 1 Sep 1994 15:41:14 GMT
Links: << >>  << T >>  << A >>

Hi,

Does anyone know where Intel's ftp site is? I'm trying
to get ahold of PLDshell.

Thanks,
/Ed

Article: 149
Subject: Re: PLDshell/Intel ftp site
From: rodneym@panix.com (Rodney Myrvaagnes)
Date: 1 Sep 1994 15:12:44 -0400
Links: << >>  << T >>  << A >>
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