Q&A between DaveM and Rob ========================= 1) How much of your backend VHDL is reusable? My expectation is that the back end/vme code is virtually a 100% re useable as is. Also it will be easy to add in the trigger block to the BE code. 2) How does the front FPGA to backend FPGA serial protocol work? There is basically a fast 80 MByte/s uni directional channel data channel and a 40 mbit/s serial bidirectional channel for control setup and monitoring. These are independant. Essentially the fast uni directional data channel consists of a 4 bit DDR data port running a 80 MHz and 2 bidirectional serial side channels for flow control runing at 40 MHz. It should be possible to emulate the cms protocol on the side channels to make the back end merge your data and pass it to the vme. I'll put some more together on this in another e-mail... 3) How much of the VME VHDL is reusable? (We are assuming almost 100% ; but need a VME interrupter on day one) I believe I will be able to get them to add a VME interupter but this will need some diplomacy first - CMS will likely need this eventually anyway just not on day 1. 4) How does the interface between the VME FPGA and the backend FPGA work? This is a part we have just changed - it is a subtle change from our point of view and is esentailly moving blocks from the BE to the VME. We no longer have a memory mapped bus between BE & VME, there are now two channels;- a bidirectional serial channel for set up, control/monitoring and a uni directional 'SLINK' channel for fast data transfer to VME. The serial channel is nominally a 40 mbit synchronous link but could be made faster if required. In the VME FPGA there is a serial engine which is memory mapped and drives the link. It has input and output DPMs and some control registers. Essentially you put the serial command into the output DPM, set the outgoing data length in a register and the return length of any data to be shifted back and then trigger it. The serial command is shifted out and any data read back is put in the input DPM. The backend includes a 'router' which forwards on commands destined for the FE FPGAs which you achieve by preceding your FE command with a routing command. This means you can effectively have almost any command structure you like in your FE FPGA design within the limts of the Serial Engine DPM size. The be/vme slink path has a similar engine in the vme fpga with DPM buffers only for receiving the data from the slink. Flow control is achieved by asserting the slink wait when the input buffers are full and allowing software to DMA the data then release the wait line which moves another batch from the QDR. It should now be easier to add interupting to this scheme as it only has to come from the slink engine.