More RPM / RLOC fun

[Martin Euredjian]

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"

 

[Tim]

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?

 

[Allan Herriman]

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.

 

[Goran Bilski]

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...

 

[John_H]

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]

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

 

[Martin Euredjian]

This is the top module. It's simple. I'm using the new attribute syntax to
specify U_SETs. It's nice 'cause you can comment these out if you are
experimenting.

code below.

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

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





module test(
input wire clk,
input wire [9:0] a,
input wire [9:0] b,
output reg [10:0] total
);

wire [9:0] a_dly[1:0];

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

always @(posedge clk) begin
total <= a_dly[0] + a_dly[1];
end

endmodule

 

[Tim]

Martin Euredjian wrote:

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.

Another reason why I try to persuade my customers to buy a
copy of Synplicity. I guess you are using the X tool which
bypasses EDIF. Bummer.

 

[Allan Herriman]

On Tue, 07 Oct 2003 19:39:11 -0400, Ray Andraka <ray@andraka.com>
wrote:

BTW, this is a heckuva lot easier in VHDL with the generate statements. With
VHDL you can convert the generate index variable to a string constant to form
the attribute string. I don't know of a way to do that in verilog. For VHDL,
the code might look like:

L:for i in 0 to width-1 generate
constant rloc_str : string := "R" & itoa( origin -(i/2)) & "C0" & ".S" &
itoa(slice mod 2);
signal l,d,qr,qs: STD_LOGIC;
attribute BEL of U1:label is bel_lut(i mod 2);
attribute RLOC of U1 : label is rloc_str;

Hi Ray,

I've been using Verilog recently. Verilog got a whole lot better
(read: borrowed some features from VHDL) with the 2001 language
revision.

Pertinent bits added:

new attribute syntax.
generate statements.
constant functions (i.e. functions that can run at elaboration time).
$swrite system task.

It would seem that the above VHDL fragment could be translated to
Verilog as follows:

genvar i;
generate
for (i = 0; i < width; i=i+1)
begin
(* RLOC = $swrite("R%dC0.S", origin -(i/2)) *)
(* BEL = i%2 ? "G" : "F" *)

// instantiate something here

end
end generate

But there are still problems:

1. $swrite is a system task, and system tasks can't be used in
constant functions.

2. The (* name = value *) attribute syntax doesn't seem to allow
anything other than integer values. I don't have the Verilog 2001
LRM, so I can't say for sure.
This current comp.lang.verilog thread gives some hints:
http://groups.google.com/groups?threadm=3a8e124e.0310071017.75124189%40posting.google.com

3. This is all new to the Verilog language. Good tool support isn't
there yet. The equivalent features have been in VHDL since the '87
version, so the VHDL tool support is a lot better.
Note: XST 6.1 supports the new attributes but the value must be a
string literal, i.e. it's useless for this sort of work.


It looks like I'll have to wait another few years. Sigh.

Regards,
Allan.

 

[Brian Davis]

"Tim" <tim@rockylogic.com.nooospam.com> wrote in message news:<blvdot$3f4$1$8302bc10@news.demon.co.uk>...

Martin Euredjian wrote:

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.

Another reason why I try to persuade my customers to buy a
copy of Synplicity. I guess you are using the X tool which
bypasses EDIF. Bummer.

I also prefer Synplicity, but you can use NGC2EDIF to look
at the output of XST.

http://www.fpga-faq.com/archives/58175.html#58181

Brian

 

[Goran Bilski]

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]

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

 

[Martin Euredjian]

"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"

 

[Martin Euredjian]

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), .Q15(Q15_OUT), .A3(D[3]), .A2(D[2]), .A1(D[1]),
..A0(D[0]), .CLK(CLK), .D(IN));
FD DFF (.Q (Q_OUT), .C (CLK), .D (qw));
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

 

[Ray Andraka]

Thinking about this some more, I don't think it is a hierarchy problem. That is
usually caught by the mapper complaining there are more than 2 FF/s or LUTs in a
single slice because the flattened netlist RLOCs wind up on top of each other.
I didn't see what device you are using, so the specifics may vary for what I am
going to describe below. The fact that one instance is getting placed properly
tells me the netlist going in has the placement info in it, so that is not
likely the problem either. First, check to make sure you don't have the use
RLOCs property disabled in the xilinx tools. That seems to disable some but not
all RLOCs in a hierarchical design. Assuming that is not disabled, then the
RPMs will get broken up if there is something preventing one or more of the
primitives being placed according to the RLOC.

I think you said these were SRL16's, in which case the two SRL16's packed in one
slice must share clock, and WE. If you are packing a register with the SRL, the
registers in the slice must share CE, and can't use the reset pin. If any of
these restrictions are violated, then it will break up the RPM. Also, if this is
a Spartan 3, the SRL16s must be in an even column. The synthesis may be
duplicating control signals causing different instances of the same signal to
appear on the two SRLs or FFs in the slice. You can control the segmentation of
a high fanout signal by using strategically placed keep buffers in your code
(syn_keep attribute for synplify, don't recall off hand the syntax for xilinx).
Place a buffer on high fanout control signals where they enter the lowest levels
of your hierarchy. It might look something like this:

signal lcl_ce:std_logic;
attribute syn_keep of lcl_ce:signal is true;
attribute RLOC of....

begin
lcl_ce<=ce;

This forces a keep buffer at the entrance to the RPM, which in turn regulates
how the high fanout signal gets broken up. The net result is all the primitives
in the RPM use the same branch of the signal provided the fanout limit is high
enough to accommodate all the instances in your RPM. If you don't have a clock
buffer, the clocks can be broken up too, so make sure your design either has a
clock buffer, or has a high enough fanout limit to keep from breaking up the
clock into a tree.

BTW, this is a heckuva lot easier in VHDL with the generate statements. With
VHDL you can convert the generate index variable to a string constant to form
the attribute string. I don't know of a way to do that in verilog. For VHDL,
the code might look like:

L:for i in 0 to width-1 generate
constant rloc_str : string := "R" & itoa( origin -(i/2)) & "C0" & ".S" &
itoa(slice mod 2);
signal l,d,qr,qs: STD_LOGIC;
attribute BEL of U1:label is bel_lut(i mod 2);
attribute RLOC of U1 : label is rloc_str;



Martin Euredjian wrote:

This is the top module. It's simple. I'm using the new attribute syntax to
specify U_SETs. It's nice 'cause you can comment these out if you are
experimenting.

code below.

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

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

module test(
input wire clk,
input wire [9:0] a,
input wire [9:0] b,
output reg [10:0] total
);

wire [9:0] a_dly[1:0];

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

always @(posedge clk) begin
total <= a_dly[0] + a_dly[1];
end

endmodule

--
--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

 

[Goran Bilski]

Hi Martin,

I'm not fluent in verilog. I prefer VHDL but not let start that thread
again.

When you use U_SET, every primitive within that SET as to have the
attribute U_SET.
You have to assign the U_SET attribute to all SRL16C and FD in the
submodule.

That's why I pass along the U_SET name as a generic in my VHDL code.
When you use H_SET, all primitives within a module belong to the same
SET but for U_SET for have to assign each primitive to the SET.

I have attached a module from MicroBlaze which detect ZERO on one of the
register values.
Here you can see that I pass along a generic called C_U_SET which is of
the type string.
I use that value for the attribute value of U_SET.

When I instanciate the module on a higher level, I assign a unique name
to the generic or giving it a common name if it belongs to a bigger RPM.
The actual values for the RLOC in this module is calculated in the
function which exists in a library. That will allow me to handle all
floorplanning in one place and also handle the difference of the RLOC
values between "XnYm" and "RnCm.S" for different families. That a nice
thing with VHDL.

Göran

--SINGLE_FILE_TAG
-------------------------------------------------------------------------------
-- $Id: zero_detect.vhd,v 1.1 2003/08/06 01:41:23 sid Exp $
-------------------------------------------------------------------------------
-- Zero Detect - entity/architecture
-------------------------------------------------------------------------------
--
-- ****************************
-- ** Copyright Xilinx, Inc. **
-- ** All rights reserved. **
-- ****************************
--
-------------------------------------------------------------------------------
-- Filename: zero_detect.vhd
-- Version: v1.00a
-- Description: Detect if a std_logic_vector signal is zero
--
-------------------------------------------------------------------------------
-- Structure:
-- zero_detect.vhd
-- -- MUXCY_L (Xilinx primitive)
--
-------------------------------------------------------------------------------
-- Author: goran
-- History:
--
-------------------------------------------------------------------------------
-- Naming Conventions:
-- active low signals: "*_n"
-- clock signals: "clk", "clk_div#",
"clk_#x"
-- reset signals: "rst", "rst_n"
-- generics: "C_*"
-- user defined types: "*_TYPE"
-- state machine next state: "*_ns"
-- state machine current state: "*_cs"
-- combinatorial signals: "*_com"
-- pipelined or register delay signals: "*_d#"
-- counter signals: "*cnt*"
-- clock enable signals: "*_ce"
-- internal version of output port "*_i"
-- device pins: "*_pin"
-- ports: - Names begin with
Uppercase
-- processes: "*_PROCESS"
-- component instantiations: "<ENTITY_>I_<#|FUNC
-------------------------------------------------------------------------------

library IEEE;
use IEEE.std_logic_1164.all;

library Microblaze_v2_00_a;
use Microblaze_v2_00_a.MicroBlaze_Types.all;
library Unisim;
use Unisim.all;

-------------------------------------------------------------------------------
-- Port declarations
-------------------------------------------------------------------------------

entity Zero_Detect is
generic (
-- Size generics
C_DATA_SIZE : natural range 4 to 64 := 32;
C_TARGET : TARGET_FAMILY_TYPE := VIRTEX;
C_U_SET : string :=
"zerodetect"
);
port (
-- Zero flag signals
Reg_Test_Equal : in std_logic;
Reg_Test_Equal_N : in std_logic;
EX_Result : in std_logic_vector(0 to C_DATA_SIZE-1);
Reg_zero : out std_logic
);

end entity Zero_Detect;

-------------------------------------------------------------------------------
-- Architecture section
-------------------------------------------------------------------------------

architecture IMP of Zero_Detect is

attribute U_SET : string;
attribute RLOC : string;

component LUT3 is
generic(
INIT : bit_vector := X"00"
);
port (
O : out std_logic;
I0 : in std_logic;
I1 : in std_logic;
I2 : in std_logic);
end component LUT3;

component LUT4 is
generic(
INIT : bit_vector := X"0000"
);
port (
O : out std_logic;
I0 : in std_logic;
I1 : in std_logic;
I2 : in std_logic;
I3 : in std_logic);
end component LUT4;

component MUXCY_L is
port (
DI : in std_logic;
CI : in std_logic;
S : in std_logic;
LO : out std_logic);
end component MUXCY_L;


-------------------------------------------------------------------------------
-- Begin architecture
-------------------------------------------------------------------------------

begin -- IMP


-----------------------------------------------------------------------------
-- Handles Zero flag

-----------------------------------------------------------------------------

-- pragma xilinx_rtl_off
Using_FPGA : if (C_TARGET /= RTL) generate

Using_VII_or_Higher : if (C_TARGET = VIRTEX2) or (C_TARGET =
VIRTEX2PRO) or (C_TARGET = Spartan3) generate
constant NR_OF_NIBBLES : natural := C_DATA_SIZE/4;
signal nibble_Zero :
std_logic_vector(NR_OF_NIBBLES-1 downto 0);
signal zero_CI :
std_logic_vector(NR_OF_NIBBLES downto 0);
signal zero_C : std_logic;
attribute U_SET of Part_Of_Zero_Carry_Start : label is C_U_SET;
attribute RLOC of Part_Of_Zero_Carry_Start : label is
Get_RLOC_Name(Target => C_TARGET,
Y => Get_RLOC_Y(C_TARGET, Zero_Detect_T,
C_DATA_SIZE-1),
X => Get_RLOC_X(C_TARGET, Zero_Detect_T,
C_DATA_SIZE-1));
begin

Part_Of_Zero_Carry_Start : MUXCY_L
port map (
DI => '0', -- [in std_logic]
CI => '1', -- [in std_logic]
S => Reg_test_Equal, -- [in std_logic]
LO => zero_CI(0)); -- [out std_logic]


zero_C <= Reg_Test_Equal_N;

-- Detect Zero
Zero_Detecting : for I in 0 to NR_OF_NIBBLES-1 generate
attribute U_SET of I_Part_Of_Zero_Detect : label is C_U_SET;
attribute RLOC of I_Part_Of_Zero_Detect : label is
Get_RLOC_Name(Target => C_TARGET,
Y => Get_RLOC_Y(C_TARGET, Zero_Detect_T,
C_DATA_SIZE-2-I),
X => Get_RLOC_X(C_TARGET, Zero_Detect_T,
C_DATA_SIZE-2-I));
begin

nibble_Zero(I) <= not (EX_Result(C_DATA_SIZE-4-I*4) or
EX_Result(C_DATA_SIZE-3-I*4) or

EX_Result(C_DATA_SIZE-2-I*4) or EX_Result(C_DATA_SIZE-1-I*4));


I_Part_Of_Zero_Detect : MUXCY_L
port map (
DI => zero_C, -- [in std_logic]
CI => zero_CI(I), -- [in std_logic]
S => nibble_Zero(I), -- [in std_logic]
LO => zero_CI(I+1)); -- [out std_logic]

end generate Zero_Detecting;

Reg_zero <= zero_CI(NR_OF_NIBBLES);
end generate Using_VII_or_Higher;

Using_Virtex_Family : if (C_TARGET = VIRTEX) or (C_TARGET =
VIRTEXE) or
(C_TARGET = SPARTANII) or (C_TARGET =
SPARTANIIE) generate
constant NR_OF_NIBBLES : natural := (C_DATA_SIZE+2)/3;
signal nibble_Zero : std_logic_vector(NR_OF_NIBBLES-1 downto 0);
signal zero_CI : std_logic_vector(NR_OF_NIBBLES downto 0);
signal zero_C : std_logic;
begin

zero_CI(0) <= Reg_Test_Equal;
zero_C <= Reg_Test_Equal_N;

Zero_Detecting : for I in 0 to NR_OF_NIBBLES-1 generate
attribute U_SET of I_Part_Of_Zero_Detect : label is C_U_SET;
attribute RLOC of I_Part_Of_Zero_Detect : label is
Get_RLOC_Name(Target => C_TARGET,
Y => Get_RLOC_Y(C_TARGET, Zero_Detect_T,
C_DATA_SIZE-1-I),
X => Get_RLOC_X(C_TARGET, Zero_Detect_T,
C_DATA_SIZE-1-I));
begin

Not_Last_One : if (I /= (NR_OF_NIBBLES - 1)) generate
nibble_Zero(I) <= not (EX_Result(C_DATA_SIZE-3-I*3) or
EX_Result(C_DATA_SIZE-2-I*3) or
EX_Result(C_DATA_SIZE-1-I*3));
end generate Not_Last_One;

The_Last_One : if (I = (NR_OF_NIBBLES-1)) generate
nibble_Zero(I) <= not (EX_Result(C_DATA_SIZE-2-I*3) or
EX_Result(C_DATA_SIZE-1-I*3));
end generate The_Last_One;

I_Part_Of_Zero_Detect : MUXCY_L
port map (
DI => zero_C, -- [in std_logic]
CI => zero_CI(I), -- [in std_logic]
S => nibble_Zero(I), -- [in std_logic]
LO => zero_CI(I+1)); -- [out std_logic]

end generate Zero_Detecting;

Reg_zero <= zero_CI(NR_OF_NIBBLES);

end generate Using_Virtex_Family;
end generate Using_FPGA;

Using_RTL: if (C_TARGET = RTL) generate
Detect_Zero: process (EX_Result, Reg_Test_Equal, Reg_Test_Equal_N) is
constant Zero : std_logic_vector(EX_Result'range) := (others =
'0');
begin -- process Detect_Zero
if (EX_Result = Zero) then
Reg_zero <= Reg_Test_Equal;
else
Reg_zero <= Reg_Test_Equal_N;
end if;
end process Detect_Zero;

end generate Using_RTL;

end architecture IMP;

Martin Euredjian wrote:

This is the top module. It's simple. I'm using the new attribute syntax to
specify U_SETs. It's nice 'cause you can comment these out if you are
experimenting.

code below.

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

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





module test(
input wire clk,
input wire [9:0] a,
input wire [9:0] b,
output reg [10:0] total
);

wire [9:0] a_dly[1:0];

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

always @(posedge clk) begin
total <= a_dly[0] + a_dly[1];
end

endmodule

 

[Martin Euredjian]

There was an error in the code posted below. I posted the wrong iteration
of code.
The error had nothing to do with the problem (but didn't help).

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

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



"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:axGgb.12589$g_2.8245@newssvr25.news.prodigy.com...

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), .Q15(Q15_OUT), .A3(D[3]), .A2(D[2]), .A1(D[1]),
.A0(D[0]), .CLK(CLK), .D(IN));
FD DFF (.Q (Q_OUT), .C (CLK), .D (qw));
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

 

[Ray Andraka]

Goran,

I can't understand why you are working in flatland. First off, it creates a bunch of

extra typing. If you use H_SETs, there is no need to explicitly declare each set, it

is done automatically for you, and then you can piece together the RLOCs without
having to pass placement information into your lower levels. Using USETs means
you need a unique name for each instance of a macro, plus you need to compute the
offsets for each and manually (in your code) add them to the RLOCs before applying
the RLOCs. With HSETs, that is all done automatically, so each module is truely
standalone. That means with HSETs you can compile parts of the code and then
instance it as a black box in a higher level. I'm not sure of the motivation for
handling
all the floorplanning in one place either. Seems to me that the floorplanning should

be with the module, as your layout normally will be the same regardless of where
you put it. (I do have some with alternative layouts such as swapped horizontal, in
which case I use generics to control the layout. A simple case is whether the origin

is at the top or the bottom of a carry chain, which is illustrated partly below).

I handle the different RLOC strings for RC or XY grids by creating both strings and
then using a pickstring function to select which gets used. Pickstring has an
argument for the family
(0=unplaced, 1= virtex/spartanII, 2=v2, 3=spartan3) plus an RC sting and an XY
string. In the
case of unplaced, it returns the null string. For 1 it returns the RC string, and
for 2 or more the xy string
For example:
constant rc_str : string := "R" & itoa( origin -(i/2)) & "C0" & ".S" & itoa(slice
mod 2);
constant xy_str : string := "x0y" & itoa((i/2)-origin) ;
constant rloc_str : string := pickstring(virtex,rc_str,xy_str);
signal l,d,qr,qs: STD_LOGIC;
attribute BEL of U1:label is bel_lut(i mod 2);
attribute RLOC of U1 : label is rloc_str;


Is there some advantage of doing this flat that has totally escaped me?


--
--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

 

[Goran Bilski]

Hi Ray,

This is the reason I choose U_SET.

1. Not everything in a level might not go to the same SET but with H_SET
EVERYTHING is forced into
the same set.
2. I need very different floorplanning for different architectures.
3. I don't want to have my design hierarchical force to be the floorplan
hierarchical.
I like to divide my design into functional block independent of the
floorplanning.
ex. I have all my register file bits in the same vhdl file even if
they are spread out in the floorplanning
In one of the leafs in a branch of my design, I might need due to
minimizing the routing delay from a primitive
to another primitive in another leaf in a total different branch of
the design.
With H_SET, it a nightmare since I have to know all the relative
placement of all H_SET
from the first leaf to the top and then from the top to the another
leaf.
Whenever I change any of the relative placements, I have to check
all the cross placement to see
if they are effected.
With the U_SET approach and all RLOC values in one function, I just
need to change a value in the function and
the placement is changed.

Göran

Ray Andraka wrote:

Goran,

I can't understand why you are working in flatland. First off, it creates a bunch of

extra typing. If you use H_SETs, there is no need to explicitly declare each set, it

is done automatically for you, and then you can piece together the RLOCs without
having to pass placement information into your lower levels. Using USETs means
you need a unique name for each instance of a macro, plus you need to compute the
offsets for each and manually (in your code) add them to the RLOCs before applying
the RLOCs. With HSETs, that is all done automatically, so each module is truely
standalone. That means with HSETs you can compile parts of the code and then
instance it as a black box in a higher level. I'm not sure of the motivation for
handling
all the floorplanning in one place either. Seems to me that the floorplanning should

be with the module, as your layout normally will be the same regardless of where
you put it. (I do have some with alternative layouts such as swapped horizontal, in
which case I use generics to control the layout. A simple case is whether the origin

is at the top or the bottom of a carry chain, which is illustrated partly below).

I handle the different RLOC strings for RC or XY grids by creating both strings and
then using a pickstring function to select which gets used. Pickstring has an
argument for the family
(0=unplaced, 1= virtex/spartanII, 2=v2, 3=spartan3) plus an RC sting and an XY
string. In the
case of unplaced, it returns the null string. For 1 it returns the RC string, and
for 2 or more the xy string
For example:
constant rc_str : string := "R" & itoa( origin -(i/2)) & "C0" & ".S" & itoa(slice
mod 2);
constant xy_str : string := "x0y" & itoa((i/2)-origin) ;
constant rloc_str : string := pickstring(virtex,rc_str,xy_str);
signal l,d,qr,qs: STD_LOGIC;
attribute BEL of U1:label is bel_lut(i mod 2);
attribute RLOC of U1 : label is rloc_str;


Is there some advantage of doing this flat that has totally escaped me?


--
--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]

I guess to each his own. Seems you have the placement knowledge problem either way if
stuff is being placed somewhat randomly. With HSETs, the hierarchy is hidden whenyou get
to the floorplanner. The RPM gets flattened in the floorplan view and moves as one large
RPM block. When there are two sets in one block, I use HU_sets, but I also avoid doing
that. If that happens, it tells me that I probably have not used hierarchy correctly. My
bottom level entities are simple things like adders, delay queues, registers, etc. The
stuff that does not have a carry chain has generics on it to set the row and column pitch
so that I can set up the layout in a regular array. Where it is not a regular array, I
use smaller instances in the next level up.

Goran Bilski wrote:

Hi Ray,

This is the reason I choose U_SET.

1. Not everything in a level might not go to the same SET but with H_SET
EVERYTHING is forced into
the same set.
2. I need very different floorplanning for different architectures.
3. I don't want to have my design hierarchical force to be the floorplan
hierarchical.
I like to divide my design into functional block independent of the
floorplanning.
ex. I have all my register file bits in the same vhdl file even if
they are spread out in the floorplanning
In one of the leafs in a branch of my design, I might need due to
minimizing the routing delay from a primitive
to another primitive in another leaf in a total different branch of
the design.
With H_SET, it a nightmare since I have to know all the relative
placement of all H_SET
from the first leaf to the top and then from the top to the another
leaf.
Whenever I change any of the relative placements, I have to check
all the cross placement to see
if they are effected.
With the U_SET approach and all RLOC values in one function, I just
need to change a value in the function and
the placement is changed.

Göran

Ray Andraka wrote:

Goran,

I can't understand why you are working in flatland. First off, it creates a bunch of

extra typing. If you use H_SETs, there is no need to explicitly declare each set, it

is done automatically for you, and then you can piece together the RLOCs without
having to pass placement information into your lower levels. Using USETs means
you need a unique name for each instance of a macro, plus you need to compute the
offsets for each and manually (in your code) add them to the RLOCs before applying
the RLOCs. With HSETs, that is all done automatically, so each module is truely
standalone. That means with HSETs you can compile parts of the code and then
instance it as a black box in a higher level. I'm not sure of the motivation for
handling
all the floorplanning in one place either. Seems to me that the floorplanning should

be with the module, as your layout normally will be the same regardless of where
you put it. (I do have some with alternative layouts such as swapped horizontal, in
which case I use generics to control the layout. A simple case is whether the origin

is at the top or the bottom of a carry chain, which is illustrated partly below).

I handle the different RLOC strings for RC or XY grids by creating both strings and
then using a pickstring function to select which gets used. Pickstring has an
argument for the family
(0=unplaced, 1= virtex/spartanII, 2=v2, 3=spartan3) plus an RC sting and an XY
string. In the
case of unplaced, it returns the null string. For 1 it returns the RC string, and
for 2 or more the xy string
For example:
constant rc_str : string := "R" & itoa( origin -(i/2)) & "C0" & ".S" & itoa(slice
mod 2);
constant xy_str : string := "x0y" & itoa((i/2)-origin) ;
constant rloc_str : string := pickstring(virtex,rc_str,xy_str);
signal l,d,qr,qs: STD_LOGIC;
attribute BEL of U1:label is bel_lut(i mod 2);
attribute RLOC of U1 : label is rloc_str;


Is there some advantage of doing this flat that has totally escaped me?


--
--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, 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