I've been mostly* successfully trying out the Dry Run Dict Vendor Script - thanks for including this! Also hoping this issue raises some search engine awareness of the feature too.
- *vendor simulate uses Filename variable instead of LibraryUnit, which causes issues
I wanted to share a pretty minimal example for how you could relatively easily export the source dict into YAML format - helpful for any further processing (particularly in a language that isn't tcl!)
I think OSVVM already requires tcl above a certain version, which I think implies tcllib is available. There's a package called huddle that can be used with yaml that are part of tcllib - they make exporting nested dictionaries slightly easer.
# OSVVM_TOOL2=DryRunDict nvc --do this_script.do
source ~/projects/OsvvmLibraries/Scripts/StartUp.tcl
puts "Simulator Detected as $::osvvm::ScriptBaseName"
puts "Osvvm based in $::OsvvmLibraries"
namespace eval ::osvvm {
# can be DryRunDict or CompileList
variable ScriptBaseName $::env(OSVVM_TOOL2)
source ${::osvvm::OsvvmScriptDirectory}/VendorScripts_${::osvvm::ScriptBaseName}.tcl
}
build $::OsvvmLibraries/OsvvmLibraries.pro
package require yaml
package require huddle
# {library [file {name language_ver}]}
# to be explicit innermost layer could be dict * {string}, but it doesn't have any effect
set myhud [huddle compile {dict * {list {dict}}} $::osvvm::AnalyzeDict]
set write_file [open "analyze.yaml" w]
puts $write_file [yaml::huddle2yaml $myhud]
close $write_file
set write_file [open "analyze.json" w]
puts $write_file [huddle jsondump $myhud]
close $write_file
produces (condensed for clarity):
analyze.yaml
---
osvvm:
-
FileName: >
C:/Users/danie/projects/OsvvmLibraries/osvvm/IfElsePkg.vhd
LanguageVersion: 2019
-
FileName: >
C:/Users/danie/projects/OsvvmLibraries/osvvm/OsvvmTypesPkg.vhd
LanguageVersion: 2019
-
FileName: >
C:/Users/danie/projects/OsvvmLibraries/osvvm/OsvvmScriptSettingsPkg.vhd
LanguageVersion: 2019
osvvm_common:
-
FileName: >
C:/Users/danie/projects/OsvvmLibraries/Common/src/ModelParametersPtPkg.vhd
LanguageVersion: 2019
-
FileName: >
C:/Users/danie/projects/OsvvmLibraries/Common/src/ModelParametersSingletonPkg.vhd
LanguageVersion: 2019
osvvm_uart:
-
FileName: >
C:/Users/danie/projects/OsvvmLibraries/UART/src/UartTbPkg.vhd
LanguageVersion: 2019
-
FileName: >
C:/Users/danie/projects/OsvvmLibraries/UART/src/ScoreboardPkg_Uart.vhd
LanguageVersion: 2019
and
analyze.json
{
"osvvm": [
{
"FileName": "C:\/Users\/danie\/projects\/OsvvmLibraries\/osvvm\/IfElsePkg.vhd",
"LanguageVersion": "2019"
},
{
"FileName": "C:\/Users\/danie\/projects\/OsvvmLibraries\/osvvm\/OsvvmTypesPkg.vhd",
"LanguageVersion": "2019"
},
"osvvm_common": [
{
"FileName": "C:\/Users\/danie\/projects\/OsvvmLibraries\/Common\/src\/ModelParametersPtPkg.vhd",
"LanguageVersion": "2019"
},
{
"FileName": "C:\/Users\/danie\/projects\/OsvvmLibraries\/Common\/src\/ModelParametersSingletonPkg.vhd",
"LanguageVersion": "2019"
},
I don't love that json exporter has decided to mess up with windows file paths.. but it mostly got there.
Do you think it would be worthwhile to have the DryRunDict create an analyze.yml and a simulate.yml by default? I think the huddle and yaml tcl packages are pretty obscure, so it'd be nicer to hide those details in OSVVM layer.
Also, perhaps those packages could be useful for all the existing yaml reporting in OSVVM scripting? It currently looks pretty clunky, particularly if you make changes. Whereas huddle means you don't have to manually iterate and re-state keys or anything (done for you).
By using dry run dict with compile order, if you did a m5sum on the file contents inside the analyse and another one on all the checksums (in compile order) for a library then you have most of the building blocks for a incremental compile feature like VUnit has!
Just some suggestions - no strong urgency or anything. Interested to hear your thoughts.
I've been mostly* successfully trying out the Dry Run Dict Vendor Script - thanks for including this! Also hoping this issue raises some search engine awareness of the feature too.
I wanted to share a pretty minimal example for how you could relatively easily export the source dict into YAML format - helpful for any further processing (particularly in a language that isn't tcl!)
I think OSVVM already requires tcl above a certain version, which I think implies tcllib is available. There's a package called
huddlethat can be used withyamlthat are part of tcllib - they make exporting nested dictionaries slightly easer.produces (condensed for clarity):
analyze.yamland
analyze.json{ "osvvm": [ { "FileName": "C:\/Users\/danie\/projects\/OsvvmLibraries\/osvvm\/IfElsePkg.vhd", "LanguageVersion": "2019" }, { "FileName": "C:\/Users\/danie\/projects\/OsvvmLibraries\/osvvm\/OsvvmTypesPkg.vhd", "LanguageVersion": "2019" }, "osvvm_common": [ { "FileName": "C:\/Users\/danie\/projects\/OsvvmLibraries\/Common\/src\/ModelParametersPtPkg.vhd", "LanguageVersion": "2019" }, { "FileName": "C:\/Users\/danie\/projects\/OsvvmLibraries\/Common\/src\/ModelParametersSingletonPkg.vhd", "LanguageVersion": "2019" },I don't love that json exporter has decided to mess up with windows file paths.. but it mostly got there.
Do you think it would be worthwhile to have the DryRunDict create an analyze.yml and a simulate.yml by default? I think the huddle and yaml tcl packages are pretty obscure, so it'd be nicer to hide those details in OSVVM layer.
Also, perhaps those packages could be useful for all the existing yaml reporting in OSVVM scripting? It currently looks pretty clunky, particularly if you make changes. Whereas huddle means you don't have to manually iterate and re-state keys or anything (done for you).
By using dry run dict with compile order, if you did a m5sum on the file contents inside the analyse and another one on all the checksums (in compile order) for a library then you have most of the building blocks for a incremental compile feature like VUnit has!
Just some suggestions - no strong urgency or anything. Interested to hear your thoughts.