[Fpga-synth] Starting points?

[Eric Brombaugh]

Theo Verelst wrote:

> As someone who'd built my own logic from electronics even already in the
> 70s it always strikes me that contrary to the well-formed TTL family
> logic for instance, all HDL designs I've witnessed the last years, even
> factory supplied ones (Maybe with the exception of tailored RTL) are
> comparison wise almost extremely under-specified in terms of fundamental
> behavior of parts and connections and timing associated with those, and
> margins and such, so that like with spread out delay and setup and hold
> time and drive line characteristics in TTL, a lot still depends on trial
> and error, preferably with for instance on-fpga probes (like Agilent I
> seem to remember has special interfaces and test software for).

I think Mike Ravkine has already addressed the principle point of this 
complaint - namely that it's not necessary to specify most of the things 
you're lamenting. Controlling the clock-clock timing and external I/O 
delays relative to the clock is really all that you need to do. Anything 
more than this is overconstrained and hinders rather than aids the 
automated place & route process.

I'll grant that there's a certain lack of top-level control in the P&R 
tools (at least those I've used) which can lead to some iteration when 
trying to close timing. This is a shortcoming of the individual tool 
flows, not necessarily of modern digital design though.

> The nice and preferable 'correct by construction' paradigm like in
> Pascal (or C of course, to an extend) seems really not so readily
> achievable, if even at all, which is kind of a shame, I would think.

I disagree. You can write bad code in any language, not just HDL. Pascal 
  is often held up as some paragon of programming virtue because it has 
strict type checking. That's good for catching low level bugs, but it 
doesn't help you if you make conceptual errors. Hardware description 
languages have the same problems - VHDL is more strict and verbose while 
Verilog is loose and terse. Each user can choose, but it doesn't make 
one _better_ than the other. Diversity is good.

> The suggestion of 'soled and unbreakable logic', in general, is
> seriously deluding, anyhow, regarding of the HDL language. I even prefer
> schematics from the manufacturer because some of the problems are than
> more over viewable and like the historic logic design process was fairly
> successful, alas lossing portability across brands. Opencores for
> instance does not clearly prove to my anyhow that all the activities of
> those kinds are a huge succes, or at least they are far from insightful,
> and I notice most public shared designs, and I suppose many closed
> source ones, too, are made often for a even a specific target chip.

Schematics have their place - the mark of a good designer is knowing 
when to use them and when to use HDL. The fact that special features of 
different FPGA families aren't portable can be a nuisance, but that's 
the price you pay for the added performance they provide (Just ask me - 
I've been porting a large project from Virtex 2-pro to Virtex 5 lately). 
OpenCores is of necessity a compromise between time and hardware 
resources - if you want an efficient design you'll have to specifically 
target your resources, which requires an investment of your time. If you 
  don't have the time, you'll have to spend more money on FPGA resources 
to accommodate the less efficient design that results.

Like all engineering, designing with FPGAs is the art of compromise. 
It's well encapsulated in the ancient saying: Fast, cheap, good. Pick 
any two.

Eric