More RPM / RLOC fun

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

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

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

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

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.

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

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

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

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