Is a hash function used to expand the key after ECC shared secret is complete? I have designed an ECC engine in silicon that handles any curve in the form of $$y^2 = [ax^3 + bx^2 +cx + d] \mod(P)$$

The shared secret is then passed to symmetric encryption engine, which happens to be Simon.  The system is asynchronous and simulates great, but there's an occasion situation where I can have a key underflow.  

As an example, the shared secret is 160-bits, but my Simon 128/256 has a 256-bit key.  

If the solution to the curve is longer than what I need, I can just truncate the value to fit into my symmetric key requirement; however, in the case that it's shorter, it doesn't make sense to have all of those bits be zero.  

This hardware doesn't check for a sane user, so if you want to tell it to do a 4-bit ECC, it'll do that.  For this reason (and because I'm doing the hardware), it seems like there'd be a hash that is used for the shared secret so it is expanded into the key bit width.

Is there a NIST standard or a paper that specifically describes how this situation should be handled?
First of all, you would probably want to put the shared secret into a KDF even if you have enough bits to use it in a symmetric encryption algorithm. Check these two related posts: Key Derivation Function (KDF): Can a key derived from KDF be considered as a secure key? and How to derive a symmetric key from ECDH shared secret?


  So, the question: Is there a NIST standard or a paper that
  specifically describes how this situation should be handled?


For a standard way to handle this situation you can check the IEEE Std 1363-2000 document, particularly section 9.2.2 which show the steps of key agreement operation. The algorithm given in that document uses the shared secret as an input to a KDF function which generates the agreed key (could be the symmetric encryption key in your case).