cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pallison
Adventurer
Adventurer
6,273 Views
Registered: ‎03-30-2012

Map error when power reduction is turned on?

Map gives a Pack:2811 error in trying to map the KCPSM6 with directed packing when I have 'power reduction' turned on at all:

 


ERROR:Pack:2811 - Directed packing was unable to obey the user design
constraints (BLKNM=u_phase_scanner_A_B/processor/KCPSM6_PC2) which requires
the combination of the symbols listed below to be packed into a single SLICE
component.

The directed pack was not possible because: The clock enable signals don't
agree.
The symbols involved are:
MuxCY symbol
"u_phase_scanner_A_B/processor/address_loop[8].upper_pc.mid_pc.pc_muxcy"
(Output Signal = u_phase_scanner_A_B/processor/carry_pc<8>)
MuxCY symbol
"u_phase_scanner_A_B/processor/address_loop[9].upper_pc.mid_pc.pc_muxcy"
(Output Signal = u_phase_scanner_A_B/processor/carry_pc<9>)

(plus many more).

 

Is there a way to tell Map to somehow exclude the KCPSM6 section from power optimization? Or is there another way to make KCPSM6 compatible here? Or is the only solution just "remove all BLKNM references"?

 

Thanks,

Patrick

0 Kudos
6 Replies
athandr
Xilinx Employee
Xilinx Employee
6,266 Views
Registered: ‎07-31-2012

Hi,

 

Try various combinations of the -power switch. I guess you are using either high or xe. please try setting the -power switch to on and check if helps. More information on -power swith check Pg 93- http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/devref.pdf

 

-power on|off|high|xe

 

If you have the BLKNM references, in UCF then try commenting them out and check.

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
yashp
Moderator
Moderator
6,259 Views
Registered: ‎01-16-2013

Hello,

As per your error message. Tool is unable to pack 2 component in single slice because of different control set.

Do you have any PAR constraint for component mentioned in your design?

Thanks,
Yash
0 Kudos
chapman
Xilinx Employee
Xilinx Employee
6,249 Views
Registered: ‎09-05-2007

The following is to be found in the 'Known Issues' section of the 'READ_ME_FIRST.txt' file provided in the KCPSM6 package. Could it be that it is actually one of these causes? Regardless, workaround 'd' is already the one that your propose and the modified file is provided in the package. 

 

 

'Pack:2811' errors in MAP when using ChipScope
----------------------------------------------

Connection of ChipScope can generate 'Pack:2811' errors in MAP. This mainly appears to happen
when connecting 'out_port' or 'port_id' directly to ChipScope. It has also been known to
happen when connecting ChipScope directly to the 'address' or 'instruction' ports.
 
There are four potential workarounds for this issue.
  a) To insert a pipeline register between KCPSM6 and ChipScope.
  b) Set the 'Keep Hierarchy' option in XST to 'Yes' (default is 'No').
     However this may not work if there are more than one KCPSM6 (see below). 
  c) Set the following system environment variable: XIL_MAP_OLD_SAVE=1.
     Close ISE.
     Right click on 'My Computer' and select 'Properties'.
     Go to the 'Advanced' tab and choose 'Environment Variables'.
     Use 'New' or 'Edit' as necessary.
     Open and run ISE again. 
  d) Remove or comment out all the Slice packing directives (HBLKNM attributes) in the KCPSM6
     source file. The 'kcpsm6_without_slice_packing_attributes.vhd' located on the 'Miscellaneous'
     directory already has these attributes commented out. Using this workaround will result in
     KCPSM6 occupying more Slices and having a lower peak performance and therefore it is
     better to only resort to using it if the other methods cannot be used or are unsuccessful.


'Pack:2811' errors in MAP when using 'Keep Hierarchy' and design contains multiple KCPSM6.
------------------------------------------------------------------------------------------

This error has been observed when a design contains multiple instances of KCPSM6 and
the 'Keep Hierarchy' option in XST has been set to 'Yes'. Therefore the obvious solution is
to revert to the default setting of 'No'. Alternatively the 'Allow Logic Optimization Across
Hierarchy' option in MAP can be enabled (tick box in Project navigator or apply the
-ignore_keep_hierarchy switch on the command line).

If it is undesirable to adjust your implementation settings then please see 'c' and 'd'
workarounds in the issue above.


'Pack:2811' errors in MAP when using a low 'Max Fanout' value in XST.
---------------------------------------------------------------------

The 'Max Fanout' parameter is a 'Xilinx Specific Option' for XST and has the default value
of 100000 for the devices used with KCPSM6. It has been known for very low values (e.g. <20)
to result in a subsequent error in MAP. Should this occur, please increase the value. If
you have a particular reason to use such a low value then synthesize KCPSM6 separately and
include it in your design as a 'black box'.

Ken Chapman
Principal Engineer, Xilinx UK
pallison
Adventurer
Adventurer
6,228 Views
Registered: ‎03-30-2012

On, high, or xe all produce the same result here. With "off", it works fine.
0 Kudos
pallison
Adventurer
Adventurer
6,226 Views
Registered: ‎03-30-2012


@chapman wrote:

The following is to be found in the 'Known Issues' section of the 'READ_ME_FIRST.txt' file provided in the KCPSM6 package. Could it be that it is actually one of these causes? Regardless, workaround 'd' is already the one that your propose and the modified file is provided in the package. 


Ken:

 

No, none of the causes there are the problem - there's only one PicoBlaze, KEEP_HIERARCHY is off (power optimization actually doesn't work with KEEP_HIERARCHY being on), and ChipScope isn't connected to the PicoBlaze at all.

 

I saw those listed in the 'Known Issues', but since this was directly related to the power optimization only, I was hoping someone else had found a better solution. I have *no* idea if there's a way to tell the Power Optimization stuff to stay the heck away from a portion of the hierarchy. There doesn't seem to be...

 

The project does compile by removing the HBLKNM constraints, but sadly, the performance is worse and it doesn't meet timing (system clock is 162.5 MHz here, on an Artix-7 200T, speed grade 2) - it does meet timing with the HBLKNM constraints present.

 

Any other ideas? I'm loathe to try it under Vivado to see if things magically get better because of the amount of work required to migrate it over, and plus the notes also say that Vivado doesn't honor the HBLKNM constraints either...

 

Patrick

0 Kudos
chapman
Xilinx Employee
Xilinx Employee
6,209 Views
Registered: ‎09-05-2007

Patrick,

 

Thanks for confirming that this was unrelated to any of the previously known issues. Clearly something isn’t right here, but on this occasion I think I have some sympathy for the ISE tools because they are being presented with conflicting messages. The HBLKNM constraints are saying what logic should be placed in each Slice but the power optimisation option is telling MAP that it should change the logic to reduce power consumption. If we look at the reference suggest by ‘athandr’ it tells us that the power optimization options can result in minor area increase and reduced performance. In the case of PicoBlaze, virtually any minor increase in logic size will prevent it from packing into the Slices. This would in turn lead to an additional level of logic in one or more of the critical paths and that would have a noticeable impact on the performance. That’s exactly what you are seeing when you remove the conflicting HBLKNM constraints so we should be surprised.

 

As far as I can see, the Power Optimisation is a global switch so I don’t personally know if there is a way to tell MAP not to touch certain sections of your design. I suggest that you open a case with the official Xilinx Technical Support to see if they can make any suggestions (i.e. this is not really a PicoBlaze specific issue). One way or another it would keep coming back to the issue of having conflicting constraints/directives and therefore we would need to know which takes priority.

 

The only design-level suggestion I can make is to analyse the path(s) that are falling short of your target. If they are internal to PicoBlaze then there is not a lot I can suggest as it just sounds like you are on that boundary that is trading off power verses performance. If however the failing paths relate to your definition of input and/or output ports then maybe you can do something. Look to see of you can optimise the decoding of ‘port_id’ (e.g. check that you are allocating ports in an optimum way and then only decoding relevant bits of ‘port_id’). Also look to see where you could insert some pipeline registers (e.g. ‘port_id’ is valid for two clock cycles so you could break your port decoding down into two stages).

 

Sorry, but I’m still waiting on a delivery of magic wands before I can give any more out.

 

Ken Chapman
Principal Engineer, Xilinx UK
0 Kudos