A seriously interesting article about fab times. Post: 302998080

Sponsored Content

Special Forums News, Links, Events and Announcements A seriously interesting article about fab times. Post 302998080 by cb88 on Wednesday 24th of May 2017 10:58:36 PM

05-24-2017

Registered User

That really is a great article, I think one of the ways Intel is going to work around this is multi process chips... so things that aren't as performance intensive are going to be made on older faster cheaper processes, or more optimized processes. So they can make IO optimized drivers for high speed ram interfaces, logic optimized areas for the CPU, and low cost peripheral areas. It is certainly interesting to see companies trying to cope with the limits they are running up against. As well as they can conentrate on making only one sub unit faster per generation... rather than thier tick - tock tock they have been doing. They could do some iteration on aspects of the design without having to worry about parts that won't change getting broken by moving to a new process etc.. .

I've seen some ideas about die stacking of CPU and GPU components instead of chips ram as is done with HBM. So, perhaps they would make tiny very high yeild dies, but stack a bunch of them and run them rather slowly for a higher aggregate speed so they don't fry themselves with heat.

As an aside I've actually seen Daifuku (Wynright is the specific branch I've worked with) equipment installed in several locations where I have been out on an on site setup trip for the equipment my employer makes... very cool cranes (I've seen them shuffling shoe boxes and potato chips) though apparently they shuffle computer chips around as well!

Last edited by cb88; 05-25-2017 at 12:03 AM..

cb88

View Public Profile for cb88

Find all posts by cb88

4 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

An interesting problem

hi!, here is an interesting problem ..... I ftp a file named " my first file.doc" from windows to my HP workstation. Ftp is succesful. The file appears with the same name in my home directory.. But now how do I open this file?? while using Vi or More or other editor, they take only the...

2. Shell Programming and Scripting

interesting problem

Hi, I am new in this forum and I am glad to be a part of it. I have a problem that has two parts: 1/ extract just the timestamp from a filename: for example, I have a file called 'sales20080226144525.txt' and I want to extract just the '20080226144525' part out of it. 2/ Now, take that...

3. AIX

how would you know your server was rebooted 3 times or 5 times

Is there such location or command to know how many times did you reboot your server in that particular day?in AIX.

4. Programming

Problem with implementing the times() function in C (struct tms times return zero/negative values)

Hello, i'm trying to implement the times() function and i'm programming in C. I'm using the "struct tms" structure which consists of the fields: The tms_utime structure member is the CPU time charged for the execution of user instructions of the calling process. The tms_stime structure...

LEARN ABOUT DEBIAN

cpuburn

cpuburn(1)																cpuburn(1)

NAME

       cpuburn, burnBX, burnK6, burnK7, burnMMX, burnP5, burnP6 - a collection of programs to put heavy load on CPU

SYNOPSIS

       burnBX
       burnK6
       burnK7
       burnMMX
       burnP5
       burnP6

DESCRIPTION

       These  programs	are designed to load x86 CPUs as heavily as possible for the purposes of system testing ("burn in").  They have been opti-
       mized for different processors.	FPU and ALU instructions are coded in an assembler endless loop.  They do not test every instruction.  The
       goal  has  been to maximize heat production from the CPU, putting stress on the CPU itself, cooling system, motherboard (especially voltage
       regulators) and power supply (likely cause of burnBX/burnMMX errors).  The programs produce no output, but  signal  hardware  errors  by  a
       return code or (more likely) your machine locking up.

       burnP5	 is optimized for Intel Pentium with or without MMX CPUs
       burnP6	 is optimized for Intel PentiumPro, Pentium II & III CPUs
       burnK6	 is optimized for AMD K6 CPUs
       burnK7	 is optimized for AMD Athlon/Duron CPUs
       burnMMX	 tests cache/memory interfaces on all CPUs with MMX
       burnBX	 is an alternate cache/memory test for Intel CPUs

USAGE

       Burn  testing  is  designed to make your computer glitch if it has hardware problems, so make sure that nothing critical is running and all
       critical data is saved back to the hard-drives.	The best is to run it with filesystems mounted read-only.  Note that root  privileges  are
       not required.

       Run  the desired program in the background, checking the error result.  You'll may want to repeat this command for every processor you have
       in an SMP or HyperThreading system.  For example,

	   burnP6 || echo $? &

       Monitor progress of cpuburn by ps.  You can monitor CPU temperature and/or system voltages through ACPI or using the lm-sensors package	if
       you system supports it.	When finished, kill the burn* process(es).  For example,

	   killall burnP6

BUGS

       Report all bug to submit@bugs.debian.org, for more information visit http://bugs.debian.org

AUTHORS

       cpuburn was written by Robert Redelmeier <redelm@ev1.net>

								   June 04, 2011							cpuburn(1)