Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Module 'xyz' does not have a timeunit/timeprecision specification in ...

Status
Not open for further replies.

tahirsengine

Member level 3
Member level 3
Joined
May 7, 2007
Messages
66
Helped
3
Reputation
6
Reaction score
3
Trophy points
1,288
Location
Germany
Activity points
1,929
So the original error in Modelsim is :

Module 'xyz' does not have a timeunit/timeprecision specification in effect, but other modules do.

The issue is: I have checked all the files in project, and no file contains 'timescale' directive.

But it is still complaining that other files have timeprecision. What may be the possible reason for this error?

Thanks
 

I am seeing what you have written and it includes none of your project files. So I find it difficult to answer your question.
What if you remove the file in question from Modelsim project, add it back and then try recompiling?

Generally in Verilog, it is a good practice to include this compiler directive in the RTL files.
 

Mods please delete this thread, posted the same on Intels website.
 

I am seeing what you have written and it includes none of your project files. So I find it difficult to answer your question.
What if you remove the file in question from Modelsim project, add it back and then try recompiling?

Generally in Verilog, it is a good practice to include this compiler directive in the RTL files.

Meanwhile mods see this thread, let me explain.

Its kind of a problem with software.

I wrote some files in Modelsim(in a project).
Then this project was taken to another computer. That guy added some more files into that.
Then I again copied that project and opened it on my computer. And then it started to complain. I checked all the files that he added, and doesn't contain any such thing as it is complaining.

The conclusion is, there must be some setting file or some other file that keeps the track of files added and their contents too. Because at the other computer there were timescale directive added to all files, and I manually removed from all the files here.
Before, these files were working perfectly fine in my computer.

So that's the mystery. :)
 

Mods please delete this thread, posted the same on Intels website.

Then don't cross post to multiple sites or on this site.

Cross posting is an inherently rude and selfish act that has no place on any forum, if you must cross post in the very first post you should always inform others where those cross posts are located so that users can either ignore your post (figuring the question will get answered on the other site) or so they don't repeat something someone already answered, wasting their time trying to help you.


If you run into this timescale issue again just add the -timescale #ns/#ps or whatever you want for the timeunit/timeprecision to the vsim or xvsim or whatever simulator you are using. Doing this will force a default and you won't have to add the directive in all the files.

I run into this issue all the time due to vendor cores having a `timescale in all their (synthesizable) files. Sometimes this is because all the files have #delays on all the assignments. I suspect many vendors use inexperienced people (new grads) to generate their simulation library models, which is a huge mistake. Ran across this issue with a Xilinx DDR model that didn't work correctly unless you put #delays in your RTL to fix the model's race condition problems. The previous model was written by someone who must have written ASIC models before. The "new" improved model was garbage with #1 delays all over the place on the clock input to detect clock edges and on the data to try and compensate for the introduced clock delays. What really surprised me was I complained to the FAE and they told the factory which kept that model for many base version numbers of the tools before it was finally rewritten by someone who obviously knows how to write a simulation model.
 

The conclusion is, there must be some setting file or some other file that keeps the track of files added and their contents too. Because at the other computer there were timescale directive added to all files, and I manually removed from all the files here.
Before, these files were working perfectly fine in my computer.

1. Get a repo, SVN, Git -- best solution!
2. Get a filelist or .f file (tracking of files possible but not their contents). More details here - https://stackoverflow.com/questions/25439170/what-is-the-list-file-f-for-verilog
 

Then don't cross post to multiple sites or on this site.

Cross posting is an inherently rude and selfish act that has no place on any forum, if you must cross post in the very first post you should always inform others where those cross posts are located so that users can either ignore your post (figuring the question will get answered on the other site) or so they don't repeat something someone already answered, wasting their time trying to help you.


If you run into this timescale issue again just add the -timescale #ns/#ps or whatever you want for the timeunit/timeprecision to the vsim or xvsim or whatever simulator you are using. Doing this will force a default and you won't have to add the directive in all the files.

I run into this issue all the time due to vendor cores having a `timescale in all their (synthesizable) files. Sometimes this is because all the files have #delays on all the assignments. I suspect many vendors use inexperienced people (new grads) to generate their simulation library models, which is a huge mistake. Ran across this issue with a Xilinx DDR model that didn't work correctly unless you put #delays in your RTL to fix the model's race condition problems. The previous model was written by someone who must have written ASIC models before. The "new" improved model was garbage with #1 delays all over the place on the clock input to detect clock edges and on the data to try and compensate for the introduced clock delays. What really surprised me was I complained to the FAE and they told the factory which kept that model for many base version numbers of the tools before it was finally rewritten by someone who obviously knows how to write a simulation model.

Spot on.
But the model I am using is from a world renowned company (and yes shit happens :) ).

The problem is somewhat solved. Followed your and @dpauls instructions. Put timescale in all files. Working now.

But why it happened in first place, is still unknown.
 

But the model I am using is from a world renowned company (and yes shit happens :) ).
So what their management still hires new grads to "work" on F-ing up their models thinking they are "saving" money...(short memory problem or management turnover)

The problem is somewhat solved. Followed your and @dpauls instructions. Put timescale in all files. Working now.
Why did you edit all your source files...
Just make your vlog command line:
vlog -timescale 1ns/1ps my_source_with_no_timescale.v if you do that all your files will have a timescale and vsim won't complain. This also works when using Vivado's simulator (though I think you have to use -t 1ns/1ps).

- - - Updated - - -

I noticed I specified that you put the timescale on the vsim command line in the previous post, it was supposed to be on the vlog or xvlog command line.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top