Skip to content

Consider adding a dict export to yaml by defult for DryRun #84

@danielbee

Description

@danielbee

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions