Hello, thank you for this report. I have just fixed it.
Tristan. ----- Mail original ----- > Mhm, after some trying, I know have something working. If I call the > OSVVM RandomPType InitSeed() procedures directly > inside a process, then it works with 'instance_name: > > shared variable RW : RandomPType; > shared variable DATA : RandomPType; > > init_p : process > begin > DATA.InitSeed(DATA'instance_name); > RW.InitSeed(RW'instance_name); > --DATA_rand_init; > --RW_rand_init; > queue.init; > wait; > end process init_p; > > > If I call them indirectly through wrapper functions, defined in a > separate package, it's not working: > > package body testbench_pkg is > > > shared variable RW : RandomPType; > shared variable DATA : RandomPType; > > > procedure RW_rand_init is > begin > RW.InitSeed(RW_rand_init'instance_name); > end procedure RW_rand_init; > > > procedure DATA_rand_init is > begin > DATA.InitSeed(DATA_rand_init'instance_name); > end procedure DATA_rand_init; > > ... > > end package body testbench_pkg; > > > Maybe it's more a problem of the attribute usage in procedures ... > > > Greets, > Torsten > > > > Am 09.06.2014 um 22:02 schrieb Torsten Meißner > <[email protected]>: > > > Hello GHDL users, > > > > > > while doing some experiments with the OSVVM library (which GHDL is > > able to compile) I stumbled upon > > a potentially bug within GHDL. There are 3 overloaded procedures > > within the RandomPType protected type > > to initialize the random generators of the OSVVM library; > > > > procedure InitSeed (S : string ) is > > begin > > RandomSeed := GenRandSeed(S) ; > > end procedure InitSeed ; > > > > procedure InitSeed (I : integer ) is > > begin > > RandomSeed := GenRandSeed(I) ; > > end procedure InitSeed ; > > > > procedure InitSeed (IV : integer_vector ) is > > begin > > RandomSeed := GenRandSeed(IV) ; > > end procedure InitSeed ; > > > > > > The documentation gives the hint to call the procedure with the > > instance_name attribute of the variable, which is used > > to generate the random numbers. If you call the init procedure on a > > local variable in a process, all is fine. > > Bit when you call it on a shared variable, there is an exception > > error when trying to analyze the design: > > > > path_add_element: cannot handle IIR_KIND_PACKAGE_BODY > > (tb_pkg.vhd:32:14) > > > > ******************** GHDL Bug occured **************************** > > Please report this bug on http://gna.org/projects/ghdl > > GHDL release: GHDL 0.31 (20140108) [Dunoon edition] > > Compiled with GNAT Version: GPL 2013 (20130314) > > In directory: /Users/torstenmeissner/Projects/osvvm/trias/ > > Command line: > > /opt/ghdl/gcc-4.8.2/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/ghdl1 > > --std=02 > > -P/opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib//v93/std/ > > -P/opt/ghdl/gcc-4.8.2/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/vhdl/lib//v93/synopsys/ > > -quiet -o tb_pkg.s tb_pkg.vhd > > Exception TYPES.INTERNAL_ERROR raised > > Exception information: > > Exception name: TYPES.INTERNAL_ERROR > > Message: errorout.adb:71 > > Call stack traceback locations: > > 0x101282507 0x1012ace41 0x1012b4d42 0x1012d71ac 0x1012f2f49 > > 0x1012f4e6b 0x1012f4eb2 0x10130156f 0x101300093 0x101300ff9 > > 0x101301bd8 0x101306884 0x10125f024 0x10123f8b3 0x10124b0ef > > 0x10124cc1a 0x10124265e 0x10125f084 0x10123ec04 > > ****************************************************************** > > > > Execution terminated by unhandled exception > > Exception name: TYPES.INTERNAL_ERROR > > Message: errorout.adb:71 > > Call stack traceback locations: > > 0x101282507 0x1012ace41 0x1012b4d42 0x1012d71ac 0x1012f2f49 > > 0x1012f4e6b 0x1012f4eb2 0x10130156f 0x101300093 0x101300ff9 > > 0x101301bd8 0x101306884 0x10125f024 0x10123f8b3 0x10124b0ef > > 0x10124cc1a 0x10124265e 0x10125f084 0x10123ec04 > > ghdl: compilation error > > > > > > Maybe the support for the instance_name attribute on shared > > variables is broken? > > My workaround is to use the instance_name attribute of the > > procedure, which I use as wrapper around the > > InitSeed() call. when I'm doing that, GHDL is compiling without > > errors. > > > > Besides of that, I'm very happy that there are GHDL binary packages > > for a bunch of operation systems on > > the sourceforge site. So, the installation is much easier on OSX > > for example :) > > > > > > Greets, > > Torsten > > > > > > -- > > > > Blog: http://blog.goodcleanfun.de > > Github: https://github.com/tmeissner > > > > > > _______________________________________________ > > Ghdl-discuss mailing list > > [email protected] > > https://mail.gna.org/listinfo/ghdl-discuss > > -- > > Blog: http://blog.goodcleanfun.de > Github: https://github.com/tmeissner > > > _______________________________________________ > Ghdl-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/ghdl-discuss > _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
