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
Explorer
Explorer
9,829 Views
Registered: ‎05-15-2009

bus2IP_Reset and custom core strange behaviour

Jump to solution

Hello,

I have a strange behaviour in a custom IP core. First, i don't understand why it's busIP_Reset starts high, comes low for about 4 busIP_clk cycles and then goes high again. Where is this signal driven and what is its purpose? I mean, why is it allways high in my simulation?

 

Other thing is the if statement in the core. I have a process with a very simple code to generate interrupts only when an external signal (FEDATA_ACK) is high:

 

 

  if ( rising_edge(Bus2IP_Clk) ) then
            
     if ( Bus2IP_Reset = '1' ) then
         IP2Bus_IntrEvent <= (others => '0');
     else
         if  FEDATA_ACK = '1' then
                IP2Bus_IntrEvent <= (others => '1');      
                elsif FEDATA_ACK = '0' then
                IP2Bus_IntrEvent <= (others => '0');
          end if;
       end if;
    end if;

 

The issue is that if I remove the "elsif FEDATA_ACK = '0' then" statement and its "IP2Bus_IntrEvent <= (others => '0');", interrupts are generated However if I change the state of a test signal, say testsignal <= '1' insithe the "if" statement, it does not change, at least in simulation. Also, if I include the elsif part of the statement above, interrupts are never generated. The sensitivity list of the process includes the bus2IP_clk and FEDATA_ACK. Why this behaviour? Note that I checked that FEDATA_ACK is arriving good to the IP core.

 

Best,

JM

Message Edited by jmonteiro-dme on 06-02-2009 07:42 AM
Message Edited by jmonteiro-dme on 06-02-2009 07:44 AM
Message Edited by jmonteiro-dme on 06-02-2009 07:46 AM
0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
12,163 Views
Registered: ‎05-15-2009

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution
Solved, the uB reset is set as active high.
0 Kudos
8 Replies
Adventurer
Adventurer
9,820 Views
Registered: ‎01-04-2008

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution

I would recommend using an if-else instead of an if-elsif in your code.  Additionally, simulation results may optimize out un-used signals such as your "testsignal".

 

Is your bus configured to have an active-low reset instead of active-high?

 

-Jason

0 Kudos
Explorer
Explorer
9,815 Views
Registered: ‎05-15-2009

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution

Thank you.

 

Checked the C_EXT_RESET_HIGH of clock_generator and it's 1 (active high). I'm using UART (interrupt handler sends xil_print) to test the interrupt generation:

 

1) May this device be sow slow that if I enable/disable itnerrupts within a half of period of a signal they don't appear in hyperterminal?

 

2) I guess the simulator is not simulating the core driven signals. For instance, intr_counter, which drives IP2Bus_IntrEvent is allways low in the simulator even if I see interrupt's xil_printf in hyperterminal, which can't be. Am I right?

0 Kudos
Historian
Historian
9,807 Views
Registered: ‎02-25-2008

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution

jmonteiro-dme wrote:

Thank you.

 

Checked the C_EXT_RESET_HIGH of clock_generator and it's 1 (active high). I'm using UART (interrupt handler sends xil_print) to test the interrupt generation:

 

1) May this device be sow slow that if I enable/disable itnerrupts within a half of period of a signal they don't appear in hyperterminal?

 

2) I guess the simulator is not simulating the core driven signals. For instance, intr_counter, which drives IP2Bus_IntrEvent is allways low in the simulator even if I see interrupt's xil_printf in hyperterminal, which can't be. Am I right?


 

What is the source of the reset signal? If it's driven by a DCM locking, then it's possible that the DCM isn't locked and everything remains in reset.  What is the clock frequency?

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Explorer
Explorer
9,802 Views
Registered: ‎05-15-2009

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution

Thank you very much for your attention.

 

Yes, it's driven by a DCM. The xmp project is "fed" by the clk100MHz_i, right out of the DCM. The system_reset_pin of the xmp project is connected to the DCM's reset. I suppose that once driven by an input clock, the DCM starts giving its outputs automaticaly (after the initialization time), right? I didn't understand why do you say "it's possible that the DCM isn't locked and everything remains in reset"? In this case, what do I have to do? Note that in ISE simulator I can see the clock signal feeding the microblaze pulsing..

0 Kudos
Explorer
Explorer
9,766 Views
Registered: ‎05-15-2009

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution
any one?
0 Kudos
Xilinx Employee
Xilinx Employee
9,715 Views
Registered: ‎08-07-2007

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution

Do you have proc_sys_reset module in your system? What's the parameter C_EXT_RESET_HIGH set for this core?

 

-XF

0 Kudos
Explorer
Explorer
12,164 Views
Registered: ‎05-15-2009

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution
Solved, the uB reset is set as active high.
0 Kudos
Adventurer
Adventurer
6,796 Views
Registered: ‎10-27-2011

Re: bus2IP_Reset and custom core strange behaviour

Jump to solution

I know this is quite an old topic, but I'm facing the same problem.

What do you mean with "uB is set active high". I havent seen a parameter for Microblaze Software-Reset, if that's what you mean.

 

Or is it just  a parameter in iSim? 

0 Kudos