I have got a piece of verilog code, which i am trying to synthesize. There is a line in there,
MUX2B_XB gas34 ( notPropSig, OECin, generate, notCoutSig );
instantiating a module. Where, the module implements a simple Boolean logic. But, synthesizer was giving an error:
Syntax error near "generate".
I can not understand the use of 'generate' statement in this context here while instantiation and also how to go about resolving the error without affecting the intended functionality.
You seem to be trying to use generate as a variable name and connect that variable to the 3rd port of your module. However, generate is a Verilog keyword and cannot be used as a variable name (another example would be trying to use always as a variable like logic [1:0] always;, you cannot use such keywords as variable names). You simply need to change the name of that variable:
logic gen; // Or whatever the type and width of this line should be
...
MUX2B_XB gas34(notPropSig, OECin, gen, notCoutSig);
If you actually what to use the generate construct for something, you'll need to provide more context so we can help.
Related
Is their a possibility to access a node in the code using a define macro via string parameters
e.g.
module design
(
input logic signal_in_1_temp,
input logic signal_in_2_temp
);
endmodule
module tb_top;
parameter string signal_names[0:1] = {"in_1","in_2"};
i_design design(.signal_in_1_temp(0),.signal_in_2_temp(0));
`define IN_SIG(IN_NAME,VAL)\
force i_design.signal_\``IN_NAME\``_temp = VAL;
initial begin
\`IN_SIG(signal_name[0],1);
\`IN_SIG(signal_name[1],0);
end
endmodule
In the above the two inputs of the design would need to be accessed via a parameter list and then a macro ...
Compiling the above gives error .... I would want to know if we can access the nodes status or drive them based on the above means ..
The idea is to have a dynamic parameter list given and then to know the status of that list or drive them based on need....
Any suggestions ... please
No, you cannot use string names within the language to build identifier names. Verilog does have a C interface (called VPI) that allows you to access signals by signal name, but that comes at a performance cost which means the signal cannot have certain optimizations and must remain intact.
SystemVerilog has a bind construct that allows you to attach functionality to signals deep inside your design. I wrote a DVCon paper about it.
No, you cannot do it with strings, but you can do it with regular macro arguments.
here is a working example:
`define A(B) \
$display(sig_``B``_sig);
module top;
logic sig_x_sig, sig_hello_sig;
initial begin
`A(x)
`A(hello)
end
endmodule
do not use \ as in your code and do not use empty lines in macro definitions.
I'm not that familiar in Verilog but can you call another module when it's inside a case statement?
You cannot call a module just as you do in C language, since it's not a function, you instantiate it.
If you want to instantiate a module, you should use generate.
Edit: An example of using generate with a case statement can be found here.
2nd edit: If you just wanted to call a section of code in a case-statement then you can create a task or a function. More information here. (credit goes to Hida)
you can not call module within case statement , but you can create function and then call in case statement (task is not synthesizeble)
My program, PKGDAYMONR has the control option:
ctl-opt Main( CheckDailyPackages )
The CheckDailyPackages procedure has the following PI:
dcl-pi *n ExtPgm( 'PGMNAME' );
As you can see the ExtPgm parameter is not the name of the program. In fact, it’s what came over in the template source and I forgot to change it. Despite the wrong name in ExtPgm, the program runs without a problem.
If I remove that parameter and leave the keyword as just ExtPgm, I get the following message:
RNF3573: A parameter is required for the EXTPGM keyword when the
procedure name is longer than 10.
If I drop ExtPgm from the Procedure Interface altogether, it also complains:
RNF3834: EXTPGM must be specified on the prototype for the MAIN()
procedure.
So why is it that I have to specify a parameter if it doesn't matter what value I enter?
O/S level: IBM i 7.2
Probably worth pursuing as a defect with the service provider; presumably for most, that would be IBM rather than a third-party, as they would have to contact IBM anyhow, given the perceived issue is clearly with their compiler. Beyond that, as my "Answer", I offer some thoughts:
IMO, and in apparent agreement with the OP, naming the ExtPgm seems pointless in the given scenario. I think the compiler is confused while trying to enforce some requirements in validations of the implicitly generated Prototype for the linear-main for which only a Procedure Interface is supplied; i.e. enforcing requirements that are appropriate for an explicit Prototype, but requirements that could be overlooked [thus are no longer requirements] in the given scenario.? I am suggesting that while the RNF3573 would seem appropriate for diagnosing EXTPGM specifications of an explicit Prototype, IMO that same effect is inappropriate [i.e. the validation should not be performed] for an implicit prototype that was generated by the compiler.
FWiW: Was the fixed-format equivalent of that free-form code tested, to see if the same or a different error was the effect? The following source code currently includes the EXTPGM specification with 'PGMNAME' as the argument [i.e. supplying any bogus value of 10-byte naming to supplicate the compiler, just as is being done in the scenario of the OP, solely to effect a successful compile], but could be compiled with the other variations with changes to the source, mimicking what was done with free-form variations, to test if the same\consistent validations and errors are the effect:
- just EXTPGM keyword coded (w/out argument); is RNF3573 the effect?
- the EXTPGM keyword could be omitted; is RNF3834 the effect?
- the D-spec removed entirely (if there are no parameters defined); ¿that was not one of the variations noted in the OP as being tried, so... the effect?
H MAIN(CheckDailyPackages)
*--------------------------------------------------
* Program name: CheckDailyPackages (PGMNAME)
*--------------------------------------------------
P CheckDailyPackages...
P B
D PI EXTPGM('PGMNAME')
/free
// Work is done here
/end-free
P CheckDailyPackages...
P E
I got a response from IBM and essentially Biswa was on to something, it simply wasn't clear (in my opinion) about the answer.
Essentially the EXTPGM is required on long Main procedure names in order to support recursive program calls.
This is the response I received from IBM explaining the reason for the scenario:
The incorrect EXTPGM would only matter if there was a call to the main
procedure (the program) within the module.
When the compiler processes the procedure interface, it doesn't know
whether there might be a call that appears later in the module.
EXTPGM keyword is used to define the external name of the program which you want to prototype. If you mention the EXTPGM then the program will be called dynamically.
Let us take an example in order to explain your query.
PGMA
D cmdExc PR ExtPgm('QSYS/QCMDEXC')
D 200A const
D 15P05 const
c callp cmdExc('CLRPFM LIB1/PF1':200)
C Eval *INLR = *ON
In the above example CmdExc used for the dynamic call to QSYS/QCMDEXC.
When we use the same program name as the EXTPGM parameter it acts as an entry point to the program when called from other programs or procedure.
But in any case when we mention any name as the sample parameter the EXTPGM will not give any error in compilation, but it gives the error during run time as it tries to resolve the name during run time.
I'm trying to compile following code in Modelsim:
module ctrl_mem
#(
parameter BYTE_SIZE = 256
)
(
input [ADDR_W - 1 : 0] i_addr,
...
...
);
localparam ADDR_W = $clog2(BYTE_SIZE);
Modelsim writes that ADDR_W is unknown.
Similar question was discussed here but Modelsim behavior is not covered there and unfortunately I cannot comment it to ask this question.
Is it possible to fix this issue without code modification?
I use Modelsim Altera Starter Edition 10.3c
Your code is not legal. The Verilog/SystemVerilog LRM requires that simple identifiers (those not followed by a '.' or '(') be declared prior to being referenced. The correct way to write this module is
module ctrl_mem
#(
parameter BYTE_SIZE = 256, localparam ADDR_W = $clog2(BYTE_SIZE)
)
(
input [ADDR_W - 1 : 0] i_addr,
...
...
);
As you discovered, the newer style parameter declaration ("module_parameter_port_list" in the LRM syntax definition) only supports parameters and not localparams, and as has been mentioned it needs to be declared before it's used, so this leaves you with the option of either using the old-style syntax, or using parameter.
Whenever I have an I/O width dependent on a constant derived from another parameter that I want to be able to override, I always used parameter for this reason. They way I think of it, a case like this is not necessarily a good candidate for 'localparam', as it's not truly/completely "local" -- you are using it to specify the width of an interface signal thus exposed outside the module. At least that's how I explain the situation to myself.
Verilog system function $value$plusargs invoked as task.Return value
will be ignored
I get the above error during a compile of my verilog test which is basically trying to read and write values over i2c. I wasn't getting this error earlier.I don't know what changed which is giving me this error.Also this error points to another file called tb.v which contains the testbench infrastructure. The line it points to in tb.v just says `ifdef TEST
That error message means you are calling a function which returns a value without doing anything with the return value. As Brian noted, $value$plusargs returns a value, so you need to either assign it to something, or in SystemVerilog you can ignore it with use of void'(..).
// For Verilog
reg result;
result = $value$plusargs(...);
-
// For SystemVerilog
void'($value$plusargs(...));
You may also care to know if the plusarg matched or not. In that case, it's best coded in this way:
if ($value$plusargs(...)) begin
// do something
end
One explanation as to why you started seeing this all of a sudden, would be if you changed something so the source is being compiled as SystemVerilog instead of Verilog. It's tool dependent, but a given compiler may complain about this in SystemVerilog but not in Verilog.
$value$pluargs is a function which returns a value. This value is whether or not the call succeeded or not. Not the value of the +arg you're attempting to get. I've seen some simulators get upset if you don't assign the result to something.
Basically this will fix it:
reg dummy;
dummy = $value$plusargs(...)