iLED Technologies “Made in USA” A19 LED Lightbulb

2016

Packaging I Developed

iLED Schedule

Automation I Designed

Automation HW Selection and Cost Tracking

Intel Valley Vista Visual Compute Accelerator

2015

Valley Vista Schedule

Lizard Head Pass (Intel 4 CPU Server)

2012

Lizard Head Pass Schedule

Example of Best Known Method (BKM) I Wrote:

PCSD Best Known Method (BKM)

Process to Grant Warranty and Grant Early Shipments Ahead of SRA

Rev Revision Detail Owner Date

1.0 First Ratified Version James Gates January 2014

Purpose:

The purpose of this BKM is to document a process whereby product not ready for SRA can be warrantied and shipped to

key customers. In the past, decisions to warranty product ahead of SRA were done prior to fully understand the risks and

impact associated to quality, resource load, costs, and overall customer satisfaction. This BKM will detail all of the

needed actions to understand the risks and impacts prior to making the decision to grant warranty with pre SRA unit.

Audience:

The intended audience for this BKM is managers and PDT members who are needed to take part in authorizing the

warranty of pre SRA unit.

Where can the latest version of this BKM be found?

You can find the most current, approved version of this document in the PLC Web Site under BKM Repository/Program

Management.

Why would we ever grant warranty to pre SRA units?

Mainly due to schedule delays, the need for a business decision exists to grant pre SRA units to major customers who

have critical commits to their customers. Granting warranty to pre SRA units may be the only way to retain major

customer design wins and prevent losing volume sales and lost revenue.

RAPID:

Here is the RAPID diagram showing the key participants involved in reaching a decision.

Seven Step Process

This BKM breaks down the process into seven steps. This document will detail each step and the roles. Formal exception

process should be followed for early shipments.

Step 1 – Pre-SRA Warranty Request Form

The PME assigned to the impacted PDT owns making the formal request (“R”) to the PDT regardless of who actually

wants to grant warranty ahead of SRA. The Pre-SRA Warranty request must be fully formed and include the following

information:

1. Customer or customers targeted to receive pre SRA units under warranty

2. Specific product codes involved

3. Specific config(s) that the customer plans to use and customer specific usage model should be also

considered.

a. OS used including revision

b. CPUs used (How many per system, description, speed, core count, cache size)

c. Memory used (Supplier, supplier part number, density, rank, Speed)

d. HDD used (Supplier, supplier part number, density, Speed)

e. DVD used

f. All add in cards used (Supplier, supplier part number)

g. Any other HW or adapters that will be shipped with the SKUs.

4. Priority of SKUs to be shipped (If more than one SKU recommended)

5. Specific quantity of units being requested

6. Destination geography of the key customer

7. Number of locations/n-customers each key customer plans to ship to. Certifications/Safety/UL

requirements that must be in place

8. Required Ship date

9. Recommendation on if products are (time needed to get to key customers and dollar transfers vary based

on decision):

a. Shipped out of the ODM factory direct to customer

b. Shipped out of the associated SAP warehouse Addendum B is a template that can be used to help the PME document all of the required information that then gets

passed to the PDT. Once approved, the final agreement should be archived in the PDT SharePoint folder.

Addendum B

Addendum B - Pre-SRA Warranty Request Form Template 1.0 Final.docx

Key Information for the Requester:

The overall concept of warrantying pre SRA product is a high risk endeavor. PCSD is essentially saying the early product

is production ready when it is not. A strong business case must exist such as allowing a small sample of Pre SRA product

to go out early to hold a major high volume design win. Below are some high level risk we may be taking depending on

how close to gold builds the Pre SRA build needs to take place:

1) BOMs not released to production approved status 2) Milestones missing may include lack of documentation about the part (part drawings often not created

until final part is ready (during Silver phase). 3) GEMs compliance information incomplete in SPEED (no RoHS compliance info available for customers). 4) Some parts on boards may not be RoHS compliant during pre-SRA (not sellable and must be replaced?) 5) Supplier AML may not be completed 6) Pre-SRA parts may not be available after SRA and post SRA versions may not fit on pre SRA systems.

This was a HUGE issue on the EMC PQ builds. 7) PBAs in system often have last minute changes for bug fixes (sometimes show stopper type issues).

Customer has to live with these issues or we need to agree to replace This was a HUGE issue on the EMC PQ builds.

8) Power Supplies often have last minute changes prior to SRA Another issue with the EMC builds. 9) Systems may not have Regulatory or EMI compliance in place

Step 2 – PDT Health Assessment:

The healthy assessment should include a complete listing of all gaps to SRA requirements and risk assessment

associated to these gaps. The PM is the main recipient of the formal request. All RAPID stakeholders and their managers must be copied. Once the

PM confirms all information required is provided, the health assessment process can begin. The PDT has one week to

provide. In some cases, the PDT may require more time and in this case, the PDT will notify the requester in advance.

The health assessment usually takes longer than one week if the request is made prior to POPL3. The PDM has the right

to reject the PDT doing the health assessment if known issues are too great to provide a quality Pre SRA product. If the

assessment requirements happen prior to POPL3, then the Pre-SRA plan, schedule/commits, and risks should be

captured in the POPL3 slide set.

Role of the Program Manager (PM):

The PMs owns the PDT Health Assessment. The PMs role is to drive timely feedback from RAPID input owners (“I”). As

soon as possible, the PM needs to notify the PDT when a target build can take place based on the customer demand

detailed in the request form. If the demand is being seen for the first time when the request form is submitted, it may

take as long as 12-16 weeks to get the needed material in house in order to build. All stakeholders need to know the

target build date before they can accurately assess the health because the longer we wait for builds, the healthier the

SKU requested can become. The PM schedules a PLC review meeting the day after the Health Assessment is completed

and approved by the PDT. If the decision to support is approved, the PM then serves as the interface to the PME and

TME and the driver of all PDT deliverables. The health role up should include a best case target ship date and commit

ship date. The PM owns placing the PO to either the ODM directly if direct ship from the ODM is agreed to. This PO

needs to be charged to the PME organization. If units are to be sent out of the Intel warehouse, then the PME owns

placing any sales orders directly using SAP.

Role of the Product Marketing Engineer (PME):

The PMEs is the “R” who owns submitting the formal request. Addendum B is a template to help ensure all required

information is provided. The PME owns filling out the request form and submitting to the PM (on behalf of the PDT).

Once the PM accepts the form as complete, the 1-week clock starts.

If Step 3 (Decision) is granted by the PCSD GM, the PME then completes the SOW template and sends to the customer

for sign off. The SOW must be signed off before any build take place. Addendum A is a SOW template with the correct

legal information approved by Legal. Once approved, the final agreement should be archived in the PDT SharePoint

folder.

Addendum A

Addendum A - Conditional Shipment SOW Template Rev 1.0 Final.docx

Role of the Board Development Engineer (BDE):

The BDE owns delivering to the PM document stating all of the board level differences between the revision level of the

product targeted to be under warranty and the production version. The Here is a list of what data is required:

1. PCB differences (which Fab will be used compared to the planned production Fab)

2. Board PBA/TA differences (any BOM changes known to be different from the production PBA/TA)

3. Program BMC/BIOS/SRD/FRU differences by code stack revisions level and IPN. (BDE does not own

detailing what changed between SW version)

4. List of all HW/SI validation tasks not complete or failing with the boards planned to be included.

5. Any known board hardware CQ bugs not root caused or corrected only in a future build.

6. All silicon on any given board below S-Spec along with a list of any known errata that exists.

Role of the Sys-Dev Engineer:

The Sys-Dev Engineer owns delivering to the PDT a summary stating all of the system/BIK level differences between the

revision level of the product targeted to be under warranty and the production version. Here is a list of what data is

required:

1. System TA differences (any system BOM changes known to be different from the production system

TA) – Uses BOM compare tool

2. System validation tasks not complete or failing with the boards planned to be included.

3. Understand any known system hardware CQ bugs not root caused or corrected only in a future build.

4. Status of all Certs required based on the geographies being shipped to per the request form. (Cert Label

on system modified as needed which may force a custom SKU)Normal SKUs are marked Eng Sample

Only,

5. Work with Thermal Engineer to identify thermal gaps between Pre SRA systems shipped compared to

production systems.

6. Pre SRA BOMs should be under ECO control.

Role of the Mechanical Engineer:

The Mechanical Engineer owns delivering to the PDT

1. Sheet metal and plastics differences (which are still soft tooled vs. hard tooled)

2. Providing a list of any known changes coming that may require rework or replacement of the customers

Pre SRA system.

Role of the Power Supply Engineer:

The Power Supply Engineer owns delivering to the PDT

1. Sheet metal and plastics differences (which are still soft tooled vs. hard tooled)

2. Providing a list of any known certification not complete or must be completed in order to ship to the

GEO outlined in the Addendum B.

Role of the VL(Validation Lead)

VL owns delivering overall validation task/tracker status, (Including what tasks have not started or are completed) and

also providing risk assessment to PDT. The VL is the driver for any needed customized validation plans & execution per a

customer’s possible unique configuration The VL must and drive early shipment gate defects to closure by reviewing

with stakeholders including Design/TME/QRE etc. The VL owns coordinating with all disciplines a roll up of CQ bugs not

root caused or corrected only in a future build.

Role of the Peripheral Validation Lead (PVL):

The assigned PVL owns delivering to the PDT a document stating the current completion of all PVL owned deliverables

called out in the customers planned shipping configuration. Here is a list of what data is required:

1. Approved Peripheral (AP) list tagging all AP items not yet qualified on the customers planned shipping

configuration called out in Addendum B

2. All supported OSs and OS cert status along with those not yet supported

3. Understand any known PVL CQ bugs not root caused or corrected only in a future build.

4. List of all WHQL pre testing complete and passing vs. incomplete and perhaps failing

Role of the Hardware Validation (HWV) Lead:

The assigned HWV lead owns delivering the overall HWV & SI test status to PDT including the customized validation

plans for unique customer configuration. Any HWV & SI related testing that fails or is not done associated to the

customer configuration also must be reported out.

Role of the Environmental Validation Lead (EVL) & Memory Validation Lead (MVL):

The assigned MVL lead owns delivering to the PDT a document stating the current list of formally qualified memory

along with a list of what pre testing has passed, failed or has not yet been done prior to formal memory qualification.

Any EVL related testing that fails or not done associated to the customer’s configuration also must be reported out.

Role of the Factory Test Program Manager (TPM):

The assigned TPM owns delivering to the PDT a test health document stating any features not tested or any other

possible escapes.

Role of the Material Program Manager (MPM):

The assigned MPM owns reporting back any material risks such as non-production material needed. They also need to

provide a shortage report if any parts that are critical path to the target build. If the customer demand is new and a build

must be loaded, it may take as long as 12-16 weeks to get the needed material in house in order to build. The target

build date is critical because it impacts most other disciplines response since the longer we wait for builds, the healthier

the SKU requested can become. The assigned MPM also owns the understanding and timing of all POs and send a

summary to the PDT for review.

Role of the Mfg. Engineer:

The assigned Mfg Engineer owns establishing a summary starting what special actions need to be managed such as MDs

or special instructions needed. This summary gets sent to the PDT.

1. Pre SRA BOMs should be under ECO control.

2. All Pre SRA units shipped must be logged by the serial number and product code.

Role of the OIV Engineer:

The assigned OIV Engineer owns reporting out:

1. Any known LAN feature issues with the customer’s configuration

2. Any known driver errata with the customer’s configuration

Role of the BIOS and BMC Lead:

Any Pre SRA units shipped out will not have the latest BIOS/BMC/SDR with the most possible bugs resolved. The

customer must upgrade the BIOS/BMC/SDR upon receipt. The assigned BIOS/BMC/SDR lead owns recommending which

BIOS/BMC/SDR drop to load. The BIOS/BMC/SDR lead owns delivering to the PM a document stating the revision of

BIOS/BMC/SDR to be used including a list of all features not yet implemented along with a list out of CQ stating all SRA

gating bugs not yet implemented with the recommended release.

Below key facts need to be considered for SW:

1. Some customer required specific features/specific issue fixing

2. Sometimes, BIOS will drop old stepping Silicon support on later/newer BIOS release ,we should not

drop early stepping support in future BIOS, need ensure the BIOS/BMC release can be flashed success

both forward and backward.

3. Support field upgradable.

4. SDL meeting held and should get waiver if any gaps on security.

5. BIOS/BMC release should meet SWLC requirement

Role of the product Quality & Reliability Engineer (QRE):

The product QRE owns delivering to the PDT a product qualification report, presenting the quality indicators against the

health of the SKUs defined in the SOW, defined quality criteria at the time of early shipment and a recommendation

whether the product is ready. Not completed qualification work and PRQ gaps should be listed in the Qual report. Risk

assessment shall be included for all the qualification gaps.

The health of the Pre SRA SKUs defined in the Addendum B needs to be weighed against typical PRQ criteria qualification

criteria, with the consideration of customer specific requirements and configuration.

Role of the Product Manager (PM):

The PM owns driving completion of all PDT requirements and then consolidating all of the PDT deliverables into one

presentation. The entire document is then shared with PDT and a recommendation is agreed upon which is added. This

document is the material used to present during the management decision meeting. The PDT may recommend not

supporting the PME proposal based on resources, risks, schedule hits or financial impact are not added and

management wants to hold schedule or so many resources.

As far as pricing, the PME will inflate the price enough to cover the NPI overhead and 10% RMA buffer.

Role of the Product Development Manager (PDM):

The PDM owns rolling up the incremental costs if the proposal is approved. Driving completion of all PDT requirements

and then consolidating all of the PDT deliverables into one presentation. The entire document is then shared with PDT

and a recommendation is agreed upon which is added. This document is the material used to present during the

management decision meeting. The PDT may recommend not supporting the PME proposal based on resources, risks,

schedule hits or financial impact are not added and management wants to hold schedule or so many resources.

The PDM needs to get a health assessment from any Intel silicon team if the stepping of the silicon is pre PRQ.

Role of the Technical Marketing Engineer (TME):

Owns working with the Product Repair Site to see if they will support field failures. Significant extra communication and

documentation needs to occur.

1. SOW review and agreed with customer at PDT level

2. Communicating decision made in Step 3

3. Pre-launch marketing collateral developed

4. Ensures all bugs captured by customer are entered into CQ with all the needed information such as

owner, config used, and error logs.

5. Ensure a system with the customer representative configuration can be integrated with all of the unique

peripherals or have the customer agree to send one system with the customer configuration used.

6. Own driving root cause and corrective action of all issues found by customer.

7. Logistics of shipping replacement units.

8. Working with the Product Repair Site to see if they will support field failures (if they will not sign up,

the TME would own providing technical help and repair units)

9. The Mfg Engineer provides serial numbers and product codes and the TME must track where the units

are shipped and logged by serial number.

Warranty Support:

By default, all warranty support is owned by the TME organization. This means that any failure or return from the

customer who has received pre-production units will work directly with the TME group on getting service or

replacements. The TME may negotiate with the Product Repair Site to see how much support (if any) will be supported.

The Product Repair Site agrees to, will depend on the quality and health report provided by the PDT.

RMA Support:

By default, all RMA support comes from the TME unless the Product Repair Site agrees to support. A 10% buffer will be

planned and charged to the PME group to cover replacements since no RMA process exists before SRA.

Step 3 – Decision Meeting:

The plan must be available for review 24 hours ahead of the meeting. The PCSD GM is the “D”. A meeting is scheduled in

an existing PLC or PPC time slot. The GM can allow approval by mail. All functional managers of the PDT members

contributing attend the meeting or are on the approval mail thread. The PM presents the plan along with the

recommendation. The GM approves, declines or approves with conditions/changes. TME owns communication decision

to customer

Step 4 – Customer Requirements (Accept Warranty Agreement)

The Conditional Shipment SOW (See template Addendum A) must be signed off before any builds (Step 5)

take place. Ensure customer is aware of the limitation of the products and agree on it before early shipment

decision is made. Legal has approved the wording in Addendum A but should still be involved in this process.

Step 5 – Builds (if approved):

Follow standard PRA template to get approval to trigger build. Builds are done per any MDs or other changes unique to

the pre SRA product. In most cases, the build will be 100% focused on the customer order and not be mixed with a

standard NPI build. A custom product code may be required. Any POs or sales orders should be approved and in

progress at the time of the builds.

Step 6 – Ship

Follow standard SRA template to get early ship approval for customer. Revision change control should be in place for

early ship as well

PDT to publish any needed system pedigree to customer when engineering changes are applicable to early ship

products.

Step7 –Support

The TME is the owner of all support required after shipment. All the early shipment information should be

transferred to sustaining team.

List of Stakeholders who Approved

Discipline Shanghai USA Other

PM Hong Jin Jim Gates

PDM Fan Li Jim Gates

TDE Ike Lu Chris Horton

Mfg Eng. George Jing Craig Cauvel

MPM Jason Lv/Chris Wang John He

PME Ryan Sun Madhu Bramharouthu

TME Frank Liu Rod Stepherson

BIOS TonyWang /Rock Cao Y K, Raghavendra

BMC TonyWang/ Amy Pan Mehta, Mina

OIV Lake Yu Ryan Weese

SLV Felix Zhan Vickie Huisenga

PVL Felix Zhan Tim Linn

EVL/MVL Zoe Zhou Yvonne Yang

Mech Simon Zhao Marc Milobinski

QRE Jieping Li Jason Gillick

Product Repair Site

Bernard Kiernan,

(APAC)

Ana Pedraza

(ASMO)

Bernard Kiernan,

(EMEA)

Sys-Dev Jacky Xia Dan Surratt

"D" Olive Hu Mike Hill

Example of Minutes I Wrote:

Valley Vista PDT Meeting Minutes

WW08.4 ‘15

Executive Summary:

Power On is underway. We started WW08.3 instead of WW08.1 after delivery was delayed because of a snow storm in

Tennessee where they first docked domestically. We have one more week to get the boards booting and deployed to

hold an Alpha validation start WW10.1. POPL3 is trending to WW10.

Major Milestones in Table Form

Milestone Owner Target Comment

DR0.3 Doug Opoka WW43 Done

DR0.6 Doug Opoka WW51.5 Done

Engage with ODM Chelsey Bowman WW43 Done (WW46)

POPL2 Dave Ogden WW06 Done

DR0.9 Doug Opoka WW52 Done

DR1.0 (Tapeout) Doug Opoka WW03.3 Done

POPL3 Dave Ogden/Jim Gates WW10

Major Gaps/Risks

Added Risk: Need a validation lead/tracker person to own tracker meetings and look at the “big picture” from

a validation perspective.

A/R Dave …. See if you can find an owner for the above risk.

Risk – no plan Risk w/plan On track

SW Risks provided by ITP

Topic Risk ww07 ww08 Status

SW IO

Performance

Virtual IO (Ethernet over PCI) drivers

performance may be not satisfactory for 4k

HEVC encoding.

Currently 500-900MB/s, varying

across POC setups.

SW is the bottleneck, utilizing single

CPU core @ 100%.

KNL code reused requires refactoring

to improve performance and loseless

PCI transfers.

SW Virtual IO

with Xen

POR config with Xen on Host and VV currently

blocked - VirtuIO driver not functional in Xen

Dom0.

This was expected to work, but we

see issues with mapping DMA

buffers. KNL team doesn't use such

config and cannot help.

SW

Leveraged

boot with

AMI BIOS

Features we saw working on Intel internal

BIOS are causing problems with AMI AptioV

BIOS.

Both functional issues resolved, but

with impact on schedule. 1ww delay

vs. previously assumem ww15 best

case target.

SW Alpha

release

schedule

With SW readiness trending to ww16, hitting

Alpha quality on ww17 is very high risk.

Just 1ww buffer left for test cycle

and final fixes for the Alpha release.

SW team suggests shifting schedule

by 1ww to ww18.

Helpful Links:

Valley Vista SharePoint Site:

Link to Valley Vista SharePoint Home Page

PDT Contact List:

Link to PDT Contacts

TU Spending to date can be found at:

Link to Valley Vista BTI Spending

Valley Vista CCB:

Link to Valley Vista CCB Tool

Valley Vista Build Plan:

Valley Vista Build Plan

PDT indicators:

Link to PDT indicators

PLC Checklist:

http://epsdplc.intel.com/

Opens – New Business:

SysDev Resource Needed:

This role needs to be supported. Mainly around system Qual validation management and PLC Checklist items.

A/R Jim …. See if you can get a summary of scope of work needed around.

Power On Update:

1. After a rework both PLX switches come out of reset and are able to communicate to the PLX PDE tool

over I2C. 8733 is being enumerated, and is visible to the host, but the 8713 is not due to suspected reset

timing. Avago FAE engaged.

2. Unable to access flash via the dediprog, lots of time has been spent on debugging and will continue

today.

3. Unable to access the serial ports through the USB.

4. Able to access PCH through XDP and will get ITP support as needed.

5. Thanks to the power on team that is on site from Oregon, Guadalajara, and Poland for all the long hours

and good progress so far!

Poor Yields at Dynamics:

Dynamics had poor yields and Carlos identified some major issues with the Gerber package.

All VDCRs were responded by Quanta. Quanta sent us the list of VDCRs including the ones they wanted us to

confirm what they communicated back to the fab house. All VDCRs were reviewed by the associated experts.

(CAD, SI, Mfg, BDE). All teams came back and approved the responses Quanta gave to the Fab house. GCE kept

the 4mil thickness from layer 2 and 3. PDT followed the PDG. Long term, we need to get Carlos observation

into the PDG. Dynamics followed the thinner dielectric recommendation but the results caused poor yield.

Carlos recommended moving everything off of layer 3. Meeting tomorrow at 10am to discuss. Carlos must

attend.

Old Business:

Alpha Validation Starts WW10.1

We only have 4-5 weeks to complete all gating Alpha Validation tasks.

A/R All Validation Disciplines .. Let Jim know if any major risks exist to complete Alpha in 4-5 weeks.

Latest Forecast

Total (Ku) 2015 2016 2017 2018 2019

Remote DT 0 0 5 7 4

Remote WS 0 0 5 7 4

Cloud Gaming 0 0 5 7 4

Cloud Media, Analytics 1 6 18 21 27

Total 1 6 33 42 40 121.5

Valley Vista 1 4.3392 8.37 0 0 13.7

Monte Vista 0 1.4464 25.11 41.643 39.633 107.8

POR Update:

Request for change in POR – Valley Vista SW being part of Red Hat 7.3 release:

WW07.4 …….. ITP will not do the work to get the Valley Vista SW into the Red Hat 7.3 release.

We will target Monte Vista as the first SW that is part of a Red Hat release.

CCB #1 – qualifying VV in a Dell 4130 - Open

Weekly meetings will be held

We need:

Thermal/mechanical impact

Performance SW impact

Need 3-5 systems before we can close.

Schedule

Internet bandwidth out of box (needs to be 140gb total) A/R Brian J…. Reply with and cost, schedule or resource impacts from a thermal mechanical perspective. Fill

out response in CCB tool Open WBD this week.

A/R Brian V.….. Reply with Volume forecast adder if the PDT approves the CCB. Fill out response in CCB tool.

Done

A/R Brian V.….. Request four 4130 systems from Dell to do validation with. If they will not pay, inform Jim so

he can look into purchasing. System must have at least 140gb Bandwidth Open

Schedule Review:

Team to review

PLC Checklist:

This is loaded through Alpha Exit for all disciplines.

Owners:

SW/BIOS Jarek Looked at it

PME/TME Brian No

BDE Mario No – This week

CAD/SI Mario No – This week

VR Design Salvador No – This week

System/Mechanical/thermal Brian J. Looked at it

Validation Lead TBD

MPM (Boards) Tom No – This week

TDE Chris No – This week

PM Jim Looked at it

PDM Dave No – This week

Mfg Joe

HW Verification Manh

PVL/SLV Kirk No – This week

QRE Mark A/R Brian J… Can you do the SysDev role in the checklist?

A/R Owners above …. Fill out your checklists

KIT & more LCT Reviews

Board team is looking at what additional reviews can be done before the HVM order by WW10.3.

Tom reported risk of hitting WW10.3

A/R Mario … Check and report out status … Target WW09.

A/R Mario …. Get the resources to do the VR Noise test during the Power On time frame. WBD this week. Yvonne Yang

or Manh Vu

Shall the build in WW14 be Fab 2? Open pending PO results and 10am meeting

Yes but we will not have time to do the DDR4 fix.

We will mainly rely on MVL to prioritize this testing first.

HVM Supplier for WW14 Fab 2 build of 120:

Shall we use Nanya, or GCE or both?

A/R Tom …. Send Nanya the actual gerbers. Done - Tom will ping again.

A/R Tom …. See if Nanya can do 4 weeks. Open – No response. See if Doug completed

If Nanya can do 4 weeks we will order 60 from Nanya and 60 form GCE.

If Nanya cannot do 4 weeks, the PDT will decide the ratio of Quantities.

Shall we use Nanya, or GCE or both?

Build Plan

Posted here:

Valley Vista Build Plan

POPL3 targeted for WW09 – Need your risks updated.

A/R PDT … Update your risks. Jim send a reminder

Need Product Codes and TAs and MM#s for Valley Vista

PC = VCA1283LVV (add BPP or SPP to end if beta or Silver samples)

MM# = 942876 (Production version only)

TA = H71361-100

PBA = H57152-100

HS Qual Plan

Mark is working with Quanta to get a plan together. It will be a challenge to get the Qual done and hold schedule. Brian

Jarrett is now on the team and will help.

A full quarter of testing was brought up but we still have no plan.

A/R Brian J ….Send the plan from Tao to Mark. - In progress

A/R Mark ….. Get a plan out ASAP - In progress

POR Change Request by Marketing:

Detailed Schedule:

Please remember this is our best case schedule. Some buffers will be added at POPL3 after the PDT reviews potential

risks and their schedule impacts if realized.

Target dates plus buffers will equal our PDT commit.

Build Plan:

Posted here:

Valley Vista Build Plan

Indicator Reviews:

PDT indicators:

Link to PDT indicators

Here is a matrix of who has been getting their indicators in:

Discipline Owner 39 40 41 42 43 44 45 46 47 48 49 50 52 03 04 05 06

POC Update Doug X X X X X

Ma

p

Da

y

X X X

X X

Valley Vista

Fab 1 Update

Doug X X X X X X X X

X X

X X X X

SW Update Jarek X X X X X

X X

X X X X

ISV/OEM/CSP

Update

Brian

Power (VR)

Update

Salvador X X X X X X

X X

X X X X

Thermal

Update

Jeff X X X X X X

X X

X X X X

Material

Update

Tom X X X

X X

X X

Mechanical

Update

Craig X X

ODM Selection

Update

Chelsey X

Test Update Chris X

X X

X X X X

Mfg Update Joe X

X

X X

Indicates Indicators were not requested that week or are no longer needed

Indicates no Indicator posted that week.

Attendees: Dave, Jim, Brian and list below

POR:

WW05.4 ….. 16G SODIMMs with ECC are not available until Q2 ’15.

2.4.5 Valley Vista

Memory

Types

Supported

Valley Vista will support and thus be

validated with 8G Dual Rank

SODIMMs and 16G dual Rank

SODIMMs with ECC support

1 Y

PRD will state that 16G will be validated once samples are available and the PDT will make their

“Best Effort” to qualify but this is not a gate to SRA.

WW03.4 …….. PDT will NOT develop the changes and qualify Valley Vista in GZP to allow Valley Vista to be able to ship

in the chassis. CCB will be needed including custom volume increases before we made it POR. If

approved, changes may include:

Tooling impact ($70K):

o Tooling: $70K total

o New Duct: $35K

o Support Bar: $30K

BOM Cost adder:

o Accessory kit BOM Impact: $1.50 total

o Add support bar: $1.25

o Duct cost increase: $0.25

ECO to GZP chassis SKU to add mounting features(and tooling changes)

Creation of a new accessory kit. WW49.4 ……. The custom GT3e SKU will have the same CPU ID as the standard GT3e SKU (1283V4) - The ID is 40671.

WW49.4 …….. We will use Bergquist on 100% of all of the thermally challenged components – No Gap Pads.

WW47.4 …….. We will not sell and SODIMMs with the Valley Vista product. A CCB will be needed if customer feedback

requests Valley to be shipped with SODIMMs.

WW47.4 …….. We plan to qualify the Valley Vista with two memory types only.

Two 8G dual rank SO RDIMMs or two 16G dual rank SO RDIMMs is POR.

Three-four suppliers will be qualified:

Micron/Crucial

Hynix

Kingston

Samsung WW46.4 …….. A thermal sensor will be provided for other OEMs to use and will not be used or read by any PCSD SW.

WW46.4 …….. PDT will support and qualify GZP in addition to WCP and TBD customer system SKUs.

Like the Knights cards, the valley vista cannot ship in a GZP. Valley Vista will have to ship separately and

be installed by the customer.

WW45.4 …….. Default memory for Valley Vista will be 2 8G SODIMMs (dual rank) per CPU.

WW45.4 …….. Three USB connectors will be designed into the Valley Vista for Fab 1 only. USB will not be part of the

real product.

WW42.4 …….. Soldered down SSDs will no longer be supported.

WW43.4 …….. Valley Vista will not support PXE boot across PCIe.

WW43.4 …….. The name approved for Valley Vista Sky lake Program is “Monte Vista”

WW42.4 …….. New custom CPU SKU

Lira team recommends creating a new part number but have this part actually be the

same as 1284 SKU. Valley Vista and Monte Vista PDT is OK with using 1283V4 and 1284V5 for this

custom part respectively.

We WILL NOT fuse out any features

It will be available with G0 parts in the WW04 time frame.

WW42.4 …….. CentOs7.1 with kernel 3.16.2 is POR for Host system

WW42.4 …….. CentOs7.1 with kernel 3.16.2 is POR for Valley Vista (Media SDK delivered by VPG)

WW42.4 …….. Valley Vista will deliver drivers for DomU & Dom0 for Host and Card

WW42.4 …….. CentOS 7.1 with XEN services is the only OS supported on the Host system.

WW42.4 …….. CentOS 7.1 with KVM services will be supported TBD weeks post SRA on the Valley Vista card.

WW42.4 …….. CentOS 7 with KVM services will be supported TBD weeks post SRA on the Host system.

WW40.2 …….. For the balance of 2014, we will use Cost Center 41693 & Project ID 1000500629

WW40.2 …….. HEVC scalability: no scalability solution provided by Intel other than code

samples. Code samples are not Poland team deliverables. WW40.2 ……… RemoteFX will not be supported. If a decision is made that it is needed, a CCB

will need to be processed:

WW40.2 …….. No Power saving features will be designed into the board due to realistate

constraints and added cost.

WW39.2 …….. PDT will pick option #7b and add 2 switches to the design. Diagram below.

WW35.2 …….. Only 2 power states will be offered from a HW/SW perspective. On and Off.

WW35.2 …….. Criteria to pass the POC to other team members including Poland is:

Boot

PLX working (with Host and COM module side)

Traffic generator working

Serial port working WW34.2 …….. POC Development Platform is GZP 2U.

WW32.2 ….. Valley Vista Development Platform is WCP MIC BIK (R2208WTTYC1) and GZP BIK (R2208GZ4GS9) –

plus the Accessory Duct (AGZCOPRODUCT)

WW32.2 ….. Primary OS is CentOS 7.