Judging by your other question, you're a Xilinx guy. So I highly suggest getting the data sheet for your Xilinx chip and going to the Functional Description chapter. For the Spartan 3 chip that I use, it's 42 pages of fun reading. It details exactly what components are inside an FPGA - the IOBs, CLBs, slices, LUTs, Block RAM, Multipliers, Digital Clock Manager, Clock Network, Interconnect, and some very basic configuration information. You need to understand this information if you want to know what a "compiled HDL" looks like.
Once you're familiar with your FPGA's architecture, then you can understand this process. First, your HDL design is run through the synthesis engine, which turns your HDL into basically RTL. Then the Mapper processes the results from Synthesis, "mapping" them onto the available pieces of FPGA architecture. Then the Router does Place And Route (PAR), which figures out where those pieces go and how to connect them. Finally, the results from PAR are turned into a BIT file. Typically this BIT file is then transformed in some way so that it can be loaded into a Flash chip, so that the FPGA can be programmed automatically when it powers up.
This bit file describes the entire FPGA program. For instance, the CLBs in a Spartan 3 are composed of slices, which are composed of LUTs, which are just 16-address 1-bit SRAMs. So one thing the BIT file will contain is exactly what data goes into each address of the SRAM. Another thing the BIT file contains is how each input of the LUT is wired to the connection matrix. The BIT file will also contain the initial values that go inside the block RAM. It will describe what is connected to the set and reset pins of each flip flop in each slice. It will describe how the carry chain is connected. It will describe the logic interface for each IOB (LVTTL, LVCMOS, LVDS, etc). It will describe any integrated pull-up or pull-down resistors. Basically, everything.
For Xilinx, the FPGA's memory is cleared when configuration is initiated (i.e. PROG_B is asserted). Once memory is clear, INIT_B goes high to indicate that phase is complete. The BIT file is then loaded, either through JTAG or the Flash chip interface. Once the program is loaded, the Global Set/Reset (GSR) is pulsed, resetting all flip flops to their initial state. The DONE pin then goes high, to indicate configuration is complete. Exactly one clock cycle later, the Global Three-State signal (GTS) is released, allowing outputs to be driven. Exactly one clock cycle later, the Global Write Enable (GWE) is released, allowing the flip flops to begin changing state in response to their inputs. Note that even this final configuration process can be slightly reordered depending on flags that are set in the BIT file.
EDIT:
I should also add that the reason the FPGA program is not permanent is because the logic fabric is composed of volatile memory (e.g. SRAM). So when the FPGA loses power, the program is forgotten. That's why they need e.g. Flash chips as non-volatile storage for the FPGA program, so that it can be loaded whenever the device is powered on.
Partial answer... there are quite a few I don't know, and Libero has decided to segfault when I start it tonight...
- bfm: Source file - keep under version control. Bus Functional Model script which you write in their ad-hoc language, compile into a .vec file, which is read and executed by a testbench instantiating their VHDL BFM models.
- cfg: This captures information about the settings that were specified for the system.
- cxf: SmartDesign core configuration file. This and the matching .sdb allow SmartDesign to recreate the DirectCore components via its "Generate Design" command.
- dat:
- def: Discontinued Programming file. Output file from flashpoint.
- edn: is the Output file.
- gen: Output netlist file from the generated cores
- ipd: Programming file
- loc:
- log: log file from configured generated cores
- precision.log: Precision logfile
- map: lets you know the location of the Logic inside the FPGA
- _syn.prj: Synplify log file
- pro: FlashPro settings. Generated by FlashPro.
- psp: Precision project file
- rpt: Report. Optionally generated from a menu item in Designer.
- sdb: Source file - keep under version control. Archive to permit recreation of DirectCore components.
- srr: Synplify logfile
- tcl: Used to run synthesis
- xml: XML files. Some are part of the auto-generated SmartDesign, passing info to the embedded software tools. There may be others.
Additional:
- prj: Source file - keep under version control. Project file; stores Libero settings for a project
- adb: Actel Designer database, stores the compiled design for P&R. Output
- pdb: Actel Designer physical database; essentially the finished bitfile
readable by FlashPro
- vec: Compiled from .bfm
- pdc: Source file - keep under version control. Constraints such as pinout, I/O standards.
- sdc: Constraints generated by the tools (e.g. Synplicity). If I modify this I treat it as as source file.
The ones I have listed as Source Files are the ones I keep under version control. I tend to keep all my actual sources OUTSIDE the Libero project structure and "link" them into Libero to minimize interactions between Libero and versioning.
Best Answer
Only if your compilation creates intermediate files to avoid recompiling unchanged files.
In an FPGA compile, unless you are using incremental compilation (which is a complex endeavour), then it will have to resynthesise everything all the time.
Remember that an FPGA design is not software. You are describing a physical circuit. Any changes to any part of that circuit can have knock-on effects on other parts of the circuit, due to the way the synthesis tools optimise. Furthermore the tools do not and in most cases cannot "compile" each file in isolation, because the files are typically descriptions of small parts of the overall circuit.
When the design is fit into the FPGA, unless you lock down certain parts of it (post-fit netlists and incremental compilation), the fitter will start from scratch each time to try and find the most optimal way of fitting the design. Usually the compile time is heavily impacted by timing constraints as the fitter tries to minimise routing delays to meet your required clock frequencies.