UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor jbradach
Visitor
8,623 Views
Registered: ‎03-04-2012

"Constraint cannot be distributed... do not contain or drive any instances of correct type" problem

I'm workin on a design on a Digilent Spartan-3E starter board and am attempting to add debounce logic to the buttons and switches.  Whenever I add the debouncer logic to the design, I get the following warning, which results in the location constraints for the pin in question being removed from my design:


WARNING:ConstraintSystem:119 - Constraint <NET "db_reset_i/clean" IOSTANDARD =
   "LVCMOS33">: This constraint cannot be distributed from the design objects
   matching 'NET: UniqueName: /soc_top/EXPANDED/db_reset_i\/clean' because those
   design objects do not contain or drive any instances of the correct type.
WARNING:ConstraintSystem:119 - Constraint <NET "db_reset_i/clean" LOC = K17>:
   This constraint cannot be distributed from the design objects matching 'NET:
   UniqueName: /soc_top/EXPANDED/db_reset_i\/clean' because those design objects
   do not contain or drive any instances of the correct type.
WARNING:ConstraintSystem - A target design object for the Locate constraint
   '<NET "db_reset_i/clean" LOC = K17>' could not be found and so the Locate
   constraint will be removed.

 

The debouncer module is instantiated in the top-level wrapper (pasted after the signature) and looks like this:

 

module debouncer_1bit (clk, noisy, clean);
    input   clk;
    input   noisy;
    output  clean;

    reg [19:0] count = 0;
    reg tmp = 0;
    reg clean = 0;

   always @(posedge clk)
   begin
       count <= count + 1;
       tmp <= noisy;
       if (count == 0)
           clean <= tmp;
   end
endmodule

 

Oddly, when I add the instantiations to the top-level wrapper, I have to also explicitly specify a BUFFER_TYPE = IBUF constraint on the clock pin, otherwise it gets a similar "does not drive any instances of the correct type" message and removed.  I tried doing the same for the other inputs, but it didn't make a difference in those cases.  Any help would be greatly appreciated.

 

Thanks!

 

- Jack

 

 

 

//-----------------------------------------------------------------------------
// soc_top.v
//-----------------------------------------------------------------------------

module soc_top
  (
    fpga_0_RS232_DCE_RX_pin,
    fpga_0_RS232_DCE_TX_pin,
    fpga_0_LEDs_8Bit_GPIO_IO_O_pin,
    fpga_0_DIP_Switches_4Bit_GPIO_IO_I_pin,
    fpga_0_Buttons_4Bit_GPIO_IO_I_pin,
    fpga_0_FLASH_Mem_A_pin,
    fpga_0_FLASH_Mem_CEN_pin,
    fpga_0_FLASH_Mem_OEN_pin,
    fpga_0_FLASH_Mem_WEN_pin,
    fpga_0_FLASH_Mem_DQ_pin,
    fpga_0_FLASH_BEN_pin,
    fpga_0_DDR_SDRAM_DDR_Clk_pin,
    fpga_0_DDR_SDRAM_DDR_Clk_n_pin,
    fpga_0_DDR_SDRAM_DDR_CE_pin,
    fpga_0_DDR_SDRAM_DDR_CS_n_pin,
    fpga_0_DDR_SDRAM_DDR_RAS_n_pin,
    fpga_0_DDR_SDRAM_DDR_CAS_n_pin,
    fpga_0_DDR_SDRAM_DDR_WE_n_pin,
    fpga_0_DDR_SDRAM_DDR_BankAddr_pin,
    fpga_0_DDR_SDRAM_DDR_Addr_pin,
    fpga_0_DDR_SDRAM_DDR_DQ_pin,
    fpga_0_DDR_SDRAM_DDR_DM_pin,
    fpga_0_DDR_SDRAM_DDR_DQS_pin,
    fpga_0_DDR_SDRAM_ddr_dqs_div_io_pin,
    fpga_0_Ethernet_MAC_PHY_tx_clk_pin,
    fpga_0_Ethernet_MAC_PHY_rx_clk_pin,
    fpga_0_Ethernet_MAC_PHY_crs_pin,
    fpga_0_Ethernet_MAC_PHY_dv_pin,
    fpga_0_Ethernet_MAC_PHY_rx_data_pin,
    fpga_0_Ethernet_MAC_PHY_col_pin,
    fpga_0_Ethernet_MAC_PHY_rx_er_pin,
    fpga_0_Ethernet_MAC_PHY_tx_en_pin,
    fpga_0_Ethernet_MAC_PHY_tx_data_pin,
    fpga_0_Ethernet_MAC_PHY_MDC_pin,
    fpga_0_Ethernet_MAC_PHY_MDIO_pin,
    fpga_0_clk_1_sys_clk_pin,
    fpga_0_rst_1_sys_rst_pin
  );
  input fpga_0_RS232_DCE_RX_pin;
  output fpga_0_RS232_DCE_TX_pin;
  output [0:7] fpga_0_LEDs_8Bit_GPIO_IO_O_pin;
  input [0:3] fpga_0_DIP_Switches_4Bit_GPIO_IO_I_pin;
  input [0:3] fpga_0_Buttons_4Bit_GPIO_IO_I_pin;
  output [8:31] fpga_0_FLASH_Mem_A_pin;
  output fpga_0_FLASH_Mem_CEN_pin;
  output fpga_0_FLASH_Mem_OEN_pin;
  output fpga_0_FLASH_Mem_WEN_pin;
  inout [0:7] fpga_0_FLASH_Mem_DQ_pin;
  output fpga_0_FLASH_BEN_pin;
  output fpga_0_DDR_SDRAM_DDR_Clk_pin;
  output fpga_0_DDR_SDRAM_DDR_Clk_n_pin;
  output fpga_0_DDR_SDRAM_DDR_CE_pin;
  output fpga_0_DDR_SDRAM_DDR_CS_n_pin;
  output fpga_0_DDR_SDRAM_DDR_RAS_n_pin;
  output fpga_0_DDR_SDRAM_DDR_CAS_n_pin;
  output fpga_0_DDR_SDRAM_DDR_WE_n_pin;
  output [1:0] fpga_0_DDR_SDRAM_DDR_BankAddr_pin;
  output [12:0] fpga_0_DDR_SDRAM_DDR_Addr_pin;
  inout [15:0] fpga_0_DDR_SDRAM_DDR_DQ_pin;
  output [1:0] fpga_0_DDR_SDRAM_DDR_DM_pin;
  inout [1:0] fpga_0_DDR_SDRAM_DDR_DQS_pin;
  inout fpga_0_DDR_SDRAM_ddr_dqs_div_io_pin;
  (* BUFFER_TYPE = "IBUF" *)
  input fpga_0_Ethernet_MAC_PHY_tx_clk_pin;
  (* BUFFER_TYPE = "IBUF" *)
  input fpga_0_Ethernet_MAC_PHY_rx_clk_pin;
  input fpga_0_Ethernet_MAC_PHY_crs_pin;
  input fpga_0_Ethernet_MAC_PHY_dv_pin;
  input [3:0] fpga_0_Ethernet_MAC_PHY_rx_data_pin;
  input fpga_0_Ethernet_MAC_PHY_col_pin;
  input fpga_0_Ethernet_MAC_PHY_rx_er_pin;
  output fpga_0_Ethernet_MAC_PHY_tx_en_pin;
  output [3:0] fpga_0_Ethernet_MAC_PHY_tx_data_pin;
  output fpga_0_Ethernet_MAC_PHY_MDC_pin;
  inout fpga_0_Ethernet_MAC_PHY_MDIO_pin;
  (* BUFFER_TYPE = "IBUF" *)
  input fpga_0_clk_1_sys_clk_pin;
  (* BUFFER_TYPE = "IBUF" *)
  input fpga_0_rst_1_sys_rst_pin;

  wire [0:3] fpga_0_Buttons_4Bit_GPIO_IO_I_db;
  wire [0:3] fpga_0_DIP_Switches_4Bit_GPIO_IO_I_db;
  wire fpga_0_rst_1_sys_rst_db;

    debouncer_4bit
        db_buttons_i (
            .clk ( fpga_0_clk_1_sys_clk_pin ),
            .noisy ( fpga_0_Buttons_4Bit_GPIO_IO_I_pin ),
            .clean ( fpga_0_Buttons_4Bit_GPIO_IO_I_db )
        );
    
    debouncer_4bit
        db_switches_i (
            .clk ( fpga_0_clk_1_sys_clk_pin ),
            .noisy ( fpga_0_DIP_Switches_4Bit_GPIO_IO_I_pin ),
            .clean ( fpga_0_DIP_Switches_4Bit_GPIO_IO_I_db )
        );
    
    debouncer_1bit
        db_reset_i (
            .clk ( fpga_0_clk_1_sys_clk_pin ),
            .noisy ( fpga_0_rst_1_sys_rst_pin ),
            .clean ( fpga_0_rst_1_sys_rst_db )
        );

  (* BOX_TYPE = "user_black_box" *)
  soc
    soc_i (
      .fpga_0_RS232_DCE_RX_pin ( fpga_0_RS232_DCE_RX_pin ),
      .fpga_0_RS232_DCE_TX_pin ( fpga_0_RS232_DCE_TX_pin ),
      .fpga_0_LEDs_8Bit_GPIO_IO_O_pin ( fpga_0_LEDs_8Bit_GPIO_IO_O_pin ),
      .fpga_0_DIP_Switches_4Bit_GPIO_IO_I_pin ( fpga_0_DIP_Switches_4Bit_GPIO_IO_I_db ),
      .fpga_0_Buttons_4Bit_GPIO_IO_I_pin ( fpga_0_Buttons_4Bit_GPIO_IO_I_db ),
      .fpga_0_FLASH_Mem_A_pin ( fpga_0_FLASH_Mem_A_pin ),
      .fpga_0_FLASH_Mem_CEN_pin ( fpga_0_FLASH_Mem_CEN_pin ),
      .fpga_0_FLASH_Mem_OEN_pin ( fpga_0_FLASH_Mem_OEN_pin ),
      .fpga_0_FLASH_Mem_WEN_pin ( fpga_0_FLASH_Mem_WEN_pin ),
      .fpga_0_FLASH_Mem_DQ_pin ( fpga_0_FLASH_Mem_DQ_pin ),
      .fpga_0_FLASH_BEN_pin ( fpga_0_FLASH_BEN_pin ),
      .fpga_0_DDR_SDRAM_DDR_Clk_pin ( fpga_0_DDR_SDRAM_DDR_Clk_pin ),
      .fpga_0_DDR_SDRAM_DDR_Clk_n_pin ( fpga_0_DDR_SDRAM_DDR_Clk_n_pin ),
      .fpga_0_DDR_SDRAM_DDR_CE_pin ( fpga_0_DDR_SDRAM_DDR_CE_pin ),
      .fpga_0_DDR_SDRAM_DDR_CS_n_pin ( fpga_0_DDR_SDRAM_DDR_CS_n_pin ),
      .fpga_0_DDR_SDRAM_DDR_RAS_n_pin ( fpga_0_DDR_SDRAM_DDR_RAS_n_pin ),
      .fpga_0_DDR_SDRAM_DDR_CAS_n_pin ( fpga_0_DDR_SDRAM_DDR_CAS_n_pin ),
      .fpga_0_DDR_SDRAM_DDR_WE_n_pin ( fpga_0_DDR_SDRAM_DDR_WE_n_pin ),
      .fpga_0_DDR_SDRAM_DDR_BankAddr_pin ( fpga_0_DDR_SDRAM_DDR_BankAddr_pin ),
      .fpga_0_DDR_SDRAM_DDR_Addr_pin ( fpga_0_DDR_SDRAM_DDR_Addr_pin ),
      .fpga_0_DDR_SDRAM_DDR_DQ_pin ( fpga_0_DDR_SDRAM_DDR_DQ_pin ),
      .fpga_0_DDR_SDRAM_DDR_DM_pin ( fpga_0_DDR_SDRAM_DDR_DM_pin ),
      .fpga_0_DDR_SDRAM_DDR_DQS_pin ( fpga_0_DDR_SDRAM_DDR_DQS_pin ),
      .fpga_0_DDR_SDRAM_ddr_dqs_div_io_pin ( fpga_0_DDR_SDRAM_ddr_dqs_div_io_pin ),
      .fpga_0_Ethernet_MAC_PHY_tx_clk_pin ( fpga_0_Ethernet_MAC_PHY_tx_clk_pin ),
      .fpga_0_Ethernet_MAC_PHY_rx_clk_pin ( fpga_0_Ethernet_MAC_PHY_rx_clk_pin ),
      .fpga_0_Ethernet_MAC_PHY_crs_pin ( fpga_0_Ethernet_MAC_PHY_crs_pin ),
      .fpga_0_Ethernet_MAC_PHY_dv_pin ( fpga_0_Ethernet_MAC_PHY_dv_pin ),
      .fpga_0_Ethernet_MAC_PHY_rx_data_pin ( fpga_0_Ethernet_MAC_PHY_rx_data_pin ),
      .fpga_0_Ethernet_MAC_PHY_col_pin ( fpga_0_Ethernet_MAC_PHY_col_pin ),
      .fpga_0_Ethernet_MAC_PHY_rx_er_pin ( fpga_0_Ethernet_MAC_PHY_rx_er_pin ),
      .fpga_0_Ethernet_MAC_PHY_tx_en_pin ( fpga_0_Ethernet_MAC_PHY_tx_en_pin ),
      .fpga_0_Ethernet_MAC_PHY_tx_data_pin ( fpga_0_Ethernet_MAC_PHY_tx_data_pin ),
      .fpga_0_Ethernet_MAC_PHY_MDC_pin ( fpga_0_Ethernet_MAC_PHY_MDC_pin ),
      .fpga_0_Ethernet_MAC_PHY_MDIO_pin ( fpga_0_Ethernet_MAC_PHY_MDIO_pin ),
      .fpga_0_clk_1_sys_clk_pin ( fpga_0_clk_1_sys_clk_pin ),
      .fpga_0_rst_1_sys_rst_pin ( fpga_0_rst_1_sys_rst_db )
    );
  
endmodule


Tags (1)
0 Kudos
10 Replies
Instructor
Instructor
8,620 Views
Registered: ‎08-14-2007

Re: "Constraint cannot be distributed... do not contain or drive any instances of correct type" problem

It looks to me that the nets in the warnings are actually internal to the FPGA, connecting

between the debouncer and the wrapped black box code.  It doesn't make sense

to attach a pin location to an internal net.  If you wanted to locate a pin, it should be

on the "noisy" net rather than the "clean" net.  Also, when you instantiate a module and

map the ports to a signal at the top level, you would generally use the signal name

from the top level in your constraints, rather than the hierarchical name of the signal

within the lower level module.

 

In any case, the only nets that can be LOC'd to a pin are the top level (wrapper) ports.

 

-- Gabor

-- Gabor
0 Kudos
Visitor jbradach
Visitor
8,616 Views
Registered: ‎03-04-2012

Re: "Constraint cannot be distributed... do not contain or drive any instances of correct type" problem

That's what is confusing me; It's applying the locate constraint on the "clean" internal side and (unless there's something right in front of me I'm missing) I haven't done anything to tell it to do that.  The relevant constraint in the UCF looks like this:

 

Net fpga_0_rst_1_sys_rst_pin LOC=K17  |  IOSTANDARD = LVCMOS33  |  PULLDOWN;

 

Which should be applying the constraint to the external, "noisy" side.  There's no place where I'm putting a constraint on the internal net, unless it inferred it from some rule I'm unknowingly violating.  As far as I can tell, though, the only signals I'm applying constraints to are the top level.

 

 

0 Kudos
Teacher eteam00
Teacher
8,614 Views
Registered: ‎07-21-2009

.UCF syntax

Net fpga_0_rst_1_sys_rst_pin LOC=K17  |  IOSTANDARD = LVCMOS33  |  PULLDOWN;

 

In the .UCF file, the signal (port) name should be in quotations marks, for example:

 

Net "fpga_0_rst_1_sys_rst_pin" LOC=K17  |  IOSTANDARD = LVCMOS33  |  PULLDOWN;

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Visitor jbradach
Visitor
8,612 Views
Registered: ‎03-04-2012

Re: .UCF syntax

Do they?  These are the constraints that was generated by XPS and it didn't use quotes on any of them.  I can try putting quotes around the relevant signals, just to rule that out, but the system-generated UCF makes me think that it doesn't matter.

0 Kudos
Visitor jbradach
Visitor
8,606 Views
Registered: ‎03-04-2012

Re: .UCF syntax

Follow up - no difference. Oh, and I do have the "-iobuf" option being passed to XST.
0 Kudos
Instructor
Instructor
8,597 Views
Registered: ‎08-14-2007

Re: .UCF syntax


@jbradach wrote:
Follow up - no difference. Oh, and I do have the "-iobuf" option being passed to XST.

The -iobuf option should only be used to build the black box you instantiate with your wrapper.

The wrapper itself should be allowed to infer I/O buffers (pads).  Otherwise you end up with a

design with no external pads and that sould have no place to attach the pin LOC constraints.

If you did this backwards (added I/O buffers when building the black box and not for the wrapper)

then all of your internal connections would have I/O buffers added and you could end up with

multiple drivers among other problems.

 

-- Gabor

-- Gabor
0 Kudos
Visitor jbradach
Visitor
8,593 Views
Registered: ‎03-04-2012

Re: .UCF syntax

Isn't having it required in order for it to infer them?  I'm using ISE and under Process Properties->Xilinx Specific Options for Synthesize-XST, the default for -iobuf ("Add I/O Buffers") is set.  If I don't have it set, the wrapper crashes and burns because it doesn't insert any of the buffers.

0 Kudos
Instructor
Instructor
8,583 Views
Registered: ‎08-14-2007

Re: .UCF syntax

Maybe I misunderstood you.  I assumed you meant that the -iobuf attribute was set the same

for the wrapped code and the wrapper.  You want to have no IO buffer insertion in the EDK

hardware build (or allow ISE to build it instead by attaching the EDK project file to the ISE

project), but you must have IO buffers in the ISE build.  You should not need buffer type

attributes on your clocks.  In fact this could cause large amounts of skew on the clock

nets.

 

-- Gabor

-- Gabor
0 Kudos
Visitor jbradach
Visitor
8,575 Views
Registered: ‎03-04-2012

Re: .UCF syntax

The wrapped code was generated in XPS.  From a blank project, I added an embedded processor using the XPS base system builder, generated a top-level HDL, and then added the instantiation for my debouncer.  I don't think it added the buffers to the wrapped code (I didn't change it from the default and I'm making the possibly naive assumption that it'll pick a sane default).  ISE has the buffers enabled, as per the default.  If I have the debouncers instantiated, not putting the buffer type qualifier on the clock results in the "does not drive net of correct type" message and it removes them.  Since adding the same qualifier to the other inputs doesn't fix them up, I'm guessing that even though it leaves the clock in, I'm not fixing it correctly.

 

Does the way I've described my design make sense?  The top level looks like this conceptually (assume the instantiation names are unique, I'm just putting the types for clarity):

 

soc_top

    debouncer_4bit  // debouncer for buttons

    debouncer_4bit // debouncer for switches

    debouncer_1bit // debouncer for button mapped to reset

    soc  // embedded processor generated in XPS

 

- Jack

 

0 Kudos
Visitor krlarsen
Visitor
2,925 Views
Registered: ‎11-14-2008

Re: .UCF syntax

I know this is an old thread, but I'll respond for posterity's sake! (In case others like myself arrive here from google looking for answers)

 

I just experienced this problem.

 

You must use the same name of the port you originally had going into the microblaze black box.  This is, of course currently the top-level input port. So you need to change that.

 

I'll explain what to do for the reset pin. Basically change the last line of your soc_top.v from:

 

.fpga_0_rst_1_sys_rst_pin ( fpga_0_rst_1_sys_rst_db )

 

back to

 

.fpga_0_rst_1_sys_rst_pin ( fpga_0_rst_1_sys_rst_pin )

 

Then remove the the following line from your soc/data/soc.ucf file:


Net fpga_0_rst_1_sys_rst_pin LOC=K17  |  IOSTANDARD = LVCMOS33  |  PULLDOWN;

 

And add a new line to a new top_level ucf source file that you need to create. I've found that constraints specified in the microblaze ucf file sometimes don't apply properly to IO that is only in the top level module.  The line would be something like this:

 

Net reset_pin LOC=K17  |  IOSTANDARD = LVCMOS33  |  PULLDOWN;

 

Then simply use reset_pin as the input to your top module as well as the input to the debouncer. The output of the debouncer will be fpga_0_rst_1_sys_rst_pin.

 

So I guess the generic solution is to leave the port declarations as they came, and change, instead, the ucf file.  I'm not sure why, but this is what seemed to work for me.

0 Kudos