Stats

  • Locked Locked
  • Replies 9
  • Subscribers 144
  • Views 16084
  • 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

rodCreateRect taking too long

thomas1000

Using the profiler and also just putting print statements in I found that I am having trouble with rodCreateRect taking longer and longer to process.  I have some very simple code:

for(i 0 Nx

   for(j 0 Ny

      <compute X & Y>

      rodCreateRect(?cvId Cv ?layer LPP ?bBox <Computed from X and Y by a simple linear formula>)

   );End for j

);End for i

This is such a simple code segment but when you have 700 or 800 rectangles to place on each inner loop, things are slowing down to the point that it takes hours to get throught this.  I realize that every time you create an object it has to add it to a large data structure, but is there no way to do this?  I cannot use the array or mosaic functions because the array is not cartesian.

Anyone have any ideas about how to speed this up?

  •  If you don't use any ROD functionality, which I cna't see in your code snipset,

    and you don't use ROD handles later on, which I also can't see there are no ROD names assigned,

    why don't you use then not "dbCreateRect" rather than "rodCreateRect", this might speed up your code.

     

    Bernd

  • Hours? Really? I just tried this code:

    Nx=30
    Ny=30
    LPP="Metal1"
    Cv=geGetEditCellView()
    startTime=getCurrentTime()
    for(i 0 Nx
       for(j 0 Ny
          rodCreateRect(?cvId Cv ?layer LPP ?bBox list(i:j i+0.5:j+0.5))
       );End for j
    );End for i
    endTime=getCurrentTime()

    printf("Start: %L \nEnd: %L\nDiff: %L\n" startTime endTime compareTime(startTime endTime))

     

    This is placing 900 (you were talking about 700-800) rectangles (yes, all evenly spaced, but that shouldn't matter if it's the rodCreateRect which is being slow), and I got:

    Start: "Feb  4 10:27:11 2013"
    End: "Feb  4 10:27:11 2013"
    Diff: 0

    In other words, it was less than a second (it seemed to return immediately).

    Maybe the rodCreateRect is not the bottleneck. Can you run the SKILL Profiler on your code?

    Regards,

    Andrew.

  • Thanks Andrew for your response.  I have a of comment to your response that I believe makes my situation more difficult:

    1)  I wasn't clear enough in my write-up.  I am not just placing 800-900 rectangles - it is that number squared and it is being done for 7 layers.  Nx and Ny are both 800-900.  At first things go pretty fast until you get a ways into the placement on each layer but all along it is slowing down until it is litterally seconds between rectangles.  Seven layers worth of placement (same code run over seven times) took about 24 hours with only a small number of pre-existing shapes in the layout to define borders).  With seven complete iterations of this code, the total number of rectangles placed is, therefore, between 4.48 and 5.67 million - not 800 or 900.

    2)  I ran the profiler on the entire code and eliminated the other portions.  rodCreateRect seems to call an internal rodiCreateRect that is the bottleneck.  It uses the most time and memory.

    Even with 4.48 - 5.67 million elements it is hard to believe that things slow down that much.  Do you think the dbCreateRect operation would be faster?  Are there any other options available if I cannot simply use a mosaic?

  • We have always found the rod commands to be much less efficient than the db commands. I would encourage you to avoid rod for something this large. But, even if you use the dbCreateRect command, having ~5 million flat shapes in a cellview can also lead to performance problems. Is there any way you can introduce some hierarchy? You may need to use the needNCells command to increase the amount of memory allocated for db objects and lists for that much data.

    Derek

  • The profile showed that dbCreateRect runs over 30x faster than rodCreateRect and rodCreateRect started fast and then slowed down.  dbCreateRect ran fast to begin with and stayed at the same rate so this is a huge difference to me.  It speeded up run time from 36 hr to I'm guessing less than 2 hr. - I'll have to wait until it is done but it did a layer in 10 minutes and there are 7.

    Thanks for the tip!  I had no idea there would be such a difference.

  • ROD objects have a lot of benefits if you want to align them or refer to them by name, but there's overhead involved in doing this. It will take more time, more memory, and more database info to record this extra info, and if you're only creating the shapes and not accessing them by name or by handles later (which seems unlikely for such a vast number of shapes) then dbCreateRect will clearly be faster. needNCells may help too, but if you can break things down into repeating patterns and use mosaics, that will help enormously. Creating millions of flat shapes will always be a performance challenge.

    Andrew

  • The final improvement in run time was that the 36 hr was shortened to 28 minutes. 

     Thanks for the explanation on the rod functions.

  • Hi Thomas,

    I didn't see if anybody suggested rodFillBBoxWithRects(), did you happen to try this at all?  This might be beneficial - the rectangles will be regular rects with no "RODiness" to them, hence less overhead, and hopefully quicker too?

    Best regards,

    Lawrence.

  • Lawrence,

    I think Thomas said his rectangles were not Cartesian, so I assumed that wouldn't help.

    Andrew

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.