[Fpga-synth] Learning FPGA Design

[Magnus Danielson]

From: Eric Brombaugh <ebrombaugh at earthlink.net>
Subject: Re: [Fpga-synth] Learning FPGA Design
Date: Fri, 19 Oct 2007 14:16:44 -0700
Message-ID: <47191EBC.9090402 at earthlink.net>

Scott, Eric,

> That's an interesting account of HDL traps you've collected, but I can't 
> look at any of your code examples and categorically state "That one is 
> wrong." - they all look workable to me, and the one you specifically 
> said doesn't work actually looks like the best representation in my 
> experience.

With my limited Verilog-knowledge I'd say that I agree here. You should expect
these to boil down to a DFF and some variations of the feedback network which
should result in the same inverter regardless of initial form if the synthesis
tool has a decent enought logic reduction in them. That part is a known
problem.

> You asked for a recommendation of a text which could warn you away form 
> these problems, and unfortunately I can't give you any suggestions. I've 
> been coding HDL for synthesis and simulation for almost 20 years now as 
> well as taken classes from a wide variety of tool vendors and there is 
> no one guaranteed way to success. The reason for this is simple - every 
> simulator and synthesis tool out there was written by different people 
> and will have different quirks. Your job as a user of these tools is to 
> quickly find out where the snags are in the tool you're using today and 
> remember to avoid them tomorrow. The unfortunate implication of this is 
> that when the tool changes you'll likely have to rediscover the new snags.

You also misses the news of correction of snags so your uses has been limited
due to old bugs and old limitation which are no longer necessarilly limiting
you. I significantly reduced the code of an early project by just expanding
out old libraries made up to cover old limitations. The benefit was more
readable code too.

The background stories for causes of quirks is different for VHDL and Verilog.
The main flaw of VHDL have been fairly complete standard, but lacking a common
synthesizeable subset, which is due for its initial life as a simulation
description langauage. Nowdays most synthesis-tools support much more than the
synthesizeable subset standard would make you beleive it can do.
For Verilog the standard have lacked key language definitions and implementors
have made different guess-works of what should be there.

Add that different amount of effort is put into inference, logical reduction
etc. Some limitations only exists in certain topologies unless constrainted by
module borders in the right way, but another tool will tolerate more flexible
designs.

Things have improved thought. The tools we had when I got started was a hell
more painfull than what we have today.

If you where doing VHDL designs I know exactly which book you should be
reading. Much of it isn't magic once you have the facts laid out for you.

> Text books, vendor instruction and college courses can't lay these 
> problems out for you in advance - the best preparation they can give you 
> is rules of thumb for writing maintainable code and processes for 
> debugging when you hit the inevitable problems. You have to supply the 
> drive and intelligence to use these techniques to get a successful 
> design, and from what I've read below you are doing fine in that regard.

True, but you can learn to avoid many potholes by having good coding-examples
and bad coding-examples with relevant comments.

> Just wanted to let you know that you're not alone - these are problems 
> that even the pros beat their heads against.

True, but the pain have become less over the years and it is more of higher
level design-issues and bugs in the tools that usually annoy us.

Asynchronic designs is a pain which usually can be avoided.
Clock-domain changes needs to be made in a planned way.

> Eric
> 
> PS - Not to knock academia, but 'sagacious professors' are rare birds 
> when it comes to these sorts of practical aspects of engineering. Most 
> college EE professors don't know which end of a soldering iron to grab, 
> and are way too busy hustling research grants and herding grad students 
> to keep up with the fast pace of EDA tool evolution. They're the last 
> people I'd look to for wisdom in this area.

Every once in a while you bump into people that actually understands the field
and can spread their knowledge.

Cheers,
Magnus - speaks VHDL