Open coretl opened 4 months ago
I've added a timing test in pcap-TS_START-test . However, I cannot replicate this behaviour in the VHDL. @EmilioPeJu Does a change need to be made in the server similar to https://github.com/PandABlocks/PandABlocks-server/issues/37 ?
The relevant change to the FPGA already happened when the start time feature was added. Was this bug introduced after that? if you don't see the problem in the timing tests, it might be a subtle problem that could be investigated with chipscope (or similar)
This current problem is different behaviour to what Glenn reported in #129 (which was fixed by https://github.com/PandABlocks/PandABlocks-server/issues/37), it looks like it's only affecting TS_START whereas it previously affected the entire first capture. I think when the previous problem was fixed, it introduced the current issue (or made the current issue noticeable).
When GATE=ONE
then there will never be a gate_rise
, so it's still set to the last TS.
Can we zero ts_start
on rising enable? Or trigger gate_rise
on rising enable?
It would be nice simplifying that code, though that would require more work(and testing) than just fixing this bug
I've tried putting these changes onto a PandA but it does not seem to have fixed this problem.
Thanks for testing it, I have added two extra lines that will (hopefully) fix it
I've just put the new changes onto a PandA. It still hasn't fixed this.
is it showing exactly the same behaviour? I'm surprised, as soon as enable goes low, it should be clearing ts_start
If![image](https://github.com/PandABlocks/PandABlocks-FPGA/assets/101418278/a3a0c597-02dd-4412-9f8a-4172998e0f37)
PCAP.GATE
andPCAP.ENABLE
are both tied toONE
, like in this diagram:then
TS_START
on the last frame will be leftover from the previous scan rather than being 0: