GHDL workarounds – any known ones?

Why OSVVM™? › Forums › OSVVM › GHDL workarounds – any known ones?

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • June 5, 2024 at 18:02 #2464
    Ajeetha Kumari
    Member

    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

    June 5, 2024 at 19:54 #2466
    Jim Lewis
    Member

    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

    June 5, 2024 at 20:08 #2467
    Jim Lewis
    Member

    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

    June 6, 2024 at 07:07 #2475
    Ajeetha Kumari
    Member

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

    Regards
    Ajeetha

  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.