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

Verilator behaviour of driving DUT inputs #1222

Closed
veripoolbot opened this issue Sep 28, 2017 · 9 comments
Closed

Verilator behaviour of driving DUT inputs #1222

veripoolbot opened this issue Sep 28, 2017 · 9 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Sep 28, 2017


Author Name: Shareef Jalloq
Original Redmine Issue: 1222 from https://www.veripool.org


Perhaps this is by design, but it feels like a bug to me. I'm seeing that having driven a top level input pin to a known value, without updating that driver, the signal reverts to its old value. I was assuming that they'd stay constant until you forced them again.

For example, modelling a bus interface driving some data with a CPU_D[15:0] and an active low write enable CPU_NWR. I assumed that the following code would result in the data being maintained. Surely we can't be expected to update every IO every cycle for a bus we're driving?

  void test(void) {
     tick();
     printf("Driving CPU interface. tickcount=%d clk=%d\n", m_tickcount,m_core->CLK);
     m_core->CPU_D = 0x1;
     m_core->CPU_NWR = 0;
     tick();
     m_core->CPU_NWR = 1;
     tick();
  }

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Sep 28, 2017


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-09-28T22:21:27Z


Try running with valgrind memcheck or similar. Perhaps there's a wide signal input adjacent to the reset where your code is exceeding the bounds of the array.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 2, 2017


Original Redmine Comment
Author Name: Shareef Jalloq
Original Date: 2017-10-02T14:45:12Z


Have you got any recommendations for debug options? We've tried running with valgrind, and there are warnings about uninitialized values somewhere in Vtop, but there are no line numbers printed for Vtop.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 2, 2017


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-10-02T14:53:47Z


When you compile the verilator output with GCC, use "-O0 -g". Also link with "-g".

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 2, 2017


Original Redmine Comment
Author Name: Shareef Jalloq
Original Date: 2017-10-02T16:00:00Z


So we fixed one unitialised variable in my TB and my colleague fixed another issue with your VCD callbacks, patch attached, but I'm still getting the same behaviour where my toplevel input is cleared.

There is also another leak that valgrind moans about which is in your Verilated::catName function where strp is never cleaned up.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 2, 2017


Original Redmine Comment
Author Name: Shareef Jalloq
Original Date: 2017-10-02T16:16:51Z


OK, so we stepped through the sim and found the issue. Do you support tri-state buses? My CPU input is an inout and the following code seems to drive 0x0.

VL_INLINE_OPT void Vkitt_top::_sequent__TOP__2(Vkitt_top__Syms*
__restrict vlSymsp) {
      VL_DEBUG_IF(VL_PRINTF("    Vkitt_top::_sequent__TOP__2\n"); );
      Vkitt_top* __restrict vlTOPp VL_ATTR_UNUSED = vlSymsp->TOPp;
      // Body
      vlTOPp->CPU_D =( 
                       ( 
                          ( (IData)(vlTOPp->kitt_top__DOT__u_biu__DOT__cpu_rdata_oe_r) ? (IData)(vlTOPp->kitt_top__DOT__u_biu__DOT__cpu_rdata_r) : 0U) & 
                          ( (IData)(vlTOPp->kitt_top__DOT__u_biu__DOT__cpu_rdata_oe_r) ? 0xffffU : 0U) 
                       )  &
                       ( (IData)(vlTOPp->kitt_top__DOT__u_biu__DOT__cpu_rdata_oe_r) ? 0xffffU : 0U)
                     ); }


@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 2, 2017


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-10-02T22:52:50Z


Thanks for the VCD leak fix, I pushed that change. As for catName, I suspect you aren't deleting the model you new().

Tristates have very limited support, see the manual. It might be no one has tried having an inout as a pin to the model before, will need to do some research on that. The typical usage is to not Verilate a chip's pad ring, just do the core, so all of the signals are unidir.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 3, 2017


Original Redmine Comment
Author Name: Shareef Jalloq
Original Date: 2017-10-03T09:16:29Z


Hi,

thanks for the info. Will create a top level wrapper that only includes the inout.

I think we're deleting the model correctly. My colleague's view was that it looked like a performance hack and that the buffer would never be deleted. I'm out of my depth here though.

Cheers.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 3, 2017


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-10-03T11:12:47Z


FYI, it didn't have tracing hence the issue you found, but the t_leak test checks there aren't any leaks.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Aug 25, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-08-25T14:45:21Z


Closing due to age; tracing issues etc fixed earlier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.