Ah, ok. Thanks for the info. I'll abandon that challenge for the time being then. I think I will still try to get the Verilog working so I can run it at weekends

Are you trying to learn VHDL knowing Verilog or from scratch?
VHDL from scratch. I write embedded software (ASM, C, C++) for a living, so the language syntax is easy enough. The bit I'm struggling with at the moment is exactly what makomk has said - tailoring the HDL to the FPGA. I still think in terms of high level code that has the correct behaviour in the simulator, not how best to utilise the available slices, flip flops, block rams etc. With any luck this will come with time. It seems that getting the VHDL working would be an interesting challenge when I start understanding things.
The issue is not the "syntax" but rather the complete change in the mindset of hardware programming.
If you approach hardware programming the same way you approach C programming, then it will be a fail and you will spend you life in a mental hospital wondering WHY it did not work.
Certainly when you code something like
noverheat <= NOT overheat;
reset <= reset_count(reset_count'high);
fpga_0_LEDs_8Bit_GPIO_IO_pin(0) <=NOT overheat;
From a C perspective you would say WTF it should be:
fpga_0_LEDs_8Bit_GPIO_IO_pin(0) <=noverheat ;
So that I can save logic.......
But then you discover that in VHDL in this situation:
1. you CANNOT guarantee WHICH order the statements are executed in ,even they are in top down format......
2.That
fpga_0_LEDs_8Bit_GPIO_IO_pin(0) <=NOT overheat;
may actually get executed before or at the same time as:
noverheat <= NOT overheat;
it all depends on the FPGA chip being used and the compiler options, so if you have flaky code that just about functions on one chip, changing the chip can make it non functional even when it simulates correctly.
Then you have the completely GASH Xilinx tools, written in all their memory leaking java glory........