More RPM / RLOC fun

So...I have this little module that creates an RLOC'd SRL-based delay pipe
that will feed one side of an adder in an FIR filter.  Floorplanner confirms
that the RLOCs are working as promised.

However, if I instantiate more than one of these modules, only the first one
is placed per the defined RLOCs and the rest are placed with SRL's and FF's
outside of the required relative locations.  I've looked through every
report and I cannot find any warnings that would indicate that there's a
problem of any kind.

I also wrote and compiled a simplified version of the above to see if
anything changed.  The RLOC'd module consists of eight SRL's feeding eight
FF's, RLOC'd to form a column.  I instantiated two of these to then feed an
8-bit adder that clocks out to 8 FF's.  The layout I got confirms the
problem:  The first module follows the RLOCs and the second does not.

What's interesting is that section 7 of the MAP report lists two RPM's by
their set name (for the last example) but section 13's "Number of RPM
Macros" count is 1.

Not sure where to go from here...



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

Martin Euredjian wrote:
> So...I have this little module that creates an RLOC'd SRL-based delay
> pipe that will feed one side of an adder in an FIR filter.
> Floorplanner confirms that the RLOCs are working as promised.
>
> However, if I instantiate more than one of these modules, only the
> first one is placed per the defined RLOCs and the rest are placed
> with SRL's and FF's outside of the required relative locations.  I've
> looked through every report and I cannot find any warnings that would
> indicate that there's a problem of any kind.

And the EDIF - always a pleasure to read - looks OK?

On Tue, 07 Oct 2003 08:23:15 GMT, "Martin Euredjian"
<0_0_0_0_@pacbell.net> wrote:

>So...I have this little module that creates an RLOC'd SRL-based delay pipe
>that will feed one side of an adder in an FIR filter.  Floorplanner confirms
>that the RLOCs are working as promised.
>
>However, if I instantiate more than one of these modules, only the first one
>is placed per the defined RLOCs and the rest are placed with SRL's and FF's
>outside of the required relative locations.  I've looked through every
>report and I cannot find any warnings that would indicate that there's a
>problem of any kind.
>
>I also wrote and compiled a simplified version of the above to see if
>anything changed.  The RLOC'd module consists of eight SRL's feeding eight
>FF's, RLOC'd to form a column.  I instantiated two of these to then feed an
>8-bit adder that clocks out to 8 FF's.  The layout I got confirms the
>problem:  The first module follows the RLOCs and the second does not.
>
>What's interesting is that section 7 of the MAP report lists two RPM's by
>their set name (for the last example) but section 13's "Number of RPM
>Macros" count is 1.
>
>Not sure where to go from here...

Martin,

Is keep_hierarchy on or off?

Allan.

Hi Martin,

What kind of SET are you using?

U_SET or  HU_SET?

G�ran

Martin Euredjian wrote:

>So...I have this little module that creates an RLOC'd SRL-based delay pipe
>that will feed one side of an adder in an FIR filter.  Floorplanner confirms
>that the RLOCs are working as promised.
>
>However, if I instantiate more than one of these modules, only the first one
>is placed per the defined RLOCs and the rest are placed with SRL's and FF's
>outside of the required relative locations.  I've looked through every
>report and I cannot find any warnings that would indicate that there's a
>problem of any kind.
>
>I also wrote and compiled a simplified version of the above to see if
>anything changed.  The RLOC'd module consists of eight SRL's feeding eight
>FF's, RLOC'd to form a column.  I instantiated two of these to then feed an
>8-bit adder that clocks out to 8 FF's.  The layout I got confirms the
>problem:  The first module follows the RLOCs and the second does not.
>
>What's interesting is that section 7 of the MAP report lists two RPM's by
>their set name (for the last example) but section 13's "Number of RPM
>Macros" count is 1.
>
>Not sure where to go from here...
>
>
>
>  
>

When I specify RLOCs in my UCF file manually, I have to associate a U_SET
for each group to keep the RLOCs associated with the unique U_SET name.  Are
you using unique U_SET names for each instance of your module?  Or are you
using "hierarchical" HU_SETs?  I haven't messed with those myself.

Perhaps someone who regularly does RLOCs in their code can help explain how
to make the groups unique and seperable since my experience hasn't touched
on hierarchical RLOCs.


"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:TJugb.12278$hT5.11925@newssvr25.news.prodigy.com...
> So...I have this little module that creates an RLOC'd SRL-based delay pipe
> that will feed one side of an adder in an FIR filter.  Floorplanner
confirms
> that the RLOCs are working as promised.
>
> However, if I instantiate more than one of these modules, only the first
one
> is placed per the defined RLOCs and the rest are placed with SRL's and
FF's
> outside of the required relative locations.  I've looked through every
> report and I cannot find any warnings that would indicate that there's a
> problem of any kind.
>
> I also wrote and compiled a simplified version of the above to see if
> anything changed.  The RLOC'd module consists of eight SRL's feeding eight
> FF's, RLOC'd to form a column.  I instantiated two of these to then feed
an
> 8-bit adder that clocks out to 8 FF's.  The layout I got confirms the
> problem:  The first module follows the RLOCs and the second does not.
>
> What's interesting is that section 7 of the MAP report lists two RPM's by
> their set name (for the last example) but section 13's "Number of RPM
> Macros" count is 1.
>
> Not sure where to go from here...
>
>
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"
>
>

Hi,

I will try to explain it from my view.
There exists an explanation on the RLOC in the ISE documentation.
Look under RLOC in the constraint guide and you will see how it works.

U_SET (User_SET) names have to be unique in the design and all RLOC 
attributes where ever they are specified in the design hierarchical 
works within the same U_SET name domain.
ex. If you have a top level where you add a primitive to a U_SET (like 
X1Y0) and then in a submodule add another primitive to the same U_SET 
name with the values of (X1Y1) then they will be using the same 
co-ordinate system.

But with HU_SET (Hierarchical User Set) or H_SET the submodule starts 
with a new co-ordinate system for each hierarchical level and so for 
each submodule you have to specify the relation between the level 
co-ordinate system and the submodule system.
This makes it hard to down in a hierarchical design place a primitive 
close to another primitive in another branch of the hierarchical since 
you have to know all the relations of the co-ordinate systems between 
the two primitives.
One difference between H_SET and HU_SET is with HU_SET you can give it a 
name instead of relying of the design hierarchical. The name has to be 
as for the U_SET unique within the design.
Another difference is that with H_SET everything within a level with a 
RLOC is automatically in the set but with HU_SET, you have to manual 
assign the primitives to the SET (ala U_SET).

Another way of looking at it is that U_SET flattens the hierarchical and 
all RLOCs within the same name uses the same co-ordinate system. 
HU_SET/H_SET preserves the hierarchical and each level has it's own 
co-ordinate system.

Personally I only uses U_SET since it will give me one co-ordinate 
system independent where in the design I place something. The U_SET have 
the catch that you can only have one unique name in your design and if 
you want to have multiple instances, you need to name them differently.
I have added a generic of the type string in my VHDL RPMs which the 
module uses as the U_SET name.
For each new instance of the module, I give it a new name.

G�ran

John_H wrote:

>When I specify RLOCs in my UCF file manually, I have to associate a U_SET
>for each group to keep the RLOCs associated with the unique U_SET name.  Are
>you using unique U_SET names for each instance of your module?  Or are you
>using "hierarchical" HU_SETs?  I haven't messed with those myself.
>
>Perhaps someone who regularly does RLOCs in their code can help explain how
>to make the groups unique and seperable since my experience hasn't touched
>on hierarchical RLOCs.
>
>
>"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
>news:TJugb.12278$hT5.11925@newssvr25.news.prodigy.com...
>  
>
>>So...I have this little module that creates an RLOC'd SRL-based delay pipe
>>that will feed one side of an adder in an FIR filter.  Floorplanner
>>    
>>
>confirms
>  
>
>>that the RLOCs are working as promised.
>>
>>However, if I instantiate more than one of these modules, only the first
>>    
>>
>one
>  
>
>>is placed per the defined RLOCs and the rest are placed with SRL's and
>>    
>>
>FF's
>  
>
>>outside of the required relative locations.  I've looked through every
>>report and I cannot find any warnings that would indicate that there's a
>>problem of any kind.
>>
>>I also wrote and compiled a simplified version of the above to see if
>>anything changed.  The RLOC'd module consists of eight SRL's feeding eight
>>FF's, RLOC'd to form a column.  I instantiated two of these to then feed
>>    
>>
>an
>  
>
>>8-bit adder that clocks out to 8 FF's.  The layout I got confirms the
>>problem:  The first module follows the RLOCs and the second does not.
>>
>>What's interesting is that section 7 of the MAP report lists two RPM's by
>>their set name (for the last example) but section 13's "Number of RPM
>>Macros" count is 1.
>>
>>Not sure where to go from here...
>>
>>
>>
>>-- 
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>Martin Euredjian
>>
>>To send private email:
>>0_0_0_0_@pacbell.net
>>where
>>"0_0_0_0_"  =  "martineu"
>>
>>
>>    
>>
>
>
>  
>

Make sure you are preserving the hierarchy, it sounds like either the hierarchy
is being flattened or that you have overlapping RLOCs within the same Uset.  I
generally don't use explicit USETs in my code, as I've had trouble on and off
with the tools properly passing them through.  Look in your edif netlist to see
what it is doing.  You should see one instance of your macro, and then multiple
instantiations of it in the main part of the code.

Martin Euredjian wrote:

> So...I have this little module that creates an RLOC'd SRL-based delay pipe
> that will feed one side of an adder in an FIR filter.  Floorplanner confirms
> that the RLOCs are working as promised.
>
> However, if I instantiate more than one of these modules, only the first one
> is placed per the defined RLOCs and the rest are placed with SRL's and FF's
> outside of the required relative locations.  I've looked through every
> report and I cannot find any warnings that would indicate that there's a
> problem of any kind.
>
> I also wrote and compiled a simplified version of the above to see if
> anything changed.  The RLOC'd module consists of eight SRL's feeding eight
> FF's, RLOC'd to form a column.  I instantiated two of these to then feed an
> 8-bit adder that clocks out to 8 FF's.  The layout I got confirms the
> problem:  The first module follows the RLOCs and the second does not.
>
> What's interesting is that section 7 of the MAP report lists two RPM's by
> their set name (for the last example) but section 13's "Number of RPM
> Macros" count is 1.
>
> Not sure where to go from here...
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

I prefer the default H_sets, as that allows me to build up a larger macro from my
library of smaller pieces so that individual piece just need an RLOC when they
get instantiated to put them in their place.  Leave off the RLOC, and it becomes
a placed macro that can be moved around relative to other placed macros.  The
caution is that you must not let the tools flatten the design.

Goran Bilski wrote:

> Hi,
>
> I will try to explain it from my view.
> There exists an explanation on the RLOC in the ISE documentation.
> Look under RLOC in the constraint guide and you will see how it works.
>
> U_SET (User_SET) names have to be unique in the design and all RLOC
> attributes where ever they are specified in the design hierarchical
> works within the same U_SET name domain.
> ex. If you have a top level where you add a primitive to a U_SET (like
> X1Y0) and then in a submodule add another primitive to the same U_SET
> name with the values of (X1Y1) then they will be using the same
> co-ordinate system.
>
> But with HU_SET (Hierarchical User Set) or H_SET the submodule starts
> with a new co-ordinate system for each hierarchical level and so for
> each submodule you have to specify the relation between the level
> co-ordinate system and the submodule system.
> This makes it hard to down in a hierarchical design place a primitive
> close to another primitive in another branch of the hierarchical since
> you have to know all the relations of the co-ordinate systems between
> the two primitives.
> One difference between H_SET and HU_SET is with HU_SET you can give it a
> name instead of relying of the design hierarchical. The name has to be
> as for the U_SET unique within the design.
> Another difference is that with H_SET everything within a level with a
> RLOC is automatically in the set but with HU_SET, you have to manual
> assign the primitives to the SET (ala U_SET).
>
> Another way of looking at it is that U_SET flattens the hierarchical and
> all RLOCs within the same name uses the same co-ordinate system.
> HU_SET/H_SET preserves the hierarchical and each level has it's own
> co-ordinate system.
>
> Personally I only uses U_SET since it will give me one co-ordinate
> system independent where in the design I place something. The U_SET have
> the catch that you can only have one unique name in your design and if
> you want to have multiple instances, you need to name them differently.
> I have added a generic of the type string in my VHDL RPMs which the
> module uses as the U_SET name.
> For each new instance of the module, I give it a new name.
>
> G�ran
>
> John_H wrote:
>
> >When I specify RLOCs in my UCF file manually, I have to associate a U_SET
> >for each group to keep the RLOCs associated with the unique U_SET name.  Are
> >you using unique U_SET names for each instance of your module?  Or are you
> >using "hierarchical" HU_SETs?  I haven't messed with those myself.
> >
> >Perhaps someone who regularly does RLOCs in their code can help explain how
> >to make the groups unique and seperable since my experience hasn't touched
> >on hierarchical RLOCs.
> >
> >
> >"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
> >news:TJugb.12278$hT5.11925@newssvr25.news.prodigy.com...
> >
> >
> >>So...I have this little module that creates an RLOC'd SRL-based delay pipe
> >>that will feed one side of an adder in an FIR filter.  Floorplanner
> >>
> >>
> >confirms
> >
> >
> >>that the RLOCs are working as promised.
> >>
> >>However, if I instantiate more than one of these modules, only the first
> >>
> >>
> >one
> >
> >
> >>is placed per the defined RLOCs and the rest are placed with SRL's and
> >>
> >>
> >FF's
> >
> >
> >>outside of the required relative locations.  I've looked through every
> >>report and I cannot find any warnings that would indicate that there's a
> >>problem of any kind.
> >>
> >>I also wrote and compiled a simplified version of the above to see if
> >>anything changed.  The RLOC'd module consists of eight SRL's feeding eight
> >>FF's, RLOC'd to form a column.  I instantiated two of these to then feed
> >>
> >>
> >an
> >
> >
> >>8-bit adder that clocks out to 8 FF's.  The layout I got confirms the
> >>problem:  The first module follows the RLOCs and the second does not.
> >>
> >>What's interesting is that section 7 of the MAP report lists two RPM's by
> >>their set name (for the last example) but section 13's "Number of RPM
> >>Macros" count is 1.
> >>
> >>Not sure where to go from here...
> >>
> >>
> >>
> >>--
> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>Martin Euredjian
> >>
> >>To send private email:
> >>0_0_0_0_@pacbell.net
> >>where
> >>"0_0_0_0_"  =  "martineu"
> >>
> >>
> >>
> >>
> >
> >
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

"Ray Andraka" wrote:

> Make sure you are preserving the hierarchy, it sounds like either the
hierarchy
> is being flattened or that you have overlapping RLOCs within the same
Uset.  I
> generally don't use explicit USETs in my code, as I've had trouble on and
off
> with the tools properly passing them through.  Look in your edif netlist
to see
> what it is doing.  You should see one instance of your macro, and then
multiple
> instantiations of it in the main part of the code.


Lot's of interesting replies.  I'll lump my responses here.

Yes, I tried all combinations of U_SET and HU_SET with unique names for each
instantiated module.  An example:

(* HU_SET = "DLY00" *)
SRL_DLY #(.WIDTH(10), .DELAY( 2)) DLY00(.CLK(clk), .IN(a), .Q_OUT(a_dly[0]),
.Q15_OUT());
(* HU_SET = "DLY01" *)
SRL_DLY #(.WIDTH(10), .DELAY( 4)) DLY01(.CLK(clk), .IN(a), .Q_OUT(a_dly[1]),
.Q15_OUT());

I also tried assigning U/HU_SET inside the "SRL_DLY" module using "generate"
to actually attach every generated entity to the corresponding set.  This
didn't work.

Setting "Keep Hierarchy" to "Yes" did not fix the problem.  I tried this
with unique U_SET and HU_SET attributes as well as without any sets defined.
Nothing seemed to make a difference.

At the risk of sounding stupid.  I can't find an EDIF (old ".edn")file
anywhere and NGD2EDIF doesn't seem to be supported any more (running 6.1i).
Where do I look?  I used NGD2VER to create a simulation model.  It clearly
shows one instance of the macro and two instantiations.  However, all
placement info is gone, as this is a simulation model.

Some have mentioned the specification of RLOCs in the UCF file.  All of my
RLOCs are defined in the HDL file for the module in question.  That way the
module is easily reusable in other projects and you can build more complex
circuits with placement already defined at various levels of the hierarchy.
I'm just getting into this (as most can tell).  I don't like the UCF
approach.  It's not portable at all.  If you wanted to move modules to
another design it would be a very ugly cut and paste session.

Someone mentioned that the Constraints Guide has an explanation of RLOCs.
Just know that before I decide to post anything on a newsgroup I try to
exhaust all possible sources to the point of frustration.  I spent all day
(defined as >12 hours) yesterday reading just about anything you could find
about RPMs, RLOCs, H/U/HU_SETS and related subjects in the online manuals,
Google, techXclusives, app notes, answer database, etc.  I posted my message
at 1:30AM, when I finally threw my hands up.  In other words, the newsgroup
is not a replacement for doing the necesary work, it's a resource that I
think most should (and do) use after they've exhausted all other
possibilities.  That simply out of respect to those who've put in years of
work to be able to solve your problem in five minutes.

The RLOC section of the Constraints Guide does a good job of treating RLOCs
in isolation, but if fails to connect the greater subject of RPM's and,
perhaps, their use in floorplanning.  The heading, for example, does not
even mention the finer-grain control you can have by using the BEL attribute
(thanks Ray!).  It also deals with RLOCs in isolation of HDL (other than
offering HDL syntax), hence my current endevour to re-invent of the wheel.
Another area not mentioned (appropriately, as it is a separate subject) is
that of the various considerations or consequences of choosing a particular
BEL with respect to how it affects routing (switch box) and general
connectivity to other parts of your design.  In other words, a nice column
of logic might not be the best way to lay something out if you need to route
in/out of block RAM, etc.

I'll post the code in a separate message to keep this one short.

Thanks,

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

This is the module with the RLOCs.
I'm just hacking away here, so it's not perfect code.
The long list of RLOC/BEL attributes is there because I haven't been able to
figure out how to integrate that into the "generate" portion of the code.  I
don't see a way to construct the attribute string --even with the V2001
(*...*) attribute format.  Yet another case for VHDL :-(

Code below.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"




// Generates an SRL-based shift register of the desired word width and delay
(in clocks)
// A minimum delay of 2 clocks is required, as the output is registered.
// "Q15_OUT" is the cascading SRL output, used to get 16 clocks of delay,
regardless
// of the DELAY setting.
//

module SRL_DLY
#(parameter WIDTH = 8, DELAY = 2)
(
   input   wire  CLK,
   input   wire [WIDTH - 1:0] IN,
   output  wire [WIDTH - 1:0] Q_OUT,
   output  wire [WIDTH - 1:0] Q15_OUT
);

localparam D = DELAY - 2;

wire [WIDTH - 1:0] qw;

genvar i;

generate
for(i=0; i < WIDTH; i=i+1) begin:BIT
 SRLC16 SRL(.Q(qw[i]), .Q15(Q15_OUT[i]), .A3(D[3]), .A2(D[2]), .A1(D[1]),
.A0(D[0]), .CLK(CLK), .D(IN[i]));
 FD DFF (.Q (Q_OUT[i]), .C (CLK), .D (qw[i]));
end
endgenerate

// RLOC the SRLC16 primitives
//
//synthesis attribute RLOC of BIT[0].SRL  is X0Y0
//synthesis attribute BEL  of BIT[0].SRL  is F
//synthesis attribute RLOC of BIT[1].SRL  is X0Y0
//synthesis attribute BEL  of BIT[1].SRL  is G

//synthesis attribute RLOC of BIT[2].SRL  is X0Y1
//synthesis attribute BEL  of BIT[2].SRL  is F
//synthesis attribute RLOC of BIT[3].SRL  is X0Y1
//synthesis attribute BEL  of BIT[3].SRL  is G

//synthesis attribute RLOC of BIT[4].SRL  is X0Y2
//synthesis attribute BEL  of BIT[4].SRL  is F
//synthesis attribute RLOC of BIT[5].SRL  is X0Y2
//synthesis attribute BEL  of BIT[5].SRL  is G

//synthesis attribute RLOC of BIT[6].SRL  is X0Y3
//synthesis attribute BEL  of BIT[6].SRL  is F
//synthesis attribute RLOC of BIT[7].SRL  is X0Y3
//synthesis attribute BEL  of BIT[7].SRL  is G

//synthesis attribute RLOC of BIT[8].SRL  is X0Y4
//synthesis attribute BEL  of BIT[8].SRL  is F
//synthesis attribute RLOC of BIT[9].SRL  is X0Y4
//synthesis attribute BEL  of BIT[9].SRL  is G

//synthesis attribute RLOC of BIT[10].SRL is X0Y5
//synthesis attribute BEL  of BIT[10].SRL  is F
//synthesis attribute RLOC of BIT[11].SRL is X0Y5
//synthesis attribute BEL  of BIT[11].SRL  is G

//synthesis attribute RLOC of BIT[12].SRL is X0Y6
//synthesis attribute BEL  of BIT[12].SRL  is F
//synthesis attribute RLOC of BIT[13].SRL is X0Y6
//synthesis attribute BEL  of BIT[13].SRL  is G

//synthesis attribute RLOC of BIT[14].SRL is X0Y7
//synthesis attribute BEL  of BIT[14].SRL  is F
//synthesis attribute RLOC of BIT[15].SRL is X0Y7
//synthesis attribute BEL  of BIT[15].SRL  is G


// RLOC the FF's
//
//synthesis attribute RLOC of DFF[0] is X0Y0
//synthesis attribute BEL  of DFF[0] is FFX
//synthesis attribute RLOC of DFF[1] is X0Y0
//synthesis attribute BEL  of DFF[1] is FFY

//synthesis attribute RLOC of DFF[2] is X0Y1
//synthesis attribute BEL  of DFF[2] is FFX
//synthesis attribute RLOC of DFF[3] is X0Y1
//synthesis attribute BEL  of DFF[3] is FFY

//synthesis attribute RLOC of DFF[4] is X0Y2
//synthesis attribute BEL  of DFF[4] is FFX
//synthesis attribute RLOC of DFF[5] is X0Y2
//synthesis attribute BEL  of DFF[5] is FFY

//synthesis attribute RLOC of DFF[6] is X0Y3
//synthesis attribute BEL  of DFF[6] is FFX
//synthesis attribute RLOC of DFF[7] is X0Y3
//synthesis attribute BEL  of DFF[7] is FFY

//synthesis attribute RLOC of DFF[8] is X0Y4
//synthesis attribute BEL  of DFF[8] is FFX
//synthesis attribute RLOC of DFF[9] is X0Y4
//synthesis attribute BEL  of DFF[9] is FFY

//synthesis attribute RLOC of DFF[10] is X0Y5
//synthesis attribute BEL  of DFF[10] is FFX
//synthesis attribute RLOC of DFF[11] is X0Y5
//synthesis attribute BEL  of DFF[11] is FFY

//synthesis attribute RLOC of DFF[12] is X0Y6
//synthesis attribute BEL  of DFF[12] is FFX
//synthesis attribute RLOC of DFF[13] is X0Y6
//synthesis attribute BEL  of DFF[13] is FFY

//synthesis attribute RLOC of DFF[14] is X0Y7
//synthesis attribute BEL  of DFF[14] is FFX
//synthesis attribute RLOC of DFF[15] is X0Y7
//synthesis attribute BEL  of DFF[15] is FFY


endmodule