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!

Reply

PicoBlaze timing constraints

Accepted Solution Solved
Highlighted
Visitor
Posts: 3
Registered: ‎01-03-2018
Accepted Solution

PicoBlaze timing constraints

Hi

 

I'm running into an issue with timing constraints for the PicoBlaze within a Artix 7 design.

The issue is that after synthesis I'm seeing a number of 'inconstrained_internal_endpoints'.

Looking further it states 'Unconstrained Pins for maximum delay due to constant clock'.

 

These endpoints reside within the PicoBlaze generated memory file which consists mainly of DIBDI[*] inputs on a RAMB36E1.

The DIBDI[*] input are connected to the DOBDO[*] outputs.

The port B write clock signal, CLKBWRCLK, is connected directly to a constant 0.

 

I've tried multicycle, set_max_delay constraints on these signals, set_case_analysis on the write clock and and cannot remove these medium severity warnings.

 

I'm curious if anyone has a constraint solution to address this.

 

Thanks!


Accepted Solutions
Visitor
Posts: 3
Registered: ‎01-03-2018

Re: PicoBlaze timing constraints

For now I'm stuck using false paths like this:

 

set_false_path -to [get_pins {{design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_h/DIBDI[*]} {design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_h/DIBDI[*]}}]
set_false_path -to [get_pins {{design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_l/DIBDI[*]} {design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_l/DIBDI[*]}}]

 

set_false_path -to [get_pins {{design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_h/DIPBDIP[*]} {design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_h/DIPBDIP[*]}}]
set_false_path -to [get_pins {{design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_l/DIPBDIP[*]} {design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_l/DIPBDIP[*]}}]

 

It will do for now but still feel like there should be an easier way to relax constraints rather than remove them from the timing analysis.

View solution in original post


All Replies
Explorer
Posts: 151
Registered: ‎02-24-2014

Re: PicoBlaze timing constraints

[ Edited ]

set_false_path will kill any analysis on these signals. 

 

It seems rather odd that the output bits are fed back to the inputs on the BRAM36.   Port B is grounded if the JTAG loader is disabled, otherwise port B is connected to the JTAG logic.    It looks like you set the JTAG generic parameter C_JTAG_LOADER_ENABLE = 0 ?    If so,  here is the relevant code for Artix:

 

      no_loader : if (C_JTAG_LOADER_ENABLE = 0) generate
        data_in_b_l <= "000" & data_out_b_l(32) & "000000000000000000000000" & data_out_b_l(7 downto 0);
        data_in_b_h <= "000" & data_out_b_h(32) & "000000000000000000000000" & data_out_b_h(7 downto 0);
        address_b <= "1111111111111111";
        we_b <= "00000000";
        enable_b <= '0';
        rdl <= '0';
        clk_b <= '0';

So this is normal for the picoblaze without JTAG..     I can only guess why Ken decided to feed the output of the RAM back to the input in this case.  But it should be easy to just set the data inputs to zero with  (others =>'0'),  shouldn't it?   

 

( Easter Egg:  KCPSM6 stands for "Ken Chapman's Programmable State Machine version 6" )

Visitor
Posts: 3
Registered: ‎01-03-2018

Re: PicoBlaze timing constraints

HI

 

Thanks for the quick reply.  Much appreciated!

 

I'm using the verilog version along with a memory form that doesn't include the JTAG which gives me:

 

assign address_a = {1'b1, address[11:0], 3'b111};
assign instruction = {data_out_a_h[32], data_out_a_h[7:0], data_out_a_l[32], data_out_a_l[7:0]};
assign data_in_a = 36'b000000000000000000000000000000000000;
//
assign address_b = 16'b1111111111111111;
assign data_in_b_l = {3'h0, data_out_b_l[32], 24'b000000000000000000000000, data_out_b_l[7:0]};
assign data_in_b_h = {3'h0, data_out_b_h[32], 24'b000000000000000000000000, data_out_b_h[7:0]};
assign enable_b = 1'b0;
assign we_b = 8'h00;
assign clk_b = 1'b0;

 

I'm reluctant to change the behavior of the generated memory as I'm not sure what Ken's intent was.

That is why I was looking to only 'relax' the constraint rather than false path it.

Visitor
Posts: 3
Registered: ‎01-03-2018

Re: PicoBlaze timing constraints

For now I'm stuck using false paths like this:

 

set_false_path -to [get_pins {{design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_h/DIBDI[*]} {design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_h/DIBDI[*]}}]
set_false_path -to [get_pins {{design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_l/DIBDI[*]} {design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_l/DIBDI[*]}}]

 

set_false_path -to [get_pins {{design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_h/DIPBDIP[*]} {design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_h/DIPBDIP[*]}}]
set_false_path -to [get_pins {{design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_l/DIPBDIP[*]} {design_1_i/kcpsm6_design_0/inst/my_program/kcpsm6_rom_l/DIPBDIP[*]}}]

 

It will do for now but still feel like there should be an easier way to relax constraints rather than remove them from the timing analysis.