Olof Kraigher
Forum Replies Created
-
AuthorPosts
-
May 12, 2015 at 06:14 #989Olof KraigherMember
Yes report is allowed in pure functions, presumably to debug code executed during elaboration, while writing to file is not allowed by not allowing file variables or passing files as parameters.
May 12, 2015 at 04:55 #986Olof KraigherMemberUnfortunately VHDL already breaks referential transparency of pure functions by allowing reports in them. Still compilers might be able to optimize pure functions which do not contain any report statements or calls to other pure function containing report statements.
Consider the following code:
entity test is
end entity;
architecture a of test is
function expensive_function_returning_false return boolean is
begin
report “This cost much”;
return false;
end function;
begin
main : process
begin
assert (not (expensive_function_returning_false or expensive_function_returning_false));
wait;
end process;
end architecture;
This cannot and is not optimized by at least Modelsim and GHDL.
Modelsim outputs this “This cost much” twice as does GHDL. NVC which is another open source VHDL simulator will print nothing. It is likely it performs a static constant folding removing the assert entirely falsely believing it can optimize pure functions in this way.
It is not easy to determine if GHDL or Modelsim would have performed constant folding and optimized away the assert if there were no report statement without deep knowledge of their binary formats and a binary viewer.May 12, 2015 at 03:33 #982Olof KraigherMemberMay 11, 2015 at 09:20 #980Olof KraigherMemberI changed the offending call as you specified. Unfortunately it produced an error:
/home/kraigher/repo/vunit/vhdl/osvvm/AlertLogPkg.vhd:493:11: type “alertlogstructptype” cannot be selected by name
ghdl: compilation error
If you know the LRM supports this syntax then maybe this is a valid bug report for GHDL.
They are generally quite responsive so if you file a ticket it might be fixed before their next official release. I can help you file a ticket if you like.
I would be happy to test your beta releases of OSVMM and will send you an email.
May 11, 2015 at 08:59 #978Olof KraigherMemberJim: I am using the latest development branch of GHDL which I have built from source and OSVVM 2015.03.
Like you say there is no problem outside of the protected type since the procedure is not visible to the outside as a stand-alone name without prefixing a protected type instance. The only problem is with line 493 which can be easily fixed with:
ReportAlerts(ReportAll => TRUE);
May 11, 2015 at 07:21 #976Olof KraigherMemberI am sure it applies since the state changes between calls and thus the program result is affected by the number of calls to the function. Is not the idea behind pure functions to provide referential transparency (https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29)?
Anyway I am convinced that changing the signature to impure cannot have any effects since it is a subprogram within a protected type which cannot be passed as an argument to a pure function anyway and cannot be used anywhere where a pure function would be required.
I have made this modification myself locally to OSVVM 2015.03 and I am able to use it with the latest GHDL using the LLVM backend and VHDL 2008 by the way. I was quite impressed by development of GHDL lately.
May 11, 2015 at 03:11 #972Olof KraigherMemberChanging the function signature of GenRandSeed to “impure function” makes it not violate the LRM and I believe it has no limitations on the usage of the function since its a member of a protected type.
NOTE: The GHDL error is actually a run-time error occurring when the call is made and not a statical error on analysis. Thus I cannot promise that there are no other instances of this problem within the OSVVM code since I do not have any running example which executes the entire code base. However every subprogram that is a pure function within a protected type is a potential problem.
May 11, 2015 at 03:03 #971Olof KraigherMemberChanging 493 to the following is enough to resolve the ambiguity:
ReportAlerts(ReportAll => TRUE);
-
AuthorPosts