Proposed additions to std.env

[Rob Gaddi]

A couple things that might be really nice to have, probably in std.env

***

function simulation return bool;

This would allow the use of if/else/endif blocks to get around one of my
least favorite VHDL anti-patterns, the use of
--synthesis translate_on/off

Pragmas are awful. They're error-prone kludges that can lead to
accidentally and silently knocking huge chunks of your code out, because
a misformed pragma is just a comment. Additionally, while most vendors
support knocking code out for synthesis, support for putting some back in
for synthesis such as Altera's comment_as_hdl is limited.

Another way around this would be to pass SIMULATION down as a generic,
but this a) doesn't work for functions in packages and b) requires that
you manually pass the generic all the way down the hierarchy.

You could also put it into a package, but then you're responsible for
manually changing it back and forth in the code.

Now, an argument could be made that this is all awful because you
shouldn't be doing it anyhow; that synthesizing code that is different
than what you simulate is inherently dangerous. I wouldn't disagree.
But at the end of the day, sometimes it's the only way to get it to
actually work; the vendor synthesis tools are pretty dumb and get
confused by things like assigning 'X' values so that you can trace
invalid states through your simulation. Or debugging log file writes.
And if there has to be a knock-out mechanism, it should at least be
linguistically sound.

***

function file_path return string;

Provides the path to the current VHDL file. Not sure if there's a better
implementation option than that, but some way of enforcing relative paths
for files that is better than "Hope the tool has the same understanding
of the root directory than I do." would be great.

Again, there are workarounds with generics or packages, but again they're
a pain for all the same reasons; who wants to have to hard code absolute
paths into a VHDL package that you may need to move to another machine?



--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Lars Asplund]

A way to get the current line number would also be great. Together with file path and the now function you have a solid foundation for logging. It can be achieved with preprocessing like we do in VUnit (https://github.com/LarsAsplund/vunit):

86810000 ps: DEBUG in traffic_logger (uart_rx.vhd:39): Received 77

but language support would be better.

/Lars

 

[Andy]

I've used a deferred constant for detection of simulation. Just compile a different package body for simulation, after compiling the RTL.

constant simulation: Boolean; -- package

constant simulation: Boolean := false; -- rtl package body

constant simulation: Boolean := true; -- simulation package body

Andy

On Friday, January 30, 2015 at 1:27:26 PM UTC-6, Rob Gaddi wrote:

A couple things that might be really nice to have, probably in std.env

***

function simulation return bool;

This would allow the use of if/else/endif blocks to get around one of my
least favorite VHDL anti-patterns, the use of
--synthesis translate_on/off

Pragmas are awful. They're error-prone kludges that can lead to
accidentally and silently knocking huge chunks of your code out, because
a misformed pragma is just a comment. Additionally, while most vendors
support knocking code out for synthesis, support for putting some back in
for synthesis such as Altera's comment_as_hdl is limited.

Another way around this would be to pass SIMULATION down as a generic,
but this a) doesn't work for functions in packages and b) requires that
you manually pass the generic all the way down the hierarchy.

You could also put it into a package, but then you're responsible for
manually changing it back and forth in the code.

Now, an argument could be made that this is all awful because you
shouldn't be doing it anyhow; that synthesizing code that is different
than what you simulate is inherently dangerous. I wouldn't disagree.
But at the end of the day, sometimes it's the only way to get it to
actually work; the vendor synthesis tools are pretty dumb and get
confused by things like assigning 'X' values so that you can trace
invalid states through your simulation. Or debugging log file writes.
And if there has to be a knock-out mechanism, it should at least be
linguistically sound.

***

function file_path return string;

Provides the path to the current VHDL file. Not sure if there's a better
implementation option than that, but some way of enforcing relative paths
for files that is better than "Hope the tool has the same understanding
of the root directory than I do." would be great.

Again, there are workarounds with generics or packages, but again they're
a pain for all the same reasons; who wants to have to hard code absolute
paths into a VHDL package that you may need to move to another machine?



--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.