how to do a good placement in encounter

[egg]

Hi all, recently I was doing a pure digital design with encounter, when I imported the data, and do the placement of std-cell automaticly, I found the placement was
not so good, because some of the reference cell was placed everywhere by encounter, and the time is hard to close, can anybody tell me how can I improve the placement? Or maybe I can define some region/fence or partitions? or can anybody tell me some principle to define the region because I had tried some work like this , the result looks not so good.

 

[egg]

could anybody give some advices about this ?

 

[research235]

Dear egg,

since u mentioned its a pure digital (std.cells) placements. You can use different placement optimisation tech. available with EDA tool (eg: timing diriven, area driven placemnet).

Or you can incrase the floorplan and try the placement . or check your placemnt constraits.

BR

Sing

 

[egg]

Dear egg,

since u mentioned its a pure digital (std.cells) placements. You can use different placement optimisation tech. available with EDA tool (eg: timing diriven, area driven placemnet).

Or you can incrase the floorplan and try the placement . or check your placemnt constraits.

BR

Sing

Dear 235, thanks for you valuable info.
The size has decided and I cann't change it now, for timing diriven, you mean in the pre-cts step? My understand is that the CTS step has contained the timing diriven, so if use timing diriven in the pre-cts step, it would be reduplicate, right?
if not, please tell me the different.

 

[research235]

Dear Egg

It all depends on how much negative setup and hold violation are there in ur design. If very less then u can work on teh cts optimisation.

But just post placement the timing is very worst, then during placement, u can plaay around with setoptmode and do placement.

or try to cotact front end guys if the constrainst are hard one. else u can play with with SDC file .

SING

 

[ebuddy]

If timing is not tight in your design, try to place the cells with "timing driven" option off. By default, the encounter places cells based on congestion. It will make the routability better.

I also found it better to add fillers later, after the routing is done. This can allow me to have some room to move cells around a little bit, if there is any "check geometry" violations.

 

[cop02ia]

Hi,

When I first worked, I had a small design, only around ~10K gates (180nm). No macros at all but total slack after routing was ridiculous.
Since it was an IO constrained design, there was not much I could do regarding the size of the floorplan.

Apart from the 3 P/G stripes which I had, the cells were all crowding towards along the centre (which means I/O paths to FF weren't an issue). Trying to fix routing made the density worse & worse.

Astro was taking more than 3 days to do routing & each round of routing seemed to pile in more & more buffers, so I tried doing something that seemed counter-intuitive during placement:
I put a cell-blockage on almost every other row.

With more routing area, I managed to close timing of the design. Now we're not using Astro anymore but I believe you can specify a placement padding around standard cells with Encounter so the extra room can be used for routing. You can also specify some distance between rows (non-abutted rows).

Best regards.

Added after 20 minutes:

Hi,

A couple of years ago I had a design which was purely made up of standard cells. Placement was OK but after CTS, some routing congestion issues cropped up and I also had some violations with maximum fanout gates (less than 10 violations).

Optimization created either more fanout errors or setup timing violations. Other DRV problems (transition & capacitance) were not an issue so I proceeded to routing (maximum fanout for this design was constrained below 10 gates). The end result was bad. Timing was not met & each optimization made the area more dense.

In the end, I went back to post-CTS & fixed fanout problems manually and used Encounters' optimization just for setup & hold fix. When it passed, I proceeded to routing & did more or less the same thing. The manual fixes seemed somewhat labourious but I could see that in a lot of cases, the routing to the gates were too complicated. Sometimes by adding a buffer, the routed net could easily detour to a less congested spot and thus fixing fanout & making timing a lot more better.

So if the timing violations are small, sometimes upsizing / downsizing / shifting that #*&% flip-flop to the row below, might just be what it takes to ease congestion & fix total slack.

 

[egg]

Thanks SING again, and ebuddy, cop02ia.