VME64xCore_Top.vhd
------------------

In the comments, it would be useful to explain a bit about the context
this core expects in the PCB, e.g. what chips are used in the SVEC
board (which is the reference platform for this core). This would help
people understand e.g. how open collector outputs are dealt with, or
what the VME_LWORD_n_o and VME_ADDR_o outputs are for.

VME_AS_n_i and VME_DS_n_i are passed to two different synchronizer
blocks in parallel. The actual implementation of this will depend on
how clever the synthesis tool is. If it is not clever, it will not
notice it can tap the three-FF synchronizer to get the double-FF
output, and we will have two parallel synchronizers: not good,
especially considering that one of them will not use the I/O FFs. If
these double-clocked signals are really needed, the triple-clocking
block could deliver an extra ouput port for them. 

There are a number of outputs which are supposed to go to the outside
world (VME_DTACK_n_o, WE_o, VME_DATA_DIR_o...) and which are not using
I/O FFs because they are the result of some combinational logic. This
will result in tricky timing issues, and need complex constraints to
P&R to guarantee consistent results. I would strongly advise to make
sure all these signals are outputs of I/O FFs, with any necessary
logic placed *before* these FFs. In general, all inputs to the core
should be sampled before using them, and all outputs should be the
result of clocking in I/O FFs.

VME_IRQ_Controller.vhd
----------------------

Text diagram in the initial comments not clear regarding state
IACKOUT2.

Line 69: "To avoid the time constraint" -> "To respect the timing
constraint"

Signal naming is not consistent. If the "s_" prefix is used, it should
be used for all internal signals.

Instantiation of many FlipFlopD components: a single clocked process
would be more compact and easier to understand.

Line 247: why should the interrupt controller not be allowed to go to
the IRQ state when VME_IACKIN_n_i='0'? That line could be at '0'
because of some other interrupt from another module in the
crate. Because the INT_Req input (shouldn't this be called INT_Req_i?)
is supposed to be a pulse, this can lead to interrupt requests being
lost.




TODO:
- Check iack_in -> iack_out part.
- Make sure no interrupts can be missed.
- Check licensing in sources.
- Check sampling of DS0 and DS1.
- Check the reset signals.
- See if the main state machine can be stuck somewhere.
