Bug #342

Missing default value for unused bits

Added by Richard Schindler over 1 year ago. Updated over 1 year ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Estimated time:
30.00 h


When calling Verilog Generator out of HW Design using attached database, you can see that unconnected ports are assigned with the specified default value.
But there is no assignment for unused input bits if not all bits of a vector are connected within the design.

In the example, the bits of DIN_0[7:4] are still open.

Best regards,

Richard (3.62 KB) Richard Schindler, 10.03.2017 12:37 PM (5.39 KB) Richard Schindler, 13.03.2017 01:51 PM (5.82 KB) Richard Schindler, 23.03.2017 12:55 PM

Associated revisions

Revision 90b886df (diff)
Added by Janne Virtanen over 1 year ago

[CORRECTIVE] Revised the rules when to use abstraction definition default instead of port default. (refs #342)

Revision 86638df6 (diff)
Added by Janne Virtanen over 1 year ago

[CORRECTIVE] Fixed the failure in rules defining used default value for port assignments. (refs #342)


#1 Updated by Janne Virtanen over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Janne Virtanen
  • Estimated time set to 30.00 h

This should be fixable, although it will take some time and testing. Essentially this requires parsing which bits will be left unconnected and then assign them with either default value if it exists, or z if it does not.

Current work around could be using tieoffs, but apparently tieoff editor does not support part selection.

#2 Updated by Richard Schindler over 1 year ago

Hi Janne,

can you do this for unconnected ports as well?
When having unconnected ports by accident in a large design, it will be much easier to find this issues when the ports are undriven and not tied to low by default.

Best regards,


#3 Updated by Richard Schindler over 1 year ago

I think there is a general problem with default value assignment, not even when using part select operator.
When a port is mapped to a bus interface this issue is also visible.
In the attached example clk_en port of Sink module is not assigned to default value.

Best regards,


#4 Updated by Janne Virtanen over 1 year ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

Some bugs were found in closer inspection, but according to the standard, the default value for a port is used only if it is unconnected. This means that no bits from any default value is used if any bits of the port is connected.

Moreover, if an unconnected port in mapped in a bus interface have a default value defined in abstraction definition, it shall be used for the port.

As stated earlier, an obvious workaround could be a tie-off with part select, but I do not know if and how we will proceed with that. This seemed to work by injecting part selection to the XML file of a design, but the editor does not currently allow it.

#5 Updated by Richard Schindler over 1 year ago

Hi Janne,

I think the current implementation of unconnected ports is not correct.
The standard says: “The value shall be applied to this port when it is left unconnected, independent of being part of a busInterface. This value shall be over-ridden by the default value from the abstraction definition if the interface is connected”
Can you please keep this issue in mind and fix it on a longterm basis?

Best regards,


#6 Updated by Janne Virtanen over 1 year ago

Current implementation should take this into account.

#7 Updated by Richard Schindler over 1 year ago

Sorry for the inconvenience but I tried with K2 version 3.4.0 and I think, the implementation is not like described in the standard.
Please see the example in the attachment.
Maybe I'm wrong but my understanding is, that for the unconnected interface the default values of the port definition should be assigned.

#8 Updated by Esko Pekkarinen over 1 year ago

  • Status changed from Closed to In Progress

DefaultValue_432_3: I agree the default values for data1 and en1 should come from the port definition and not from the abstraction definition, since interface DATA_1 is not connected in the design. We'll look to fix this soon.

#9 Updated by Janne Virtanen over 1 year ago

Fixed. Now DATA_0 gets its defaults from abstraction definition and DATA_1 picks the port defaults. Likewise, a third port in DATA_0 picks its default value from port since it has no defined default value in the abstraction definition.

Also available in: Atom PDF