I want to know how this one cycle single carry the instruction bits.
The wording of this question is a little hard to understand. Do you mean to ask "how does the CPU receive instructions (1001) with a single clock line"?
It doesn't. A clock signal always look like (4 cycles):
+--+ +--+ +--+ +--+
| | | | | | | |
+ +--+ +--+ +--+ +--+
It's a metronome. It doesn't carry any information other than timing. It keeps all parts of the CPU working at the same speed. There are lots of connections carrying signals inside a CPU. Signals take time to change (0 -> 1 or 1 -> 0). Some change faster, some slower. Changes take place between rising edges (or falling edges depending on circuit design). The CPU will do the "next step" of the computation at every rising edge (or falling). Eg, fetch, decode, execute, could take 3 cycles. Because the rising (or falling) edges are when signals should have stabilized.
The CPU fetches instructions through other lines, like buses. Typically, the address of the next instruction is placed on the address bus, the instruction is then placed on the data bus, the CPU reads it from the data bus, decodes, executes it. The clock line is for transmitting timing information only, not "data" information.
The 2nd diagram you drew is what 1001 would look like if you were to transmit it serially, but that's a different topic.
The origin of the word firmware is a mid-point between hardware and software -
software embedded on hardware. It refers to software that it is stored in non-volatile memory (such as ROM, EEPROM or Flash memory) on a hardware device, and is used by the device itself.
It's becoming more common in some types of hardware for its "firmware" to be stored in driver software and loaded onto the device when it's booted/initialised, instead of leaving it permanently on the device. It's not a big deal nowadays, for example, to store a few hundred KB of firmware code in a software driver loaded onto the host OS, and to send that down to the device as it's initialised by the driver.
This is still commonly referred to as "firmware" even though it is not resident on the hardware (if you detach the hardware and put it in another system, it won't retain that version of "firmware").
Microcode is a subset of this. Microcode is not a generic term for all firmware that is loaded onto a device at boot. Instead, it's specific to CPUs, where the microcode forms the translation layer between higher level standard CPU instructions and the lower-level operations specific to that CPU. It may be loaded onto the CPU at boot, by the BIOS, and replaced later in the boot stage by the OS as well.
An update to microcode can allow a CPU's low-level behaviour to be modified to work around certain yet to be discovered bugs, without needing to replace the CPU hardware. Microcode usually contains the most efficient mapping from higher to lower level instructions as possible for the best speed and energy efficiency, so sometimes when a change to microcode is necessary to fix some bug, it can result in reduced performance.
Note that unlike Spectre, Meltdown (the vulnerability affecting only Intel chips) cannot be fixed with microcode updates alone and requires changes to core OS functionality, which may reduce performance even further.
To answer some of your specific questions since your edit:
Yes, microcode is basically firmware that runs on the processor. The special term "microcode" specifically refers to the firmware on a processor that contains the blueprint for translating from standard machine language to low level processor instructions. So it is a more specific term than firmware.
Note that as I discuss above it isn't stored on the CPU while it's off but loaded onto it each time you boot.
I don't think you're wrong. Firmware doesn't have to be written in a certain machine language and its execution doesn't have to be triggered in a certain way. At a certain low level all machine code is "data" that is "read" by a processor and interpreted in a certain way.
The term "microcode" is typically only used for main CPUs and not graphics cards or other hardware, even though those other devices may have code loaded onto them in the same way.
Best Answer
The BIOS can issue a microcode update during boot. So can the operating system. Frequently these updates are required, especially with later Intel CPUs.
Modern Intel and CPUs have a mechanism called "Model Specific Registers", and special CPU instructions to read (RDMSR) and write to them (WRMSR). While these registers affect CPU settings, writing to a specific one with the address of the new microcode tells the CPU to read a region of memory and apply over the existing microcode.
There is always a microcode. The mechanism above updates the microcode. Intel/AMD don't really publish specifics on how it works, they only provide an update mechanism. Obviously somehow it is copying a ROM microcode to some sort of CPU internal memory. But there is some microcode there when the CPU starts. Some recent Intel and possibly AMD CPUs won't work reliably after boot without a microcode update done by the BIOS but evidently they will function well enough to perform an initial microcode update.
The initial microcode setup is done internally by the CPU and no instructions are executed to achieve that. It's setup before the first CPU instruction is executed.
To update the BIOS the appropriate RDMSR and WRMSR instructions must be executed.
Reference: "This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) will be generated." If it's not executed in real mode it must be done in ring 0 or kernel mode. You can update the microcode anytime.