Hi, Jason, Looking at the recent commit activity for tcpborphserver2, it seems like a lot of instrument-specific functionality is being added, which moves it away from being a general purpose "BORPH over TCP/IP" utility. If everybody adds their own instrument-specific functionality to tcpborphserver2, it will become quite bloated and confusing. Do you guys have any plans to support loadable modules to allow users to load design-specific functionality dynamically into tcpborphserver2 (e.g. upon programming a new bitstream into the FPGA)?
Thanks, Dave On Oct 15, 2010, at 4:25 AM, Jason Manley wrote: > Hi Sean > > We are not writing to the DRAM in any of our current designs and so I haven't > tested this myself with the latest tcpborphserver. Nothing *should* have > changed between versions. We'll check it out and get back to you. > > Thanks for bringing this to our attention. > > Jason > > On 14 Oct 2010, at 18:38, [email protected] wrote: > >> Dear Casper, >> >> We recently upgraded to the newest version of tcpborphserver >> (tcpborphserver-2.3304 2010-08-27) and have discovered that we can no >> longer write to DRAM. Specifically, tcpborphserver crashes on the roach >> when we try to use the Python KATCP command write('dram_memory', data). >> We switched back to the previous version, >> tcpborphserver2-2010-04-02-tgtap, and it works. Both versions also work >> when writing to registers or BRAM. >> >> We're running the latest versions of software according to: >> http://casper.berkeley.edu/wiki/LatestVersions. And we updated >> tcpborphserver according to Henry Chen's email: >> http://www.mail-archive.com/[email protected]/msg01878.html. >> >> Any thoughts? >> >> >> Thanks, >> Sean McHugh >> >> >> >> > >
