cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
fishere
Visitor
Visitor
791 Views
Registered: ‎11-27-2019

Register Trimming Report vs Schematic: Need more detail...

Hi,

As part of our design, we have some RTL that is being optimised away during synthesis. The registers are indeed used elsewhere, however the reports are not particularly illuminating as to what is going on.

1) Synthesis report states that the register ByteCounter is being removed as it is unused. There are no information statements saying why, or if it is merged or optimised in some other manner.

- WARNING: [Synth 8-6014] Unused sequential element ByteCount_reg was removed. [… location...]

2) Both post synthesis and post implementation schematics show ByteCounter_reg and its output net going to subsequent LUTs and FFs meaning it is not removed.

3) On the bench, the design operates correctly, which would not happen if ByteCounter was incorrectly synthesized, it is in fact used to concatenate 8-bit words into 32-bit words, and is also used as part of a timeout system...

Now... I suspect that there is some optimisation going on as we have both OptDesign and PowerOptDesign utilised in the flow, however there is no further mention of ByteCount anywhere other than saying it is unused.

Question:

How can I get more detail as to what optimisations were performed for registers such as this? The fact the design is functional must mean that it is included in some manner, but it could well have been merged, combined, re-timed, re-named or otherwise modified by the tools as part of the optimisation flow. I don't need to change the synthesis strategy, as the design passes timing closure and has no errors, no critical warnings and a bare minimum of warnings (most of which we have checked).

Is there a way to get far far more verbose output from synthesis report?

Thanks,

Ed

0 Kudos
9 Replies
dpaul24
Scholar
Scholar
789 Views
Registered: ‎08-07-2014

@fishere ,

Is there a way to get far far more verbose output from synthesis report?

This part only a Xilinx staff can comment.

It may possible that the concatenation function is being done somewhere else in the design and so the tool is using the info from that part of the design. The synthesis engine has found out that the existence of the register/s is redundant and so is being removed. The tool algos are smart enough, you have to rely on them.

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem
Asking for solutions to problems via PM will be ignored.

0 Kudos
fishere
Visitor
Visitor
779 Views
Registered: ‎11-27-2019

Yes, that's right. Eventually these 8-bit words are formed into a 32-bit word called "Word_reg", this is then delayed one clock cycle via register Word_d1_reg, and both are used as part of an error detection routine. "Word_reg" is then re-timed over to a different clock domain.

As you say, it is entirely possible the tools are doing something like merging ByteCount with something else, however as the report makes no mention of signals that are related, it isn't possible to find out what optimisation it has done.

0 Kudos
dpaul24
Scholar
Scholar
773 Views
Registered: ‎08-07-2014

@fishere ,

If possible try out other synthesis tools for FPGAs - e.g. Synopsys Synplify for the Xilinx FPGA you are using. Perhaps the log report there has more details.

But as I said, what is happening at the synthesis report generated can be best answered by a Xilinx staff.

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem
Asking for solutions to problems via PM will be ignored.

0 Kudos
varunra
Xilinx Employee
Xilinx Employee
639 Views
Registered: ‎01-24-2017

hi @fishere ,

have to tried running synthesis with -debug_log option?

If that does't solve your query. you can share the code.

0 Kudos
drjohnsmith
Teacher
Teacher
606 Views
Registered: ‎07-09-2009

Why do you want to know what optimisation is done ?

     Remember, the tools are compiling your code, and applying your constraints, till the design fits and meets timing,

      Like your C++ compiler, would you ask how that has optimised the code , yes ok occasionally 

          but the hardware tools are a lot more ocmplex, as they have to be cycle accurate, 

               and they have plenty of options of moving registers back and forward, and duplicating paths which a C++ compiler has limited options to do .

      even so , I have seen very experience codes flummoxed as to what the C++ compiler has done, just that its dammed faster than they could make it run,

so provided the code meets timing / constraints and the code runs fine in the simulation

   question is , why do you want to know what   the tools have done ?

As others have said, the tricks of the tools are the crown jewels of Xilinx, your not going to get any info on the  public forums.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
fishere
Visitor
Visitor
492 Views
Registered: ‎11-27-2019

Hi Varunra,

I will try this next, thank you. Sadly cannot share code due to commercial sensitivity.

0 Kudos
fishere
Visitor
Visitor
489 Views
Registered: ‎11-27-2019

Hi John,

As part of the ISO-26262 and DO-254 development process we use commercially, there is a need to justify all warnings output during synthesis, implementation and bit generation. Many warnings can be ignored, however when it trims a register that is critical to correct operation, we need to be able to justify why that register has been trimmed. It could be that it is trimmed in error if the compiler is making optimisations down stream. It is the lack of information that is the issue, not its trimmed status or not, if it said removed due to optimisations x, y or z that would be fine, as you are right, the detail of each optimisation is proprietary. Other instances of this warning are preceded with information stating the register was re-named, merged with other registers or fully unconnected. As this instance doesn't state any optimisation, I have to ensure that the design is fully correct matching simulation. This is made more of a requirement due to the report stating removed but still present in post synthesis and post implementation schematics and netlists. 

Part of the issue is that it is not possible to exhaustively test all registers via bench tests. It could be that bench tests are correct as 8 bits of this 16 bit register are synthesised, but the upper byte is trimmed. In that case it would likely state something like ByteCount[15:8] has been removed as unused, however it doesn't provide that detail.

As the development flow requires checking, justification and sign-off of these warnings, I have to have sufficient information to be able to make that justification. To just note this down as a compiler optimisation is insufficient as it requires more detail to know if it is a safe optimisation. We could perform post implementation simulation, however that takes time when one extra line in this report would be sufficient to enable that justification.

I could re-phrase this question perhaps into:

Q: If the report provides information such as merge, rename etc before most register removal warnings, why has it neglected to provide such information for the case of this warning?

0 Kudos
drjohnsmith
Teacher
Teacher
415 Views
Registered: ‎07-09-2009

ah yes 

dO254 , avionics, mill stuff

yep, you need more details , and the tools arn't providing it ,

I assume your up to speed on the , admittedly now rather out dated Wight papers

https://www.xilinx.com/support/documentation/white_papers/wp401_DO254_FPGA_Designer.pdf

https://www.xilinx.com/support/documentation/white_papers/wp403_DO254_IP_Use.pdf

 

My, admittedly limited experience in this 

    is if there is a warning that we can not explain, 

      we ensure there is a simulation to demonstrate its not a problem,

            obviously this has to be on the post P&R code,

And I guess to ensure full DO 254 compliance, your using the DO254 code ?

 

Its an interesting problem, same as C code ,

   on the one side you have the compliers, and can they be guaranteed,

      and on the other, you silicon thats increasingly complex, and can't be tested 100 % 

What do the other design teams in the company do in this case ?

  Being Mil / Avionics, you must have very strict and audited procedures in place,

      what do they say to do if you have a warning / info in the copile,

 

Out of interest, what do you do abut register push back / forward , and about logic duplication ?

 

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
fishere
Visitor
Visitor
347 Views
Registered: ‎11-27-2019

Thanks John, Register forward, back, duplication, merge, etc are all fine in our flow, as long as the design is functionally correct, passes timing and that all warnings are justified. Most instances of these kinds of warnings have some other information messages or are rather obvious, but lack of information (you are right) forces a post PNR sim etc. At this point of the flow it is sufficient to mark the warning as still to be investigated, but it would need to be cleared by the end of the next step.

In this case, I'll read up on those whitepapers and likely try and explore the design post PNR to get some more clarity.