How do you handle build variants in VHDL?

Andy wrote:

> For example, if  you gate all the interface signals to a module with a 
> generic/constant, the synthesis tool will not implement one gate/flop 
> of it (leave the clock and reset alone, they'll go away by themselves).

Gee, that's quite efficient from a coding POV, and makes it much more
readable too! (Not)

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

On Jul 27, 12:08=A0am, Mark McDougall <ma...@vl.com.au> wrote:
> Gee, that's quite efficient from a coding POV, and makes it much more
> readable too! (Not)

Efficient compared to what, integrating a non-standard pre-processor
into all of my tool flows?  And training everyone else that will ever
touch/review/reuse any of my code how to use it and integrate it into
their flows? Oh, yeah, I forgot; you only have one tool and nobody
else to worry about.

Obviously, a generate statement remains the easiest way to control an
entire module. But if you need to implement variant functionality at
much lower levels, gating things with constants/generics is simpler
and easier. For instance, using constant/generic masks makes getting
rid of unused bits and controlling writeability in control/status
registers much easier to write/read/review/maintain. And if a control
register bit that enables a variant function is gated off in the
control register, guess what happens to the code that implements that
function?  If a state in a state machine is not reachable due to
constant/generic inputs, a good synthesizer will optimize that state
away.

I suggest you learn more about the language and how to use what it
already has before you go off and roll your own, unless you want to
stay on your own.

Otherwise, you are completely free to pre-process and ifdef all of the
above away.

Andy

> Andy wrote:
> 
>> For example, if  you gate all the interface signals to a module with a 
>> generic/constant, the synthesis tool will not implement one gate/flop 
>> of it (leave the clock and reset alone, they'll go away by themselves).

Mark McDougall wrote:
> Gee, that's quite efficient from a coding POV, and makes it much more
> readable too! (Not)

The only reason I read code is to reuse it or to change it.
In either case, knowing all of the available options is a good thing.

  -- Mike Treseler