TL;DR: ASIC input/output is the bold text below.
No, the ASIC does not assemble a block.
The block is assembled by a mining pool server. If you are solo mining you could let bitcoind assemble the block but you'd still need mining pool or proxy software in between to make a modern ASIC machine (stratum only) and bitcoind (getblocktemplate only) communicate.
Modern ASIC miners have a small computer built-in, acting as a controller. Some use a beaglebone. This is a low-performance computer which handles the stratum protocol, generating work, pushing work to the ASIC chips in the machine, and receiving results from them. The ASIC chips only handle the part of the number crunching that must be repeated many billions of times.
When the miner receives data over the stratum protocol it is allowed to change the nonce, the timestamp and part of the coinbase (often called the extra nonce). An ASIC chip goes through all possible nonce values pretty quickly, so the controller needs to be able to make more work using the extra nonce.
When the controller changes the extra nonce it needs to generate a new hash for the coinbase transaction (which has now been modified) and use this hash together with a merkle branch received from the pool server to generate a new merkle root. This merkle root goes in the block header.
After a merkle root is generated the controller can now calculate the midstate. The bitcoin block header is 80 bytes. SHA-256 hashing is done in chunks of 64 bytes. Since the interesting parts which we are going to change are not in the first chunk the controller will hash the first chunk once and then the ASIC chip will do the rest billions of times while changing the nonce in the second chunk each time. The midstate is the state of the SHA-256 hashing engine after the first chunk has been processed.
So the input for the ASIC chip is the midstate (32 bytes) and the 16 bytes of the second chunk (last 16 bytes of our bitcoin block header). The outputs are nonces (4 bytes) that resulted in hashes below the target. These nonces are retrieved by the controller and passed on to the pool server.
So what are those 16 bytes of data the ASIC chip needs in addition to the midstate? These 16 last bytes of the bitcoin block header are the 4 last bytes of the merkle root, 4 bytes of timestamp, 4 bytes of "bits" indicating current bitcoin target/difficulty, and 4 bytes of nonce.
In reality the ASIC doesn't need to receive a 4 byte nonce from the controller. It is going to try different nonce values on its own. So we are left with this:
The inputs to the ASIC chips are a 32 byte midstate, the last 4 bytes of the merkle root, a 4 byte timestamp, and 4 byte "bits" (target/difficulty).
If I managed to explain the above properly then you should now see why the ASIC chip is focused on this specific part of the work. For each time the work up to completing the midstate is done, the work after that point is repeated billions of times.
You can also see that generating a new midstate (which also entails generating a new merkle root) is a lot more work than just incrementing the timestamp. So once you have enough midstates to keep the ASIC chips happy for one second, you can reuse the same midstates over and over every second just by incrementing the timestamp. If the controller is slow enough and the ASICs fast enough then this "time rolling" may be necessary for the machine to work.
The slowness of the controller can also mean that the ASIC machine has a minimum difficulty it can operate on. Otherwise it will get more results (nonces) than it can handle. But the same thing goes for the mining pool server which would also not want to be spammed to death.
For maximum efficiency the ASIC is designed to only handle a limited area where expensive specialization really pays off, while the rest is handled by a tiny computer that is very cheap and very energy efficient.
Note: there are of course some differences between manufacturers. For instance some ASIC chips do not scan the entire nonce range. But the above should be the gist of it.
