Download to read offline
Uploaded bySigasi
EclipseCon Europe 2011
This document discusses using the Xtext framework to build an Eclipse-based integrated development environment (IDE) for digital hardware design using VHDL. It describes implementing a VHDL grammar, scoping, autocompletion, formatting and testing. Key challenges included debugging the declarative scoping approach, improving autocomplete beyond the grammar, customizing formatting, and addressing performance issues for large files. Overall Xtext provided a good starting point but significant custom work was still required to build the IDE.
More Related Content
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
EclipseCon Europe 2011
- 1. Bringing the powerof Eclipse to Digital Hardware designers Hendrik Eeckhaut Mark Christiaens Lieven Lemiengre
- 2. HELLO MY NAMEIS @heeckhau 2
- 3.
- 4. Eclipse • Navigation • Autocomplete • Real-time errors • Quick-assist/fix • Refactoring 4
- 5.
- 6. hardware development toolkit Bringpower of Eclipse to Digital Hardware Designers
- 7. VHDL • 20 yearold language (based on Ada) • all shortcomings of arcane languages • verbose • irregular • ... 7
- 8. 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? 8
- 9.
- 10. Xtext experience Results EMF Guice Eclipse Antlr Xtext Effort 10
- 11. Overview • Grammar • Scoping •UI • Autocomplete • Formatting • Testing • Performance Lessons learnt ? 11
- 12. Grammar • Grammar • Scoping •UI • Autocomplete • Lexer: No problems • Formatting (We had ANTLR grammar to start from) • Testing • Parser: No semantic predicates • Performance • Keep track of the number/size of objects that are created 12
- 13. Scoping • Grammar • Scoping •UI • Autocomplete • Formatting • A lot harder than expected • Testing • Difficult to debug (declarative • Performance approach, lazy evaluation) 13
- 14. 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 • Some scalability issues: Large files are problematic in UI (n 2 problems) 14
- 15. Autocomplete • Grammar • Scoping •UI • Autocomplete based on • Autocomplete grammar/scope is not powerful • Formatting enough • Testing • autocomplete is mostly triggered for incomplete code (incorrect context) • Performance • extended toolkit would be better • Most VHDL autocompletes are manually designed 15
- 16. Formatting • Grammar • Scoping •UI • Needs a lot of customization • Autocomplete • Formatting • A lot cleaner to implement than • Testing what e.g. Emacs does • Performance • Priority of rules not always clear • Custom extension for vertical alignment 16
- 17. Testing • Grammar • Scoping •UI • Autocomplete • Formatting • Xtext itself contains good • Testing starting points • Performance • Dependency injection (Guice) makes it easy to test 17
- 18. Performance • Grammar • Scoping •UI • Autocomplete • Xtext continuously improves • Formatting • Sigasi patches: Parallel loading, • Testing Model Caching • Performance • Memory usage OK 18
- 19. Unresolved Xtext issues ? • Type system • Opening non-project files • Preprocessing 19
- 20. Conclusions • Xtext isreally powerful technology • Gives great architecture/structure • Getting started is easy • But... still a lot of work • Devil is in the details 20