jbush001 / NyuziProcessor

GPGPU microprocessor architecture
Apache License 2.0
2k stars 351 forks source link

Coprocessor memory interface #63

Open jbush001 opened 7 years ago

jbush001 commented 7 years ago

Currently, the only way to access external coprocessors is to use the I/O bus. Writes to addresses at high physical memory addresses, instead of going through the normal cache hierarchy, are redirected to the I/O bus. While this is useful for relatively low-speed peripherals, it has performance limitations when used with coprocessors such as texture fetch units:

The proposal is to create a new bus for use in high-speed peripherals. This would not replace the low speed bus, but would address different use cases and constraints.

Design here: https://gist.github.com/jbush001/09f51178a366c0f6b8f07363c30f414f

jbush001 commented 6 years ago

Prototype implementation here: https://gist.github.com/jbush001/636812836911d5c7873893a1d0ae517e

jbush001 commented 6 years ago

A few alternatives (which are not mutually exclusive):

jbush001 commented 6 years ago

On SRAM: this solution would look similar to the proposal in implementation, and could be implemented using the proposal. However, the proposal is more general. On instruction: one big issue is that an access control model would need to be defined. The instruction could be made supervisor-only, but that might incur an unreasonable performance penalty for some configurations. The advantage of memory mapping is that the existing MMU access control model can be reused.