Samsung chooses Intel CPU for new iPad-competing Android Galaxy Tab - report

124

Comments

  • Reply 61 of 90

    Quote:

    Originally Posted by SolipsismX View Post





    I vote for the BASE-2 and BASE-10 for kilo, mega-, gigi-, tera-, et al. be addressed first. Using both 2^10 and 10^3 for kilo- is absurd. BASE-10 was first, and by a large margin, so I think the IEC Binary Prefixes of kebi-, mebi-, gibi-, tebi-, et al. be utilized... but it might be easier to get Americans to use the metric system for something other than 2 Liters of soda.


     


    You'll pry my Imperial Measurements from my cold, dead fingers! :)

  • Reply 62 of 90
    wizard69wizard69 Posts: 12,860member
    solipsismx wrote: »
    The only app I use that I think is even Java-based is a Pearson-Vue app for practice exams. That looks alright. The UI doesn't appear to be created in Java. I wish it was as I assume that would make it easier to port to Mac OS.
    There are a few apps out there that are really impressive and written in Java. Eclipse is one of them even though it is a fairly buggy piece of software. Again I'm not dissing Java or Eclipse here as I use Eclipse often. I can't remember the name but there is a fantastic little Timing Diagram piece of software out there written in Java. There is also a text editor that I never liked.
    I had thought that Wireshark uses Java since it's so incredibly ugly and clunky but Wikipedia says the UI is GIMP. I wish there was a native app for Mac OS X (or Windows) that can do what Wireshark can do.

    Actually I thought somebody was working on a native Mac OS interface to Wireshark. You might want to do a quick search though maybe the project died. I have to agree though Wireshark has one ugly interface.

    Not to pull this thread completely off the rails but a few comment about Eclipse. One thing to like about it is that it is cross platform. This makes it very handy if you work on multiple platforms. Being Java it is very multi threaded and as such you really need a multi core processor to get Eclipse to work half decently, this happens to be true with a lot of Java apps. Fast multi core hardware has made Eclipse more bearable but native apps like XCode and Visual studio though work much better on their respective platforms. Even EMACS can feel snappier than Eclipse. Eclipse has a pretty huge following of developers actually working on Eclipse code, as such the sheer number of hands at play have built a rather impressive but bulky package. It isn't uncommon for Eclipse to take nearly a GB of disk space. Bulk though seems to be a theme for a lot of Java apps.

    In any event I just wanted to point out that Java has brought us some interesting apps. It may be less than ideal but hardware has done much to make Java more interesting or maybe half respectable. Native code and apps still feel better in my experience.
  • Reply 63 of 90
    wizard69wizard69 Posts: 12,860member
    solipsismx wrote: »
    I vote for the BASE-2 and BASE-10 for kilo, mega-, gigi-, et al. be addressed first. Using both 2^10 and 10^3 for kilo- is absurd. BASE-10 was first, and by a large margin, so I think the IEC Binary Prefixes of kebi-, mebi-, gibi-, et al. be utilized... but it might be easier to convince Americans to use the metric system for something other than 2 Liters of soda.


    Actually the IEC can go to hell. I've never understood this issue in the first place. Context is everything.

    I work on systems that use a lot of octal notation, sometimes it does confuse me especially if I come off another system where it isn't used. But who's fault is it if I forget to make the mental context shift? Frankly this is just another IEC proposal that the standards people came up with to justify their jobs. Computer systems have always been binary so there is no problem at all with using kilo mega and what have you in this context. IEC Binary Prefixes are a solution to a problem that never existed.
  • Reply 64 of 90
    solipsismxsolipsismx Posts: 19,566member
    wizard69 wrote: »
    Actually the IEC can go to hell. I've never understood this issue in the first place. Context is everything.

    I work on systems that use a lot of octal notation, sometimes it does confuse me especially if I come off another system where it isn't used. But who's fault is it if I forget to make the mental context shift? Frankly this is just another IEC proposal that the standards people came up with to justify their jobs. Computer systems have always been binary so there is no problem at all with using kilo mega and what have you in this context. IEC Binary Prefixes are a solution to a problem that never existed.

    Imagine if what you call octal was also called hex or binary. When it comes to a numerical value it's highly important that the terms aren't easily interchangeable. Saying kilo = 1024 after kilo was equal to 1000 should have never happened in the first place.
  • Reply 65 of 90
    iang1234iang1234 Posts: 35member

    Quote:

    Originally Posted by SolipsismX View Post





    The only app I use that I think is even Java-based is a Pearson-Vue app for practice exams. That looks alright. The UI doesn't appear to be created in Java. I wish it was as I assume that would make it easier to port to Mac OS.



    I had thought that Wireshark uses Java since it's so incredibly ugly and clunky but Wikipedia says the UI is GIMP. I wish there was a native app for Mac OS X (or Windows) that can do what Wireshark can do.


     


    WebObjects that Apple uses is also a Java app :) I believe there are far more Java apps running on server than on desktop machines.


     


    Wireshark is native app in sense that it does not run on a virtual machine. The GUI toolkit that it uses, GTK+, is also native. However, it is not native as in natively comes with OS X.(i.e. Cocoa)

  • Reply 66 of 90
    iang1234iang1234 Posts: 35member

    Quote:

    Originally Posted by wizard69 View Post



    Computer systems have always been binary so there is no problem at all with using kilo mega and what have you in this context.


     


    Unfortunately not all "kilo" in computer systems is 1024. When we are talking about network bandwidth, kilo is still 1000. So 1 kbps is 1000 bps. (network is part of the computer system right?)

  • Reply 67 of 90
    gatorguygatorguy Posts: 20,894member
    Ah, a million thanks Soli and Wizard. I have a perfect grasp on it now.:err:
  • Reply 68 of 90
    jeffdmjeffdm Posts: 12,946member
    solipsismx wrote: »
    I vote for the BASE-2 and BASE-10 for kilo, mega-, gigi-, et al. be addressed first. Using both 2^10 and 10^3 for kilo- is absurd. BASE-10 was first, and by a large margin, so I think the IEC Binary Prefixes of kebi-, mebi-, gibi-, et al. be utilized... but it might be easier to convince Americans to use the metric system for something other than 2 Liters of soda.

    Which is a tangential issue, and I honestly don't think this is a big deal. It was only an issue in regards to reported hard drive capacity vs. what was said on the box, and that issue seems to have died down with better reporting in the computer dialogue.
  • Reply 69 of 90
    solipsismxsolipsismx Posts: 19,566member
    jeffdm wrote: »
    Which is a tangential issue, and I honestly don't think this is a big deal. It was only an issue in regards to reported hard drive capacity vs. what was said on the box, and that issue seems to have died down with better reporting in the computer dialogue.

    The issue hasn't died so much as the discrepancy has gotten so large that it's harder to be misunderstood in regards to HDD capacities but we still issue here nearly every week. It wasn't too long ago that an article claimed that Android OS plus Samsung apps on the S4 used xGB by subtracting the remanding capacity as noted by the OS (BASE-2) by the initial NAND capacity (BASE-10).
  • Reply 70 of 90
    mdriftmeyermdriftmeyer Posts: 7,291member


    Samsung backed the wrong boat on this one. AMD is already eating Intel's lunch in this market space and will only expand with its most recent line up to compete against Haswell's low power alternatives.



    Meanwhile, GlobalFoundries just turned up the heat:



    http://www.techpowerup.com/184728/globalfoundries-accelerates-adoption-of-20nm-lpm-and-14nm-xm-finfet-processes.html

     


     


    Quote:


    GLOBALFOUNDRIES Accelerates Adoption of 20nm-LPM and 14nm-XM FinFET Processes



    At next week's 50th Design Automation Conference (DAC) in Austin, Texas, GLOBALFOUNDRIES will unveil a comprehensive set of certified design flows to support its most advanced manufacturing processes. The flows, jointly developed with the leading EDA providers, offer robust support for implementing designs in the company's 20nm low power process and its leading-edge 14nm-XM FinFET process. Working closely with Cadence Design Systems, Mentor Graphics and Synopsys, GLOBALFOUNDRIES has developed the flows to address the most pressing design challenges, including support for analog/mixed signal (AMS) design, and advanced digital designs, both with demonstration of the impact of double patterning on the flow.



    The GLOBALFOUNDRIES design flows work with its process design kits (PDKs) to provide real examples that demonstrate the entire flow. The user can download the design database, the PDK, detailed documentation and multi-vendor scripts to learn how to set up and use the GLOBALFOUNDRIES design flow. The flows use open source examples and provide the customer with working, executable and customizable flows.

    "As the developer of the industry's first modular 14nm FinFET technology and one of the leaders at 20nm, we understand that enabling designs at these advanced process nodes requires innovative methodologies to address unprecedented challenges," said Andy Brotman, vice president of design infrastructure at GLOBALFOUNDRIES. "By working with a new level of collaboration with EDA partners, we can provide enhanced insight into our manufacturing processes in order to fully leverage the capabilities of 20nm and 14nm manufacturing. This provides our mutual customers with the most efficient, productive and risk-reduced approach to achieving working silicon."



    Production Ready AMS flow from specification to verification

    To address the unique requirements of analog/mixed signal (AMS) design at advanced processes, GLOBALFOUNDRIES has enhanced its design flows to provide production quality scripts and packaged methodologies. The new reference flow establishes a working flow from specification to physical verification that has been taped out to be verified on working silicon.



    The AMS reference flow provides comprehensive double pattern design guidelines. It gives overview of decomposition flow for both block level and chip level. The flow also addresses decomposition for different design styles. Recommendations for color balancing, hierarchical decomposition, ECO changes are discussed. The flows also present decomposition impact on DRC run time and resulted database size.



    Notably, the reference flow includes support for efficiency and productivity improvements in the Cadence Virtuoso environment specifically for designing in a double patterned process. The flow includes support for Virtuoso Advanced Node 12.1 and provides efficient access to the tool's productivity benefits for physical design with real-time, color-aware layout. Circuit designers can assign "same net" constraints in the schematic, and the layout designers can meet these requirements as they create the physical view. Additionally, layout designers can take advantage of Virtuoso tool support for local interconnect, and advanced layout dependent effect management.



    The flow also features interoperability with Mentor's Calibre nmDRC, nmLVS, and extraction products which address multipatterning requirements for both double and triple patterning. In addition special settings for analog design; auto-stitching and when to use it; and fill and color balancing are described in detail.



    The AMS flow provides detailed information on parasitic extraction and layout dependent effects, both of which introduce new challenges at 20nm and 14nm. For parasitic extraction, the flows are described in detail and customizable scripts and examples demonstrate OA and DSPF back annotation. In addition the flows illustrate methodologies to predict layout-dependent effects during schematic design and methods to include full models in post layout extraction. PEX flows for Synopsys StarRC extraction, Cadence QRC and Mentor CalibrexRC are supported.



    These flows serve as references to validate the correctness of the accompanying PDK as well as the vendor tools setup.



    Sign-off ready RTL2GDSII flows that address double patterning

    GLOBALFOUNDRIES is also making available new flows that support a complete RTL-to-GDSII design methodology for targeting its 20nm and 14nm manufacturing processes. The company worked with EDA vendors to certify the flows in their respective environments and provide a platform for optimized, technology-aware methodologies that take full advantage of the performance, power and area benefits of the processes.



    The result is a set of fully executable flows containing all the scripts and template files required to develop an efficient methodology. The flows serve as a reference to validate the correctness of the accompanying PDK as well as the vendor tool setup. In addition the flows offer access to other critical and useful information, such as methodology tutorial papers; guidelines and methodologies for decomposition of double patterned layouts; PEX/STA methodology recommendations and scripts; and design guidelines and margin recommendations.



    A critical aspect of manufacturing at this level is the use of double patterning, an increasingly necessary technique in the lithographic process at advanced nodes. Double patterning extends the ability to use current optical lithography systems and the GLOBALFOUNDRIES flows provide comprehensive double pattern design guidelines. They address design for double patterning and the added flow steps for different design styles and scenarios.



    This includes support for odd cycle checking, a new type of DRC rule that must be met to allow for legal decomposition of the metals into two colors. This check is detailed in the flow and guidelines are provided to make sure it is met.



    Synopsys and GLOBALFOUNDRIES worked together to minimize the impact of changes associated with the 3-D nature of FinFET devices as compared to planar transistors. The two companies focused on making FinFET adoption transparent to the design team. The collaboration on Synopsys' RTL to GDSII flow includes 3-D parasitic extraction with the Synopsys StarRC tool, SPICE modeling with the Synopsys HSPICE product, routing rules development with the Synopsys IC Compiler tool and static timing analysis with the Synopsys PrimeTime tool.



    Cadence contributed a complete RTL-GDSII flow, including physical synthesis, and planning and routing developed with the Encounter Digital Implementation (EDI) System foundation flow. The seamless implementation flow, using Cadence Encounter RTL Compiler and EDI System, supports double patterning and advanced 20- and 14-nm routing rules.



    Mentor's Olympus-SoC place and route system is supported in the flow, providing support for new DRC, double patterning, and DFM rules. The Olympus-SoC router has its own native coloring engine along with verification and conflict resolution engines that detect and automatically fix double patterning violations. Expanded features include DP-aware pattern matching, coloring aware pin access, pre-coloring of critical nets, and DP aware placement. The Calibre InRoute product allows Olympus-SoC customers to natively invoke Calibre signoff engines during design for efficient and faster manufacturing closure.



    Double patterning also impacts LVS and other DRC issues, and the flows provide methodology details to address these areas, including hierarchical decomposition to reduce data base explosion. Parasitic extraction methodologies and scripts are provided as well, offering ways to address double patterning-induced variations via DPT corners or with maskshift PEX features.


  • Reply 71 of 90
    solipsismxsolipsismx Posts: 19,566member
    You'll pry my Imperial Measurements from my cold, dead fingers! :)

    Well you'll have to pry my binary correctness from my 10 cold, dead hands. :p
  • Reply 72 of 90
    relicrelic Posts: 4,735member
    A x86 Android tablet can use the same apps that a ARM based tablet can. Dalvik, like Java is CPU architecture independent, the Asus Fonepad which is Atom based has no problems playing games like Nova 3, GTA Vice City, Max Payne, ect.
  • Reply 73 of 90
    suddenly newtonsuddenly newton Posts: 13,762member
    rogifan wrote: »
    I see we've veered off to SamsungInsider again...

    But but but ... I don't understand why Apple users don't want to hear about the competition! Only rational and open-minded people appreciate competition (and the rest of you are iSheep). /s
  • Reply 74 of 90
    nhtnht Posts: 4,494member
    solipsismx wrote: »
    jragosta is correct.

    Running MS Windows on a PPC Mac is emulation because Windows only had binaries for x86. Running MS Windows on an Intel Mac is virtualization because Windows understands the HW. That means it al had to be emulated so that the processor code understand what the OS was requesting. This made it very slow even on the fastest systems. Many Intel chips are even designed to allow a VM to take advantage of the HW with less overhead but the OS needs to understand x86 or x86_64 HW for this to work.

    No, there isn't ARM emulation happening. The Dalvik vm runs as a native x86 binary. The binary translator converts ARM machine code to equivalent X86 code.
  • Reply 75 of 90
    solipsismxsolipsismx Posts: 19,566member
    relic wrote: »
    A x86 Android tablet can use the same apps that a ARM based tablet can. Dalvik, like Java is CPU architecture independent, the Asus Fonepad which is Atom based has no problems playing games like Nova 3, GTA Vice City, Max Payne, ect.

    This is also true for all apps built and compiled with Android NDK?

    edit: It appears Google has worked on allowing fat binaries for 3rd-party developers for their NDK. Apparently APP_ABI := all will compile binaries for ARMv5, ARMv7, x86_32 & MIPS_32.

    nht wrote: »
    No, there isn't ARM emulation happening. The Dalvik vm runs as a native x86 binary. The binary translator converts ARM machine code to equivalent X86 code.

    I didn't say it was happening with Java. I said he's correct that emulation is not virtualization.
  • Reply 76 of 90

    Quote:

    Originally Posted by Tallest Skil View Post


    So what does this mean? Incompatibility with everything made before it?



    It means they're sacrificing battery longevity. Want proof? Compare Surface Pro and Surface RT. Night & Day.  

  • Reply 77 of 90
    jragostajragosta Posts: 10,473member
    gatorguy wrote: »
    . . . and?
    Would it then be using emulation or virtualization? I'm way over my head when it comes to technical issues like that and so would defer to you.

    Cool. I found my new signature.
  • Reply 78 of 90
    jragostajragosta Posts: 10,473member
    nht wrote: »
    No, there isn't ARM emulation happening. The Dalvik vm runs as a native x86 binary. The binary translator converts ARM machine code to equivalent X86 code.

    But you still have inefficiencies in the translation - so the translated app will generally run slower.

    Not to mention that there will be incompatibilities and some apps won't run (even Anand's report confirms this). As just one example, if the app is based on Flash, it's going to have trouble - since the latest versions of Flash won't run on Dalvik. And since we heard endlessly how critical Flash was, that's an important deficiency.
  • Reply 79 of 90
    gwmacgwmac Posts: 1,797member


    It is nice to see that Intel is finally starting to take this market seriously and may one day be a potential Apple supplier. It would be nice to see these two iconic American technology giants expand their partnership beyond the Mac line into iOS devices. I must admit I was surprised to hear Samsung would be partnering with them before Apple since I always assumed they would go in house whenever possible but I guess they have their reasons. 

  • Reply 80 of 90

    Quote:

    Originally Posted by dreyfus2 View Post


     


    My point (it might well be irrelevant, what do I know) is simply that I would consider it surprising if Samsung would release a mass market device (supposed to compete with the iPad, Amazon's and Samsung's own ARM devices) that would be incompatible with quite a few Android apps, especially since Android is still short of dedicated tablet apps. What is the actual benefit of a x86 CPU when running Android? A product needs at least one selling point. It won't be lighter, it won't be cooler, it can't be cheaper, and it definitely won't have more battery life... so, what is the point?




     


    Quote:


    Originally Posted by AppleFanPro View Post


    It means they're sacrificing battery longevity. Want proof? Compare Surface Pro and Surface RT. Night & Day.  



     


     


    For Samsung to switch to Intel's Atom lineup for a tablet, there has to be an extremely compelling reason that they would give up using their own SoCs.  My guess is that it will have better performance and longer battery life than the competition.  And who knows what's in store for future versions with Bay Trail later this year.


     


    The comments about Intel's battery life in Atom products isn't accurate.  If you are comparing a Surface Pro with Surface RT, remember that Surface Pro has an Intel Core i5 chip, not Atom.  If you read about the latest Intel Medfield chips in smart phones, you see they deliver the same battery life (with better performance) than ARM-based phones (for example, see the comparisons with the Motorola Razr M with Qualcomm versus Razr i with Intel).


     


    It's a good point though - there must be something really spectacular about the chips that would Samsung choose them over their own chips.  My guess is that Samsung compared their own roadmap with Intel's and made the decision to switch.

Sign In or Register to comment.