cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
4,738 Views
Registered: ‎05-21-2008

illegal to place instance Part Deux

Jump to solution

 

   If you followed my earlier thread, I had marked it as solved by rebuilding the project.  That DID help, until I connected to my IP.  I think I'm starting to understand this better, but I still don't have a solution.  I'm still a newbie, making newbie mistakes.

 

   If you take Xilinx 14.4 (or 14.7) and create an embedded system, and connect L18 to L19 using a Utility Vector Logic NOT gate, it WILL WORK.

 

   If you take IP that connects to the NOT gate output (and/or L19 ( either fails)) you get a critical warning:

 

[Constraints 18-5] Cannot loc instance 'util_vector_logic_0_Op1_pin_BUFGP/BUFG' at site L18, Illegal to place instance util_vector_logic_0_Op1_pin_BUFGP/BUFG on site L18. The location site type doe not match the instance type. ["C:/Users/cti/Documents/AFETest3/AFETest3.runs/impl_1/.constrs/system.ncf":6]

  and it WILL FAIL to assign to L18.

 

   Basically, my IP used the input from L18 through the NOT as a clock input. (I'll post code fragment below)  As soon as it is used as a clock, evidently the system wants to assign a BUFG, and that is illegal to do for this clock input pin.  (Looking things over, there may not be a free BUFG in the system, it may totally be used by the processor system.  An "illegal" warning is probably a red herring, and, ultimately, "illegal" in itself. Nevertheless the problem remains.)

 

   The *strange* thing here is the pin gets re-assigned to another input pin.  If you give up and assign the NOT gate input to the input pin it re-assigns it to, it gives you the *very same* warning and assigns it to a different pin.  (Sometimes, rarely, L18!)

 

    Previously, once tainted, the system never recovered and never allowed L18 to be used even with all IP removed, until I created a new project.

 

    My question is this:  How can I force it to pin L18, or even to a pin it automatically assigns it to when it forcibly removes it from L18?  (Remember, assigning it to a pin it automatically placed it to causes the *same warning* and problem with the new pin.)

 

   My user logic is included below, and the LOG file fragments with the warnings about the NOT utility vector logic are included. CLK_XMIT_DAC is assigned to the output of the util_vector_logic.  (I've searched for the LOG file, but "log" is a directory,and it is empty.  Also, the MHS file fragments are included.  This is a totally standardized design.  Fragments are used to avoid 1,000 lines of text.

 

   Do I have to force an iBUF, or is this something where I have to pretend it is not a clock and use different terminology in my VHDL in order to get Xilinx tools to route it.  It is only 16mhz in, so the speed isn't that great for this particular FPGA.  If so, how would I craft my VHDL to accomplish this?

 

 

thanks,

wade

 

MHS File fragments:

 

 PORT util_vector_logic_0_Op1_pin = net_util_vector_logic_0_Op1_pin, DIR = I
 PORT util_vector_logic_0_Res_pin = util_vector_logic_0_Res, DIR = O
 PORT xt_dac_test_manager_0_mux_reg_output_pin = xt_dac_test_manager_0_mux_reg_output, DIR = O, VEC = [15:0]

BEGIN util_vector_logic
 PARAMETER INSTANCE = util_vector_logic_0
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_OPERATION = not
 PARAMETER C_SIZE = 1
 PORT Op1 = net_util_vector_logic_0_Op1_pin
 PORT Res = util_vector_logic_0_Res
END

 

BEGIN util_vector_logic
 PARAMETER INSTANCE = util_vector_logic_1
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_OPERATION = not
 PARAMETER C_SIZE = 1
 PORT Op1 = util_vector_logic_0_Res
 PORT Res = util_vector_logic_1_Res
END

BEGIN xt_dac_test_manager
 PARAMETER INSTANCE = xt_dac_test_manager_0
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_BASEADDR = 0x6d400000
 PARAMETER C_HIGHADDR = 0x6d40ffff
 BUS_INTERFACE S_AXI = axi_interconnect_1
 PORT S_AXI_ACLK = processing_system7_0_FCLK_CLK0
 PORT CLK_XMIT_DAC = util_vector_logic_1_Res
 PORT mux_reg_output = xt_dac_test_manager_0_mux_reg_output
END

 

 

USER LOGIC:  (I created a standard IP with the wizard, then added code to turn an input into a clock for external DAC)

entity user_logic is
  generic
  (
    -- ADD USER GENERICS BELOW THIS LINE ---------------
    --USER generics added here
    -- ADD USER GENERICS ABOVE THIS LINE ---------------

    -- DO NOT EDIT BELOW THIS LINE ---------------------
    -- Bus protocol parameters, do not add to or delete
    C_NUM_REG                      : integer              := 3;
    C_SLV_DWIDTH                   : integer              := 32
    -- DO NOT EDIT ABOVE THIS LINE ---------------------
  );
  port
  (
    -- ADD USER PORTS BELOW THIS LINE ------------------
    --USER ports added here
     mux_reg_output                 : out std_logic_vector(15 downto 0); --to 16 bit DAC output
     CLK_XMIT_DAC                   : in std_logic; -- a 40mhz clock input.  (well within the 115mhz design parms)
    -- ADD USER PORTS ABOVE THIS LINE ------------------

    -- DO NOT EDIT BELOW THIS LINE ---------------------
    -- Bus protocol ports, do not add to or delete
    Bus2IP_Clk                     : in  std_logic;
    Bus2IP_Resetn                  : in  std_logic;
    Bus2IP_Data                    : in  std_logic_vector(C_SLV_DWIDTH-1 downto 0);
    Bus2IP_BE                      : in  std_logic_vector(C_SLV_DWIDTH/8-1 downto 0);
    Bus2IP_RdCE                    : in  std_logic_vector(C_NUM_REG-1 downto 0);
    Bus2IP_WrCE                    : in  std_logic_vector(C_NUM_REG-1 downto 0);
    IP2Bus_Data                    : out std_logic_vector(C_SLV_DWIDTH-1 downto 0);
    IP2Bus_RdAck                   : out std_logic;
    IP2Bus_WrAck                   : out std_logic;
    IP2Bus_Error                   : out std_logic
    -- DO NOT EDIT ABOVE THIS LINE ---------------------
  );

  attribute MAX_FANOUT : string;
  attribute SIGIS : string;

  attribute SIGIS of Bus2IP_Clk    : signal is "CLK";
  attribute SIGIS of Bus2IP_Resetn : signal is "RST";

end entity user_logic;

------------------------------------------------------------------------------
-- Architecture section
------------------------------------------------------------------------------

architecture IMP of user_logic is

  --USER signal declarations added here, as needed for user logic
  signal sawtooth_counter               : std_logic_vector(15 downto 0); -- i don't care that it is not initialized
  signal saw_counter_output             : std_logic_vector(15 downto 0);
  signal sine_wave_counter_output       : std_logic_vector(15 downto 0);
 
  type   sine2mhz_memory_type is array (0 to 7) of integer range 0 to 65535;
  -- every other one is points for 4mhz signal
  ---                          Degrees:        0       45      90      135    180      225     270    315   
  signal   sine2mhz : sine2mhz_memory_type :=(32768  ,46340  ,65535  ,46340  ,32768  ,19195  , 0     , 19195 );
  -- you can't assign string literals to integer without wordy conversion...
  --signal sine2mhz : sine2mhz_memory_type :=(X"8000",X"B504",X"FFFF",X"B504",X"8000",X"4AFB",X"0000",X"4AFB");
  ------------------------------------------
  -- Signals for user logic slave model s/w accessible register example
  ------------------------------------------
  signal slv_reg0                       : std_logic_vector(C_SLV_DWIDTH-1 downto 0);
  signal slv_reg1                       : std_logic_vector(C_SLV_DWIDTH-1 downto 0);
  signal slv_reg2                       : std_logic_vector(C_SLV_DWIDTH-1 downto 0);
  signal slv_reg_write_sel              : std_logic_vector(2 downto 0);
  signal slv_reg_read_sel               : std_logic_vector(2 downto 0);
  signal slv_ip2bus_data                : std_logic_vector(C_SLV_DWIDTH-1 downto 0);
  signal slv_read_ack                   : std_logic;
  signal slv_write_ack                  : std_logic;
begin

  --USER logic implementation added here
  mux_reg_output <= slv_reg0(15 downto 0)                         when slv_reg2(1 downto 0) = "00" else
                          saw_counter_output(15 downto 0)              when slv_reg2(1 downto 0) = "01" else
                          sine_wave_counter_output(15 downto 0)    when slv_reg2(1 downto 0) = "10";
 
 
 
 
 
  -----------------------------------------------------------------------
  -- processes "flow" in the hardware "in order" of written statements
  -- Saw Tooth Generator
  -----------------------------------------------------------------------
  saw_tooth_generator_process:  process (CLK_XMIT_DAC)
      variable sawtooth_divide_by_counter    : integer range 0 to 8 ;

  begin
        if rising_edge(CLK_XMIT_DAC) then
           if slv_reg1(0) = '1' then -- bit 0 is sawtooth
               
            if sawtooth_divide_by_counter > 3 then
                   sawtooth_divide_by_counter :=0 ;
                    sawtooth_counter <= sawtooth_counter + 1; -- this variable is a roll over counter
                else
                   sawtooth_divide_by_counter := sawtooth_divide_by_counter + 1;
                end if;
                            
            else
                sawtooth_counter <= sawtooth_counter + 1; -- this variable is a roll over counter
            end if;
        end if;
        -- do the assignment (always)
        saw_counter_output <= sawtooth_counter;
  end process;
 
 
 
  -----------------------------------------------------------------------
  -- Sine Wave Generator
  -----------------------------------------------------------------------
  sinewave_generator_process:  process (CLK_XMIT_DAC)
    variable sine_wave_index                : integer range 0 to 16;
     variable sine_wave_divide_by_counter    : integer range 0 to 8 ;
  begin
        if rising_edge(CLK_XMIT_DAC) then
           -- 16mhz -->4mhz, every 90 degrees
            -- 16mhz -->2mhz, every 45 degrees
                sine_wave_divide_by_counter := sine_wave_divide_by_counter + 1;
            
            -- if bit 1 is 1, then divide by 4 else divide by 8
            if slv_reg1(1) = '1' then
                if sine_wave_divide_by_counter > 3 then
                    sine_wave_index := sine_wave_index + 2;    
                    sine_wave_divide_by_counter :=0;
                end if;
            else
              if sine_wave_divide_by_counter > 7 then
                    sine_wave_index := sine_wave_index + 1;    
                    sine_wave_divide_by_counter :=0;
              end if;
            end if;
        
        
            if sine_wave_index > 7 then
                sine_wave_index := 0;
            end if;-- sine_wave_step
            
        end if;-- rising_edge
        
        sine_wave_counter_output <=  std_logic_vector(to_signed(sine2mhz(sine_wave_index),sine_wave_counter_output'length)); -- always set??
  end process;
 
 
  ------------------------------------------
  -- Example code to read/write user logic slave model s/w accessible registers
  --
  -- Note:
  -- The example code presented here is to show you one way of reading/writing
  -- software accessible registers implemented in the user logic slave model.
  -- Each bit of the Bus2IP_WrCE/Bus2IP_RdCE signals is configured to correspond
  -- to one software accessible register by the top level template. For example,
  -- if you have four 32 bit software accessible registers in the user logic,
  -- you are basically operating on the following memory mapped registers:
  --
  --    Bus2IP_WrCE/Bus2IP_RdCE   Memory Mapped Register
  --                     "1000"   C_BASEADDR + 0x0
  --                     "0100"   C_BASEADDR + 0x4
  --                     "0010"   C_BASEADDR + 0x8
  --                     "0001"   C_BASEADDR + 0xC
  --
  ------------------------------------------
  slv_reg_write_sel <= Bus2IP_WrCE(2 downto 0);
  slv_reg_read_sel  <= Bus2IP_RdCE(2 downto 0);
  slv_write_ack     <= Bus2IP_WrCE(0) or Bus2IP_WrCE(1) or Bus2IP_WrCE(2);
  slv_read_ack      <= Bus2IP_RdCE(0) or Bus2IP_RdCE(1) or Bus2IP_RdCE(2);

  -- implement slave model software accessible register(s)
  SLAVE_REG_WRITE_PROC : process( Bus2IP_Clk ) is
  begin

    if Bus2IP_Clk'event and Bus2IP_Clk = '1' then
      if Bus2IP_Resetn = '0' then
        slv_reg0 <= (others => '0');
        slv_reg1 <= (others => '0');
        slv_reg2 <= (others => '0');
      else
        case slv_reg_write_sel is
          when "100" =>
            for byte_index in 0 to (C_SLV_DWIDTH/8)-1 loop
              if ( Bus2IP_BE(byte_index) = '1' ) then
                slv_reg0(byte_index*8+7 downto byte_index*8) <= Bus2IP_Data(byte_index*8+7 downto byte_index*8);
              end if;
            end loop;
          when "010" =>
            for byte_index in 0 to (C_SLV_DWIDTH/8)-1 loop
              if ( Bus2IP_BE(byte_index) = '1' ) then
                slv_reg1(byte_index*8+7 downto byte_index*8) <= Bus2IP_Data(byte_index*8+7 downto byte_index*8);
              end if;
            end loop;
          when "001" =>
            for byte_index in 0 to (C_SLV_DWIDTH/8)-1 loop
              if ( Bus2IP_BE(byte_index) = '1' ) then
                slv_reg2(byte_index*8+7 downto byte_index*8) <= Bus2IP_Data(byte_index*8+7 downto byte_index*8);
              end if;
            end loop;
          when others => null;
        end case;
      end if;
    end if;

  end process SLAVE_REG_WRITE_PROC;

  -- implement slave model software accessible register(s) read mux
  SLAVE_REG_READ_PROC : process( slv_reg_read_sel, slv_reg0, slv_reg1, slv_reg2 ) is
  begin

    case slv_reg_read_sel is
      when "100" => slv_ip2bus_data <= slv_reg0;
      when "010" => slv_ip2bus_data <= slv_reg1;
      when "001" => slv_ip2bus_data <= slv_reg2;
      when others => slv_ip2bus_data <= (others => '0');
    end case;

  end process SLAVE_REG_READ_PROC;
  ------------------------------------------
  -- Example code to drive IP to Bus signals
  ------------------------------------------
  IP2Bus_Data  <= slv_ip2bus_data when slv_read_ack = '1' else
                  (others => '0');

  IP2Bus_WrAck <= slv_write_ack;
  IP2Bus_RdAck <= slv_read_ack;
  IP2Bus_Error <= '0';

end IMP;

 

 

 

 

 

LOG warnings:

 

Checking expanded design ...
WARNING:NgdBuild:478 - clock net util_vector_logic_0_Op1_pin_BUFGP with clock
   driver util_vector_logic_0_Op1_pin_BUFGP/BUFG drives no clock pins
...

 

WARNING:Pack:2912 - The LUT-1 inverter
   "system_i/util_vector_logic_0/util_vector_logic_0/Res1_INV_0" failed to join
   the "OLOGICE2" comp matched to output buffer
   "util_vector_logic_0_Res_pin_OBUF".  This may result in suboptimal timing.
   The LUT-1 inverter
   system_i/util_vector_logic_0/util_vector_logic_0/Res1_INV_0 drives multiple
   loads.

...

**************************
Generating Clock Report
**************************

+---------------------+--------------+------+------+------------+-------------+
|        Clock Net    |   Resource   |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
|system_i/processing_ |              |      |      |            |             |
| system7_0_FCLK_CLK0 |BUFGCTRL_X0Y31| No   |   87 |  0.240     |  1.892      |
+---------------------+--------------+------+------+------------+-------------+
|system_i/xt_dac_test |              |      |      |            |             |
|_manager_0/xt_dac_te |              |      |      |            |             |
|st_manager_0/USER_LO |              |      |      |            |             |
|GIC_I/slv_reg2[1]_sl |              |      |      |            |             |
|   v_reg2[1]_OR_17_o |         Local|      |   10 |  0.640     |  1.004      |
+---------------------+--------------+------+------+------------+-------------+
|util_vector_logic_0_ |              |      |      |            |             |
|        Res_pin_OBUF |         Local|      |    9 |  0.592     |  1.145      |
+---------------------+--------------+------+------+------------+-------------+

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
6,337 Views
Registered: ‎05-21-2008

@mcgett wrote:

> as the pin gets reassigned!  It does not show up on L18!

The ZIP file that you sent to me did not have the UCF constraint file correctly assigned in the PlanAhead project which is why it ended up on another pin.  With the constraint file added it was on the right pin (L18).

 

 

>  Are you saying this is ok?  I can use the design?  It won't crash and burn with all those *critical* warnings?

I don't know what the other warning are, so I don't know.  Please post the impl_1/runme.log and synth_1/runme.log files for that design implemenation.

 

> Are you also saying the Vivado 2014.2 handles the sofware issues properly?

What I said was that ISE tools are not being updated.  In particular with the Zynq family the Vivado tools have a more robust implementation for the processor subsystem along with updates for the AXI peripherals.  At the very least you must update to ISE 14.7 as ISE 14.4 does not have the production speed files as documented in the 7Z020 data sheet, DS187.

 

> We have a remote consultant that refuses to use Vivado,

You may want to find a new consultant because they are falling behind the curve.


 

    #1,  Based on your comment, I moved the pin assignments from system.ucf to system.ucf, and it routed properly, without errors.

 

   #2  I now believe that, because I had the pin assignments in system.ucf, instead of system.ucf, that XST was not wanting to use those pin assignments.  Once I moved the files from system.ucf to system.ucf, Plan Ahead was able to handle it.

 

   #3.  As I stated before 14.7 screws up the software files, and as you indicated, it won't be fixed.  The code I'm working on will not hit production, it is only for testing our analog front end.  Unfortunately, with an SOC, the software is an important part of the system, not an afterthought.    The consultant is using 14.7, so we may be able to steal the software files from 14.4 and build the system for production in 14.7

 

   #4.  I'll let you tell my boss that.  I'm not going to jeapordize my job with that suggestion.  This consultant is brilliant in his field, which is not Xilinx tool centric.

 

thanks,

Wade

 

P.S.  Assuming a project named "system", Plan Ahead opens XPS to build the system fabric ip.  It appears to be improper to place the pin assignments inside the system.ucf that XPS points to, although you *must* use XPS's system.mhs.  The XST run looks at XPS's system.ucf, but appears to only use that as a "suggestion."  The system.ucf file that Plan Ahead uses is the "proper" one to use.  That is what was throwing me.

 

 

 

 

 

 

 

View solution in original post

0 Kudos
7 Replies
Highlighted
Xilinx Employee
Xilinx Employee
4,736 Views
Registered: ‎01-03-2008

Please post the entire log file as an attachment.

 

Note: You should not place an inverter between the input buffer and the BUFG as this will result no longer have predicatable timing.  The inversion should take place after the BUFG so that it can be propogated to the local inversions in registers.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Highlighted
Observer
Observer
4,723 Views
Registered: ‎05-21-2008

 

   I could not find a log file. I found a directory with the name "log" but it had no files in it.

 

  Attached is my entire project, zipped.  It is a plan-ahead project.  It only has 3 components after the processor system.

 

  This is not a project to chase down timing issues, it is a project to get L18 used as an input pin.  Yes, I understand there could be timing issues there,  I am *trying* to wrestle Xilinx to the ground and get a pin connected.

 

wade

 

0 Kudos
Highlighted
Observer
Observer
4,715 Views
Registered: ‎05-21-2008

 

  I finally got a placement of L18, but I'm not sure it was a good thing, as the warning message still exists.

 

  XST has a bug in it (and it is still in 14.7, there is no indication this will ever be fixed) that causes it to insert a BUFG for a local clock signal that does not require it when ChipScope is being used.  (I suspect I found another situation where it happens.)

 

   The answer record #42228 (http://www.xilinx.com/support/answers/42228.html#description) says you have to do 2 things: 1) turn of read_cores  in XST, and 2) set attribute of buffer_type to none.

 

    So, I did the #2 first:

 

 attribute BUFFER_TYPE: string;
 attribute BUFFER_TYPE of CLK_XMIT_DAC : signal is "none";

   And the BUFG is still being placed.

 

   So, I did #1, in plan_ahead, "synthesis settings", "More Options" "-read_cores no".

 

   It then placed L18 as an input pin, but I still get the Critical Warning, and I have 64 critical warnings instead of 4.

 

   I suspect I did not get anywhere on this one.

 

   How Do I bring in a user clock (16mhz) into my IP without XST putting a BUFG into the design?  For this particular use, I don't need a BUFG, it isn't being shared with anything else, I don't care about skew or other timing issues.  In my case, a little skew would be beneficial, actually.

 

   If you are an expert, my previous post has the project.  It is a hack-a-day project that illustrates the problem and will not be used in production.  I *just* need L18 used, and from the looks of it, NO BUFG, but I need to use the signal as a clock into my ip.  It looks like the 42228 answer is not applicable in this instance.

 

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,710 Views
Registered: ‎01-03-2008

Using the ZIP file that you posted I noticed that the UCF file was not being correctly applied and that the IO that you wanted on L18 was not constrained.  I added the UCF that was in the ZIP to the project and found the same behavior, a warning was issued for L18 constraint on the BUFG and that the IO was placed in the L18 site.  

 

I think that this is do to a BUFGP, an obsolete cell from very early architectures that is implemented as an IBUF and BUFG, that is somehow inferred in your design.  The L18 constraint on the top level port is then being applied to both the IBUF and BUFG causing the warning to be generated, but still resulting in the correct behavior.  The ISE tool chain is no longer in active development and this issue is not critical enough to result in a patch.   So, just ignore the warning.

 

You should really move to the Vivado 2014.2 tool chains for your Zynq development.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Highlighted
Observer
Observer
4,708 Views
Registered: ‎05-21-2008

 

  Unfortunately, with standard behavior, I cannot ignore the warning, as the pin gets reassigned!  It does not show up on L18!

 

  If I do the other thing, which kept it on L18, I get 63 critical warnings, in addition to the BUFG warning.

 

  Are you saying this is ok?  I can use the design?  It won't crash and burn with all those *critical* warnings?

 

 

 

  Are you also saying the Vivado 2014.2 handles the sofware issues properly?  We have a remote consultant that refuses to use Vivado, and I'm not at the level of being able to handle two different Xilinx frameworks at the current time.

 

 

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,705 Views
Registered: ‎01-03-2008

> as the pin gets reassigned!  It does not show up on L18!

The ZIP file that you sent to me did not have the UCF constraint file correctly assigned in the PlanAhead project which is why it ended up on another pin.  With the constraint file added it was on the right pin (L18).

 

>  Are you saying this is ok?  I can use the design?  It won't crash and burn with all those *critical* warnings?

I don't know what the other warning are, so I don't know.  Please post the impl_1/runme.log and synth_1/runme.log files for that design implemenation.

 

> Are you also saying the Vivado 2014.2 handles the sofware issues properly?

What I said was that ISE tools are not being updated.  In particular with the Zynq family the Vivado tools have a more robust implementation for the processor subsystem along with updates for the AXI peripherals.  At the very least you must update to ISE 14.7 as ISE 14.4 does not have the production speed files as documented in the 7Z020 data sheet, DS187.

 

> We have a remote consultant that refuses to use Vivado,

You may want to find a new consultant because they are falling behind the curve.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Highlighted
Observer
Observer
6,338 Views
Registered: ‎05-21-2008

@mcgett wrote:

> as the pin gets reassigned!  It does not show up on L18!

The ZIP file that you sent to me did not have the UCF constraint file correctly assigned in the PlanAhead project which is why it ended up on another pin.  With the constraint file added it was on the right pin (L18).

 

 

>  Are you saying this is ok?  I can use the design?  It won't crash and burn with all those *critical* warnings?

I don't know what the other warning are, so I don't know.  Please post the impl_1/runme.log and synth_1/runme.log files for that design implemenation.

 

> Are you also saying the Vivado 2014.2 handles the sofware issues properly?

What I said was that ISE tools are not being updated.  In particular with the Zynq family the Vivado tools have a more robust implementation for the processor subsystem along with updates for the AXI peripherals.  At the very least you must update to ISE 14.7 as ISE 14.4 does not have the production speed files as documented in the 7Z020 data sheet, DS187.

 

> We have a remote consultant that refuses to use Vivado,

You may want to find a new consultant because they are falling behind the curve.


 

    #1,  Based on your comment, I moved the pin assignments from system.ucf to system.ucf, and it routed properly, without errors.

 

   #2  I now believe that, because I had the pin assignments in system.ucf, instead of system.ucf, that XST was not wanting to use those pin assignments.  Once I moved the files from system.ucf to system.ucf, Plan Ahead was able to handle it.

 

   #3.  As I stated before 14.7 screws up the software files, and as you indicated, it won't be fixed.  The code I'm working on will not hit production, it is only for testing our analog front end.  Unfortunately, with an SOC, the software is an important part of the system, not an afterthought.    The consultant is using 14.7, so we may be able to steal the software files from 14.4 and build the system for production in 14.7

 

   #4.  I'll let you tell my boss that.  I'm not going to jeapordize my job with that suggestion.  This consultant is brilliant in his field, which is not Xilinx tool centric.

 

thanks,

Wade

 

P.S.  Assuming a project named "system", Plan Ahead opens XPS to build the system fabric ip.  It appears to be improper to place the pin assignments inside the system.ucf that XPS points to, although you *must* use XPS's system.mhs.  The XST run looks at XPS's system.ucf, but appears to only use that as a "suggestion."  The system.ucf file that Plan Ahead uses is the "proper" one to use.  That is what was throwing me.

 

 

 

 

 

 

 

View solution in original post

0 Kudos