dispatches from the trenches -...
Post on 19-Sep-2019
3 Views
Preview:
TRANSCRIPT
2
Dispatches from the trenches
• We want … – More bandwidth, more memory, more performance, less latency
• System design involves many tradeoffs, and boundary condi9ons – Cost – Schedule – Power consump:on – Chip area – Bandwidth – Latency – …
• Each chip capability has a footprint and power budget – Defined early in the design process
• Bo?lenecks are the places where design tradeoffs can make a difference – Key is to iden:fy where app is being limited by features, and where tradeoffs
can impact the performance or scale of the app
Typical Custom HPC System Timeline
3
Technology Assessment
Conceptual Design &
ArchitectureChip Layout
Detailed Chip Design
Simula:on for V&V
Fab
Inte-‐grate & Test Fab
Systems SoJware
Compilers and Libraries
Packaging and Thermal Design
Re-‐vise Tes:ng at
Scale
R&D
You are Here
Year 1 Year 2 Year 3 Year 4
4
Different kinds of confidential information
• 0-‐6 month advanced product previews – Easy to obtain; not much help with app development
• 6-‐18 month roadmaps – Simple NDA; some value to near term app design
• Conceptual design of a future product – Available to a few important customers; advance feedback
• Broadly par9cipate in engineering tradeoff decisions – Rare opportunity for small set, e.g., Blue Gene; true co-‐design
• Deep material on “crown jewel” technologies – Historically employees only; protec:ng secrets limits disclosure to a
very few people
5
Why we need a vendor-interaction model*
• Enable and support effec9ve co-‐design of hardware, science applica9ons, and the system soMware stack
• Fully protect vendor IP • Establish processes for jointly developed IP • Help guide alloca9on of app and vendor resources • Reduce complexity by serving as a template for mul9ple projects
* Robert Harrison created the original slide deck on this topic, which we discussed with vendors at SC10
6
Some things to consider
• Exascale co-‐design app projects are not legal en99es – NDA agreements are made with ins:tu:ons
– Most NDAs are 2-‐way (and the IP operator does NOT commute)
• Our objec9ve is exascale science ASAP – Much of the apps work may be vendor neutral
– Produc:on science codes will be open source, likely GPLn • Vendor-‐specific, non-‐0exclusive license possible
• Most IP usually only needs to be protected for a finite period of 9me
8
! !
!"#$%&''
()*+,-./012,03,41)5,0154)6,23
7,0+)418 7,0+)419
()*+,-./01:;&13,<=18 ()*+,-./01:;&13,<=19
!"'>$# !"'>$#
!"##$%&""'()%*$+*,&-#%."##/%0$#$,012#"#+%.3'(%'.%*$.'"1&-*'$
4&"5678
9-#:#678
;&:#%<778 %=3*,#%<7784&"5%678 %9-#:#%678
9
• Strict firewall between NDA teams – Each “co-‐design NDA team” has separate staff
• Probably at different ins:tu:ons, and • Integrated into corresponding exascale associa:on
– In the figure • Dave and Alice never have access to NDA informa:on
• Mary and Steve do NDA work exclusively with one vendor each, and also contribute to open ac:vi:es
• Many precedents for this model
10
• The leadership team will need to be exposed to some level of NDA informa9on – Nominally not very deep, but enough to
• Create/sense opportuni:es • Plan and allocate resources/staff exper:se • Coordinate with exascale associa:ons
• Excep9ons should be infrequent, but we must expect and enable them – Goal-‐oriented, not process-‐oriented
11
• Informa9on must flow up to inform overall project design and for eventual deployment – No undocumented informa:on flows through filter; only approved
reports/presenta:ons/code (these can be ins:tu:on/associa:on private, *project-‐private, or public)
– Center and vendor define clearance process – A few individuals must span NDA and open parts of the project
• Essen:al for effec:ve and affordable execu:on • Bear special responsibility
* Project private includes those ins:tu:ons with a mul:-‐way NDA with the vendor
top related