Digital hardware design

Video in TIB AV-Portal: Digital hardware design

Formal Metadata

Digital hardware design
What can we learn from software development – and what not?
Title of Series
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date
Production Year

Content Metadata

Subject Area
Traditionally, the goal of digital hardware design has been to produce anASIC. Ideally one which works perfectly after the first tapeout. Tailoredtowards this goal are our development and testing processes: strictlyfollowing a V-model with separated development and verification teams, longdesign iterations and code which, once it's known to work, is never touchedagain. For people coming from the software world, this development approachlooks arcane. Where are all the sprints, the agile methods, the quickiterations? With FPGAs being on the rise and available in more and more cloud data centersand possibly bundled with our next Intel processor, we finally get the chanceto cheaply make mistakes in digital hardware designs: no more wasted tapeouts,just a new flashing of the FPGA is necessary to fix a bug. Join me in this talk for a look at development processes and tools. Where canwe build bridges between the software and hardware development world, andwhere do we have fundamentally different needs?
Digital electronics Software Observational study Multiplication sign Software Computer hardware Universe (mathematics) Computer Digital electronics Speichermodell
Web page Point (geometry) Implementation INTEGRAL Multiplication sign Software developer Bit Mereology Regular graph Software maintenance Revision control Word Process (computing) Software Internetworking Computer hardware Formal verification Universe (mathematics) Computer hardware Endliche Modelltheorie Speichermodell Probability density function
Dataflow Multiplication sign Real number Software developer Tape drive Voltmeter Bit Limit (category theory) Field programmable gate array Process (computing) Software Iteration Different (Kate Ryan album) Computer hardware Data center Right angle Table (information)
Point (geometry) Dataflow Confidence interval Feedback Multiplication sign Direction (geometry) Source code Field programmable gate array Product (business) Latent heat Goodness of fit Iteration Term (mathematics) Software Formal verification Software testing Software framework Arrow of time Physical system Personal identification number Graph (mathematics) Information Software developer Feedback Field programmable gate array Bit Arithmetic mean Film editing Grand Unified Theory Software Universe (mathematics) Software testing Formal verification Bijection Right angle Resultant
Dataflow Multiplication sign Direction (geometry) Mathematical analysis Field programmable gate array Continuous integration Discrete element method Logic synthesis Product (business) Iteration Computer hardware Analytic continuation Error message Continuous integration Feedback Mathematical analysis Sound effect Field programmable gate array Bit Continuous function Type theory Integrated development environment Personal digital assistant Routing Resultant Speichermodell
Point (geometry) Differential (mechanical device) Virtual machine Logic synthesis Product (business) Usability Revision control Web 2.0 Hardware description language Goodness of fit Programmierstil Computer configuration Different (Kate Ryan album) Intrusion detection system Compilation album Physical system User interface Programming language Standard deviation Keyboard shortcut Projective plane Integrated development environment Software Drill commands Text editor Window Speichermodell Spacetime
Point (geometry) Slide rule Implementation Parsing Computer file Direction (geometry) Multiplication sign Connectivity (graph theory) Range (statistics) Source code 1 (number) Open set Code Logic synthesis Formal language Software bug Programmierstil Different (Kate Ryan album) Computer programming Core dump Implementation Error message Compilation album Physical system Programming language Standard deviation Simulation Axiom of choice Moment (mathematics) Projective plane Bit Complete metric space Formal language Compiler Coding theory Hardware description language Process (computing) Personal digital assistant Network topology Computer programming Physical system Spacetime
Group action Sign (mathematics) Befehlsprozessor Different (Kate Ryan album) Multiplication sign Projective plane Website Bit Open set Mereology Code Asynchronous Transfer Mode
Email Presentation of a group Building Metric system Computer file Open source Disintegration Virtual machine Continuous integration Product (business) Writing Human migration Bit rate Blog Different (Kate Ryan album) Core dump Computer hardware Software testing Physical system Area Execution unit Block (periodic table) Software developer Projective plane Feedback Electronic mailing list Code Statistics Virtual machine Type theory Configuration space Website Metric system Speichermodell
Type theory Digital electronics Software Bridging (networking) Computer hardware Moment (mathematics) System call Software development kit
Addition Digital electronics Direction (geometry) Fitness function Letterpress printing Menu (computing) Bit Open set Computer hardware Core dump Boundary value problem Software framework Speichermodell
so we're ready to go I'm talking about
digital hardware design and for those of you that have been staying here for the previous talk you have not a perfect introduction that kind of leads up to this talk so I'm by when I started at computers I started at software and I've been doing software for a very long time and then just at the end of my studies at university I came to hardware and then when you first have a look at at hardware design you obviously do a kind of a VHDL a very long course at
university and they show you something like that and that's how hardware design kind of looks at at first thing so you have this very strict models or this waterfall floam fall model so you do your requirements specs you have a couple of hundred pages you live in Word or Excel or something like that and then you do your design you have your architects there then you have a couple people there to implementation and that's actually outsourced many times to some cheaper countries because if we seen before kind of writing Verilog and VHDL can be extremely boring and then we have verification so you make sure everything actually works and in the end you have maintenance that's kind of your problem stick with you forever and ever and so this is kind of the very simple version if you're kind of more than one person you usually split that up so you have kind of one part here and then one v like other part where you do this verification engineering kind of in parallel to your regular software development so you start off with a lot of PDFs or Word documents and then you work your way through to the implementation process and this is kind of really done in parallel usually because yeah why we'll see that in a bit so now coming from the from the hardware of software world kind of that's how the
fleshies software development processes look these days you have all those agile methods you have a very short sprints you have very kind of dynamic process that you do know you don't start with a 200 or 500 page PDF and then you don't see each other again for the next couple months and then you meet again to do the final integration so the things looks different actually it is different and also kind of to note in the end we had kind of maintenance at the last point if you look at that and that's just a real random picture I found an Internet there's party at the end so if that's not a good reason to have a look at why those processes are different and what we possibly can take from one of each other so why have been or our hardware
development process is the way they are and they are the way they are and that's what we've seen before making a six is expensive it's really expensive and you want to be first time right so if you do a tape out you want to make sure that it actually works and that actually seems to be funny okay silence that first time right doesn't seem to go together let's see No so the thing is if you're doing a six like stuff that cost you real huge amounts of money to get produced at fabricators there you want to make sure that you're actually your first table is correct because otherwise you have just spent a lot of time and actually even more money on that so that's why we have this this very strict flow thing is we're in a world of FPGAs now more and more and they're coming closer to you when you look at Intel putting them closer to your own process or putting them in data centers for now you don't even have to buy a huge FPGA volt anymore you can just rent them by the hour at Amazon or Microsoft so this makes kind of this kind of hardware developed and much more accessible and so the question I'll have a look at here is can we treat hardware development that actually targets a six or reprogrammable software a bit more like software design so we
have a look at three things and the probably formulated a bit to upset people so first thing is be less confident in the quality you get second is iterate iterate and iterate again and third is we should have a look at where we can actually make a difference in the things we do first of all yeah don't
worry be happy if you look at this very gut feeling graph which is showing up here but not there yeah so this is
source gut feeling but it's actually more or less right from experience so if you do a bit of testing you say okay yeah it's compiles it's probably gonna work then you do a bit of testing and at some point in time you're pretty confident that things work out the thing is if you have a software you just run it and if it reasonably performs reasonably well you say okay let's ship that to our future customers or the paying customers who cares they're just gonna come back to us but the thing is if you want to produce an ASIC that cost you a couple million you want to be really really sure that you're actually delivering a good quality product so if you're doing software development you're you you can't be okay with less confidence in your quality don't meaning you intentionally ship crap you just are not sure that you're not shipping crap so why can't we do that cut FPGAs speaking in a kind of a sea terms enables you cheap Rhys pins you can't just reprogram reflash your FPGA and that's about all you need to invest there so you don't need to be first-time right you can't go with this 80/20 approach so okay the question that comes up and that kind of makes this approach still a bit harder or big yep more difficult to execute at the what does a testing approach for an pur FPGA targeting system look like so if you google around and if you have a look at the standard tutorials either they leave our testing completely just as we've been seeing before and that's actually not just here it's also at university courses we talk a lot about design but not that much about testing and verification so how do you do actually verification and testing for an FPGA targeting things so there is not that much information out there yet so this is a place where we need to get a bit more active where we kind of also publish our best practices because I'm sure in this room there is many people that actually have experience doing that and there's actually some software tools that help with that but there is not that much knowledge about that so this is something we should change just to mention one simple example there's for example cocoa TB which is a test bench kind of generating framework written in Python which is more actually targeted at FPGA designs gives you a very nice productivity that's one example that people should know more about so but this 80/20 approach kind of is the prerequisite require thing that you need to have if you want to go more to a software like development flow and if you look at software development flows they work and they have been kind of moving in this direction this agile direction because you want to iterate you want to be very fast in your 12 sand arrows you don't want to start with one specification but you want to go in small steps and actually if you look at kind of learning and how learning works you're much more productive if you get very fast feedback imagine if you at university or been at school somewhere if you have been writing a test and just get the results back after three months you're not going to learn that much about it from it as if you're kind of one-to-one with instructure and you get immediate feedback so the sooner you get feedback the more value you have and the more you learn that's why care of software development is more fun for people usually because you see quicker results yeah
then having a look at hardware and we say ok let's go with this very nice iterative flow and actually I've seen that in Brussels on Friday everybody who has been using a synthesis tool Flo knows kind of the main time you spend actually design is waiting for the synthesis to finish it's kind of not uncommon at all for have a centers for larger fpga to take an hour two or three and if you get a feedback that you did actually a syntax error just after an hour it's just annoying as hell
so FPGAs give us cheap iterations but don't yet give us fast iterations and as we said that's what we want for productivity so I've seen a couple cigars you guys around there they are I think they're heading in this direction so intelligence idea is so we want to get feedback as soon as we can meaning if you type you want to get feedback if you want to do if you do a bit more static analysis linting that's all stuff that can be done at much earlier stages you don't need a full place in route and synthesis for that in most cases and IGI des that we can get today most of them are still stuck in the 80s I think and they don't usually give us feedback they just have some syntax highlighting and actually are able to call with one button some some IDE some synthesis tool and we also need more automation and every large company also in hardware design of course uses continuous integration continuous delivery is I think for them pretty far off but anyways the nice thing about continuous integration and I'll give you a hint oh that looks a bit in the future a nice side effect you also get reduced results and that's always a good thing
talking about IDs I just installed the 2016 dot one version of an IDE from Mentor Graphics it's called HDL editor or HDL designer and well your user interface usually always looks like tickle and crap but you're just gonna get over that if you do hardware design which is fine as you as long as it's usable and then it asked me this very nice questions do you want to setup version control and said yes that's what I want and they gave me kind of those options as I said this is the 2016 dot one version of this product it's kind of not yeah the user interface does look like it the software is like that so there is much more effort needed in this regard last point differentiate where it
matters most if we look at software we see a lot of standardization we see build tools being standardized how many different compilers are using these days you probably use either GCC LLVM or if you're targeting Windows you may be using Microsoft Visual Studio but that's about it for compilers that we usually care about if you look at hardware designs how many synthesis tools do you know of how many different front ends that just parse your language in different subtly different ways so the question is can we actually find common ground somewhere and actually differentiate where we can make a difference and I found this very nice picture of a keyboard that was kind of modified to I think a CNC drilling machine but it's still standing keyboard anyways good so question is what does make your HDL project better is it really the build system is it the way you include your dependencies or if you get dependencies from from the web somewhere the way how you include those is it really that much your programming language especially if you want to have people contribute to it is it your coding style does it make that much of a difference if you indent by three or four or five spaces oh yes I see
is it your faithful implementation that makes a difference in your whole project maybe it is there is some cases where all that makes a huge difference but the point is in many projects it just gets in your way you want to do some coding you want to build your stuff and you want to do it in a language which is reasonably saying to use so this is all questions that I obviously don't have an easy answer with and it's kind of always hard to get over personal kind of preferences which I have very strong ones about many things but what you see if we work together it's not that important anymore if you end up by three or four spaces just make it consistent in some way and that's actually what we see with a lot of newer programming languages if you look at for example rusts or Python or very modern PHP or so they have kind of a standard coding style by now which you're obviously not required to follow but as I kind of just take that one and you gotta be reasonably fine or for build systems and just use auto make or C make and you gonna be reasonably well off it's probably not gonna be the perfect solution that's gonna be the solution that makes you entirely happy but it gets the job done and gets the job done quickly so for HDL there is no such build system out there at the moment which is kind of established over a wide range of people the stack or make or C make are there are a couple of temps in this direction one I am personally a tiny bit involved one is slides that don't move okay is a
few stock which is project by all of Kent grant and this is actually kind of a build system so you specify some some any like files so this is the VHDL or Verilog files I need for this component that's the dependencies that has and essentially packages all up together builds the dependency tree and puts that out into project files that we borrow or simplify or other tools can actually make use of nice thing about that now you want to drop in your other five full implementation you just say okay take this core put it in there and it already knows how to build it actually because what you do today is you go to for example open course download some very log file put them in there manually put them in your Vivaro or other kind of project files and make sharing very hard speak a common language is probably more yeah tricky system very lock in VHDL are here they're probably here to stay there will be amended by some other tools but I don't think they will go away so and that's I think it usually compare it a bit to like see in the programming world it's not a nice language it has a lot of flaws but it will stay and we'll stay for foreseeable future and actually the huge benefit those standard languages have is you have a lot of common ground with others it makes it easy for others to get started because you don't need to learn something new a complete new programming language to get started on a project so kind of the the trade-off you have to make is how many people do I want to get involved versus is it really making me that more productive to use another language and something I've been coming across writing JavaScript is they have this very nice feature also have this arcane JavaScript language which everybody says is full of bugs and flaws and weird things but they still are able to evolve it they not replacing it iterally and they evolved it in a way that is kind of backward compatible so they do is actually a source to source compilation of the newer features and get them down through all the features that's what I call polyfills and that's for HTML as well so is there something that we can do so for example sister Verilog has nice features but if you look at at the tool support it's just not there because every tool has a lot of different parses for system error look just like Vivaro has two different parses that parse this to very look so you can use one construct that works in simulation but not in synthesis that's just annoying and this won't get any better any time soon so can we have a kind of source-to-source compiler that says we go to the common denominator and go from there
yeah that's where the kind of the advertisement part starts right now and I mentioned it a bit before you get your course usually from places like open course and open course is there because it helps you collaborate it helps you find other projects that integrate them in your own to make a difference where you can make the most of your time so
open course unfortunately is kind of in hibernation mode and there is actually no signs that this will change unfortunately so a group of people that were rather active with open course and around the open risk community that published their open risk a CPU there got together and said this is something we need to change and we need to change this and we can't unfortunately change open course itself so we launched Liberty course which is a site with just a similar target so giving you access to very nice IP course making you aware of the quality they are and teaching you a bit how to do coding and how to get started in this ecosystem and it's online now it
works it's still in its early stages so there is a couple things that we want to improve it a future so what we always get is I have noticed this project listing of ten five posts which one should I use which one is high quality which one do others tell me is actually useful so we're looking at improving or adding more quality metrics to the site and those can be machine generated of course but they also can be used at any rate that would be like reviews and things like that and one side I think that got that pretty right is a other repository site from a totally different area it's puppet Forge and what they have is make it easy for you to say okay I used this stuff in production and other things like that to get very useful but kind of quick feedback from users so that's what we're trying to integrate and the other thing is if you ever have worked with nodejs or modern PHP with a composer or other things like that it's very easy to install dependencies you don't need to go some site copy a zip file and move them somewhere you just type one command line at one thing to your configuration file and be done so we're looking if we can have a look at using this repository site and integrate them into build systems like fuse suck and there's one thing I just briefly mentioned that I won't go into much detail there is also a continuous integration set up much like Travis's so we currently kind of be trying out things in this regard if you don't want to know more there is actually a site here and there's also presentation linked from one of the Jenkins core developers that got involved in that and kind of is helping us out there to make testing and compiling hardware designs in the cloud or on your own PC much more easy so what
things to do for now add your project to liberal course itself you can do it right now if you have one there is planet Libre course which is a block planet gives you already very nice overview of some hardware projects that are out there so if you have your own block that you want to be listed there let me know and finally the last one there is documentation how to get started working on the liberal core site itself it's open source it's hosted a get up and we're always welcome for new
contributors last announcement this fall stem is usually kind of settled software and we see the hardware interest grows just by how packed this room is there is
work call of 2017 this was a rather small conference that we have been growing now - alright over a hundred people now the next edition will be at hapten bridge in the UK somewhere in the middle where have never been September 8 to 10 or confident or kits especially about digital hardware design and it's a very good place to get talk to people and get very helpful insights on what the hardware community is doing at the moment thanks for your turns and type of
questions at least a bit so do I have an answer for the licensing question and a licensing question essentially is we know that permissive licenses work so that's why we have a lot of MIT usually licensed cores around we also know that copyleft licenses are still written in a way that is not entirely clear what they mean to hardware designs I don't have an answer to that I've been talking to many people and we add at 44 - that actually runs Libra cores have been in contact with many people and we're trying to figure this out so if you already have an idea in this direction come talk to me essentially what things are looking like so gplv3 was written with hardware kind of in their mind it's not clear of that actually what they intended it to be is actually working out so let's see so but we definitely see a need for a copyleft license but the problem is how do you find boundaries of a copyleft license in a hardware design and until that's figured out I think the safest way stay permissive if you want to people to make sure that they're able to use it everything else you need to probably amend the license or make explicitly clear in your licensing what you mean where your copyleft should have a boundary okay yes there is the CERN open hardware license the thing is digital hardware designs and I think we might have a couple more additions to that chip designs are a bit special because there are kind of special from the legal framework that you can use which is different from PCB designs or 3d prints and things like that so there is some overlap in this certain open hardware license with unlicensed that would work perfectly fine for digital hardware designs it's not a perfect fit yet so we're looking how to kind of get this figured out [Applause]


  479 ms - page object


AV-Portal 3.20.2 (36f6df173ce4850b467c9cb7af359cf1cdaed247)