Your question is pretty confusingly written, but let me try to make some sense of it.
You say you receive 8 bits of input every cycle. You want to encrypt the input using AES, which operates on 128 bits at a time. This means that you need to buffer the input somehow (a shift register might be handy here) for 128 / 8 = 16 clock cycles, until you've accumulated a full buffer to encrypt.
Conveniently, while you're accumulating the next input block, you can encrypt the previous block at the same time. If you can do one full AES round per cycle (which apparently is indeed possible, if you can afford the gates), then you should have plenty of time to finish the encryption before the next block comes in.
Presumably, you also need to buffer the output in another shift register, and shift it out 8 bits at a time, but you can also do that in parallel with the input buffering and the encryption. So, at any given moment, your circuit will be doing three things: reading in the next 128-bit block, encrypting the current block and writing out the previously encrypted block.
All that's assuming that you want to implement the raw block cipher, i.e. "ECB mode". (The "scare quotes" are there because ECB isn't really a proper mode of operation suitable for securely encrypting long messages. It's really only good as a building block for implementing other modes, but it's pretty useful for that.) Once you have an ECB implementation, you can easily use it to implement any other mode.
Note that, for efficiently implementing the "feedback" modes (i.e. CBC, CFB and/or OFB), which require you to feed the previous encrypted (possibly modified by XORing it with the plaintext) block back into the cipher to encrypt the next block, you have two choices: you can either build the circuitry to do that into your AES module, or you can leave it as the responsibility of the user of your module to do that.
The first option is technically pretty simple (you need to be able to feed the block back through the round function several times anyway) and efficient, but it does make your circuit mode-specific, and requires you to implement some way to select the mode of operation, if you want to support more than one. For most modes, you also need to handle the encryption and decryption operations differently.
The second option is even simpler (at least from your viewpoint; it might not be simpler for the user of your circuit), but having to feed the output back in through the 8-bit I/O bus could reduce encryption speed considerably (at least by a factor of 2 if the input and output timings are staggered appropriately, by a factor of 3, or more, if they're not).
You don't need to generate a new IV for every input block — indeed, that couldn't possibly work, since the IV is a full input block. Typically, the IV is supplied as the first block of each multi-block message. If you do decide to implement the feedback internally, you do generally need to treat this first block somewhat differently from the later ones. (That's not always the case, though: for example, for CBC and CFB mode decryption, the IV can be treated just like any other ciphertext block, with the user being responsible for throwing the first plaintext output block away.)
There's also a very handy variation on CBC mode encryption where the initial "IV" is simply set to all zeros, and the actual IV is obtained by encrypting the first plaintext block, which should consist of a nonce. Decryption still works exactly same as usual. You might want to support this scheme explicitly (avoiding the need to actually feed in the dummy null IV), since it's more resistant to certain attacks involving poor IV generation than standard CBC mode encryption.
In fact, there's a another, more general case where using a fixed (say, all-zeros) IV is OK: whenever each message is encrypted with a different key. For some applications, this might be a common scenario, in which case you may want to provide it as a general option for any mode.
One final feature you're typically going to need is some way to change the key. There are applications for which having a single, fixed key permanently embedded in the encryption circuit may be sufficient, and it does simplify the circuit considerably, but for most purposes you do need to support changeable keys (which implies that you need to implement key expansion).
Another simplification you may be able to make, in some applications, is that many modes of operation (such as CTR, CFB and OFB, as well as many AE modes like EAX or SIV) only use the underlying block cipher to encrypt blocks, never to decrypt them. Although you can generally reuse much of the encryption circuitry for decryption, omitting the decryption parts still makes things a lot simpler. You do, however, need the decryption circuitry if you want to implement CBC or OCB mode (or, obviously, ECB mode) decryption.
