cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jmonteiro-dme
Explorer
Explorer
10,071 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
jmonteiro-dme
Explorer
Explorer
12,405 Views
Registered: ‎05-15-2009
Solved, the uB reset is set as active high.

View solution in original post

0 Kudos
8 Replies
jagron
Adventurer
Adventurer
10,062 Views
Registered: ‎01-04-2008

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
jmonteiro-dme
Explorer
Explorer
10,057 Views
Registered: ‎05-15-2009

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
bassman59
Historian
Historian
10,049 Views
Registered: ‎02-25-2008

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
jmonteiro-dme
Explorer
Explorer
10,044 Views
Registered: ‎05-15-2009

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
jmonteiro-dme
Explorer
Explorer
10,008 Views
Registered: ‎05-15-2009
any one?
0 Kudos
xiaofeip
Xilinx Employee
Xilinx Employee
9,957 Views
Registered: ‎08-07-2007

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
jmonteiro-dme
Explorer
Explorer
12,406 Views
Registered: ‎05-15-2009
Solved, the uB reset is set as active high.

View solution in original post

0 Kudos
200982
Adventurer
Adventurer
7,038 Views
Registered: ‎10-27-2011

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