Address sensitive process, Xilinx virtex2pro

hi, i'm trying to write a process that is sensitive to a given
address,
i wrote something like this:

my_proc: process (Bus2ip_Clk)
begin
  if (Bus2ip_Addr = X"some address") then
  Bus2ip_Data <= X"FF00FF00";
  end if;
end process;

basicly i what i want is: if i try to read this given address (using
Xio_In32 function) i will read      0xFF00FF00.
The address that i'm comparing Bus2ip_Addr to is well in the address
space that my IP received and not used by any other process (the base
address of my IP is used for software register though but i'm taking a
far enough address).
The problem is that evry time that i read from this address i read 0.

what i'm doing wrong?
Thanks.

ps. writing and reading from the software register works perfectly.

Add this:
> my_proc: process (Bus2ip_Clk)
> begin
  if( Bus2ip_clk'event and Bus2ip_Clk='1') then
>  if (Bus2ip_Addr = X"some address") then
>  Bus2ip_Data <= X"FF00FF00";
>  end if;
end if ;
> end process;
>

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:13eebgov3qke76@corp.supernews.com...
> Add this:
>> my_proc: process (Bus2ip_Clk)
>> begin
>  if( Bus2ip_clk'event and Bus2ip_Clk='1') then
>>  if (Bus2ip_Addr = X"some address") then
>>  Bus2ip_Data <= X"FF00FF00";
>>  end if;
> end if ;
>> end process;
>>
>
>
Naah,
This is better.
> my_proc: process (Bus2ip_Clk)
> begin
  if rising_edge(Bus2ip_Clk) then
>  if (Bus2ip_Addr = X"some address") then
>  Bus2ip_Data <= X"FF00FF00";
>  end if;
end if ;
> end process;
>
HTH., Syms.

Taking a guess, it looks like you are using Xilinx, and taking another
guess, you may have created your core using the Xilinx Create
Peripheral Wizard.

If you did, one thing to look out for is the USER_HIGHADDR.  Depending
on what options you choose int the Peripheral Wizard, in the core
wrapper file the USER_HIGHADDR could be being set with the following
line (syntax purposefully abbreviated).

USER_HIGHADDR : stl := C_BASEADDR or X"000000FF";

Which has the annoying effect of only allowing 256 byte addresses.  If
you are trying to read an address within your core above xFF, the IPIF
returns 0 for you.

In my cores, when I see this I always just change this line to read
USER_HIGHADDR : stl := C_HIGHADDR;

Hope this helps.

Erik

 > sensitive to a given address

means to me:

> --my_proc: process (Bus2ip_Clk)
> my_proc: process (Bus2ip_Addr)

?

Yes, Symon, that's shorter.

On Sep 12, 12:53 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> Yes, Symon, that's shorter.

Have you thought about what happens to bus2ip_data before the magic
address is hit? What about after it has been hit?

What else (if anything) is driving bus2ip_data? If nothing,
bus2ip_data will be (others => 'U') before, and X"FF00FF00" after,
forevermore.

If something else is driving data, then a (others => 'X') will almost
certainly result.

Andy

> Have you thought about what happens to bus2ip_data before the magic
> address is hit? What about after it has been hit?

No, I had not thought of it. I was just correcting the obvious
lack of a clk if-then and hopefully explaining why he got zeroes.
Perhaps, there is another driver.

> What else (if anything) is driving bus2ip_data? If nothing,
> bus2ip_data will be (others => 'U') before, and X"FF00FF00" after,
> forevermore.
>
> If something else is driving data, then a (others => 'X') will almost
> certainly result.
>
> Andy
> 

On Sep 12, 2:20 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> > Have you thought about what happens to bus2ip_data before the magic
> > address is hit? What about after it has been hit?
>
> No, I had not thought of it. I was just correcting the obvious
> lack of a clk if-then and hopefully explaining why he got zeroes.
> Perhaps, there is another driver.
>
> > What else (if anything) is driving bus2ip_data? If nothing,
> > bus2ip_data will be (others => 'U') before, and X"FF00FF00" after,
> > forevermore.
>
> > If something else is driving data, then a (others => 'X') will almost
> > certainly result.
>
> > Andy

Sorry Brad, my reply was meant for the OP instead of you.

Andy

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:13ega7ucrfkr521@corp.supernews.com...
> Yes, Symon, that's shorter.
>
Hi Brad,
There's a little bit more to it than that. For synthesis, the two forms are 
identical, I think. However, for simulation, IIRC, the rising_edge form is 
'better' because it only triggers when the clock changes from '0' to '1'. 
The other form triggers when the signal changes from anything, e.g. 'Z' or 
'U', to '1'.

But it is shorter too! :-)
Cheers, Syms.