- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Linux platform specific:
It seems that modelsim-ase only works if it is used by the installer. It's installed in our labs by root but when used by the students the following error occurs # Copying /altera/11.0/modelsim_ase/linux/../modelsim.ini to /altera/11.0/modelsim_ase# ** Error: (vmap-7) Failed to open ini file "/altera/11.0/modelsim_ase" in write mode.# Is a directory. (errno = EISDIR)# ** Error: (vmap-20) Cannot access for writing file "/altera/11.0/modelsim_ase".# Permission denied. (errno = EACCES) Temporarily changing the ownership to that of one of the students fixes the problem but only for that student. Also the error messages appear to be wrong as, according to the file date stamps, no overwrite of the files takes place. It seems that it is specifically the ownership that is the issue as the write permissions are not even set anyway and vsim is happy! global read and execute permissions are set on all relevent directories so there should be no permission denied just for access. I came across a similar post relating to windows where it was fixed by changing the file permissions. Has anyone managed to use modelsim-ase from a file server in a multi-user environment?Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[root@ptolome ~]# chmod -R u+s /usr/altera/modelsim_ase/*
[root@ptolome ~]# chmod go+x /usr/altera/modelsim_ase/vco [root@ptolome ~]# chmod -R ugo-w /usr/altera/modelsim_ase/* [root@ptolome ~]# chown -R nobody /usr/altera/modelsim_ase/* would seem to be a workaround but I get very twitchy with setting the suid bit. Unsetting the write bit on everything would seem to confirm that it's the ownership not write permission that is the issue. I haven't fully tested this yet but so far....- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- # Copying /altera/11.0/modelsim_ase/linux/../modelsim.ini to /altera/11.0/modelsim_ase# ** Error: (vmap-7) Failed to open ini file "/altera/11.0/modelsim_ase" in write mode.# Is a directory. (errno = EISDIR)# ** Error: (vmap-20) Cannot access for writing file "/altera/11.0/modelsim_ase".# Permission denied. (errno = EACCES) --- Quote End --- Modelsim uses modelsim.ini to track the location of mapped libraries. You should always have the original file read-only. That way, Modelsim will copy the file to the student's own working folder (where they have write permission). ls -aln modelsim.ini Should show the mode as 644. Cheers, Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Dave,
That's what I thought should happen. The initialisation script seems to be trying to copy modelsim.ini to itself which obviously wouldn't work unless you were the owner. Copying /altera/11.0/modelsim_ase/linux/../modelsim.ini to /altera/11.0/modelsim_ase I cant' find where/why that write is happening. If the user owns the original then it writes a local copy no problem. Permissions were set as per the install script which was 644. My previous workaround was gross overkill and caused other problems. Undoing all that and just changing the owner of modelsim.ini to 'nobody' and setting the suid bit fixes the problem. -r-Sr--r-- 1 nobody users 15995 Apr 28 2011 /usr/altera/modelsim_ase/modelsim.ini The above permissions work fine and suid nobody is fairly safe. Nice to find a fix just before hometime on a Friday, it's 5.30pm here :-) Regards, Nigel- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- That's what I thought should happen. The initialisation script seems to be trying to copy modelsim.ini to itself which obviously wouldn't work unless you were the owner. Copying /altera/11.0/modelsim_ase/linux/../modelsim.ini to /altera/11.0/modelsim_ase I cant' find where/why that write is happening. If the user owns the original then it writes a local copy no problem. --- Quote End --- That sounds bizarre. I have 11.1sp1 installed on Centos 6.2, and a few other versions under Ubuntu. Write a short Tcl script for Modelsim that triggers this error, and I can see if I reproduce the error. Cheers, Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I use system-wide ModelSim instalations and I never came that issue.
That said, I always create a new ModelSim project for each.. well, project. During the project's setup, ModelSim copies the default .ini file to the project's folder. I have some vague recolection that you may use ModelSim without creating a new project, in which case ModelSim will try to use a common .ini file, which may be the default one.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I have some vague recolection that you may use ModelSim without creating a new project, in which case ModelSim will try to use a common .ini file, which may be the default one. --- Quote End --- I use Modelsim without creating a project (.mpf file) at all. Each version of modelsim gets its own global .ini file, eg., c:/build/modelsim/v10.c_ase/modelsim.ini c:/build/modelsim/v10.c_se/modelsim.ini That way the 'work' library, or my component libraries can live under the version-specific folder and the version specific modelsim.ini contains the mappings. Cheers, Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- That sounds bizarre. I have 11.1sp1 installed on Centos 6.2, and a few other versions under Ubuntu. Write a short Tcl script for Modelsim that triggers this error, and I can see if I reproduce the error. Cheers, Dave --- Quote End --- We're running the electronics lab spin of Fedora 14 in the student labs, Archlinux on my desktop. Stock install of Quartus 11 Full version on my desktop, 11sp1 Full in the labs with standard install of modelsim_ase in both cases. Everything was installed and owned by root in the labs, no problems with Quartus. We haven't been using a custom tcl script. Modelsim is started either via the tools option in quartus with the following quartus_sh -t /usr/altera/quartus/common/tcl/internal/nativelink/qnativesim.tcl --rtl_sim my_pwm_1 my_pwm_1 or as vsim from the command prompt. In either case, if you are not the owner of the .../modelsim_ase/modelsim.ini file then the error message occurs. Altera supports solution is to make everything world writable! Not a good idea for a student lab. As far as creating projects and assuming the ownership of modelsim.ini is correct, then if launched from quartus modelsim creates it's project fine. With vsim one can create a project from within the tool no problem. What is the ownership of the file on your setup? Regards, Nigel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- What is the ownership of the file on your setup? --- Quote End ---
$ ls -al /opt/altera/11.1sp1/modelsim_ase/modelsim.ini
-r--r--r--. 1 root root 16445 Jan 21 12:22 /opt/altera/11.1sp1/modelsim_ase/modelsim.ini
If I start vsim, then because of the way I have things setup I see:
$ vsim
Reading /opt/altera/11.1sp1/modelsim_ase/tcl/vsim/pref.tcl
Reading /home/dwh/dwh/work/vhdl/scripts/modelsim.tcl
MODELSIM (before) = /opt/altera/11.1sp1/modelsim_ase/linux/../modelsim.ini
MODELSIM (after) = /opt/build/modelsim/v10.0c_ase/modelsim.ini
$
The environment variable MODELSIM_TCL can be set to the path of a script that will be run on startup. The messages regarding MODELSIM (before) and MODELSIM (after) relate to the modelsim.ini path before my remapping occurs and then after. In my setup I explicitly change the location the system looks for modelsim.ini, so I am probably circumventing the error you are seeing. If I unset MODELSIM_TCL so that script does not run, then start Modelsim from a shell via vsim, then I can create the following transcript withing Modelsim:
ModelSim> where# Current directory is: /home/dwh# Project is: /opt/altera/11.1sp1/modelsim_ase/linux/../modelsim.ini#
ModelSim> pwd# /home/dwh
ModelSim> vlib mwork
ModelSim> vmap work mwork# Copying /opt/altera/11.1sp1/modelsim_ase/linux/../modelsim.ini to modelsim.ini# Modifying modelsim.ini# ** Warning: Copied /opt/altera/11.1sp1/modelsim_ase/linux/../modelsim.ini to modelsim.ini.# Updated modelsim.ini.
ModelSim> where# Current directory is: /home/dwh# Project is: modelsim.ini#
The command 'where' tells you where Modelsim is looking for modelsim.ini. Note how it copied it to my home directory. Is this different from what you are getting? Cheers, Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the responses, bit of a Doh! moment here. Turned out that one of the environments that we were using had $MODELSIM set to the root of our installation /altera/11.0/modelsim_ase
Interestingly it wasn't preventing the initialisation stages from finding modelsim.ini file as shown in the original post... # Copying /altera/11.0/modelsim_ase/linux/../modelsim.ini to /altera/11.0/modelsim_ase but it was causing the error messages regarding write access and a number of other oddities for example the following error message when attempting to create a new project. On entering a project name in the popup we would get the following error message Invalide (sic) Configurtation/Project file suffix "" Further confusion was added by the fact that the ase version has 2 different splash screens depending on whether it is being run for the first time or not thus leading us to think we had subtly different versions installed. The title bar is also different if you start vsim from the command line or from within quartus->tools->run eda simulation tool->rtl level simulation. The path to the executable is the same in all cases.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Thanks for the responses, bit of a Doh! moment here. Turned out that one of the environments that we were using had $MODELSIM set to the root of our installation /altera/11.0/modelsim_ase --- Quote End --- Ah, so it was just trying to do what you told it to :) Glad you figured it out. Cheers, Dave

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page