Firewire bus initialization with TSB81BA3

Ruud,

It is very difficult to speculate on where the initialization is breaking down without looking at a bus trace. Do you have access to a 1394 protocol analyzer? Trying the same test with cycle master enabled(isoc on) will tell us something if it starts working but a bus trace would be much more informative.

Regards,

DJ

Hallo,

I'm Nicolas and I'm taking over the work of Ruud.

I have solved the problem that Ruud had uncountered, The problem was in the wrong configuration of the source ID of the message. It was just 0 (problem in the software)

Now, I'm a bit further in the devlelopment and see an other problem.

I try to perform a "Read Request Quatlet" This is the sequence as I perform it:

1/ FPGA sends a "Read Request Quatlet" Message to the Camera

2/ Camera sends a "Ackn Pending" (this is OK)

3/ Camera sends a "Read Response Quatlet" (this is also OK)

4/ FPGA sends a "Ackn Complete" to the Camera (This is going wrong)

I Have placed a Scope on the interface between the FPGA and the PHY. I can then monitor the CTR, DATA, Clocks and LREQ signal.

Each time I send an "Ackn Complete", The Phy Answers with a "Zero Data Packet" (Ctrl[0:1] = Receive Mode and Data[0:7] = FF) . The camera, located at the other side of the bus, retries 12 times to send the "Read Response Quatlet". Aparently, at each retry the FPGA fails to send the right "Ackn Complete"

a/ What is a "Zero packet"? Is that a kind of Abort communication or wrong command indication? And who generates it, is it the PHY or the Camera.

b/ How must the "Ackn Complete" message look like? I send the Ackn Complete direct after the reception of the  (Req Imediate). The PHY puts the Bus in "GRANT" with "Immediate req" and "Speed = 400". The bus is 1 clock cycle in IDLE and the, the FPGA takes the bus over. During 2 clock cycles I put CTRL= Transmit  and DATA = 1E (Ackn Complete + parity) and then put the bus in IDLE for 1 clock cycle and the PHY retakes the bus. (Almost directly after I got a "Read Zero data" Back.

Is that the right way to proceed?

c/ Do you have some application notes that explain clearely how the messages have to be made (Interface from LLC to PHY ?

Thank you very must for your help.

Have a nice day, Nicolas.

Hello Nicolas,

Please clarify the following:

   1.- The problem is only when attempting to send the "Ackn Complete" message, that means that you are able to communicate with the camera using other instructions?

   2.- When the LLC sends the "Ackn complete" to the PHY, does the PHY send something to the camera? or it just reply to the LLC with the "zero data" packet?

   3.- When you try to send the "Ackn complete" message to the PHY, you say you are setting Ctrl[0:1] = Receive mode,  how are you interpreting the "Ctrl[0:1]" in regards with the most and least significant bits:   Ctrl[MSb:LSb]   or    Ctrl[LSb:MSb]   ?

Regards.

Hello Elias,

1/ Until now, I'm only trying to send "Read Request Data Octlet" . Because I have an Acknowledge Pending back and an a Response back, I assume that the camera is able to communicate. I did not try other instructions like Write Request or Read Blocks or Isochronous transfer. My collegue Has started the design and was able to get information of the link layer of the camera. (Node info, Max Speed = 400Mbits/s...)

2/ When LLC sends "Ackn complete" I cannot tell you if the PHY actually sends somthing to the Camera. We do not have a Firewire sniffer to monitor the cable, and I don't think that the scope is going to be usfull. All I can say is that the phy answers with "Zero Data"  In the documentation, I have see that the "Zero Data" can be send back to the sender when the LLC does write a wrong message.

See Documentation, TSB81BA3-ep.pdf, page 34, receive section (figure 14)

A null packet is transmitted whenever the packet speed exceeds
the capability of the receiving PHY, or whenever the LLC immediately releases the bus without transmitting any
data. In this case, the PHY asserts receive on the CTL terminals with the data-on indication (all 1s) on the D
bus terminals, followed by Idle on the CTL terminals, without any speed code or data being transferred. In all
cases, in normal operation, the TSB81BA3 sends at least one data-on indication before sending the speed code
or terminating the receive operation.

3/ Ctrl[0] = '0' and Ctrl[1] = '1' Transmit mode used when .

I send to you the simulation I have made. I is working as I see it wit the real implementation. First, The FPGA makes a request for the bus (not in the picture) Then the Phy puts the bus in GRANT (s_phy_ctrl = 11), The code of the message is AF (speed = 400Mb/s and Imediate request) this is OK. Then PHy goes to IDLE for one clock cycle and after that the LLC send the Ackn Complete during 2 clocks cycles. then the transfer is complete. On target (FPGA) I have the same signal form, direct after the sent of the transmit, I got a "Null Packet" (Ctrl[0] = 1 Ctrl[1]=0 + Data = FF)

Remark1: It seems that Data comming from/to the PHY are in the right order. GRANT here is wel DATA = 0xAF, but data coming from/to the Firewire (Camera) are in an invertered order. Ackn Complete DATA = 0x78, And the expected packet is 1E. This is how the PHY is working. (It's a bit disturbing at first)

Remark2: You can see here that the s_phy_data_i and s_phy_ctrl_i signals are shifted of 4 ns compare to the clock (s_phy_llc_i) when the PHY is master of the bus. This shift corresponds to the td (time delay) that is specified in the datasheet. td can be 0.5 to 7ns. Then for the simulation I put is on 4ns. When LLC is master of the bus, There is no td of the FPGA.

Can you tell me if this is the right way to send an Acknowledege?

I'm currently verifying then signal integrity of the bus between the FPGA and the PHY. It is still possible that somthings are not going wel there.

Thank you very much.

Nicolas