Yesterday I started designing a Digital Signal Processor with megabytes of DRAM. Provided this is intended for use in USB peripherals... How'd it communicate with your "host" computer?
I'd include a config table mapping up to 16 endpoints to the DSP's arrays (I guess then our DSP should support 32 arrays). Upon receiving a valid IN packet from its USB transceiver it'd stream data from the corresponding array in DATA packets with error detection codes, awaiting acknowledgements.
1/3?
Upon receiving an OUT packet our Digital Signal Processor would stream the body of valid DATA packets into one of its arrays.
In either case I'd trigger an interrupt on our to-be-designed processor letting it clear or update the next packet.
Interface 0 would hold data to be sent in reply to SETUP packets. GET/SET_DESCRIPTOR SETUP packets specifies 4bytes addressing the metadata covering type (1 nybble used), index, & (for strings) 2byte locale.
2/3?
Other SETUP packets specifies 2bit type, 2bit recipient, 1byte request code, & 1byte index for 20bits total. Though it appears that a bit of that request-code byte should stolen to indicate read/write, in exchange these values can be 2bytes each. This includes an address value used to determine whether we should pay attention to a USB packet.
Meanwhile the string pointers may need to be nudged to fit in this address-space, so I'd reserve a page where we can store per-locale offsets.
3/3.5!
The 20bit addressing for SETUP fields & 16bit addressing for locale-offsets would fit comfortably within spare regions of the 28bit-addressed descriptors.
Yes 1/4GiB is a lot of memory to dedicate to storing USB metadata, but... If I'm saying I need a lot of RAM anyways, it can simpler to use some more RAM than to embed fancier logic.
Its worth mentioning that the dereference would incur some overhead.
4/4 Fin for today! Tomorrow: FFT!
