From: micahjd@users.sourceforge.net (Micah Dowty) Newsgroups: comp.arch.fpga Subject: Architecture for high-level reconfigurable computing Date: 13 May 2002 10:01:54 -0700 Organization: http://groups.google.com/ Lines: 47 Message-ID: <37ce351d.0205130901.3c70066f@posting.google.com> NNTP-Posting-Host: 12.252.169.247 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1021309314 16406 127.0.0.1 (13 May 2002 17:01:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 13 May 2002 17:01:54 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17396 A few days ago a friend of mine and I were inspired to build a new computer architecture, with the intent of making it easy to split tasks between hardware and software and implement them on a scalable system. And it would all be Open Source. So far this is still in the very early planning stages... There will be an off-the-shelf microprocessor (like maybe a StrongArm) running a conventional OS (Linux probably) combined with one or more FPGAs. The FPGAs and processor would be connected together with a relatively slow bus, with faster interconnect between adjacent FPGAs. Each fpga would have extra peripherals attached, and optionally a bank of memory separate from the CPUs memory. There would be a new language for designing hardware and software systems. Something along the lines of Handel-C, but object oriented. The idea would be that an object would be a precompiled hardware macro, and when it is instantiated it is loaded into the FPGA at runtime and connected to an internal bus that allows objects to pass messages between each other. It would be something of a combination between Handel-C and Objective C. Since both hardware and software objects would need to instantiate hardware objects, the FPGAs would actually have to reconfigure themselves. The CPU could perhaps use the boundary scan port to configure a bootstrap circuit that would then allow partial reconfiguration through the CPU's bus or the FPGA's message-passing bus. Anyway... Obviously this would be a huge effort, but to even get started I would need open source tools for bitstream creation, routing, etc, since there would need to be embedded software and/or hardware to place the object macros and route the busses together. I have read the threads at http://www.opencollector.org/news/Bitstream on the subject. With projects like this in the realm of the possible, it's quite annoying that the bitstream format is so closely guarded. (especially since the design security issue is being addressed by encryption in the Virtex II family) In the mean time, I'll take a crack at reverse engineering the bitstream for the Xilinx Spartan II. (Since that's what I have on hand) I would appreciate any comments on the feasibility of this whole idea. I've puttered around with FPGAs for a while now, but I still can't claim any serious experience. --Micah ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: 13 May 2002 22:42:07 +0200 Organization: My own Private Self Lines: 117 Message-ID: <6ubsbjlqzk.fsf@chonsp.franklin.ch> References: <37ce351d.0205130901.3c70066f@posting.google.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1021322527 1120 10.0.3.2 (13 May 2002 20:42:07 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 13 May 2002 20:42:07 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:17400 micahjd@users.sourceforge.net (Micah Dowty) writes: > Since both hardware and software objects would need to instantiate > hardware objects, the FPGAs would actually have to reconfigure > themselves. More likely be reconfigured by external stuff, i.e. your CPU. > The CPU could perhaps use the boundary scan port to > configure a bootstrap circuit Or for lot faster reconfig use the SelectMap interface. It costs IO pins, but for your data processing style application pin count should not be limiting. > Anyway... Obviously this would be a huge effort, but to even get > started I would need open source tools for bitstream creation, > routing, etc, The old problem. Appears in a thread about every 1/4 to 1/3 of a year. :-) > on the subject. With projects like this in the realm of the possible, > it's quite annoying that the bitstream format is so closely guarded. Nitpick: not "closely guarded", just "not published". According to Peter Alfke of Xilinx it is not about secrecy, but more that they do not want the support costs from people trying to roll their own tools. Published = must be supported in the commercial world. That open source programmers accept non-supported stuff is a new thing in FPGA development circles. They have still got to get used to our different culture. Give them a bit of time and they will digest it. > (especially since the design security issue is being addressed by > encryption in the Virtex II family) The info on Virtex (and so also Sparten-II) bitstreams is acually out here, just not in an user friendly form. Xilinx is actually an exeption in this respect, all other vendors do not publish such info at all. Try the following stuff: Virtex datasheet http://www.xilinx.com/partinfo/ds003.pdf (the basics how the chip works, Spartan-II is the same) + XAPP138 Virtex Configuration and Readback http://www.xilinx.com/xapp/xapp138.pdf (how to load the chip, important for your reconfiguring, btw) + XAPP151 Virtex Series Configuration Architecture User Guide http://www.xilinx.com/xapp/xapp151.pdf (how the bitstream is formatted, LUT/FF/IOB/BRAM data bit positions) + JBits config API, an set of Java .class files to modify bitstreams mailto:jbits@xilinx.com (its docs document what bits exist in the stream, how routing looks) (JBits may actually be all that you need, not the bitstream, if you write your compiler in Java!) + use JBits to experimentally determine bit positions (make various configs and look where the bits appear) > In the mean time, I'll take a crack at reverse engineering the > bitstream for the Xilinx Spartan II. (Since that's what I have on > hand) Looking at how long your project will take (just defining your language and how to split it CPU/FPGA), I will most likely have that already finished before you get around to doing it. It has been on my project list for about 1 year, and now that my job change is through, I can start off doing it. http://neil.franklin.ch/Projects/VirtexTools/ > I would appreciate any comments on the feasibility of this whole idea. Possible, just a lot of work. Which is why I needed the new half-time job first. :-) > I've puttered around with FPGAs for a while now, but I still can't > claim any serious experience. In my case an partially done FPGA-CPU project, using JBits: http://neil.franklin.ch/Projects/PDP-10/ -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Make your code truely free: put it into the public domain ###### Message-ID: <3CE02AA7.2BEF@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 117 Date: Tue, 14 May 2002 09:05:43 +1200 NNTP-Posting-Host: 203.79.98.85 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1021323951 203.79.98.85 (Tue, 14 May 2002 09:05:51 NZST) NNTP-Posting-Date: Tue, 14 May 2002 09:05:51 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!telocity-west!TELOCITY!news-out.spamkiller.net!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17422 Micah Dowty wrote: > > A few days ago a friend of mine and I were inspired to build a new > computer architecture, with the intent of making it easy to split > tasks between hardware and software and implement them on a scalable > system. And it would all be Open Source. > > So far this is still in the very early planning stages... There will > be an off-the-shelf microprocessor (like maybe a StrongArm) running a > conventional OS (Linux probably) combined with one or more FPGAs. The > FPGAs and processor would be connected together with a relatively slow > bus, with faster interconnect between adjacent FPGAs. Each fpga would > have extra peripherals attached, and optionally a bank of memory > separate from the CPUs memory. > > There would be a new language for designing hardware and software > systems. Something along the lines of Handel-C, but object oriented. > The idea would be that an object would be a precompiled hardware > macro, and when it is instantiated it is loaded into the FPGA at > runtime and connected to an internal bus that allows objects to pass > messages between each other. It would be something of a combination > between Handel-C and Objective C. > > Since both hardware and software objects would need to instantiate > hardware objects, the FPGAs would actually have to reconfigure > themselves. The CPU could perhaps use the boundary scan port to > configure a bootstrap circuit that would then allow partial > reconfiguration through the CPU's bus or the FPGA's message-passing > bus. > > Anyway... Obviously this would be a huge effort, but to even get > started I would need open source tools for bitstream creation, > routing, etc, since there would need to be embedded software and/or > hardware to place the object macros and route the busses together. > > I have read the threads at http://www.opencollector.org/news/Bitstream > on the subject. With projects like this in the realm of the possible, > it's quite annoying that the bitstream format is so closely guarded. > (especially since the design security issue is being addressed by > encryption in the Virtex II family) > In the mean time, I'll take a crack at reverse engineering the > bitstream for the Xilinx Spartan II. (Since that's what I have on > hand) > > I would appreciate any comments on the feasibility of this whole idea. > I've puttered around with FPGAs for a while now, but I still can't > claim any serious experience. Getting in at the bitstream level is not a great idea, for the first stages. Better to learn up on the existing file-level entry choices, from EDIF up to VHDL/Verilog, as well as the soft cores about. As for a top-level language, C is far from ideal, as it always quickly morphs into 'a new language', and looses any benefit. What is needed is a parallel language, that can run on PCs or FPGAs, with common source. You then get fpga-simulation for free, and do NOT have to make early-parition decisions, plus can easily deploy on multiple cores. See my earlier post (pasted here) : ASML is working now on PCs. Jim Granville Wrote: > I also came across this recently, > > http://www.research.microsoft.com/fse/asml/ > > and it seemed to me, this could have FPGA applications. > > A key weakness of C, is the sequential nature of all descriptions, > and the fact that FPGA "C's" are not C at all, but are some > 'variant of the C programming language' - they seem more keen > on getting the magic buzzword C in there, than in how it can be used > practically. Throwing thousands of HW novice C coders at FPGAs sounds > more a problem than a solution :-) > > ASML is inherently parallel, until 'step' in invoked, and thus > the SAME source could potentially target an OpCode or FPGA at runtime. > > This from the overview > > It is only after a step has been made that the new values > > become visible. > > In general, a computation in AsmL is not sequential unless > > explicitly marked as being so. > > ASML would encourage 'sea of CPU' innovations on the PC, as well as > FPGA implementations. > Because it has a path to compile -> Runs on a PC, that also gives a > Simulation path, to verify the logic on FPGA. The best 'horizon' approach would be - A language that is inherently parallel and capable of HW description (More than one language support would be good : some problems suit some languages better than others). - A three way path for that language, to allow a) Run on a PC/ARM/PPC etc HW, ie Hard core with maximal resource b) Run on a soft-core, ie FPGA core with minimal resource c) Run in FPGA HW Some discussion on Java in FPGA's is already underway, another pathway would be to implement .NET MSIL in FPGA/Softcore combination. .NET is new, but already looks a more stable pivot point than Java flavours, and .NET has good language support already - See http://msdn.microsoft.com/vstudio/partners/language/default.asp This would lead to .NET core(s) in FPGA, with key code sections chosen as FPGA-Macros, running as a system. jg ###### Message-ID: <3CE0346B.C5901BF2@qut.edu.au> Date: Tue, 14 May 2002 07:47:23 +1000 From: John Williams Organization: CRC for Satellite Systems, QUT X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: hpc2.scsn.bee.qut.edu.au X-Trace: 14 May 2002 07:48:37 +1000, hpc2.scsn.bee.qut.edu.au Lines: 30 X-Authenticated-User: williaj2 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!bunyip.cc.uq.edu.au!news.qut.edu.au!hpc2.scsn.bee.qut.edu.au Xref: chonsp.franklin.ch comp.arch.fpga:17403 Jim Granville wrote: > > Micah Dowty wrote: > > > > A few days ago a friend of mine and I were inspired to build a new > > computer architecture, with the intent of making it easy to split > > tasks between hardware and software and implement them on a scalable > > system. And it would all be Open Source. > The best 'horizon' approach would be > > - A language that is inherently parallel and capable of HW description > (More than one language support would be good : some problems suit > some languages better than others). > > - A three way path for that language, to allow > a) Run on a PC/ARM/PPC etc HW, ie Hard core with maximal resource > b) Run on a soft-core, ie FPGA core with minimal resource > c) Run in FPGA HW This may be a stupid question, but would it be feasible to have native VHDL support on a microprocessor? Preferably compiled, but even interpreted would be a starting point. Imagine the flexibility of being able to do your entire design in VHDL, then choosing, perhaps on the fly, which parts are instantiated in hardware and which in software... Regards, John ###### Reply-To: "Steve Casselman" From: "Steve Casselman" Newsgroups: comp.arch.fpga References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> Subject: Re: Architecture for high-level reconfigurable computing Lines: 25 Organization: Virtual Computer Corporation X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: NNTP-Posting-Host: 64.174.106.246 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr14.news.prodigy.com 1021326729 ST000 64.174.106.246 (Mon, 13 May 2002 17:52:09 EDT) NNTP-Posting-Date: Mon, 13 May 2002 17:52:09 EDT X-UserInfo1: [[PA@SBEQJUMA]DYMBCD^VX@WB]^PCPDLXUNNHPHBATBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN Date: Mon, 13 May 2002 21:52:09 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!newscon02.news.prodigy.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr14.news.prodigy.com.POSTED!6b43ba4c!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17445 > > A key weakness of C, is the sequential nature of all descriptions, This is not really correct. C has lots of parallelism. It always amazes me when people say there is no parallelism. Here is a line of very parallel C code. a = b+c, d= e+f, Myfunc(); According to the C specs the above line can be executed in parallel. The problem is if you can get different answers since the specs don't say what order they must executed in if you do them one at a time. example a = b , b = a ; Could be "a" and "b" have the value of "a" or they have the value of "b" or "a" and "b" swap values. It's one of the reasons Java only has lists for initializations. If you write a compiler you'll see what I mean. Steve ###### Message-ID: <3CE03767.665E161C@qut.edu.au> Date: Tue, 14 May 2002 08:00:07 +1000 From: John Williams Organization: CRC for Satellite Systems, QUT X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: hpc2.scsn.bee.qut.edu.au X-Trace: 14 May 2002 08:01:22 +1000, hpc2.scsn.bee.qut.edu.au Lines: 48 X-Authenticated-User: williaj2 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!bunyip.cc.uq.edu.au!news.qut.edu.au!hpc2.scsn.bee.qut.edu.au Xref: chonsp.franklin.ch comp.arch.fpga:17402 Hi Michael, Micah Dowty wrote: > > > Anyway... Obviously this would be a huge effort, but to even get > started I would need open source tools for bitstream creation, > routing, etc, since there would need to be embedded software and/or > hardware to place the object macros and route the busses together. > > I have read the threads at http://www.opencollector.org/news/Bitstream > on the subject. With projects like this in the realm of the possible, > it's quite annoying that the bitstream format is so closely guarded. > (especially since the design security issue is being addressed by > encryption in the Virtex II family) > In the mean time, I'll take a crack at reverse engineering the > bitstream for the Xilinx Spartan II. (Since that's what I have on > hand) > I too recently read those threads at opencollector.org... interesting stuff. Recently I've been researching the XC4000 series readback functionality, and in the process of debugging it I've learned some very interesting things about the bitstream format. In particular, we found a simple method that could, in principle, be used to reverse engineer the bitstream. Or more precisely, reverse engineer the relationship between a placed and routed design, and the corresponding bitstream. The idea of actually developing a tool to do the constrained routing etc just makes my head hurt. As other correspondents have said, the bitstream is not so much "secret", as unpublished. Although that said, I'm not sure how Xilinx would react should someone post on a website a clearly written document outlining the details with accompanying code. Comments anyone? Anyway let me know if you are really interested to hear more about the bitstream stuff. I tend to agree with one of the other posters, who said (more or less) that you'd be better starting off at a higher level and working down. Otherwise you're likely to get bogged down in the interesting, but time-consuming task of figuring out the bitstream, rather than your grand system ideas (which sound v. interesting by the way - do a search for hardware software codesign) Regards, John ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Mon, 13 May 2002 15:17:37 -0700 Organization: Xilinx, Inc. Lines: 26 Message-ID: <3CE03B81.B6624D70@xilinx.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> NNTP-Posting-Host: 149.199.34.160 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en To: John Williams Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!freenix!sunqbc.risq.qc.ca!newsfeed.mathworks.com!wn3feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi_feed3!attbi.com!12.120.28.17!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17407 John Williams wrote: > > > As other correspondents have said, the bitstream is not so much > "secret", as unpublished. Although that said, I'm not sure how Xilinx > would react should someone post on a website a clearly written document > outlining the details with accompanying code. Comments anyone? Speaking for myself ( I am not the official Xilinx spokesman, even if I behave like that occasionally): I am concerned about a publicized bitstream decoder for two reasons: 1. It might make some users feel vulnerable that their design can be reverse-engineered and then slightly modified to hide the rip-off. 2. It might expose Xilinx to unreasonable and unsupportable user questions, especially when they painted themselves into a corner. And he who sells the chips ultimately is stuck with the cry for help... Peter Alfke ###### From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Mon, 13 May 2002 22:33:59 +0000 (UTC) Organization: Unknown Lines: 13 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> NNTP-Posting-Host: soda.csua.berkeley.edu X-Trace: agate.berkeley.edu 1021329239 50665 128.32.247.226 (13 May 2002 22:33:59 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Mon, 13 May 2002 22:33:59 +0000 (UTC) Originator: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17425 In article <3CE03B81.B6624D70@xilinx.com>, Peter Alfke wrote: >Speaking for myself ( I am not the official Xilinx spokesman, even if I >behave like that occasionally): >I am concerned about a publicized bitstream decoder for two reasons: > >1. >It might make some users feel vulnerable that their design can be >reverse-engineered and then slightly modified to hide the rip-off. *cough* Jbits *cough*. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Message-ID: <3CE0404E.AE4B37C5@qut.edu.au> Date: Tue, 14 May 2002 08:38:06 +1000 From: John Williams Organization: CRC for Satellite Systems, QUT X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga To: Peter Alfke Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: hpc2.scsn.bee.qut.edu.au X-Trace: 14 May 2002 08:39:21 +1000, hpc2.scsn.bee.qut.edu.au Lines: 38 X-Authenticated-User: williaj2 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!bunyip.cc.uq.edu.au!news.qut.edu.au!hpc2.scsn.bee.qut.edu.au Xref: chonsp.franklin.ch comp.arch.fpga:17405 Hi Peter, Peter Alfke wrote: > Speaking for myself ( I am not the official Xilinx spokesman, even if I > behave like that occasionally): I understand your position - I think your participation in this group is a great thing and I hope your employer actively supports it. > 1. > It might make some users feel vulnerable that their design can be > reverse-engineered and then slightly modified to hide the rip-off. Yes, however in the long run "security-by-obscurity" is not sustainable. I'm guessing you are probably moving towards (already there?) bitstream encryption that would help deflate this aspect somewhat? > 2. > It might expose Xilinx to unreasonable and unsupportable user questions, > especially when they painted themselves into a corner. And he who sells the > chips ultimately is stuck with the cry for help... Indeed. With a hacked bitstream it would probably be easier than not to cook a device. Having worked in support before I'm familiar with the fact that users will lie about what they've done because they know they did the wrong thing, are embarrassed, but still want the help. "No, we didn't hack the bitstream, it came fresh from your tools!". How about a serial number generator in BITGEN, so when user has trouble you could ask for a copy of the .bit file, if it doesn't contain a valid serial then you say sorry, can't support you if you didn't use our tools. Of course, then someone could just hack the serial number generator, and so it goes... Regards, John ###### From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Mon, 13 May 2002 23:22:55 +0000 (UTC) Organization: Unknown Lines: 12 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> NNTP-Posting-Host: soda.csua.berkeley.edu X-Trace: agate.berkeley.edu 1021332175 52552 128.32.247.226 (13 May 2002 23:22:55 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Mon, 13 May 2002 23:22:55 +0000 (UTC) Originator: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17427 In article <3CE0404E.AE4B37C5@qut.edu.au>, John Williams wrote: >Yes, however in the long run "security-by-obscurity" is not sustainable. > >I'm guessing you are probably moving towards (already there?) bitstream >encryption that would help deflate this aspect somewhat? Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key is then loaded (through JTAG) into a distinct register on the part, which has a separate power pin to maintain state. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 00:57:18 +0100 Message-ID: <1021334275.2242.0.nnrp-07.9e9832fa@news.demon.co.uk> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> <3CE0346B.C5901BF2@qut.edu.au> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1021334275 nnrp-07:2242 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 10 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!kibo.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17442 John Williams wrote > This may be a stupid question, but would it be feasible to have native > VHDL support on a microprocessor? Preferably compiled, but even > interpreted would be a starting point. That is what the compiled simulators do. Performance is not great... ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 01:00:45 +0100 Message-ID: <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1021334482 nnrp-07:2332 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 12 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!kibo.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17441 Nicholas Weaver wrote > Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key > is then loaded (through JTAG) into a distinct register on the part, > which has a separate power pin to maintain state. All together, for the umpteenth time: "Please can we have these few register bits as flash" ###### Message-ID: <3CE05A10.12D4@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 21 Date: Tue, 14 May 2002 12:28:00 +1200 NNTP-Posting-Host: 203.79.102.127 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1021336090 203.79.102.127 (Tue, 14 May 2002 12:28:10 NZST) NNTP-Posting-Date: Tue, 14 May 2002 12:28:10 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!hub1.nntpserver.com!telocity-west!TELOCITY!news-out.spamkiller.net!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17421 Tim wrote: > > Nicholas Weaver wrote > > > Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key > > is then loaded (through JTAG) into a distinct register on the part, > > which has a separate power pin to maintain state. > > All together, for the umpteenth time: > "Please can we have these few register bits as flash" Not until FLASH can be placed in the corner of a CMOS process, without needing the rules/mask sets across the whole die. That said, there are companies claiming to have NV RAM processes, supposedly CMOS FAB compatible - these are small size memories, but certainly OK for Keys / IDs / etc, Then there's also MRAM... -jg ###### Message-ID: <3CE0874C.C18C852@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 17 Date: Tue, 14 May 2002 03:41:23 GMT NNTP-Posting-Host: 216.244.44.81 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1021347683 216.244.44.81 (Mon, 13 May 2002 20:41:23 PDT) NNTP-Posting-Date: Mon, 13 May 2002 20:41:23 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17418 Tim wrote: > > All together, for the umpteenth time: > "Please can we have these few register bits as flash" Same answer for the umpteenth time: "No, as long as that would mean sacrificing the standard, high-volume and high-performance CMOS logic/microprocessor process". Tell us how it can be done without significant impact on fab availability, performance, and cost, and we will really listen. We are convinced these conditions cannot be met today. Hope is eternal! Peter Alfke ###### From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 03:43:37 +0000 (UTC) Organization: Unknown Lines: 12 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> NNTP-Posting-Host: soda.csua.berkeley.edu X-Trace: agate.berkeley.edu 1021347817 62047 128.32.247.226 (14 May 2002 03:43:37 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Tue, 14 May 2002 03:43:37 +0000 (UTC) Originator: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17424 In article <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk>, Tim wrote: >All together, for the umpteenth time: > "Please can we have these few register bits as flash" All together, for the umpteenth time: "Flash slows the process down, and anyway, damnit, being properly paranoid, I prefer battery backed SRAM, its harder to probe." -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Message-ID: <3CE08BC5.12AA0FFE@attbi.com> From: Phil Hays Organization: phil-hays at above domain X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 50 NNTP-Posting-Host: 12.230.124.133 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52.ops.asp.att.net 1021348776 12.230.124.133 (Tue, 14 May 2002 03:59:36 GMT) NNTP-Posting-Date: Tue, 14 May 2002 03:59:36 GMT Date: Tue, 14 May 2002 03:59:36 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!wn3feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17401 Steve Casselman wrote: > > > A key weakness of C, is the sequential nature of all descriptions, > > This is not really correct. C has lots of parallelism. It always amazes me > when people say there is no parallelism. Here is a line of very parallel C > code. > > a = b+c, d= e+f, Myfunc(); > > According to the C specs the above line can be executed in parallel. The > problem is if you can get different answers since the specs don't say what > order they must executed in if you do them one at a time. > example > > a = b , b = a ; > > Could be "a" and "b" have the value of "a" or they have the value of "b" or > "a" and "b" swap values. It's one of the reasons Java only has lists for > initializations. Useful parallelism would need to define what happens. Perhaps it would be better to state that C has no useful parallelism. Suppose I wanted to swap a and b in parallel, how could I do this in C? I can in other parallel languages. For example, in HandelC: par { a = b; b = a; } "a" and "b" will swap values. Or in VHDL: process (clk) begin if rising_edge(clk) then a <= b; b <= a; end if; end process; "a" and "b" will again swap values. -- Phil Hays ###### From: Buddy Smith Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 04:20:15 +0000 (UTC) Organization: Georgia Institute of Technology Lines: 20 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> <3CE08BC5.12AA0FFE@attbi.com> NNTP-Posting-Host: r57h202.res.gatech.edu X-Trace: news-int.gatech.edu 1021350015 25627 128.61.57.202 (14 May 2002 04:20:15 GMT) X-Complaints-To: usenet@news-int.gatech.edu NNTP-Posting-Date: Tue, 14 May 2002 04:20:15 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (Linux/2.4.18-xfs (i686)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub.sdsu.edu!csulb.edu!news-ext.gatech.edu!news-int.gatech.edu!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17426 Phil Hays wrote: > Or in VHDL: > > process (clk) begin > if rising_edge(clk) then > a <= b; > b <= a; > end if; > end process; > > "a" and "b" will again swap values. > Correct me if i'm wrong, but aren't processes in VHDL sequential? if you did this outside of a process, then they will swap values...but inside a process, you just made both a and b have the value of b. --buddy ###### From: "news.bellatlantic.net" Newsgroups: comp.arch.fpga References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> Subject: Re: Architecture for high-level reconfigurable computing Lines: 41 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Tue, 14 May 2002 04:32:25 GMT NNTP-Posting-Host: 151.203.24.31 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc02.gnilink.net 1021350745 151.203.24.31 (Tue, 14 May 2002 00:32:25 EDT) NNTP-Posting-Date: Tue, 14 May 2002 00:32:25 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.nuthinbutnews.com!propagator-sterling!news-in.nuthinbutnews.com!cyclone1.gnilink.net!spamfinder.gnilink.net!nwrddc02.gnilink.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17432 There's a big difference between having the programmer specify the parallelism, vs. hoping someday someone will figure out algorithms so that a compiler that can find it. Many man-years have been spent trying to make compilers that can find the inherent parallelism in a program, and so far only some loop-level parallelism can be exploited. Adding features to a language like fork and join with explicitly stated synchronization will get you to useful parallelism far sooner than waiting for the compiler that does it automatically. -Stan "Steve Casselman" wrote in message news:dAWD8.870$q67.72741089@newssvr14.news.prodigy.com... > > > A key weakness of C, is the sequential nature of all descriptions, > > > This is not really correct. C has lots of parallelism. It always amazes me > when people say there is no parallelism. Here is a line of very parallel C > code. > > a = b+c, d= e+f, Myfunc(); > > According to the C specs the above line can be executed in parallel. The > problem is if you can get different answers since the specs don't say what > order they must executed in if you do them one at a time. > example > > a = b , b = a ; > > Could be "a" and "b" have the value of "a" or they have the value of "b" or > "a" and "b" swap values. It's one of the reasons Java only has lists for > initializations. > > If you write a compiler you'll see what I mean. > > Steve > > ###### Message-ID: <3CE10038.A042D3B8@algor.co.uk> From: Rick Filipkiewicz X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!unknown@rfhome.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 28 Date: Tue, 14 May 2002 13:16:56 +0100 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 1021378615 62.254.210.251 (Tue, 14 May 2002 13:16:55 BST) NNTP-Posting-Date: Tue, 14 May 2002 13:16:55 BST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.icl.net!newsfeed.freenet.de!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newspeer1-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17410 Nicholas Weaver wrote: > Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key > is then loaded (through JTAG) into a distinct register on the part, > which has a separate power pin to maintain state. > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu The problem comes when, for some reason, the battery fails and the user's board is now dead [User "No I really really didn't try to change the battery with the board powered down, honest"]. To avoid being faked the only real way to deal with this is to offer a free ``return-to-base'' service. There was a long thread on this subject some time ago discussing the battery endurance necessary to maintain the 3DES keys. Peter/Austin: Do you have any real life experience on the VBATT current drain now the V-2's have been characterised ? Any recommendations or apps notes on battery types & circuits ? Is there, for example, any way of detecting the battery state from inside the chip to see if its dropped below 1V + some margin ? It might be worth a nA or 2 to have this feature. ###### From: Keith R. Williams Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 08:41:13 -0400 Organization: http://extra.newsguy.com Lines: 21 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> NNTP-Posting-Host: p-228.newsdawg.com X-Newsreader: MicroPlanet Gravity v2.60 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!newsfeed.r-kom.de!news.netcologne.de!news-xfer2.newshosting.com!news-out.newsfeeds.com!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!feed.newsfeeds.com!cyclone-sf.pbi.net!199.106.71.17!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews4 Xref: chonsp.franklin.ch comp.arch.fpga:17440 In article <3CE0874C.C18C852@earthlink.net>, palfke@earthlink.net says... > > > Tim wrote: > > > > > All together, for the umpteenth time: > > "Please can we have these few register bits as flash" > > Same answer for the umpteenth time: > "No, as long as that would mean sacrificing the standard, > high-volume and high-performance CMOS logic/microprocessor process". Tell > us how it can be done without significant impact on fab availability, > performance, and cost, and we will really listen. We are convinced these > conditions cannot be met today. Hope is eternal! Fuses? The problem then moves to test, but it's been done. ---- Keith ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 09:39:12 -0700 Organization: Xilinx, Inc. Lines: 14 Message-ID: <3CE13DB0.F6A37653@xilinx.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> NNTP-Posting-Host: 149.199.34.160 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en To: "Keith R. Williams" Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17411 "Keith R. Williams" wrote: > Fuses? The problem then moves to test, but it's been done. Fuses are ugly: 1. take lots of current to blow (big drivers) 2. are not good for keeping a secret ( easily detected ) 3. are inherently one-time-programmable, which does not sit well with the basic concept of our FPGAs Peter Alfke ###### From: Keith R. Williams Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 13:59:39 -0400 Organization: http://extra.newsguy.com Lines: 41 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> NNTP-Posting-Host: p-099.newsdawg.com X-Newsreader: MicroPlanet Gravity v2.60 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!news.maxwell.syr.edu!pln-e!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews2 Xref: chonsp.franklin.ch comp.arch.fpga:17434 In article <3CE13DB0.F6A37653@xilinx.com>, Peter.Alfke@xilinx.com says... > > > "Keith R. Williams" wrote: > > > Fuses? The problem then moves to test, but it's been done. > > Fuses are ugly: Crypto stuff tends to be ugly. Batteries have their ugly side too (flammability, waste hazard, PO'd customers...). > 1. take lots of current to blow (big drivers) True, though it is possible. > 2. are not good for keeping a secret ( easily detected ) It's done for cryptographically strong data (e.g. private keys) in FIPS 140-1 level-4 crypto equipment. Secrets are a pretty big deal in this application. > 3. are inherently one-time-programmable, which does not sit well with the basic > concept of our FPGAs A OTP key doesn't preclude a modified bitstream. The bitstream generator must know about it, of course. The key could even be blown at module test before shipment to company X under contract Y. Ugly, to be sure, but possible. The only issue I see here is whether or not customers are willing to pay for security. Of course, the question becomes, how much security at what cost? Xilinx has made a stab at it. ...been on all sides of this one. ---- Keith (not speaking for IBM) ###### From: micahjd@users.sourceforge.net (Micah Dowty) Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: 14 May 2002 11:37:40 -0700 Organization: http://groups.google.com/ Lines: 37 Message-ID: <37ce351d.0205141037.b48f444@posting.google.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <6ubsbjlqzk.fsf@chonsp.franklin.ch> NNTP-Posting-Host: 12.252.169.247 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1021401460 21245 127.0.0.1 (14 May 2002 18:37:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 14 May 2002 18:37:40 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17436 Neil Franklin wrote in message news:<6ubsbjlqzk.fsf@chonsp.franklin.ch>... > > That open source programmers accept non-supported stuff is a new thing > in FPGA development circles. They have still got to get used to our > different culture. Give them a bit of time and they will digest it. > Yep, hopefully. The extent of my FPGA experience has been a little work on video processing with the XC4000 and Spartan II families. I'm mostly a software guy.. I started a GUI for embedded systems a while ago (http://picogui.org) and among other things I wanted to experiment with a hardware version of its rendering pipeline, that could do things like compositing and primitive sorting in real time. But I'm also a fan of reconfigurable computing.. and of course I like to generalize everything :) > Try the following stuff: ... > Looking at how long your project will take (just defining your > language and how to split it CPU/FPGA), I will most likely have > that already finished before you get around to doing it. > > It has been on my project list for about 1 year, and now that my > job change is through, I can start off doing it. > > http://neil.franklin.ch/Projects/VirtexTools/ > Very nifty! I had actually seen your work a few days ago, but didn't know whether it was still active. Also, I knew about JBits, but was under the impression it could only modify the LUTs and BRAMs in existing designs, not route new ones. If JBits can in fact to routing, it sounds like a good interim solution to use until you reverse engineer the bitstream so we can have faster and open tools. --Micah ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: 14 May 2002 22:15:48 +0200 Organization: My own Private Self Lines: 29 Message-ID: <6u3cwu32q3.fsf@chonsp.franklin.ch> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1021407349 543 10.0.3.2 (14 May 2002 20:15:49 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 14 May 2002 20:15:49 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:17446 John Williams writes: > things about the bitstream format. In particular, we found a simple > method that could, in principle, be used to reverse engineer the > bitstream. Or more precisely, reverse engineer the relationship between > a placed and routed design, and the corresponding bitstream. The idea > of actually developing a tool to do the constrained routing etc just > makes my head hurt. For Virtex it is a bit simpler. The JBits docs actually show exactly how many wires and PIPs the routing consists of. And the library allows discovering them individually. For an _partial_ sketch (no hex and long lines), derived soley from that docu, no experimentation yet, see this: http://neil.franklin.ch/Projects/VirtexTools/Virtex-CLB-PIPs > Anyway let me know if you are really interested to hear more about the > bitstream stuff. Allways interested here. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Make your code truely free: put it into the public domain ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: 14 May 2002 22:34:37 +0200 Organization: My own Private Self Lines: 69 Message-ID: <6uznz21naa.fsf@chonsp.franklin.ch> References: <37ce351d.0205130901.3c70066f@posting.google.com> <6ubsbjlqzk.fsf@chonsp.franklin.ch> <37ce351d.0205141037.b48f444@posting.google.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1021408479 576 10.0.3.2 (14 May 2002 20:34:39 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 14 May 2002 20:34:39 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:17447 micahjd@users.sourceforge.net (Micah Dowty) writes: > Neil Franklin wrote in message news:<6ubsbjlqzk.fsf@chonsp.franklin.ch>... > > > > That open source programmers accept non-supported stuff is a new thing > > in FPGA development circles. They have still got to get used to our > > different culture. Give them a bit of time and they will digest it. > > mostly a software guy.. I started a GUI for embedded systems a while > ago (http://picogui.org) I have heard of its name, but never looked into its details. > and among other things I wanted to experiment > with a hardware version of its rendering pipeline, An open source graphics accelerator, nice. > also a fan of reconfigurable computing.. and of course I like to > generalize everything :) What hacker doesn't? ;-) > > http://neil.franklin.ch/Projects/VirtexTools/ > > I had actually seen your work a few days ago, but didn't know whether > it was still active. Not yet active. Waiting for the 3rd milestone of the PDP-10 before I really start on it. To follow current state of activity look at: http://neil.franklin.ch/Projects/VirtexTools/Logfile (freshly updated, just now) And for the PDP-10 project that is competing with it for my time look at: http://neil.franklin.ch/Projects/PDP-10/Logfile > Also, I knew about JBits, but was under the > impression it could only modify the LUTs and BRAMs in existing > designs, not route new ones. My entire PDP-10 clone FPGA CPU is written using only JBits. YOu can look at the source at: http://neil.franklin.ch/Projects/PDP-10/pdp10.java Limit is presently, that you need an empty bitfile to modify (programming is debugging an empty file, and so ...), and there are only XCV300/800/1000 coming with JBits. No Spartan-II compatible sizes. > If JBits can in fact to routing, it > sounds like a good interim solution to use until you reverse engineer > the bitstream so we can have faster and open tools. It can and it is. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Make your code truely free: put it into the public domain ###### From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 20:20:01 +0000 (UTC) Organization: Unknown Lines: 23 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE13DB0.F6A37653@xilinx.com> NNTP-Posting-Host: soda.csua.berkeley.edu X-Trace: agate.berkeley.edu 1021407601 84507 128.32.247.226 (14 May 2002 20:20:01 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Tue, 14 May 2002 20:20:01 +0000 (UTC) Originator: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17469 In article , Keith R. Williams wrote: >> 2. are not good for keeping a secret ( easily detected ) > >It's done for cryptographically strong data (e.g. private keys) in FIPS >140-1 level-4 crypto equipment. Secrets are a pretty big deal in this >application. Then again, look at the massive physical packaging to maintain that level of security in the IBM 4758 (Is this what you are referring to?). Also, I thought that they used SRAM, simply because it is much easier to zero out the contents when the physical tamper-sensor is disturbed, keeping the SRAM bits from being burned in by the use of occasional data moves. I wonder what sort of ram-keeper/ram-saver is used in the Virtex II mechanism? -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: Micah Dowty Subject: Re: Architecture for high-level reconfigurable computing Newsgroups: comp.arch.fpga Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> User-Agent: Pan/0.11.3 (Unix) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Comment-To: "Jim Granville" Lines: 61 NNTP-Posting-Host: 12.252.169.247 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc01 1021407802 12.252.169.247 (Tue, 14 May 2002 20:23:22 GMT) NNTP-Posting-Date: Tue, 14 May 2002 20:23:22 GMT Organization: AT&T Broadband Date: Tue, 14 May 2002 20:23:22 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!wn3feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc01.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17452 That's pretty much what I was figuring. You would be able to program software objects in any existing language, and hardware or software objects in the new language. Existing software languages could use a shared library to send/recieve messages with other objects (software or hardware) and native message sending support could be used where applicable (in languages like Objective C). The new language would compile each object to software and to hardware. The decision of which objects to implement in hardware could be made automatically (by available FPGA space and software CPU utilization) or hinted by the programmer. Each software/hardware object would share a relatively low speed message passing bus, plus there could be some way to do faster direct data transfer. This could be done between hardware components by directly routing wires between the objects, and it could be done between hardware and software objects using DMA. I would prefer to stay away from .NET, for a few reasons... - For software-only components any language should work - For the software/hardware components, I haven't seen a language that really satisfies the requirements fully - I'm an open source geek, I'd rather not use a microsoft product :) That said, I'll be thinking about the design of this language. Since it needs to be easy to use for non-EE software people, there needs to be an easy way to specify sequential operation, but parallel operations must be intuitive enough that the programmer doesn't overlook them. Handel-C fits this bill, but besides the problem of it being proprietary, it doesn't support the dynamically loaded objects and message passing. Maybe what we need is something like a Handel-C++. On Mon, 13 May 2002 15:05:43 -0600, Jim Granville wrote: > The best 'horizon' approach would be > > - A language that is inherently parallel and capable of HW description > (More than one language support would be good : some problems suit > some languages better than others). > > - A three way path for that language, to allow > a) Run on a PC/ARM/PPC etc HW, ie Hard core with maximal resource b) > Run on a soft-core, ie FPGA core with minimal resource c) Run in FPGA > HW > > Some discussion on Java in FPGA's is already underway, another > pathway would be to implement .NET MSIL in FPGA/Softcore combination. > > .NET is new, but already looks a more stable pivot point than Java > flavours, > and .NET has good language support already - See > > http://msdn.microsoft.com/vstudio/partners/language/default.asp > > This would lead to .NET core(s) in FPGA, with key code sections chosen > as > FPGA-Macros, running as a system. > > jg ###### From: Keith R. Williams Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 16:31:18 -0400 Organization: http://extra.newsguy.com Lines: 48 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE161BB.801C40DB@xilinx.com> NNTP-Posting-Host: p-791.newsdawg.com X-Newsreader: MicroPlanet Gravity v2.60 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews2 Xref: chonsp.franklin.ch comp.arch.fpga:17477 In article <3CE161BB.801C40DB@xilinx.com>, Peter.Alfke@xilinx.com says... > I do not have the statistics about what users do with our parts, nobody really has. Are FAEs encouraged to feed back such requirements? How about cost sensitivity to real solutions? Fuses are cheap, by the dozen. However, if there are billions unused, then the dozen used get expensive. > That's the beauty of FPGAs; users can do anything they please, without telling us > about it ( life support equipment being explicitly excluded, see one of the first > pages of our data book). The first time I saw the "life support" issue was when perusing a Nat- Semi databook some thirty years ago. I thought it strange, until I thought about it a few microseconds. > So I don't know this for sure, but I venture to guess that there are more people who > have voiced opinions here about battery reliability and alternate security solutions, > than there are designers who have actually used the free encryption we offer. I've dealt with batteries. What a PITA! I'd be more wary about PO'd customers than a few stealing the products. When it's crypto stuff, the customer's data is far more important than my design. The tables turn. > Security was often "very important" while it was not available, but then turned into > a big yawn when it became available. Honestly, it's of no concern for the FPGA application I've had. I can see where it's a nice feature. Don't get me wrong, I'm not complaining about Xilinx' design point. It seems to be a cheap solution to at least part of the problem. Anything more complex could cost everyone. I don't think that's the right answer for the market. My only point is that there are solutions to this problem, though perhaps not simple. Similar things have been done (though I don't know about the IP status). > Maybe that's just human nature... True. "I want it, and I want it free" is human nature. "I need it and now" is definitely PHB nature. ;-) ---- Keith (not speaking for IBM) ###### From: Micah Dowty Subject: Re: Architecture for high-level reconfigurable computing Newsgroups: comp.arch.fpga Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <6ubsbjlqzk.fsf@chonsp.franklin.ch> <37ce351d.0205141037.b48f444@posting.google.com> <6uznz21naa.fsf@chonsp.franklin.ch> User-Agent: Pan/0.11.3 (Unix) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Comment-To: "Neil Franklin" Lines: 14 NNTP-Posting-Host: 12.252.169.247 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc54 1021410711 12.252.169.247 (Tue, 14 May 2002 21:11:51 GMT) NNTP-Posting-Date: Tue, 14 May 2002 21:11:51 GMT Organization: AT&T Broadband Date: Tue, 14 May 2002 21:11:51 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc54.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17453 On Tue, 14 May 2002 14:34:37 -0600, Neil Franklin wrote: >> If JBits can in fact to routing, it >> sounds like a good interim solution to use until you reverse engineer >> the bitstream so we can have faster and open tools. > > It can and it is. > Sounds like it would be useful to have an intermediate format that could be fed into a JBits-based tool or into your open tools. Are there already any good formats for this? --Micah ###### Message-ID: <3CE18569.6121@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 40 Date: Wed, 15 May 2002 09:45:13 +1200 NNTP-Posting-Host: 203.79.98.238 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1021412726 203.79.98.238 (Wed, 15 May 2002 09:45:26 NZST) NNTP-Posting-Date: Wed, 15 May 2002 09:45:26 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xmission!news-out.spamkiller.net!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17460 Peter Alfke wrote: > > "Keith R. Williams" wrote: > > > Fuses? The problem then moves to test, but it's been done. > > Fuses are ugly: > 1. take lots of current to blow (big drivers) > 2. are not good for keeping a secret ( easily detected ) > 3. are inherently one-time-programmable, which does not sit well with the basic > concept of our FPGAs > > Peter Alfke On a more up-to-date front than fuses, has Xilinx looked at this : http://www.viragelogic.com/products/compilers/novea/index.jsp http://www.viragelogic.com/products/datasheets/NOVeA_family_datasheet.pdf They claim TSMC process compatible, and : # NOVeA is a non-volatile memory that can be reprogrammed multiple # times. Additionally, this memory can be embedded into a SoC and can be # fabricated in a state-of-the-art, leading edge standard logic process # with no additional process steps. Integrating NOVeA will help reduce # overall system costs, increase performance and security and greatly # decrease the time to market. This is not large capacity, so not suited to the whole bitstream, but does look a candidate for security, and serial numbering applications. Xilinx could even use this to put another spin on their Yield-Recovery offerings of 'Device does not fully pass test' pathways :) ie Turn the FPGA into a Hard Drive in nature, with 'bad sector' mapping. -- oops, now it's in the public domain, I can't patent this. -jg ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 14:57:28 -0700 Organization: Xilinx Lines: 48 Message-ID: <3CE18848.791E9326@xilinx.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!wn3feed!wn1feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!12.120.28.17!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17448 Jim, Yup. Been there, done that. No news. Nothing there. Austin Jim Granville wrote: > Peter Alfke wrote: > > > > "Keith R. Williams" wrote: > > > > > Fuses? The problem then moves to test, but it's been done. > > > > Fuses are ugly: > > 1. take lots of current to blow (big drivers) > > 2. are not good for keeping a secret ( easily detected ) > > 3. are inherently one-time-programmable, which does not sit well with the basic > > concept of our FPGAs > > > > Peter Alfke > > On a more up-to-date front than fuses, has Xilinx looked at this : > > http://www.viragelogic.com/products/compilers/novea/index.jsp > > http://www.viragelogic.com/products/datasheets/NOVeA_family_datasheet.pdf > > They claim TSMC process compatible, and : > # NOVeA is a non-volatile memory that can be reprogrammed multiple > # times. Additionally, this memory can be embedded into a SoC and can be > # fabricated in a state-of-the-art, leading edge standard logic process > # with no additional process steps. Integrating NOVeA will help reduce > # overall system costs, increase performance and security and greatly > # decrease the time to market. > > This is not large capacity, so not suited to the whole bitstream, but > does look a candidate for security, and serial numbering applications. > > Xilinx could even use this to put another spin on their Yield-Recovery > offerings of 'Device does not fully pass test' pathways :) > > ie Turn the FPGA into a Hard Drive in nature, with 'bad sector' > mapping. > -- oops, now it's in the public domain, I can't patent this. > > -jg ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 23:49:53 +0100 Message-ID: <1021419886.18531.0.nnrp-13.9e9832fa@news.demon.co.uk> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1021419886 nnrp-13:18531 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 23 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!kibo.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17481 Steve Casselman wrote > Yes the other way in C is to have functions that run in parallel like > threads. The compiler must be smart enough to infer real parallel hardware. > Also if you take the list operator and define the behavior as fully parallel > then C does not seem sequential. Handel-C does that - the good bits of CSP, with C-flavored syntax. And it still ain't quite what the market wants. Not even old Occam hackers like me. Though maybe if I was given a chunk of C to "accellerate"... Even then, I would need to be convinced that C->Handel is way faster than C->VHDL for anyone except a Handel enthusiast. ###### Message-ID: <3CE19CCA.2F4C@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 10 Date: Wed, 15 May 2002 11:24:58 +1200 NNTP-Posting-Host: 203.79.98.238 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1021418709 203.79.98.238 (Wed, 15 May 2002 11:25:09 NZST) NNTP-Posting-Date: Wed, 15 May 2002 11:25:09 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!news-out.newsfeeds.com!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17464 Austin Lesea wrote: > > Jim, > > Yup. Been there, done that. No news. Nothing there. You mean it has more 'qualifications' and 'vaporware nature' than suggested by their marketing info :) -jg ###### From: samg@codenet.net Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Wed, 15 May 2002 01:42:17 GMT Organization: http://extra.newsguy.com Lines: 44 Message-ID: <3ce1bc4b.3133345@news.newsguy.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <3CE10038.A042D3B8@algor.co.uk> Reply-To: samg@codenet.net NNTP-Posting-Host: p-492.newsdawg.com X-Newsreader: Forte Free Agent 1.21/32.243 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews3 Xref: chonsp.franklin.ch comp.arch.fpga:17466 On Tue, 14 May 2002 13:16:56 +0100, Rick Filipkiewicz wrote: > > >Nicholas Weaver wrote: > >> Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key >> is then loaded (through JTAG) into a distinct register on the part, >> which has a separate power pin to maintain state. >> -- >> Nicholas C. Weaver nweaver@cs.berkeley.edu > >The problem comes when, for some reason, the battery fails and the user's >board is now dead [User "No I really really didn't try to change the battery >with the board powered down, honest"]. To avoid being faked the only real way >to deal with this is to offer a free ``return-to-base'' service. > >There was a long thread on this subject some time ago discussing the battery >endurance necessary to maintain the 3DES keys. > >Peter/Austin: Do you have any real life experience on the VBATT current drain >now the V-2's have been characterised ? Any recommendations or apps notes on >battery types & circuits ? > >Is there, for example, any way of detecting the battery state from inside the >chip to see if its dropped below 1V + some margin ? It might be worth a nA or >2 to have this feature. > This was/is a real issue on Capcom based Arcade boards that would die if the watch battery was removed. You had to send it back to their tech service area to replace the battery and reinstall the key. I don't think it is all that bad of an idea in a final product but not on a prototyping product. You are right that it is too easy to clear the memory key. Regards, Sam ###### From: samg@codenet.net Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Wed, 15 May 2002 01:44:28 GMT Organization: http://extra.newsguy.com Lines: 39 Message-ID: <3ce1bd2f.3360832@news.newsguy.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> Reply-To: samg@codenet.net NNTP-Posting-Host: p-555.newsdawg.com X-Newsreader: Forte Free Agent 1.21/32.243 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews3 Xref: chonsp.franklin.ch comp.arch.fpga:17467 On Tue, 14 May 2002 19:47:22 GMT, "Steve Casselman" wrote: >As FPGAs get more popular people will just get together and figure out the >bitstream anyway. So why not just publish the whole thing and get it over >with? All your doing is making people jump through hoops. With the little >information already published people are already making tools. Imagine if >Intel had you encrypt all your programs because some people were afraid of >having their programs decompiled? The software world would be in the stone >age. And that is where we are as far as programming FPGAs. Maybe someone at >GNU will start hacking away. I don't think it would take much. > >Steve > > >"Peter Alfke" wrote in message >news:3CE03B81.B6624D70@xilinx.com... > > >> 1. >> It might make some users feel vulnerable that their design can be >> reverse-engineered and then slightly modified to hide the rip-off. >> >> 2. >> It might expose Xilinx to unreasonable and unsupportable user questions, >> especially when they painted themselves into a corner. And he who sells >the >> chips ultimately is stuck with the cry for help... >> >> Peter Alfke >> > > Check out the Icarus project. (www.icarus.com) Stephen Williams has work to create a Verilog simulator with a FPGA synthesis tool built into it. The code is GPL, it might be an interesting place to start. Sam ###### From: Keith R. Williams Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Tue, 14 May 2002 22:13:07 -0400 Organization: http://extra.newsguy.com Lines: 61 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE13DB0.F6A37653@xilinx.com> NNTP-Posting-Host: p-826.newsdawg.com X-Newsreader: MicroPlanet Gravity v2.60 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!pln-e!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews3 Xref: chonsp.franklin.ch comp.arch.fpga:17479 In article , nweaver@CSUA.Berkeley.EDU says... > In article , > Keith R. Williams wrote: > > >> 2. are not good for keeping a secret ( easily detected ) > > > >It's done for cryptographically strong data (e.g. private keys) in FIPS > >140-1 level-4 crypto equipment. Secrets are a pretty big deal in this > >application. > > Then again, look at the massive physical packaging to maintain that > level of security in the IBM 4758 (Is this what you are referring > to?). No, I was referring to the current (though I've been out of the business for almost ten years) mainframe integrated crypto stuff. The secure wall is done on chip for these things. Understand that I did the physical security, master key storage, and user interface on the original mainframe (ES3090, then ES9000) crypto hardware. Yes, this stuff was massively expensive. The later fuse/asymmetric key stuff nearly as bad. Depending on the security requirements it can be rather simple to do, or expensive. > Also, I thought that they used SRAM, simply because it is much easier > to zero out the contents when the physical tamper-sensor is disturbed, > keeping the SRAM bits from being burned in by the use of occasional > data moves. Well... I proposed my solution (six copies of the master keys, constantly scrubbed and flipped) to the 4758 folks... ;-) They insisted on a radiation detector. The "sensor" wasn't specified for the purpose and I didn't want to *ever* tell our customer that they'd been nuked unless the system was glowing. Engineers differ and customers differ. The intended user of my UI was a major bank VP. "You're dead" wasn't something I wanted to tell them. ...particularly when I had no way of testing the "you're dead" sensor. > I wonder what sort of ram-keeper/ram-saver is used in the Virtex II > mechanism? I don't think cryptographic security is a design point for Xilinx. An FPGA with crypto-clearance! What a concept! ;-) My point is that such things *are* possible. The level of security I've seen requested on this NG is well within the possible. The question, as Peter has asked, is how interested *are* people in bitstream security? I'm betting, as Xilinx has, not very. OTOH, I agree with the other side, batteries to hold config keys are a *bad* idea. The customer problems are likely to outstrip any benefit. That decision is up to the developer and the PHBs. I know I wouldn't be happy doing it. ---- Keith ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Wed, 15 May 2002 08:03:24 -0700 Organization: Xilinx Lines: 45 Message-ID: <3CE278BC.AC460E55@xilinx.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!news-out.nuthinbutnews.com!propagator-sterling!news-in.nuthinbutnews.com!cyclone1.gnilink.net!washdc3-snf1!washdc3-snh1.gtei.net!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17454 Jim, I didn't say that, but you guessed it. In all fairness, as the we descend into the UDSM world, all foundries have NVRAM/ROM (read: fuse) type cells that they are offering (eg in 0.1u). This is good, as if you use them, they will support them. Their programming voltages, retention, etc. is all characterized, and the cells to store, readback, and write, are all IP that the foundry will support if you use it exactly as they propose. As with all IP, one pays for it if it is worth anything. That isn't the issue here, as having even 1K bits of NVRAM/ROM would be useful in an FPGA, so as a percentage of the die, it is almost invisible. We are just working with our foundries to engage when we see that the technology will support what we need to accomplish. It is still scarey, as at 0.1u the reason why these cells work, is that they are so easy to blow up (ie make a 0, instead of a 1). Obviously, we are not into fuse (or anti-fuses), and have a long tradition of SRAM based FPGAs and EEPROM, EPROM based CPLDs. Fuses just make us nervous ..... did they blow? did we blow something else? Will they heal? etc. Right now, if a foundry is asked what the reliability of their 0.1u NV technology is, you can't expect an answer .... no one has built enough of anything yet to run a reliability study on. Austin Jim Granville wrote: > Austin Lesea wrote: > > > > Jim, > > > > Yup. Been there, done that. No news. Nothing there. > > You mean it has more 'qualifications' and 'vaporware nature' > than suggested by their marketing info :) > > -jg ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Wed, 15 May 2002 08:12:17 -0700 Organization: Xilinx Lines: 64 Message-ID: <3CE27AD1.F1E3BA26@xilinx.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <3CE10038.A042D3B8@algor.co.uk> <3ce1bc4b.3133345@news.newsguy.com> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.nuthinbutnews.com!propagator-sterling!news-in.nuthinbutnews.com!cyclone1.gnilink.net!washdc3-snf1!washdc3-snh1.gtei.net!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17455 Sam, Battery backup is an old, old technology. You get one of those "supercaps" that is ~ 1F. You also get a 150 mAHr coin cell. You connect the Vbatt pin to the supercap through a 100K ohm resistor. You connect the supercap to the battery through another 100K ohm resistor. If you pull the battery, it takes a long long time to lose the key (and that only happens if the power is off, as well). If the battery dies (i.e. you bought the wrong battery, as a lithium cell lasts twenty years -- I have replaced my camera's lithium cell once in the last 29 years), then when power is removed, the key goes away after the supercap has discharged. The current drain is 0.1 nA, max (was not tested on early ES, so some parts were leaky, and the batteries could and did get exhausted, but we fixed that in the test program). I=CdV/dt, or dt= C dV/I, and C = 1, V = 2V (assume 3 V discharges to 1V), and I = 1E-10, so dt = 3E10 seconds. Now the supercap can't be that good, so it is whatever the self discharge rate is of the supercap. Could be weeks. Austin samg@codenet.net wrote: > On Tue, 14 May 2002 13:16:56 +0100, Rick Filipkiewicz > wrote: > > > > > > >Nicholas Weaver wrote: > > > >> Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key > >> is then loaded (through JTAG) into a distinct register on the part, > >> which has a separate power pin to maintain state. > >> -- > >> Nicholas C. Weaver nweaver@cs.berkeley.edu > > > >The problem comes when, for some reason, the battery fails and the user's > >board is now dead [User "No I really really didn't try to change the battery > >with the board powered down, honest"]. To avoid being faked the only real way > >to deal with this is to offer a free ``return-to-base'' service. > > > >There was a long thread on this subject some time ago discussing the battery > >endurance necessary to maintain the 3DES keys. > > > >Peter/Austin: Do you have any real life experience on the VBATT current drain > >now the V-2's have been characterised ? Any recommendations or apps notes on > >battery types & circuits ? > > > >Is there, for example, any way of detecting the battery state from inside the > >chip to see if its dropped below 1V + some margin ? It might be worth a nA or > >2 to have this feature. > > > This was/is a real issue on Capcom based Arcade boards that would die > if the watch battery was removed. You had to send it back to their > tech service area to replace the battery and reinstall the key. > I don't think it is all that bad of an idea in a final product but not > on a prototyping product. You are right that it is too easy to clear > the memory key. > > Regards, > Sam ###### Message-ID: <3CE28E71.EA694FF8@algor.co.uk> From: Rick Filipkiewicz X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <3CE10038.A042D3B8@algor.co.uk> <3ce1bc4b.3133345@news.newsguy.com> <3CE27AD1.F1E3BA26@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!unknown@rfhome.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 8 Date: Wed, 15 May 2002 17:36:01 +0100 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 1021480560 62.254.210.251 (Wed, 15 May 2002 17:36:00 BST) NNTP-Posting-Date: Wed, 15 May 2002 17:36:00 BST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.clara.net!heighliner.fr.clara.net!newsfeed.vmunix.org!peernews!peer.cwci.net!newspeer1-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17458 Austin Lesea wrote: > The current drain is 0.1 nA, max (was not tested on early ES ... The Jan 2002 V-2 data sheet shows IBATT (max) = 100nA ? ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: 15 May 2002 21:31:48 +0200 Organization: My own Private Self Lines: 59 Message-ID: <6u4rh95hsr.fsf@chonsp.franklin.ch> References: <37ce351d.0205130901.3c70066f@posting.google.com> <6ubsbjlqzk.fsf@chonsp.franklin.ch> <37ce351d.0205141037.b48f444@posting.google.com> <6uznz21naa.fsf@chonsp.franklin.ch> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1021491108 2311 10.0.3.2 (15 May 2002 19:31:48 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 15 May 2002 19:31:48 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:17484 Micah Dowty writes: > On Tue, 14 May 2002 14:34:37 -0600, Neil Franklin wrote: > > >> If JBits can in fact to routing, it > >> sounds like a good interim solution to use until you reverse engineer > >> the bitstream so we can have faster and open tools. > > > > It can and it is. > > Sounds like it would be useful to have an intermediate format that could > be fed into a JBits-based tool or into your open tools. Are there already > any good formats for this? Never heard of one. But also never looked for one, so above does not mean much. FYI: I am presently aiming that my tools will be 2-level: - an .so library (libvirtex) with an API of functions, callable from C (or possibly also perl). - an assembler-like program (vas) that uses above library, and reads an abstracted assembly-like source file. Aim of that is that then VHDL/Verilog/... compilers can target 'vas' to make the bitstream, the same as the gcc C/Fortran/... compilers target 'as' to make the binaries. I _perhaps_ may develop the 'vas' source language still using JBits, i.e. there would in the end exist 2 assemblers for it, one written in Java/JBits and one in C/libvirtex. This source form may be usefull as an intermediate form for you: design---your-Tool---C/gcc---as-------------binary for CPU `---X/???---vas/libvirtex--bitstream for FPGA `-vas/JBits-----' Of course this language is not yet defined, so it may be no more use to you than waiting till I am finished. So perhaps better to use direct JBits and then convert. For an preview of the ideas going into developing this language, look at the style adopted in my PDP-10 code. Particularly how I wrap the JBits API with the stuff in the first larger section of the code. P.S: I am now going offline for 5 days, visiting the anual German/Swiss/Austrian Linux User Group meeting. They should have Internet there, but last year it sucked so bad that even ssh failled. So I do not expect to be able to Usenet while there. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Make your code truely free: put it into the public domain ###### From: gah@ugcs.caltech.edu (glen herrmannsfeldt) Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: 15 May 2002 20:25:47 GMT Organization: California Institute of Technology, Pasadena Lines: 15 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> NNTP-Posting-Host: seniti.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #1 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!nntp-server.caltech.edu!gah Xref: chonsp.franklin.ch comp.arch.fpga:17567 "Steve Casselman" writes: >Yes the other way in C is to have functions that run in parallel like >threads. The compiler must be smart enough to infer real parallel hardware. >Also if you take the list operator and define the behavior as fully parallel >then C does not seem sequential. Say I take an FFT algorithm from Numerical Recipes in C. What is the chance that I will find a compiler that can generate a reasonable FPGA implementation of that algorithm, say in the next 5 years to give someone a chance? -- glen ###### Message-ID: <3CE2F5A8.1BB9@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> <3CE278BC.AC460E55@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 23 Date: Thu, 16 May 2002 11:56:24 +1200 NNTP-Posting-Host: 203.79.98.118 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1021506997 203.79.98.118 (Thu, 16 May 2002 11:56:37 NZST) NNTP-Posting-Date: Thu, 16 May 2002 11:56:37 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xmission!news-out.spamkiller.net!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17563 Austin Lesea wrote: > > Jim, > > I didn't say that, but you guessed it. > > In all fairness, as the we descend into the UDSM world, all foundries > have NVRAM/ROM (read: fuse) type cells that they are offering (eg in > 0.1u). Yes, but virage claim not ROM, but EE cells, supposedly on a Std CMOS process. # NOVeA is a non-volatile memory that can be reprogrammed multiple # times. Additionally, this memory can be embedded into a SoC and can be # fabricated in a state-of-the-art, leading edge standard logic process # with no additional process steps. I do note they mention TSMC, but not UMC :-) Does sound like a free lunch - anyone used these cells ? -jg ###### From: Keith R. Williams Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Wed, 15 May 2002 22:07:22 -0400 Organization: http://extra.newsguy.com Lines: 51 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> <3CE278BC.AC460E55@xilinx.com> NNTP-Posting-Host: p-979.newsdawg.com X-Newsreader: MicroPlanet Gravity v2.60 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews2 Xref: chonsp.franklin.ch comp.arch.fpga:17633 In article <3CE278BC.AC460E55@xilinx.com>, austin.lesea@xilinx.com says... > Obviously, we are not into fuse (or anti-fuses), and have a long > tradition of SRAM based FPGAs and EEPROM, EPROM based CPLDs. Fuses just > make us nervous ..... did they blow? did we blow something else? Will > they heal? etc. Right now, if a foundry is asked what the reliability > of their 0.1u NV technology is, you can't expect an answer .... no one > has built enough of anything yet to run a reliability study on. Obviously you have your (official Xilinx) bias. It's been stated with no uncertain terms. The fact is that these things have been used for at least ten years. They've been used for similar applications for nearly as long (I personally know of such). I'm on the other side of this fence, I *hate* batteries and as long as I work for my current employer I hope I won't be forced onto that pyre again. Read the specs all you want, but batteries are not nice. As an example, think about storage of replacement parts in uncontrolled wharehouses in the middle of a desert! Batteries are *bad* news. Your specs of .1nA don't impress me either (if that is even the right number). It's *easy* to have contaminates on the board that have more leakage. Anyone who's had a PC die because the frappin' battery went west knows this. Reasonable people can differ in opinions, but your faith in batteries is very much displaced. Some of us have *no* faith in batteries and have much experience with fuses. Don't tell me fuses cannot be done, because I know better. Xilinx *chooses* not to go there. That's a business decision and that's acceptable. ...unless one needs real security and reliability. Yes, I consider "forever-caps" toys in this application. Consider a compu-nerd: takes the card out and lays it on his anti-stat- mat and then leaves for the weekend. For most cards, not a biggie! For the Xilinx customer's card? I really like Xilinx products, the company, the whole idea, but I don't understand the refusal to understand the other side's problems. I've been a lurker here for three years, occasionally adding something when I can. When it comes to some serious issues with the "Xilinx way" I see nothing but defense. Yes, some of us have been well roasted by things you consider "trivial". ---- Keith ###### Message-ID: <3CE32E1F.62854C2B@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> <3CE278BC.AC460E55@xilinx.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 50 Date: Thu, 16 May 2002 03:57:34 GMT NNTP-Posting-Host: 209.179.200.204 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1021521454 209.179.200.204 (Wed, 15 May 2002 20:57:34 PDT) NNTP-Posting-Date: Wed, 15 May 2002 20:57:34 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!hermes.visi.com!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17547 "Keith R. Williams" wrote: > Obviously you have your (official Xilinx) bias. It's been stated > with no uncertain terms. > > > I really like Xilinx products, the company, the whole idea, but I > don't understand the refusal to understand the other side's > problems. I've been a lurker here for three years, occasionally > adding something when I can. When it comes to some serious > issues with the "Xilinx way" I see nothing but defense. Yes, > some of us have been well roasted by things you consider > "trivial". > > ---- > Keith Keith, both Austin and I make no secret about the fact that we are loyal Xilinx employees. As such we will not attack our company in a public forum. But we are also engineers, so we will represent Xilinx in a rational way. Non-volatile memory in a CMOS process is not a trivial issue, and Xilinx developers have struggled with this issue for years. Austin and I have given inputs about the desirability, and about the many attractive possibilities that would come with such a solution. Our processing folks ( yes, we have dozens of them, even though we are a fabless company) listen to these inputs, and take them into consideration, together with many other requirements. Like the need for process migration to ever smaller geometries, compatibility with different fabs, speed, cost, reliability, etc. Weighted against all these sometimes conflicting choices and trade-offs, non-volatile storage has not made it. Other things were more important. And I can live with those priorities. My personal opinion is that it might have made it, if the fate our company were depending on it, but that is clearly not the case. Other things are far more important. So, for the time being, we are without such a capability. It still is very much on our wish list, but we concede that there are other priorities. That's why Austin and I defend the present situation, and explain the realistic user options. Publicly, we are applications engineers who understand how to build systems using our existing devices and technology. Inside Xilinx, we may rant and rave and fight and disagree about dfferent options, but outside we try to help you use our parts in the best way. Pretty obvious, isn't it. End of soapbox. Peter Alfke, Xilinx Applications ###### From: "Bryan" Newsgroups: comp.arch.fpga References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE02AA7.2BEF@designtools.co.nz> Subject: Re: Architecture for high-level reconfigurable computing Date: Thu, 16 May 2002 09:09:51 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 25 Message-ID: <3ce3cc5e$0$6550$4c41069e@reader0.ash.ops.us.uu.net> NNTP-Posting-Host: 65.212.36.10 X-Trace: 1021561950 reader0.ash.ops.us.uu.net 6550 65.212.36.10 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!spool0900.news.uu.net!reader0900.news.uu.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17649 www.srccomp.com "glen herrmannsfeldt" wrote in message news:abug8b$4al@gap.cco.caltech.edu... > "Steve Casselman" writes: > > >Yes the other way in C is to have functions that run in parallel like > >threads. The compiler must be smart enough to infer real parallel hardware. > >Also if you take the list operator and define the behavior as fully parallel > >then C does not seem sequential. > > Say I take an FFT algorithm from Numerical Recipes in C. > > What is the chance that I will find a compiler that can generate > a reasonable FPGA implementation of that algorithm, say in the > next 5 years to give someone a chance? > > -- glen > ###### From: Keith R. Williams Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Thu, 16 May 2002 23:02:46 -0400 Organization: http://extra.newsguy.com Lines: 102 Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> <3CE278BC.AC460E55@xilinx.com> <3CE32E1F.62854C2B@earthlink.net> NNTP-Posting-Host: p-774.newsdawg.com X-Newsreader: MicroPlanet Gravity v2.60 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews1 Xref: chonsp.franklin.ch comp.arch.fpga:17631 In article <3CE32E1F.62854C2B@earthlink.net>, palfke@earthlink.net says... > > > "Keith R. Williams" wrote: > > > Obviously you have your (official Xilinx) bias. It's been stated > > with no uncertain terms. > > > > > > > I really like Xilinx products, the company, the whole idea, but I > > don't understand the refusal to understand the other side's > > problems. I've been a lurker here for three years, occasionally > > adding something when I can. When it comes to some serious > > issues with the "Xilinx way" I see nothing but defense. Yes, > > some of us have been well roasted by things you consider > > "trivial". > > > > ---- > > Keith > > Keith, both Austin and I make no secret about the fact that we are loyal > Xilinx employees. As such we will not attack our company in a public forum. I have no problem with that. I appreciate what you folks are doing on this forum. > But we are also engineers, so we will represent Xilinx in a rational way. > Non-volatile memory in a CMOS process is not a trivial issue, and Xilinx > developers have struggled with this issue for years. Austin and I have given > inputs about the desirability, and about the many attractive possibilities > that would come with such a solution. Fine. My point is that this issue has been covered for ten years. I know nothing (ok, small lie) about your foundry efforts, but I can assure you that reliable fuses have been around for years. My example of the mainframe crypto stuff (almost ten years ago) was an attempt to show that what the customers are asking for is bit only possible, but reliable. Sheesh! All D/SRAM manufacturers have some sort of fuse technology for redundancy. This isn't rocket-surgery anymore. > Our processing folks ( yes, we have dozens of them, even though we are a > fabless company) listen to these inputs, and take them into consideration, > together with many other requirements. Like the need for process migration to > ever smaller geometries, compatibility with different fabs, speed, cost, > reliability, etc. "Cost" is the only part of this I understand. That "cost" is not in the process, but rather "we've caught the car, now what do we do with it?". > Weighted against all these sometimes conflicting choices and trade-offs, > non-volatile storage has not made it. Other things were more important. And I > can live with those priorities. I can live within your priorities as well, but don't tell us the technology isn't available. It is! The only question is business. If no one wants to *pay* for security, then it's not to be. Certainly there are issues that are specific to FPGAs, but they are not a problem with your desired technology. > My personal opinion is that it might have made it, if the fate our company > were depending on it, but that is clearly not the case. Other things are far > more important. That, is the bottom line. If you (collective) believe the fate of Xilinx depends on not offering some real security, I have no problem with the decision. Please don't tell us it's a technology problem. I've seen what has been proposed, in *spades* (every chip with a unique public/private 2048bit key). ...in a process far older than what you're currently using. Reliability? Please! > So, for the time being, we are without such a capability. It still is very > much on our wish list, but we concede that there are other priorities. That's > why Austin and I defend the present situation, and explain the realistic user > options. Publicly, we are applications engineers who understand how to build > systems using our existing devices and technology. Inside Xilinx, we may rant > and rave and fight and disagree about dfferent options, but outside we try to > help you use our parts in the best way. Pretty obvious, isn't it. I have no real problem with your business decision. Your argument about the technology not being there is, in my opinion, bogus. It's been there for *years* and it's cheap. Again, even DRAM manufacturers use it. *THAT'S* cheap. I dispute your (Austin included) claim that fuses are strange/unreliable/dangerous. Yes, there are issues with them. ...as there are with everything else about this business. > End of soapbox. I'd like to know if people *really* want security (as in paying for it). Since I worked in secure/crypto hardware for some years it's kinda a side interest for me. The technology is not only available, but cheap. The management of any real security is the real problem. ---- Keith ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Fri, 17 May 2002 11:13:31 +0100 Message-ID: <1021635310.14469.0.nnrp-10.9e9832fa@news.demon.co.uk> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> <3CE278BC.AC460E55@xilinx.com> <3CE32E1F.62854C2B@earthlink.net> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1021635310 nnrp-10:14469 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 21 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!news-lei1.dfn.de!newsfeed00.sul.t-online.de!t-online.de!kibo.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17638 Keith R. Williams wrote > I'd like to know if people *really* want security (as in paying > for it). Since I worked in secure/crypto hardware for some years > it's kinda a side interest for me. The technology is not only > available, but cheap. The management of any real security is the > real problem. Yes, worth paying for. Though not worth the cost and problems of the battery solution. Mostly my customers just want to raise the bar on copying. Program a (secret) key into the chip at manufacturing time, then the copiers would not be able to use your bitstream without cracking the key. Of course they would still be able to work the problem from other angles, but the other angles are all significantly more difficult than just copying a bit stream. ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Fri, 17 May 2002 10:17:35 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <37ce351d.0205130901.3c70066f@posting.google.com> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> <3CE278BC.AC460E55@xilinx.com> <3CE32E1F.62854C2B@earthlink.net> X-Complaints-To: newsabuse@supernews.com Lines: 20 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!isdnet!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:17589 >I'd like to know if people *really* want security (as in paying >for it). Since I worked in secure/crypto hardware for some years >it's kinda a side interest for me. The technology is not only >available, but cheap. The management of any real security is the >real problem. I have one data point. I worked on one card that got to production. It was an early ATM card, expensive, but worked well, and it was available "now". We didn't worry about getting cloned - never thought about it. I'll bet if somebody wanted to clone it we would have given them the whole package as long as they would sell boards back to us. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Fri, 17 May 2002 08:51:45 -0700 Organization: Xilinx, Inc. Lines: 14 Message-ID: <3CE52711.800DE93A@xilinx.com> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> <3CE278BC.AC460E55@xilinx.com> <3CE32E1F.62854C2B@earthlink.net> <1021635310.14469.0.nnrp-10.9e9832fa@news.demon.co.uk> NNTP-Posting-Host: 149.199.34.29 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en To: Tim Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17503 Tim wrote: > Keith R. Williams wrote > > Yes, worth paying for. Though not worth the cost and problems of the > battery solution. Cost cannot be the issue. Battery plus holder are less than $2. Reliabilty is the subject of some discussions, not cost. Peter Alfke ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: Architecture for high-level reconfigurable computing Date: Fri, 17 May 2002 19:49:27 +0100 Message-ID: <1021661375.16928.0.nnrp-14.9e9832fa@news.demon.co.uk> References: <37ce351d.0205130901.3c70066f@posting.google.com> <3CE03767.665E161C@qut.edu.au> <3CE03B81.B6624D70@xilinx.com> <3CE0404E.AE4B37C5@qut.edu.au> <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk> <3CE0874C.C18C852@earthlink.net> <3CE13DB0.F6A37653@xilinx.com> <3CE18569.6121@designtools.co.nz> <3CE18848.791E9326@xilinx.com> <3CE19CCA.2F4C@designtools.co.nz> <3CE278BC.AC460E55@xilinx.com> <3CE32E1F.62854C2B@earthlink.net> <1021635310.14469.0.nnrp-10.9e9832fa@news.demon.co.uk> <3CE52711.800DE93A@xilinx.com> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1021661375 nnrp-14:16928 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 18 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!kibo.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17639 Peter Alfke wrote > Tim wrote: > >> Yes, worth paying for. Though not worth the cost and problems of the >> battery solution. > > Cost cannot be the issue. Battery plus holder are less than $2. > Reliabilty is the subject of some discussions, not cost. Absolutely. What I should have said is the "real estate cost". It is quite a while since I did a design where physical size was not a prime constraint. But maybe that is just my destiny working itself out. ###### From: Micah Dowty Subject: Re: Architecture for high-level reconfigurable computing Newsgroups: comp.arch.fpga Message-ID: References: <37ce351d.0205130901.3c70066f@posting.google.com> User-Agent: Pan/0.11.3 (Unix) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Comment-To: "m0" Lines: 13 NNTP-Posting-Host: 12.252.169.247 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52.ops.asp.att.net 1022037572 12.252.169.247 (Wed, 22 May 2002 03:19:32 GMT) NNTP-Posting-Date: Wed, 22 May 2002 03:19:32 GMT Organization: AT&T Broadband Date: Wed, 22 May 2002 03:19:32 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:17673 On Mon, 20 May 2002 11:17:14 -0600, m0 wrote: > This already exists, do a search on google for 'hardware software split > language pc' exactly and you'll get your hit. Sorry boys. Uh... when I try that I get a bunch of shopping sites :P Anyway, even if the idea I proposed already has been invented, it hasn't been implemented and made Open Source software. If the invention hasn't been developed and put out there for the use of others, it might as well not have been invented. --Micah