Stats

  • Locked Locked
  • Replies 7
  • Subscribers 93
  • Views 15482
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PAD connections in Encounter

naderi

 Hello everyone, 

I have manually modified synthesized RTL to include pad cells and their connections, then, fed them to Encounter v6.2 for place and route. After place and route, I realized vdd and gnd net are not connected to any pin.

I am wondering if I have to remove pad cells from input RTL.

Also, other IOs are connected to the associated pads by a metal layer that has the minimum width. What is the best way to define width of metal layer for connecting to the pads.

Thanks,

Ali 

  • Hi Ali,

    I usually see vdd and gnd connected not in the netlist, but via the "globalNetConnect" command.  Maybe you could try that to see if you could define the power/ground connectivity you're seeking to establish?

    I'm not sure I understand the issue you're describing regarding minimum width connections between IOs and associated pads.  Perhaps this would be cleared up with globalNetConnect so that a specialized routers could operate on nets connecting to IO cell rather than NanoRoute.

    If you could post back with how things are looking after running globalNetConnect with more details on the minimum width issue, I'm sure the community could help give suggestions on where to look next.

    Hope this helps,
    Bob

  • Hi Bob,

     

    I repeated the flow and used the "globalNetConnect" command, and still getting the same results.I think the problem of vdd/gnd connection is due to pad cells in the CMOS library from STMicro. The power pad cells have only one pin called "DUMMY". It seems the Encounter does not recognize it as a pgpin. I get following warning during "placeDesign" when I have connected "DUMMY" pin to gnd using a wire.

    **WARN: (SOCDC-348):    The output pin ioco_vssioco_1/DUMMY is connected to power/ground net gnd. This can compromise the delay calculation. Fix the netlist and re-run. 

    After SRoute the vdd/gnd warnings are following:

    Begin power routing ...
    **WARN: (SOCSR-1256):   Net vdd does not have pad pins to be routed. Please check net list or port class. (must be CORE class).
    **WARN: (SOCSR-1256):   Net gnd does not have pad pins to be routed. Please check net list or port class. (must be CORE class).
     

     

    About the second problem (width of the wire when connecting to a pad),as you mentioned, the option [-padPinWidth real] for sroute could solve the problem.

    Thanks,

    Ali 

  • Hi Ali,

    I am having the same problem.

    By editing the RTL netlist file after sythesis I instantiated the power pads in my RTL netlist and connected the pin "duumy" to vdd or vss wires which are defined as "inout". Accordingly IO assignment in .io and .eco files is fixed. After routing it only shows a thin wire connected between power pad and power ring. Apparently it did not solved the problem completely. I also tried to use 'sroute', but it did not wroked as well.

    If you have solved this problem, then please give some suggestion.

    Thanks,

    Rizwan

  • Hi Rizwan,

     For the thin metal connection I think the solution is modifying sroute parameters. sroute is connecting the wires based on pin width by default. Hence, you just need to change it from "pin width" to something you like. However, for IO pads, it may short other close pins if they are in the same metal layer.

    I still have trouble for connecting power pads to power rings. Would you please list the steps you followed in io and ico files? or copy some part of those files here.

    Also what is your power pad name?

     Thanks,

    Ali

  • Hi,
     
    I tried to use the sroute again by changing some parameters, it produces many thick power lines from many pads to power ring, resulting many violations.
    As a try, I changed the RTL netlist as below: I used VDDIO_65 and VSSIO_65 as my power pads.
    module abc( clk, rst, .....
    ......., vdd, gnd );
    inout vdd, gnd;
    .......
    VDDIO_65 io_Inst_VDD_1 ( .DUMMY(vdd) );
    VSSIO_65 io_Inst_VSS_1 ( .DUMMY(gnd) );
    endmodule
     
    abc.io file : used instaces as mentioned above
    .......
    Pad: io_Inst_VDD_1 N
    Pad: io_Inst_VSS_1 N
    .......
     
    abc.eco file : just commented the power pads
    #ADDINST io_vssio_2 VSSIO_65
    #ADDINST io_vddio_2 VDDIO_65
     
    I am normally using script to do all steps including floorplanning, power mangement, routing etc.
    Just trying through gui after getting this problem.
     
    Rizwan

  • Dear all,

     I have a problem. I define in my verilog file Pin and and I/O and connect them together. I define in the abc.io the Pin and Pad,  an d load the design in encounter. The pins a placed but not the Pad due to some errors. 

    Verilog File abc.v:

    module abc(clk, spi_sck_BU12P, spi_sdi_BU12P, spi_sdo_ICP, spi_chip_select_BU12P

    , led_BU12P, switch_ICP, reset_ICP, flash_reset_i_ICP, cc_vreg_en_BU12P

    , cc_reset_BU12P, cc_fifo_ICP, cc_fifop_ICP, cc_cca_ICP, cc_sfd_ICP

    , lcd_d_BBT16P, lcd_rs_BU12P, lcd_rw_BU12P, lcd_e_BU12P);

     

    BU12P spi_chip_select_2_Inst_BU12P(.A(spi_chip_select_pad[2]), .PAD(spi_chip_select_BU12P[2]));

    BU12P spi_chip_select_1_Inst_BU12P(.A(spi_chip_select_pad[1]), .PAD(spi_chip_select_BU12P[1]));

    BU12P spi_chip_select_0_Inst_BU12P(.A(spi_chip_select_pad[0]), .PAD(spi_chip_select_BU12P[0]));

    ICP flash_reset_i_Inst_ICP(.PAD(flash_reset_i_ICP), .Y(flash_reset_i_pad));

     ---------

    -------

    endmodule

     

    Reading IO assignment file "abc.io" ...

    **Warn: ignored IO file "spi_top.io" line 14: Pad: flash_reset_i_Inst_ICP N

    Reason: unable to determine object from name.

    **Warn: ignored IO file "spi_top.io" line 17: Pad: spi_chip_select_0_Inst_BU12P N

    Reason: unable to determine object from name.

    .........

    Can anyone tell what it does mean?

    Thanks,

     

    Eric

     

  • Eric,

    I'm not great with verilog, so it's hard for me to tell, but maybe you're missing the LEF of the ICP macro?

    - Kari

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.