FPGA Central

> >As opposed to, say, thinking it through carefully and getting it right
> >the first time?
> >
> >John
> >
> >
> If you can think something through carefully and get it right first
> time, without experimentation, you are either:
>
> a) a genius who would make Newton look like a moron, or
>
> b) doing something pretty trivial.
>
> Regards,
> Steve

If you design a complex 10s Mgates system-on-chips where each of the
10s masks costs 100k$ and where each design iteration is many months
long, you'll be killed if you come w/ your experimentation approach. I
don't think it's trivial ; so I'll try to compete w/ Newton w/ my
small capabilities.

Why not carefully think about your implementation of the requested
features? Select the appropriate architecture from the very beginning
(and regarding the penalty if you didn't choose the right architecture
from the beginning, you should better carefully look at the features
you're looking for and in which direction they can develop), identify
the main technical risks and concentrate on a way to be sure that the
architectural choices + the main functions will be validated during
the first iteration and that all the debug functions are in place to
identify most of the bugs.

W/ Mgates FPGA and ASIC, HW stuff is no longer trivial. The HDL
productivity has only slightly improved while in the mean time the
FPGA/ASIC density has drastically increased. HW is not SW. Any
design/experiment/update approach only leads to loss of time (and
therefore $).

Eric DELAGE wrote:

>>>As opposed to, say, thinking it through carefully and getting it right
>>>the first time?
>>>
>>>John
>>>
>>>
>>>
>>>
>>If you can think something through carefully and get it right first
>>time, without experimentation, you are either:
>>
>>a) a genius who would make Newton look like a moron, or
>>
>>b) doing something pretty trivial.
>>
>>Regards,
>>Steve
>>
>>
>
>If you design a complex 10s Mgates system-on-chips where each of the
>10s masks costs 100k$ and where each design iteration is many months
>long, you'll be killed if you come w/ your experimentation approach. I
>don't think it's trivial ; so I'll try to compete w/ Newton w/ my
>small capabilities.
>
>Why not carefully think about your implementation of the requested
>features? Select the appropriate architecture from the very beginning
>(and regarding the penalty if you didn't choose the right architecture
>from the beginning, you should better carefully look at the features
>you're looking for and in which direction they can develop), identify
>the main technical risks and concentrate on a way to be sure that the
>architectural choices + the main functions will be validated during
>the first iteration and that all the debug functions are in place to
>identify most of the bugs.
>
>W/ Mgates FPGA and ASIC, HW stuff is no longer trivial. The HDL
>productivity has only slightly improved while in the mean time the
>FPGA/ASIC density has drastically increased. HW is not SW. Any
>design/experiment/update approach only leads to loss of time (and
>therefore $).
>
>
So, you don't produce any models of the modules in your chips? You don't
use any simulators to debug each modelled element of the design? You
don't try to simulate the entire thing to the extent the available tools
will permit?

I think perhaps you do. Clue: those models are prototypes, and those
simulators are where you experiment with them. I really really doubt
you'll get a big design right without using them effectively. Even if
you can get the logic right at the first attempt, your timing
constraints must be pretty loose if you don't need to try some
experiments with simulators to check the critical paths are going to
play nicely.

Chips tend to have clearer requirements than complete systems. Few
complete systems of any complexity are implemented without changes in
the requirements along the way. Attempts to resist such changes just
increase the likelihood of the system being already obsolete, or just
inappropriate, on completion. Experimental systems (either physical or
simulations) available early are a powerful way to get the end users to
really figure out what they want. Specification by simulation is the
only way I've ever seen a spec produced that survived the implementation
phase intact. It is still a strategy too rarely used, even though it was
producing excellent results 20 years ago.

You write like you have a chip on your shoulder (pun partially intended)
about software vs hardware work. You seem to assume I was writing from a
software developer's point of view. If so, you were wrong. Most software
developers generally don't have to worry too much about this stuff. With
so many embedded systems now using flash, most software is fairly fluid
even after the ship date. :-)

Regards,
Steve