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: 
Visitor wk.open
Visitor
8,007 Views
Registered: ‎07-09-2013

Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution

Environment: ISE 14.6, PlanAhead 14.6 with Partial Reconfiguration enabled.

Board: Zedboard

Reference Tutorial: UG743

 

I'm implementing a very simple partial reconfiguration design with a top.v and two modules, an "adder" and a "multiplier".

 

Top.v

INPUT: SWITCH[7:0], OUTPUT LED[6:0]

 

The "adder" will use SWITCH[3:0] as the inputs and display result to LED[2:0].

The "multiplier" will use SWITCH[7:4] as the inputs and display result to LED[6:3];

 

Translated into Verilog code will be:

 

module top(
    input  [7:0]	switch,       
    output [6:0]  led);

    // instantiate reconfigurable module BRAM
    twobit_adder U1_RP_Adder (
      .a    (switch[1:0]),
      .b    (switch[3:2]),
      .z    (led[1:0]),
      .cout (led[2])
     );

    // instantiate reconfigurable module counter
    twobit_blank_multiplier U2_RP_Multi (
      .a    (switch[5:4]),
      .b    (switch[7:6]),
      .z    (led[6:3])
     );

endmodule

 And I also added an UCF to the top file as the following:

# PlanAhead Generated physical constraints 

NET "led[6]" LOC = U14;
NET "led[5]" LOC = U19;
NET "led[4]" LOC = W22;
NET "led[3]" LOC = V22;
NET "led[2]" LOC = U22;
NET "led[1]" LOC = T21;
NET "led[0]" LOC = T22;

# PlanAhead Generated IO constraints 

NET "led[6]" IOSTANDARD = LVCMOS18;
NET "led[5]" IOSTANDARD = LVCMOS18;
NET "led[4]" IOSTANDARD = LVCMOS18;
NET "led[3]" IOSTANDARD = LVCMOS18;
NET "led[2]" IOSTANDARD = LVCMOS18;
NET "led[1]" IOSTANDARD = LVCMOS18;
NET "led[0]" IOSTANDARD = LVCMOS18;
NET "switch[7]" IOSTANDARD = LVCMOS18;
NET "switch[6]" IOSTANDARD = LVCMOS18;
NET "switch[5]" IOSTANDARD = LVCMOS18;
NET "switch[4]" IOSTANDARD = LVCMOS18;
NET "switch[3]" IOSTANDARD = LVCMOS18;
NET "switch[2]" IOSTANDARD = LVCMOS18;
NET "switch[1]" IOSTANDARD = LVCMOS18;
NET "switch[0]" IOSTANDARD = LVCMOS18;

# PlanAhead Generated physical constraints 

NET "switch[7]" LOC = M15;
NET "switch[6]" LOC = H17;
NET "switch[5]" LOC = H18;
NET "switch[4]" LOC = H19;
NET "switch[3]" LOC = F21;
NET "switch[2]" LOC = H22;
NET "switch[1]" LOC = G22;
NET "switch[0]" LOC = F22;

 In PlanAhead, I created a new project with partial reconfiguration enabled and set top.ngc and top.ucf as the top file. And I also set two partitions according to the modules defined in top.v and gave them .ngc files w/o any other .ucf files.

 

But when I ran "Run Implementation" there were warnings shown:

WARNING:Par:289 - The signal switch[7] has no driver. PAR will not attempt to route this signal.
WARNING:Par:289 - The signal switch[6] has no driver. PAR will not attempt to route this signal.
WARNING:Par:289 - The signal switch[5] has no driver. PAR will not attempt to route this signal.
WARNING:Par:289 - The signal switch[4] has no driver. PAR will not attempt to route this signal.
WARNING:Par:289 - The signal switch[3] has no driver. PAR will not attempt to route this signal.
WARNING:Par:289 - The signal switch[2] has no driver. PAR will not attempt to route this signal.
WARNING:Par:289 - The signal switch[1] has no driver. PAR will not attempt to route this signal.
WARNING:Par:289 - The signal switch[0] has no driver. PAR will not attempt to route this signal.
WARNING:Par:288 - The signal led[6] has no load. PAR will not attempt to route this signal.
WARNING:Par:288 - The signal led[5] has no load. PAR will not attempt to route this signal.
WARNING:Par:288 - The signal led[4] has no load. PAR will not attempt to route this signal.
WARNING:Par:288 - The signal led[3] has no load. PAR will not attempt to route this signal.
WARNING:Par:288 - The signal led[2] has no load. PAR will not attempt to route this signal.
WARNING:Par:288 - The signal led[1] has no load. PAR will not attempt to route this signal.
WARNING:Par:288 - The signal led[0] has no load. PAR will not attempt to route this signal

I simply ignored the warnings and ran "Promoted" and "Generate Bitstream", but in "Generate Bitstream" those warnings became errors:

ERROR:PhysDesignRules:10 - The network <switch[7]> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <switch[6]> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <switch[5]> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <switch[4]> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <switch[3]> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <switch[2]> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <switch[1]> is completely unrouted.
ERROR:PhysDesignRules:10 - The network <switch[0]> is completely unrouted.

 It looks like I didn't route <switch> and <led> properly, but in top.v I declared the assignments so I am confused where I went wrong.

 

If anyone can help me with this problem, it will be a boost to my study of partial reconfiguration on Zedboard. Thank you in advance!

0 Kudos
1 Solution

Accepted Solutions
Mentor hgleamon1
Mentor
10,204 Views
Registered: ‎11-14-2011

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution

@wk.open wrote:

And also, do these two critical warnings have anything to do with the connection problem?

 

couldn't_recognize_module.PNG

 

These two warnings exist when I created the PlanAhead project and imported top.v into the project.


Yes. Directly. It means that the tools cannot find your subcomponents. Subsequently, with no subcomponents, there are no connections, hence the top level failure.

 

You need to check that the subcomponents are included in the design directory or, if you are instantiating netlists (but I don't think you are), the relevant .NGC files should be in the design directory.

----------
"That which we must learn to do, we learn by doing." - Aristotle
10 Replies
Mentor hgleamon1
Mentor
7,991 Views
Registered: ‎11-14-2011

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution

Can you post your adder and multiplier submodules, so we can see what happens to the top level nets at the lower levels?

 

It appears that the top level nets are not connected to anything, which suggests some issues with your hierarchical implementation.

 

Regards,

 

Howard

 

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Visitor wk.open
Visitor
7,983 Views
Registered: ‎07-09-2013

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution

Sure. Here is the adder:

entity twobit_adder is
	port( a, b : in STD_LOGIC_VECTOR(1 downto 0);
	z : out STD_LOGIC_VECTOR(1 downto 0);
	cout : out STD_LOGIC );
end twobit_adder;

architecture MY_STRUCTURE of twobit_adder is

component FULL_ADDER
    port( x, y, cin : in STD_LOGIC;
    sum, cout : out STD_LOGIC );
end component;

signal c0, c1 : STD_LOGIC;
begin
    c0 <= '0';
    b_adder0: FULL_ADDER port map (a(0), b(0), c0, z(0), c1);
    b_adder1: FULL_ADDER port map (a(1), b(1), c1, z(1), cout);
END MY_STRUCTURE;

 FYI the full adder module is:

entity full_adder is
	port(x, y, cin: in std_logic;
	sum, cout: out std_logic);
end full_adder;	 

architecture my_dataflow of full_adder is	   

begin 	
	sum <= (x xor y) xor cin;
	cout <= (x and y) or (x and cin) or (y and cin);  
end my_dataflow;

 And the multiplier module is:

entity twobit_multiplier is
    Port ( a : in  STD_LOGIC_VECTOR (1 downto 0);
           b : in  STD_LOGIC_VECTOR (1 downto 0);
           z : out  STD_LOGIC_VECTOR (3 downto 0));
end twobit_multiplier;

architecture my_dataflow of twobit_multiplier is

begin
	z <= a * b;
end my_dataflow;

 In order to prevent ISE from trimming my ports, I add the following SAVE constrains to the .ucf file of my adder and multiplier as PlanAhead doesn't allow IOBUF in partial reconfiguration partitions.

NET "a*" S;
NET "b*" S;
NET "z*" S;
NET "cout" S;

 I believe my adder and multiplier are working fine as I have tested them separately on Zedboard with ports directly connected to switches and LEDs. So I believe it's the io buffer thing which drove me crazy these days.

 

Thank you!

0 Kudos
Visitor wk.open
Visitor
7,981 Views
Registered: ‎07-09-2013

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution
And besides of that, I turned off auto iobuf option in design strategy for adder and multiplier but NOT for the top module.
0 Kudos
Visitor wk.open
Visitor
7,978 Views
Registered: ‎07-09-2013

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution

And also, do these two critical warnings have anything to do with the connection problem?

 

couldn't_recognize_module.PNG

 

These two warnings exist when I created the PlanAhead project and imported top.v into the project.

0 Kudos
Visitor wk.open
Visitor
7,970 Views
Registered: ‎07-09-2013

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution


PlanAhead showed some warning about the constraint matching when "Run Implementation" was run. Here is an example:

 

[ConstraintSystem 119] Constraint <NET "led[6]" LOC = U14;> [config_1.ucf(13)]: This constraint cannot be distributed from the design objects matching 'NET "led[6]"' because those design objects do not contain or drive any instances of the correct type.


Same warning for led[5] 4 3 2 1 0 and switch[7] 6  5 ... 0

0 Kudos
Mentor hgleamon1
Mentor
10,205 Views
Registered: ‎11-14-2011

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution

@wk.open wrote:

And also, do these two critical warnings have anything to do with the connection problem?

 

couldn't_recognize_module.PNG

 

These two warnings exist when I created the PlanAhead project and imported top.v into the project.


Yes. Directly. It means that the tools cannot find your subcomponents. Subsequently, with no subcomponents, there are no connections, hence the top level failure.

 

You need to check that the subcomponents are included in the design directory or, if you are instantiating netlists (but I don't think you are), the relevant .NGC files should be in the design directory.

----------
"That which we must learn to do, we learn by doing." - Aristotle
Community Manager
Community Manager
7,935 Views
Registered: ‎06-14-2012

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution

The two critical warnings are important. They are trying to convey that both these modules have been taken a black boxes and they can be resolved.

 

Please check on how you are adding your source files.

0 Kudos
Visitor wk.open
Visitor
7,929 Views
Registered: ‎07-09-2013

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution

Thank you hgleamon1!

 

I created a new PlanAhead project and added the whole directory of top module into the project and those two critical warnings never showed up again. And I could successfully generate bit files without any problem :)

0 Kudos
Visitor wk.open
Visitor
7,928 Views
Registered: ‎07-09-2013

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution
Thank you siktap. Those warnings are critical to solve my problem, now I can run my implementation w/o any problem.
0 Kudos
Visitor xertian
Visitor
2,274 Views
Registered: ‎08-06-2013

Re: Signal <switch> and <led> not routed in the top level design of a partial reconfiguration

Jump to solution
hi,wk.open
i am now running with the same critical warning as u described above .icant quite .understand . how u solved this .can u describe more clearly ?
thks
0 Kudos