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
 Click to see the full signature
Reply to
Martin Euredjian
Loading thread data ...

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

Reply to
Tim

Martin,

Is keep_hierarchy on or off?

Allan.

Reply to
Allan Herriman

Hi Martin,

What kind of SET are you using?

U_SET or HU_SET?

Göran

Mart>So...I have this little module that creates an RLOC'd SRL-based delay pipe

Reply to
Goran Bilski

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.

confirms

one

FF's

an

Reply to
John_H

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:

Reply to
Goran Bilski

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

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

Reply to
Ray Andraka

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

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

Reply to
Ray Andraka

hierarchy

Uset. I

off

to see

multiple

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
 Click to see the full signature
Reply to
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 snipped-for-privacy@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

Reply to
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 snipped-for-privacy@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

Reply to
Martin Euredjian

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.

Reply to
Tim

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 This is the top module. It's simple. I'm using the new attribute syntax to

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

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

Reply to
Ray Andraka

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

Mart>This is the top module. It's simple. I'm using the new attribute syntax to

Reply to
Goran Bilski

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 snipped-for-privacy@pacbell.net where "0_0_0_0_" = "martineu"

to

I

delay

Reply to
Martin Euredjian

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.

  1. 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:
    formatting link

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

Reply to
Allan Herriman

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

formatting link

Brian

Reply to
Brian Davis

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 snipped-for-privacy@andraka.com
formatting link

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

Reply to
Ray Andraka

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:

bunch of

set, it

without

the

applying

for

should

horizontal, in

origin

below).

and

and

itoa(slice

Reply to
Goran Bilski

bunch of

set, it

without

means

the

applying

truely

for

floorplanning should

where

horizontal, in

the origin

below).

strings and

string, and

itoa(slice

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

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

Reply to
Ray Andraka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.