I have been checking the accuracy of the delay fun...
# mpw-2-silicon
y
I have been checking the accuracy of the delay function, and from the definition of the function the implementation seems to be using the timer0 in single-shot countdown mode. I wrote this code to toggle the Low GPIO chain at
1ms
Copy code
void main()
{
     // Management GPIO Configuration
    reg_gpio_mode1 = 1;
    reg_gpio_mode0 = 0;
    reg_gpio_ien = 1;
    reg_gpio_oe = 1;

    // User GPIO Configuration
    set_registers();
    gpio_config_io();

    while (1)
    {
        
            reg_mprj_datal = 0x00000000; // GPIO0 - GPIO31 High
            delay(10000);        // Delay
            reg_mprj_datal = 0xffffffff; // GPIO0 - GPIO31 Low
            delay(10000);        // Delay
        
    }
}
and from observing the output on a logic analyser it seems to be really off. I have attached a screenshot of the same. Seems like an interesting issue and would love to know the reason behind this. I appreciate any insights on the same.Thanks for all the insights and help.
t
The counter/timer is implemented somewhere in LiteX, so the openlane development team that integrated the LiteX VexRISC core into Caravel would need to respond to this. @Marwan Abbas?
m
@Mohamed Hosni Abdalmonem Can you please take a look at this?
y
Any updates or information on this? Thanks for any information on the same.
k
same here Given a delay of 10ms, getting 10.708ms
t
If it shows up on silicon, then it should be simulatable as well.
I expect that it has to do with the amount of overhead to call the function as a subroutine plus the overhead of how long it takes to fetch each instruction from SPI flash. Still, nearly half a millisecond of overhead is rather excessive. Possibly related: The discussion on https://github.com/efabless/caravel_mgmt_soc_litex Issue #129---"The CPU is slow"
k
Thank you for the pointers. Looking at it