I think that 4000 gates is something which makes the difference. I would agree that 400 or 40 gates could be statistic error, but 4k, especially in 8051 could be useful.
When someone's licensing ARM, he surely gonna stick to that. But what about thousands or millions of designs based on 8051? Wouldn't be interesting replace good, old fashion 8051 with DT8051 which consumes less energy, less area and gives 8x higher performance. When you drive to job, you don't need a Ferrrari car - speed limits and traffic jams will kill the joy of driving that dream from Maranello.
And re the proprietary stuff which is being offered with DT8051. As it is 100% compatible with 8051 standard, you can use all the tools you have for 51. And if DCD offers extra, proprietary tools, which can boost your design - I can only say: gimme more.
So, the difference is 4000 gate counts, whatever gate counts are as there are several ways to count them.
If a company doesn't have a license for the Cortex-M0(+) it can be interesting indeed. On the other hand, the silicon size difference in a .18 um process is just about 0.1 mm2, sometimes this fraction of a cent lower cost might make a difference. However, possibilities with an ARM core are endless and many companies have been using ARM M-cores for a few years and probably don't want to head this step back.
Some data is missing in this article; what is the power consumption of this core? If it can beat the M0+, the lowest power MSP430s, PICs or AVRs that can make a difference. If not, I doubt this core will fly just because it offers the lowest advertised gate count. Power, licensing costs and support for the propriety debugging interface are not covered in this article.
The additional information on the DCD webpage shows support from all the known 51 compiler vendors as expected for a binary compatible core. It also shows the propriety debugger interface that depends on the also propriety hardware DCD hardware assisted debugger.
All this propriety stuff for what they claim a standard core?
Been there and done that, using an almost standard 51. Won't do it again.
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.