Thanks, Jason. I think we may have found the problem and, as you say, it's not related to reading the shared BRAM. We actually have four roach boards connected to a switch. One of the boards has a problem with its 1 Gbe nic and was only able to connect at 100 Mb/s. It was also sending out lots of corrupted packets, which is what we were seeing. We've swapped that roach out with a spare and now everything seems to be working fine. Despite this, I think we'll still take a closer look at how we're reading the BRAM.
Thanks, again. Sean > No, the shared BRAM is a dual-ported RAM with independent access from the > PPC and from fabric. If you try'n read from the same address that is > currently being written, you can choose if you should get the old or the > new value. But I think this is hidden from the Simulink designer. > > What is the nature of the errors? We do this sort of thing pretty > regularly using the tcpborphserver daemon on ROACH and do not have such > problems. > > It might be a caching problem in Linux. Are you flushing writes? And > resetting the file pointers back to the start of the file before > subsequent reads? tcpborphserver should take care of this sort of thing > for you but if you're reading/writing registers in other ways then this > might be worth checking. > > Jason > > > On 25 Jul 2011, at 20:55, mch...@physics.ucsb.edu wrote: > >> Hi CASPER, >> >> We have a simple python TCP server running on a roach board's PPC. It >> reads a shared software register that acts like an address pointer for >> data in a shared BRAM; just like in the "snap" block. When the address >> gets to a certain value, the server reads the data in the BRAM using the >> python command "read()." We're seeing some rare, but important errors >> in >> the data collected this way which prompts this question: Is this python >> command read() blocking the data from being written to the shared BRAM >> by >> the fpga? If so, is there a way around that? >> >> >> thanks, >> >> Sean >> >> > > >
