cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Voyager
Voyager
11,822 Views
Registered: ‎06-24-2013

RLOC wrong or just ignored during placement?

Jump to solution

I wrote a simple test code (attached) which instantiates seven LUTs, three explicitely and four via generate.

 

They all get assigned RLOCs, three explicitely and the four computed.

 

I added a small procedure to the tcl script to list name, rloc and loc for interesting cells, and I'm using this function after synthesis, optimization and placement. The output looks like this:

 

  GEN_LUT2[0].LUT2_inst            X0Y0    
  GEN_LUT2[1].LUT2_inst            X0Y1    
  GEN_LUT2[2].LUT2_inst            X0Y2    
  GEN_LUT2[3].LUT2_inst            X0Y3    
  LUT3_X0_inst                     X0Y0    
  LUT3_X1_inst                     X1Y0    
  LUT3_X2_inst                     X2Y0    

  GEN_LUT2[1].LUT2_inst            X0Y1     SLICE_X43Y3
  GEN_LUT2[2].LUT2_inst            X0Y2     SLICE_X42Y5
  GEN_LUT2[3].LUT2_inst            X0Y3     SLICE_X43Y5
  LUT3_X0_inst                     X0Y0     SLICE_X43Y5
  LUT3_X1_inst                     X1Y0     SLICE_X43Y5
  LUT3_X2_inst                     X2Y0     SLICE_X43Y5

So, obviously the correct RLOC attributes got assigned, and they are present throughout synthesis and implementation. But unfortunately, the placer does not seem to care much about them.

 

Maybe I'm missing the obvious here, or the RLOC syntax is wrong for Vivado 2014.1 or some magic option is missing.

 

As usual, any input on topic is very much appreciated!

 

Thanks in advance,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Reply
1 Solution

Accepted Solutions
Scholar
Scholar
14,098 Views
Registered: ‎07-01-2008

Neither CR was scheduled to be fixed in 2014.2. 798591 is scheduled for 2014.4 and 798592 has been closed as verified in 2014.3. I think both issues are related to the LUT optimization and so you can avoid the bugs by applying dont_touch attributes to the LUTs to block the optimization.

View solution in original post

0 Kudos
Reply
16 Replies
Scholar
Scholar
11,801 Views
Registered: ‎07-01-2008

Are these cells all in the same hierarchy? If not you need to use a U_SET constraint to tie them together.

0 Kudos
Reply
Voyager
Voyager
11,782 Views
Registered: ‎06-24-2013

Yes, they are, as there is only one hierarchy in this example, but to rule this out, attached is a modified version which uses two U_SETs, one for the three horizontal LUTs and another one for the four vertical LUTs. Not that it would change anything in the placement.

 

  GEN_LUT2[0].LUT2_inst            foo      X0Y0    
  GEN_LUT2[1].LUT2_inst            foo      X0Y1    
  GEN_LUT2[2].LUT2_inst            foo      X0Y2    
  GEN_LUT2[3].LUT2_inst            foo      X0Y3    
  LUT3_X0_inst                     bar      X0Y0    
  LUT3_X1_inst                     bar      X1Y0    
  LUT3_X2_inst                     bar      X2Y0    

  GEN_LUT2[1].LUT2_inst            foo      X0Y1     SLICE_X43Y3
  GEN_LUT2[2].LUT2_inst            foo      X0Y2     SLICE_X42Y5
  GEN_LUT2[3].LUT2_inst            foo      X0Y3     SLICE_X43Y5
  LUT3_X0_inst                     bar      X0Y0     SLICE_X43Y5
  LUT3_X1_inst                     bar      X1Y0     SLICE_X43Y5
  LUT3_X2_inst                     bar      X2Y0     SLICE_X43Y5

Thanks,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Reply
Xilinx Employee
Xilinx Employee
11,776 Views
Registered: ‎09-20-2012

Hi,

 

It looks like there is some problem with generate statement.

 

When I removed the generate statement, I see that LUT3_X0_inst LUT3_X1_inst LUT3_X2_inst are placed according to the RLOC constraints given.

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Reply
Xilinx Employee
Xilinx Employee
11,775 Views
Registered: ‎09-20-2012

To add,

 

The same design, if I remove the generate loop and apply the RLOC constraints as below , the RLOC constraints are obeyed. I will attach the modified code here.

 

attribute RLOC of LUT3_X0_inst : label is "X0Y0";
attribute RLOC of LUT3_X1_inst : label is "X1Y0";
attribute RLOC of LUT3_X2_inst : label is "X2Y0";
attribute RLOC of LUT2_inst1 : label is "X0Y0";
attribute RLOC of LUT2_inst2 : label is "X0Y1";
attribute RLOC of LUT2_inst3 : label is "X0Y2";
attribute RLOC of LUT2_inst4 : label is "X0Y3";

 

Replace the INIT values of LUT2 instances with correct values.

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Reply
Voyager
Voyager
11,767 Views
Registered: ‎06-24-2013

Nope, it's not the generate statement (see attached example with unrolled generate :)

 

LUT2_inst1                                X0Y1     SLICE_X43Y3
LUT2_inst2                                X0Y2     SLICE_X42Y5
LUT2_inst3                                X0Y3     SLICE_X43Y5
LUT3_X0_inst                              X0Y0     SLICE_X43Y5
LUT3_X1_inst                              X1Y0     SLICE_X43Y5
LUT3_X2_inst                              X2Y0     SLICE_X43Y5

Best,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Reply
Scholar
Scholar
11,758 Views
Registered: ‎07-01-2008

This is very odd. I can see that the shape is being created (using an internal command) but the placer ignores it:

 

(SLICE_X0Y0, SLICEM)     LUT3_X0_inst (LUT3)

(SLICE_X0Y1, SLICEM)     LUT2_inst1 (LUT2)

(SLICE_X0Y2, SLICEM)     LUT2_inst2 (LUT2)

(SLICE_X1Y0, SLICEM)     LUT3_X1_inst (LUT3)

(SLICE_X2Y0, SLICEM)     LUT3_X2_inst (LUT3)

Tag(s): RLOC

WxH: 3x3

 

I'll be filing a CR for this tomorrow.

Bret

0 Kudos
Reply
Scholar
Scholar
11,745 Views
Registered: ‎07-01-2008

I see what's going on here now and think there are two bugs. If you skip the optimization phase and run place_design on the synthesized design the RPM gets placed correctly. When optimization is run two of the LUTs are being optimized (one entirely, one partially) and this is causing the shape to be broken (bug1) and also one of the LUT2s is being optimized to a LUT1 and its RLOC value is being dropped (bug2). I believe the modified LUTs should maintain the constraints of the original and the Shape Builder should maintain the remnents of the shape post-optimization.

0 Kudos
Reply
Scholar
Scholar
11,742 Views
Registered: ‎07-01-2008

CRs 798591 and 798592 filed for these RPM macro issues. For the shape issue I'm seeing some sporadic behavior where one run succeeds and another fails based on changes that should make a difference. Running place from a DCP works but running the project flow fails. This seems like a corruption problem with the shape database.

Tags (1)
Voyager
Voyager
11,484 Views
Registered: ‎06-24-2013

Just verified, the issue is still present in Vivado 2014.2.

 

Best,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Reply
Scholar
Scholar
14,099 Views
Registered: ‎07-01-2008

Neither CR was scheduled to be fixed in 2014.2. 798591 is scheduled for 2014.4 and 798592 has been closed as verified in 2014.3. I think both issues are related to the LUT optimization and so you can avoid the bugs by applying dont_touch attributes to the LUTs to block the optimization.

View solution in original post

0 Kudos
Reply
Voyager
Voyager
8,232 Views
Registered: ‎06-24-2013

Okay, thanks for the info and the solution.

I can confirm, adding DONT_TOUCH to the LUTs works around the issue.

 

Thanks,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Reply
Anonymous
Not applicable
8,071 Views
Herbert, I have downloaded your test project and plan to port it to verilog and try it out tomorrow; I have a pretty complicated project (Verilog) and am encountering the same problems.

I have added DONT_TOUCH in multiple locations to my verilog design and the problem persists. So I'm going to backup and start with your project and convert it to verilog and see if the same conditions exist, and then if the same DONT_TOUCH attribute corrects the problem. I will report back here with my findings.

I am also using Vivado 2014.2.

cheers,
..dane
0 Kudos
Reply
Contributor
Contributor
6,969 Views
Registered: ‎05-05-2015

Hello,

 

It seems that this problem still exists in VIvado 2014.4 (latest version) ?

 

My RLOC constratints are present after synthesis but ignore during placement.

 

I have been experimenting with the simple top.vhd provided as an example here and add dont_touch and u_set as in the attachment but the placed design does not follow the RLOC constraints.

 

Any ideas please ?

 

0 Kudos
Reply
Contributor
Contributor
6,944 Views
Registered: ‎05-05-2015

I have now installed 2015.1 Vivado and the behaviour of RLOC is not consistent at all.

 

I managed to implement the IP by itself using the RLOC and they were taken into account but once I added the IP to a more complex design the RLOC were ignored and the logic went to random positions.

 

In the attachements you can see that the RLOC have been recognised correctly and that the same SET is used for components mff and sff but the final placements are not what RLOC is saying.

 

I have added dont_touch to all the components etc so that cannot be the problem.

 

These constraints were working correctly with ISE and Planahead.

 

Thanks,

 

 

 

Screenshot1.png
Screenshot2.png
0 Kudos
Reply
Scholar
Scholar
6,887 Views
Registered: ‎07-01-2008

The fix for CR 798591 mentioned above has slipped to 2015.3 and so is not yet fixed in the current tools. What happens is that for example if a LUT3 has an RLOC property and is optimized to a LUT2, the RLOC property is dropped and so the resulting shape is missing some intended logic. The work around is to block the optimization by applying a dont_touch property to the LUT3.

 

Bret

0 Kudos
Reply
Anonymous
Not applicable
6,868 Views

For what it's worth for the benefit of others, after much heartache (and customer deadlines), we abandoned the RLOC appoach completely in Vivado (or in this cast, Vivadon't ), and I spent a few weeks learning TCL from scratch and now have all our placement moved out of HDL and into a TCL script.  It took a lot of effort, but so far (knock, knock) this seems to be working.

 

cheers,

..dane

0 Kudos
Reply