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.
Related
I'm a little confused going about adding a new instruction to QEMU and want to confirm if my understanding is right. After going through the source code, I think adding an instruction to QEMU involves the following steps:
Define a helper function of the format CHERI_HELPER_IMPL(*instruction* in \target\target_arch\op_helper.c that emulates this instruction.
Define generate_*instruction* in \target\target_arch\translate.c that calls gen_helper_*instruction* which calls the helper function.
Am I missing any steps?
The fact that you mention a "CHERI_HELPER_IMPL" macro tells me that you're not working with upstream QEMU, but with the CHERI project's fork of it. So you should talk to them about anything special that might be needed there. As I understand it their local modifications may be quite significant.
For upstream QEMU, this depends on whether the target architecture is using decodetree or not.
For decodetree-based architectures:
add a suitable instruction pattern or patterns to the .decode file. This will result in the generation of code which calls a function whose name begins trans_ to handle instructions that match that pattern, passing it a pointer to a structure which contains the values of the various instruction fields defined by your pattern.
implement the trans_ functions appropriately. What you need to do depends on what the instruction behaviour is. For simple instructions, you can just emit TCG ops which do the actions the instruction must do. For more complicated work, you might want to emit TCG ops for "call a runtime helper function". The tcg/README file has some "recommended coding rules" at the bottom which include a rule of thumb for when to use a helper function.
if you decided to emit a helper call, you need to implement the helper function. The DEF_HELPER_* macros in helper.h both define the prototype for the C function you're going to write and also auto-generate a function gen_helper_whatever that your translate-time code can call to generate the TCG code to call it.
For non-decodetree-based architectures:
There will be hand-written code, usually starting in translate.c, which identifies instructions using switch statements and bit-masking code. You'll need to look at that code to find out where in that to add the code which identifies the instruction that you're adding. This is all completely target-specific; some targets use a somewhat table-driven setup or some preprocessor macros as part of this, some use completely hand-written code.
Once you've figured out where to add the "is this my instruction type?" check, the rest is similar to decodetree-based targets: you need to emit TCG ops to either do the work or to call a helper to do the work at runtime.
You'll find that there's a lot of specific detail that needs to be got right in each of these steps, but that's the basic outline.
I would like to automate some Terraform documentation and CI/CD checks related to input variables. Is there any way to do one or more of the following:
detect what input variables a specific module will take
detect what output variables a specific module can generate
detect the data type and description fields of the above (when applicable)
If not possible, I guess I will have to resort to regex parsing of all files in a module folder - but this seems like brute force, and far from ideal.
Any ideas?
I have had a good bit of success with the terraform-docs open-source tool. You essentially point it to your module and it generates fairly standard looking docs in the format you provide.
This tool can also output JSON if you'd like a raw tree of data to process yourself.
If you're looking for something a little more "low level" you could also look into the module that powers terraform-docs: terraform-config-inspect.
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.
Is it possible to make a fully compiled and standalone version of an RTL module, like a snapshot in Cadence terms, and then later instantiate this compiled module into a testbench?
Ultimately, running another compile step to create a final snapshot which contains the originally delivered snapshot but now instantiated in the testbench.
If so, are there any special considerations when compiling the original snapshot to enable this and how would you instantiate such a compiled object within a testbench?
Yes. But every simulation tool has slightly different approaches to the compilation flow. Most tools break this flow into a number steps: parsing, optimization, elaboration, and initialization (the snapshot you mention is the last step). Not all tools give you access to all the individual steps.
There are several ways to achieve what you ask for, but the choice really depends on why you want to do this, and what limitations you are willing to work with.
You can parse your module's source code into a library and then re-use that same library for compiling many different test benches. But usually the time consuming part is optimization.
Questa provides what you are looking for in what they call the Pre-compiled Design Unit (PDU) flow. You can optimize your RTL module and save it back into a library, and Questa simply choses the optimized module instead of the un-optimized module during elaboration. The special considerations are that you need to preserve any signals from optimization that might have hierarchical references from the testbench.
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.