Hi all,
FWIW, I use these snapshots extensively on ROACH2 and have not had any
issues. However I'm still compiling using 11.x and still running
tcpborphserver2.
Best,
Rurik
On 12/7/2012 2:41 AM, Henno Kriel 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 <[email protected]
<mailto:[email protected]>> 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
