GHDL workarounds – any known ones?

[Ajeetha Kumari]

I am new here in this forum, am creating a Python based utility to enhance productivity with OSVVM based TBs. One of them is a testbench skeleton generator that should go live shortly (opensource). While navigating some examples I see:

[code]
library OSVVM ;
context OSVVM.OsvvmContext ;
— use osvvm.ScoreboardPkg_slv.all ;
–!! GHDL
use osvvm.ScoreboardPkg_slv.NewID ;
use osvvm.ScoreboardPkg_slv.Empty ;
use osvvm.ScoreboardPkg_slv.Push ;
use osvvm.ScoreboardPkg_slv.Pop ;

[/code]
(UartRx.vhd).
Is this done to enable GHDL to work with OSVVM? Are there known such workarounds for GHDL/NVC?

Thanks
Ajeetha

[Jim Lewis]

Hi Ajeetha,
WRT scoreboards, there are no known issues with either GHDL or NVC.

There is a subtle VHDL thing with using or referencing multiple generic packages that declare a type – such as ScoreboardIDType that is declared in ScoreboardGenericPkg.

If you reference only one Scoreboard package instance, such as ScoreboardPkg_slv, then the following is fine:

library OSVVM ;
context OSVVM.OSvvmContext ;
use OSVVM.ScoreboardPkg_slv.all ; 
entity e ...
architecture a of e is 
  signal SB1 : ScoreboardIDType ;
begin
  initialize : process
  begin
    SB1 <= NewID("SB1") ; 
    . . . 

OTOH, if you reference a second scoreboard, then you need to disambiguate ScoreboardIDType, but that happens in the type reference and not in the methods.

library OSVVM ;
context OSVVM.OSvvmContext ;
use OSVVM.ScoreboardPkg_slv.all ; 
use OSVVM.ScoreboardPkg_int.all ; 
entity e ...
architecture a of e is 
  signal SB1 : osvvm.ScoreboardPkg_slv.ScoreboardIDType ; -- all the disambiguation you need.
begin
  initialize : process
  begin
    SB1 <= NewID("SB1") ; 
    . . . 

Looking at the code you provided it is either due to preference or a misunderstanding. I have seen code where people prefer to reference specific subprograms from a package. I would think though they would also need to reference ScoreboardIDType as that is required to use these subprograms.

It is possible that someone arrived at that code by starting with a misunderstanding of what went wrong when using two scoreboard packages. So they pealed things back until they got something that worked without really understanding that their issues were due to including the second scoreboard package.

In addition to needing to disambiguate ScoreboardIDType, the only other call that needs to be disambiguated is the calls to WriteScoreboardYaml. Anything subprogram that has ScoreboardIDType as a parameter is disambiguated by the signal with which it is called.

Need additional examples see: OsvvmLibraries/AXI4/Axi4/src/Axi4Manager.vhd and search on ScoreboardIDType. I used the selected path that includes the library and package in Axi4Manager as if someone uses it as a template, they will not have issues.

Cheers,
Jim

[Jim Lewis]

Hi Ajeetha,
Since you are creating a code generator I recommend that when it uses ScoreboardIDType that it always uses a selected path that includes the library and package as that way if people using the generated code add to it they too will not have any issues – and they will have a safe example from which to template.

If your generator includes generating the EndOfTestReports, I recommend that for non-osvvm scoreboards that you add a call to WriteScoreboardYaml before the call to EndOfTestReports:

    osvvm_uart.ScoreboardPkg_Uart.WriteScoreboardYaml(FileName => "Uart") ;
    EndOfTestReports ; 
    std.env.stop ;

There are examples of this in the OsvvmLibraries/UART/testbench_multiple_uarts – however – note that the examples need to be updated as with release 2024.03, short named parameters (as shown above) became the default. The examples there are still using full file name. I just updated in my copy of the dev release and they will be pushed shortly.

Cheers,
Jim

[Ajeetha Kumari]

Thanks Jim, I understand this better now – it’s scoping issue when multiple types are getting visible to a test.

Regards
Ajeetha

[Author]

Posts