leeloothedolphin said:
and asynchronous CPU.. well it's not up to me... that is dictated by others...
You should not have problems with asynchronous SRAMs. As they are passive devices, you can totally control them with synchronous design. If they're still using core memory, same thing - except you'll need to deal with the peculiarities of reading/writing them.
Do your CPU designs use any kind of clocking?
If they do, there actually is a high degree of synchronous design. They probably don't use edge-triggered FF's, but that doesn't mean the designs are asynchronous. Only the components are asynchronous.
The FPGAs I work with have FFs with both asynchronous sets and resets, in addition to the edge-sensitive clock signal. So if your design is full of RS FFs, you can ignore the clock input. You will probably need to "create" (actually allocate) FFs with a "primitive component", rather than with behavioral HDL code.
If you are using an old-school multiple clock design, you can generate them with synchronous design from a single clock source. If two clocks can change at roughly the same time, you will need to be careful at clock boundaries. Because you don't have total control of the geometry, differing routing delays can cause unpredictable overlap (or nonoverlap).
If you decide to redesign with edge-triggered design, you can build a CPU that uses only a single clock. There is an internal clock network that is optimized to minimize skew - all edge-triggered FFs change at roughly the same time. The compactness of the FPGA allows this. With logic spread out over several chips, it is much harder to build a reliable system that uses a single clock that drives edge-triggered FFs.