cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
centercitybill
Adventurer
Adventurer
9,051 Views
Registered: ‎01-27-2016

ERROR: [Simulator 45-7] No such file 'C:/Users/kirscwm1/Documents/My' in the design.

Jump to solution

I am getting the error posted in the subject line. I am using Vivado 2017.3, Windows 7. There is nothing in the simulation.log file to help find the source of the error. 

Below are the messages I get in the Tcl console. I saw one post with a similar problem, but they were running vivado in Xilinx. I have also attached the test bench. Thanks.

 

Running: C:/Xilinx/Vivado/2017.3/bin/unwrapped/win64.o/xelab.exe -wto 7c66c1eefd4f4abfb45e34c8c4d85447 --incr --debug typical --relax --mt 2 -L xil_defaultlib -L secureip --snapshot tb_fir_double_dsp_behav xil_defaultlib.tb_fir_double_dsp -log elaborate.log
Using 2 slave threads.
Starting static elaboration
Completed static elaboration
INFO: [XSIM 43-4323] No Change in HDL. Linking previously generated obj files to create kernel
run_program: Time (s): cpu = 00:00:00 ; elapsed = 00:00:11 . Memory (MB): peak = 923.668 ; gain = 0.000
INFO: [USF-XSim-69] 'elaborate' step finished in '11' seconds
INFO: [USF-XSim-4] XSim::Simulate design
INFO: [USF-XSim-61] Executing 'SIMULATE' step in 'C:/HDL/fir_dsp_double/fir_dsp_double.sim/sim_1/behav/xsim'
INFO: [USF-XSim-98] *** Running xsim
with args "tb_fir_double_dsp_behav -key {Behavioral:sim_1:Functional:tb_fir_double_dsp} -tclbatch {tb_fir_double_dsp.tcl} -view {C:/HDL/fir_dsp_double/tb_fir_double_dsp_behav.wcfg} -log {simulate.log}"
INFO: [USF-XSim-8] Loading simulator feature
Vivado Simulator 2017.3
Time resolution is 1 ps
ERROR: [Simulator 45-7] No such file 'C:/Users/kirscwm1/Documents/My' in the design.

ERROR: [USF-XSim-62] 'simulate' step failed with errors. Please check the Tcl console or log files for more information.
ERROR: [Vivado 12-4473] Detected error while running simulation. Please correct the issue and retry this operation.
launch_simulation: Time (s): cpu = 00:00:01 ; elapsed = 00:00:26 . Memory (MB): peak = 923.668 ; gain = 0.000
ERROR: [Common 17-39] 'launch_simulation' failed due to earlier errors.

0 Kudos
1 Solution

Accepted Solutions
hbucher
Scholar
Scholar
10,142 Views
Registered: ‎03-22-2016

@centercitybill  I believe what @shameera says also applies to Windows. 

Vivado is heavily TCL based on both Linux and Windows. As that is a script tool, spaces do matter when you do variable substitution.

Make a test and move your project from "My Documents" to say the C: root, just for the sake of a try.

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.

View solution in original post

13 Replies
shameera
Moderator
Moderator
9,039 Views
Registered: ‎05-31-2017

Hi @centercitybill,

 

Can you please make sure that there is no white space in the directory path of the file which you are trying to open in TB.

Below is the thread about similar issue

https://forums.xilinx.com/t5/Simulation-and-Verification/Vivado-simulate-error-white-spaces-in-path/m-p/831527

 

Thanks & Regards,

A.Shameer

centercitybill
Adventurer
Adventurer
9,036 Views
Registered: ‎01-27-2016

I read this post, however it states that this is only a problem in Linux, not Windows. I am running Windows.

0 Kudos
hbucher
Scholar
Scholar
10,143 Views
Registered: ‎03-22-2016

@centercitybill  I believe what @shameera says also applies to Windows. 

Vivado is heavily TCL based on both Linux and Windows. As that is a script tool, spaces do matter when you do variable substitution.

Make a test and move your project from "My Documents" to say the C: root, just for the sake of a try.

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.

View solution in original post

centercitybill
Adventurer
Adventurer
9,026 Views
Registered: ‎01-27-2016

I moved all the files that are used by the test bench into the vivado design directory: C:/HDL/fir_dsp_double/, but I am getting the same error.

0 Kudos
hbucher
Scholar
Scholar
9,018 Views
Registered: ‎03-22-2016

@centercitybill Well it is not it then...

Can you post the error message now?

At least the path in the message should be different, no?

 

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
centercitybill
Adventurer
Adventurer
9,015 Views
Registered: ‎01-27-2016

@hbucher I am getting the same error message. I agree, it should reference a different path, but it is not. I reset the simulation and re-ran it. The error messages are below.

 

Time resolution is 1 ps
ERROR: [Simulator 45-7] No such file 'C:/Users/kirscwm1/Documents/My' in the design.

ERROR: [USF-XSim-62] 'simulate' step failed with errors. Please check the Tcl console or log files for more information.
ERROR: [Vivado 12-4473] Detected error while running simulation. Please correct the issue and retry this operation.
launch_simulation: Time (s): cpu = 00:00:01 ; elapsed = 00:00:39 . Memory (MB): peak = 940.910 ; gain = 0.000
ERROR: [Common 17-39] 'launch_simulation' failed due to earlier errors.

0 Kudos
shameera
Moderator
Moderator
9,014 Views
Registered: ‎05-31-2017

Hi @centercitybill,

 

From the attached TB I see that you are using the statement file_open(infile, "fir_dbl_dsp_stim.txt", READ_MODE); for opening the file.

By the way vivado searches the file in the current directory. You can use the command pwd to check the current directory.

 

Thanks & Regards,
A.Shameer

centercitybill
Adventurer
Adventurer
9,012 Views
Registered: ‎01-27-2016

Hi @shameera,

 

I have included the fir_dbl_dsp_stim.txt in my design so I assumed that vivado has the path to this file.

When I type the pwd command I get: C:/Users/kirscwm1/AppData/Roaming/Xilinx/Vivado

 

 

Bill

0 Kudos
centercitybill
Adventurer
Adventurer
8,972 Views
Registered: ‎01-27-2016

I created a new project and made the files local and now the error has gone away. I guess the old design directory was corrupted somehow. Thanks for your help.

 

 

Bill

hossam1984
Participant
Participant
4,777 Views
Registered: ‎02-26-2019

I had the same issue and I resolved it by deleting the files in simulation folder.

e.g:  vivado\yourproject.sim\sim_1\behav\xsim

By deleting its contents, I am able to run the simulation.

 

Regards,

Hossam

soujanya_sr
Newbie
Newbie
4,496 Views
Registered: ‎03-06-2020

Changing the module name worked for me.

0 Kudos
whelm
Explorer
Explorer
3,400 Views
Registered: ‎05-15-2014

I encountered a similar problem and narrowed it down.  In my case the one of my Verilog files had a space in the name, but I had been simulating the project numerous times without incident.  Suddenly I got this error that it couldn't find a file using the name only up to the space.  I was puzzled at why it broke when all I thought I had been doing was  some  minor edits.  I had not added any files.

I explored the relevant files with some help from other posts in this thread.  What I found was that Vivado had removed the space from just about all references to the file.  Apparently, it trims white space in names, and also trims white spaces in potential directory matches, because it worked just fine.

But there was one exception.  I had recently set a breakpoint in the sourcefile with a space in the name.  The breakpoint file <project>.sim/sim_1/behav/xsim/xsim.dir/<simfile>_behave/TempBreakPpointFile.txt

had the filename in it with the space included.  Apparently when parsing that file, it truncated the name at the space.  This would not be surprising, because nothing on the line is quoted, and it is a (tcl?) command with space delimited parameters.

By this time I had changed the filename to eliminate the space.  It was part of a project I had also been synthesizing, The block design didn't like the change.  I had to remove the file from the project (with its old name), change its name and then add the file back in.  At that point, updating sources in the block design allowed it to find the file with its new "clean" name and nothing was lost, not even connectivity in the block design.

The block design behavior was amazing and at the same time frustrating.  Amazing because it would find the renamed  file and associate the module in it with the block without breaking anything.  Frustrating in that it appears to be impossible to delete a block that is not supported by a file.  When the file ? box appears in the source tree, removing the file is not an option and opening the block design is not an option, either, so the block cannot be deleted from there.  I ran across this recently in another situation, and had to save my source files and then revert to backups from my repository and then overlay the newer source files.  This should be looked into.

But back to simulation.  Once the source file was renamed without spaces, and the TempBreakPointFile.txt was modified to reflect that name, the simulation ran fine.  Like the block design, the simulator found the renamed file with no problem, and as one would expect the corrected breakpoint was tagged as it should be.

Interestingly the simulator, though has some of the same weaknesses as the block design.  Not only would it refuse to run a simulation without being able to read the file referenced by the breakpoint (a note about unidentified breakpoint not being set would have been more robust), but until the problem was fixed, it was not possible to enter the simulator to even see what the files were (not that it mattered in this case).  It would come to the error and stop without doing any GUI stuff, yet trying again (even after fixing it) it would claim that the simulator was already running and ask if I wanted to relaunch it, even though to all indications from the GUI it was not.  Yet another bug or disconnect between the GUI and underlying code.  I sometimes wonder if the developers are CLI people who either do everything with TCL scripts or directly from the command line.  There are a number of these sorts of things that one would expect the developers to see and correct, assuming they actually used the GUI.

Anyway, for the next user who rings into this error condition, know that there is a rather simple fix that doesn't involve destroying half the project and starting over.  And if you, like me have been working on a project for days or weeks and suddenly encounter this for no apparent reason, it is probably because you just set a breakpoint in a source file that has a space in the name.  As pointed out by the staff posting in this thread, spaces are supposedly legal in the Windows environment, but obviously the breakpoint file is one place the developers missed.

 

PhilipWee
Visitor
Visitor
612 Views
Registered: ‎05-11-2021

The above reply worked for me, and provides a very good explanation of the error. Thank you very much, and if any Xilinx employees are around is it possible to fix this?

0 Kudos