Q&A on TTCci - From: Tony Rohlev > Hi Tony, > > I am reading your: > http://cmsdoc.cern.ch/cms/TRIDAS/ttc/modules/pdf/TTCci_notes.pdf > and have a few questions. > > - Can you add some explanations on 4.iii (command prescaling) ? > is it another way to make a repetitive command ? Sorry my description wasn't so good. What the prescaling does is send out ONE of every N requests on the B-Channel. 'N' is the value of the pre-scaler and it is set by the user for every channel. For example if N = 2 on Channel 8, N = 1 on Channel 2, and N = 2^16-1 on Channel 15, then every OTHER request is acknowledged and sent out on Channel 8, every request is acknowledged on Channel 2, and one out of every 65535 requests is acknowledged on Channel 15. The counters can be reset at any time by the user through VME - which is not very deterministic time wise. The number of requests can also be read out (and reset) by the user. All of these counters are 16-bit so at 65535 they turn over. > I think it's implicit but I want to confirm that when the TTCci receives > one B-Go input, then only one FIFO is enabled. So from one B-Go input > I can generate at most 2 different commands (with a double transmission cycle) Close. Each B-Go has a dedicated "FIFO" (it's not really a FIFO it's a dual port RAM). Each B-Go can only access its FIFO. But there are 3, not 2, types of transmission: 1) Single transmission: One B-Go, one command transmission. 2) Double transmission: One B-Go, two command transmissions (as you mentioned). 3) Block transmission: One B-Go, many command transmissions (up to 1024). > what is the max delay programmable for the inhibit signals? The inhibit counters are 12-bit. So 2^12-1 (4095) cycles or approximately 102 micro seconds maximum delay. Minimum delay will be more tricky. I think I had it down to two cycles in the state machine. > The pdf note states: > "The inhibit signal for each channel has two parts: > (1) a programmable delay, and (2) a fixed (44 cycle) duration." > Is the delay time really a part of the inhibit ? I call it that but in reality it's just a delay. > For example, if B-Go<1> has a delay of 3000 clock ticks, > during this time are the other channels blocked from transmission ? Yes. The Delay is used to place the command at a time the user likes. It does not interfere with other channels. After the delay comes the 44 cycle duration. During this time all other lower priority channels are permitted to finish their current transmission and then are blocked until the higher priority channel has finished its transmission. [I guess the correct answer was "No", rather than "Yes" - T.G.] > About the Block Transmission, what is the delay > between consecutive command transmissions ? The delay can be minimal. A couple cycles of the clock max. Unless of course the TTCrx needs more time. I need to check this. A couple clock cycles is from the end of a command to the beginning of the next command. While from beging to begin is: (44 + a couple clock cycles). > Is it programmable ? No. In "Block Transmission" mode the commands are sent in a string with a fixed delay. The value of that delay can be changed now (as I program the functionality) but then it will be forever fixed. Any suggestions? When you fill the FIFO bit 33 is the "Send/No Send" bit. You will fill the FIFO with 36 bits. Bits 0 to 31 are the normal bits that you already know about. Bit 32 is "Long/Short" bit to tell what kind of command is in the lower 32, bit 33 is the "Send/No Send" - on a 'No Send' 44 clocks go by and nothing comes out, and bit 34 is the "Last Command" bit. Bit 35 is not used .... yet. So, what you can do is just set Bit 33 to '1' and it will pass time in 44 cycle increments. > the inhibit duration is now fixed at 44 clock cycles. > If I transmit a block with N commands, then the 44-cycle inhibit is per > command, so per block the inhibit duration is really (44 x N), right ? --Yes. There is a special 'Block Inhibit' signal that is created in the FPGA when there is a block send. It stops all lower priority commands from transmitting until the block transmission is finished. So the last command in the block must have bit 34 set. I read that and after that command is finished the inhibit is released. This also means that you CAN'T mix 'block' and non-block transmissions on one channel because when I read 'last command' the FIFO goes back to address 0. > - the concept of B-Data is new to me (I did not find it on the old > TTCvi); is it different from B-Channel ? The concept is new to me too....in fact so new it hasn't even been programmed yet. Here's my understanding of it: The B-Data is 8-bit and one strobe delivered to the front panel on a flat cable. The data comes in and is stored in a dual port RAM that will be made to act like a FIFO. When there is data in the FIFO a request is made for time on the B-Channel. The B-DATA has the LOWEST priority on the B-Channel (so it would be like a B-Go 16). When the B-Channel is free the request is acknowledged and B-Data is sent out as a short command. The B-Data continues to be sent out until either there is no more B-Data or a higher priority B-Go takes over. Next time the bus is free the B-data is sent again starting from where it left off. If the B-Data FIFO gets filled (1024 commands) - a flag will be set. If the B-Data FIFO is empty - a flag will be set. If a B-Data transmission is cancelled by a higher priority B-Go - a flag will be set. The cancelled command will be sent next time the bus is free. The B-Data input is a way to send short commands in a way that does not disturb the normal B-Go operation. If you want to send commands (short or long) with absolute priority then you can use the VME asynchronous send. This is a real sledge hammer so I don't think it will be used during a run.