1. Home
  2. Field-Programmable Gate Arrays
  3. BRAM/XMD strangeness?

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

Reply to
Joseph
Loading thread data ...

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:

Reply to
Paul Hartke

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

Reply to
Joseph

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

Reply to
Joseph

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

Reply to
Duane Clark

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

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

Reply to
Joseph

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.