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
