The difference between the two formats is purely semantic: They communicate the same information in different ways. If you're designing the hardware that is sending the stream of data, you might find JEITA easier to implement than VESA for one reason or another.
As for the bitrate, notice that the LVCLK duty cycle is asymmetrical. There's no reason why data always need to be sent in a multiple of 8. In this case, the clock is divided into 7 cycles, four in one polarity and 3 in another. Your raw datarate is going to be 45.25MHz * 7 bits * 4 lanes = 1.267gbps per link (so 2.534gbps total). Notice the lowercase 'b': these are gigabits per second, not gigabytes per second.
I don't know enough about VESA or JEITA LVDS links to know why they picked 7 bits per clock period, but if I were to take it guess it would be that since 24 bits are required for pixel data alone, they had a couple options:
- Implement this with three lanes, one for red, another for green, another for blue: This method requires a higher data rate in order to get the same transmission rate since now each lane has to operate at 362mbps rather than 316.75mbps to get the same amount of data for the same LVDS clock. Not so great. But not the worst either. It's just ~50mbps difference.
- This could be done with 4 lanes with 6 bits per clock cycle. This would probably be fine, except for the next point:
- There's also a use for having the sync signals embedded in the datastream. By adding those 3 bits you now require 27 bits of data per clock cycle. Add an extra dummy bit and now you can send all of your sync signals along with your color signals in just four data lanes. No need for extra signals like VGA and other historical protocols required. The cost is that now you get to send 7 bits each cycle in 4 lanes.
As for actual hardware implementation, things do tend to work best in groups of 8 since today's typical processors work in 8-bit bytes. Since this is just 7 bits, you'll probably have to queue up 56 bits at a time to land on a 8-bit boundary. However, I know that at least the Xilinx 7-series FPGA families have a hardware configuration for a 14-bit OSERDES. Perhaps they did that with this standard in mind...
EDIT: Clarifying things
The datarate calculation is very straightforward:
- Your clock frequency is 45.25MHz.
- You have 7 bits in each clock period. If you multiply the clock frequency by the number of bits, you'll get the number of bits send in a second, aka mbps: 7 * 45.25MHz = 316.75mbps.
- You have 8 lanes, so multiply that number by 4 to get the total data throughput: 316.76mbps * 8 = 2534mbps = 2.534gbps.
As for the asymmetrical duty cycle and 4 bits and 3 bits comment, look at the LVDS clock (sorry for this verbose explanation, stackexchange refuses to upload my picture)
- There are solid and dotted lines in each clock plot which represent the "p" and "n" electrical lines. I picked the solid line to be the "p" line, so a rising edge on that line I am calling a "rising edge" and a falling edge on that line I'm calling a "falling edge".
- Let's define a clock period as the time between two consecutive rising edges.
- Look at the number of bits during the clock period: There are 7, which is how I know that there are 7 bits per clock cycle and consequently how I was able to compute the datarate of this interface.
- Look at the number of bits between a rising edge and the following falling edge: There are 4. Since there are 7 total bits, this means that the remaining 3 bits occur after the falling edge before the next rising edge.
- If we define the time between the rising edge and the next falling edge as the "high" or "on" time of a clock and the remaining time in a period (which is between the falling edge and the next rising edge) as the "low" or "off' time, we can see that the duty cycle (the ratio of on-time to clock period) is not 50%, but is actually 57%.
- Therefore, the clock is asymmetrical because the on time and off time are different values (i.e. not symmetrical).
As for why the pixels are divided into odd and even bitstreams, I will speculate:
- Odd and even likely refers to the odd and even pixel rows of the screen.
- Historically, television signals actually only updated every other row on the screen each frame. So, if your frame was 640 rows tall and you updated at 24Hz, you would only update half the screen (320 rows) at 24Hz. So, you had odd and even frames where you would update the odd rows and then the even rows.
- As the data is received by the screen, it needs to be captured time-aligned to the LVDS clock. It is much easier to match 4 lanes to a clock rather than 8 lanes to a clock. At these speeds, the exact length of each wire on the circuit board matters (electricity travels at about 6" per nanosecond on a circuit board). The two groups of 4 lanes + clock can probably be routed independently on the circuit board and so it is much easier to match timing lengths.
- By splitting the data stream into two halves, the datarate for each stream is lowered. Instead of needing to have a ~600mbps transmitter, you only need a 300mbps transmitter. This greatly reduces the cost of the technology needed to send a large amount of pixel data to the screen.
