Different Synthesis Results on Different Levels of Hierarchy (different amount of occupying slices)

Hello,

I have some design with regular structure (i.e. resembling 2D array), synthesizing in ISE 6.3 (for Spartan 3).And I experiencing following problem:

Assume the there is simple 3-level hierarchy A |_B |_C

The synthesis results for Unit "C" gives me implementation in X slices; in B - X+1. OK I assume that due to complex routing it is a predictable result (yet hesitating). But when I try to place and route unit A - it gives me X+2 slices, which conflicts with my area constraints. The problem is that "A" is simply an implementation of B (for debugging purposes). So I guess there are some differences in synthesis process. The constraints files, as well as Synth., Map, and PAR options are the same.

So probably I am missing something. Maybe someone can give some tips how to resolve this really annoying problem. Thanks.

--
Alex
Reply to
Alex
Loading thread data ...

It may be unexpected, but it's only a problem if you are out of slices. If that's the case you could try your own synthesis with instances of primitive elements or get a bigger part.

-- Mike Treseler

Reply to
Mike Treseler

That's the thing I can't be out of slices on level A, as it is only a wrapper for element "B" - so logically it is exactly the same. However the result is different. I normally don't tend to blame software :) but so far I can't really find the reason. Any other guesses.

--
Alex
Reply to
Alex

Howdy Alex,

The various report files should show what elements (MUXF's, LUTs, FF's, slices, CLB's, etc) are being used differently across your different hieractical locations. What do they tell you? Have you tried compiling both with and without flattening of hierachy?

I find it a bit surprising that A and B produce different results - but synthesis tools can be finicky sometimes.

Marc

Reply to
Marc Randolph

Hi Marc,

I have checked the MAP reports of both design and here is the difference: For the Element B:

AREA_GROUP AG_CU RANGE: SLICE_X6Y2:SLICE_X8Y1,SLICE_X5Y1:SLICE_X5Y1 COMPRESSION: 100 AREA GROUP Logic Utilization: Total Number of Slice Registers: 6 out of 14 42% Number used as Flip Flops: 2 Number used as Latches: 4 Logic Distribution: Number of occupied Slices: 7 out of

7 100% Number Slices used containing only related logic: 4 out of 7 57% Number Slices used containing unrelated logic: 3 out of 7 42% *See NOTES below Design Summary for an explanation of the effects of unrelated logic Total Number 4 input LUTs: 12 out of 14 85% Number used as logic: 12

For the element A:

AREA_GROUP AG_P00__CU RANGE: SLICE_X6Y2:SLICE_X8Y1,SLICE_X5Y1:SLICE_X5Y1 COMPRESSION: 100 AREA GROUP Logic Utilization: Total Number of Slice Registers: 6 out of 14 42% Number used as Flip Flops: 2 Number used as Latches: 4 Logic Distribution: Number of occupied Slices: 8 out of 7 114% (OVERMAPPED) Number Slices used containing only related logic: 4 out of

8 50% Number Slices used containing unrelated logic: 4 out of 8 50% *See NOTES below Design Summary for an explanation of the effects of unrelated logic Total Number 4 input LUTs: 13 out of 14 92% Number used as logic: 13

So now we can see that the amount of unrelated logic has increased!!

For the element C itself with the same constraints the data is: Logic Distribution: Number of occupied Slices: 7 out of

13,312 1% Number of Slices containing only related logic: 5 out of 7 71% Number of Slices containing unrelated logic: 2 out of 7 28%

I don't really see the the reason for appearing of the additional logic at the "A" level of hierarchy. The PLACE constrainis is set to CLOSED. :(

Alex

Reply to
Alex

Is it adding an IO Buffer or something like that?

Reply to
Benjamin Todd

It seems that problem has been solved. Problem was that in "A" I have one element unconstrained (unlike in B) however I thought MAPer will fit it onto free slices. When I placed back that constrain, everything seemed to work ok (the synthesis results are the same). I can't really explain such behaviour, but it works. So now the question is why it has been changed from the unit C. Unit B(simple asynch processor) is combined from different modules, every of which is strictly constrained (by area). In unit B all the units are simply interconnected (i.e. no additional logic used), so there again no reason for logic elements increase.

--
Alex
Reply to
Alex

Hi,

No the number of IOB's correspond to the design (if mean that). So far I can't explain where is this unrelated logic appear.

The problem now is when I have an array (design has a regular structure)of N units it map everything alright, but when I add one, i.e. N+1- it is appear that some of the previously well mapped elements appear to be bigger :-/. I assumed MAP-er tries to fit some unrelated logic into occupied slices, but first of all the AREA_GROUP is constrained as PLACE=CLOSE, and second there are still plenty of slices. So I am really desperate now.

--
Alex
Reply to
Alex

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.