Re: gEDA-user: fritzing

[Eric Brombaugh <ebrombaugh1@xxxxxxx>]

Ben Jackson wrote:
> Well, that's basically my point.  Working on a large IC requires a huge
> team of people.  I live right by Intel, so I see how many people they have
> swallowed up to do chip design.  My complaint is that the complexities of
> designing chips or FPGAs is very poorly abstracted as compared to software
> at large.  The only reason it's possible to execute those designs at all
> is that on an absolute scale they're fairly simple.  That's no slight on
> the people doing the work -- it's just a reflection of how ineffective
> the tools are.

This is an interesting perspective. Essentially I hear you saying two 
things:

1) A task that requires a lot of smart people to complete must suffer 
from a lack of adequate tools.

2) A task that can be completed with inadequate tools can't be very complex.

 From my standpoint there's a bit of a disconnect between these two 
positions.

Coming from a background as a wireless systems engineer as well as a 
chip designer, I'm here to tell you that there's nothing simple about 
the chips I've worked on: the Wifi chipsets I was doing 6 years ago were 
complex enough that no one person understood _everything_ that was 
happening in them. Move up the food chain to something like a modern 
multi-core processor and it's amazing that they work at all.

The only way these things are at all possible is with a wide variation 
in levels of abstraction. They guy designing the transistors doesn't 
know about the circuits they go into, while the architect working on the 
memory management can't be bothered with the ESD structures of the I/O 
pads. I have very little knowledge about how modern large-scale software 
development projects work, but I assume that they're also staffed by 
large teams, each with their own specialties - UI designers, core 
coders, build managers, library maintainers, QA & test. I don't see much 
difference between this and what happens in chip design.

> I would like to be able to express the essence of what I need to do, such
> as an arithmetic operation, without having to understand how it should be
> pipelined, how wide the intermediate results need to be, how it should map
> to the facilities of the FPGA (or hard macros or etc), etc.  I would like
> to be able to take that design and target FPGAs from different families
> or vendors without having to reevaluate the design tradeoffs.  Even if I
> *did* have to make the choices manually (eg where to register intermediate
> values), I'd like to control those aspects independently from the core
> logic, rather than having to mix it in.

Some of these are reasonable goals and a lot of engineers out there 
would agree with you, myself included.

As far as the top-level design of pipelined arithmetic systems, I have 
actually used some tools that approached this level of flexibility - 
Synopsys Module Compiler was doing a lot of this 10 years ago on small 
systems. The big problem is scaling it up to what's normal today. Xilinx 
has taken some stabs in this direction with System Generator and 
AccelDSP, but these also have their shortcomings. Very few tools (any?) 
out there today allow you design complex arithmetic without specifying 
internal details, although many provide libraries of functions that you 
don't have to dig into to use effectively.

Retargeting FPGAs from different families within one vendor is almost 
there - I'm able to port designs across Xilinx Spartan3, Virtex2, 4 and 
5 families without too much pain. Going across vendors is a bit more of 
an issue because there aren't _any_ 3rd-party tools that handle the back 
end PAR processes - the vendors treat that as proprietary and require 
you to use their own tools. The only interface that works is the 
top-level HDL, and while it's possible to make retargetable code you 
give up a lot of performance due to the dissimilar IP structures. 
Nothing wrong with that - it's competition in action.

I'm sure we'll get there. It won't be easy though.

Eric




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user