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
Observer matt_marti09
Observer
10,671 Views
Registered: ‎08-27-2012

Chipscope multiple ILA Instance Issue

Jump to solution

 

In order to verify the sync between two bRAM instances, I created two instances of Chipscope with the following code:

 

component icon_arbitrator   PORT (     CONTROL0 : INOUT STD_LOGIC_VECTOR(35 DOWNTO 0);   CONTROL1 : INOUT STD_LOGIC_VECTOR(35 DOWNTO 0)); end component;

component ila_arbitrator   PORT (     CONTROL : INOUT STD_LOGIC_VECTOR(35 DOWNTO 0);   CLK     : in    std_logic := 'X';     TRIG0   : IN STD_LOGIC_VECTOR(15 downto 0)); end component;

 

icon_cont_inst : icon_arbitrator
  port map (
    CONTROL0 => CONTROL0,
  CONTROL1 => CONTROL1);
 
ila_msdpd_inst : ila_arbitrator  --this chipscope instance takes up a lot of RAM space. It would be best removed after initial testing
  port map (
    CONTROL => CONTROL0,
    CLK => clk_368,
    TRIG0 => TRIG0);       
 
 
ila_fmc_inst : ila_arbitrator  --this chipscope instance takes up a lot of RAM space. It would be best removed after initial testing
  port map (
    CONTROL => CONTROL1,
    CLK => clk_245_fmc_dac,
    TRIG0 => TRIG1);   

 

TRIG1 <= fmc_addrb;
TRIG0 <= addr_368;

 

These are just the port maps, data, and instantiation there is too much code to post it all.  I used the trigger same as data option in Chipscope.   On the first run, I saw that the last three bits of data were missing in both addresses.  They are both 16 bits and only counted up to 2^13(8192).  Now there may be errors in my code, but I have done other tests with each RAM seperately and not seen any problems.  Then, I made some changes to the code to make sure that the addresses count up to 2^16 by setting an end address to "1111111111111111" and:

 

if addr_368 < end addr then

adress++;

end;

Sudo code above. I then ran Chipscope and saw, "waiting for core to be armed, slow or stopped clock".  

Any suggestions?  Am I doing something wrong? Thanks!

 

Matt Martinez 

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
15,412 Views
Registered: ‎01-03-2008

Re: Chipscope multiple ILA Instance Issue

Jump to solution

> I changed the differential buffer from LVDS_25 to DEFAULT just as a test, and there are no more clock problems.


The use of an IOSTANDARD with a IBUFDS input buffer is more of a placebo than a requirement.  My guess is that something else in your design or system changed at the same time that fixed the clock.  If you really wanted to confirm this then you should open up the working design in FPGA Editor and set the IOSTANDARD to LVDS_25 on this buffer, save the NCD to a new file, generate a bitstream and retest.  I am 100% certain that you will get the same working result.

 

Ok, so if that isn't it then what is it?   Looking at the additional material that you posted I see the use of IDELAY on the clock input and that this output goes to a MMCM with only one output.   Is this really necessary?  I can understand the use of a MMCM to improve IO timing, but adding a variable IDELAY in front of it I have never seen before.  If you are using trying to dynamically align this interface is the MMCM necessary.

 

My guess on the root cause, is that the MMCM reset (cpu_reset) is being asserted in your design.

------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
8 Replies
Observer matt_marti09
Observer
10,657 Views
Registered: ‎08-27-2012

Re: Chipscope multiple ILA Instance Issue

Jump to solution

**Update**

 

It seems that the problem is not the double ILA instances.  I removed one and setup Chipscope the way I normally do.

Then I changed this section of code

 

if addr < "111111111111" then

addr++

 

and I got the error again.  I changed this back and it worked again...This is the problem area...I think maybe I am maxing the fanout of the clock??? thanks for any and all help!

Matt

 

0 Kudos
Xilinx Employee
Xilinx Employee
10,652 Views
Registered: ‎01-03-2008

Re: Chipscope multiple ILA Instance Issue

Jump to solution

> I think maybe I am maxing the fanout of the clock???

This simply cannot happen.

 

The waiting for the core to be ARMED is an indication that the clock is not active.  You should check the synthesis report file to see the difference in the WARNING messages between the two versions of your code.

------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
Observer matt_marti09
Observer
10,647 Views
Registered: ‎08-27-2012

Re: Chipscope multiple ILA Instance Issue

Jump to solution

You are right.  The clock is not meeting the contraint.  I got the following message regarding the clock used and it has many paths.

Timing constraint: TS_Inst_ml605_fmc150_mmcm_dac_inst_clkout0 = PERIOD TIMEGRP         "Inst_ml605_fmc150_mmcm_dac_inst_clkout0" TS_CLK_TO_FPGA_P * 0.5 HIGH         50%;

  4440 paths analyzed, 1618 endpoints analyzed, 55 failing endpoints 
  55 timing errors detected. (55 setup errors, 0 hold errors, 0 component switching limit errors) 
  Minimum period is   4.788ns. 
0 Kudos
Observer matt_marti09
Observer
10,646 Views
Registered: ‎08-27-2012

Re: Chipscope multiple ILA Instance Issue

Jump to solution

I know that it has failing endpoints. This clock is generated from a DAC clock using clock wizard.  I don't really understand the error message.  What would cause this and do you have any suggestions for a fix?

0 Kudos
Observer matt_marti09
Observer
10,640 Views
Registered: ‎08-27-2012

Re: Chipscope multiple ILA Instance Issue

Jump to solution

Also, it is weird because 13 of 16 bits work in the address, which means the clock is working, but on 3 bits I get nothing

0 Kudos
Xilinx Employee
Xilinx Employee
10,623 Views
Registered: ‎01-03-2008

Re: Chipscope multiple ILA Instance Issue

Jump to solution

Your posts are not clearly communicating the issues that you are facing, but it sounds like the clock is working as your latest post does not mention that the ILA core did not arm.

 

> I know that it has failing endpoints. This clock is generated from a DAC clock using clock wizard.

My earlier post about checking for WARNINGs was meant to refer to the synthesis and MAP reports.   However, since you mentioned a DAC clock it could be that input clock is not functioning correctly causing the MMCM to not lock.  Adding a proper reset to your system might fix the missing clock problem.

 

> Also, it is weird because 13 of 16 bits work in the address, which means the clock is working, but on 3 bits I get nothing

 

In a previous post you said that you had this code:

> if addr < "111111111111" then addr <= addr + 1;

 

That would be 10 bits, so I'm surprised that 13 bits are working.

------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
Observer matt_marti09
Observer
10,612 Views
Registered: ‎08-27-2012

Re: Chipscope multiple ILA Instance Issue

Jump to solution

mcgett,

 

Yes my previous posts were very unclear.  I am on a stressful schedule so sometimes I get frantic to finish the projects

by deadline.  I have done a few tests, and it seems you are right about the MMCM having an issue.  I am still learning VHDL and the rules of digital design.  I am building on top of the code written by other students.  The clock used for the MMCM is as follows:

 

mmcm_dac_inst : mmcm_dac
port map (
  clk_in1   => clk_to_fpga,
  clk_out1  => clk_fpga_245_76MHz, --the clock we use for a BRAM that is fed to FMC DAC
  reset     => cpu_reset,
  locked    => mmcm_dac_locked

);

 

 

And clk to FPGA is generated as follows:

 

ibufds_ref_clk : ibufds
generic map (
  IOSTANDARD => "LVDS_25",
  DIFF_TERM => TRUE
)
port map (
  i  => clk_to_fpga_p,
  ib => clk_to_fpga_n,
  o  => clk_to_fpga_in
);
iodelay_fpga_inst : iodelaye1
generic map (
  IDELAY_TYPE    => "VAR_LOADABLE",
  IDELAY_VALUE   => CLK_IDELAY,
  SIGNAL_PATTERN => "CLOCK",
  DELAY_SRC      => "I"
)
port map (
  idatain     => clk_to_fpga_in,
  dataout     => clk_fpga_dly,
  c           => clk_100MHz,
  ce          => '0',
  inc         => '0',
  datain      => '0',
  odatain     => '0',
  clkin       => '0',
  rst         => delay_update,
  cntvaluein  => clk_cntvaluein,
  cntvalueout => clk_cntvalueout_fpga,
  cinvctrl    => '0',
  t           => '1'
);
-- Make sure the clock is routed on a global net
bufg_fpga_inst : bufg
port map (
  i  => clk_fpga_dly,
  o  => clk_to_fpga
);

 

 

I changed the differential buffer from LVDS_25 to DEFAULT just as a test, and there are no more clock problems.  I also tried using a "BUFR" with "BYPASS" option, and the system works. We have no buffers selected for MMCM clk input. I need the clocks for both the RAM read and FMC DAC.  The DAC works with this clock but does not when set to DEFAULT.  How will the MMCM treat the clock since it is LVDS and what affect does this have on the output clocks?  

0 Kudos
Xilinx Employee
Xilinx Employee
15,413 Views
Registered: ‎01-03-2008

Re: Chipscope multiple ILA Instance Issue

Jump to solution

> I changed the differential buffer from LVDS_25 to DEFAULT just as a test, and there are no more clock problems.


The use of an IOSTANDARD with a IBUFDS input buffer is more of a placebo than a requirement.  My guess is that something else in your design or system changed at the same time that fixed the clock.  If you really wanted to confirm this then you should open up the working design in FPGA Editor and set the IOSTANDARD to LVDS_25 on this buffer, save the NCD to a new file, generate a bitstream and retest.  I am 100% certain that you will get the same working result.

 

Ok, so if that isn't it then what is it?   Looking at the additional material that you posted I see the use of IDELAY on the clock input and that this output goes to a MMCM with only one output.   Is this really necessary?  I can understand the use of a MMCM to improve IO timing, but adding a variable IDELAY in front of it I have never seen before.  If you are using trying to dynamically align this interface is the MMCM necessary.

 

My guess on the root cause, is that the MMCM reset (cpu_reset) is being asserted in your design.

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