UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Reply

BRAM warnings round-up

Accepted Solution Solved
Advisor
Posts: 543
Registered: ‎01-22-2015
Accepted Solution

BRAM warnings round-up

This post is my attempt to consolidate and give-back to the Forum some things I’ve learned about the BRAM Xilinx IP. For this discussion, I have used a Kintex-7, Vivado v2017.3, and Block Memory Generator (8.4).

 

First, I am grateful to Xilinx for making the BRAM IP freely available to us. I use this IP a lot and it has always worked well. However, BRAM IP has some peculiarities that can be understood by looking at the warning messages generated during synthesis and implementation.

 

As with most Xilinx IP, you can select either Out-Of-Context(OOC) or Global synthesis. I’ll discuss each separately.

 

Global-Synthesis + Implementation:

Synthesis Warning [Synth 8-3331] ….. has unconnected port….

I get lots (>100) of these warnings and they have long been a pet peeve of mine. As explained in <this post>, these warnings can be safely ignored and indicate that you are not using some ports of the BRAM IP - and hence these ports are unconnected. The reason these warnings are my pet peeve is because they tend to cover-up warnings of the same type for my HDL – which sometimes should not be ignored. I hope that Xilinx can someday provide a switch that turns-OFF these “unconnected port” warnings coming from synthesis of IP.

 

Implementation Warning [DRC REQP-1839] RAMB36 async control check….

Implementation Warning [DRC REQP-1840] RAMB18 async control check….

These warnings have lots of text explaining that a BRAM control pin (eg. ENA) is being driven by a register that has an asynchronous set or reset. As explained by @avrumw in <this post>, this warning can be ignored unless you are putting data into the BRAM, toggling the async set/reset, and then expecting the data in the BRAM to be uncorrupted. Some tire of seeing this warning and simply use HDL to tie the control pin high (eg. set ENA=1).  Surprisingly, as shown in <this post> the warning can reappear.  This is because BRAM-power-optimization will (sometimes) boldly ignore your HDL that sets ENA=1 and instead add circuits of its own design to the ENA pin. Sometimes these added circuits connect to registers that have an async set/reset (eg. coming from a reset-bridge which is async-ON, sync-OFF). As explained by @vemulad, you can avoid all these surprises by turning OFF BRAM-power-optimization (go to settings for implementation and select the opt_design directive, NoBramPowerOpt). However, I found that turning OFF BRAM-power-optimization increased the Vivado-reported BRAM power consumption by over 20% in some of my projects.

 

 

OOC-Synthesis + Implementation:

Synthesis Warning [Timing 38-316] Clock period '20.000' specified … is different from the actual clock period…

This warning is about the target-clock-period (ug896, pg41) used by OOC synthesis. This target-clock-period is specified in an OOC XDC constraints file that is automatically-generated when the BRAM IP files are created. The target-clock-period is needed because OOC synthesis is done separately from synthesis for your project and hence the actual clocks in your project are not yet known. As explained by avrumw in <this post> synthesis uses the target-clock-period to make decisions that can help your design achieve timing closure. So ideally, you should manually edit the OOC XDC constraints file and make the target-clock-period equal to the actual-clock-period from your project.   Doing this is not as simple as it sounds and guidance is given by ug896. However,  <this post> shows that the ug896 guidance is not currently working for BRAM and that vemulad has submitted enhancement CR-992544 to correct this. A workaround is described by vemulad that involves managing the IP yourself (rather than letting Vivado manage the IP) – but this was too scary for me to use.

 

Implementation Warning [DRC REQP-1839] RAMB36 async control check….

Implementation Warning [DRC REQP-1840] RAMB18 async control check….

These warning are the same as those that appear during Global-Synthesis + Implementation.

 

 

Final Thoughts:

You’ll note that my pet peeve warnings, [Synth 8-3331], do not appear during OOC-synthesis. Further, as you know, OOC-synthesis saves lots of time if you are often rerunning synthesis for your entire project. So, I mostly use OOC-synthesis for BRAM IP.   However, I kinda feel that the OOC-synthesis warning, [Timing 38-316], should be a critical warning until CR-992544 is implemented. So, for final synthesis+implementation of my projects, I switch to Global-synthesis for BRAM IP. –and leaving BRAM-power-optimization ON.


Accepted Solutions
Xilinx Employee
Posts: 5,894
Registered: ‎08-01-2008

Re: BRAM warnings round-up

yes that should be fine. You can go ahead with global synthesis option. CRs place and it will fix in future release. I have just checked with internal CRS tool. You can ignore the warning for now . It should be fine
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.

View solution in original post


All Replies
Xilinx Employee
Posts: 5,894
Registered: ‎08-01-2008

Re: BRAM warnings round-up

yes that should be fine. You can go ahead with global synthesis option. CRs place and it will fix in future release. I have just checked with internal CRS tool. You can ignore the warning for now . It should be fine
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
Advisor
Posts: 543
Registered: ‎01-22-2015

Re: BRAM warnings round-up

@balkris – thanks for confirmations and comments

 

@kudoers – I’m honored !

 

 

    I hope that Xilinx can someday provide a switch that turns-OFF these “unconnected port” warnings coming from synthesis of IP.

 

Actually, Vivado already has this capability. First, add the “-verbose” option under “Synthesis Settings..”.  Without this option, Vivado will save and display only 100 instances of each warning message type.  Second, read about the “Manage Suppression” dialog box on pg124 of ug893.  Into this dialog box, you simply enter text that is common to all the warning messages you want suppressed.  I found that entering the text, [Synth 8-3331] design blk_mem, caused my pet peeve warnings from BRAM IP to be suppressed  –  and I was left with the [Synth 8-3331] warnings coming from my HDL.  -just what I wanted.  Thanks Xilinx!