View Single Post
  #21 (permalink)  
Old 04-13-2005, 11:25 PM
Tim Hubberstey
Guest
 
Posts: n/a
Default Re: VHDL language of choice?

Mike Treseler wrote:
> Tim Hubberstey wrote:
>
>> Foremost among these, IMO, is the issue of a built-in pre-processor.
>> Nearly every person I have encountered who is just learning VHDL, but
>> has experience with another language, asks: Why is there no
>> pre-processor/macro capability?

>
> Hi Tim,
>
> I came from a hardware background and found
> it odd when first maintaining a C program that I had to
> wade through a nest of #ifndefs and hack
> some #defines to get the options right.
> Maintaining the *almost* C-like macros
> can also be challenging for a bit bouncer.


Unfortunately, any language feature can be abused. I also come from a
hardware background so I understand what you mean. However, a lot of the
pre-processor complexity you see in C code often comes from people
writing code that will work on many different platforms and operating
systems.

>> Then there are the issues that, I believe (perhaps incorrectly), can't
>> (or shouldn't) be addressed by any solution other than a
>> pre-processor. One of the most common issues is having optional ports
>> in an entity declaration.

>
> If it's my code, I am inclined to just edit in the change
> and use version control to dig it up if I ever have to.
> If it's an untouchable entity, I can make a wrapper
> in about a minute.


That's fine, as long as you're the only person dealing with the code. I
try to write code that is, as much as possible, reusable and
parameterizable. This often results in situations where you want to vary
the port list to include/exclude control signals. There are ways you can
do this that stay within the existing VHDL definition, but these methods
often result in compiler and/or synthesis warnings that add confusion to
the log files. Using a pre-processor, IMO, produces much cleaner results
for the *user* of an IP block even though the code inside the block may
be a little harder to understand.

>> Finally, there is the whole issue of compiler directives.

>
> I prefer to keep my code free of directives and
> make those settings in the back-end files.


This is, mostly, a style issue so I won't disagree with your choice.
However, there are some pragmas that *must* be inside the code because
the tool the pragma is for doesn't have any back-end files. Some code
coverage and formal verification tools come to mind here.

Even if you don't choose to intentionally use pragmas in your code, it
can still happen by accident. For instance, I once wasted an entire
day's synthesis run because I reformatted a comment block and
inadvertently ended up with a comment line that started out:
-- Synopsys ...
This caused the synthesis of the block to fail which, since it was a
block instantiated by many other blocks, caused the entire 18-hour
synthesis run to fail.

Even worse is the case where you accidentally generate a valid pragma
that causes some subtle error in your result. My point is that, whether
you choose to use them or not, pragmas have no business looking like
comments.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com
Reply With Quote