Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-Wno-lint disables LITENDIAN and allows silent generation of code inconsistent with other simulators #1631

Closed
veripoolbot opened this issue Dec 9, 2019 · 13 comments
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Julien Margetts
Original Redmine Issue: 1631 from https://www.veripool.org

Original Assignee: Julien Margetts


The manual states "Ranges must be big-bit-endian" so I think LITENDIAN should not be a member of lintError() and should be a more serious error, amybe adding it to the dangerous() set?

The attached testcase (complicated by also containing a little-endian array of instances - may not be necessary but its how I discovered it) highlights the mismatch between Verilator and in this case VCS

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-09T13:55:54Z


Changing only the declaration of inc from an N-bit LE vector, to a an N element LE array, makes the output match, and avoids the LITENDIAN warning

-wire [0:N-1] inc;
+wire inc[0:N-1];

VCS and Verilator also differ if the ONLY change made it to reverse the bit order of the inc vector to

wire [N-1:0] inc;

This implies to me there is a difference in the way the bits of the vector are being applies to the individual instances of the array of instances.
I need to check the spec to see whether VCS or Verilator is more closely obeying the rules

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-09T15:12:19Z


Actually, the difference between VCS and Verilator is that when connecting the elements of the +array+ 'cval' to the array of instances, Verilator ignores the direction of the range in the declaration of the 'cval' array, but VCS does not.

Both VCS and Verilator however 'honour' the order of the range used to declare the array of instances.

Attaching a second testcase to better illustrate this by executing with all 4 possible combinations of range order:

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-09T15:14:08Z


A brief scan of the LRM has left me still unsure of what the correct behaviour should be

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-12-09T17:33:14Z


LITENDIAN was intended not to change the results.

Can you please run this on all of the big-3 e.g. on edaplayground to see if there's a consensus?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-09T18:13:32Z


VCS and NCSIM behave the same. I do not have access to Modelsim and it does not appear to be an option on edaplayground.

Aldec Riviera Pro however (which I'd never heard of) behaves the same way as Verilator.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-12-10T00:58:20Z


Ok, seems reasonable to clean this up then.

Perhaps you could try to put together a patch? The code that does this expansion is V3Inst.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-10T11:53:15Z


Ok, Ill take a look

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-10T12:56:52Z


This fixes it:
Regression in progress

diff --git a/src/V3Inst.cpp b/src/V3Inst.cpp
index cb62b505..1a7c4276 100644
--- a/src/V3Inst.cpp
+++ b/src/V3Inst.cpp
@@ -328,8 +328,10 @@ private:
                    <<"  pd="<<pinDim.first<<","<<pinDim.second<<endl);
              if (expDim.first == pinDim.first && expDim.second == pinDim.second+1) {
                  // Connection to array, where array dimensions match the instant dimension
+                AstRange *rangep = VN_CAST(nodep->exprp()->dtypep(), UnpackArrayDType)->rangep();
+                int arraySelNum = rangep->littleEndian() ? (rangep->elementsConst() - 1 - m_instSelNum) : m_instSelNum;
                  AstNode* exprp = nodep->exprp()->unlinkFrBack();
-                exprp = new AstArraySel(exprp->fileline(), exprp, m_instSelNum);
+                exprp = new AstArraySel(exprp->fileline(), exprp, arraySelNum);
                  nodep->exprp(exprp);
              } else if (expwidth == pinwidth) {
                  // NOP: Arrayed instants: widths match so connect to each instance

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-10T14:57:51Z


No new failures in regression

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-12-10T22:38:18Z


Patch looks good, can you please also update one of the test_regress tests to show the issue so it doesn't break in the future, then attach the diff?

Note you can cross check with e.g. VCS by running "test_regress/t/testname.pl --vcs"

Do you have a github user name?

Thanks

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-11T11:32:21Z


Will do.
github username is jcrmargetts

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Julien Margetts
Original Date: 2019-12-11T12:47:44Z


Patch and new test attached
(test pass with --vcs confirmed, test fail without patch confirmed)

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-12-11T22:16:42Z


Excellent, thanks.

Pushed to git towards eventual 4.026 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants