Is there any way to setting timescale in command line

[jimmysitu]

Hi, All

I found a command file is needed if you want setting a timescale with iverilog.

+timescale+1ns/10ps

I wonder if there is a easier way to set timescale in iveirlog, something like

iverilog -timescale=1ns/10ps` myverilog.v

Thanks

[steveicarus]

It is normal to use the timescale syntax within the Verilog language (the `timescale directive, or the SystemVerilog timescale keyword) and there is, as you noted, the command file option. There is no command line flag.

On Mon, Apr 30, 2018 at 3:12 AM, Jimmy Situ notifications@github.com wrote:

Hi, All

I found a command file is needed if you want setting a timescale with iverilog. +timescale+1ns/10ps I wonder if there is a easier way to set timescale in iveirlog, something like iverilog -timescale=1ns/10ps

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/steveicarus/iverilog/issues/189, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAlMiVwlZ7jqNr2D18WzFICUDM3m3Qzks5ttuOggaJpZM4TsX9F .

-- Steve Williams "The woods are lovely, dark and deep. steve@icarus.com steveicarus@gmail.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."

[svenka3]

I was looking for the same command line control today, will be good to have

[caryr]

@svenka3 Can you provide a more detailed description of your usage that is requiring this? So far I have not found a good reason for this and in my own personal experience have found the option to forcibly override the timescale to be dangerous and disruptive. This is one place where following the commercial tools may not be a good choice because what they have is a far as I can tell because of users who do not understand how this all should be used. I agree `timescale can be a complete mess, but the new SystemVerilog keywords appear to be enough for everything I have done. I can make some guesses regarding why you want this, but would like facts and not assumptions.

[svenka3]

@caryr Below are my notes on this topic.

There are 2 different options/features:

1. Providing timescale via the command line (For those modules/scopes that lack `timescale in code)
2. Overriding timescale - dangerous but useful at times (rare I would agree, but still used in large chip DV projects)

Req number 1 above is made almost mandatory due to some strange rule I have seen in other tools:

  Error! Module (...) has a `timescale directive but previous modules do not

Ref: https://www.xilinx.com/support/answers/2224.html

So this is what makes me look for a command-line -timescale (and almost all tools provide this feature).

The Req number 2 above - for overriding, I would say let's leave that till there is a strong pull from other users, I don't need that as of now.

HTH

[caryr]

I work on some of the largest SOCs on the planet and every case of option 2 I have seen is because someone is hacking around something someone did wrong and they do not want to take the time to fix it correctly in the moment. This then causes unexplained issues when the root issue is not resolved correctly and some other module that is correctly using delays unexpectedly breaks because of this forced override when it is integrated (e.g. a delay gets rounded to zero). The problem is this override gets enshrined in mythos over time and often no one, including the person who originally added the override, fully understands the subtlety of the issue. In my opinion this type of thing should only be done when clear documentation about the issue and what steps are being taken to resolve it and who is responsible are provided. That cannot be easily done with a command line flag. In a control file that supports comments you have a little more of a chance, but enforcing good comments is not possible. The only way to avoid all this chaos is to forbid this dangerous behavior and require the original issue to be resolved when discovered instead of being delayed until we have time to fix it. Which as we all know doesn't usually happen.

For option 1 I believe what could be provided safely is the ability to set the simulator default time unit and precision, but this is just the default and does not count as an explicit timescale definition so the timescale warning we provide will still identify places where timescales are used inconsistently. This should match what is provided in the command file exactly.

Is this simple override of the default time unit and precision enough for what you want?

Note the Icarus warning is intelligent and does not report modules that do not actually use delays. Many tools just report modules that have an inconsistency no matter if it makes a difference or not. I am also assuming the only reason the other tools are begin mentioned is because you would like to be able to make sure the default that the various tools use match explicitly and would prefer a command line flag versus the command file option we already provide. If this is really because it's just part of what you do see my mythos comment above.

[svenka3]

Thanks for your detailed comments. I still see 2 separate features - simple timescale specification for missing modules (like default), then the override_timescale - I am not in favor of override_timescale feature.

As a side question - are you saying the command-file +timescale in Icarus is an override? That would be scary for me to use.

[caryr]

The manual page is clear on the command file functionality:

+timescale+value
        The +timescale+ token is used to set the default timescale  for
        the simulation. This is the time units and precision before any
        `timescale  directive  or  after  a  `resetall  directive.  The
        default is 1s/1s.

I would only support a command line flag that supported this exact behaviour. Of course doing that brings up the question of precedence and I assume it would be the command line flag has precedence over the command file which has precedence over the executable default.

[caryr]

I will also point out that code that uses anything other than clock/event based delays (@, wait) and non-blocking delays with no delay value should be tagged to be updated to use the SV timeunit/timeprecision statements instead of relying on a timescale directive or even worse a simulator default.

[svenka3]

I agree with your proposal, please add as and when possible.

Thanks

[caryr]

The first request for this dates back to an early SourceForge request (2006). As I remember what needs to get taken care of first is updating the command line parsing to support getopt_long() with an appropriate configure check for base functionality and then we can use --timescale= to implement this. Adding long options opens up a number of other enhancements so it is good for other things and something that should get done. I think we used to have a custom version of the getopt() library that was used if it was not available as a standard library element, but I'm not certain that is still the case. I'll look into getting this taken care of.

[steveicarus]

Given the discussion above, I'm inclined to accept that setting a different default timescale really does need to be something that goes in the command file, and not on the command line. If you are hacking around code that doesn't properly set timescales (and you care) then putting it in a command file seems like the right solution. So I'm closing this ticket.

If you disagree, reopen it and write an argument that convinces me otherwise.

[pberuto]

Hello, reading this discussion, I would suggest a reason to have a -timescale=<> option on the command line as well. I fully agree that we only want to change the default timescale, not overriding (just as the +timescale+ directive in the command file).

The reason is compatibility with other tools. Many of us use tools and scripts that provide a way to compile the very same design in a tool-independent manner. I would love to integrate icarus into such a tool too. Creating a command file "on the fly" is a workaround but creates nasty races and unneeded complexity. It would be so much easier if we could specify the default timescale just via command line as for mentor, vcs and xrun.

Just my two cents! Thanks.