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, [email protected] 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 > >
