06-23-2010 09:23 AM
I am getting some weird messages about my registers not getting packed into the IOB's...can someone tell me what causes them?
"WARNING:PACK:2780 - The register XXX has the property IOB=TRUE, but it did not join an IO component because it is not connected to any IO element."
"WARNING:PACK:1543 - The register XXX has the property IOB=TRUE, but was not packed into the input side of an I/O component. the IFF1 BEL site already contains the register symbol YYY. The clock enable signal on the register symbol XXX in the IFF2 BEL site conflicts with the clock enable signal on the register symbol YYY in the IFF1 BEL site."
Additional info: My project's design goals was defaulted at first to "Timing Performance with IOB packing", I had changed it to "Timing Performance with Physical Synthesis".
06-23-2010 11:31 AM
Ok, why did you change settings ? and what was happening before hand ?
The first warning is you have no IOB pin conencted, may be the synthesiser chucked it away due to some other problems.
Hows the simulation look ?
The second one is your trying to use an IOB register in a way that it can't support.
Are you infering the IOB or instantiating ?
Try instantiating, then at least you know what you get.
06-23-2010 03:51 PM
I'll answer in pieces.
1) I was having some implementation failures so I was just playing around with the design goals to see what would happen. I think before hand i was not getting these errors. However I did a project cleanup and reset the design goals, I am still getting these warnings.
2) The signals that ISE is flagging with these IOB warnings are all internal signals. I never had any intention of connecting them to IOB pins. Does the tool do something weird with the "IOB packing" design goal?
3) I never made an attempt to infer/instantiate an IOB register that I know of (I don't even know what that does).
06-23-2010 11:26 PM
Since you're not aware of the IOB properties they must be coming from the synthesis tool. Since the failure depends on physical synthesis which is a post-placement optimization, my guess is that physical synthesis is doing some optimizations that invalidate the IOB register packs. For the clock enable case it sounds like there's some logic replication occurring with the driver and the loads aren't being grouped appropriatly. That would be a bug against physical synthesis. The work around besides not using physical synthesis would be to apply an "S" property on the CE driver to block the replication.
06-23-2010 11:51 PM
when you synth a design 'into a chip' then you must by definition have as far as the tools are concerned IOB pins.
If you had no inputs / outputs the function would do nothing !
So I assume this is part of a bigger project.
Have you simulated ?
It's very un usual to have to change the design goals,
it's not 'the way' most people do synthesis.
If your not getting the design you want / expect change the code is the normal way.
Yes goals are useful, but a long way down the synth tree.
I have the thoughts you are not simulating, I'd recomend you look at the route .
06-24-2010 09:53 AM
Thanks for all the replies so far guys.
BWade: Sorry but i'm not so savvy....these internal registers in my code I didn't necessarily put explicit clock enable signals to them, so I don't really understand what you mean?
DrJohnSmith: Yes my design has signals going to IOB pins at the top level. But the signals giving me the warnings are INTERNAL signals that should not go to IOBs. I have run pre-synthesis simulations to verify functionality of my design. If you are talking about whether I have run post-synthesis simulation, no I haven't. I tried but the net names get so mangled I can't tell which signal is what in the modelsim waveform viewer..
06-24-2010 10:28 AM
synth warnign messages say these signals are conected to pins.
could be because your signals have been pushed up / down the hierachcy in the synth.
so these signals work in modelsim, same code etc etc ?
06-24-2010 11:56 AM
It's not so hard to debug. Examine the resulting NCD in FPGA Editor and trace the CE signals for the two FFs in conflict. If they are logically equivalent but different signals then logic replication caused the problem. Find the original driver in the logical design and apply an "S" property to it to block the replication.
06-24-2010 02:22 PM
DrJohn: Yes my design passed modelsim simulation, waveforms looked good.
BWade: Ok thanks for the extra info, I'll take a look at that. However what is this 'S' property? Is there a manual describing it that I can look at?
06-24-2010 03:28 PM
Page 194 of the constraints guide:
This documentation only talks about it as a net property but it can also be applied to logical instances for the use case I mentioned previously. This is fairly new behavior and I see the documentation isn't current. Time for a CR.
INST "ff_name" S;
07-08-2011 01:39 AM
You should also consider the fact that you may be actually grouping internal registers into IOB components (e.g. using the design goal for timing performance, which tells the synthesizer to do that). If the warning really bothers you consider another design goal. I had the same problem a few days ago.
06-26-2013 07:00 AM
Tried to give S constraint in my verilog code.
reg net_name /* S= TRUE */; //As per guide.
But did not worked for me still IOB packing warning apears for internal signal which is not output or input.
Using Xilinx ISE 14.4. Target device is Kintex 7.
09-10-2017 07:15 PM
From my experience, If input pin is to drive multiple outputs you must first clock input pin into a register using something like a clock. Then the single point register can be shared without a warning to multiple outputs like if 1 input was to drive 10 outputs. It should be clocked to a single register first then distributed or else there is a warning.
Seems like compiler does not want to guarantee all driven signals will match if it is a non clocked input signal.
If input changes close to clock edge it is safer to clock it into 1 point then distribute, compared to assuming that all 10 routes will end up with the same input value when timing is super close to clock.
I am not sure if that is the exact reasoning but after encountering the same error I clocked in the input first then distributed.