As a bare minimum, you would require data, address, a ReadNotWrite signal and a chip select. If you want to make it synchronous, you would provide a clock. If you want the FPGA to control how long the access takes, you would also have the FPGA generate an acknowledge signal.
In general, the processor bus to an FPGA only needs to set control registers and read status registers, and perhaps load and read internal memories to the FPGA. More often than not, this is done at fairly low speeds with simple single burst transactions. Thus there is rarely a need for anything complex here. Hence the desire for a low speed, low pin count interface. The most complex processor interface I've had to use in 22 years of telecom chip designing was a PCI interface, and quite frankly, that was overkill.
If you have more complex needs, then by all means use a more complex bus. But treating the FPGA as an SDRAM may not just mean using the more complex bus. If you use the SDRAM interface of the processor, it might also insist on accessing the FPGA as an SDRAM protocol-wise as well, which means burst control, bank and row precharging, bank selection, auto or manual refresh, etc. None of these have any meaning to the FPGA, but will require complexity and needless overhead.
Figure out your bandwidth needs for the processor bus, and any functionality you will require from the bus. If you are just accessing control and status registers, or low bandwidth data storage memories, then do the simplest thing you can.
I'd worry more about needing extra pins for features that get thrown at you later, than using them for a processor bus.
But that's just my opinion. And I simply can't think of a reason offhand why you would use an SDRAM interface for an FPGA, unless the FPGA was being used as a slave SDRAM controller or something. Perhaps others have some ideas.
r.b.
r.b.