Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ogicse!emory!att!cbnewse!cwpjr From: cwpjr@cbnewse.att.com (clyde.w.jr.phillips) Newsgroups: comp.lang.forth Subject: Re: FPGA Forth engines Summary: Multi-Process Implementation and speed of FPGA based Engine Message-ID: <1990Dec11.150410.14713@cbnewse.att.com> Date: 11 Dec 90 15:04:10 GMT References: <9012061501.AA20109@ucbvax.Berkeley.EDU> Distribution: na Organization: AT&T Bell Laboratories Lines: 30 In article , adyer@milo.wyse.com (Andrew Dyer x2446) writes: I think this is in responce to Mitch Brady's remarks that a FPGA engine would be SLOOOOOOW!: > I don't think your comments are necessarily true. Several vendors have > arrays with approx. 2000 2-input NAND-equivalent gates, which will run > at toggle rates of 70 MHz.(Xilinx and AMD) I wouldn't trust I/O rates > to be more than 50 Mhz tho. Assuming a 50 MHz clock, and 6 clock > cycles/instruction you get 8.33 MHz cycle rate. Not too shabby. > > The other problem is that FPGAs are expensive, and it would take > several of them if they were the only components. For a one shot > system that's o.k., but if it's to be ``public domain'' hardware, then > it should be a bit simpler (IMHO). > > Rather than FPGA's exclusively, I would be inclined to use a mixture > of LSI type parts like register files, dual port memories, ALU's and > some FPGA logic for ``glue''. I beleive I did reference this issue. And there are neat sequencer PALs Register file, ALU and BUS interface chips out there.... > > If one chose the correct parts, the design could be easily migrated to > a standard cell or gate array library. (2900 series bit slice > components, for example, are available from at least one vendor.) > > -- So at least two people beleive it' doable! --Clyde