Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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)
From: kremser@rbg.informatik.th-darmstadt.de (steffen kremser)
Date: 18 Aug 1994 08:48:02 GMT
Links: << >>  << T >>  << A >>
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: 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
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
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 >>
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 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 >>
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 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..
From: kaydee@uplink.eng.umd.edu (Kaustabh Duorah)
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
From: hutch@timp.ee.byu.edu (Brad Hutchings)
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},
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: 136
Subject: Re: Self-Programming Devices (was Re: Proprietary Configuration Data)
From: hutch@timp.ee.byu.edu (Brad Hutchings)
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:
>|> 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 Institute




Article: 145
Subject: Re: Dynamic Incremental Reconfiguration
From: hutch@timp.ee.byu.edu (Brad Hutchings)
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
>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
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>,
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 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




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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