Hardware and software are different

This should be obvious, but some people forget (or feign to forget, sometimes to justify dubious choices) that hardware and software are different, and have vastly different outputs: hardware produces chips, software produces instructions for chips. In some cases, comparing one with the other is about as meaningful as comparing the manufacturer of a car to its driver. When writing software, you typically write (still) mostly sequential code in a high-level language (Java, Objective C, C#, Python, etc.) and compile it to a sequence of instructions (native assembly or intermediate representation). You execute this and run tests, and if something is wrong, change the source code and repeat. End of story.

When designing hardware, you write code (either RTL with Verilog or VHDL, or at a higher-level with domain-specific languages like Cx), and you simulate it. If something is wrong, change the source code and repeat. Then you synthesize your code to gates, or registers+LUTs (Look Up Tables), and hope that they behave like your code. Compare that with software, in which you directly test the end result (the sequence of instructions), so you quickly know if there is a problem with (by decreasing order of likelihood) your code, the libraries you use, the compiler, the OS, or the processor. By contrast, to test the result of synthesis, you can run a post-synthesis simulation, but this is computationally expensive because gates/LUTs are very low-level; or you rely on equivalence checking tools to make sure synthesis did its job; or do nothing at this point (see below).

And this is only the first half of the story! After synthesis you need to place and route (P&R) the gates/LUTs on the chip, and often iterate back and forth between synthesis and P&R until your design meets constraints of speed, power consumption, etc. At each step you may need to go back to the source to change something if your design is too slow, or too big, or consumes too much, etc. If the target is an FPGA, you use another tool to transform the result of P&R to a bitstream that you upload on the FPGA. At this point you can finally run tests 'at speed' to verify that the hardware behaves correctly (either manually, or automatically, for instance with Adacsys' AVAtest tool). If you are making an ASIC, you can also run your tests on the integrated circuit that you've created, though generally verification engineers try to simulate as much as possible before asking for the fabrication of a prototype (especially given the huge, fast-rising costs of technology nodes at 28nm, 20nm, and below!).