Allow Jtag cells (from specifyJtag) to be sized 

Hi,

I have a question that need advice.

I place jtag cells near the pad using specifyJtag, and then placeJtag. However, after placeDesign and optDesign, I am seeing very bad timing from reg->IO. These timing violation can be easily resovle by sizing or insert buffer in the jtag cells. However, encounter not doing it as after jtag placmement, the jtag cells are fixed.

So, is the correct flow to "unfix" the jtag cells before placeDesign (or before optDesign)?

Thanks for your advice.

Regards,
Eng Han

Additional information : There are many bi-direction I/O in the design, so the timing path through the jtag cells can go through more than one standard cell.

hi
Please find here with my suggestion on your question .
- Its not all ways recommended to unfix the Jtag cells if the placement is good
( good means : placed very closed to there respective IOs) .
- use "placeJtag with (-nrRow 10)  and ( -ioNetWeight 256)"  is you need close placement of IO buffers with in 10 Rows and with NetWeight.
- check the IO buffer is sufficient to drive the load if its placed correctly (close ) ( like X8 )  if not do manual eco "changeCell"
- check in your STA how much is the propagation time from fixed JTAG buffer to the next  driver ot load .
- if there is a huge timing delay and transition violation (at JTAG cells) then Soce can handle it by inserting repeater ( Optimises ) with out touching fixed cells. 

Probable cause for your timing get worst in REG2OUT paths .
1. floor planning
2. sdc constrains for reg2out or in2reg paths is too high (or not loding properly onto the design).
3. Placement quality of JTAG cell not good. ( need manual placement in this case if "placeJtag" fails with all swetches .

Hi Mohan,

I understand what you suggest. I am doing some of your suggestion but it is tedious and time consuming. Especially early in the design where there are numerous netlist update.

The tool suppose to do this automatically since timing can be met by sizing and buffering. So, back to my question, it is a practise to "unfix" the boundary scan cell after placeDesign?

Also, can someone confirm that the tool can buffer the wires connected to a "fixed" cell (or a wire connected only to 2 fixed cells)? I didn't observe this after optDesign, and I am not sure. Thanks.

Regards,
Eng Han

Hi ,
So from your mail I understood that placement is the problem. ( not placed close to corresponding IO) . have you specified all the cells before placing ??
if not use ,
Please try this command before actual jtag plancement.
"specifyJtag"  You can use this command before running the placeJtag command.
 Example
   -  The  following command specifies that the cell jtag_FlipFlop will be
       placed when using the placeJtag command:
       "specifyJtag -cell jtag_FlipFlop"
    - The following command specifies that all instance  names  that  begin
       with instG will be placed when using the placeJtag command:
    " specifyJtag -inst instG*"

In my trial the Jtag placement was successful ,

Hi ,
So from your mail I understood that placement is the problem. ( not placed close to corresponding IO) . have you specified all the cells before placing ??
if not use ,
Please try this command before actual jtag plancement.
"specifyJtag"  You can use this command before running the placeJtag command.
 Example
   -  The  following command specifies that the cell jtag_FlipFlop will be
       placed when using the placeJtag command:
       "specifyJtag -cell jtag_FlipFlop"
    - The following command specifies that all instance  names  that  begin
       with instG will be placed when using the placeJtag command:
    " specifyJtag -inst instG*"

In my trial the Jtag placement was successful using "First Encounter v04.20-s383_1 " ,

Hi Mohan,

Perhaps I am not clear.

The jtag cell is not a FF. It is a few combinatorial cells. The cells that drive the pad are placed close to the pad. That is okay. However, as I have mentioned, the design has alot of bi-direcitonal pads, and the timing path through the jtag module consist of a few combinatorial cell. Some of these combinatorial cell is shared by several pads, so they cannot be placed near a pad, but in the middle of sevaral pads. This is fine also.

However, logic synthesis could not know that there is a considerable distance between the placement of the jtag cells, so it use a small drive, and not buffering. After placement, some sizing and buffering will meet the timing relatively easy. The issue is after jtag placement, the jtag cells are "FIXED", so the tool cannot size it (I am not sure if the tool can buffer it).

For now, I re-fix it after placeDesign so that optDesign can do something about it. Still, after optDesign, the tool fix half of them, but some still have nasty -1.2ns slack. So I have to size all the jtag cells manually in the netlist before placeDesign. I think there is something wrong in the flow, so I am asking a better way to do this.


Regards,
Eng Han

What i have done in the past was to change the jtag cell from FIXED to PLACED and left it that way through out the rest of the flow.  With PLACED, optDesign was able to fix any timing violation related to the jtag cells.  In general, the JTAG prop on the cells only help in the initial placement.  After the initial placement, it should not be moved by too much.

li siang

The comand you are looking for is
userRptFixedCellsMakePlaced

It is under /share/fe/gift/scripts/tcl/

( at least in the latest  v5.2.1 ... I do not have any old releases )

I would do this between placeDesign and optDesign

... Shawn

Sorry
The comand you really want is
userUnfixJtagCells

located in the same place
the previous command would unfix blocks  as well

... Shawn