Deos AMP Estimate

An estimate/strategy to get Deos AMP to a sellable state.

AMP requires an AMP aware BSP. BSP development is not included in any of the following.

If we assume caches, busses and memory controllers are independent, then the kernel code is already done. It does require a BSP, but that is not much more difficult than a normal BSP.

Verification strategy: This is largely analytically performed (i.e., ensuring data areas are separate). Suggest running kernel test simultaneously on the cores for informal verification.

Estimate: 1week to run tests.

Memory controllers not independent

Our supposition is that if the memory controllers are not independent, then AMP is likely not usable unless one of the apps doesn't use a lot of memory bandwidth and/or the apps are not "hard real time", i.e., they are "soft real time".

Busses not independent

If busses not independent, then we need to bound the cross core interference, probably by bus trashing. In this case we'd provide guidance, and perhaps a sample trasher application.

Estimate: 2 weeks for paper and review, another 2 weeks to put together a sample test.

1 month total.

Caches not independent

If caches are not independent, then we inter-core need cache partitioning. Code is done, we need requirements and tests, and an application verification strategy.

Requirements. Kernel and hyperstart image verification rules would both be needed. Probably month of work for kernel requirements and tests, a week or two for establishing the hyperstart image verification rules and procedures.

Application verification is probably to do a test that writes a bunch of memory and verify that the cache lines associated with the other processor are not perturbed. This would be automatable perhaps in software, but likely would require an emulator script.

We could also use an indirect method based on timing. Have one core establish an environment, then time the duration to read the cached lines. The other core would attempt to perturb the cache. The test would be indicative of success, the fidelity might even be acceptable.

Run We could push this off on the user.