vpi_get of vpiDirection property broken

[veripoolbot]

---

Author Name: Rich Porter
Original Redmine Issue: 681 from https://www.veripool.org
Original Date: 2013-09-30
Original Assignee: Rich Porter

---

It seems that vpi_get of vpiDirection property only works for top level ports.

I have an inkling this may be due to the way verilator works internally.

Here's the tree dump of an example (t_vpi_get from branch below).

     1: MODULE 0x1c24400 <e533> {f14}  TOP_t  L1 [P]
     1:2: VAR 0x1c245c0 <e537> {f16} @dt=0x1c49d70@(G/w1)  clk [PI] [CLK] [P] INPUT
     1:2: VAR 0x1c24850 <e542> {f19} @dt=0x1c26040@(G/w16)  testin [PI] [P] INPUT
     1:2: VAR 0x1c24ae0 <e548> {f20} @dt=0x1c44cf0@(G/w24)  testout [PO] [P] OUTPUT
     1:2: VAR 0x1c4e700 <e623> {f16} @dt=0x1c49d70@(G/w1)  t__DOT__clk [PO] [P] WIRE
     1:2: VAR 0x1c4e7d0 <e393> {f19} @dt=0x1c26040@(G/w16)  t__DOT__testin [PO] [P] WIRE
     1:2: VAR 0x1c4e8a0 <e401> {f20} @dt=0x1c44cf0@(G/w24)  t__DOT__testout [PO] [P] WIRE
     1:2: SCHDR 0x1c4e970 <e241> {f26} "..."
     1:2: VAR 0x1c4ea30 <e484> {f30} @dt=0x1c49d70@(G/w1)  t__DOT__onebit [P] VAR
     1:2: VAR 0x1c4eb00 <e412> {f31} @dt=0x1c46420@(G/w2)  t__DOT__twoone [P] VAR
     1:2: VAR 0x1c4ebd0 <e420> {f32} @dt=0x1c47350@(w1)u[1:2]  t__DOT__onetwo [P] VAR
     1:2: VAR 0x1c4eca0 <e430> {f33} @dt=0x1c48800@(w2)u[4:3]  t__DOT__fourthreetwoone [P] VAR
     1:2: VAR 0x1c4ed70 <e441> {f35} @dt=0x1c48ac0@(G/sw32)  t__DOT__status VAR
     1:2: VAR 0x1c4ee40 <e512> {f42} @dt=0x1c49d70@(G/w1)  t__DOT__subin [P] WIRE
     1:2: VAR 0x1c4ef10 <e513> {f43} @dt=0x1c49d70@(G/w1)  t__DOT__subout [P] WIRE
     1:2: VAR 0x1c516c0 <e588> {f68} @dt=0x1c49d70@(G/w1)  t__DOT__sub__DOT__subin [P] WIRE
     1:2: VAR 0x1c51790 <e386> {f69} @dt=0x1c49d70@(G/w1)  t__DOT__sub__DOT__subout [P] WIRE

It seems to be correctly label the top level ports, but the sub-module sub has signals subin & subout which are labelled as wires. When we execute vpi_get(vpiDirection, portHandle) the function returns vpiNoDirection as would be expected from the above debug trace, but that's not the answer we're looking for.

The test case can be found as test_regress/t/t_vpi_get from the branch vpi-vpiSize-680 at https://github.com/rporter/verilator (which is the candidate fix for #680, but the test fails because of this issue).

[veripoolbot]

---

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-10-07T02:21:43Z

---

I suspect that V3Gate is flattening away the input/output attributes. We could make a new m_declInput similar to m_declOutput and propagate with propagateAttrFrom() but I think that will be overly aggressive and make signals that are not in/outs appear as such.

Right now only signals with some sort of 'verilator public' marking are saved - have you tried adding that to one of the input/output lines?

[veripoolbot]

---

Original Redmine Comment
Author Name: Rich Porter
Original Date: 2013-10-08T19:58:43Z

---

I updated t_vpi_get with a submodule that had public IO and it still doesn't work.

It's not the end of the world, it just makes vpi_get(vpiDirection, h) a bit impotent.

If you agree I can update t_vpi_get to not check and we can close this issue.

[veripoolbot]

---

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-10-10T02:15:50Z

---

Seems reasonable plan, for now at least.