[Coco] FPGA vs. Emulation Speed

[jdaggett at gate.net]

On 20 Nov 2010 at 22:22, Frank Swygert wrote:

> Speed isn't the real issue. I made the comment that the FPGA version 
> would be the limiting factor in some areas because of various hardware 
> limitations. Speed wasn't one of the things I was referring to. Might 
> just be what the developers are capable of doing skill wise. There are 
> limits to memory and how much one can put into an FPGA, and limits of 
> the board design. In software emulation those limits can easily be 
> exceeded in most cases.
> 

In FPGAs there are options for Size and Speed. By size I mean the amount of resources 
taken up in the FPGA. Smaller (lees) resource utilization does not always yield the best 
timing sollution. Likewise optimizing for Speed may not be the best use of resources. There 
are ways to code to use less resources with the best speed but that often is the realm of very 
expericenced designers for FPGA circuitry. 

You are correvct in that for given FPGA there is a limited amount of resources for that 
specific chip. Both Altera and Xilinx have devices that have the equivalency of 5 to 6 million 
gates. Granted these chips become very very expensive and are all in BGA packages and 
not in the realm of hobby construction practices. Believe me I do not want to even try and 
solder a 1100 pin BGA with the limited tools that I have. That requires a pick and place robot 
and reflow ovens and so forth. Not forgetting that such a package  will certainly require a ten 
to twelve layer board to route all the pins. 

I will agree that software emmulation in the long run will probably lead to a more fluid design 
atmosphere and ability to change as demands require. It makes sense for those that do not 
want more hardware than what they already have invested in their desktop or laptop. Also a 
FPGA is somewhat more fluid in design than a discrete IC design that we now have in the 
present COCO3.

So to move forward, there may necessarily be the need for compromise to at least get 
something out for people to use and make the ultimate decission as to what they want. It may 
after all make sense for two camps and two designs to go forward with any project. 

just some thoughts

james
> Date: Sat, 20 Nov 2010 08:47:43 -0500
> From: Aaron Wolfe <aawolfe at gmail.com>
> Subject: Re: [Coco] What would a CoCo successor have to have as a minimum?
> 
> A few comments on the list seemed to say that if a project supported 
> both emulaltors and
> FPGA, the FPGA's performance would limit the capabilities of this
> proposed coco 4. This seems unlikely.
> 
> -- 
> Frank Swygert
> Publisher, "American Motors Cars"
> Magazine (AMC)
> For all AMC enthusiasts
> http://www.amc-mag.com
> (free download available!)
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1153 / Virus Database: 424/3268 - Release Date: 11/20/10
>