Add configurable system bus access delay

[timsifive]

Add configurable SBA read/write delays with --dm-sba-write-busy and --dm-sba-read-busy. They default to no delay.

This lets me test OpenOCD behavior when this happens.

[aswaterman]

I'm not wild about making this feature a part of mainline Spike, as it invites other timing-related features. Can you live with maintaining it on a branch that you use on occasion when changes are made to the relevant parts of OpenOCD?

[timsifive]

I guess I could do this on a branch, but it would be a branch we use for continuously regression testing OpenOCD. Relying on people to run some extra tests when they think they may have broken something is drastically less effective than simply getting as much coverage as is possible.

Presumably there is some way to use github actions to automate merging master into a test branch, but it sounds like a bunch of hassle to set up.

[aswaterman]

any thoughts @jerryz123 @scottj97?

[jerryz123]

Would it be reasonable to hard-code a fixed SBA delay? Does changing the delay values around substantially improve coverage of your tests?

[timsifive]

For test coverage hard coding the value is fine. But that does reduce performance if people are debugging with gdb and using system bus access for memory access. (By default system bus access is not used by gdb, but if you're using some different debugger then it's the only option that allows reading memory while the target is running.)

[aswaterman]

I don’t think perf of debugging a Spike target with SBA is a first-order constraint. I like Jerry’s idea if the coverage is good enough.

[timsifive]

OK. I'll remove the CLI options and hard-code the delay.

[timsifive]

I've hardcoded a reasonable delay for testing.

[aswaterman]

@jerryz123 OK with you, too?