This is much worse in ASIC, where there's no standardized SRAM interface and you have built-in self-test wires coming in that uglify each non-standard interface tremendously.
HDLs have their share of warts - pragmas in comments, vital information in non-portable synthesis scripts, etc.; well, C has its own pragmas and vital info in linker scripts and stuff as well... Verilog is in some ways much prettier because for instance it compiles down to itself - the output of synthesis tools, a netlist, is Verilog source. In C the closest approximation is int main[] = {non-portable hexadecimal representation of machine instructions}.
I'm curious about the ASIC comment. Surely no one is "synthesizing" SRAM in ASIC by describing its behavior with an HDL, right? You just decide at design time to use an SRAM array of whatever size, then (for simulation) just stub it out with an appropriate HDL model that gets replaced during synthesis. The "SRAM" abstraction in that model is provided by the semiconductor fab, no?
At least, that's how I've always assumed things work.
It works as you describe, pretty much, the gnarly bit being that there's no standard interface for an SRAM (that is, SRAM is not in the standard library, unlike say simple gates.) One reason is the many different ways to implement BIST and connect the BIST signals from all memories in the chip into a coherent whole.
Here's an article (not written by me, just found by using google) that has an example how the VHDL/Verilog compiler infers to use a dual-ported SRAM from code that describes the behavior, including the bugs you'll encounter.
Verilog is in some ways much prettier because for instance it compiles down to itself - the output of synthesis tools, a netlist, is Verilog source.
This is a terribly lame analogy. You could have the C compiler output C that exactly resembles what the actual CPU instructions do. And even write an assembler for that if you wanted.
I think it would be absolutely awesome if the assembly output from my C compiler were syntactically-valid and semantically-equivalent C. Among other things, it would enable me to compile it (with a C compiler rather than an assembler) to run on a different CPU architecture. And then I'd just need a disassembler to generate it in the first place.
Unfortunately this isn't possible because you can do a lot of things in assembly that you can't do in C. RET, say.
HDLs have their share of warts - pragmas in comments, vital information in non-portable synthesis scripts, etc.; well, C has its own pragmas and vital info in linker scripts and stuff as well... Verilog is in some ways much prettier because for instance it compiles down to itself - the output of synthesis tools, a netlist, is Verilog source. In C the closest approximation is int main[] = {non-portable hexadecimal representation of machine instructions}.