Hi, I seem to be running into this same problem. Will tcpborphserver2 run on the same linux kernel or do I need to change to a borph specific kernel? Thanks, Glenn
On Fri, Dec 7, 2012 at 2:41 AM, Henno Kriel <he...@ska.ac.za> wrote: > Hi Dave > > I think Andrews point 3 is relevant. > > We have picked up on transient on the register write with the latest memory > mapped TCPBORPH. It seems that sometimes, some of the bits goes high for a > short while and then settles at the required register value. > > We need to figure out where the issue is (gateware or software). > > For now try TCPBORPH server 2 and see if the problem still persist. > > HK > > > On Fri, Dec 7, 2012 at 8:56 AM, Andrew Martens <and...@ska.ac.za> wrote: >> >> Hi Dave >> >> > I am working on ROACH2. >> >> Jason also had a problem with snapshot blocks using ROACH2. His snap >> block would not finish capturing, i.e write 7 into the control register, >> busy bit goes high and byte count spins, but busy bit never goes low >> again! Again, the logic to finish capturing is very simple (counter and >> comparison). He also reports that this behaviour changes with different >> compiles. This may mean that we are missing some crucial timing-related >> constraint. >> >> > When I say they are triggered, I mean that the contents of the BRAM >> > change immediately upon writing 5 to the ctrl register while the trigger >> > input is 0 (i.e. before I set the trigger to 1). >> >> I will assume that the BRAM value changes are caused by snapshot logic >> (the status register reflects a 'busy' snapshot, address changing etc), >> which seems ok as a write to a register connected to logic triggering >> capture causes the values to change. >> >> That means that the snapshot block was enabled, and then triggered. It >> seems as though the enable is happening as expected i.e it does not >> randomly become enabled, but the trigger is premature. The trigger could >> come from three sources >> 1. Some kind of metastability in the triggering logic in the snapshot >> block. This is unlikely as all 4 snapshot blocks are behaving the same. >> >> 2. The bit in the register linked to the trig input on all snapshots is >> toggling high (or held high). This is unlikely (no writes to that >> address) but would indicate some problem in the bus controller (writes >> affect registers not addressed) or register logic (some kind of >> metastability/weirdness). Replicating the register for each snapshot >> block, and replacing some with constants would shed some light. >> >> 3. The ctrl register is misbehaving. If bit 1 somehow goes high for a >> bit before going low, or toggles high for even one cycle, then this >> would generate an internal trigger. This would indicate some systematic >> error in the register logic (occurs in the same way in four different >> registers) or metastability (unlikely again as occurs in multiple >> places). Manually modifying the snapshot block to use bit 0 for the >> trigger and 1 for the enable would be interesting as bit 0 *seems* to be >> behaving (no completely random enabling). >> >> Changing the design would also be interesting as it would be nice to see >> if the problem changes if things are placed differently in the chip. >> >> Regards >> Andrew >> >> >> >> >> >> > > > > -- > Henno Kriel > > DSP Engineer > Digital Back End > meerKAT > > SKA South Africa > Third Floor > The Park > Park Road (off Alexandra Road) > Pinelands > 7405 > Western Cape > South Africa > > Latitude: -33.94329 (South); Longitude: 18.48945 (East). > > (p) +27 (0)21 506 7300 > (p) +27 (0)21 506 7365 (direct) > (f) +27 (0)21 506 7375 > (m) +27 (0)84 504 5050
