BRAM/XMD strangeness?

I have a V2P chip and am using both PPCs.  Each has its own PLB bus and
each PLB bus is connected to a small dual-ported BRAM (amongst other
things).  The idea is for them to pass messages to each other through
this BRAM, but I was noticing mangled data.  The shared BRAM is
dedicated to this message-passing (no code or other data lives there).
Trying to reduce the problem, I started using XMD to debug.  The two
programs initiallizng the respective programming BRAMs are just a few
lines each now and don't even reference the shared BRAM, so there is no
code accessing  the shared area.  Now when I use XMD (on either
processor), I can read/write the shared BRAM.  The wierdness is that
consecutive reads can give different results.  I am assuming this is
the behavior I was initially seeing with my message-passing program and
isn't a problem with XMD.  The read results are ususally not wildly
different... it is as if a value from one location sort of jumps to an
adjacent location or lives in a couple locations at once, then on the
next read, something variant of this.  Clearly not the behavior I'd
hope for.  When using XMD to fiddle with the off-chip RAM on the board,
it holds values just fine.

I can provide more details if helpful, but I was just wondering if
anyone has any idea what is going on here.  Any advice on how to debug
further would be appreciated.  Unfortunately can't use ModelSim because
of the license requirements on the IBM stuff (PLB bus, etc).  Just
hoping it is something simple I have neglected...

Thanks in advance,
Joey

My next step would be to simulate the design.  What license requirements
are holding you up?  Everything for simulation with Modelsim is
available from Xilinx in EDK/ISE. 

Paul

Joseph wrote:
> 
> I have a V2P chip and am using both PPCs.  Each has its own PLB bus and
> each PLB bus is connected to a small dual-ported BRAM (amongst other
> things).  The idea is for them to pass messages to each other through
> this BRAM, but I was noticing mangled data.  The shared BRAM is
> dedicated to this message-passing (no code or other data lives there).
> Trying to reduce the problem, I started using XMD to debug.  The two
> programs initiallizng the respective programming BRAMs are just a few
> lines each now and don't even reference the shared BRAM, so there is no
> code accessing  the shared area.  Now when I use XMD (on either
> processor), I can read/write the shared BRAM.  The wierdness is that
> consecutive reads can give different results.  I am assuming this is
> the behavior I was initially seeing with my message-passing program and
> isn't a problem with XMD.  The read results are ususally not wildly
> different... it is as if a value from one location sort of jumps to an
> adjacent location or lives in a couple locations at once, then on the
> next read, something variant of this.  Clearly not the behavior I'd
> hope for.  When using XMD to fiddle with the off-chip RAM on the board,
> it holds values just fine.
> 
> I can provide more details if helpful, but I was just wondering if
> anyone has any idea what is going on here.  Any advice on how to debug
> further would be appreciated.  Unfortunately can't use ModelSim because
> of the license requirements on the IBM stuff (PLB bus, etc).  Just
> hoping it is something simple I have neglected...
> 
> Thanks in advance,
> Joey

Thanks for the quick reply Paul,

I went through trying to get the necessary tools to simulate the PLB
bus using the BFM (bus functional model?) stuff a while ago.  Turned
out I need a more advanced version of ModelSim than we had... got a
trial version of the PE(?) version which was necessary for the BFM
stuff I think.  That trial ended in 30 days, and since then I haven't
even considered simulating anything.  We are a little behind the times
I guess, just upgraded to EDK 7.1 a couple weeks ago, maybe not so hard
now to get the necessary BFM stuff?  Guess I need to look into it, the
Xilinx modelsim stuff is all a little confusing/frustrating...

Any other advice appreciated...

Joey

Just an update:

Still using XMD, poking other on-chip memory locations, I can see that
they behave normally.  The only obvious difference I see right now is
the fact that I am using both ports in the shared BRAM and not the
others.

Any advice still appreciated!
Joey

Joseph wrote:
> Thanks for the quick reply Paul,
> 
> I went through trying to get the necessary tools to simulate the PLB
> bus using the BFM (bus functional model?) stuff a while ago.  Turned
> out I need a more advanced version of ModelSim than we had... got a
> trial version of the PE(?) version which was necessary for the BFM
> stuff I think.  That trial ended in 30 days, and since then I haven't
> even considered simulating anything.  We are a little behind the times
> I guess, just upgraded to EDK 7.1 a couple weeks ago, maybe not so hard
> now to get the necessary BFM stuff?  Guess I need to look into it, the
> Xilinx modelsim stuff is all a little confusing/frustrating...
> 
> Any other advice appreciated...

You really want to be able to simulate this. The bus functional model is 
not strictly necessary. If all you care about is basic read/write 
accesses, you can create your own model of the PPC that works reasonably 
enough to tell you what is going on. I created one, largely by trial and 
error.

For example, here are a couple of (VHDL) procedures I use. I stick them 
within a test file that is embedded within a wrapper that simply hard 
sets all the unused signals. It looks like I set the "Reset Interface" 
and "Instruction Cache Unit" signals to all '0', and all the rest of the 
unused signals to '1'. The procedures below implement the "Data Cache 
Unit" interface.

       procedure sread(addr : in std_logic_vector(0 to C_PLB_AWIDTH-1)) is
       begin
          wait until rising_edge(PLB_Clk);
          M_request <= '1';
          M_RNW <= '1';
          if addr(29) = '1' then
             M_BE <= X"0F";
          else
             M_BE <= X"F0";
          end if;
          M_size  <= (others => '0');
          M_type  <= (others => '0');
          M_ABus <= addr;
          if PLB_MAddrAck = '0' then
             wait until PLB_MAddrAck = '1';
          end if;
          wait until rising_edge(PLB_Clk);
          M_request <= '0';
          M_RNW <= '0';
          M_BE <= X"00";
          M_ABus <= (others => '0');
          if PLB_MRdDAck = '0' then
             wait until PLB_MRdDAck = '1';
          end if;
          if addr(29) = '1' then
             RD_DATA <= PLB_MRdDBus(32 to 63);
          else
             RD_DATA <= PLB_MRdDBus(0 to 31);
          end if;
          wait until rising_edge(PLB_Clk);
       end procedure sread;

       procedure swrite(addr : in std_logic_vector(0 to 31);
          data : in std_logic_vector(0 to 31)) is
       begin
          wait until rising_edge(PLB_Clk);
          M_request <= '1';
          M_RNW <= '0';
          M_size  <= (others => '0');
          M_type  <= (others => '0');
          M_ABus <= addr;
          if addr(29) = '1' then
             M_BE <= X"0F";
--            M_wrDBus(0 to 31) <= (others => '0');
             M_wrDBus(0 to 31) <= data;
             M_wrDBus(32 to 63) <= data;
          else
             M_BE <= X"F0";
             M_wrDBus(0 to 31) <= data;
--            M_wrDBus(32 to 63) <= (others => '0');
             M_wrDBus(32 to 63) <= data;
          end if;
          if PLB_MAddrAck = '0' then
             wait until PLB_MAddrAck = '1';
          end if;
          wait until rising_edge(PLB_Clk);
          M_request <= '0';
          M_RNW <= '0';
          M_BE <= X"00";
          M_ABus <= (others => '0');
          if PLB_MWrDAck = '0' then
             wait until PLB_MWrDAck = '1';
          end if;
          wait until rising_edge(PLB_Clk);
          M_wrDBus <= (others => '0');
       end procedure swrite;

Joseph,
    You could try to insert Chipscope into your design.  Chipscope is
like a logic analyzer you insert into the FPGA. I think if you capture
a waveform during an anomalous XMD poke/peek sequence, it would shed
light on the problem.  I think a 60 day evaluation comes with the EDK
CD.

-Newman

Thanks for the replys.  It turns out that the funkiness is on a shared
DSOCM BRAM... each processor's DSOCM bus hooks into a dual-ported BRAM,
when I noticed this is how I had set it up months ago, I made the
change for them to share a PLB BRAM instead.  Now there is no odd
behavior.  So, as much as I'd like to know what was going on with that
OCM bus, I'll probably have to just move forward with the new stable
system.  Maybe when I get a break, I will either chipscope or simulate
that odd behavior.  There is probably a lot I don't understand about
the DSOCM business, maybe I forgot to set something somewhere...

Anyway, thanks for the replys, they were all appreciated.

Joey