I’m trying to read events directly from the DAVIS240C using the SignalConn connector. I’m using Digilent’s Nexys 3 board with Xlinix Spartan 6 FPGA and I have started by writing a simple verilog code which supposed to only implement the AER async’ handshake with the device without processing the events data at all at this stage; meaning that after receiving a ‘req’ from the device I’m sending an ‘ack’, I’m waiting for ‘req’ to go inactive and then I inactivate the ‘ack’.
It seems like I manage to complete the handshake but for some reason I get very low and fixed rate of events sent from the device no matter what (in the order of 100 events per second).
Do you have any idea what might be the reason for that? What am I doing wrong?
Thank you in advance for your assistance,
Eldad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, was the DAVIS240C camera setup correctly? Even when you take over the DVS bus, the whole camera needs to be setup and biased correctly via USB. Also, the normal DVS state machine needs to be disabled, and the external AER control setting enabled.
You can do this via jAER or cAER.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I used jAER to bias and setup the camera via USB. I disabled the normal DVS state machine and enabled the external AER control option. In case the camera wouldn’t have been configured correctly I would have expected not to get any events but I did get some.
Do you have tested implementation in verilog (or vhdl) of the AER protocol handshake which I can use to test my hardware and configuration?
Thank you,
Eldad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The simples AER state machine we have is this: https://sourceforge.net/p/jaer/code/HEAD/tree/devices/logic/SystemLogic2/common-source/GenericAERStateMachine.vhd
In principle it's a 4-phase handshake with a few extra features such as delays.
An easy test to do on your side is to just redirect REQ to ACK directly and look at the pins with an oscilloscope, you should see the frequency of rising edges correlate with more or less activity in front of the camera. At least that way you know the camera and everything is setup correctly, and your device at least can read the REQ and send the ACK.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will redirect the REQ to ACK and see what I get.
Also, I saw that in your AER state machine code you drive an AERReset signal, should I drive it also in my code? Is it active-low?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, yes it is active-low, but the normal DVS state machine already drives it so that it is always disabled (not in reset), when you enable external AER control, so you don't have to care about it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks,
I’m going to capoccacia next week and I will bring the system with me. Is there going to be anyone there who may be able to have a look at it and help me solve this (assuming I won’t find a solution before)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I remember now as well, that on the DVS128 chip we have a pin "reqdel"
output from the sensor IC that delays the request with inverter chain.
But I don't remember the details about how this is wired up on the PAER
board.
On 4/28/2017 4:14 PM, Federico Corradi wrote:
Solved:
Shorting req/ack signals of the DAVIS240C directly on the pAER does not work as it is required a delay between req and ack of about 40 to 60 ns.
Dear Developers,
I’m trying to read events directly from the DAVIS240C using the SignalConn connector. I’m using Digilent’s Nexys 3 board with Xlinix Spartan 6 FPGA and I have started by writing a simple verilog code which supposed to only implement the AER async’ handshake with the device without processing the events data at all at this stage; meaning that after receiving a ‘req’ from the device I’m sending an ‘ack’, I’m waiting for ‘req’ to go inactive and then I inactivate the ‘ack’.
It seems like I manage to complete the handshake but for some reason I get very low and fixed rate of events sent from the device no matter what (in the order of 100 events per second).
Do you have any idea what might be the reason for that? What am I doing wrong?
Thank you in advance for your assistance,
Eldad
Hi, was the DAVIS240C camera setup correctly? Even when you take over the DVS bus, the whole camera needs to be setup and biased correctly via USB. Also, the normal DVS state machine needs to be disabled, and the external AER control setting enabled.
You can do this via jAER or cAER.
Hi Luca,
I used jAER to bias and setup the camera via USB. I disabled the normal DVS state machine and enabled the external AER control option. In case the camera wouldn’t have been configured correctly I would have expected not to get any events but I did get some.
Do you have tested implementation in verilog (or vhdl) of the AER protocol handshake which I can use to test my hardware and configuration?
Thank you,
Eldad
The simples AER state machine we have is this:
https://sourceforge.net/p/jaer/code/HEAD/tree/devices/logic/SystemLogic2/common-source/GenericAERStateMachine.vhd
In principle it's a 4-phase handshake with a few extra features such as delays.
An easy test to do on your side is to just redirect REQ to ACK directly and look at the pins with an oscilloscope, you should see the frequency of rising edges correlate with more or less activity in front of the camera. At least that way you know the camera and everything is setup correctly, and your device at least can read the REQ and send the ACK.
Thanks Luca!
I will redirect the REQ to ACK and see what I get.
Also, I saw that in your AER state machine code you drive an AERReset signal, should I drive it also in my code? Is it active-low?
Hi, yes it is active-low, but the normal DVS state machine already drives it so that it is always disabled (not in reset), when you enable external AER control, so you don't have to care about it.
Thanks,
I’m going to capoccacia next week and I will bring the system with me. Is there going to be anyone there who may be able to have a look at it and help me solve this (assuming I won’t find a solution before)?
Hi,
yes. Prof Tobi Delbruck and myself will be attending CapoCaccia. We can definitely help you in getting this working.
best,
Federico
Thank you Federico! See you next week.
Solved:
Shorting req/ack signals of the DAVIS240C directly on the pAER does not work as it is required a delay between req and ack of about 20 to 60 ns.
Last edit: Federico Corradi 2017-04-28
I remember now as well, that on the DVS128 chip we have a pin "reqdel"
output from the sensor IC that delays the request with inverter chain.
But I don't remember the details about how this is wired up on the PAER
board.
On 4/28/2017 4:14 PM, Federico Corradi wrote: