[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] Real newbie questions
Aloha!
John Sheahan wrote:
> minor nit - 'fancy language constructs' can often have a place in
> test benches / models of the things your code is talking to.
Yes, sorry. I was only talking about the design description, not the whole
enchilada with testbenches and other constructs used during development.
I'm not allergic to advanced language constructs per se, I have only found it
to be a symptom of a problematic design. I know several experienced designers
that produce great HW that uses properly selected advanced constructs from the
language to create good, tight code.
One have to be very careul though and verify that the subset of the HDL
language to be used in a given project will be accepted by all tools in the
flow to be used.
I know at least one instance were the introduction of a tool into the flow
(for STA, formal verification etc) ended up causing all kinds of pain simply
because the tool deemed neccesary didn't handle a language feature used.
If you have a small FPGA design with a few source files that might be ok. With
1000+ source files in the database, then someone will have a bad day (week or
month).
> but definitely not in the code you want to synthesize.
> I agree - if you cannot visualize the hardware your rtl is describing
> there is (will be) a problem.
Exactly. Seriously, what do we have to play with - really? Primitive gates
(combinational clouds), registers and latches. Then possibly MUXes, FIFOs, and
specific memories. That's it (basically ,-)
The HDL needed to describe these things are very simple and well understood.
From these primitives we create higher level RTL thingys such as ALUs,
register files, FIR filters, etc. We end up with RTL based IP-cores. But it's
all (again basically) hierarchies of very simple functions. The HDL
description should reflect that.
The way you do your system modelling, system design, design entry, simulation,
feedback, incremental functional development, synthesis, backend, timing
convergence runs or whatever is up to you and your methodology. There are good
and bad ones and different designs requires different tool flows and
adaptation of the methodology. But no matter what your methodology looks like,
my deepest recommendation is that you never, never forget that it's a HW
design you are developing and implementing. Not HDL programs.
--
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