Dev

[NJDFan]

I had intended this to be a simple small change where I just added Vivado as a possible target, just for the sake of unifying project files between synthesis and simulation. I ran into a problem, though, when trying to call the OSVVM scripts from my own Vivado Tcl which happened in namespaces. OSVVM Scripting did everything against the global namespace, and assuming it was executing in the global namespace. If that assumption was wrong, it got tied in knots.

So that's the bulk of what I've changed here. I changed everything to force itself into the top-level ::osvvm Tcl namespace, and then only export the named procedures. Not knowing who might be using what of those procs I exported nearly everything; someone with more insight than me could profitably tighten that list up (end of OsvvmProjectScripts.tcl) to keep the procs that were meant to be purely internal internal.

• Note: map is one command I did NOT export; ModelSim seems to believe it's a Tcl built-in even though I can't find any reference to it. This can be kludged around easily enough, but warrants investigation.

This is tested and working on ModelSim 2021.1 under Linux. I modified the other vendor-specific files as well, but didn't have the ability to test them. Other modifications I snuck in:

• I added the Vivado vendor-specific stuff. This is tested and working both in the GUI and in a non-project flow, in so far as it works. It allows the use of .pro files to specify file lists to be added to a Vivado design and what libraries they should be in. Simulation requests are entirely ignored, due to the lack of Vivado simulator support for VHDL-2008 generally and OSVVM specifically.
• I added a hook for vendor-specific files to set ::osvvm::DefaultVHDLVersion in order to allow the Vivado builder to default to VHDL-2002, again in response to Vivado's poor handling of VHDL-2008. This hook is necessary because the vendor-specific files are processed before ScriptDefaults.
• I patched include to be able to better handle absolute file paths. I was running into trouble where asking to build a project file using an absolute path was trying to append that absolute path to my relative path. This is tested on Linux, but should be tested under Windows as well.

[JimLewis]

This has been merged on the Dev branch. Will be released with the next revision. I have tested it in Aldec and Mentor tools. Still need to test in GHDL.

[NJDFan]

Great, thanks. I tried it with GHDL, but ran into trouble getting GHDL scripting to work under Linux at all, re: line 52, which is variable console "/dev/pty0"

Under Linux I have no /dev/pty0. I suspect the right answer under Linux is to have $console be null so that the pipeline just feeds tee -a $GHDL_TRANSCRIPT_FILE but haven't gotten a chance to get that squared away yet.

On Tue, Apr 20, 2021 at 9:37 PM JimLewis @.***> wrote:

This has been merged on the Dev branch. Will be released with the next revision. I have tested it in Aldec and Mentor tools. Still need to test in GHDL.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OSVVM/OSVVM-Scripts/pull/7#issuecomment-823769753, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBCACBAGTJJ2XJDT4JMLQDTJZI7HANCNFSM42LTARBA .