1.
Bringing the power of Eclipse to Digital Hardware designers Hendrik Eeckhaut Mark Christiaens Lieven Lemiengre

2.
2

3.
Eclipse• Navigation• Autocomplete• Real-time errors• Quick-assist/fix• Refactoring 3

4.
• Navigation • Text based• Autocomplete • Syntax books• Real-time errors • Scroll through logs• Quick-assist/fix • Stare at code• Refactoring • Live with ugly code 5

5.
hardware development toolkitBring power of Eclipse to Digital Hardware Designers

6.
VHDL VHSIC (Very High Speed Integrated Circuit) Hardware Description Language• Efficient and robust way to design HW• 20 year old language (based on Ada)• But all shortcomings of arcane languages • lots of noise • limited expressiveness • irregular • most designers use small subset • ... 7

7.
Verbose 8

8.
Irregular syntax 9

9.
Long feedback loops 10

10.
Not everything is negative!• Efficient and robust way to design HW• You can build cool stuff • Custom cpu’s, Mars rovers, ...• A good IDE can resolve most issues 11

11.
Sigasi 1.0• ANTLR-based Eclipse plugin• Proved business value• But: • Lots of prototype code • Type time compilation • Memory usage • Better architecture required 12

12.
Perfect fit for ?• Xtext looks like perfect fit: • navigation • navigation • • type time syntax checking type time syntax checking Grammar • • linting and quick-fixes linting and quick-fixes • formatting • formatting• But: Powerful enough for VHDL? 13

13.
Demo

14.
Xtext experienceResults EMF Guice Eclipse Antlr Xtext Effort 15

15.
Overview• Grammar• Scoping• UI• Autocomplete• Formatting• Testing• Performance Lessons learnt ?• Validation 16

16.
Grammar• Grammar• Scoping• UI• Autocomplete • Lexer: No problems• Formatting (We had ANTLR grammar to start from)• Testing • Parser: No semantic predicates• Performance• Validation • Keep track of the number/size of objects that are created 17

17.
Scoping• Grammar• Scoping• UI• Autocomplete • A lot harder than expected• Formatting • Difficult to debug (declarative• Testing approach, lazy evaluation)• Performance• Validation • Some corner cases continue to pop up 18

18.
User Interface• Grammar• Scoping • Works as expected : outline,• UI preferences, templates, folding,• Autocomplete (syntax and semantic)• Formatting highlighting• Testing • Xtext team keeps adding nice• Performance improvements• Validation • Some scalability issues: Large files are problematic in UI (n 2 problems) 19

19.
Autocomplete• Grammar• Scoping • grammar/scope information is not• UI enough for VHDL autocomplete• Autocomplete • too many suggestions because of• Formatting generic grammar (no type• Testing information, ... )• Performance • strange behavior because of• Validation backtracking parser • Most VHDL autocompletes are manually designed 20

20.
Formatting• Grammar• Scoping• UI • A lot cleaner to implement than• Autocomplete what e.g. Emacs does• Formatting • Priority of rules not always clear• Testing • Custom extension for vertical• Performance alignment• Validation 21

21.
Testing• Grammar• Scoping• UI • Xtext itself contains good• Autocomplete starting points• Formatting• Testing • Dependency injection (Guice)• Performance makes it easy to test• Validation • Most tests can run as simple unit tests (with Eclipse workbench) 22

22.
Performance• Grammar• Scoping• UI • Xtext continuously improves• Autocomplete • Sigasi patches:• Formatting• Testing • Parallel loading (#358714)• Performance • Model Caching (#359824)• Validation • Memory usage OK 23

23.
Validation• Grammar• Scoping• UI • Good framework to add• Autocomplete validation checks• Formatting • Watch out for resource loading• Testing • Custom configurable severities• Performance• Validation 24

24.
Conclusions• Xtext is really powerful technology• Gives great architecture/structure• Getting started is easy• But... still a lot of work• Devil is in the details 25