I have heard a lot of people talk about CXL being a new paradigm in computing interconnects. But if we skip over the few technical flaws in the presentation itself. (FPGAs is just a cost effective ASIC development platform for low volume products in some cases... It isn't really "different" than an ASIC itself, so listing both at 4:30 is redundant, similar story for AI and Machine Learning at 17:00) The statement at 18:45 about it being prohibitively more expensive to make a dedicated CXL connector and the reasons given aren't actually all that true in practice. (Making 2-4 product skews does add cost, but it isn't as gigantic as to be prohibitively expensive, especially if it gives additional performance (that sometimes might be of importance) due to having a more suitable connector for the job.) Other than that, using PCIe connectors as stated isn't stupid. Over at 36:00 I do have to ask, is all of the memory mapped as device/host biased, or can we dedicate what bias we want for certain portions of our memory? If we can portion of the memory in sections, then this would increase overall system performance since we can more dynamically scale it to our needs. (If this isn't the case, then host biased could lead to performance bottlenecks due to the CXL interface itself.) Then we have the protocol muxing, and fixed package size constraints. Both these do lead to additional protocol overhead, decreasing overall throughput over our link. Now the argument given is latency. But I have to say that this is a bit of an incorrect approach to the situation... It would have been better if the lanes of the interface were divided up, so that we can send low priority packages over only a portion of the link, while leaving resources left on the table for our higher priority packages. (And by having a variable payload size we can also get higher overall bandwidth for tasks that require this.) Also, in regards to the memory controllers being installed in a system as seen at 40:50. Here it would be beneficial if a device/program could inform the memory controller that it wants to receive cache updates if the memory contents gets changed by another device/program. This would make certain clustered applications perform better. (If an application can state what needs to be cache coherent, then we can more efficiently utilize our resources. And this is applicable to the whole caching environment at large.) Otherwise this has been an informitive video, but CXL seems a bit lackluster, but it sure brings some interesting features to the table compared to just PCIe.
Yes! You can find it on the CXL Consortium website in the resource library: b373eaf2-67af-4a29-b28c-3aae9e644f30.filesusr.com/ugd/0c1418_69c5b01236ad4ebeb5c6aaa16a866b7c.pdf
![NISAMANEE - TADA (ท้าดา) [ OFFICIAL MV ]](http://i.ytimg.com/vi/hcQHEPMmJpU/mqdefault.jpg)
I have heard a lot of people talk about CXL being a new paradigm in computing interconnects.
But if we skip over the few technical flaws in the presentation itself. (FPGAs is just a cost effective ASIC development platform for low volume products in some cases... It isn't really "different" than an ASIC itself, so listing both at 4:30 is redundant, similar story for AI and Machine Learning at 17:00)
The statement at 18:45 about it being prohibitively more expensive to make a dedicated CXL connector and the reasons given aren't actually all that true in practice. (Making 2-4 product skews does add cost, but it isn't as gigantic as to be prohibitively expensive, especially if it gives additional performance (that sometimes might be of importance) due to having a more suitable connector for the job.) Other than that, using PCIe connectors as stated isn't stupid.
Over at 36:00 I do have to ask, is all of the memory mapped as device/host biased, or can we dedicate what bias we want for certain portions of our memory?
If we can portion of the memory in sections, then this would increase overall system performance since we can more dynamically scale it to our needs. (If this isn't the case, then host biased could lead to performance bottlenecks due to the CXL interface itself.)
Then we have the protocol muxing, and fixed package size constraints. Both these do lead to additional protocol overhead, decreasing overall throughput over our link. Now the argument given is latency. But I have to say that this is a bit of an incorrect approach to the situation... It would have been better if the lanes of the interface were divided up, so that we can send low priority packages over only a portion of the link, while leaving resources left on the table for our higher priority packages. (And by having a variable payload size we can also get higher overall bandwidth for tasks that require this.)
Also, in regards to the memory controllers being installed in a system as seen at 40:50.
Here it would be beneficial if a device/program could inform the memory controller that it wants to receive cache updates if the memory contents gets changed by another device/program. This would make certain clustered applications perform better. (If an application can state what needs to be cache coherent, then we can more efficiently utilize our resources. And this is applicable to the whole caching environment at large.)
Otherwise this has been an informitive video, but CXL seems a bit lackluster, but it sure brings some interesting features to the table compared to just PCIe.
This is great. Are there any videos of training slides ?
How the communication happen between transmitter cxl link layer and receiver cxl link layer?
can you provide the ppt
Yes! You can find it on the CXL Consortium website in the resource library:
b373eaf2-67af-4a29-b28c-3aae9e644f30.filesusr.com/ugd/0c1418_69c5b01236ad4ebeb5c6aaa16a866b7c.pdf