Menu
▾
▴
#299 $clog2 is not supported
This function was added in 1364-2005 to make it easy to determine the size of counters, etc. This is typically uses in place of constant functions. Covered should be able to use this mathematical function while evaluating parameters/localparams that are then used to size counters. It is fairly trivial to code around this by replacing the value with a fixed constant, but that looses the scalability of the design.
If you need an example let me know and I can whip something up. I think all that is need is is the ability to actually evaluate the function when processing the r-value of a parameter/localparam. Icarus has the constant version of this in eval_tree.cc if you are interested.
Sounds reasonable. I'll put together a patch for you to try.
I have attached a patch that provides $clog2 functionality. This feature will be available in the 0.7.8 stable release of Covered.
Adds $clog2 functionality
I don't think you meant to include the Makefile.in or genprof.{c,h} changes, they do not apply correctly to what I have! To make it worse this doesn't appear to be working!
Covered says it is removing the logic block containing the unsupported system function!
I have a line like the following:
localparam cntr_wid = $clog2((d_wid+1)*8);
d_wid is a parameter passed into the module. d_wid is set to 3 so I expect cntr_wid to be set to 5.
It then goes on to crash at the place I previously reported.
Cary,
Usually I don't provide patches for new features because of these issues with applying the patch. You can update the genprof.h/c files by running the "./genprof.pl" script in the src directory.
I have another patch that fixes the segfault issue with the localparam usage of $clog2.
Thanks,
Trevor
Second patch to complete the $clog2 support
We still are not quite there with $clog2. I'm attaching an example that shows a couple examples that are getting the unsupported system function warning.
Note that there are two places that $clog2 is used and one of those (inside the #())should not be run if the second dut call is used. This runs exactly like my previous examples.
If I use a constant value for the localparam I can get covered to run, so the crash is fixed. When I try to merge in other databases that have the full testing on the sub blocks the report command is failing. I need to figure out if this is something I'm doing wrong and if not how to reproduce it in a small example.
Example $clog2 usage that fails
Cary,
I'm not seeing any warnings/failures with the attached example. The results look about right to me (the widths of the signals are accurate). Am I missing something here?
Thanks,
Trevor
It appears I'm the one missing something. When I try to run this I get a warning for both line 41 and 46. Is there some place where I can get covered from cvs or git so I can have the exact same version as you? As you can guess I don't mind running a development version as long as it works correctly. I currently have straight V0.7.7 and the following patches:
bug2926579
bug2927285 (both)
bug2929935 (both)
bug 2929948
I was just tempted to run gitk to double check what was added, but that won't work for this project!
You should be able to get anonymous CVS access (instructions available on SourceForge). To get the correct branch, do:
cvs co -r stable-0_7-branch covered
Using the code from CVS fixed the $clog2 issue. I still have the crash when trying to report on the merged data bases, os that one is still valid. Thanks for your help! I'll mark this pending.
Ack, I spoke too soon. I had forgotten that I had redefined the localparam to be a constant. Both the bug example I submitted and my production code create a warning about the $clog2 function and remove the logic block that contains it. covered reports that it is version 0.7.8. Both the bug report and production code crash after the warning in param_expr_eval (param.c:790). I suppose that is some what expected if it has thrown out the $clog2 function.
Back to open it goes.
Again, the bug example that you have provided does not emit any warnings nor crash for me. I'm not sure how to proceed from here.
Well this is either a machine/OS difference (unlikely) or a code difference (likely). Can you in a new directory check out V0.7 from anonymous CVS, build it and then verify that you still don't have a problem. I'm guessing this should fail fro you as well and somehow your build/working directory is out of sync with CVS and that is what's creating the problem. I don't know how you deal with the different branches so maybe your real development branch has everything correct, but in copying it to V0.7 something got dropped. I like you don't know exactly what to do this is a very odd problem, but I'm guessing we're smart enough to figure it out!
Well, I've done my own checkout of the stable-0_7-branch (clean environment) and ran the provided example. Again, no warnings, no segfaults. Here are the command-line options I'm using...
covered score -t top -v bug.v -vcd bug.lx2 -cdd bug.cdd
And I'm running this as:
covered score -t example -i top.dut -g 2 -v bug.v -lxt bug.lx2 -o bug.cdd
and this does crash. It appears that the issue is you put $clog2() only in the -g3 (SystemVerilog) generation since you do not have a 2005 generation. I can live with this as long as there are no issues with me telling covered my 1364-2005 Verilog code is really SystemVerilog.
Please let me know if this is the case or not. I would expect this to work, but I don't know enough about SV to know for sure. It appears that it does work.
It would be nice if the generations were more explicit 1364-1995, 1364-2001, 1364-2005, 1800-2005 and 1800-2009. We went to that in Icarus because of the confusion, though for something like this we let the older generations also have the system function since it doesn't break anything.
The next covered show stopper for me is the report crash on the merged cdd files.
Thanks for your patience and help!
One SV difference is that byte is a reserved word. After some minor editing I think everything I have is running using the -g3 (SystemVerilog) setting.
I'm going to fix the issue of a C assertion being raised in this case. It would be better to change the warnings to errors in this case and have Covered exit gracefully. I'll attach that fix as another patch to this bug.
I would certainly be willing to break out the -g options to have better granularity. The problem is that I do not have all of the LRMs for each version to know what belongs where.
That sounds prudent. A sorry $clog2() is not supported in this generation would have allowed us to figure this out much quicker. To me getting all the keywords right is the most important thing for the various generations and all of that is in the back of the LRM. If you need help figuring this all out please let me know.
Attached third patch which generates an error message when an unsupported construct is found in the RHS of a parameter assignment.
Third patch to generate error message instead of segfaulting
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).