When generic CODE_ROM_SIZE > 8192, XST synthesizes the XCODE ROM with too many BRAM blocks.
For example, with CODE_ROM_SIZE=8193 the XCODE uses 4 2KB BRAM blocks; yet, with 8193<=CODE_ROM_SIZE=12288, the XCODE uses 8 BRAM blocks.
This happens in two versions of ISE (9 and 14) and targetting two different generations of Spartan (3 and 6).
There must be something in the code that upsets the XST synthesis tool but not Quartus'.
Since I haven't tried the project on Xilinx hardware, I don't know if the XCODE is properly initialized despite its wrong size, or if there are other synthesis problems not apparent in the reports.
Typo fix: in the example above, XST infers 4 BRAM blocks when CODE_ROM_SIZE=8192, not 8193.
Looks like I have screwed the example while typing in the bug description above; looks like you can't use 'less-than' signs in a bug description text...
Anyway, this is what happens for different XCODE sizes:
CODE_ROM_SIZE = 8192 : 4 BRAM blocks CODE_ROM_SIZE = 8193 : 8 BRAM blocks CODE_ROM_SIZE = 12288 : 8 BRAM blocks
The Dhrystone demo works in Avnet's S3A eval board, yet the number of BRAMs is still wrong: 10 when it should have been 8.
So far, no clue about the extra BRAMs but at least I know there is no big trouble with XST and the core works on Xilinx hardware with no changes.