( ESNUG 399 Item 4 ) --------------------------------------------- [08/08/02]
Subject: ( ESNUG 398 #1 ) Customer Reports A Failed Floorplan Compiler Demo
> Design 'Obelix' was a 1.4 M instance 0.13 um design (~5.6 M gates) with 7
> top level soft blocks, 35 K leaf cells and more than 230 embedded hard
> macros. The top level of Obelix had more than 50K nets. It's highest
> system frequency was 15O Mhz with the I/O frequency exceeding 600 MHz.
> ... with Obelix we needed to apply both a top down and a bottom up
> approach. ... The floorplan completed with a very fast cycle time (10
> minutes for cluster creation and half an hour for cluster placement).
> The top-level architecture was well understood and the blocks identified
> were successfully closed in term of timing and routability in our Apollo
> back-end flow.
>
> - Valentina Baiardo
> STMicroelectronics Agrate, Italy
From: Valentina Baiardo <valentina.baiardo@st.com>
John,
I wanted to correct a typo here. We used Magma as the backend for the
Obelix design and an Apollo flow in shadow mode as a check. Both flows
closed timing successfully.
- Valentina Baiardo
STMicroelectronics Agrate, Italy
---- ---- ---- ---- ---- ---- ----
From: [ Chicken Man ]
Hi, John,
Keep me anon. I am very curious regarding Floorplan Compiler evalution.
We saw a Floorplan Compiler demo last week at Synopsys where their own test
data was smaller than the chip in Valentina's report. The clustering and
placement was not finished at 1.5 hrs and they did not show us the final
result in the full 2 hr demo. I do not know what was wrong. Thus, I'm kind
of curious on her 40 minute runtime quote.
Anyway, we will not spend much time on FPC till it merges with the Milkyway
database next year. They are working in mergeing JupiterXT and FPC (under
Ho's team that owns FPC, Jupiter, Columbia, etc.) I know there are some
key differences in Astro-Apollo/PhysOpt based placement algoritms. It's not
easy to merge both. We plan to stick to our Apollo + Jupiter flow for now.
- [ Chicken Man ]
|
|
