Electronic – Processor with hardware camera interface port

It's not anywhere as simple as you think.

It is likely that your "BNC" camera is a standard composite video camera.

As such, you need a fast ADC, and a bunch of logic to properly decode the video signal. You cannot in any way just wire it up to usb.

Your best bet is probably to buy an inexpensive video-capture card (google "video capture", there's lots of options). They run as low as ~$30.

If you really want to do it yourself, there are a few people who have done so out there, and posted projects online.

Here is one.

It's worth noting that if you want to do this in real-time, you will have to use a FPGA or very fast microcontroller of some sort. The above project is just a frame-grabber (i.e. it can take one frame every few seconds). Commercial products for video-USB generally use an ASIC of some sort.

(I do not know any HDL, but I hope the following will be helpful anyway.)

One can use a 32-bit wide interface and implement atomic 64-bit loads/stores. For loads one can "cheat" by reading from the invalidated cache entry (only checking the tags on the first 32-bit load), since one knows that the two 32-bit accesses will be back-to-back and within the same cache block that is known to be a hit.

For stores, since the cache block must be in modified (or exclusive if silent updates are allowed) state to accept a store, an invalidate request (really read-for-ownership) generates a data response. Since a data response is provided and the total time of the write would typically only be two processor cycles, the data response could be delayed until the store has completed.

LDSTUB (load-and-store-unsigned-byte) and SWAP could be handled somewhat similarly to a 64-bit store by delaying the load until the cache block is in exclusive/modified state; the store part of the operation is known to be immediately after the read portion and a data response is required anyway, so the data response can be delayed slightly.

An alternative implementation of LDSTUB and SWAP could treat an invalidation between the load and the store as a miss for the load, effectively reissuing the load. However, this presents a danger of livelock. While livelock issues can be managed (e.g., various back-off techniques), the earlier mentioned implementation is probably much simpler.