Embed Size (px)
Citation preview
18th
/19th
February 2020
IBM Research & Development
Böblingen, Germany
You can edit the document (e.g. to insert photos, links, etc.) using your smartphone and the
Google Docs App. → Activate: ‘Drucklayout’ / ‘Print Layout’ for the right layout view.
Otherwise the view on the smartphone appears different to the real document.
Summary on: ‘what is edaBarCamp’ and the ‘Rules of BarCamp’:
Information for the Evening-Event:
Schönbuch Bräu Brauhaus ( http://www.brauhaus-schoenbuch.de )
Lange Str. 20, 71032 Böblingen ( https://goo.gl/maps/JcMkWX6skMwp9ve1A )
Agenda (Tue, 18.02.2020):
Session Wall (Tue, 18.02.2020):
Agenda (Wed, 19.02.2020):
Session Wall (Wed, 19.02.2020):
Lightning Talks
Artificially IntelligEnt EDA (by Georg Gläser)
Please write an E-Mail to Georg Gläser (IMMS) for getting the slides.
Hardware-Software Co-Development and Virtual Platforms for
Custom SoC Design (by Eyck Jentzsch)
Please write an E-Mail to Eyck Jentzsch (MINRES) for getting the slides.
Open Source Hardware - Roadmap or Temporal
(by Jürgen Becker)
Please write an E-mail to Jürgen Becker (KIT) for getting the slides.
Session-Documentation:
1. Verification is Software - How can we treat it like that?
● What is “verification” to participants? - system, chip, subsystem, block, analog, ....
Very different tools and approaches. What commonalities can we extract?
● cocotb as one solution to block level verification
○ Philipp gives an introduction to cocotb.
● The higher the level, the more “legacy” frameworks/simulators/models are available
in-house. How can we integrate all of that?
○ cocotb can be one option for this “glue” layer (but it’s certainly not the only
option)
● Why Python? Will it stay around? (Nobody does Perl any more!) -- it’s a highly
productive language with a large ecosystem. Even if it goes away in the future
(industry moves on!), it’s likely that there will be compatibility layers invented.
● Discussion: UVM is a methodology (and a class framework). For other approaches
like cocotb, do we need a methodology? Can we gain reuse in other ways? What do
people like about UVM? (We didn’t reach a real conclusion here.)
● Question: How can we bring verification and design teams closer together? Is that
even desired? Or in other words: can we make verification code more approachable?
(After all, software engineers write things like unit tests all the time. Why should
hardware devs be scared of verification code?)
cocotb docs: https://cocotb.readthedocs.io/en/latest/
cocotb source code: https://github.com/cocotb/cocotb
Selected slides from Philpp’s presentation:
2. AI and EDA
- it’s hard, we said many things :)
3. AI for Automation of Analog Design
- Historische Intro
- EDA (also Synthese/Entwurf und nicht Verifikation) basierte seit Jahren auf
Optimierungen
- Macht der Abstraktion hat im Digitalentwurf geholfen -- im Analogentwurf
leider nicht
- Entwurfsstrategien im Analogentwurf basieren auf Expertenwissen
- Designproblem lässt sich mit ggf. auf Entscheidungsproblem zurückführen: Welche
Strategie sollte im nächsten Schritt verwendet werden?
⇒ Agent, der Entscheidungen trifft
- Entwurfsraumbeschränkung muss irgendwie eingeführt werden
- Kostenfunktion des Designs muss klar definiert werden
- Methoden, wie man aus dem Entscheidungsbaum Folgerungen trifft
- Ggf. zufällige Erzeugung von Strategien
- Repräsentation des eigentlichen Problems und Defiition des
Optimierungskriteriums
- WIE werden Topologie/Parameter beschrieben
- wie definiert man eine Zielfunktion generisch
- wie mappt man “klassische” Parameter (Verstärkung, CMRR,
Rauschen, …) auf diesen generischen, bewertbaren
Zielfunktionsraum
4. Automatic Debugging using AI - next step in verification?
Where did I get my knowledge and experience with AI
1. Learning the basics
○ background Electrical Engineering, with some experience in python
programming
○ "Machine learning with Python" - bad idea to start with : lots of code and
examples but no idea
○ Coursera : Machine Learning track gave first background and mathematical
foundation
■ practical examples, like the MNIST (number classification) data set
○ Coursera : Deep learning track : Neural networks, Object Detection -
understanding and practical python experience
This enabled me to leave the "we can use AI for everything"-Powerpoint level, to start having
a differentiated discussion about which ML approach or even algorithm could be used.
2. pick a project to get some experience:
Picked an existing project and started to try it on "my work domain data".
Which problem(s) did we (try) to solve
● Clustering fails to find different signature belonging to the same "root cause"
● Identifying duplicate fails // Identifying fails that belong to previously identified issue
(bug)
○ using clustering within the same "bug label" to find outliers
○ Challenges
■ the more classes (bug label) we have the worse it gets
■ ai algorithms are overconfident when identifying a label
■ new fails are wrongly classified as "known"
■ changing data over time
● Linear Regression, Identifying a relation between coverage events and parameter
(values) of a testcase, test bench
Working on Simulation Traces from Logs
- Don’t want to look on the same “Bug” for several times
- Classification
What is the Training Data and How do we collect it
● first we use the data that are generated when our test case regression system
identifies a fail
○ use "fail database" data (simulation error, checker, test case name, model
version etc...)
○ using trace as input for "NLP" similar work
● for "classification" we take advantage of the fact, that verification engineers already
assign "bug numbers" i.e. they do the labeling
○ problem is quality of labeling, typos, ...
Benefit vs overhead
● overhead is mainly the development of the glue code (to parse text files and create
"ML consumable" features)
● overhead is the management of the data
● The training itself is not an actual issue
● Benefit: for some projects the classification worked and helped and gave some
feedback on duplicate fails and outliers. In other projects the classification was
underperforming, i.e. not a help at all
5. AI for System Design
- Wir benötigen ein KI-Interaktionsmodell
- Wir brauchen eine EDA-Roadmap für ML/AI
- edaKI ist kein short term Ansatz
6. Very early HW/SW Performance Evaluation - How to know
today what to build tomorrow?
7. Future of Computing - Bits, Neurons, Qubits
● see slides
8. RISC-V Virtual Prototyping & Verification
Open source RISC-V based Virtual Prototype (VP) developed at the University of
Bremen / DFKI:
Compliance Testing (for RISC-V) is very important but challenging. Promising
approaches to tackle the compliance testing problem include:
- Specification-based test-suite generation (positive testing).
- Fuzzing-based test-suite generation (negative testing).
Visit http://www.systemc-verification-org/riscv-vp for the open-source RISC-V based VP and
more information and most recent updates on the (VP-based) analysis and verification
techniques.
9. VLSI Routing
Presented a simple VLSI Routing flow, consisting of a Global Routing, optimizing
congestion and timing via a Resource Sharing Relaxation solved by a black box
algorithm (see e.g. http://www.or.uni-bonn.de/home/vygen/files/rs.pdf) and a Detailed
Routing uses Successive Path Search, obeys the Design Rules and stays close to
the Global Routing. Discussed if these steps should be interconnected instead of
seperated.
10. Bridge the gap to software - AMS SoC Verification
by Co-Emulation
- Emulation of SoC by synthesis into FPGA
- Simultaneous interaction of Model of FPGA and Software on PYNQ-Z1 board
11. Generalizing scripting Interface for EDA
(Example Skillbridge)
Example Skillbridge Python <-> Skill
unihd-cag/skillbridge: A seamless python to Cadence Virtuoso Skill interface
The problem is several scripting interfaces for different EDA tools. It is mostly tcl in the semi
custom domain but even there are differences (synopsis flavoured tcl). In the Open Source
domain the problem becomes even bigger everyone uses a different interface from simple
config files over complex scripting languages.
openRoad (Research Project Open Source Synthesis Flow ) OpenROAD – Foundations and
Realization of Open and Accessible Design was mentioned which has the same problem
and also tries to solve this.
Which languages to use as standard interface? Maybe Python
Server based Language mapping Python plus:
- widely used a lot people know some python
- package environment is large
- for computing extensive problems its faster
- numeric packages are often accelerated
- easier to debug
Cons:
- For synthesis or routing tools there are alot of exiting scripts in mostly tcl which are
not python.
- For communication extensive problems it is slower
12. Agile for Hardware
13. Concolic Testing
- Software Verification/Testing Technique
- Try to maximize SW path coverage
- Constraint-based descriptions and solvers
- Symbolic : variables are replaced with a “set of possible numbers”. assigned a value
from that range
- aforementioned symbols lead to Symbolic expression
- Path conditions, along with symbolic expression result in constraints
Main Challenges
- State Space : the larger the program, the more instructions, the more constraints to
solve
- Complex constraints: if (a>1) is easy, but Hash functions need “reverse function”
resulting in very hard constraints
- Program interaction with the “environment” (for example interrupts, sensor input)
14. What can embedded system designers learn
from the Z in IBM Z?
- Z = Zero Downtime
- in Bezug auf den Endanwendung
- Kein Single Point of failure
- Redundante Stromversorgung
- Auf welchen Ebenen wird Redundanz verwendet
- von HW (im Chip) bis auf Anwendungsebene
15. Emotions in Design
Can we express emotions in code/design?
● Difficult on the level of “line of code” because we try to stick to different style-guide
rules (indentation, parentheses, etc.)
Flow State: https://en.m.wikipedia.org/wiki/Flow_(psychology)
A State of mind where you are doing a thing which you are good at but also being (slightly)
challenged.
Can we see emotions in code/design?
● We can probably see the emotions the programmer was in because the code is
“good” or ”bad”
● Code itself is unemotional but we can see e.g. beauty in the design of the whole
system
● Can we see the emotions of others in their code?
● Emotions experienced by one person of some piece of code or some design may be
totally different from those that another person experiences
# 3 takeaways from Decoding Programmers: How Emotions Can Change Code,
https://www.informationweek.com/devops/decoding-programmers-how-emotions-can-
change-code/a/d-id/1333265
● Happiness leads to productivity and vice versa
● When people are happy, they may be less critical of their own work. This
means that they focus on writing more code rather than fine-tuning what they
currently have.
● Now, you may be asking: more code sounds good, but it still has to be correct
code. Do positive messages also equal cleaner code? Here, the answer
seems to be no.
● Sadness leads to cleaner code
● While this may sound surprising, it actually reflects a pattern that has been
observed in many fields; sadness or lowered mood often coincides with focus,
improved judgment and critical thinking.
● Anger leads to mistakes
● the least surprising result
16. OpenPower / Open Hardware
Can RISC V suffice for high performance requirements?
Why Open Hardware?
- more companies can nowadays design hardware down to silicon
- (cloud) companies want standards to stay (vendor) independent (and have pricing
competition)
OpenPower MicroWatt Core: a tiny openpower ISA softcore
https://github.com/antonblanchard/microwatt
- flow with open source tools: ghdl, yosys…
- till synthesis for Xilinx
open_core_scalar
- not tiny
- openpower ISA compliant RTL
General Question was the “Usability” , Documentation, how to “use” and build the RTL
- community definitely needs a way to feed back changes
- for example an extension of the ISA
- change in micro architecture (for example reset of a core)
- this applies also for the tools environment (documentations, accessibility, feedback)
- would “cocoTB based” tests in conjunction with IBM’s C++ simulation library be a
valid option?
17. Continuous Testing - What is required
(with real-world example)
As an example for continuous testing, ABIST (array built-in self test) verification automation
from a current IBM processor project was presented.
There, automated test case generation is key to enable short interval testing with huge
numbers of test objects. Test is however not fully continuous, since sim models are not built
automatically.
After a specialized side-discussion among IBM participants, two other examples were
brought up.
- Regression of array PD tools on array macros every weekend to keep track of quality
changes, using Jenkins CI pipeline.
- Regression of routing examples to keep track of router code quality.
Collected requirements and key features of Continuous Testing:
● Machine-readable Spec (not required, if full control on data) ● Continuous Release of Design ● Automatic Test Case Generation, if changing test cases ● Automated Regression Environment ● Use of CI tools (or traditional scripting) recommended ● Keep history ● Backlevel of two runs + and full history on final results
18. EDA for Quantum - Quantum for EDA &
Toolchain for superconducting Circuits
- Intro
- …
- Fixed Delay for cells
- Platzierung über ein Raster mit definierten Verzögerungs Beschränkungen
- Routing über Raster über Verbindungsgraph aus Netzliste
-
19. Machine Learning on Microcontrollers
- Intro
- Different directions: Hardware, Model, Target-aware
- TFLite for Microcontrollers Flow Introduction
- Discussion
20. Event-Feedback
1. In my opinion, edaBarCamp is better for networking (compared to normal
conferences)?
2. I (who) would prefer a complete Hashtag-Introduction of all participants?
3. Shall we continue the concept of our (short) invited 'Lightning Talks'?
4. Who agrees to have some more but even shorter ‘Lightning Talks’?
5. I prefer the time-table creation process to be based on 'interactive session reordering'
or just on 'pre-evaluated-participants'?
