SPI and I2C aren't really the same at all, except at a trivial level in that they're both serial and use a separate clock to transfer one bit per clock (and that's not even truly the case with SPI, which can be wider than 1 bit: 2, 4 and 8-bit wide versions are available.)
Beyond this, how are I2C and SPI different? As a protocol, I2C requires more processing and state-machine control to deal with receiving bits and determining packet state than SPI, which in contrast is a much more rudimentary serial-in serial-out protocol, with transfers framed by chip select.
On the other hand, SPI supports a wider variety of modes: data width, speed, clocking polarity/phase, single/double data rate, compared to I2C which only supports different speeds. Finally, SPI is much faster than I2C: the very fastest SPI clock rate is well north of 100 MHz, while the fastest I2C variant is 3MHz.
If your goal is to design a dual-mode controller in VHDL, it will be much easier to create separate I2C and SPI controllers and share the pins using a mode select. Further, a SPI implementation will likely need high-priority system I/O (like FIFO and DMA) to deal with its increased throughput.
I've seen systems that share physical SPI and I2C signals (for example, sharing an I2C EEPROM with a SPI DAC or ADC.) This is possible since chip select negated will make SPI ignore I2C, and it's also possible to carefully code SPI so that it never emits a START or STOP condition (that is, never change SDA state while SCL is high) so I2C endpoints will also ignore SPI. But the endpoints themselves will be working in one mode or another, not dynamically switching between I2C or SPI.