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
