谁能帮忙找下 S家的 article 2091566

apollo6

谁能帮忙找下 S家的 solvneit  article 2091566 谢谢！

apollo6

[color=rgba(19, 2, 2, 0.73)][size=0.75]Title
Why Am I Getting TEST-930, TEST-932, or TEST-934 Errors During Boundary-Scan Insertion?



[color=rgba(19, 2, 2, 0.73)][size=0.75]Description

Question:

I am inserting boundary-scan logic in my design. However, I am getting TEST-932 errors when I run the preview_dft -bsd command, which prevents boundary-scan insertion:

Error: Pad cell Ubidi attached to design port EXT_BIDI_EN is a black box. (TEST-932)

I have complex pads, which I have modeled with the define_dft_design command, which was accepted. I have confirmed the pad cell library is properly linked in the design.

Why am I getting these TEST-932 errors, and how do I resolve them?

Answer:

Unexpected TEST-932 and TEST-934 errors can be caused by core-side pad signals being connected to ports of the current design during boundary-scan insertion.

Consider the following simple bidirectional pad definition:

define_dft_design -design mybidi_pad -type PAD \  -interface { \    data_out DOUT h \    data_in DIN h \    enable EN h \    port PAD h}

In most cases, the core-side pad signals (in green) connect to the core logic, and the board-side pad signals (red) connect to chip-level ports, respectively:

Figure 1: Typical Bidirectional Pad Cell Connections

In some special cases, however, an IP block might be designed to have IEEE 1149.1 boundary-scan inserted in them, but with some core-side pad control signals (in green) connected to ports:

Figure 2: IP Block With Core-Side Signal Connected to Port

In this example, the core-side bidirectional pad enable signal is connected to a port, so that it can be driven by logic at a higher level:

Figure 3: IP Block Instantiated at Chip Level

Because the boundary-scan logic is inserted at the IP core level, by default the tool expects all ports at that level to be connected to board-side pad pins. If the tool finds ports connected to core-side pad signals, it issues TEST-930, TEST-932, or TEST-934 errors, depending on the overall pad function, pad pin function, and connection topology:

TEST-930 (Error) NO Pad cell have been found on the design port %s.TEST-932 (Error) Pad cell %s attached to design port %s is a black box.TEST-934 (Error) The Input Pad cell %s attached to design port %s has no core logic output pin.

To resolve this, first determine which pad cell pin is connected to the port indicated in the message:

dc_shell> report_net -connections [get_nets -of [get_ports EXT_BIDI_EN]]****************************************Report : net        -connectionsDesign : core_topVersion: J-2014.09-SP4Date   : Tue Apr 28 08:22:57 2015****************************************Connections for net 'EXT_BIDI_EN':    Driver Pins         Type    ------------        ----------------    EXT_BIDI_EN         Input Port    Load Pins           Type    ------------        ----------------    Ubidi/EN            Input Pin (mybidi_pad)

Next, confirm that the pad pin is indeed a core-side signal. (You can check the pin's signal type in the define_dft_design specification for that pad type.) If the pad pin is a core-side pad pin, define the port from the error message as a linkage port in the boundary-scan configuration commands at the IP block level:

dc_shell> set_bsd_linkage_port -port_list {EXT_BIDI_EN}

This excludes the ports from being analyzed for proper connected pad cell functionality. Then, the preview_dft command shows the correct port DINOUT with the associated boundary-scan cells and the insert_dft command successfully inserts the boundary-scan logic.