Add initial FuseSoC core file #50
Conversation
Support for [FuseSoC](https://github.com/olofk/fusesoc) will ease use of OSVVM with FuseSoC-built designs, allowing specification of compatible OSVVM versions and hopefully easing support for multiple simulators via FuseSoC's [Edalize](https://github.com/olofk/edalize) backend. FuseSoC uses a `vendor:library:name:version` (VLNV) naming convention for cores. This core would be used as `osvvm:osvvm:utility:YYYY.MM`, leaving space for future core files such as the model library to use their own names under the `osvvm:osvvm` space. While this core file would continue to be updated with OSVVM releases, it would make sense to add copies for each release to the [standard FuseSoC core library](https://github.com/fusesoc/fusesoc-cores). @olofk created [a core in the old FuseSoC standard core library](https://github.com/openrisc/orpsoc-cores/blob/master/cores/osvvm/osvvm-2015.06.core) using the older FuseSoC core API which could be replaced by this core.
|
The core description file looks great to me. There are quite a few FuseSoC VHDL users so it would be great to have proper support for OSVVM |
|
|
||
| name : osvvm:osvvm:utility:2020.05 | ||
|
|
||
| # The Vivado simulator (xsim) does not currently (2020.1) support the VHDL |
There was a problem hiding this comment.
Is TEE the only issue with Viviado?
There was a problem hiding this comment.
I hadn't investigated past the tee error, but it looks like there are several other VHDL 2008 features not supported by the Vivado simulator.
First, it gives the same errors as GHDL regarding the use of Alert from the utility functions. Beyond that it reports it doesn't support context and to_string. Replacing context with use was an easy work around, but there are a lot of uses of to_string in TranscriptPkg and AlertLogPkg that would be more difficult. For example:
ERROR: [XSIM 43-4187] File "../src/osvvm/TranscriptPkg.vhd" Line 123 : The "Vhdl 2008 to_string Operator" is not supported yet for simulation.
I have no idea if it would be possible to use a local version of to_string rather than wait on Xilinx.
| # GHDLs compile-osvvm script currently sets the following options for | ||
| # building OSVVM: | ||
| # | ||
| # -fexplicit -frelaxed-rules --no-vital-checks --warn-binding |
There was a problem hiding this comment.
Why is relaxed-rules required? It would be nice to have bug reports based on the implications of this.
There was a problem hiding this comment.
I opened #51 for this. It looks like several pure utility functions in the coverage package are calling the Alert procedure.
| # ignore. | ||
| # | ||
| ghdl: | ||
| analyze_options: ["-frelaxed-rules", "-Wno-hide"] |
There was a problem hiding this comment.
What are the warnings that -Whide produces? Is it noting anything other than null arrays (which are legal VHDL).
There was a problem hiding this comment.
I believe it's lots of warnings of the form
../src/osvvm/CoveragePkg.vhd:4683:21:warning: declaration of "min" hides enumeration literal min [-Whide]
../src/osvvm/CoveragePkg.vhd:4720:5:warning: declaration of "weight" hides enumeration literal weight [-Whide]
and also
../src/osvvm/AlertLogPkg.vhd:964:7:warning: declaration of "alertcount" hides variable "alertcount" [-Whide]
../src/osvvm/AlertLogPkg.vhd:1121:46:warning: declaration of "alertcount" hides variable "alertcount" [-Whide]
| @@ -0,0 +1,80 @@ | |||
| CAPI=2: | |||
|
|
|||
There was a problem hiding this comment.
Thanks for the pull request.
OSVVM will be hosting a repository (perhaps only releases) at opensource.ieee.org.
To work with them we need an apache license for the file in the same format as
the other osvvm files - other than the things that refer to author and SynthWorks.
Can you also fill out the IEEE CLA at: https://opensource.ieee.org/community/cla
If you don't want it to go to the IEEE repository, can you kindly add some
sort of license to it. As a training provider, I pay attention to copyright laws.
Everything you write, whether marked or not is copyrighted. If you fail to
mark it, then it is copyrighted with all rights reserved - which is kind of
anti-open source.
There was a problem hiding this comment.
Apologies for not marking the file properly. I don't have a personal problem with the IEEE CLA and am tracking down official guidance.
There was a problem hiding this comment.
If a CLA is a problem, to put it into the OSVVM project on GitHub, I would need some sort of open source header on the file - preferably an Apache like the rest of OSVVM.
To include it with the IEEE release, we would need the CLA.
With out a CLA, it would be an exception in our sharing with IEEE. This is ok as so is the documentation.
There was a problem hiding this comment.
I've pushed a commit to properly mark the file, but the CLA process will clearly be slower.
osvvm-utility.core
Outdated
| @@ -1,5 +1,21 @@ | |||
| CAPI=2: | |||
|
|
|||
| # This file is part of OSVVM. | |||
| # | |||
| # (c) Crown Copyright 2020 | |||
There was a problem hiding this comment.
Can you write this in the form:
Copyright (c) 2020 by Crown
Support for FuseSoC will ease use of OSVVM with FuseSoC-built designs, allowing specification of compatible OSVVM versions and hopefully easing support for multiple simulators via FuseSoC's Edalize backend.
FuseSoC uses a
vendor:library:name:version(VLNV) naming convention for cores. This core would be used asosvvm:osvvm:utility:YYYY.MM, leaving space for future core files such as the model library to use their own names under theosvvm:osvvmspace.While this core file would continue to be updated with OSVVM releases, it would make sense to add copies for each release to the standard FuseSoC core library. @olofk created a core in the old FuseSoC standard core library using the older FuseSoC core API which could be replaced by this core.