JimLewis

JimLewis

VHDL Verification Specialist, OSVVM author, VHDL Trainer (including on OSVVM), IEEE VHDL WG Chair, Yoga Teacher

Member Since 9 years ago

SynthWorks / OSVVM, Tigard, OR

Experience Points
31
follower
Lessons Completed
2
follow
Lessons Completed
18
stars
Best Reply Awards
1
repos

502 contributions in the last year

Pinned
⚡ This repo is for demonstration purposes only.
Activity
Jan
24
3 days ago
push

JimLewis push OSVVM/AXI4

JimLewis
JimLewis

Evolving toward a working test case

commit sha: daf846bc7e99c887d84a3b76dfa11e9b19d753e8

push time in 2 days ago
Jan
23
4 days ago
push

JimLewis push OSVVM/AXI4

JimLewis
JimLewis

Working on test for RECEIVE_READY_WAIT_FOR_GET

commit sha: 91b2d1c3dff72f31dc8074144e687cabbcbb042e

push time in 3 days ago
push

JimLewis push OSVVM/AXI4

JimLewis
JimLewis

Update to handshaking for RECEIVE_READY_WAIT_FOR_GET

commit sha: 3433295a61b843251bc76d7a1a21725931d0eb8d

push time in 3 days ago
push

JimLewis push OSVVM/OSVVM

JimLewis
JimLewis

Updated message from ReportTestSummaries when test results indeterminate

commit sha: 6408d2fb0d7f64f9332c9d4faee65abf5911a53b

push time in 3 days ago
Jan
21
6 days ago
Activity icon
issue

JimLewis issue comment TerosTechnology/colibri

JimLewis
JimLewis

Sphinx builder and autodoc plugin for HDL

@umarcor @LarsAsplund @JimLewis @eine @suzizecat @Paebbels @nfrancque I have been talking a bit with @qarlosalberto about potentially creating a sphinx builder/autodoc plugin for HDL, although I'm more interested in VHDL. I would really like the ability to automatically document VHDL code with autodoc and a VHDL language domain capability. TerosHDL already has autodoc capability for MD/HTML, but it is difficult to manage for large or distributed projects/repos. I am hoping that Sphinx solves this problem and it'd be really nice to eventually have a generic HDL extension in sphinx-contrib that anyone can use with pip and sphinx. Plus, I see a lot of potential for this to be very widely used as HDL documentation is an area where I have not seen a solution that meets most people's needs. I decided to ping y'all as I feel that you might find this valuable for your projects, you might have some good ideas, and I'm also hoping to get some feedback about how you think this should look. Feel free to ping others.

Anyways, if you feel that this discussion belongs on Gitter, the VHDL WG issues, or elsewhere, let me know and I can move it. I am planning to talk with management at my company about sponsoring this effort and Carlos was the first person I thought might be interested in taking this on based on Colibri. I previously attempted to go from Colibri to doxygen/asciidoctor. This proved to be a huge headache for distributed projects and is not going to be easy to maintain. I figured reST and Sphinx seemed like a natural choice as there is an interface to create extensions for other languages, builders, etc. The other reason I want to have a discussion about this is there are already quite a few VHDL autodoc plugins for Asciidoctor and others, but most are dead and I don't think any of them really found the right way to document VHDL or present it in the actual HTML/PDF/etc.

Documenting Source Code

Currently, Colibri and others tend to use some pattern in the comments to differentiate between a comment and documentation. I believe colibri can use any symbol, but it defaults to !, i.e. --!. I think this is a natural direction because VHDL doesn't have any notion of a docstring or similar and I know parsing VHDL is not easy. However, I'm not the biggest fan of that pattern because it's extra typing. If your editor/TerosHDL supports carrying on this comment and symbol with ENTER, then it's not that big of a deal. But, if people don't have that then it's annoying to write and update documentation. Using a different pattern in a multi-line comment makes a little bit more sense to me, but that is only valid for 2008+. I don't think this is viable though.

Instead, I think it should be based on the placement of the comment similar to Python. In python, you can add a docstring by placing the block comment directly underneath the declaration:

def some_func() -> None:
  """This is a docstring you can access with __doc__"""

For VHDL, I think it makes sense to put the documentation after things as well:

entity and_gate is
port (
  a : in std_logic; -- or it could go here
  -- a port documentation

  b : in std_logic;

  -- b port would have no documentation because comment doesn't immediately trail

  z : out std_logic
);
end entity;
-- Documentation for and_gate, ``reST`` is supported and can link to other modules :data:`~lib.pkg.SOME_CONST`.

Or even this maybe, adapting from google's style guide for python:

entity and_gate is
port (
  a : in std_logic;
  b : in std_logic;
  z : out std_logic
);
end entity;
-- Documentation for and_gate, ``reST`` is supported and can link to other modules :data:`~lib.pkg.SOME_CONST`.
--
-- Generics:
-- ...
-- Ports:
--     a: a's documentation
--     b:
--        b's documentation
--       
--        .. deprecated:: 1.0 b will be removed in 2.0. 

Block comments would also be allowed in the same place. I don't like that the documentation is below the entire entity declaration, maybe it makes sense to adopt Python's notation for classes where the docstring is after the class declaration or something like this maybe?

entity and_gate is
-- Documentation for and_gate, ``reST`` is supported and can link to other modules :data:`~lib.pkg.SOME_CONST`.
-- Generics:
-- ...
-- Ports:
--     a: a's documentation
--     b:
--        b's documentation
--       
--        .. deprecated:: 1.0 b will be removed in 2.0. 

port (
  a : in std_logic;
  b : in std_logic;

  z : out std_logic
);
end entity;

Personally I think right before the entity makes sense. However, a lot of people put comment headers in their code so for things like signals/constants/etc. this might jack up the documentation but that could also be something that just has to change if they want to use the tool.

One unknown here is how to provide documentation for a file. I.e. if you have a license at the top of your file, how does the parser know if there is something below it that should be documentation like https://github.com/VUnit/vunit/blob/master/vunit/init.py#L7-L9? I don't necessarily think that this is even needed though. People generally put one package/ent per file so it seems like something that doesn't really matter. Even in cases where someone puts multiple entities/packages in the same file, their documentation for the library already has everything so I can't think of any useful reason to have a global file documentation section.

Layout

Once the documentation is generated, I HATE the idea that tables are used for ports/generics. I don't think it's intuitive, I feel that tables make it so you focus too much on port attributes like the type or size instead of what the port is and how to use it. Instead, I think that it should just look like it does for python:

image

With VHDL, we care more about types/ranges and whatnot, so for this we should include that information in the parameters/generics list.

As for the documentation itself in the image above but for an entity? I think that should be it. All you really care about when instancing it is the API and how to use the component, you don't care about the implementation details and they should be considered private. However, sometimes this is critical to understand, so I think that within the documentation for and_gate, there should be a drop-down to expand the architecture (or architectures) for you to view the internal/private documentation like info about signals, FSM's, etc. Teros has some neat features and internal FSM's etc would be cool to reference in an entity's documentation so it shows up when someone scrolls past and_gate in the documentation. Another neat idea would be to display the block hierarchy, e.g. and_gate and how it connects sub-components. This would be super useful for project documentation where you can go into the top level's documentation and see exactly how everything is connected.

Now for subprograms, packages, etc. it'd just expand on the above ideas to determine a documentation convention along with how it should be displayed.

Annotations/Autodoc

So for autodoc with Python in Sphinx, you can do stuff like this for automagically inserting documentation in a reST document:

.. automodule:: noodle
   :members:

How would these automodule, autoclass,... look for VHDL/HDL? I don't like the idea that we would specify files directly as I will talk about how we can handle that later. I'm kind of thinking that we could use autolibrary which would populate all entitys, packages, architectures, etc in a library:

.. autolibrary:: some_lib
    :members: some_pkg, some_ent, some_ent.some_arch ... <- default if this isn't present is to include everything

As for other annotations, I think referencing other components, subprograms, etc. would use the library if it exists, otherwise the name itself if it is not in a library:

vhdl:ent:`~lib.pkg.ent_name`  <- ~ for only displaying ent_name in docs link
vhdl:func:`lib.pkg.some_function`  <- could be pure or impure, or maybe func and ifunc 
vhdl:proc:`lib.pkg.some_procedure`
vhdl:data:`ent.arch.some_signal`
vhdl:data:`ent.arch.SOME_CONST`
vhdl:type:`lib.pkg.some_type`  <- could be type or subtype, or maybe type and stype
...

Sphinx Building

I am thinking that there would only need to be an HDL extension as the included html builder should still work once it gets the correct information. However, the HDL extension would provide a flag to specify a configuration file. This file would be CSV (or TOML, YAML, or whatever makes sense) that would define all files in the project, their associated library, and anything else needed for building the documentation.

There's probably other stuff I haven't thought about, but this is the gist. Thoughts, suggestions, concerns?

JimLewis
JimLewis

@GlenNicholls I would be happier with --! than being stuck with some automation that tries to find the documentation based on some arbitrary metric. For example, some might like their entity/subprogram documentation before the entity/subprogram and not after.

push

JimLewis push OSVVM/AXI4

JimLewis
JimLewis

Added RECEIVE_READY_WAIT_FOR_GET, Print TLast, Don't print parameters with 0 length.

commit sha: 5f6d13048c3bb077d612242ce529a37d3b43b613

push time in 5 days ago
Jan
20
1 week ago
push

JimLewis push OSVVM/Documentation

JimLewis
JimLewis

Correction to 12.5 concatenation. Thanks Richard

commit sha: 28d81528a8a4f75e98a2093db4ca4d88d51c925b

push time in 6 days ago
Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Scripts

JimLewis
JimLewis

Allow referencing pre-compiled vendor libraries for Active-HDL/Riviera-PRO

In case of OSVVM-based simulation containing encrypted IP cores from e.g. Xilinx Vivado, OSVVM should offer a generic solution to reference pre-compiled vendor libraries.

In our current approach, we use the vmap command in OSVVM's *.pro files to reference a directory containing pre-compiled IP cores. The referenced directory (e.g. dds_compiler_v6_0_20) is referenced and then added by Riviera-PRO to the local library.cfg file.

While this solution solves the problem, a more generic OSVVM-like TCL procedure should be offered to reference pre-compile libraries or IP cores.

Example:

vmap dds_compiler_v6_0_20 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/dds_compiler_v6_0_20}
vmap xbip_utils_v3_0_10 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_utils_v3_0_10}
vmap xbip_pipe_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_pipe_v3_0_6}
vmap axi_utils_v2_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/axi_utils_v2_0_6}
vmap unisim {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/unisim}
vmap xbip_dsp48_multadd_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_dsp48_multadd_v3_0_6}
vmap xbip_bram18k_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_bram18k_v3_0_6}

library myProject
include ../../src/common.pro
include ../../src/testbench.pro
JimLewis
JimLewis

BTW, since your directory names match the library name, both LinkLibrary and LinkLibraryDirectory should work with the 2022.01 release and it does not need the fix I just did. The fix I just did addresses situations like where the logical library name is fred and it is in directory fred_1.41. That would need the newer code that is in Dev.

Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Scripts

JimLewis
JimLewis

Allow referencing pre-compiled vendor libraries for Active-HDL/Riviera-PRO

In case of OSVVM-based simulation containing encrypted IP cores from e.g. Xilinx Vivado, OSVVM should offer a generic solution to reference pre-compiled vendor libraries.

In our current approach, we use the vmap command in OSVVM's *.pro files to reference a directory containing pre-compiled IP cores. The referenced directory (e.g. dds_compiler_v6_0_20) is referenced and then added by Riviera-PRO to the local library.cfg file.

While this solution solves the problem, a more generic OSVVM-like TCL procedure should be offered to reference pre-compile libraries or IP cores.

Example:

vmap dds_compiler_v6_0_20 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/dds_compiler_v6_0_20}
vmap xbip_utils_v3_0_10 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_utils_v3_0_10}
vmap xbip_pipe_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_pipe_v3_0_6}
vmap axi_utils_v2_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/axi_utils_v2_0_6}
vmap unisim {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/unisim}
vmap xbip_dsp48_multadd_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_dsp48_multadd_v3_0_6}
vmap xbip_bram18k_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_bram18k_v3_0_6}

library myProject
include ../../src/common.pro
include ../../src/testbench.pro
JimLewis
JimLewis

Since your library name and the directory name match, you can also do: LinkLibraryDirectory C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2

And that will get all of them.

Jan
19
1 week ago
Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Scripts

JimLewis
JimLewis

Allow referencing pre-compiled vendor libraries for Active-HDL/Riviera-PRO

In case of OSVVM-based simulation containing encrypted IP cores from e.g. Xilinx Vivado, OSVVM should offer a generic solution to reference pre-compiled vendor libraries.

In our current approach, we use the vmap command in OSVVM's *.pro files to reference a directory containing pre-compiled IP cores. The referenced directory (e.g. dds_compiler_v6_0_20) is referenced and then added by Riviera-PRO to the local library.cfg file.

While this solution solves the problem, a more generic OSVVM-like TCL procedure should be offered to reference pre-compile libraries or IP cores.

Example:

vmap dds_compiler_v6_0_20 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/dds_compiler_v6_0_20}
vmap xbip_utils_v3_0_10 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_utils_v3_0_10}
vmap xbip_pipe_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_pipe_v3_0_6}
vmap axi_utils_v2_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/axi_utils_v2_0_6}
vmap unisim {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/unisim}
vmap xbip_dsp48_multadd_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_dsp48_multadd_v3_0_6}
vmap xbip_bram18k_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_bram18k_v3_0_6}

library myProject
include ../../src/common.pro
include ../../src/testbench.pro
JimLewis
JimLewis

All except for the last form which takes any old directory you wish.

Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Scripts

JimLewis
JimLewis

Allow referencing pre-compiled vendor libraries for Active-HDL/Riviera-PRO

In case of OSVVM-based simulation containing encrypted IP cores from e.g. Xilinx Vivado, OSVVM should offer a generic solution to reference pre-compiled vendor libraries.

In our current approach, we use the vmap command in OSVVM's *.pro files to reference a directory containing pre-compiled IP cores. The referenced directory (e.g. dds_compiler_v6_0_20) is referenced and then added by Riviera-PRO to the local library.cfg file.

While this solution solves the problem, a more generic OSVVM-like TCL procedure should be offered to reference pre-compile libraries or IP cores.

Example:

vmap dds_compiler_v6_0_20 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/dds_compiler_v6_0_20}
vmap xbip_utils_v3_0_10 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_utils_v3_0_10}
vmap xbip_pipe_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_pipe_v3_0_6}
vmap axi_utils_v2_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/axi_utils_v2_0_6}
vmap unisim {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/unisim}
vmap xbip_dsp48_multadd_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_dsp48_multadd_v3_0_6}
vmap xbip_bram18k_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_bram18k_v3_0_6}

library myProject
include ../../src/common.pro
include ../../src/testbench.pro
JimLewis
JimLewis

Sometimes I really hate md. Like when I need to specify < and >

Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Scripts

JimLewis
JimLewis

Allow referencing pre-compiled vendor libraries for Active-HDL/Riviera-PRO

In case of OSVVM-based simulation containing encrypted IP cores from e.g. Xilinx Vivado, OSVVM should offer a generic solution to reference pre-compiled vendor libraries.

In our current approach, we use the vmap command in OSVVM's *.pro files to reference a directory containing pre-compiled IP cores. The referenced directory (e.g. dds_compiler_v6_0_20) is referenced and then added by Riviera-PRO to the local library.cfg file.

While this solution solves the problem, a more generic OSVVM-like TCL procedure should be offered to reference pre-compile libraries or IP cores.

Example:

vmap dds_compiler_v6_0_20 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/dds_compiler_v6_0_20}
vmap xbip_utils_v3_0_10 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_utils_v3_0_10}
vmap xbip_pipe_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_pipe_v3_0_6}
vmap axi_utils_v2_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/axi_utils_v2_0_6}
vmap unisim {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/unisim}
vmap xbip_dsp48_multadd_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_dsp48_multadd_v3_0_6}
vmap xbip_bram18k_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_bram18k_v3_0_6}

library myProject
include ../../src/common.pro
include ../../src/testbench.pro
JimLewis
JimLewis

LinkLibrary

WRT it is going to go through a search for OSVVM type patterns, but if it does not find any, then it uses that path as the actual directory of the library.

OSVVM Library search looks for the existence of the following paths: /VHDL_LIBS/<tool_revision>/ /VHDL_LIBS/<tool_revision> /<tool_revision>/ /<tool_revision> /

When you are using an externally generated library, you are following the last case .

OSVVM creates library names in the following format: /VHDL_LIBS/<tool_revision>/

LinkLibrary allows the above to be specified as any of the following. The idea is if they are confused as to which to specify for the library path, it just works with anything sensible. /VHDL_LIBS /VHDL_LIBS/<tool_revision> /VHDL_LIBS/<tool_revision>/

Activity icon
issue

JimLewis issue comment OSVVM/OsvvmLibraries

JimLewis
JimLewis

Cannot use OsvvmLibraries.pro to compile external library for VUnit with Riviera-PRO

Hi, I am unable to use OSVVM as compiled by the OsvvmLibraries.pro script as an external library in VUnit. This seems to be because the physical_name parameter of the vmap/amap command in Riviera-PRO requires either:

  1. The path to the directory of the .lib file, where the file has the same name as the containing directory with the .lib extension
  2. The path to the .lib file itself, with or without the .lib extension, the lib file and the directory name do not have to match

VUnit supports only 1), whereas OSVVM when compiled using the included scripts requires 2).

I have also raised this at https://github.com/VUnit/vunit/issues/754.

JimLewis
JimLewis

@as266 2021.12 updated OSVVM library handling. In addition, I just pushed some changes to OSVVM's LinkLibrary, to better support linking to externally generated libraries - previously it had a limitation in that it expected a particular naming pattern for the libraries and only then would link the library.

Activity icon
issue

JimLewis issue OSVVM/OsvvmLibraries

JimLewis
JimLewis

LinkCurrentLibraries fails on Linux if Library Folder Names contain Uppercase characters

Scenario / Issue:

After changing directories using "cd", I called LinkCurrentLibraries, as shown in the following ModelSim transcript:

# reading modelsim.ini
LinkCurrentLibraries
# LinkLibrary: /home/fpga/tools/OsvvmLibraries_compiled/2021.12/VHDL_LIBS/ModelSim-2019.10/osvvm_tbaxistream does not exist.  

ls /home/fpga/tools/OsvvmLibraries_compiled/2021.12/VHDL_LIBS/ModelSim-2019.10/
# osvvm
# osvvm_axi4
# OSVVM_Common
# osvvm_TbAxi4
# osvvm_TbAxi4Lite
# osvvm_TbAxi4_MultipleMemory
# osvvm_TbAxiStream
# osvvm_TbUart
# osvvm_uart

Discussion:

As shown above, this results in a "does not exist" error for the libraries who's folder names (on the disk) contain upper case characters.

This is caused by case sensitivity of path and filenames under Linux, and the fact that the LinkLibrary function (called by LinkCurrentLibraries) uses the stored Library names (which have been converted to lowercase). It is likely this issue also affects other functions, but I have not done a detailed investigation of the extent.

I see two potential options for fixing this:

  1. Maintain case as provided by the user when adding libraries to the library list. (This may not be feasible, if any of the Simulation tools converts to lowercase when creating libraries.)
  2. Continue to convert everything to lowercase when adding to the library list, and also convert to lowercase prior to creating folder structure (i.e. before passing library name to "vmap", in the ModelSim-specific case).

Other solutions may be feasible (and potentially better). This will probably require a survey of the code.

Temporary Workaround:

LinkLibraryDirectory can be used until this issue is fixed (potentially multiple times, to handle multiple library directories) to relink libraries after a directory change. This is obviously inconvenient for a large number of library directories, but it does work (since LinkLibraryDirectory scans the available library folder names on the disk, rather than using the names in the stored library list).

Example: LinkLibraryDirectory /home/fpga/tools/OsvvmLibraries_compiled/2021.12

Activity icon
issue

JimLewis issue comment OSVVM/OsvvmLibraries

JimLewis
JimLewis

LinkCurrentLibraries fails on Linux if Library Folder Names contain Uppercase characters

Scenario / Issue:

After changing directories using "cd", I called LinkCurrentLibraries, as shown in the following ModelSim transcript:

# reading modelsim.ini
LinkCurrentLibraries
# LinkLibrary: /home/fpga/tools/OsvvmLibraries_compiled/2021.12/VHDL_LIBS/ModelSim-2019.10/osvvm_tbaxistream does not exist.  

ls /home/fpga/tools/OsvvmLibraries_compiled/2021.12/VHDL_LIBS/ModelSim-2019.10/
# osvvm
# osvvm_axi4
# OSVVM_Common
# osvvm_TbAxi4
# osvvm_TbAxi4Lite
# osvvm_TbAxi4_MultipleMemory
# osvvm_TbAxiStream
# osvvm_TbUart
# osvvm_uart

Discussion:

As shown above, this results in a "does not exist" error for the libraries who's folder names (on the disk) contain upper case characters.

This is caused by case sensitivity of path and filenames under Linux, and the fact that the LinkLibrary function (called by LinkCurrentLibraries) uses the stored Library names (which have been converted to lowercase). It is likely this issue also affects other functions, but I have not done a detailed investigation of the extent.

I see two potential options for fixing this:

  1. Maintain case as provided by the user when adding libraries to the library list. (This may not be feasible, if any of the Simulation tools converts to lowercase when creating libraries.)
  2. Continue to convert everything to lowercase when adding to the library list, and also convert to lowercase prior to creating folder structure (i.e. before passing library name to "vmap", in the ModelSim-specific case).

Other solutions may be feasible (and potentially better). This will probably require a survey of the code.

Temporary Workaround:

LinkLibraryDirectory can be used until this issue is fixed (potentially multiple times, to handle multiple library directories) to relink libraries after a directory change. This is obviously inconvenient for a large number of library directories, but it does work (since LinkLibraryDirectory scans the available library folder names on the disk, rather than using the names in the stored library list).

Example: LinkLibraryDirectory /home/fpga/tools/OsvvmLibraries_compiled/2021.12

JimLewis
JimLewis

This is fixed in the current release. 2022.01. Please reopen or open a new issue if you find additional problems.

Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Scripts

JimLewis
JimLewis

Allow referencing pre-compiled vendor libraries for Active-HDL/Riviera-PRO

In case of OSVVM-based simulation containing encrypted IP cores from e.g. Xilinx Vivado, OSVVM should offer a generic solution to reference pre-compiled vendor libraries.

In our current approach, we use the vmap command in OSVVM's *.pro files to reference a directory containing pre-compiled IP cores. The referenced directory (e.g. dds_compiler_v6_0_20) is referenced and then added by Riviera-PRO to the local library.cfg file.

While this solution solves the problem, a more generic OSVVM-like TCL procedure should be offered to reference pre-compile libraries or IP cores.

Example:

vmap dds_compiler_v6_0_20 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/dds_compiler_v6_0_20}
vmap xbip_utils_v3_0_10 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_utils_v3_0_10}
vmap xbip_pipe_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_pipe_v3_0_6}
vmap axi_utils_v2_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/axi_utils_v2_0_6}
vmap unisim {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/unisim}
vmap xbip_dsp48_multadd_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_dsp48_multadd_v3_0_6}
vmap xbip_bram18k_v3_0_6 {C:/Tools/Precompiled/Riviera-PRO/2021.10/Vivado/2020.2/xbip_bram18k_v3_0_6}

library myProject
include ../../src/common.pro
include ../../src/testbench.pro
JimLewis
JimLewis

@Paebbels LinkLibrary has been updated such that if the directory supplied is not an osvvm library directory, then it is assumed to by a valid library directory by itself and vmap is called as above.

This has been pushed to Dev. Please test.

push

JimLewis push OSVVM/OSVVM-Scripts

JimLewis
JimLewis

In vendor_LinkLibrary use ${PathToLib} as the lib directory if ${PathToLib}/${LibraryName} does not exist

commit sha: 67da131f4ad5e0cc6fd308a977cf8794cc49eb90

push time in 1 week ago
Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Common

JimLewis
JimLewis

Where to release OSVVM based timing checks?

I have developed some timing checks based on the OSVVM lecture material that integrates the basic timing check processes into the AlertLog hierarchy and allows OSVVM-based verification models to add timing checks by instantiating these checks.

Example:

library ieee ;
  use ieee.std_logic_1164.all ;

library osvvm ;
  context osvvm.OsvvmContext ;

entity SetupTimeCheck is
    generic(
        MaxCount   : positive;
        SignalName : string;
        Message    : string := "Setup Violation on"
    );
    port(
        ParentAlertLogID : in AlertLogIDType;
        SetupTime        : in time;

        Clock : in std_logic;
        Data  : in std_logic
    ) ;
end entity;

architecture checker of SetupTimeCheck is
    constant MODEL_INSTANCE_NAME : string := PathTail(SetupTimeCheck'PATH_NAME);
    signal ModelID : AlertLogIDType;

begin
    InitProc: process
    begin
        wait on ParentAlertLogID;
        ModelID <= GetAlertLogID(MODEL_INSTANCE_NAME, ParentAlertLogID);
        wait;
    end process;
    
    SetupTimeCheckProc: process
        variable count : natural := MaxCount;
    begin
        wait until Clock = '1';
        if (Data'last_event <= SetupTime)then
            count := count - 1;
            Alert(ModelID, ("Model: " & Message & " '" & SignalName & "'"));
        end if;

        if (count = 0) then
            wait;
        end if;
    end process;
end architecture;

Proposed locations:

  • in OSVVM-Common (as it holds already common verification components and packages supporting various VCs)
  • as separate repository (might be to complex)

The following checks can be offered in a first iteration:

  • Setup time check
  • Hold time check
  • Cycle time check (clock period)
  • Pulse width check

Possible other checkers:

  • Duty cycle
  • Response check
    (rise in A → rise on B after X ns but within Y ns)

Possible enhancements:

  • Change specific timing to a range of Min/Max (e.g. account for jitter on a clock line).
  • Configurable polarity

The following additions to AlertLog would be great to support a better user experience:

  • Add an attribute to each AlertLogID to stop reporting messages after N occurrences, but keep counting for the final AlertLog report
  • Allow ordering of AlertLogIDs (lines in the AlertLog report). Currently, the log reports has in indeterministic order of items due to registering all timing checks in the same Δ-cycle. I currently do some ordering using block statements and Δ-cycle delays on ModelIDs, so timing checks are registers Δ+1 compared to e.g. an SPI controller in an DAC verification component.
JimLewis
JimLewis

I agree the checks need to report via AlertLog, however, if we did not have to write the base check, that would be nice.

Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Common

JimLewis
JimLewis

Add infrastructure for bidirectional streaming

When implementing a verification component with bidirectional streaming like SPI. Some additions are needed in the StreamTransactionPkg.

  1. Additional enumeration values in StreamUnresolvedOperationType:
      CHECK_BURST,
      TRY_CHECK_BURST,
    +  -- Bi-directional data transfer
    +  SEND_AND_GET,
    +  SEND_AND_GET_BURST,
    +
      MULTIPLE_DRIVER_DETECT  -- value used when multiple drivers are present
    ) ;
    
  2. A new Get procedure with an input and output data parameter for bidirectional data exchange.
    Because parameter modes do not distinguish subprogram overloads, a different name is needed.
    In a proof-of-concept implementation, Get2 is used.
      ------------------------------------------------------------
      procedure Get (
      ------------------------------------------------------------
        signal    TransactionRec  : inout StreamRecType ;
        variable  Data            : out   std_logic_vector ;
        variable  Param           : out   std_logic_vector ;
        constant  StatusMsgOn     : in    boolean := FALSE 
      ) ; 
    
    +  ------------------------------------------------------------
    +  procedure Get2 (
    +  ------------------------------------------------------------
    +    signal    TransactionRec  : inout StreamRecType ;
    +    variable  Data            : out   std_logic_vector ;
    +    constant  Param           : in    std_logic_vector ;
    +    constant  StatusMsgOn     : in    boolean := FALSE 
    +  ) ; 
    +
      ------------------------------------------------------------
      procedure Get (
      ------------------------------------------------------------
        signal    TransactionRec  : inout StreamRecType ;
        variable  Data            : out   std_logic_vector ;
        constant  StatusMsgOn     : in    boolean := FALSE 
      ) ; 
    
    Here the procedure body:
      ------------------------------------------------------------
      procedure Get (
      ------------------------------------------------------------
        signal    TransactionRec  : inout StreamRecType ;
        variable  Data            : out   std_logic_vector ;
        constant  StatusMsgOn     : in    boolean := FALSE 
      ) is 
      begin
        TransactionRec.Operation   <= GET ;
        TransactionRec.IntToModel  <= Data'length ;
        TransactionRec.BoolToModel <= StatusMsgOn ;     
        RequestTransaction(Rdy => TransactionRec.Rdy, Ack => TransactionRec.Ack) ; 
        Data  := SafeResize(TransactionRec.DataFromModel, Data'length) ; 
      end procedure Get ; 
    
    +  ------------------------------------------------------------
    +  procedure Get2 (
    +  ------------------------------------------------------------
    +    signal    TransactionRec  : inout StreamRecType ;
    +    variable  Data            : out   std_logic_vector ;
    +    constant  Param           : in    std_logic_vector ;
    +    constant  StatusMsgOn     : in    boolean := FALSE 
    +  ) is 
    +    variable LocalParam : std_logic_vector(TransactionRec.ParamToModel'length -1 downto 0) := (others => '-') ;
    +  begin
    +    LocalParam(Param'length-1 downto 0) := Param ; 
    +    LocalSend(TransactionRec, GET, (Data'range => 'U'), LocalParam, StatusMsgOn) ;
    +    Data  := SafeResize(TransactionRec.DataFromModel, Data'length) ; 
    +  end procedure Get2 ; 
    +	
      ------------------------------------------------------------
      procedure Get (
      ------------------------------------------------------------
        signal    TransactionRec  : inout StreamRecType ;
        variable  Data            : out   std_logic_vector ;
        variable  Param           : out   std_logic_vector ;
        constant  StatusMsgOn     : in    boolean := FALSE 
      ) is 
      begin
        Get(TransactionRec, Data, StatusMsgOn) ;
        Param := SafeResize(TransactionRec.ParamFromModel, Param'length) ; 
      end procedure Get ;  
    
JimLewis
JimLewis
Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Common

JimLewis
JimLewis

Where to release OSVVM based timing checks?

I have developed some timing checks based on the OSVVM lecture material that integrates the basic timing check processes into the AlertLog hierarchy and allows OSVVM-based verification models to add timing checks by instantiating these checks.

Example:

library ieee ;
  use ieee.std_logic_1164.all ;

library osvvm ;
  context osvvm.OsvvmContext ;

entity SetupTimeCheck is
    generic(
        MaxCount   : positive;
        SignalName : string;
        Message    : string := "Setup Violation on"
    );
    port(
        ParentAlertLogID : in AlertLogIDType;
        SetupTime        : in time;

        Clock : in std_logic;
        Data  : in std_logic
    ) ;
end entity;

architecture checker of SetupTimeCheck is
    constant MODEL_INSTANCE_NAME : string := PathTail(SetupTimeCheck'PATH_NAME);
    signal ModelID : AlertLogIDType;

begin
    InitProc: process
    begin
        wait on ParentAlertLogID;
        ModelID <= GetAlertLogID(MODEL_INSTANCE_NAME, ParentAlertLogID);
        wait;
    end process;
    
    SetupTimeCheckProc: process
        variable count : natural := MaxCount;
    begin
        wait until Clock = '1';
        if (Data'last_event <= SetupTime)then
            count := count - 1;
            Alert(ModelID, ("Model: " & Message & " '" & SignalName & "'"));
        end if;

        if (count = 0) then
            wait;
        end if;
    end process;
end architecture;

Proposed locations:

  • in OSVVM-Common (as it holds already common verification components and packages supporting various VCs)
  • as separate repository (might be to complex)

The following checks can be offered in a first iteration:

  • Setup time check
  • Hold time check
  • Cycle time check (clock period)
  • Pulse width check

Possible other checkers:

  • Duty cycle
  • Response check
    (rise in A → rise on B after X ns but within Y ns)

Possible enhancements:

  • Change specific timing to a range of Min/Max (e.g. account for jitter on a clock line).
  • Configurable polarity

The following additions to AlertLog would be great to support a better user experience:

  • Add an attribute to each AlertLogID to stop reporting messages after N occurrences, but keep counting for the final AlertLog report
  • Allow ordering of AlertLogIDs (lines in the AlertLog report). Currently, the log reports has in indeterministic order of items due to registering all timing checks in the same Δ-cycle. I currently do some ordering using block statements and Δ-cycle delays on ModelIDs, so timing checks are registers Δ+1 compared to e.g. an SPI controller in an DAC verification component.
JimLewis
JimLewis

We would probably want to look at what Vital provides and what OVL provides to make sure we are not creating duplicates.

You can find OVL here: https://www.accellera.org/downloads/standards/ovl/ovl-statement-of-use A quick look says they don't do this.

VITAL probably does though, but in a much more complicated way.

Activity icon
issue

JimLewis issue comment OSVVM/OSVVM-Common

JimLewis
JimLewis

Add infrastructure for bidirectional streaming

When implementing a verification component with bidirectional streaming like SPI. Some additions are needed in the StreamTransactionPkg.

  1. Additional enumeration values in StreamUnresolvedOperationType:
      CHECK_BURST,
      TRY_CHECK_BURST,
    +  -- Bi-directional data transfer
    +  SEND_AND_GET,
    +  SEND_AND_GET_BURST,
    +
      MULTIPLE_DRIVER_DETECT  -- value used when multiple drivers are present
    ) ;
    
  2. A new Get procedure with an input and output data parameter for bidirectional data exchange.
    Because parameter modes do not distinguish subprogram overloads, a different name is needed.
    In a proof-of-concept implementation, Get2 is used.
      ------------------------------------------------------------
      procedure Get (
      ------------------------------------------------------------
        signal    TransactionRec  : inout StreamRecType ;
        variable  Data            : out   std_logic_vector ;
        variable  Param           : out   std_logic_vector ;
        constant  StatusMsgOn     : in    boolean := FALSE 
      ) ; 
    
    +  ------------------------------------------------------------
    +  procedure Get2 (
    +  ------------------------------------------------------------
    +    signal    TransactionRec  : inout StreamRecType ;
    +    variable  Data            : out   std_logic_vector ;
    +    constant  Param           : in    std_logic_vector ;
    +    constant  StatusMsgOn     : in    boolean := FALSE 
    +  ) ; 
    +
      ------------------------------------------------------------
      procedure Get (
      ------------------------------------------------------------
        signal    TransactionRec  : inout StreamRecType ;
        variable  Data            : out   std_logic_vector ;
        constant  StatusMsgOn     : in    boolean := FALSE 
      ) ; 
    
    Here the procedure body:
      ------------------------------------------------------------
      procedure Get (
      ------------------------------------------------------------
        signal    TransactionRec  : inout StreamRecType ;
        variable  Data            : out   std_logic_vector ;
        constant  StatusMsgOn     : in    boolean := FALSE 
      ) is 
      begin
        TransactionRec.Operation   <= GET ;
        TransactionRec.IntToModel  <= Data'length ;
        TransactionRec.BoolToModel <= StatusMsgOn ;     
        RequestTransaction(Rdy => TransactionRec.Rdy, Ack => TransactionRec.Ack) ; 
        Data  := SafeResize(TransactionRec.DataFromModel, Data'length) ; 
      end procedure Get ; 
    
    +  ------------------------------------------------------------
    +  procedure Get2 (
    +  ------------------------------------------------------------
    +    signal    TransactionRec  : inout StreamRecType ;
    +    variable  Data            : out   std_logic_vector ;
    +    constant  Param           : in    std_logic_vector ;
    +    constant  StatusMsgOn     : in    boolean := FALSE 
    +  ) is 
    +    variable LocalParam : std_logic_vector(TransactionRec.ParamToModel'length -1 downto 0) := (others => '-') ;
    +  begin
    +    LocalParam(Param'length-1 downto 0) := Param ; 
    +    LocalSend(TransactionRec, GET, (Data'range => 'U'), LocalParam, StatusMsgOn) ;
    +    Data  := SafeResize(TransactionRec.DataFromModel, Data'length) ; 
    +  end procedure Get2 ; 
    +	
      ------------------------------------------------------------
      procedure Get (
      ------------------------------------------------------------
        signal    TransactionRec  : inout StreamRecType ;
        variable  Data            : out   std_logic_vector ;
        variable  Param           : out   std_logic_vector ;
        constant  StatusMsgOn     : in    boolean := FALSE 
      ) is 
      begin
        Get(TransactionRec, Data, StatusMsgOn) ;
        Param := SafeResize(TransactionRec.ParamFromModel, Param'length) ; 
      end procedure Get ;  
    
JimLewis
JimLewis

Didn't you use the AddressBus package instead?

A SendGet would need to have iData and oData right? As well as perhaps iParam and oParam?

open pull request

JimLewis wants to merge OSVVM/OSVVM

JimLewis
JimLewis

Consistent naming, minor additions

suggestion to make naming more clear and consistent: always use actual/expected instead of L/R minor hopefully useful addions to the ScoreBoard and TbUtilPkg

JimLewis
JimLewis

From an OSVVM verification suite perspective, the impact of changing AlertIfEqual/AlertIfNotEqual is relatively minor.

OTOH, changing AffirmIfEqual will require significant more work in updating the checking. So it would be a low priority update relative to other tasks that need to be done.

pull request

JimLewis merge to OSVVM/OSVVM

JimLewis
JimLewis

Consistent naming, minor additions

suggestion to make naming more clear and consistent: always use actual/expected instead of L/R minor hopefully useful addions to the ScoreBoard and TbUtilPkg

open pull request

JimLewis wants to merge OSVVM/OSVVM

JimLewis
JimLewis

Consistent naming, minor additions

suggestion to make naming more clear and consistent: always use actual/expected instead of L/R minor hopefully useful addions to the ScoreBoard and TbUtilPkg

JimLewis
JimLewis

For AlertIfEqual we could say, Parameters expected to be not equal, Param1 = ... Param2 = ....

For AlertIfNotEqual we could say, Parameters expected to be equal, Param1 = ... Param2 = ....

pull request

JimLewis merge to OSVVM/OSVVM

JimLewis
JimLewis

Consistent naming, minor additions

suggestion to make naming more clear and consistent: always use actual/expected instead of L/R minor hopefully useful addions to the ScoreBoard and TbUtilPkg

open pull request

JimLewis wants to merge OSVVM/OSVVM

JimLewis
JimLewis

Consistent naming, minor additions

suggestion to make naming more clear and consistent: always use actual/expected instead of L/R minor hopefully useful addions to the ScoreBoard and TbUtilPkg

JimLewis
JimLewis

@Paebbels The intended use model for AffirmIf is to cover all uses cases of self checking. This is where actual/expected or received/expected make sense.

The intended use model for AlertIfEqual/AlertIfNotEqual is for parameter checking. It is not clear to me how actual/expected or received/expected make any sense in the above parameter check example above. Let me be honest, I don't particularly like L and R, however, give me something that works. You can see that they do not work for my example above right?

pull request

JimLewis merge to OSVVM/OSVVM

JimLewis
JimLewis

Consistent naming, minor additions

suggestion to make naming more clear and consistent: always use actual/expected instead of L/R minor hopefully useful addions to the ScoreBoard and TbUtilPkg

Jan
18
1 week ago
open pull request

JimLewis wants to merge OSVVM/OSVVM

JimLewis
JimLewis

Consistent naming, minor additions

suggestion to make naming more clear and consistent: always use actual/expected instead of L/R minor hopefully useful addions to the ScoreBoard and TbUtilPkg

JimLewis
JimLewis

Currently we do not delete/deallocate items in the singletons. That is something I am currently working on and expect to be in one of the next two releases.

pull request

JimLewis merge to OSVVM/OSVVM

JimLewis
JimLewis

Consistent naming, minor additions

suggestion to make naming more clear and consistent: always use actual/expected instead of L/R minor hopefully useful addions to the ScoreBoard and TbUtilPkg

Previous