C-PHY took a departure from the D-PHY and M-PHY naming convention. The C doesn't stand for "100 mbps", it stands for "channel limited". As in, it can run over lower quality interconnects (at least compared to what D-PHY or M-PHY would require). This presumably makes it cheaper to implement.
Thank you Joe. For clarifying the "C" in CPHY. I was guessing on the naming convention given the heavy focus on CSI/DSI support in this revision to DPHY. I agree with you that CPHY offers great promise to increasing DPHY throughput without hanging more symbol-based overhead on.
Truth is, these letters are related to symbol rates in MHz - they are Roman numerals!.
D = 500. the first D-PHY spec in 2009 said HS speed was intended to be 80 to 1000Mb/s. The upper limit has since been raised.
M = 1000. The first HS Gear was 1.248Gb/s (HS-G1A) or 1.4576Gb/s (HS-G1B). Later specs added HS-G2 and HS-G3 (and stay tuned for HS-G4).
C = 100. C-PHY is derived from D-PHY (except it doesn't forward a clock, it is embedded) but since it transfers 2.28 bits per symbol the symbol rate for the same data transmission rate can be less than half as much as D-PHY would need. According to the latest draft C-PHY spec it is "intended to define a solution for a symbol rate range of 80 to 2500 Msps per lane, which is the equivalent of about 182.8 to 5714 Mbps per lane."
It is interesting to note that C-PHY balances the current in 3 wires, does not need an extra pair of wires for clock, and achieves speeds up to M-PHY's HS-G3 but at a symbol rate 1/2.28 of M-PHY's bit rate. It reuses D-PHY's low speed mode ... I think in some cases C-PHY could be viewed as a substantial improvement over real D-PHY.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.