From: Cary R. <cy...@ya...> - 2021-02-14 09:59:16
|
Hi Evan, I believe all the odd command line behavior you are experiencing is related to the getopt() in windows and likely has nothing to do with Icarus. I have no idea why it is providing different results. Maybe it is an older version. Regarding the timescale. For the cases I tried this worked as expected and the messages were correctly suppressed. Can you provide more details so we can figure this out. Cary On Sunday, January 31, 2021, 5:42:59 PM PST, Cary R. <cy...@ya...> wrote: Hi Evan, I believe all the odd command line behavior you are experiencing is related to the getopt() in windows and likely has nothing to do with Icarus. I have no idea why it is providing different results. Maybe it is an older version. Regarding the timescale. For the cases I tried this worked as expected and the messages were correctly suppressed. Can you provide more details so we can figure this out. Cary On Thursday, January 28, 2021, 1:26:28 PM PST, Cary R. via Iverilog-devel <ive...@li...> wrote: FYI The no-<warning> options were added because most of the warnings are added with -Wall. It's odd regarding the space issue. I'll have to take a look. I'll look at this later and see if things match my expectation. For example: I believe having modules with the default timescale and some with a user defined timescale is potentially a huge error, where inheriting a timescale from a previous file is possibly intended (your example), but could be risky if you do not know what you are doing. --timescale is one of our oldest enhancement requests. On the surface it is straight forward, but there is subtlety that is easy to miss. I will also point out some of the commercial tool overrides are broken and dangerous and we will not be implementing things that way! I'll also point out moving the definition of time away from the module always has risk regarding what the writer of the module assumed versus what they actually have. Now for delays just to show sequence I understand those may want to track a global/TB definition, but for anything using the delay to model specific behavior you run a risk of creating broken simulations. For these I always use the new SystemVerilog constructs to define the time unit/precision inside the module and leave the global timescale for this TB/sequence use. Cary On Thursday, January 28, 2021, 12:30:26 PM PST, Evan Lavelle <sa2...@cy...> wrote: On 28/01/2021 18:54, Cary R. via Iverilog-devel wrote: > For your case where you know what you are doing and > it has been thought out I would just disable the warning. > An excellent idea, but... The wiki says warnings should be prefixed with 'no-' to disable them. After some experimentation it turns out that you need to put a space after the 'W', and the 'no-' before the 'timescale' (ie. '-W no-timescale'). This works for the case I described, but then the case I described only generates a warning if you compile with '-Wtimescale' anyway, so this just restores the default behaviour. If you have a more serious case in which some earlier modules have no explicit timescale, and a later one does, '-W no-timescale' *doesn't* turn off the warning. You could argue that, in this case, the user should get a warning and shouldn't be able to turn it off. So maybe it's not a problem, and just needs some documentation that this warning can't in general be disabled. Actually, a good option might be to implement a '-timescale' command-line option for a default timescale (I think everyone else does this), and then just remove the warning completely. _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel _______________________________________________ Iverilog-devel mailing list Ive...@li... https://lists.sourceforge.net/lists/listinfo/iverilog-devel |