@Rayman said:
Any chance of defining delay in terms of nanoseconds and having some equations doing the rest?
A possibility, as it should in theory be a a linear relationship between P2 clocks at a given frequency and the delay, albeit quantized. I wonder if there's a good way to compute the "half step" we sometimes need that enables/disables the sync/async input sampling. Perhaps we can just assume it to be in the middle of the two bordering P2 clock delay values even though it probably isn't.
By the way I put together a way for the driver to essentially look up the delay using a sequence of breakpoint frequencies. It's termed a timing profile. The idea is you run a delay test on some given new board and then create this timing profile accordingly where you see the optimal delay vary with frequency. In theory at some point some tool could automate this by running a test and spitting out a timing profile you could add to the code for some new HW configuration for example. There is the ability to select a timing profile when the memory is initialized IIRC.
As evanh mentioned it doesn't currently take into account temperature variation. Ideally some process would continually probe the HW and adapt the timing if things vary, but that's a bit of work and requires another COG to manage (it would need to read with adjacent timing delays and check for any corruption and rewrite timing delays dynamically), it also consumes some of the memory which is inconvenient. When it's a borderline call between two input delay values, data corruption doesn't occur immediately and can require lots of blocks transferred before it appears so this adjustment needs to be continuous to find the "best" value to use. UPDATE: transferring data at sysclk/2 instead of sysclk/1 does assist here by providing the user an option of more than one delay value that should work but at the same time can also complicate an automated dynamic algorithm looking for working delay values to configure - ie. which one of the two is best/marginal?
An easy way to "autotune" delays to fix setup/hold time problems is to do a frequency or phase sweep and record the range that shows no errors. Then pick the center value of the working range. For example, if one to three clocks delay is error free then pick 2. But this doesn't work so well if you only have two values to choose from. Then you have to add noise or jitter and test which one shows less failures statistically.
Comments
A possibility, as it should in theory be a a linear relationship between P2 clocks at a given frequency and the delay, albeit quantized. I wonder if there's a good way to compute the "half step" we sometimes need that enables/disables the sync/async input sampling. Perhaps we can just assume it to be in the middle of the two bordering P2 clock delay values even though it probably isn't.
By the way I put together a way for the driver to essentially look up the delay using a sequence of breakpoint frequencies. It's termed a timing profile. The idea is you run a delay test on some given new board and then create this timing profile accordingly where you see the optimal delay vary with frequency. In theory at some point some tool could automate this by running a test and spitting out a timing profile you could add to the code for some new HW configuration for example. There is the ability to select a timing profile when the memory is initialized IIRC.
As evanh mentioned it doesn't currently take into account temperature variation. Ideally some process would continually probe the HW and adapt the timing if things vary, but that's a bit of work and requires another COG to manage (it would need to read with adjacent timing delays and check for any corruption and rewrite timing delays dynamically), it also consumes some of the memory which is inconvenient. When it's a borderline call between two input delay values, data corruption doesn't occur immediately and can require lots of blocks transferred before it appears so this adjustment needs to be continuous to find the "best" value to use. UPDATE: transferring data at sysclk/2 instead of sysclk/1 does assist here by providing the user an option of more than one delay value that should work but at the same time can also complicate an automated dynamic algorithm looking for working delay values to configure - ie. which one of the two is best/marginal?
An easy way to "autotune" delays to fix setup/hold time problems is to do a frequency or phase sweep and record the range that shows no errors. Then pick the center value of the working range. For example, if one to three clocks delay is error free then pick 2. But this doesn't work so well if you only have two values to choose from. Then you have to add noise or jitter and test which one shows less failures statistically.