Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMDS Driver: Make timeout values configurable #396

Open
codecubepi opened this issue May 31, 2024 · 0 comments
Open

AMDS Driver: Make timeout values configurable #396

codecubepi opened this issue May 31, 2024 · 0 comments
Labels
driver Involves the drivers which interface between C firmware and hardware. fpga Involves the FPGA Verilog code. help wanted Anyone can jump in and assist on this issue.

Comments

@codecubepi
Copy link
Contributor

Currently, the AMDS driver (as implemented in firmware v1.3) has hard-coded timeout values. These timeouts are necessary in the case that the timing manager triggers the AMDS to sample (via the SYNC_ADC interrupt), but the AMDS is unable to return data due to an unplugged/faulty/etc data line connection.

If the driver did not have the ability to time out, it would wait forever to receive the data from the AMDS, and never assert that its data acquisition is done, thus freezing the timing manager. Not ideal.

Currently, the trigger-to-first-data-packet timeout is hardcoded to ~10us in amdc_amds_v1_0_S00_AXI.v:

// Timing Out:
// This is a tempermental thing to track... at what point do we give up?
// The state machine in adc_uart_rx begins when the first falling edge is detected
// on the data line, which is taken care of in this module by the start_rx signal.
// So this waiting period should timeout if the trigger_to_fe timer below goes too
// far beyond the expected value of about 5us (Although we will give it 10us, or about
// 2000 clock cycles, to avoid being too aggressive). We will just stop waiting_for_first_fe
// and increment the timeout counter by 4 to show that all four packets failed to send.
// There is also a timeout generated by the uart_rx state machine if it was told to expect
// a start bit, but it doesn't arrive after 2.5us. That timeout increment signal is the
// one passed up into this module.
// In the event of either timeout, the driver must say that it is done, so that the timing
// manager does not freeze.
wire first_packet_timeout0, first_packet_timeout1;
assign first_packet_timeout0 = (trigger_to_fe0_timer > 11'd2000);
assign first_packet_timeout1 = (trigger_to_fe1_timer > 11'd2000);

and the timeout between individual UART bytes is hardcoded to 2.5us in uart_rx.v

// ==============
// Timeout Counter
// ==============
// Wait for a max of 2.5us for the start bit
// after adc_uart_rx
//
// 2.5us = 2500ns = 500 clock cycles
//
// Let's have max of 512, so 9 bit.
reg [8:0] timeout_counter;
reg reset_timeout_counter;
always @(posedge clk, negedge rst_n) begin
if (!rst_n)
timeout_counter <= 9'b0;
else if (reset_timeout_counter)
timeout_counter <= 9'b0;
else
timeout_counter <= timeout_counter + 1;
end

These hardcoded timeout values should be replaced with a way to configure a value in a slave register from the C code.

Relevant Development History:

@codecubepi codecubepi added fpga Involves the FPGA Verilog code. driver Involves the drivers which interface between C firmware and hardware. help wanted Anyone can jump in and assist on this issue. labels May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
driver Involves the drivers which interface between C firmware and hardware. fpga Involves the FPGA Verilog code. help wanted Anyone can jump in and assist on this issue.
Projects
None yet
Development

No branches or pull requests

1 participant