dukelec / cdbus

CDBUS (Controller Distributed Bus) Protocol and IP Core
140 stars 51 forks source link

About the DIV_xx_x parameter #1

Open David7Pan opened 2 years ago

David7Pan commented 2 years ago

Is there any way to reduce the minimum value of parameter DIV_xx_x from 2 to 1? I try to figure it out, but there still some confused questions like : Why the minimum value of parameter DIV_xx_x is 2? What the INIT_VAL means in cd_baud_rate module?To adjust the phase ?

Blessing!

dukelec commented 2 years ago

The theoretical minimum multiplier for oversampling is 3. (The DIV is counted from 0, so the minimal DIV value is 2.)

The following explains why oversampling is not feasible for 2. The waveform above is the 2x rising edge sampling clock, and the waveform below is the UART rx data:

   s   s   s   s   s
   1   2   3   4   5
   ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐
 ──┘ └─┘ └─┘ └─┘ └─┘ └──

 ──────┐       ┌───────
       └───────┘
 idle    start    bit0    ...

If s2 is sampled to 0, then s3 is used as the middle to get the correct data. But if s2 samples to 1, then s3 samples to 0, and the final sample value of s4 may be 0 or 1. Unlike the internal communication of FPGA, the clock accuracy of the external communication varies from node to node, and with noise and jitter, 2x sampling is not guaranteed to be correct. Moreover, when using 2x oversampling, the clock accuracy error will continue to accumulate if multiple bytes are received continuously.

To achieve 3x oversampling, the logic is more complex than higher oversampling, and requires careful tuning of the data synchronization between modules. sync_3x and INIT_VAL are both for adjusting the phase.

David7Pan commented 2 years ago

Thank you for your reply. I got a new question, actually hoping to know, that in the cd_tx_ser module, why Arbitration Mode do not need 'tx_pre_len', but other modes need?

dukelec commented 2 years ago

The total output data has three states: Strong 0, Strong 1 and Weak 1.

The tx_pre_len corresponds to strong 1 output, while strong 1 output is not allowed in arbitration phase, so there is no tx_pre_len in arbitration mode.

If there is no tx_pre_len when outputting data, there will be a delay in the beginning of the output data after it passes through the 485 interface chip:

 ttl output: ──────┐       ┌───────
                   └───────┘       
 485 output: ───────┐      ┌───────
                    └──────┘       

(Because the time required to enable the output of the 485 chip is much longer than the delay in data transfer. The specific time lengths can be found in the corresponding 485 chip manuals.) (The above figure ignores the delay in data transfer, as it is relatively short.)

This delay can cause problems in high-speed communication, but the rate of arbitration stage is usually not more than 1Mbps, so it does not cause problems.

David7Pan commented 2 years ago

When reach_max_idle ,BS mode will send a break character, why this character does not need tx_pre_len? Will the delay cause the receiver got a wrong break character (be less than 10 bits) ?

dukelec commented 2 years ago

Because there may be multiple nodes sending the break character at the same time. Similar to arbitration mode, strong 1 data is not allowed to be sent in case of possible data collisions, so tx_pre_len is not used.

The received data may be shorter than 10 bits, but this will not cause problems. This is because the purpose of sending the break character is to put the bus into a non-idle state.

HunterLiu0517 commented 20 hours ago

The total output data has three states: Strong 0, Strong 1 and Weak 1.

The tx_pre_len corresponds to strong 1 output, while strong 1 output is not allowed in arbitration phase, so there is no tx_pre_len in arbitration mode.

If there is no tx_pre_len when outputting data, there will be a delay in the beginning of the output data after it passes through the 485 interface chip:

 ttl output: ──────┐       ┌───────
                   └───────┘       
 485 output: ───────┐      ┌───────
                    └──────┘       

(Because the time required to enable the output of the 485 chip is much longer than the delay in data transfer. The specific time lengths can be found in the corresponding 485 chip manuals.) (The above figure ignores the delay in data transfer, as it is relatively short.)

This delay can cause problems in high-speed communication, but the rate of arbitration stage is usually not more than 1Mbps, so it does not cause problems.

Wyh " the rate of arbitration stage is usually not more than 1Mbps"? Is there something wrong when the arbitration rate > 1Mbps?