[Scons-users] Dealing with an odd dependency

[Brian Cody]

Matthew,

It's nice to see someone take a completely different approach. I think the
fact that we're building VHDL makes this a bit uglier for us versus
verilog. The current solution we have (which works somehow!) is  a single
builder that both executes vlib and makes a modelsim ini.

The original source/target to the builder (whatever you call it when you
only supply one argument to a builder) is the list of _info files to be
created by vlib. The emitter sets the target list to be an an ini file,
plus the _info files. The source list becomes just a template modelsim ini
(which has no local libraries listed). Emitter:

    def _emit_modelsim_libs_and_ini(target, source, env):
        new_targets = [os.path.join(os.path.dirname(str(source[0])),
'../../modelsim.ini')] + source
        new_sources = [os.path.join('third-party/modelsim',
env['BUILD_SPEC'] + '-template.ini')]
        env.SideEffect('phony vlib never ever created target', new_targets)
        return (new_targets, new_sources)

The action of the builder copies the ini template to the destination, and
then runs vlib and vmap for each _info target. We intentionally put
abspaths in the ini file so that it can be used outside of the build by
modelsim.

    def _create_modelsim_libs_and_ini(target, source, env):
        env.Execute(SCons.Script.Copy(target[0], source[0]))
        for library in [str(lib) for lib in target if
str(lib).endswith('_info')]:
            lib_path = os.path.dirname(library)
            lib_name = os.path.basename(lib_path)
            exit_code = env.Execute(SCons.Script.Delete(lib_path))
            exit_code = exit_code or workarounds.execute_in_directory(env,
os.path.dirname(lib_path), ['vlib', lib_name])
            exit_code = exit_code or env.Execute([['vmap',
                                                   '-modelsimini',
                                                   target[0],
                                                   lib_name,

os.path.abspath(lib_path)]])
            if exit_code != 0:
                break
        return exit_code

One thing that I don't know that I really want explained to me is the best
way to treat deal with unequal source lists or target lists. Here I assume
that the ini file is the first target. That's a positional requirement and
it feels icky. Alternatively I could loop over the entire list and fault if
I find more than one ini file, and that seems like a lot of work. Ideally
I'd like to be able to pass around dictionaries instead of lists for
sources and targets. It'd really clean some things up.

Another difference between your implementation and ours is that you compile
individual source files with vcom. We scan through all the vhd files we
want to compile, and through a scanner and toposort we figure out the
required module order in the vcom statement. We've developed a (perhaps
undeserved) mistrust of the modelsim compiler's ability to perform partial
compilations.

Also notice the 'workarounds'. The SCons chdir functionality is broken (it
uses os.chdir), and as far as I can tell, vlib absolutely requires it. Our
workaround uses subprocess with a specified work dir, like SCons ought to.
Your version doesn't bother to change the working directory, so maybe we're
using different versions of modelsim.


On Mon, Dec 8, 2014 at 7:52 PM, Matthew Swabey <mattaw at gmail.com> wrote:

> Here is my attempt to make modelsim behave with SCons. - it doesn't work
> properly yet but would you like to collaborate on improving it. The main
> issues surround identifying systemverilog packages and how to manage
> discovering them and automatically finding the dependencies or do I expect
> the user to manage it.
>
> Anyway this is from my site_scons and and example sconscript and
> sconstruct.
>
> Let me know if you want to try to take things further - it would be great
> to have a better solution to the horror that is modelsim (or I shall have
> to use vcs!)
>
> Matthew
>
> On 5 December 2014 at 15:55, Dirk Bächle <tshortik at gmx.de> wrote:
>
>> On 05.12.2014 21:02, Brian Cody wrote:
>>
>>> Hey, no argument from me about SCons having a legitimate complaint.
>>>
>>> The tool is modelsim. Modelsim relies on an INI file to tell it where
>>> things exist in your file system, e.g. lib_a is c:\here\liba, lib_b is
>>> c:\here\libb, etc. The library is the location of where compiled objects
>>> have been replaced. A caveat to this is that if lib B depends on lib A,
>>> then lib A must be compiled and in the ini file before lib B is compiled.
>>> Then if there's a lib C with a similar dependency on lib B, things start to
>>> chain together.
>>>
>>> [...]
>>>
>>> The library creation does not depend on the ini file. They all can (and
>>> do) run simultaneously. It really just creates a directory with a text file
>>> with some internal modelsim information.
>>> Next vcom can run on any library that depends on no other library.
>>> Next vmap should be run to place those libraries in the ini file (vmap
>>> would definitely need to treat the ini as a side effect at least)
>>> Next vcom can run on any library that depends on just the previously
>>> created libraries.
>>> etc.
>>>
>>>  I googled around a bit and had a short look at what Modelsim does:
>>
>> http://www.tkt.cs.tut.fi/tools/public/tutorials/mentor/
>> modelsim/getting_started/gsms.html
>>
>> I would keep the "init" step of creating libraries separate from
>> compiling them. You could define an option like "INIT", and when it's given
>> on the command-line you only include an "SConscript.init" with the required
>> steps to setup your libs. In "normal" mode, you include the main
>> "SConscript" for running the compiler on the libraries. (could also be
>> solved using Aliases, I guess)
>> About the vcom/vmap commands: you could try to define your Builder from a
>> "list of actions", such that it always automatically runs "vmap" after your
>> actual build command. Then you would probably have to define your *.ini
>> file as both, SideEffect() and Precious().
>>
>> Regards,
>>
>> Dirk
>>
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20141209/310d0473/attachment.html>