What is the motivation in using hardware description languages (HDL) such as Verilog and VHDL over programming languages like C or some Assembly?
C and assembly are good languages for telling a CPU what to do. They describe actions to be done sequentially by a single state machine.
HDLs are good languages for describing or defining an arbitrary collection of digital circuits. They can express operations done in parallel in ways that programming languages can't. They can also describe timing limitations for the interfaces between blocks in ways that programming languages can't.
I was surprised to see discussions expressing doubts whether to write firmware in C or Assembly (how is Assembly appropriate if you don't necessarily have a CPU?)
In that question, what's asked is, "If you are writing code for a microcontroller is there a real difference if you write in assembly or C or some other high level language?".
Since he's specifically asking about systems with a microcontroller (a CPU with peripherals), C or assembly are both reasonable choices for firwmare development, and HDL's are not.
A firmware really can be written either in HDL or in a software programming language, or it's just another way to perform the same mission?
It depends what kind of hardware you have. If you have a CPU, use a programming language. If you have an FPGA or you're designing an ASIC, use an HDL. If you are designing a very large amount of digital logic, you can look to one of the in-between languages like SystemVerilog.
I've read that the firmware mostly burned on ROM or flash. How it is represented in there? In bits, like software? If so, what's the profound difference? Is it the availability of adapted circuits in the case of firmware?
I think you are getting hung up on the term "firmware". This word originally meant code to be run on an embedded system, that wasn't accessible for the end user to change. If you sold somebody a PC, there's a very high chance that the user would change what software is run on it. If you sold them an oscilloscope, you wouldn't want them to change the code that's run on the internal microprocessor, so you called it firmware.
FPGA users appropriated the word "firmware" for the output of their designs, because it is more changeable than hardware (stuff that's soldered together). But really the "firmware" that configures an FPGA is different from the "firmware" that runs on a uC. uC firmware directs the uC through a series of states to perform it's function. FPGA firmware defines a set of interconnections between logic elements, and values to be stored in look-up tables.
In either case, the firmware is typically stored as bits on an eeprom (or on disk on a host machine that will donwload it whenever the embedded system is re-started). But that doesn't make them similar to each other.
Best Answer
With HDL languages, you have to understand you are describing hardware, not software. I think this is fundamental to "getting the hang of it". The order of the code in your module doesn't matter, it all happens at once.
It's not so bad once you get going - after you have designed a few simple modules (e.g. counter, adder, mux, etc) your mind should adapt naturally to the process.
The best book I have read to get going with HDL is Pong Chu's "FPGA protoyping by Verilog examples" (I use Verilog, but there is also a VHDL version of this book) It mostly focuses on the synthesisable stuff, which is what you want to know for FPGAs, aside from e.g. testbench code which has a chapter devoted to it also. (I'm assuming that you are interested in using HDL for FPGAs/CPLDs)
Aside from that, a couple of good 'net resources I have bookmarked over time are:
FPGA4Fun.com
Edaboard PLD forum
ASIC World
With the above links (particularly the first) and the book, you should be "up to speed" in a short time.