6. 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.
7. 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
8. 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
9. 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.
10. 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.
11. 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.
12. 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)
13. 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.
14. 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
15. 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.
16. 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
17. 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/
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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.
25. 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.
