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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant carwer
Participant
7,461 Views
Registered: ‎12-05-2010

RLOC on inferred logic

Hi,

 

I'm experiencing some odd behavior with RLOCs.

 

First: I need to specify the RLOC's in the VHDL code rather than in the UCF file. Partly because I'll be using them on units that will be replicated a large number of times.

 

I don't find much examples for RLOCs at all when searching the web. A main question of mine is whether RLOCs can be attached only to instantiated units or also to inferred logic. I believe the latter is true, based on having read the following in "Xilinx Constraints Guide" (cgd):

 

"In the Unified Libraries, you can use RLOC constraints with BUFT- and CLB-related
primitives, that is, FMAP. *You can also use them on non-primitive macro symbols.*"

(my emphasis)

 

"RLOC Propagation Rules
RLOC is a design element constraint and any attachment to a net is illegal. When attached
to a design element, RLOC propagates to all applicable elements in the hierarchy within
the design element."

 

I wish to do what is described by the last paragraph. I have found few examples on RLOCs on inferred logic, but several on primitives. Describing all my logic where I need the RLOCs in terms of primitives would be a huge work so my hope is to be able to RLOC on inferred logic.

 

In the following example, the RLOC on the instantiated FDCE works fine but not the one on the inferred dff:

 

entity dff is
	port(clk, d: in std_logic; q1, q2: out std_logic);
end dff;
architecture arch of dff is
	attribute rloc: string;
	attribute rloc of dff_inst1: label is "X0Y0";
attribute rloc of dff_inst2: label is "X0Y0";
begin
-- the RLOC for this one doesn't work: dff_inst1: process(clk) begin if rising_edge(clk) then q1 <= d; end if; end process;
-- but the RLOC for this one works fine: dff_inst2 : FDCE generic map ( INIT => '0') -- Initial value of register ('0' or '1') port map ( Q => q2, -- Data output C => clk, -- Clock input CE => '1', -- Clock enable input CLR => '0', -- Asynchronous clear input D => d -- Data input ); end arch;

 

I don't get any warning in MAP but the Flip-Flop from dff_inst1 (translated to a DF), when I inspect it in PlanAhead after PAR, isn't placed according to its RLOC. I can't understand why.

 

 

My question could end here, but to complicate things, I have actually found one example of RLOC on inferred logic which also does work when I implement it. It is an example on some Xilinx webpage:

http://www.xilinx.com/itp/xilinx8/books/data/docs/xst/xst0044_6.html

(at the bottom)

 

...and the code looks like this:

 

architecture beh of inits_rlocs_3 is
    signal tmp: std_logic_vector(3 downto 0):="1011";
    attribute RLOC: string;
    attribute RLOC of tmp: signal is "X3Y0 X2Y0 X1Y0 X0Y0";
begin

    process (CLK)
    begin
        if (clk'event and clk='1') then
            tmp <= DI;
        end if;
    end process;

    DO <= tmp;

end beh;

 

I have implemented this and it works fine - no warnings, an the RLOCs are accounted for and the dff is placed as described by the RLOC.

 

I just can't really understand why it works, it shouldn't. One of my quotes above from cgd reads "RLOC is a design element constraint and any attachment to a net is illegal". And the cgd gives the VHDL attribute syntax as:

 

attribute rloc of {component_name|entity_name|label_name}:
{component|entity|label} is “[element]XmYn[.extension]”;

 

...again, offering a label as something an RLOC attribute can be assigned to, but *not* including 'signal' which is actually used above, and apparently works.

 

What the cgd describes, I can't get to work, but what it forbids somehow seems to work anyway.

 

Can someone clear things out for me?

 

Thanks,

Carl

0 Kudos
5 Replies
Instructor
Instructor
7,455 Views
Registered: ‎08-14-2007

Re: RLOC on inferred logic

I think the confusion is on the definition of a "net" as opposed to a "signal."  When you

infer a flip-flop, the instance of the flop itself is named after the signal it drives.  You have

tried to attach the RLOC to the name of the process, instead.  I think in the first case

you could have placed the RLOC on signal q1.  Basically what you want is an "instance"

name, which is generated by the synthesizer with rules based on the hierarchy and

signal names.  I've generally been confused by the naming conventions myself.

 

-- Gabor

-- Gabor
Participant carwer
Participant
7,432 Views
Registered: ‎12-05-2010

Re: RLOC on inferred logic

Oh, I see, yes, that might be it. Thanks for the comments.

 

Still a bit odd though that the Constraints Guide give the syntax as:

attribute rloc of {component_name|entity_name|label_name}:
{component|entity|label} is “[element]XmYn[.extension]”;

 

and still,

attribute RLOC of tmp: signal is "X3Y0 X2Y0 X1Y0 X0Y0";

is

1.) taken from a Xilinx web page,

2.) not allowed according to the constraints guide,

3.) *actually working* with the tools, and moreover

4.) the *only* way, it seems, to actually attach the RLOC to the register

0 Kudos
Instructor
Instructor
7,429 Views
Registered: ‎08-14-2007

Re: RLOC on inferred logic

Of all the online documentation for ISE, I find the Constraints Guide the most confusing.  The

syntax descriptions are always given symbolically where a few actual examples would be much more

helpful.  The concepts are hard enough to grasp without trying to figure out how to translate the

symbolic syntax into a working example.

 

It also doesn't help that the constructs mentioned in the guide are taken mostly from an

already-translated (synthesized) netlist and don't neatly map into the source language

constructs.

 

After synthesis, you have "instances" of hardware components such as LUTs and Flip-Flops,

and "nets" that connect them.  The names of the instances are derived from the source

names, but the translation is not simple when components are infered rather than

instantiated.  In the case of your named process containing the description of a single

flip-flop, you might think that the component name would be taken from the process,

while in fact it comes from the signal name, possibly following the process name as a

hierarchy level.  This makes sense when you realise that a typical process can describe

a number of flip-flops or other components.

 

Note that a "component" after translation is very different from a VHDL "component."  This

of course lends to more confusion when the Constraints guide does not make clear the

context of the syntax.  Generally constraints that are specific to a source language are

described in the XST manual rather than the Constraints Guide.

 

Regards,

Gabor

-- Gabor
Xilinx Employee
Xilinx Employee
7,417 Views
Registered: ‎07-01-2008

Re: RLOC on inferred logic

"After synthesis, you have "instances" of hardware components such as LUTs and Flip-Flops, and "nets" that connect them."

 

Just a minor clarification, the post synthesis netlist is still a logical netlist. It isn't until the post map netlist (.ncd) that you have physical components and the name changes again and is derrived from an output net name. And I'm not just talking about slice names here. For example, if the placer prints a message with a FF name in it, it will use the component name derived from the output net name.

 

For the implementation tools,  the RLOC constraints need to be on the logical instance. The question here of how to get the synthesis tool to apply these constraints to the logical instances in the NGC file should be directed to the synthesis forum.

 

 

0 Kudos
Participant carwer
Participant
6,730 Views
Registered: ‎12-05-2010

Re: RLOC on inferred logic

I wrote a post on this, for my own reference. If anyone reading this thread is looking for the solution I used, check the post.

 

http://www.fpga-dev.com/rloc-attributes-on-inferred-logic/

 

Cheers

Tags (1)