2. cgminer does not cycle nonce from 0 to 4.29G. It just sends a lot of block header data to ASIC chips. ASIC chips or hardware do cycle nonces by digital chips and frequency pulse to check and find qualified nonces. ASIC hardware do filter out qualified nonces. So, ASIC hash header data super fast.
Does that mean that cgminer has no control at all about the current nonce which should be tested? As cgminer sends a block header to the ASIC miner, the ASIC hardware would need to know how such a block header is constructed and to derive the part where the nonce is located, wouldn't it? Otherwise the ASIC miner would only see a very long string (blockheader) without knowing which bits to change for trying for a valid hashes.
You don't really want cgminer, which runs on a relatively slow CPU to have to increment the nonce and communicate it to ASIC. That's happening much too fast. Chips like the Bitmain BM1387 or the BM1397 (like in your Compac F) have a set of address pins. If I understand this right, the address pins are used when you have several chips in a chain they can each be set to work on a different nonce range, so as not to overlap.
cgminer doesn't exactly send a block header to the mining chip. It's like a partially computed hash of the block called a midstate. Kano has a description of this here;
https://kano.is/BMMMP63278.pdf. All of the bytes are sent in fixed positions to the mining chip, so it knows what goes where. Things start to get pretty crazy (to me) when cgminer sends multiple midstates to the ASIC, which is called ASICboost.