I am getting a warning that says [Synth 8-3332] Sequential element (\i_data_1_vect_1_reg[31] ) is unused and will be removed from module cg_top in vivado. But the simulation is working fine. I would be great if someone shares why these warnings occur even though I am using these registers and how to solve it.
There are two possibilities:
The register is not needed and hence can be removed. The most common reasons for that are:
The output is not used.
The output always has the same value and can be replaced with a constant 1 or 0.
There is another (often adjacent) register which always has the same value and thus the output of that one is replicated.
Unfortunately there are some rare cases where Vivado reports removal, but actually nothing is removed. The only way to find out for certain is to open the synthesised design and check the schematic (visually, which may take you a long time) if the register has indeed been removed.
As I said these are rare cases. if your are inexperienced with HDL my money is that the register really is not needed.
Whatever the message, I have always found that the actual generated logic was correct.
Related
Trying to model a 74245 with delays representative of the HCT device.
I am finding that the timings I'm providing in a specify block are not respected.
I have added an extra route A->C (not part of my orig design) to illustrate that the delays can work, just not where there are conditionals in the expression ie none of the other delays are effective.
If I put a delay inline on the assign then this is always respected.
My code is here : https://www.edaplayground.com/x/hDa
Any ideas?
I am a noob.
It was an icarus bug and it's just been fixed on master.
https://github.com/steveicarus/iverilog/issues/315#issuecomment-607800126
Thanks all
I know that that when you make multiple instances of a module, separate hardware is created for each instance. But what about functions. What exactly happens when I call the same function from different parts of a code?
Synthesizable verilog functions will be inferred to a combinational circuit usually as a series of multiplexers.
Basically, the function will be 'inlined' each time it is called. What happens afterwards is up to the synthesis software. It is possible that some of these instances will be redundant and will be removed. It is possible that some that are not entirely redundant can be combined by inserting multiplexers. Logic path length, complexity, timing requirements, etc. will all affect the result.
This sort of optimization can take place across modules. Synthesizers can be very good about removing or even duplicating logic as necessary to reduce the overall size and to meet timing constraints.
Is it syntax correct with gate level Verilog file, where the the sub-modules are defined after the owning module or they should be defined before? Does it matter according to Verilog rules?
Regards,
This might be compiler dependent, but if you are using a tool that supports SystemVerilog (which most commercial tools do these days), it should be syntactically correct to define modules in any order, perhaps even in separate files.
See IEEE Std 1800-2012, Section 3.12 for more info.
Notice that after compilation, there is another step which is called elaboration. At that point all the module description should have been compiled correctly. From SystemVerilog LRM:
Compilation is the process of reading in SystemVerilog source code, decrypting encrypted code, and analyzing the source code for syntax
and semantic errors. Implementations may execute compilation in one or
more passes. Implementations may save compiled results in a
proprietary intermediate format, or may pass the compiled results
directly to an elaboration phase. Not all syntax and semantics can be
checked during the compilation process. Some checking can only be done
during or at the completion of elaboration.
SystemVerilog supports both single file and multiple file compilation
through the use of compilation units (see 3.12.1).
Elaboration is the
process of binding together the components that make up a design.
These components can include module instances, program instances,
interface instances, checker instances, primitive instances, and the
top level of the design hierarchy. Elaboration occurs after parsing
the source code and before simulation; and it involves expanding
instantiations, computing parameter values, resolving hierarchical
names, establishing net connectivity and in general preparing the
design for simulation.
The short answer is that you can forward-reference modules in Verilog; this has always been the case, and is not tool-dependent (in other words, you can do it in either order). There may be complications if you use libraries and configurations but, in general, you can assume that you can instantiate a module before it is defined.
In most of Verilog, you have to declare something before you reference it. There are some exceptions, including task and function calls, implicit wires, cross-module/hierarchical references, and module names. In these cases, the tool waits until elaboration to find the referenced object. There is no clear explanantion of much of this in the LRM, unfortunately. This is how Verilog-XL did it, and everyone else has done it ever since.
Note that this isn't related to 'gate-level' files.
According to the rules defined in the Verilog LRM, modules, functions and tasks are the only things that may be referenced before being declared. SystemVerilog adds interfaces and programs to that list. Verilog also has implicitly declared nets that makes it seem that you are referencing a net before it being declared, but I strongly suggest not using that feature by using the compile directive ``default_nettype none.
I need a way to find out if there are generate blocks with no instance name anywhere in a set of verilog files. I was wondering if I can compile with vcs and see warnings that indicate that there are some blocks like that. an example of a "bad" block is:
generate
for (i=0;i<N;i=i+1) begin
….
end
endgenerate
Thanks,
As far as I know, this is outside the scope of what vcs in intended for. The easier solution would be to synthesize and grep for the default name generate block instance.
You could also write a script the scans the RTL and check every for and if-else in a generate block has a begin : [name].
If checking the RTL from the simulator is what is really needed, then you will need to write a custom VPI callback with cbEndOfCompile. In the callback, find and scan through all the generated statements, then check check the naming.
In (regular) software I have worked at companies where the gcc option -Wall is used to show all warnings. Then they need to be dealt with. With non-trivial FPGA/ASIC design in Verilog or VHDL there are often many many warnings. Should I worry about all of them? Do you have any specific techniques to suggest? My flow is mainly for FPGAs (Altera and Xilinx in particular), but I assume the same rules would apply to ASIC design, possibly more so due to the inability to change the design after it is built.
Update 4/29/2010: I was originally thinking of synthesis and P&R (Place & Route) warnings, but the simulation warnings are valid too.
Here is my perspective from the ASIC world (99% Verilog, 1% VHDL).
We make an effort to eliminate all warnings from our log files, because in general, we interpret warnings as the tool telling us that we should not expect predictable results.
Since there are many types of tools which can generate warnings (simulation/debugger/linter/synthesis/equivalence-checking, etc.), I will focus this discussion on simulator compiler warnings.
We analyze warnings and categorize them into two main groups: ones which we deem will not affect the results of our simulation, and others which may affect the results. First, we use a tool's options to explicitly enable as many warnings as possible. For the first group, we then use a tool's options to selectively disable those warning messages. For the second group, we fix the Verilog source code to eliminate the warnings, then we promote the warnings to errors. If any warnings are later introduced in those categories, we force ourselves to fix them before we are allowed to simulate.
An exception to the above methodology is for third-party IP, whose Verilog code we are not allowed to modify.
That method works fairly well for RTL simulations, but it gets much more difficult when we run gate simulations using back-annotated SDF. There is simply not enough time to analyze and eliminate the literally millions of warnings. The best we can do is to use scripts (Perl) to parse the log files and categorize the warnings.
In summary, we try our best to eliminate the warnings, but it is not always practical to do so.
Here's what I do, for reference. I inspect all the log files from the tool(s).
For Altera Quartus II that includes the map, fit and merge reports. I also turn on the Design Rule Check (DRC) option and check that file. For some messages that are easy to fix, e.g. port missing from the instantiation or incorrect constant width, I fix them. Other ones I look into. For ones that are in the cores, e.g. a width mismatch because I'm not using the full output deliberate, I mark them to be suppressed in the .srf file. I only suppress the specific messages, not all of the "similar messages" since there may be others, either now or in the future, which are problems.
I wrote a script which applies a set of regexps to the logfile to throw away lines which I "know are OK". It helps, but you have to be a bit careful with the regexps - what did jwz say about them :)
The most important reason that I can think of is simulation-synthesis mismatch. Synthesis tools do a lot of optimizations (as they rightly should) and if you leave loopholes in your design you are asking for trouble. Refer to IEEE 1364.1-2002 for details about the synthesis standard.
There is no need to remove all warnings, but all should be reviewed. To make this possible for big designs, some warnings can be suppressed by its type or id.
For example, some synthesis tools give a warning if a Verilog parameter is defined and no value assigned during the module instantiation. For me, this warning is just an advice to use localparam. It's a good idea to suppress it by its id (e.g. LINT-01).
In some cases, I want to see the warnings and don't suppress them. For example, my tool gives a warning whenever I define a virtual clock by constraints. The warning doesn't mean there is a problem, but I can catch a missing source of a clock that wasn't intended to be virtual.
Sometimes non-existence of warnings points out a problem. For example, if I change an application variable, there should be a warning.
There are too many cases. Sometimes the warning is unavoidable. Sometimes it's nice to have warnings to be able to review some critical stuff. If the designer knows what he/she does, there is no problem.
Some warnings are expected and there is a problem if you don't get a warning.
for example if you really really want a latch but there is no warning about inferring a latch then your synthesis might not have made what you intended.
so no, you don't always want to 'deal' with all warnings.