[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] Real newbie questions
Aloha!
(This turned into "Joachims 0.02 Euro of rambling on HW design"... ;-)
Rudolf Usselmann wrote:
> HDLs in general are a bit different than any "normal"
> programming language you have used. <snip>
Totally agree. I get a serious itch every tine I hear the phrase "(V)HDL
programming". You don't program using HDL languages, you describe hardware. A
*huge* difference.
The "HDL programming" thinking seem to be esp pervasive in the FPGA/CPLD
design world. For smaller designs with low performance, this might work. But
as we move into SoPCs and implement larger platforms, ignoring the hardware
when designing have really started to bite people in their behinds.
There are tons of failed HW designs out there that went belly-up because
people "programmed in HDL", got the correct functional behaviour in the
simulator and then fell on their face because the HW was unable to meet
requirements, didn't make sense in a physical world and got all kinds of weird
problems. All this because they use HDL to program a functional behaviour, not
describe a real, physical object that is to be implemented in an integrated
device.
You can be an ace on the VHDL language, but it will not help you a bit (no pun
intended) if you think in terms of programming, not HW. You should learn
digital HW design and describe that in your choice of HDL language, not the
other way around. I'll even go so far as saying that if you need to use fancy
language constructs to implement your HW, then you have probably done
something wrong [1]. (Normally data- vs control path separation, analysis of
functionality.)
To bring it back to the schematic vs HDL discussion; Schematic design entry in
the old-school sense where you actually select gates and RTL blocks from a
library is good simply because you actually see such things as fan-out, gates
etc and it's way harder to "ignore" that you are working with HW.
Schematic entry in the style of Renoir, Visual HDL and similar tools are much
more evil. The reason for this is that you can have (and there have been
numerous instances of that) designers implementing large designs with a total
control and focus on functional behaviour, but zero knowledge or control over
the resulting HW [2].
This is especially true for flow chart descriptions and there are several
reasons for this to be the case:
(a) There is no natural separation of control and data. The operations
tranforming the data and the control mechanisms for the operations are
combined in the diagrams. This leads to a general mixup of the design which
makes physical implementation as well as testing much more complicated.
(b) You work with variables, not wires. People look at variables in one
diagram that is being set in another diagram, and fail to realise that this
implies a wire/bus between the logic implementing each diagram. I've seen the
Routing Nests From Hell caused by this.
Not all graphical representations are bad. I would go as far as saying that
FSM diagrams are bening, but have seen few productivity gains from them
compared to textual representation.
Graphical connectivity representation is Really Good. Hierarchical ones that
allows you to work with Werner diagrams in sub blocks, and combine/create data
structures with symbolic widths for the block interfaces can be a real time
saver, especially when you use a methodology with separate deliveries and road
maps for the sub blocks and the interconnect structure.
HDLs are great for describing things at RTL level. To get there spend lots of
time doing the system design work. Whiteboards with multiple colors pens are
great. Use graphical tools for you interconnect and finally, use a good editor
top write your RTL. Conservative? Yep. Does it work? Yep.
Side note: Knowing OO-stuff as a HW engineer is also a Good Thing. Thinking in
OO-terms, use cases, classes etc when doing you system design work is the way
to go. Substitute "Class" with "IP-core" and off you go.
Notes:
------
[1] But there are advanced language constructs that *can* be extremely useful.
The important thing is to stay away from the trap of focusing on the tool (the
language) rather than the problem at hand (the HW and the design to be
implemented).
[2] My favourite term is "code freeze". Used by some to indicate that when the
design meets the functional requirements (in the simulator), the design is
finished. All that is left is to synthesise the HDL and get HW at the other
end. Yeah riiight. ,-)
--
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
VP, Research & Development
----------------------------------------------------------------------
InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden
Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02
E-mail: joachim.strombergson@informasic.com Home: www.informasic.com
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml