tag:blogger.com,1999:blog-90569504711876899452024-03-12T16:45:40.330-07:00Tales from Beyond the Register MapGoings-on in the FuseSoC project and other Open Source Silicon related newsOlof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.comBlogger37125tag:blogger.com,1999:blog-9056950471187689945.post-62759108789509172622024-01-10T14:18:00.000-08:002024-01-10T14:18:44.713-08:00How to get more value from open source projects<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgUs7U9-4eVqlf5qeGYGJ_4zLq0i5ibbaJ1NJDrs2SbtmN-hX7NN3totEqSBmgRbU_o4iCaVoW6WxBxiTkHCcJinF1AMxsa3opXu-vVDThYtaUBsJp9kqRhWYz7WFQHhAsDLB4jJxECDNmG0INRBnsccpJqAZnSQpDuCwLD0zcJGsdE5PxGwjMOonDVlg/s961/money.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="516" data-original-width="961" height="215" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgUs7U9-4eVqlf5qeGYGJ_4zLq0i5ibbaJ1NJDrs2SbtmN-hX7NN3totEqSBmgRbU_o4iCaVoW6WxBxiTkHCcJinF1AMxsa3opXu-vVDThYtaUBsJp9kqRhWYz7WFQHhAsDLB4jJxECDNmG0INRBnsccpJqAZnSQpDuCwLD0zcJGsdE5PxGwjMOonDVlg/w400-h215/money.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">What's the missing puzzle piece that improves the open source projects
used in the services or products you deliver to customers to bring you
profit? Read on to find out</td></tr></tbody></table><br /><p>Over the years I have created some open source projects. In fact, I have created <b>a lot</b> of open source projects. Some of them are seeing very little real-world use but many of them are used by hobbyists and academic institutions and powering companies of all sizes.</p><p>Altogether with all these projects I get a lot of bug reports, suggestions, feature requests, questions and so on. In fact, I get a lot more than I could possibly handle. This naturally means that some of them receive less attention, which can of course be very frustrating. But there is actually one simple thing you could do and I would like to offer this one solid advice on how to get my attention for your particular concern. Are you ready? It's actually quite easy. Ok, here it comes. Pay for it!</p><p> </p><p>Now I can hear annoyed mumbling from some of you (*mumble* *mumble* paying?!? *mumble* *open source* *mumble* *mumble* should be free! *mumble* *mumble*) and I also think there's a lot of you who think this is pretty obvious.</p><p>The reason why I'm being very explicit about this is not that I'm angry or disappointed with someone or desperate for money, but over the years I have come to understand that a surprisingly large amount of people and companies just never have thought about this possibility. So I think it's good to make a very simple distinction here. The code is free. My time certainly is not.</p><p><br /> <table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL_J_u7aUYWigsQ4yia8pwXkGfO_-2QUCvfEt-YjnpVikz3Tfvu1ZrjWcIwVZQ-ljd_LmgDTDaVuly_4lbGULfd1e2n4FoYhEf7uhHiTPaiyTgEE7DKco0-wlnwE95Nd4bv9LQ-_5DfCTGLKqJ9pGf0UgR-y8Xm_j7cbazWPvuaaBi5DeOXBDhhOg8Sb0/s961/money2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="516" data-original-width="961" height="215" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL_J_u7aUYWigsQ4yia8pwXkGfO_-2QUCvfEt-YjnpVikz3Tfvu1ZrjWcIwVZQ-ljd_LmgDTDaVuly_4lbGULfd1e2n4FoYhEf7uhHiTPaiyTgEE7DKco0-wlnwE95Nd4bv9LQ-_5DfCTGLKqJ9pGf0UgR-y8Xm_j7cbazWPvuaaBi5DeOXBDhhOg8Sb0/w400-h215/money2.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">That's right. The missing puzzle piece is money. You probably shouldn't pay me to do graphical design though.</td></tr></tbody></table><br /></p><p>Now don't get me wrong. I'm not threatening to kill an open source project every hour until I get a million in unmarked bills and a fueled airplane waiting for me. In fact, I will work on these projects regardless, because I want them to be useful for myself and others, and I really appreciate all bug reports and questions being sent, but if the choice is between getting paid to work on some feature or do it on my spare time, then it's a pretty easy choice to be made. And this is happening already today. I have happy customers who are paying me and my colleagues to work on some of these projects. </p><p>And conversely, when I'm working on some project that could benefit from support or a feature addition in an external open source project, I try to enlist the leader of that project when I have the chance. I find it tends to be great value for the money being able to get support from someone who knows every nook and cranny of a particular piece of software and can implement or suggest and desired changes. In fact, it's not just me saying this. <a href="https://digital-strategy.ec.europa.eu/en/library/study-about-impact-open-source-software-and-hardware-technological-independence-competitiveness-and">A large-scale EU study</a> released in 2021 concluded that the benefit-cost ratio of investing in open source software was above 4, so I say that's a pretty good way to spend your money.<br /></p><p>So how does this work in practice? Well, just like any other contract work really. We define the scope, probably sign some NDAs, agree on a fixed price or a T&M setup, shake hands and get to work. Does the finished work product need to be open sourced as well? That's up to you as the customer. For any code that is generally useful, I would typically recommend integrating it back to the open source project where it came from because that saves you from being the only maintainer of that piece of code. But there might also be code that is closely tied to your proprietary work and in that case it's likely best that you keep it to yourself. Most often it's a mix of both and relatively straight-forward to decide what goes where.</p><p>And it really doesn't just have to be programming. Most of my projects work perfectly fine as they are, but perhaps you need some training to learn how to use them most efficiently, and I'm happy to supply that as well.<br /></p><p>So, this one was a bit shorter than my typically long-winded posts, but I wanted to keep it short and snazzy because time is money, you know.<br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com4tag:blogger.com,1999:blog-9056950471187689945.post-49810349510157429082023-10-23T15:29:00.000-07:002023-10-23T15:29:37.423-07:00Five years of SERVing<p>Making your own RISC-V CPU is a terrible idea. I have said that many times before. There are already a million RISC-V cores out there to choose from, so making another one makes no sense at all. It's kind of the same thing with UARTs. There are probably as many UART cores written as there are people using one. In my opinion, it's much more important to learn how to reuse and contribute to existing cores than making your own. I remember musing at ORConf one year that I was probably one of the only people in the room who hadn't built their own UART or RISC-V core. Although... I actually made a UART a couple of years ago. But only because I had to see if I could make a <a href="https://twitter.com/OlofKindgren/status/1409634477135982598">UART that fit inside a tweet</a>. And you know what's worse? I actually made a RISC-V CPU as well. In fact, the world's smallest RISC-V CPU. But I never intended to. So how did it all happen? Well, on this day five years ago, I made the first commit to the CPU that would eventually be SERV. But to see how it really started we need to go back in time one more month to September 21 2018, just before teatime.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9jC_58zrkeQMITW5LHth2A8S677LgiSfScOEA-46WfUOJDtGd2fUsJt6h4SbmPzAqUY1lWshsCz3LNSrCf5uYOWGairYDY6tNs36-fTb2GCoxI1ALKFdRZmM0Guf2zG08XX3e4Z3UZLik3jmIHBXTV-8Vl1haRAmF-J6VkmnTDZLAMmeenH7-1aCpUgk/s1350/birthdayserv.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="500" data-original-width="1350" height="238" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9jC_58zrkeQMITW5LHth2A8S677LgiSfScOEA-46WfUOJDtGd2fUsJt6h4SbmPzAqUY1lWshsCz3LNSrCf5uYOWGairYDY6tNs36-fTb2GCoxI1ALKFdRZmM0Guf2zG08XX3e4Z3UZLik3jmIHBXTV-8Vl1haRAmF-J6VkmnTDZLAMmeenH7-1aCpUgk/w640-h238/birthdayserv.png" width="640" /></a></div><p></p><p>In Gdansk, Poland, we were organizing ORConf. As usual there were a lot of great presentations covering a wide array of topics. One of those was a <a href="https://drive.google.com/open?id=1mRc7kG9vcrCM6yB7z3aGlLEFGMYnqGJi">lightning talk by Michael Gielda of Antmicro</a>. RISC-V Foundation, as it was known by then before the formation of RISC-V International, together with Google, Antmicro and MicroSemi had decided to organize a contest. The idea was to let contestants build either the fastest or the smallest RISC-V CPU for a given FPGA board. It had to pass a suite of compliance tests and it had to correctly execute some example programs, including running the Zephyr real-time operating system. The deadline was November 26, meaning just over two months to put together a core together with at least a minimal set of peripheral controllers to create a small SoC, figure out how to run the compliance test suite and port Zephyr to the SoC.<br /></p><p>I remember thinking that this sounded like a lot of fun, but quickly realized there was no way I would ever find the time to do such a thing, so I basically forgot about it for my own part.</p><p>About a month after that, I was at home doing the dishes when I started idly thinking about that processor contest. In particular, I started thinking, what if you do an operation on two 32-bit vectors, but only process one bit each cycle? Then you could theoretically reuse the same circuitry 32 times instead of having 32 separate copies of basically the same thing.</p><p>At this point I had no idea that was called a bit-serial algorithm and was an idea people had already come up with and that was quite widely used in CPUs in the 70s.</p><p>So after finishing up the dishes I had to try out this idea on a piece of paper. It obviously worked for boolean operations such as and, or, xor, but it turned out also to work for additions (and by extension subtractions, which can be described as additions). To convince myself that it actually did work, I made some simple Verilog and ran it through a simulator. And when that worked I got curious about what operations that a RISC-V CPU had to implement so I opened the <a href="https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf">base specification</a> for the first time and started reading. I was so amazed by the simplicity and how well thought-out the whole thing seemed to be. Having read at least a few similar documents before, this really stood out as a piece of art. And also, it got me thinking that maybe, just maybe, it wouldn't be impossible to actually do a CPU. I could at least give it a try and see. Just for fun, you know.<br /></p><p>So on October 23 2018 I pushed a first commit to the newly created SERV repo and suddenly I found myself making a CPU. By this time, half the contest time had already passed which was not an ideal situation, but I did it mostly for fun so it didn't matter too much. The evenings and weekends during the following month was spent doing Karnaugh maps and schematics on
paper while putting the kids to bed and then turning it into verilog.<br /><br />And finally, a few hours before the deadline on November 26, I got the Dining Philosophers Zephyr application running, which was one of the requirements, and that was that. Most of the people involved in the contest were exchanging tips, experiences and metrics on a forum. From the discussions there I knew that SERV had no chance of winning since it wasn't the smallest and definitely not fastest, but it had been a fun experience and I got a new appreciation of the RISC-V ISA, so I was happy regardless. </p><p>About a week later, I woke up to a lot of congratulations on social media. The first RISC-V Summit was ongoing on the other side of the planet and it turned out
I had won an award for SERV after all. Not for being the smallest, and definitely
not for being the fastest, but for being the most creative solution:)</p><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2a2UEIRX984Kvmom2SThif3TicmRUFklKMLsku1sUU7qSZYv5FvSIjBW-b-wqs3sQb0FlOWTx4aCvCYF6tNNNGqA2nWr6uNTO1j06ASd1JFo-iP_CPLHBPMeC63rUM1pc86G9iV6H9xIEIElM90EDxqumOqUJm1VaFGWiWlkyQBUOcrVH0x_6ZDH_ENc/s4032/jangray.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1960" data-original-width="4032" height="311" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2a2UEIRX984Kvmom2SThif3TicmRUFklKMLsku1sUU7qSZYv5FvSIjBW-b-wqs3sQb0FlOWTx4aCvCYF6tNNNGqA2nWr6uNTO1j06ASd1JFo-iP_CPLHBPMeC63rUM1pc86G9iV6H9xIEIElM90EDxqumOqUJm1VaFGWiWlkyQBUOcrVH0x_6ZDH_ENc/w640-h311/jangray.jpg" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">SERV becomes The award-winning SERV<br /></td></tr></tbody></table><br />As the code had been written to meet a one-month deadline, the implementation
was rushed, to say the least. But during the development I had gotten plenty of ideas for further improvements. So free from any time pressure, I continued working at my own pace. During the kids ballet lessons I drew schematics and
instead of bedtime reading I made more Karnaugh maps and SERV steadily
became smaller and smaller.<br /><br />In March 2019 I submitted an proposal to speak at the RISC-V workshop during the Week of Open Source Hardware (WOSH) in Zürich that summer with the first ever presentation of SERV called <i>Bit by bit: How to fit 8 RISC-V cores in a $38 FPGA board</i>. The board in question was the TinyFPGA BX, in case someone is curious.</p><p><br />The presentation was accepted, but it turned out to be a terrible name for a talk. You see, before the end of March I had made some changes to fit 10 cores inside that FPGA. After arriving in Zürich I had that number further increased to 14, and on the day of the presentation I had managed to fit 16 cores into that FPGA, so I had to make some last minute adjustments to the slides. The talk went fine but not great. However, for some unknown reason it has managed to become the <a href="https://award-winning.me/serv-bit-by-bit/">second most viewed video</a> on the RISC-V YouTube channel. I guess this is the closest I'll ever be to become a YouTuber.<br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi90U6LMU6sO1rumfCAiTXEXM3EdkhETZf7xjXPW5bzjFJ7ktejjsA_bK9F_fSksAwZ4M6mLhuWjsL2M9WOjoqGh3jQpHh3W_ykTEbJGEjzxjjIuSqkpmrjO6hgPT0O_uRQ8UyYyQn97QgBqvVIO32pszoipkIZq_V4wtIGAkhporuCLp9alpVOpCSF6Zg/s522/16.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="104" data-original-width="522" height="128" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi90U6LMU6sO1rumfCAiTXEXM3EdkhETZf7xjXPW5bzjFJ7ktejjsA_bK9F_fSksAwZ4M6mLhuWjsL2M9WOjoqGh3jQpHh3W_ykTEbJGEjzxjjIuSqkpmrjO6hgPT0O_uRQ8UyYyQn97QgBqvVIO32pszoipkIZq_V4wtIGAkhporuCLp9alpVOpCSF6Zg/w640-h128/16.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Note to self - never put performance numbers in a presentation title<br /></td></tr></tbody></table><br /><p>Another important milestone that happened just before heading to Zürich was that SERV got its logo.<br /></p><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0VXnGvTIVMnd6iVv-UlDCntr6XC9Dt8a2U_H_XnaQ1IHVLxDCICBjjwKF3RFqoO9W3aXcIJlqUAl-etML5kU3RMdgTtAPrwEun0ue8DNOJdcFobclwyOH-3GhohaLls-m8_7z9KDCRMrvkE9AZkwU85aE3ySTePMku2ObPOJAze9dChoFq4IrEEDIJWA/s1001/serv_logo.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="213" data-original-width="1001" height="136" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0VXnGvTIVMnd6iVv-UlDCntr6XC9Dt8a2U_H_XnaQ1IHVLxDCICBjjwKF3RFqoO9W3aXcIJlqUAl-etML5kU3RMdgTtAPrwEun0ue8DNOJdcFobclwyOH-3GhohaLls-m8_7z9KDCRMrvkE9AZkwU85aE3ySTePMku2ObPOJAze9dChoFq4IrEEDIJWA/w640-h136/serv_logo.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Designed using WaveDrom, the amazing timing diagram (and logo designer) tool. Here's the source for the logo https://wavedrom.com/editor.html?%7Bsignal%3A%5B%7Bwave%3A%270.P...%27%7D%2C%7Bwave%3A%27023450%27%2Cdata%3A%27S%20E%20R%20V%27%7D%5D%7D<br /></td></tr></tbody></table></p><p>In September the same year I learned about another contest, the <i>European FPGA Developer Contest</i>, by Arrow Electronics. In a fit of hubris, I entered that contest too, thinking I had such a great idea that there was a serious chance of winning. The idea was a programmable heterogeneous sensor fusion platform in which you had an FPGA that was connected to a bunch of sensors. Data was collected from each of the sensors and combined into a message stream. The novelty here was to dedicate a SERV core to each sensor. That meant that each CPU could handle the parts of sensor communication that was easiest to do in software, like configuring and handling spi/i2c transactions, while using FPGA fabric to do custom protocols and heavy processing. I called the project <a href="https://github.com/olofk/observer">Observer</a> and released it on Github<br /></p><p> <table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtBclaDMrCgq0L33YvDYLCAQ8IKtaCg-UziuVx_LeQqkuwRVzxvZ9j62vKWlJlRCKBbtiXobCm-3Zkv7qphKypHlmrAYW22xb-meSsKJ5sXzY16Apk-YMkv8sulOufor7Yp0EcK7LqDgrWfUOBY3hcCGsYWKaem4jCLMppbNhcooPAon5IjVXT6TZsOuw/s1600/observer_blocks3.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="900" data-original-width="1600" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtBclaDMrCgq0L33YvDYLCAQ8IKtaCg-UziuVx_LeQqkuwRVzxvZ9j62vKWlJlRCKBbtiXobCm-3Zkv7qphKypHlmrAYW22xb-meSsKJ5sXzY16Apk-YMkv8sulOufor7Yp0EcK7LqDgrWfUOBY3hcCGsYWKaem4jCLMppbNhcooPAon5IjVXT6TZsOuw/w640-h360/observer_blocks3.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">I felt very clever about the naming scheme of Observer. The sensor data came in through a "collector" and then the "base" controlled the data flow. Together those formed a "junction". All data streams then merged and was then sent off-chip through a "common emitter".<br /></td></tr></tbody></table> </p><p>I still think it's not a half-bad idea, but at the same time there isn't a super clear use-case for it and it would require a lot more work than I was willing to put in to get it really usable. Speaking of work, I wanted to have a nice logo for the project, so I asked my very talented fiancée to draw one for me. She didn't have time so instead I made the <a href="https://github.com/olofk/observer/blob/1ff4671e07efee3ef7f3c2e96d44a745df4cafc6/observer.svg">crappiest logo</a> I could come up with in ten minutes, proudly showed it to her saying that it had been released on the internet. The plan worked perfectly. Upon seeing the logo, she felt so embarrassed for me that I soon had a stunningly beautiful logo replacing the old one. The moral of the story: If you do something bad enough, someone will eventually be unable to resist improving it.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhh01axFdL9Xv_M_chtvCLirdaQg1ac7lV5y1G18FHnRG8h8z3TrtWC6Nan1eg7RlrvW2HCZVi21ZvrZqPEr8UlFc9GUwVxAwH1CZQOvW0sqRz7DkuhVaCUvw-LPa2_UdDwFhYpo7hz4S1jKYJg6plOGLRHtl0GqB0D4yVJmIuB0xRXLb93UkY29BfEoH4/s668/obslogo.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="352" data-original-width="668" height="338" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhh01axFdL9Xv_M_chtvCLirdaQg1ac7lV5y1G18FHnRG8h8z3TrtWC6Nan1eg7RlrvW2HCZVi21ZvrZqPEr8UlFc9GUwVxAwH1CZQOvW0sqRz7DkuhVaCUvw-LPa2_UdDwFhYpo7hz4S1jKYJg6plOGLRHtl0GqB0D4yVJmIuB0xRXLb93UkY29BfEoH4/w640-h338/obslogo.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">I have done many ugly things in my life, but the original Observer logo still hurts to look at<br /></td></tr></tbody></table><p></p><p>In the end I didn't win anything, although I did get to keep the very nice cyc1000 FPGA board. I believe some AI something something won, but I'm not sure actually. The other projects were never released anywhere to my knowledge and the whole thing felt slightly shady. And after that, Observer sank down on my list of priorities and has been laying dormant, but it did have one everlasting legacy that became its own, much more well-known project.<br /></p><p>While working on Observer, I used the on-board sensors to have some data sources to combine. There was a button, an accelerometer and...well, that was it. It felt a bit silly to have a sensor fusion system with only two sensors though. The proper thing to do here would had been to solder on a couple of more sensors, but I chose a less work-intensive way, and instead added some SERV cores that just wrote random strings without ever being connected to any sensors. (Remember, kids! Always cheat if you have the option). After adding a couple of more SERV cores generating fake sensor data, I realized that there was still a lot of room left in the FPGA. So I added a couple of more cores and there was still room left. By now I had completely abandoned all pretentions of creating a useful system and just wanted to see how many SERV cores I could stuff into the FPGA. Then, of course, I got curious to see how many cores I could stuff into other FPGAs that I had at hand. Somewhere around this point I realized that this had now become its own project, with the sole intention of finding a metric for how large an FPGA is, by measuring the number of SERV cores they could fit.<br /></p><p>For the first three minutes of existence, the project was called ServMark until I settled in the much catchier CoreScore. I then went to my fiancée again, got an amazing logo and started checking the scores for other boards at my disposal.A couple of days later I registered <a href="https://corescore.store">corescore.store</a>, got some JavaScript help to create a dynamic high score list and started inviting other people to submit their CoreScores. At the time of writing, there are now more than 40 different FPGA boards on the list, with the top entry hitting 10000 cores.</p><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1D95fXftfBOFm8VHNX9O9g6ioN0sMdFlFQYKN9qZ0LMxc5V7AChduusol6n7KZVUMyYgleUILbw6oYKqAxZbpSIXWEzOu1jBqG_QYNBLTIdgsoRm9rvGv-TAq_0yH8yMja03Ic22bqQoWKa83fgh11gWEfJT4XopASKwnI8PQBVD9TpWq8Eee_dcDuFo/s1600/corescore2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="900" data-original-width="1600" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1D95fXftfBOFm8VHNX9O9g6ioN0sMdFlFQYKN9qZ0LMxc5V7AChduusol6n7KZVUMyYgleUILbw6oYKqAxZbpSIXWEzOu1jBqG_QYNBLTIdgsoRm9rvGv-TAq_0yH8yMja03Ic22bqQoWKa83fgh11gWEfJT4XopASKwnI8PQBVD9TpWq8Eee_dcDuFo/w640-h360/corescore2.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">CoreScore with its beautiful logo and the top five entries at the time of writing. Check out the site for the latest results.<br /></td></tr></tbody></table> </p><p>I believe 10000 cores is the highest number of RISC-V cores anyone has put in a chip, at least at the time of writing. Not that they are doing anything useful, but still, I sincerely believe it has a useful purpose. First of all, it gives a rough metric of the relative size between different FPGAs, which normally tends to be an apples-to-oranges comparison thanks to different LUT sizes and available memory blocks. It's not perfect, but provides some guidance, especially to those new to FPGAs. It's also a way to compare the efficiency of FPGA toolchains. With open source alternatives popping up for more devices, it can be interesting to see how well they compare to their proprietary alternatives. For my own part, the prospect of getting higher scores has been a good motivation for further optimizations of SERV, so it has been helpful in that regard too. The rest of 2019 I was working on and off continuing to bring down the size of the core, and by the end of the year there was no doubt that it had surpassed all other RISC-V cores in terms of size, making it <i>The award-winning SERV, the world's smallest RISC-V CPU</i>.<br /></p><p>As we rolled into 2020, there was something in the air that had a big impact on most people's lives, and gathering in large groups at conferences was just out of option. What happened instead was that people took their slideshows into video calls instead at online conferences. I went to one of those in early 2020 and I absolutely hated it. I could see no reason for watching decapitated heads - most of them struggling to handle the lack of audience feedback - reciting slides decks aloud, when I could just as well just read the slides myself or watch a recording where I could skip the boring parts or listen again if something wasn't clear.</p><p>Then, in the spring, I was asked if I could present at one of these virtual conferences. With all the latest advances of SERV I really wanted to present that, so I accepted, but also started thinking if there was a better way to use the new medium than the horrible slide decks I had been subjected to. I decided early to prerecord something. It didn't make sense for the audience to hear me mumbling and losing the thread, when I could just as well edit it to something more coherent beforehand and save everyone's time. I also realized that since everyone would watch it on a computer screen, and not on a projected screen in a badly lit room, I could afford having much finer details in the pictures. And most of all, I could have animations. And sound! So, stylistically inspired by a <a href="https://www.youtube.com/watch?v=HnQMDkUFzh4">1981 video on sorting algorithms</a> we had been forced to watch in school and educational animations from my childhood, I equpped myself with a Korg Monotron for sound effects and a Python animation library to work on creating a fully immersive multimedia edutainment experience about SERV.</p><p>Creating a video like this also meant that it could not only be used for that particular online event, but could also be viewed anytime by people who wanted to get an introduction to SERV.</p><p>On April 29, the resulting video was aired during the <a href="https://www.youtube.com/watch?v=_huTcpAc7sQ">1st Virtual Munich RISC-V Meetup</a>, about 24 minutes in. And for those who prefer just to watch the SERV video without the rest of the talks, it is also available <a href="https://www.award-winning.me/serv-introduction/">here</a>.<br /></p><p>Doing a video was a lot of fun, but there is another common way to make people aware of your work - writing papers. It so happened that my friends at ETH Zürich had just released a paper called <a href="https://arxiv.org/abs/2008.06502">Manticore: A 4096-core RISC-V Chiplet Architecture for Ultra-efficient Floating-point Computing</a>. Now, 4096 cores with area-efficient floating point support is of course impressive, but I thought I could do better in at least one metric, the sheer number of cores. So over 2 days in May 2020 (~15 hours of struggling with Latex and maybe an hour actually writing the thing) I put together the first paper on SERV, <a href="https://github.com/olofk/serv/blob/doc/plenticore.pdf">Plenticore: A 4097-core RISC-V SoClet Architecture for Ultra-inefficient Floating-point Computing</a>. For some reason it was never accepted into any conferences and has been cited approximately zero times, so I guess I will have to wait a bit longer for my academic career to take off.</p><p>At this point, SERV had been implemented in plenty of FPGA projects by myself and other people, but to my knowledge hadn't been taped out. But 2020 also brought the OpenMPW program with free tapeouts for open source projects. Wanting to both add support for the OpenLANE open source ASIC toolchain in <a href="https://github.com/olofk/edalize">Edalize</a> and getting some real SERV chips, I applied for funding through NLNet Foundation to <a href="https://blog.award-winning.me/2021/04/a-first-look-at-edalize-for-asic-flows.html">add Edalize support for OpenLANE and use that to make a small SERV-based SoC</a>. Both objectives were successfully accomplished and thus the <a href="https://github.com/olofk/subservient/">Subservient SoC</a> was born, which is a minimal SoC, just like Servant, but more suitable for ASIC implementations.<br /></p><p>Over the year SERV continued to see more code commits titled <i>optimize this</i> or <i>simplify that</i>, and in addition to working on the core itself, I added documentation and other people got it running on more FPGA boards </p><p>Having so much fun making the first SERV video, as well as <a href="https://www.award-winning.me/edalize-introduction/">one on Edalize</a> (that actually <a href="https://woset-workshop.github.io/WOSET2020.html#best-video">won an award</a>!), I decided to make another one for the 2021 virtual event RISC-V Forum : Embedded Technologies. In that case it was even better to have it prerecorded since it was broadcast around 4 am my time and I don't think I would have given a very good talk at that time of the day. This time I went more for day time TV aestethics and I think it <a href="https://www.award-winning.me/serv-for-a-fistful-of-gates/">turned out pretty nice</a>.</p><p>This video was also the debut of the first major external contribution, with the (optional!) support for the M extension contributed as a Google Summer of Code project.<br /></p><p>At this time, I was still trying out some further optimizations, but it started to get really, really hard to make further improvements to the size. I could spend a week working on an idea for an optimization only to find out it didn't improve anything at all, or even made SERV slightly larger. Generally, only 1 out 10 ideas for optimizations yielded any positive results. There are still some ideas left to try out but they require a bit more time and effort than I have been able to spend. I will mention a few of these later on in the future outlook.</p><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoTHGQxbSWnVdK_8rqLUHAdWOLwUALIt6KRSt-jTpybi-Zj9KUD-TzifOoIjZa-dhmfWawzem7F-nRYqEfpuAIH5YsS9WmNqb8cwd7_rKwWfG1QUclJcRDRw4YhkyxBKylflxzIqKTlyTAP5sILTRrEVG4e1VHo_7vHEyzy_OpzL3kgDLMHRMQUq4j6Xo/s1429/reschart.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="759" data-original-width="1429" height="340" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoTHGQxbSWnVdK_8rqLUHAdWOLwUALIt6KRSt-jTpybi-Zj9KUD-TzifOoIjZa-dhmfWawzem7F-nRYqEfpuAIH5YsS9WmNqb8cwd7_rKwWfG1QUclJcRDRw4YhkyxBKylflxzIqKTlyTAP5sILTRrEVG4e1VHo_7vHEyzy_OpzL3kgDLMHRMQUq4j6Xo/w640-h340/reschart.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The amount of effort trying to further minimize SERV is pretty much the inverse of the resource usage chart<br /></td></tr></tbody></table><br /> </p><p>So the last years have focused more on features. Early in 2022, I added support for <a href="https://github.com/olofk/vidbo">ViDBo</a>, the Virtual Development Board protocol that allows interacting with a simulation of the Servant SoC through an interactive picture of an FPGA board presented in a web browser. It's a pretty fun way to try out SERV if you don't have a real FPGA board. The spring of 2022 also brought (optional!) support for the C extension thanks to another student that I mentored through the <a href="https://mentorship.lfx.linuxfoundation.org/project/45320aba-558a-4660-ab0a-0770f06b856a">LFX Mentorship Program</a>.</p><p>But no matter how small or featureful SERV is, what matters in the end is where it is actually used. As with most of my (and others) open source projects, you typically have no idea about most of the places where it is implemented. People only tend to reach out when they need support (which I'm happy to offer for SERV and my other open source projects, and already do for several clients) but I have learned about some use-cases over the years, such as USB-to-serial converters, DDR2 initialization, GPS synchronization for RADAR and power management. Two of my favorite applications is a cranial implant ASIC and a research project that has taped it out on the PragmatIC FlexIC process, likely making SERV the first RISC-V CPU to be taped out on plastic film. In general, the small size, and hence the simplicity has made it a an attractive choice for taping out on novel processes where yield is not yet maximized.<br /></p><p></p><p>And that pretty much sums up the first five years of SERV. What about the next five years? There are a number of half-finished ideas that I would like to finish up as well a couple of things that I haven't even started. Looking outside the core, I have more or less finished a new framework for CoreScore that will both allow more cores to fit in the same area as well as making routing easier and thereby faster for the P&R tools. As a point of reference, it apparently took around 48 hours to do P&R on the 10000 cores that occupies the number one spot on the list right now. And I would of course like to see both CoreScore and Servant running on more FPGA boards, and that's where you, my dear readers, can help out by making sure it runs on your board and submit a patch to get it added. <br /></p><p>For the core itself, more ISA extensions would be nice. Most of them, like floating point support, doesn't make very much sense, but why not. It would be very cool to run Linux on SERV, and for that we probably need to at least implement the atomic instructions and some more pieces of the privilege spec. More interrupt sources and a debug interface has been requested as well, which makes sense. I also have an almost completed project that uses some nifty math to calculate the smallest decode unit, given some constraints. The plan is to do a proper write-up about that and perhaps even put out another paper.</p><p>But the thing that most people seem excited about is having 2-, 4- and maybe 8-bit versions of SERV. Those would be slightly larger, but also almost 2, 4 or 8 times faster than SERV is today. Preliminary results have shown that the size of wider versions grow less than one might think. There is actually a big reveal coming up in this department soon. If you read this a couple of weeks after I write this, you will already know what it is, but I'm keeping it a secret for now :)<br /></p><p>So, all in all, I'm pretty damn proud of SERV and it has been a lot of fun working on it. It has also managed to attract commercial interest from some of the larger players in the RISC-V space while still remaining very much a passion project for which I can curl up on the couch with a cup of coffee on a Sunday afternoon and think about some optimizations, draw some schematics or Karnaugh maps just like normal people do crosswords.</p><p>Happy fifth Birthday, SERV. As a proud parent, I'm amazed to see how small you have become since you were a baby.<br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-81172406274234209922023-07-14T15:16:00.006-07:002023-07-14T15:18:09.819-07:00Happy 100k!<p>Sure, it's not a million, but then again I'm not Arianna Huffington. Given how extremely niche these topics are and that blogging has been declared dead for about a decade now (about as long as I have been blogging, come to think of it), I think that a hundred thousand visitors is actually really really good. It's sure is a lot more than I would ever had imagined when I started doing this ten years ago.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjASgFGm0xW2lW3nrmjbNvr3-NFTrmkTRcnaomj9IPH0ts-oCndnHlIScUtcRqNwwG9XSgYJc1bAR-mlnTUqx76Mt3V7pKA9lsBDwMslDmH0IoEM_kngXFruFYKSxG881sMuRRcP6WaEfMYCPE5x7fo2Wnej16TXXqxgXc9pCZkQXSwDR5caEVGiduKp_g/s1197/100kcrop.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="300" data-original-width="1197" height="100" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjASgFGm0xW2lW3nrmjbNvr3-NFTrmkTRcnaomj9IPH0ts-oCndnHlIScUtcRqNwwG9XSgYJc1bAR-mlnTUqx76Mt3V7pKA9lsBDwMslDmH0IoEM_kngXFruFYKSxG881sMuRRcP6WaEfMYCPE5x7fo2Wnej16TXXqxgXc9pCZkQXSwDR5caEVGiduKp_g/w400-h100/100kcrop.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The proof! Also notice the massive amount of followers this blog has gathered over the years<br /></td></tr></tbody></table> <p></p><p>I don't remember anymore why I started blogging but I guess I felt that the world deserved to hear my opinions on random things. Also, there wasn't really anyone else writing about the things we were doing with OpenRISC and open source silicon in general at that time. Nowadays, any industry conference and news outlet worth mentioning will have FOSSi content but back then, most people in the industry just didn't get it. (To be fair, most industry people still don't get it given the number of "open source" panels I have seen at conferences consisting of people with zero insights who just sit there making up stuff because their companies have paid to have them there. Thank god for events like ORConf and Latch-Up!).</p><p>Enough about <i>why</i>. I thought it could be fun to look at <i>how</i> instead. There are a number of events that have lead to the magic six figure number. So, let's go back to the beginning. What was supposed to be the <a href="https://blog.award-winning.me/2013/06/initial-begin.html">first article</a> actually became the second article because when I wrote it I went off on a tangent and ended up with a whole article on <a href="https://blog.award-winning.me/2013/05/scope-creep.html">scope creep</a> instead. And I think that pretty much sums up my writing and how I (fail to) get things done in general by starting something and then ending up getting stuck in some detail and end up doing something completely different instead. Not that it really mattered though. The readership consisted mostly of friends who I forced to read the blog and questioned them afterwards to make sure they had read the whole thing. But I kept writing every now and then about different things around the OpenRISC archicecture. And then one day the people in my regular IRC chat channel notified me that my <a href="https://blog.award-winning.me/2014/05/openrisc-health-report-april-2014.html">latest blog post</a> was on the frontpage of <a href="https://hardware.slashdot.org/story/14/05/14/1213239/openrisc-gains-atomic-operations-and-multicore-support">Slashdot</a>! For all you youngsters out there, Slashdot used to be the place where all nerds got their news and if you were featured on the Slashdot frontpage during its heydays you'd better have a server that could handle a massive influx of traffic. There were stories about servers burning up after being "slashdotted" because they were humble machines that never thought they would see so many visitors in their life. Luckily, 2014 was a bit after the heydays of Slashdot and Google hosted the blog so I don't think anyone got particularly worried about overloaded servers. But it did make some difference in numbers for the statistics for this humble blog.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiK3ModTULlPVEh53K0tlkPOjDYFILCcdk66gvD_1oAHEVUZm5B4smVu7-swtIsEnXvEVM_6d-rnPxVbYTHHOEkS-qc_lozwTAUmWz3XIs5BgHu8NxcR-5sxWdlpn2BYZzdi7MJOA_CZI-70EI7McGXDAp7plFoSmOLbWjhnVgZnZ2fgv_SYJ86BHyBnmE/s915/slashdot.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="140" data-original-width="915" height="61" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiK3ModTULlPVEh53K0tlkPOjDYFILCcdk66gvD_1oAHEVUZm5B4smVu7-swtIsEnXvEVM_6d-rnPxVbYTHHOEkS-qc_lozwTAUmWz3XIs5BgHu8NxcR-5sxWdlpn2BYZzdi7MJOA_CZI-70EI7McGXDAp7plFoSmOLbWjhnVgZnZ2fgv_SYJ86BHyBnmE/w400-h61/slashdot.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The Slashdot effect in action<br /></td></tr></tbody></table><br /> <p></p><p>A couple of hours later, the Slashdot crowd moved their attention elsewhere and never came back, as is painfully clear from the statistics. I kept writing now and then however, mostly about <a href="https://blog.award-winning.me/2015/12/fusesoc-and-vunit.html">FuseSoC</a>, <a href="https://blog.award-winning.me/2016/02/fusesoc-14.html">FuseSoC</a> and <a href="https://blog.award-winning.me/2016/08/fusesoc-15.html">FuseSoC</a> which apparently didn't lead to any new front page news. A couple of years later though, I wrote about my <a href="https://blog.award-winning.me/2016/11/ip-xact-good-bad-and-outright-madness.html">complicated love-hate relationship with IP-XACT</a> and that seemed to have struck a chord with some people. This one was more of a sleeper hit that didn't cause any immediate sensations but eventually became my most read, and definitely most cited, article I had written.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUqA9sLYLkR6kUCST0k4dp8s_8auyDIz7krEoF32MIedfITe_46eGxTuBxrlIOeC_S9VEw0Ktsr5iLBHMXXBOIi6c2oaySSqyeEj8ieJ1gyuz4jnZKXleMfT98isZg774u5P3BU-sTWK1yq64Si5PwxDpr0Huir93rUt6u-bD_AnQ-zActlbRaQJDyPoQ/s1174/ipxact.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="376" data-original-width="1174" height="127" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUqA9sLYLkR6kUCST0k4dp8s_8auyDIz7krEoF32MIedfITe_46eGxTuBxrlIOeC_S9VEw0Ktsr5iLBHMXXBOIi6c2oaySSqyeEj8ieJ1gyuz4jnZKXleMfT98isZg774u5P3BU-sTWK1yq64Si5PwxDpr0Huir93rUt6u-bD_AnQ-zActlbRaQJDyPoQ/w400-h127/ipxact.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">IP-Xact - an evergreen of confusing and questionable EDA standards<br /></td></tr></tbody></table><br /><p></p><p>Getting noticed in premier geek media and cited in academic circles have both been happy surprises. There's no getting around that does feel a little more fun writing when you get these kind of validations. So I kept writing to a tiny uptick in readership after the IP-XACT article, again mostly about <a href="https://blog.award-winning.me/2018/02/fusesoc-18.html">FuseSoC</a>, <a href="https://blog.award-winning.me/2018/03/fusesoc-181.html">FuseSoC</a> and <a href="https://blog.award-winning.me/2018/06/fusesoc-182.html">FuseSoC</a>, but after starting way too many FOSSi projects over the years, like <a href="https://blog.award-winning.me/2022/10/serv-little-cpu-that-could.html">SERV</a>, <a href="https://blog.award-winning.me/2021/09/and-out-come-swervolf.html">SweRVolf</a> and <a href="https://blog.award-winning.me/2022/01/edalize-030.html">Edalize</a>, I also <a href="https://blog.award-winning.me/2019/12/2019-year-of-risc-v-and-open-source.html">started</a> <a href="https://blog.award-winning.me/2021/02/fossi-fever-2020.html">doing</a> <a href="https://blog.award-winning.me/2022/02/fossi-explosion-2021.html">yearly</a> <a href="https://blog.award-winning.me/2023/04/fossi-fantasies-2022.html">round-ups</a> partly to remind myself what I did over the past year. And then one evening, after spending a day in a workshop with a clueless EDA vendor trying to shove their awful tooling down our throats, I wrote about one of the FOSSi projects that I believe will have a large impact the coming years, namely <a href="https://blog.award-winning.me/2022/10/its-time-to-to-thank-uvm-and-say-goodbye.html">cocotb and how it will save us from SystemVerilog for verification</a>. And that, my friends, turned out to be of more interest than anything I had previously written about.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJ7CBcJu0YkNwFpzpaijhbWpe9yBQri_UnF6aJLOsnWbRdINTjBeWYq1K8DebpETjEJ04bauQe_-f7PZI7rVIX-ndVOIy9-Gv2oxBKDzyfsngKz1NkMTwGm5P36FrBuWROPHleZe3PJYDQU4m0dmffmxEBqzIRcDy7qelnLmL_60xgq6ZMhGR8OP_DbI8/s1205/top5.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="880" data-original-width="1205" height="293" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJ7CBcJu0YkNwFpzpaijhbWpe9yBQri_UnF6aJLOsnWbRdINTjBeWYq1K8DebpETjEJ04bauQe_-f7PZI7rVIX-ndVOIy9-Gv2oxBKDzyfsngKz1NkMTwGm5P36FrBuWROPHleZe3PJYDQU4m0dmffmxEBqzIRcDy7qelnLmL_60xgq6ZMhGR8OP_DbI8/w400-h293/top5.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Cocotb and Python coming to steal the show, as always<br /></td></tr></tbody></table><br /><p><br /></p><p>Suddenly, the hordes of geeks coming via Slashdot was just a blip on the radar compared to the angry, happy, confused and relieved verification engineers who showed up en masse to state their opinions, tell their stories, show their support or ask what this was all about.<br /></p><p>Not everyone agreed, but it was clear that it was a hot topic. And that's the third thing I'm really happy about, to have ignited discussions around the status quo of chip design and get people to bring their ideas and opinions to the table.</p><p>I really hope to continue writing about stuff when I'm in the mood and can find the time. And hopefully some people find it interesting, at least occasionally. Given the sporadic output of the past, we will never know the next time that happens, so I'll just say until then!<br /></p><p><br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-9326426405925223122023-04-27T14:50:00.006-07:002023-04-27T14:56:10.474-07:00FOSSi Fantasies 2022<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjM4ZfRFLYhqylBLtAP-dHIqBX-xCKz16O-jUvjZBBTqihqWV7ggNvzruuQQhoaf084qVaYxoT0mrLPwp5O3Hyq1shSUBtbAm-B4aruWVyUs6evojPepmCBnpHl6cg-2L6vWPnGjWzA06d8hHRpzgz03ES1sYJL1SCNCrNdEZgWi5lN0gi08W51m3QU/s1600/2022.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="873" data-original-width="1600" height="219" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjM4ZfRFLYhqylBLtAP-dHIqBX-xCKz16O-jUvjZBBTqihqWV7ggNvzruuQQhoaf084qVaYxoT0mrLPwp5O3Hyq1shSUBtbAm-B4aruWVyUs6evojPepmCBnpHl6cg-2L6vWPnGjWzA06d8hHRpzgz03ES1sYJL1SCNCrNdEZgWi5lN0gi08W51m3QU/w400-h219/2022.png" width="400" /></a></div><br /> <p></p><p>2022 is behind us and as usual I'm wrapping up my open source silicon efforts of the past year in a blog post. <br /></p><p>Hang on...a 2022 retrospective...? In... the end of April??<br /></p><p>Yes, I am fully aware that a third of 2023 has already passed, thank you very much, and that it's way too late to write a new year's retrospective. I have just been extremely busy, but I still wanted to get it out of the system. It's only been a month since the Persian new year, so in the light of that I'm not <i>that</i> late. Anyway...</p><p>This
year, the list is shorter than usual simply because I haven't done as much
FOSSi work as previous years. <strike>The upside is that I managed to complete
this article close to new year, rather than much later as in previous
years.</strike><br /><br />But why have I done less work? The main reason is that I
have been terribly busy with my <a href="https://www.qamcom.com/">day job</a> which is mostly of proprietary
nature. While I do a lot of interesting stuff in this capacity, it's
unfortunately not much I can talk about publicly. This is another reason
why I greatly prefer open source work, so that I can show, share ideas
and collaborate with other people.<br /><br />There is one thing however
from my day job that I can and want to talk about. This summer we
launched a fully remote office that we call <a href="https://www.qamcom.com/anywhere/">Qamcom Anywhere</a>. Having
worked remote myself for the past four years I have been pushing to make
it possible for more people in the company to do the same, and this
year we got it going for real. Qamcom Anywhere has been a massive
success and we have found amazing new colleagues in various parts of
Sweden where we previously haven't been looking before. Given my
previous experience with working remote as well as working on open
source projects, which by nature tend to be highly distributed, I was
tasked to run this new office. As part of the campaign we also recorded a
<a href="https://www.youtube.com/watch?v=Jy84MgWsqFE">commercial</a>, so I can now also add movie star to my CV ;)<br /><br />As for
now, we have launched Qamcom Anywhere in Sweden, but hope to spread
to more countries in the future. Stay tuned if you want to be
colleagues!<br /><br />But even outside of this I have found some time to work on my long list of open source silicon projects.<br /><br />Let's
start by looking at what has happened to <a href="https://github.com/olofk/fusesoc">FuseSoC</a> over the past year.
Most of the effort has been spent on getting FuseSoC in shape for a long
overdue 2.0 release. A couple of major features and changes were
identified as being important to complete before this release. Most
notably is the support for the new flow API in Edalize, but a number of
critical bug fixes and backwards-incompatible changes were put in place.
Unfortunately, we never manages to get the 2.0 release out of the door,
but we got close and at least released a first release candidate in late
December, while the final release saw the light in the beginning of this year.<br /><br />Most of my other FOSSi projects made good progress. There were a few new <a href="https://github.com/olofk/edalize">Edalize</a> releases, <a href="https://github.com/chipsalliance/Cores-SweRVolf">SweRVolf</a> got some new board support, a maintenance release to an <a href="https://github.com/freecores/i2c">old i2c component</a> that I maintain (hey! it's important to put some effort into cleaning up old code, not just rewrite new code all the time) and even good old <a href="https://github.com/olofk/ipyxact">ipyxact</a> saw a new release, which now contains ipxact2v, a very handy tool to automatically convert IP-XACT designs to Verilog top-levels. It's not fully complete, but the functionality that exists is already coming to good use in various projects.</p><p>The project that probably saw the most interesting news in 2022 was <a href="https://github.com/olofk/serv">SERV</a>. SERV itself gained support for compressed instructions, thanks to Abdul Wadood
who I had the great pleasure of mentor through Linux Foundation's <a href="https://mentorship.lfx.linuxfoundation.org/project/45320aba-558a-4660-ab0a-0770f06b856a">LFX Mentorship Program</a>. And aside from improvements to the core itself, in 2022, fellow FOSSi superstar developer Florent Kermarrec, who might be most known for Litex, managed to run <a href="https://twitter.com/enjoy_digital/status/1530085417608957952">10000 SERV cores</a> in a Xilinx FPGA. This seems to be the current world record right now for the most RISC-V cores in a single device, but I'm very curious how the competitors will react (looking at you, Intel!).<br /></p><p>This
year was the first in three years where I didn't create any new videos
(or Fully Immersive Multimedia Edutainment Experiences, as I prefer to
call them). Instead I did a number of presentations using old-fashioned
slides for a live audience. The first of them being the RISC-V Week in
Paris in early May where I did both a <a href="https://award-winning.me/fusesoc-rvweek22/">presentation on FuseSoC</a> as well as
one on SERV. The SERV video was unfortunately never published, but the
slides for the presentation called How much score could a CoreScore
score if a CoreScore could score cores? can be found <a href="https://open-src-soc.org/2022-05/media/slides/4th-RISC-V-Meeting-2022-05-04-13h30-Olof-Kindren.pdf">here</a>. I did another FuseSoC talk at FPGA World in Stockholm, Sweden which was also not recorded, but the final one, from the RISC-V Summit in San Jose was. This one was title <a href="https://www.award-winning.me/serv-32-bit-is-the-new-8-bit/">SERV: 32-bit is the new 8-bit</a> and aims to look at how RISC-V can be competitive in the traditional 8-bit market thanks to SERV.</p><p>Both at the RISC-V week as well as the RISC-V Summit I also got the chance to meet with the people behind <a href="https://university.imgtec.com/rvfpga-download-page-en/">RVFPGA</a>, a project I have been involved with almost since the start. For those unaware, RVFPGA is a free computer architecture course by Imagination University Programme that runs on a slightly modified version of SweRVolf that I built a couple of years ago. Right after the RISC-V Summit I also got the chance to watch a RVFPGA workshop in action, and it was super fun to see all these students working their way through the labs.</p>Let's see.... what else then...hmm... you know what? I'm sure other things in 2022 as well, but my memory is fading and May is just outside the door waiting to come in, so let's just cut it here before the rest of the year passes too. Here's to 2023. Happy new year!<br />Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-75875767485798645802023-04-19T01:51:00.006-07:002023-04-19T01:56:20.457-07:00FuseSoC 2.2<div class="separator" style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6-L0ljwyA8xDa7YDqeB2CkC58_5qz5HNulYfgUK7etBgUrD1RnzQMDjrtwRZAeuOG-v_6b-uz78mt9LtYHuW14GnercKGRYPZ35sP10-1k3mn2UmXYiC2irnIWKGCbHVBGY2kP5l5HlkgWBXimHk0V-WKu1Ue-fIhVwifzMgu49U6WbLLNBgyFhDs/s3861/fusesocjson.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="864" data-original-width="3861" height="90" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6-L0ljwyA8xDa7YDqeB2CkC58_5qz5HNulYfgUK7etBgUrD1RnzQMDjrtwRZAeuOG-v_6b-uz78mt9LtYHuW14GnercKGRYPZ35sP10-1k3mn2UmXYiC2irnIWKGCbHVBGY2kP5l5HlkgWBXimHk0V-WKu1Ue-fIhVwifzMgu49U6WbLLNBgyFhDs/w400-h90/fusesocjson.png" width="400" /></a></div><br /><br /></div><br /><p>Do you know the best way to find out who is using your open source software? Introduce bugs! You will suddenly come in touch with a lot of users you didn't know existed. And let's just say I found out about a lot of new users after the release of FuseSoC 2.1. And with FuseSoC 2.1 having a lot of new features, it's perhaps not too surprising that the odd bug crept in.<br /><br />But enough about that, because FuseSoC 2.2, the topic for today, has hopefully fixed what was broken. And of course we have a couple of new features as well, even though the list is somewhat shorter than usual. But let's see what the new version has to offer<br /></p><h3 style="text-align: left;">JSON Schema</h3><p>Generally, I'm pretty happy about the code quality of FuseSoC. It has proven to be relatively friendly to new contributors and has gone through a couple of major refactorings without too much problems over its almost 12 years of existence. But there is one part of the code base that I usually try to stay clear from.<br /></p><p>Deep inside of the FuseSoC code base there is a yaml structure encoded inside a Python string that is parsed when the module is imported to dynamically create a tree of Python classes which are then used to recursively read and validate core description files. Pretty clever, right? This is a fantastic example of the sort of thing that seems great because it's possible and not too hard to actually do with Python. Now, the thing is, because of the cleverness of the code, it is pretty much unreadable even for me who wrote it. Every time I need to fix some bug in this area of the code I end up spending hours trying to figure out how it all works, all the time crying and asking why oh why I built it like this in the first place.<br /></p><p>So what little time was saved on writing some more verbose code, we pay for over and over again in maintenance. Not to mention all the bizarre corner cases that arises because the code is trying to outsmart itself. Things that required us to create classes like this:</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjIrrXyywSAZ6dR-zP6s5rMTQQE-ZNDOMfv4VoIo9qXpUdD4Ko2eNWithDgP4bJA-ZXXhFlUdPzNpHGhsT2XiX52HtNxCCNihoyI27DwnznIxKfR5U3uioHb8B2bbkzdX3ZBgUm3vgpUKj0viNbFfTMElGvd9-2Nbwearzzwws7l7uWSoODb5_hGy4/s301/classany.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="82" data-original-width="301" height="82" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjIrrXyywSAZ6dR-zP6s5rMTQQE-ZNDOMfv4VoIo9qXpUdD4Ko2eNWithDgP4bJA-ZXXhFlUdPzNpHGhsT2XiX52HtNxCCNihoyI27DwnznIxKfR5U3uioHb8B2bbkzdX3ZBgUm3vgpUKj0viNbFfTMElGvd9-2Nbwearzzwws7l7uWSoODb5_hGy4/s1600/classany.png" width="301" /></a></div><p>The time was ripe now to rework this whole thing into something more sensible. So what we do instead now is to have a <a href="https://json-schema.org/">JSON Schema</a> definition of the CAPI2 format...encoded as a string in a Python module deep inside the FuseSoC code base. I understand this doesn't look all that much like an improvement, but it's the first, and most important, step of a journey.</p><p><br />Short-term this leads to a more maintainable parser and validator because we only need to care about the definition. There is battle-proven Python code already that does the actual validation and is better at pointing out where in a core description file there is an error. There are also other utilities for generating documentation to offload this from FuseSoC itself. The parsing is also a bit more consistent now and supports use flag expansion in more places.<br /></p><p>But long-term, this paves the road for actually splitting out the CAPI2 definition to its own project that can be readily reused by other tools without having to use FuseSoC. Having the validation code in jsonschema allows for much easier reimplementations and utilities written in other languages than Python. The first case that comes to mind is JavaScript for having web-based utilities around CAPI2 or built-in validation of core description files in e.g. VS code. But it also makes it easier to implement support for CAPI2 files directly in EDA tools written in Java, C++ or why not Rust.</p><p>It should be noted that the new parser is a bit more strict than the old one, so it might complain on files that were previously deemed ok. Hopefully there shouldn't be too many of those. There's also a new command-line switch <i>--allow-additional-properties</i> that can be turned on to make the parser more relaxed towards elements in the core description files that it doesn't know about.<br /></p><h3 style="text-align: left;">Tags</h3><p>The other thing I want to mention in this release is a small code change that I think will have open up for more use cases. It's now possible to set tags for files or filesets, very much like we can set file_type or logical_name today. FuseSoC itself doesn't care about the tags, but they are passed on to Edalize through the EDAM file. In Edalize, since version 0.5.0 we have begun to look at tags in some of the flows and take decisions upon them. The only tag that is recognized today is the "simulation" tag, that can be set on HDL files to indicate they are intended for simulation and not for synthesis. This change opens up for use-cases such as gate-level simulation where we first send our code through a synthesis tool and then the created netlist is simulated together with a testbench. By marking the testbench files with simulation, we tell the synthesis tools to not try to synthesize them into the netlist but instead pass them on to the simulator untouched. Another future use-case is for TCL files. There might be many tools in a tool flow that parses TCL files and so far, there hasn't been a way to tell the backend for which tool a particular TCL file is intended. I suspect we will see a whole bunch of more use-cases in the future. <br /></p><h3 style="text-align: left;">Other things</h3><p>I mentioned some bugs, right? A big one was that users of the old tool API (which I believe is still most users) noticed that the FPGA image or simulation model was not rebuilt when source files were changed. The new flow API has some properties that allows us to track changes in a much better way and avoids unnecessary rebuilds in many cases. Unfortunately, when these changes were made we didn't properly test how that affected the tool API.</p><p>Another issue was reported from users who uses <i>--no-export</i> together with generators. The recently introduced caching mechanism forced us to rewrite much of the code around generators and unfortunately we ended up missing this case, where the generated code got removed before it was used. Whoops. Also fixed now.</p><p>All in all, I hope you enjoy the new features and the new release. Happy FuseSoCing!<br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-33910008586308690692023-03-24T15:58:00.002-07:002023-03-24T15:58:33.241-07:00Edalize 0.5.0<p>A new version of Edalize has just been released and I'm taking the opportunity to dust off this old blog by writing a bit about some of the highlights.</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZcTj0HlQrgOeovlB30AO2SliIMSc7oJDE8DAKB2oPXa75UM21bl25OLEoxfqzy716DIqxlhvaht7Axq9joLp5oKUYN3Ze3wbE-2K3POQDNjNjujTPhXoqxnm82eir80W-aYq_M3hxjodqSXl621HSFOOyyubQu00uJwch2sAzxPa7xcymPCLhT9Ba/s130/edalize_red.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="121" data-original-width="130" height="372" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZcTj0HlQrgOeovlB30AO2SliIMSc7oJDE8DAKB2oPXa75UM21bl25OLEoxfqzy716DIqxlhvaht7Axq9joLp5oKUYN3Ze3wbE-2K3POQDNjNjujTPhXoqxnm82eir80W-aYq_M3hxjodqSXl621HSFOOyyubQu00uJwch2sAzxPa7xcymPCLhT9Ba/w400-h372/edalize_red.png" width="400" /></a></div>In case someone is wondering, Edalize is an open-source abstraction library for EDA tools that allow users to make a description of their RTL design once in a format called EDAM (EDA Metadata) and then Edalize can setup a project for any of the 40+ supported EDA tools. This allows quickly retargeting a design for different flows and saves users from learning all the intricacies of each of these EDA tools. Edalize does the job for you. This <a href="http://award-winning.me/edalize-introduction/">five minute award-winning introduction video</a> goes into more detail for those who are interested.<p></p><p>Anyway, Edalize 0.5.0 was just released and it contains a whole bunch of new features.</p><h2 style="text-align: left;">New backends</h2><p>Three new backends were added for the legacy tool API. These are called <i>filelist</i> for producing .f files, <i>sandpipersaas</i> for the SandPiper TL-Verilog compiler and <i>openroad</i> for the OpenROAD toolchain. And with this, we now support 40 different EDA tools with the same simple interface. Not bad considering the EDA world is mostly known for its insane level of incompatibilty, vendor lock-in and general user hostility. Still waiting for the EDA vendor to natively support the EDAM format though. That would make Edalize unnecessary and I could spend my time improving the world instead of adding new tool support.<br /><br /><b>Note:</b> With this release, the old tool API is under feature freeze. Only backends currently under review will be considered for addition. No new features of backends will be added outside of that. All future work should be done for the new flow API instead<br /></p><h2 style="text-align: left;">New flows</h2><p>Two flows have been added to the new Flow API. <i>generic</i> is a customizable flow that can be used for all single-tool flows. It is also used internally as a parent class to the <i>sim</i> and <i>lint</i> flows which saves quite a few lines of code.</p><p><br /><i>gls</i> is a gate-level simulation flow that runs a synthesis flow to produce a netlist followed by a simulator. All simulators and synthesis tools covered by the new flow API should be automatically supported. It is also a good way to show off some of the benefits of the new flow API. Doing this with the old tool API would had been terribly complicated.<br /><br /><b>Note:</b> Help is needed to port all the tool classes from the legacy tool API to the new flow API. There is still only a small subset of tools supported.<br /><br /></p><h2 style="text-align: left;">External tool and flow plugins</h2><p>Edalize now supports PEP0420, also known as implicit namespace packages. What does means in practice is that new flows and tools can be added outside of the Edalize code base, so that Edalize users who needs support for some internal proprietary tool or wants to run an esoteric flow can add these without having to modify the Edalize code base. There is documentation that describes how this works in practice.<br /><br /></p><h2 style="text-align: left;">Avoid unnecessary rebuilds</h2><p>A much-requested feature is to avoid rebuilding when the source files haven't changed. This is now possible for most cases using the new flow API. A demonstrator will also soon be released that shows an advanced example of this will soon be released. For most users (at least the ones who have already migrated to the flow API), the only visible change will be that builds will become faster in many cases. <br /></p><h2 style="text-align: left;">Smaller things</h2><p>The <i>modelsim</i> backend supports mfcu mode where all files are compiled into the same compilation unit. <i>icarus</i> supports multiple toplevels. <i>yosys</i> and <i>vivado</i> both support verilog output and recognizes files tagged with the <i>simulation</i> tag. Both these features are used by the gate-level sim flow. The internal flow API has been improved to make creation of new flows easier and have less boilerplate code.</p><p>That's pretty much it. Getting the newest version of edalize should be as easy as running <i>pip install -U edalize</i> (the -U forces an upgrade if you already have an older version installed). Hope you enjoy it!<br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-82455723852015692212022-10-30T18:05:00.005-07:002022-10-30T18:05:53.474-07:00Don't copy that IP<p>Making copies of other people's IP is a terrible thing! And it's a really big problem in the EDA world.</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5g2UhQEv2TBqpyAHF31scbCbsHOHxExdjadig45PwWiyG9KVgTKHkt7AqQsaR-QZQBuGrfHcoaLo9HORDwQzBPNxCdJGJ_wtCPRs_j7LjKuZfQIFCCa_F9cYrHfcF1XkeWzgWKU8ubtwLS_78MgnMgpkVHiMXcOyleB3t82zklEYUqY09vJOB2WKT/s1024/copyip.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="696" data-original-width="1024" height="272" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5g2UhQEv2TBqpyAHF31scbCbsHOHxExdjadig45PwWiyG9KVgTKHkt7AqQsaR-QZQBuGrfHcoaLo9HORDwQzBPNxCdJGJ_wtCPRs_j7LjKuZfQIFCCa_F9cYrHfcF1XkeWzgWKU8ubtwLS_78MgnMgpkVHiMXcOyleB3t82zklEYUqY09vJOB2WKT/w400-h272/copyip.png" width="400" /></a></div> <p></p><p>Oh, I'm not talking about the legal aspects. That's something I happily leave to the lawyers. No, I'm talking about making copies of source code instead of referencing the original code. It's a big problem because suddenly you have two different versions, and the chances that a fix that was done in one version will reach the other version are slim to none. When I was entering the world of open source silicon around 2010, this was how things were normally done. And my first reaction was to try and upstream all fixes to IP cores that I found in various projects that were using those cores. My second reaction was to try and find a more sustainable way to avoid this problem in the first place. And solving this problem was one of the initial driving forces behind FuseSoC, and it still is. So it makes me very very sad when, twelve years later, I still find random copies of IP cores, all with various subsets of fixes applied to them.</p><p>When we started working on the OpenLANE Edalize backend, one important thing was to have as many example designs as possible, both to make sure the backend was flexible enough to cover all use-cases and also to have a good set of examples for anyone interested in adding FuseSoC support for their own cores. We found a number of example designs in the OpenLANE repository which were used to test OpenLANE itself. Great! ...except... it turned out most of the examples were cores or parts of cores copied from various places. So we did what every sensible person (not really) would do. We decided to upstream all those example designs, so that the OpenLANE support and any other fixes would benefit all users of that IP core.</p><h3 style="text-align: left;">Bringing' it all back home<br /></h3><p>At the time we started looking at this, there were 32 different example designs. Our first job was to find out where on earth all these came from. That took a fair amount of detective work, but in the end we found what we believe is the proper upstream for all, except perhaps for one where we are a bit unsure. In that case we chose to file a PR against OpenLANE since that was the closest we could get to an upstream. A few designs were dropped from the OpenLANE examples while we were working on this, in which case we also chose to ignore them.<br /></p><p>Once we had identified the origin, we tried to figure out how they worked and then set off to add FuseSoC support for each and every core. At the minimum we added a target for linting and a target for building with OpenLANE through the Edalize backend. In the cases where we found testbenches, we also added support for running those, with a few exceptions where that required tools we didn't have access to.</p><p>In addition to adding FuseSoC support, we also added support for running the targets as GitHub CI actions, so that every new commit to the project would automatically lint, build a GDS with OpenLANE and potentially run some testbenches.</p><p>And finally we packaged it all up and sent a humongous number of pull requests to different projects with detailed instructions how they could use this. Many of these pull requests have been accepted, but not all. There's not much more we can do about that however. If you are curious, it's possible to check the progress <a href="https://github.com/klasnordmark/openlane-examples/issues/2">here</a> <br /></p><p>So, what does this really mean? Did we make the world a better place for you and for me and the entire human race? I like to think so. At least we didn't make it worse. There are a couple of very real benefits to this work.</p><ul style="text-align: left;"><li>Adding FuseSoC support makes it eaiser for other users to use these cores in their own projects</li><li>Adding testbench targets makes it easy for other people to check the cores work as expected <br /></li><li>Adding a lint target makes it easy to check code quality. Far from all of the designs we encountered pass the lint check</li><li>On a few occasions, fixes had been made in the copies. These were fed upstream to benefit all users of those cores</li><li>The CI actions makes it easy to check nothing breaks on future updates of the cores</li><li>We could test the Edalize OpenLANE backend on a number of different designs to ensure it was flexible enough to handle them all</li><li>We now have a large pool of example designs for anyone interested in doing the same for their cores</li><li>And finally, we have seen that some of the maintainers whose cores we added support for, have started doing the same on their other cores, which is fantastic to see.</li></ul><p>Now, our hope is of course that you too will be bitten by the FuseSoC fever and add support for your cores too so that we can keep growing the ecosystem of FuseSoC-compatible cores, which in turn will help the EDA tool developers improve their tools.</p><p>This work was sponsored by a grant from <a href="https://nlnet.nl/project/Edalize-ASIC/">NLNet Foundation</a><br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-31761221924983040032022-10-30T11:14:00.011-07:002022-11-01T04:11:53.387-07:00From simulation to SoC with FuseSoC and Edalize<p>As you probably also know by now there is a fully open source
ASIC toolchain called <a href="https://github.com/The-OpenROAD-Project/OpenLane">OpenLANE</a> + a <a href="https://github.com/google/skywater-pdk">130nm PDK</a> from SkyWater Foundries together with a program called <a href="https://efabless.com/open_shuttle_program">OpenMPW</a> which allows
anyone to produce ASICs from their open source RTL designs completely for free.</p><p>And regular readers probably also know that <a href="https://nlnet.nl/project/Edalize-ASIC/">NLNet Foundation</a> has kindly sponsored an Edalize backend for this toolchain, so that users can easily run their designs through this toolchain just as they would do with a simulation environment or an FPGA implementation.</p><p>But wouldn't it be great if there also was a good example design to show how this is actually accomplished? And wouldn't it be good if this example design was small enough to quickly run through the tools but still complex enough to showcase several of the features that users might want to use in their own designs. <br /></p><p>Well, what better design could exist than a small SoC based on the award-winning SERV, the world's smallest RISC-V CPU? This tutorial will show we can take an existing building block, in this case SERV, turn it into an ASIC-friendly SoC, run it in simulation, make an FPGA prototype and finally have it manufactured as an ASIC. All using FuseSoC and Edalize to hide most of the differences between these vastly different tool environments. Afterwards, you should be able to use the same process and thinking to turn your own designs into FuseSoC packages that can be used with different tools and easily reused in your own and other people's designs.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEip23QcGrEBcULsUpBjLIG_iBjwiTfllqwlQX8nfAjsx8qnDxTC6bOZY3VKwQbtNdXY4zzIG8F48u2lf3nqqY0E_uD3F3QlX01v82Rc5FqZMFU28WMe5lGbvH_-zPWl0F02fN_ptrYTytUKlsMJUqH2-aq0vIvczu5u8ITqwZLY101yH8eiqu61l8F6/s984/serv_to_asic.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="513" data-original-width="984" height="334" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEip23QcGrEBcULsUpBjLIG_iBjwiTfllqwlQX8nfAjsx8qnDxTC6bOZY3VKwQbtNdXY4zzIG8F48u2lf3nqqY0E_uD3F3QlX01v82Rc5FqZMFU28WMe5lGbvH_-zPWl0F02fN_ptrYTytUKlsMJUqH2-aq0vIvczu5u8ITqwZLY101yH8eiqu61l8F6/w640-h334/serv_to_asic.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">From design to simulation to FPGA to ASIC. FuseSoC+Edalize helps you all the way<br /></td></tr></tbody></table><br /><p><br /></p><p>Let's start by looking at what we can do to make an ASIC-friendly SoC out of our good friend SERV.<br /></p><h2 style="text-align: left;">Creating an ASIC-friendly SoC <br /></h2><p>For FPGA implementations, there is a reference design for SERV called the Servant SoC. That one is unfortunately not so well suited for ASIC implementation for two reasons. The main one being that it relies on the data/instruction memory being preinitialized with an application that we can run, which is not something we can easily support in an ASIC. The other thing is also memory-related. The Servant SoC uses a separate memory for RF and for instruction+data but SERV supports using a a single shared memory for that, which will allow for an even smaller footprint.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjT3Me--aIoGE2v80-IVF8svy-1CAUIhH6UZBHNlv7Ak-u_Z7WgFy5-BowgSzU31C_bVbbOab9rrnuqBXrGszwuF5LDgZuEWuK4EE_pBdMnOpG_4KQK5q8uYewTmzwcrqSeUgauooEdJzYb9KNuZ-oGIEPvKW_2XIfxIfAbR6i3dCbeNMOZut-jCW3I/s385/servant.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="385" data-original-width="360" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjT3Me--aIoGE2v80-IVF8svy-1CAUIhH6UZBHNlv7Ak-u_Z7WgFy5-BowgSzU31C_bVbbOab9rrnuqBXrGszwuF5LDgZuEWuK4EE_pBdMnOpG_4KQK5q8uYewTmzwcrqSeUgauooEdJzYb9KNuZ-oGIEPvKW_2XIfxIfAbR6i3dCbeNMOZut-jCW3I/w374-h400/servant.png" width="374" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Servant SoC - the reference platform for running SERV on FPGA<br /></td></tr></tbody></table><br /><p><br /> </p><p>So with these things taken into consideration, we look at how to design our SoC called Subservient. An obvious inspiration for this is the Serving SoClet which uses this aformentioned shared memory setup. For the subservient SoC however we need to move the actual RAM macro out of the innards of the design so that we can instead connect the RAM and the subservient SoC as hard macros. Related to this we also introduce a debug interface that we can use to write to the memory while SERV is held in reset since we can't rely on preinitialized memory content.<br /></p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmT1YHMpDueFd7RbYok1fpVnthQSuhhjl_BKukbp9VoJtEvf9Qdb-V1CWx8mIEMbd3a-csGKhd7ccMZbfwU-rn8z26E9VIDIx5U8-hc6-ghFLnzSDaIh0Y1p0IruZtuxRWYfSe4i6zjd6HDaTSFziIlLt_BoN0An4WO2Igmvg98jw15DPH1Omcaajj/s483/serving.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="348" data-original-width="483" height="289" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmT1YHMpDueFd7RbYok1fpVnthQSuhhjl_BKukbp9VoJtEvf9Qdb-V1CWx8mIEMbd3a-csGKhd7ccMZbfwU-rn8z26E9VIDIx5U8-hc6-ghFLnzSDaIh0Y1p0IruZtuxRWYfSe4i6zjd6HDaTSFziIlLt_BoN0An4WO2Igmvg98jw15DPH1Omcaajj/w400-h289/serving.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The Serving SoClet. A building block for making tiny SoCs. Just add peripherals.<br /></td></tr></tbody></table> <p></p><p>We can reuse the arbiter and mux from the serving SoClet as is (reuse is good!), but use a slightly modified version of the RAM IF that basically just introduces a Read Enable for the RAM. The debug interface is just a dumb mux that assumes there aren't any memory accesses in flight when the switch is toggled. The RAM interface module that turns the internal 32-bit accesses to 8-bit accesses towards the RAM is the only moderately complex addition, and this is a great thing! It means that we have been able to reuse most of the code and have less untested code to deal with. The resulting architecture looks like this.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpsrOwV7pjwR70dXritNhONEX27_SzGpxzcKVLUgJ5AX1iBv0jJiNN_QLyDP8xXx4SxBKPlOAR9lDJSD5whHk6m-in1-iI4qoyVSjD_tjqihxkyz2o49fRdpGuLP0Da-3eSfNe7KX3zM_8SxqRXiuyjoAw1yhSf9MAazUGWmYoLE_FAp_WiWdAjCfk/s544/subservient_core.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="544" data-original-width="537" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpsrOwV7pjwR70dXritNhONEX27_SzGpxzcKVLUgJ5AX1iBv0jJiNN_QLyDP8xXx4SxBKPlOAR9lDJSD5whHk6m-in1-iI4qoyVSjD_tjqihxkyz2o49fRdpGuLP0Da-3eSfNe7KX3zM_8SxqRXiuyjoAw1yhSf9MAazUGWmYoLE_FAp_WiWdAjCfk/w395-h400/subservient_core.png" width="395" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The core of the Subservient SoC. Made for portable ASIC implementation. Needs RAM, peripherals and a way to initialize the instruction/data memory<br /></td></tr></tbody></table> <p></p><p>The subservient_core exposes a Wishbone interface where we can hook up peripheral devices. Since we want the simplest thing possible, we just terminate the peripheral bus in a 1-bit GPIO controller and make a wrapper. The greyed out blocks are potential future additions.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWfBWlFeCzXTK118tqcRaIVDrmUbGQFua4NKHbSLIoNByoc3pwsRbMUmZKmVNuzULoWS39PLe30MX5UjDTEuRq-6bdX-fj8u--wwQitdiA5Kp5ULTaCbkB9K1CJbD4VsW3U9K9OZsZ5R7fEl9oBt2ndg5ZYMGSZrrL0G_TdoNeZEH37Uof1BovHfL8/s420/subservient.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="420" data-original-width="347" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWfBWlFeCzXTK118tqcRaIVDrmUbGQFua4NKHbSLIoNByoc3pwsRbMUmZKmVNuzULoWS39PLe30MX5UjDTEuRq-6bdX-fj8u--wwQitdiA5Kp5ULTaCbkB9K1CJbD4VsW3U9K9OZsZ5R7fEl9oBt2ndg5ZYMGSZrrL0G_TdoNeZEH37Uof1BovHfL8/w528-h640/subservient.png" width="528" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The simplest I/O configuration for Subservient. Just a single output pin<br /></td></tr></tbody></table><p> And for someone looking at it from the outside, it looks like this.<br /></p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtAQkRtp2sXB3tqqzUNUei7fvdNhCqHoOYcZF6M9usFrgz8dq4bwG84ThZ4xIK5cnp5CrDdIZLyIAP3WGBQdFLFOMxHSq5YB_8XhoCum-IwKNeSmMPBLCSiv__zPGD2qpidU5_e5YMvnUilELBbPP0NfWjYIG7QV1EHLLvHtKchP77YRwUNdEv06e_/s306/subservient_externals.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="220" data-original-width="306" height="288" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtAQkRtp2sXB3tqqzUNUei7fvdNhCqHoOYcZF6M9usFrgz8dq4bwG84ThZ4xIK5cnp5CrDdIZLyIAP3WGBQdFLFOMxHSq5YB_8XhoCum-IwKNeSmMPBLCSiv__zPGD2qpidU5_e5YMvnUilELBbPP0NfWjYIG7QV1EHLLvHtKchP77YRwUNdEv06e_/w400-h288/subservient_externals.png" width="400" /></a></div> <p></p><p>Now that we have a design we want to do some testing. For this, we create a testbench that contains a SoC hooked up to a model of the OpenRAM macro that we intend to use in the SkyWater 130nm OpenMPW tapeout and a UART decoder so that we can use our GPIO as a UART. We also add some hastily written lines of code to read a Verilog hex file and write the contents to memory through the debug interface before releasing the SoC reset. This task would be handled by the Caravel harness in the real OpenMPW setup.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXUr-2fBCMHDbTHFebp10F05DxG-NoNLQ4zKme0C5b0aaFtwfwuxKYgCfS-f6k5F6uLVFdS2G6M51YX1ohgPKGM5pHKGduWImiJKN6NkMWXUfUN68Dw_CFhQADxsRmH8tVzGH4ne7uMVR--wqMy3kvcpc1XE8mKpONc925oAIslYKB8W8vo29-6YZZ/s380/subservient_tb.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="242" data-original-width="380" height="204" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXUr-2fBCMHDbTHFebp10F05DxG-NoNLQ4zKme0C5b0aaFtwfwuxKYgCfS-f6k5F6uLVFdS2G6M51YX1ohgPKGM5pHKGduWImiJKN6NkMWXUfUN68Dw_CFhQADxsRmH8tVzGH4ne7uMVR--wqMy3kvcpc1XE8mKpONc925oAIslYKB8W8vo29-6YZZ/s320/subservient_tb.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Subservient testbench. Starts by loading a program to the simulated RAM through the debug interface and then hand over to SERV to run.<br /></td></tr></tbody></table><p><br /></p><h2 style="text-align: left;">Adding FuseSoC support </h2><p>We are almost ready to run some simulations with FuseSoC. The last thing remaining is just to write the core description file so that FuseSoC knows how to use the core. Once you have a core description file, you will be able to easily use it with almost any EDA tool as we will soon see. Having a core description file is also an excellent way to make it easier for others to use your core, or conversely, pull in other peoples cores in your design.</p><p></p><p>We begin with the CAPI2 boilerplate.
</p><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">CAPI=2:
name : ::subservient:0.1.0
</pre></div>
<p></p><p> </p><p>Next up we create filesets for the RTL. Filesets are logical groups of the files that build up your design. You can have a single fileset for your whole design or a fileset each for your files. The most practical way is often to have a fileset for the core RTL, one for each testbench, and separate ones for files that are specific for implementation on a certain FPGA board etc. This is also what we will do here.<br /></p><p>Filesets is also where you specify dependencies on other cores. In our case, subservient_core instantiates components from the serving core (or package to use the software equivalent of a core) so we add a dependency on serving here. The serving core in turn depends on the serv core. This means we don't have to care about the internals of either serving or SERV. Their respective core description files take care of the details for us. And if some larger project would want to depend on the subservient SoC, the core description file we are about to write will take care of that complexity for them.</p><p>The testbench fileset uses an SRAM model available from a core called sky130_sram_macros and also our trusty testbench utility core, vlog_tb_utils. Finally we add a couple of test programs in Verilog hex format.</p><p></p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">filesets:
core:
files:
- rtl/subservient_rf_ram_if.v
- rtl/subservient_ram.v
- rtl/subservient_debug_switch.v
- rtl/subservient_core.v
file_type : verilogSource
depend : [<span style="color: #996633;">serving</span>]
mem_files:
files:
- sw/blinky.hex : {<span style="color: #996633;">copyto</span> : <span style="color: #996633;">blinky.hex</span>}
- sw/hello.hex : {<span style="color: #996633;">copyto</span> : <span style="color: #996633;">hello.hex</span>}
file_type : user
tb:
files:
- tb/uart_decoder.v
- tb/subservient_tb.v
file_type : verilogSource
depend : [<span style="color: #996633;">sky130_sram_macros</span>, <span style="color: #996633;">vlog_tb_utils</span>]
soc:
files:
- rtl/subservient_gpio.v
- rtl/subservient.v
file_type : verilogSource
</pre></div>
<p></p><p> </p><p>We then define the user-settable parameters to allow us to easily change test program from the command-line, experiment with memory sizes and decide whether the GPIO pin should be treated as a UART or a regular I/O pin.</p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">parameters:
firmware:
datatype : file
description : Preload RAM with a hex file at runtime
paramtype : plusarg
memsize:
datatype : int
default : 1024
description : Memory size in bytes for RAM (default 1kiB)
paramtype : vlogparam
uart_baudrate:
datatype : int
description : Treat gpio output as an UART with the specified baudrate (0 or omitted parameter disables UART decoding)
paramtype : plusarg
</pre></div>
<p><br /></p><p>Finally we bind it all together by creating a simulation target. Targets in the core description files are end products or use-cases of the design. In this case, we define a target so that we can run the design within a testbench in a simulator. The targets is also where we reference the filesets and parameters that were defined earlier. This allows us to use different subsets of the core for different targets. We also throw in a derivative sim_hello target as a shortcut to run the other test program, a default target and a lint target so that we can get quick feedback on any potential design mistakes.</p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">targets:
default:
filesets : [<span style="color: #996633;">soc</span>, <span style="color: #996633;">core</span>]
lint:
default_tool : verilator
filesets : [<span style="color: #996633;">core</span>, <span style="color: #996633;">soc</span>]
tools:
verilator:
mode : lint-only
toplevel : subservient
sim: <span style="color: #997700; font-weight: bold;">&sim</span>
default_tool: icarus
filesets : [<span style="color: #996633;">mem_files</span>, <span style="color: #996633;">core</span>, <span style="color: #996633;">soc</span>, <span style="color: #996633;">tb</span>]
parameters :
- firmware
- memsize
- uart_baudrate
toplevel : subservient_tb
sim_hello:
<<: <span style="color: #996633;">*sim</span>
parameters :
- firmware=hello.hex
- memsize=1024
- uart_baudrate=115200
</pre></div>
<p><br /></p><p>With this in place we can now run</p><p></p><blockquote><span style="font-family: courier;">$ fusesoc run --target=sim_hello subservient</span></blockquote><p>which will run the testbench with the hello.hex program loaded and the GPIO output interpreted as a UART with 115200 baud rate. The output should eventually look something like this.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcXJiYCB_hRmkp4j72Syj9F1_TNp_uULntTz-ZaJBXYvpwlpKK6EKnoxiUgC5AQRxnIMEMbbsoZ7Fz1A9QemqH2U6D3EdMpg__M-JUxHobCn077cin7QfAZXUbxj3IlJd_M53OzJRcuUbYd5UARePWpN2GrgsRoNJ_NcyQzF52ROK2RsXIBqN5Mvez/s1016/subservient_hello_output.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="490" data-original-width="1016" height="309" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcXJiYCB_hRmkp4j72Syj9F1_TNp_uULntTz-ZaJBXYvpwlpKK6EKnoxiUgC5AQRxnIMEMbbsoZ7Fz1A9QemqH2U6D3EdMpg__M-JUxHobCn077cin7QfAZXUbxj3IlJd_M53OzJRcuUbYd5UARePWpN2GrgsRoNJ_NcyQzF52ROK2RsXIBqN5Mvez/w640-h309/subservient_hello_output.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Running our first FuseSoC target on Subservient<br /></td></tr></tbody></table><br />We can run any other program like this, for example the blinky example which toggles the GPIO pin on and off, by supplying the path to a verilog hex file containing a binary<br /><p></p><blockquote><p><span style="font-family: courier;">$ fusesoc run --target=sim subservient --firmware=path/to/subservient/sw/blinky.hex</span></p></blockquote><p> We won't go into detail on how to prepare a Verilog hex file, but there's a Makefile in the subservient sw directory with some rules for to convert an elf to a hex file.</p><p>And as usual, you can list all targets with</p><p></p><blockquote><span style="font-family: courier;">$ fusesoc core show subservient</span></blockquote><p></p><p>and get help about all available options for a specific target by running</p><blockquote><p><span style="font-family: courier;">$ fusesoc run --target=<target> subservient --help</span><br /></p></blockquote><h2 style="text-align: left;">Prototyping on FPGA <br /></h2><p>All right then. Simulations are nice and all, but wouldn't it also be good to have this thing running on a real FPGA as well? Yes, but let's save ourselves a bit of work. In the simulation we could load a file through the debug interface from our testbench. In the ASIC version, that task will be handled by someone else. But to avoid having to implement an external firmware loader in Verilog for the FPGA case, we use the FPGA's capability of initializing the memories during synthesis instead. Remember, always cheat if you have the option!</p><p>What board we want to use does not really matter. We can probably just take any random board we have at hand and add the proper pinout and clocking. I happened to have a Nexys A7 within arm's reach so let's go with that one.</p><p>We put the FPGA-specific clocking in a separate file so that we can easily switch it out if we want to run on a different board. Next up we add an FPGA-compatible SRAM implementation that supports preloading. We can steal most of the logic for the memory and clocking as well as a constraint file from the Servant SoC (Remember, always steal if you have the option!). Finally we add the subservient SoC itself, connect things together and put them in a new FPGA toplevel like this.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNdig1ZyStEJxB8G_fpl01e2JwtpnURhnRK-a6hMcTShMJGO_FlPrmMMqPCvQAIhuYOZozHeKH-yveFHuDrv8C1JpvQN3cv33ggO4ZmuaH5ixEhHqN__2G5eJG3BuYTRVa8c77TaT1CCnBFLRDwtmxuW-oL-2V02HKD1YE9XqTGDWPT2D8yFy9oSz_/s509/subservient_fpga.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="120" data-original-width="509" height="94" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNdig1ZyStEJxB8G_fpl01e2JwtpnURhnRK-a6hMcTShMJGO_FlPrmMMqPCvQAIhuYOZozHeKH-yveFHuDrv8C1JpvQN3cv33ggO4ZmuaH5ixEhHqN__2G5eJG3BuYTRVa8c77TaT1CCnBFLRDwtmxuW-oL-2V02HKD1YE9XqTGDWPT2D8yFy9oSz_/w400-h94/subservient_fpga.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">FPGA-friendly version for quick prototyping of our ASIC-friendly SoC<br /></td></tr></tbody></table><br /><p></p><p>We're now ready to build an FPGA image but it's probably a good idea to run some quick simulations first to check we didn't do anything obviously stupid. All we need for that is a testbench, and since the Subservient FPGA SoC is very similar to the Servant SoC from the outside, we just take the Servant testbench and modify it slightly. We also put in a clock generation module that just forwards the clock and reset signals. With the code in place we add the necessary filesets<br /></p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;"> fpga:
files:
- rtl/subservient_generic_sram.v : {<span style="color: #996633;">file_type</span> : <span style="color: #996633;">verilogSource</span>}
- rtl/subservient_fpga.v : {<span style="color: #996633;">file_type</span> : <span style="color: #996633;">verilogSource</span>}
fpga_tb:
files:
- tb/subservient_fpga_clock_gen_sim.v : {<span style="color: #996633;">file_type</span> : <span style="color: #996633;">verilogSource</span>}
- tb/subservient_fpga_tb.cpp : {<span style="color: #996633;">file_type</span> : <span style="color: #996633;">cppSource</span>}
</pre></div>
<p>and the target for the fpga testbench<br /></p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;"> fpga_tb:
default_tool : verilator
filesets : [<span style="color: #996633;">core</span>, <span style="color: #996633;">soc</span>, <span style="color: #996633;">mem_files</span>, <span style="color: #996633;">fpga</span>, <span style="color: #996633;">fpga_tb</span>]
parameters: [<span style="color: #996633;">firmware</span>, <span style="color: #996633;">uart_baudrate=46080</span>]
tools:
verilator:
verilator_options : [<span style="color: #996633;">-trace</span>]
toplevel: subservient_fpga
</pre></div>
<p>to the core description file. Note that we're using a baud rate of 46080. That's because we define the testbench to run at 40MHz instead of 100MHz (for reasons that will become clear later) and then we must scale down that baud rate to 40% of 115200. Let's give it a shot by running<br /></p><blockquote><p>$ fusesoc run --target=fpga_tb subservient<br /></p></blockquote><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMO-IAaCabxuvIUfDt4zs65HM-boVS7-Tvl0ICrCflIQ9pTSplF6IQNAmXCbAKdObBifuh9uVKxH61ThZIJKA8MGyinNC9tWIDL3JNF8wlG_6lWEekr7OcMqPd0FOwgVqNKLTbNicbe4faIzEt7fHwvi9q75n4dd-NR5JOgExl72erOF_9xi7ur18h/s872/fpga_tb_output.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="519" data-original-width="872" height="381" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMO-IAaCabxuvIUfDt4zs65HM-boVS7-Tvl0ICrCflIQ9pTSplF6IQNAmXCbAKdObBifuh9uVKxH61ThZIJKA8MGyinNC9tWIDL3JNF8wlG_6lWEekr7OcMqPd0FOwgVqNKLTbNicbe4faIzEt7fHwvi9q75n4dd-NR5JOgExl72erOF_9xi7ur18h/w640-h381/fpga_tb_output.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Works in simulation! This increases our confidence in the FPGA implementation<br /></td></tr></tbody></table><br /><p></p><p>Works like a charm. Now we have more confidence when going to FPGA.</p><p>There are a couple of things that differ between our simulation and an actual FPGA target. Instead of a testbench we need to add an FPGA-specific clocking module and a pin constraint file for our board. So let's put them in a new fileset and then create a target referencing these files and telling the EDA tool (Vivado) what FPGA we're targeting.</p><p> </p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">filesets:
...
nexys_a7:
files:
- data/nexys_a7.xdc : {<span style="color: #996633;">file_type</span> : <span style="color: #996633;">xdc</span>}
- rtl/subservient_nexys_a7_clock_gen.v : {<span style="color: #996633;">file_type</span> : <span style="color: #996633;">verilogSource</span>}
targets:
...
nexys_a7:
default_tool: vivado
filesets : [<span style="color: #996633;">core</span>, <span style="color: #996633;">soc</span>, <span style="color: #996633;">mem_files</span>, <span style="color: #996633;">fpga</span>, <span style="color: #996633;">nexys_a7</span>]
parameters: [<span style="color: #996633;">memfile</span>]
tools:
vivado: {<span style="color: #996633;">part</span> : <span style="color: #996633;">xc7a100tcsg324-1</span>}
toplevel: subservient_fpga
</pre></div>
<p> Voilà! Now we can run our FPGA build with</p><blockquote><p>$ fusesoc run --target=nexys_a7 subservient<br /></p></blockquote><p>If everything goes according to plan and we have the board connected, it will be automatically programmed. Using our favorite terminal emulator and setting the correct baud rate should then give us the following output.</p><p></p><div class="separator" style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4BrU971EYoOYA4LXYOzjlT4faBzvdreLBLn6SYZ98AAUVhSGKi2IRN7_14w6Z36KYQY5cD9LpoIkiQyzoqtG1BhbveK3QqvjVnw9heE7T-LXl4prF_2aRPc1_YAujbI7Iq1dlriRMMCI0tY89UTWXMCmpEo3KGo8pe1334msf8vzyVAB_Hp2SWvRU/s1080/fpga_output.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="899" data-original-width="1080" height="533" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4BrU971EYoOYA4LXYOzjlT4faBzvdreLBLn6SYZ98AAUVhSGKi2IRN7_14w6Z36KYQY5cD9LpoIkiQyzoqtG1BhbveK3QqvjVnw9heE7T-LXl4prF_2aRPc1_YAujbI7Iq1dlriRMMCI0tY89UTWXMCmpEo3KGo8pe1334msf8vzyVAB_Hp2SWvRU/w640-h533/fpga_output.png" width="640" /></a></div>Wow! It's just like in the simulation...which is kind of the idea<br /><br /></div>Alright then, simulation and FPGA is all good, but our original idea was to put this in an ASIC. Sooo....how do we do that?<p></p><h2 style="text-align: left;">Making an ASIC target<br /></h2><p>The good news is that we have actually done most of the work already, and this is very much the point of FuseSoC and Edalize. It allows you to quickly retarget your designs for different tools and technologies without having to do a lot of tool-specific setup every time. Now, OpenLANE is a bit special compared to other EDA tool flows so
there will be a couple of extra bumps in the road, but hopefully these
will be smoothed out over time.<br /></p><p>Since we have an Edalize backend for the OpenLANE toolchain already, all we need to to is to add any technology- and tool-specific files and invoke the right backend. OpenLANE can be operated in several different ways, but the way that Edalize integration currently works is by adding TCL files with OpenLANE configuration parameters that will be picked up by OpenLANE and then Edalize assumes it will find an executable called <i>flow.tcl</i> and that a usable PDK is installed and can be found by OpenLANE.<br /></p><p>So on the tool configuration side, all we need to do is to add a TCL file containing the parameters we want to set. And the only things we are strictly required to put into this file is information about the default clock signal and target frequency.</p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">set ::env(CLOCK_PERIOD) "25"
set ::env(CLOCK_PORT) "i_clk"
</pre></div>
<p>There are a million other parameters that can be set as well to control size, density and different routing strategies so I encourage everyone to read the <a href="https://openlane-docs.readthedocs.io/en/rtd-develop/index.html">OpenLANE docs</a> and experiment a bit, but for this time we just add the aforementioned settings to a tcl file and add a fileset and target.</p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">filesets:
...
openlane:
files:
- data/sky130.tcl : {<span style="color: #996633;">file_type</span> : <span style="color: #996633;">tclSource</span>}
targets:
...
sky130:
default_tool: openlane
filesets : [<span style="color: #996633;">core</span>, <span style="color: #996633;">soc</span>, <span style="color: #996633;">openlane</span>]
parameters :
- memsize
toplevel : subservient
</pre></div>
<p>Seriously, it's not harder than that. We're now ready to run OpenLANE and have our GDS file. The thing is, though, that it can be a bit finicky to install the toolchain and the PDK. Building the PDK from sources using the official instructions requires downloading gigabytes of Conda packages, keeping track of a number of git repositories and an somewhat convoluted build process. There are several disjointed attempts at providing a pre-built PDK but at the time of writing there didn't seem to be an agreement on how to do that. Also, the OpenLANE toolchain itself is a bit special in that the recommended way of running it is from a Docker image rather than install it directly. So, with these two facts at hand we decided to simply prepackage a <a href="https://hub.docker.com/u/edalize">Docker image with OpenLANE and a PDK included</a>. This image gets updated from time to time, but in general it's a bit behind the upstream version. But that's totally fine. There's seldom any need for running the absolutely latest versions of everything.</p><h2 style="text-align: left;">Launcher scripts <br /></h2><p>But how then do we run OpenLANE from the Docker image? For that we use another one of Edalize's nifty features, launcher scripts! Normally, Edalize calls the EDA tools it wants to run directly but we can also tell Edalize to use a launcher script. A launcher scripts is a script (or any kind of program, really) that gets called instead of the EDA tools. The launcher script is also passed the original command-line as parameters so that it can make decisions based upon what Edalize intended to originally run.<br /></p><p>In this case, Edalize wants to run <i>flow.tcl -tag subservient -save -save_path . -design .</i> when we invoke the OpenLANE backend but telling Edalize to use a custom launcher that we choose to call <i>el_docker</i>, the command-line instead becomes <i>el_docker flow.tcl -tag subservient -save -save_path . -design .</i><br /><i></i><br /></p><p>If we just want the launcher script to do something special when OpenLANE is launched, then we simply check if the first argument is flow.tcl. In that case we do something special, or otherwise call the original command-line as usual. Simple as that.</p><p>So what special magic do we want to do for OpenLANE? We want to run flow.tcl from our OpenLANE+PDK Docker image and at the same time make our source and build tree available within the image. The whole command in its simplest forms looks something like this when invoked from the Edalize work root</p><blockquote><p>$ docker run -v $(pwd)/..:/src -w /src/$(basename $(pwd)) edalize/openlane-sky130:v0.12 flow.tcl -tag subservient -save -save_path . -design .<br /></p></blockquote><p>We could make this script a bit nicer if we want so that we run as the ordinary user instead of as root, and so on, but this has in fact already been taken care of. The aforementioned <i>el_docker</i> launcher script <a href="https://github.com/olofk/edalize/blob/master/scripts/el_docker">already exists</a> and is installed together with Edalize. And not only does it support running OpenLANE through Docker but also a whole bunch of other tools like verilator, icarus, yosys, nextpnr and so on. So you can just as well use this script for simulation and FPGA purposes if you for some reason don't want to natively install all these EDA tools. The proprietary tools are for obvious reasons not runnable this way since the EDA vendors would probably get very, very angry if we put their precious tools in containers and published them for everyone to be used. Hopefully we can completely avoid proprietary tools some day, but not yet. Anyway, so how do we tell Edalize to use a launcher script? Currently, this is done by setting the EDALIZE_LAUNCHER environment variable before launching FuseSoC (which launches Edalize).</p><p>So, our final command will be:</p><p>$ EDALIZE_LAUNCHER=el_docker fusesoc run --target=sky130 subservient</p><p>And with that, my friends, we have built a GDS file for the Subservient SoC that we can send to the fab and get real chips back. And this we did, but that's for another day. So let's just lean back and take in the beauty of the world's smallest RISC-V SoC, created by open source tools, and think a bit about how incredibly easy it was thanks to FuseSoC and Edalize (and of course NLNet who funded the Subservient SoC and integration of OpenLANE and Edalize).</p><p> And now, it's your turn to do the same with your own designs. Good luck! <br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_i7oebsl1c9oVDx99R8lQ45SDtrfa8TocTYFqOJApmKb_1_tyuRqqbU2_1Y5mM84e_gtKrZMtrb0ucUMsmqG0dW3pPwhaRDThX3rAEeA2ERF5ht0fwuZe5Gi_LEjY8tGU7isVsxOLszdBuFE85yYwF4PEsWT4Dsv1Qi9QCDwG-PzEC_A6H--Q02Wv/s1967/subservient_gds.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1902" data-original-width="1967" height="618" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_i7oebsl1c9oVDx99R8lQ45SDtrfa8TocTYFqOJApmKb_1_tyuRqqbU2_1Y5mM84e_gtKrZMtrb0ucUMsmqG0dW3pPwhaRDThX3rAEeA2ERF5ht0fwuZe5Gi_LEjY8tGU7isVsxOLszdBuFE85yYwF4PEsWT4Dsv1Qi9QCDwG-PzEC_A6H--Q02Wv/w640-h618/subservient_gds.png" width="640" /></a></div><br /><p><br /></p><p><br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-23475777818464768292022-10-14T13:53:00.001-07:002022-10-14T13:53:22.342-07:00SERV: The Little CPU That Could<p></p><p></p><p></p><p>Big things sometimes come in small packages. Version 1.2.0 of the award-winning <a href="https://github.com/olofk/serv">SERV,</a> the
world's smallest RISC-V CPU has been released and it's filled to the brim with new features.<br /></p><p>Historically, focus has always been on size reduction, making it ever smaller, and that has paid off. It's now about half the size of when it was first introduced. But at this point we're not really getting much smaller, and frankly, that's fine. It still is the world's smallest RISC-V CPU by a good margin.</p><p> </p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfrM8klRk8PVMIkLQ14fMuNDGJ8_LiTh3r-8IeOoApso_P95RxmfiB5vimlcP97cpKWozogvN3vNSidFzOTE3vkROlT74RIm8pB9VGg5BNoWNZ3XgZAb1GlvjgzkYrJSK-K-cqwLhMxc8qivhao5hGyOhql_gSfwEpGmmuY0yAUP6RjIZVFnlv0k9B/s1429/reschart.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="759" data-original-width="1429" height="340" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfrM8klRk8PVMIkLQ14fMuNDGJ8_LiTh3r-8IeOoApso_P95RxmfiB5vimlcP97cpKWozogvN3vNSidFzOTE3vkROlT74RIm8pB9VGg5BNoWNZ3XgZAb1GlvjgzkYrJSK-K-cqwLhMxc8qivhao5hGyOhql_gSfwEpGmmuY0yAUP6RjIZVFnlv0k9B/w640-h340/reschart.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Resource usage over time for the SERV default configuration<br /></td></tr></tbody></table><br /> <br /><p></p><p><br /></p><p><br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg63DaasLurBkCfe4Ki1NnPppHJNcbS4UegDtvlBpxKzOz29nqzhFQvM3jGMROZ85I1p2mmAShJXUsL0m7Ej8oe8Jd1SmlMpTEA72AiDjjMxudWXEPb63cNokqcVKkR09BvDCwezEqjWkFt2irX-WKFNSUn_ufrN3J04lObqxCHCqQtypYHdjCcDz4M/s1284/serv_resources.drawio.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="284" data-original-width="1284" height="142" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg63DaasLurBkCfe4Ki1NnPppHJNcbS4UegDtvlBpxKzOz29nqzhFQvM3jGMROZ85I1p2mmAShJXUsL0m7Ej8oe8Jd1SmlMpTEA72AiDjjMxudWXEPb63cNokqcVKkR09BvDCwezEqjWkFt2irX-WKFNSUn_ufrN3J04lObqxCHCqQtypYHdjCcDz4M/w640-h142/serv_resources.drawio.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Mimimum SERV resource usage for some popular FPGA families<br /></td></tr></tbody></table><br /><br /><p>So this time we focus on features instead. Most notably we have support for two major ISA
extensions, both often requested by users, but there are also a number of other new
features as well. Let's take a look at all of them, shall we?<br /></p><p></p><h2 style="text-align: left;">M extension</h2><p> <table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi85XwW2v11OPUVuz95dLp7fAUeflolhOjXSE6mePoM_7o84crsSY6LvPfc2weEMcZVfiy97vwfe_N19d-UZbRBrw0Ac2fJ85EqVZ9RMBpiXX4ac_oxXlS_sDd5ted1o-6PCbP9a0UCq51MNOO_Nb28AcDCqP_TDEeDHaftYk4lVpT7IZttKwnvz1no/s433/mul3.drawio.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="273" data-original-width="433" height="253" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi85XwW2v11OPUVuz95dLp7fAUeflolhOjXSE6mePoM_7o84crsSY6LvPfc2weEMcZVfiy97vwfe_N19d-UZbRBrw0Ac2fJ85EqVZ9RMBpiXX4ac_oxXlS_sDd5ted1o-6PCbP9a0UCq51MNOO_Nb28AcDCqP_TDEeDHaftYk4lVpT7IZttKwnvz1no/w400-h253/mul3.drawio.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Multiple SERV cores can share one MDU (or perhaps other accelerators)<br /></td></tr></tbody></table><br /></p><p>As
part of Google Summer of Code 2021, <a href="https://www.linkedin.com/in/zeeshanrafique23/">Zeeshan Rafique</a> implemented support
for the M ISA extension. This was done through an extension interface
that allows the MDU (Multiplication and Division Unit) to reside outside
of the core and potentially be shared by several SERV cores in the same
SoC, or integrated into other RISC-V cores for maximum reusability.
We hope to also see other accelerators use the extension interface soon. Zeeshan's report about the project to add the M extension can be read
<a href="https://medium.com/@zrafique/gsoc21-with-fossi-foundation-ff1c869daec8">here</a><br /></p><h2 style="text-align: left;">C extension</h2><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQXISPE8uy4HRT_LOpmimKKzh4oBP8PIBewHV-gGATv2K4tatkr9hk4ruYT_6GODfPy84xyEzvX6_2hqla6NkYtUSTGTmMyDgAWREJNe64wJWfsKp3OMV1nldXJeLfSUhSUq5D3cNocolST_DCGrxcbtm904WM7awgGl4SHhvQO-mUl-OsodIbsU2N/s692/1%200nkMYuDMDNW3W0q3QqaEzw.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="211" data-original-width="692" height="196" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQXISPE8uy4HRT_LOpmimKKzh4oBP8PIBewHV-gGATv2K4tatkr9hk4ruYT_6GODfPy84xyEzvX6_2hqla6NkYtUSTGTmMyDgAWREJNe64wJWfsKp3OMV1nldXJeLfSUhSUq5D3cNocolST_DCGrxcbtm904WM7awgGl4SHhvQO-mUl-OsodIbsU2N/w640-h196/1%200nkMYuDMDNW3W0q3QqaEzw.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Two extra blocks to save a lot of memory<br /></td></tr></tbody></table><br /> </p><p>As part of the <a href="https://mentorship.lfx.linuxfoundation.org/">Linux Foundation Mentorship</a>
program Spring 2022, <a href="https://www.linkedin.com/in/abdul-wadood-03260a157/">Abdul Wadood</a> has implemented support for the C ISA
extension. The C extension has been the most requested feature of SERV.
Since SERV is so small, the memory typically dominates the area and the C
extension has the potential to allow for smaller memories and by
extension a smaller system. Abdul's report about the project to add the C
extension can be read <a href="https://medium.com/@abdulwadoodd/risc-v-compressed-instructions-for-serv-6065f55158b4">here</a><br /></p><h2 style="text-align: left;">Documentation</h2><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipgJsNVW8q1euvZqk1Tzgcau8dPIsV7Rlb28DrdLhFvHntnxU7022zTk4nuUa1rIZ4jCha9UJTeMJTyR4Cf46JgXVmc-fw77cKcg-2ONXpV3Seu_gM648UAYchEqYhCbiMFLJkydpgy0YKtnwAwPHfNOYHpBOWwRYf6aWKHJC8SR9rbx88KcVP36Sw/s1184/doc_3.drawio.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="750" data-original-width="1184" height="406" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipgJsNVW8q1euvZqk1Tzgcau8dPIsV7Rlb28DrdLhFvHntnxU7022zTk4nuUa1rIZ4jCha9UJTeMJTyR4Cf46JgXVmc-fw77cKcg-2ONXpV3Seu_gM648UAYchEqYhCbiMFLJkydpgy0YKtnwAwPHfNOYHpBOWwRYf6aWKHJC8SR9rbx88KcVP36Sw/w640-h406/doc_3.drawio.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Pictures and words. The SERV documentation has it all<br /></td></tr></tbody></table> </p><p>Documentation
continue to improve with more gate-level schematics, written
documentation, source code comments and timing diagrams towards the goal
of becoming the best documented RISC-V CPU. There are always room for improvements, but now all modules as well as the external interfaces are at least documented.<br /><br /></p><h2 style="text-align: left;">Bug fixes</h2><p>A bug
that caused immediates to occasionally get the wrong sign (depending on
which instruction was executed prior to the failing one) was found and
fixed.<br />Model/QuestaSim compatibility has been restored after accidentally being broken after the 1.1.0 release and a few more resets have been added after doing extensive x-propagation analyses.<br /> </p><h2 style="text-align: left;">Compliance tests</h2><p>Version
2.7.4 of the RISC-V compliance test suite is now supported over the
older 1.0 release. A Github CI action has also been created to test the
compliance test suites with all valid combinations of ISA extensions for
improved test coverage.<br /><br /></p><h2 style="text-align: left;">Servant </h2><p>Moving outside of the SERV core itself we have Servant, the simple SERV reference SoC. Servant isn't the most feature rich SoC, instead focusing on simplicity, but it has at least the bare minimum to run the popular Zephyr Real Time Operating System. During this development cycle Servant, has gained support for five new FPGA boards: (EBAZ4205, Chameleion96, Nexys2 500, Nexys2 1200 and Alinx AX309)<br />With this, the total number of officially supported boards is 26.<br /></p><h2 style="text-align: left;">ViDBo support</h2><p> <table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4X9IO4FpcLqoidYXCEyLn1f3JlTZ2mbPrVKcL3nl_Qa2gJqVbPnnAaxjeITpkcN_uq75q2DxwMGZlw3hjT7Kn7hM_FtSX1ZxhNe-XftBaRDpP-xuVoYXxKH_dqL4w49DEOtc3wyQlvWxw959imxWv1KxZwKFB7PlpnXO_pBwC7_ydHpjiPzfGIE98/s1920/vidbo_browser.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1080" data-original-width="1920" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4X9IO4FpcLqoidYXCEyLn1f3JlTZ2mbPrVKcL3nl_Qa2gJqVbPnnAaxjeITpkcN_uq75q2DxwMGZlw3hjT7Kn7hM_FtSX1ZxhNe-XftBaRDpP-xuVoYXxKH_dqL4w49DEOtc3wyQlvWxw959imxWv1KxZwKFB7PlpnXO_pBwC7_ydHpjiPzfGIE98/w640-h360/vidbo_browser.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Got no FPGA board? Don't worry. ViDBo has you covered.<br /></td></tr></tbody></table><br /> <br /></p><p>Support for the
<a href="https://github.com/olofk/vidbo">Virtual Development Board protocol</a> has been added, making it possible to
interact with a simulation of an FPGA board running a SERV SoC, just as
it would be a real board. This allows anyone to build software for SERV
and try it in simulation without access to a real board.<br /><br /></p><h2 style="text-align: left;">OpenLANE support</h2><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkIFgjBHOFGL7jrDG_iFBU7h84qo_tTBOXHBh-6qTeQ6TfhZjgAVBT5lRuDX2a4_Txk3CBhRvWdt5nTOA88N-JiWL8B5Qy-Nedi0OMQAjWyZ95U5LB1hSNbjUV-ptMQpRLq6AFbiK2qolqEjnxJOpS6FdY40AnwV0rKk6I5VfP4TLXThIKmGjkgzFs/s1967/subservient_gds.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1902" data-original-width="1967" height="618" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkIFgjBHOFGL7jrDG_iFBU7h84qo_tTBOXHBh-6qTeQ6TfhZjgAVBT5lRuDX2a4_Txk3CBhRvWdt5nTOA88N-JiWL8B5Qy-Nedi0OMQAjWyZ95U5LB1hSNbjUV-ptMQpRLq6AFbiK2qolqEjnxJOpS6FdY40AnwV0rKk6I5VfP4TLXThIKmGjkgzFs/w640-h618/subservient_gds.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">A few thousand transistors needed to build the world's smallest RISC-V CPU<br /></td></tr></tbody></table><br /> </p><p>Thanks
to the FOSSi <a href="https://github.com/The-OpenROAD-Project/OpenLane">OpenLANE</a> toolchain, SERV can be implemented as an ASIC
with the SkyWater 130nm library. It has also been taped out as part of the
<a href="https://github.com/olofk/subservient/">Subservient SoC</a> but at the time of this release the chips have not yet
returned from the fab. Thanks to the combination of a FuseSoC, a FOSSi
ASIC toolchain and publicly available CI resources however, a GDS file
of SERV is now created on every commit to the repository, making the
ASIC process about as agile as it can get.<br /><br /></p><h2 style="text-align: left;">The future</h2><p>So what lie as ahead for
our favorite CPU? Well, there were a number of features that I decided
to postpone in order to get a new version released. There were plenty of
big features anyway<br /><br /></p><h3 style="text-align: left;">DSRV & QERV</h3><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2vgqyzhazxxwiAZio2I1VFa7ncmA-CvMxGYptx-CIwumBwVwTq7PyEg6etTSA_7MeBedDdTNYWGtzzyGa0LUy5j7QI6WX7Tifae6vLyV5OV49z1_Se-89RsfeBLm8S0tIRaiiY4a0JuIQ16EndAEjiRaiqCcOBcSNBcFBiYUWNKw56niqFRavmv8r/s1280/size_serv_end.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="720" data-original-width="1280" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2vgqyzhazxxwiAZio2I1VFa7ncmA-CvMxGYptx-CIwumBwVwTq7PyEg6etTSA_7MeBedDdTNYWGtzzyGa0LUy5j7QI6WX7Tifae6vLyV5OV49z1_Se-89RsfeBLm8S0tIRaiiY4a0JuIQ16EndAEjiRaiqCcOBcSNBcFBiYUWNKw56niqFRavmv8r/w640-h360/size_serv_end.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Smaller or faster. The choice is yours.<br /></td></tr></tbody></table><br /><p><br />SERV is very small.
That's kind of the point. However, many times it's preferable to use
slightly more resources if it also means faster. Changing to a 2-bit
datapath would make SERV twice as fast, while likely using far less than
twice as much logic. Moving to a 4-bit datapath would halve the CPI
once again. The 2- and 4-bit versions are tentatively called DSRV, for
Double SERV, and QERV, for Quad SERV. I think you get the point, but <a href="https://www.youtube.com/watch?v=FWb_oIAHxNc">here's</a> a video explaining the
idea in slightly more detail if anyone is interested in taking up this
as a project.<br /><br />While we could theoretically go for 8-, 16- and
32-bit versions as well, there are some internal design choices that
would make this more complicated and it would probably be a better idea
to design a new implementation from scratch for 8+ bit datapaths.<br /></p><h3 style="text-align: left;">Decoder generator <br /></h3><p>Another big thing that I had hoped to finish but decided to push to a future version is autogenerated decoder modules. I have spent a lot of work on it and I think it's a really interesting idea that might even end up as a paper at some point. Unfortunately I don't have the time to finish it up right now. So, what's it all about? Well, it's a bit complicated so I think it's best to leave the details to a separate article (which I hope to find time to write soon), but the overall idea is to take advantage of the fact that many internal control signals are irrelevant when executing some class of instructions, so that we can combine them with other control signals that are irrelevant for other classes of instructions.<br /></p><h3 style="text-align: left;">Servant <br /></h3><p>I was also hoping to add some improvements to Servant, the SERV reference platform but couldn't find time for that either. I think that's ok though. Anyone who's looking for a more advanced platform to run SERV should go for Litex instead which supports SERV already. Fellow RISC-V ambassador Bruno Levy even demonstrated that it was possible to <a href="https://mobile.twitter.com/BrunoLevy01/status/1482762899835822080">run DooM on SERV</a> through Litex, I might be a bit partial, but it's a beautiful thing to see this tiny thing take on such a big task and as a proud parent I look at it and wonder is there anything this little CPU can't do with a little encouragement.<br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-56194669966505410302022-10-01T02:11:00.001-07:002022-10-01T02:11:50.130-07:00It's time to to thank UVM and say goodbye<p>UVM has been a massive success. There's no doubt about that. For the first time it showed the chip industry the benefits of having a common framework. You can hire directly for UVM skills. Vendors provide UVM models for interfacing their IP. There are tools for generating UVM registers and other boilerplate code. There is training available and forums for asking UVM-related questions.<br /></p><p>But it wasn't always like that. I remember when UVM was still not widely adopted. A lot of companies said <i>"Weeeell, I'm sure this UVM thing is very good for other companies, but you know, our needs are a bit special"</i>. It's funny how all those special needs just suddenly disappeared when the economic benefits of not having to deal with your own framework and being able to easily hire people and get VIP from vendors became apparent.</p><p>So UVM has been a massive success. It has become so ubiquitous so that many people in the industry seem to believe it has some magical properties and that it's the only way to verify chips. But, frankly speaking, it's not really that good of a framework. It's clunky and suffer from a lot of legacy. Many companies I'm talking with don't actually use it as is but have written some custom framework on top, and you can find plenty of tools to <i>generate</i> UVM, which in the end means we end up with a boatload of incompatible framework generators instead. But the biggest issue is that it's written in SystemVerilog.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgr6yOTdamevrGgXt81DaWHMb-WkOVUMdNyKFvo728_xV7cJFmTdpQrya7Bt2-16KHe9QE0h_6SIBjk2pnWF6KmViU2Z0ALJx8AMpe6auSumKIKLPaeefgBBCf5WXy1533DcszoOX1kpOioGmDnkF41hQLsGcGDYfFmbt45e65av5q_xUnw24LD-vEc/s672/6vcu6y.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="672" data-original-width="500" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgr6yOTdamevrGgXt81DaWHMb-WkOVUMdNyKFvo728_xV7cJFmTdpQrya7Bt2-16KHe9QE0h_6SIBjk2pnWF6KmViU2Z0ALJx8AMpe6auSumKIKLPaeefgBBCf5WXy1533DcszoOX1kpOioGmDnkF41hQLsGcGDYfFmbt45e65av5q_xUnw24LD-vEc/s16000/6vcu6y.jpg" /></a></div><br /><p></p><p>Oh no! Will this turn in to one of those language wars again? Maybe, but we can't ignore the fact that there probably goes 1000 Javascript, Python or Java developers for each Verilog coder. (System)Verilog (or VHDL for that matter) barely scrapes the bottom of the top 50 most popular language lists. <i>"Nonsense!"</i>, I hear my fellow chip design engineers mumble, <i>"Everyone knows Verilog"</i>. Well, there's a word for that. Survivor bias. Everyone in the semiconductor industry knows Verilog because those who couldn't stand the language just went elsewhere. And this is a huge problem for the industry. On top of an aging demographic we have issues keeping the youngsters interested when there's other fancier languanges and environments out there.</p><br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrxik46_GaRhQ4_inctD7JWDfNWvmIc3Ba9yEAoAy7OcrvUD6aXaZraFt3nDUaohRIsTutSKRNwYLfancX7l-dP6kLurFAMeT2QubTI5cvK9KlB3GR3rKeb6Fnfg3SKUZYrDQ1iTUuk0qSZjkPSuEwAWmakWxFJDu52aqbJF1zbNgWpaxubZFEAyVn/s927/langlist.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="927" data-original-width="847" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrxik46_GaRhQ4_inctD7JWDfNWvmIc3Ba9yEAoAy7OcrvUD6aXaZraFt3nDUaohRIsTutSKRNwYLfancX7l-dP6kLurFAMeT2QubTI5cvK9KlB3GR3rKeb6Fnfg3SKUZYrDQ1iTUuk0qSZjkPSuEwAWmakWxFJDu52aqbJF1zbNgWpaxubZFEAyVn/w584-h640/langlist.png" width="584" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Github Language Stats (https://madnight.github.io/githut)<br /></td></tr></tbody></table><br /><p></p><p><i>"But! But!..."</i>, you argue, <i>"...you need Verilog to work with chip design"</i>. I won't argue that in practice this is true to some degree because there's a whole lot of verilog out there, but in theory Verilog doesn't say absolutely anything about how chips work. It's just a programming language, which original intended purpose was to describe chip behavior. Remember, Verilog wasn't ever meant to be used to implement chips, which is a fact that tends to get forgotten many times. As another example of this, look at <a href="https://en.wikipedia.org/wiki/Erlang_(programming_language)">Erlang</a>, which was created to program telephone switches. This means neither that Erlang can't be used for other things, nor that Erlang is the only way to program telephone switches.<br /></p><p>"Still.. ", I hear from the back of the room, <i>"..can't they just learn SystemVerilog? It's like C++, sort of".</i> That misses a large part of what makes a language successful. True, it's a C-like syntax to some extent (mixed up with Java and a hodge-podge of 90's language ideas), but you don't have access to your toolbox of C++ tools like linters, debugger, syntax highlighters, IDEs, sanitizers and everything else that makes you productive. While the chip designers might think SystemVerilog is the best option because it has the largest ecosystem in this domain, this ecosystem is a drop in the ocean compared to popular languages.<br /></p><p>And I'm 100% certain that in many cases, although it's beneficial, you
don't need to know a single thing about how chips work and you can still
do a great job of verifying the functionality of some IP core. Let's turn things around for a while. I have spent the past ten years developing military radar, software defined radios, automotive radar, digital cameras, weather radar to name a few things. And I have absolutely no clue about how microwaves work and I'm a lousy photographer, but I <i>still</i> can do a good job because at the abstraction where I work I don't need to understand all these things. But if I also would be required to learn, let's say Fortran, because that's what was traditionally used for math heavy applications. well, then I would probably start looking for jobs elsewhere. And the same goes for verification engineers. Give them a spec, tell them what to do and a familiar programming languages and they'll probably do just fine. I definitely think it's preferable to have someone who does know how chips work on the team, but it doesn't have to be all of them.</p><p>So let's assume then that we can have verification engineers who don't have to know verilog. What does that mean? Well, it means that our pool of potential candidates has grown by a 1000 times. I can tell you for sure that it will be a lot easier to find good verification engineers than finding good vericication engineers who <i>also</i> happen to know Verilog. And if you have ever experienced how hard it is to get good verification engineers, then this is something you will greatly appreciate. And it's not just the number of developers that's growing. The whole flourishing ecosystem of libraries, forums and examples around popular languages like Python makes the Verilog ecosystem look like a wasteland and this means you can reuse much more existing code and involve your software friends in better ways.<br /></p><p>So what's the solution then? We need to enable software developers to create and verify chips. In this article we will be looking at the verification side, but I suggest looking at companies like <a href="https://www.chipflow.io/">ChipFlow</a> to see what's happening on the design side as well. And Python is a good bet right now. It might be Go or Rust or something completely different in a couple of years, but right now Python is widely used already as a glue language in chip development environments, like perl was used 10-20 years ago. And we see more and more EDA tools growing Python bindings. I'm <a href="https://twitter.com/OlofKindgren/status/1266360304881057792">not sure</a> the latter is a purely positive thing, but we'll see.<br /></p><p>And when it comes to Python and verification I have said many times by now that I believe <a href="https://www.cocotb.org/">cocotb</a> will be one of the important technologies in the coming years. It is a mature technology that is already adopted by large and small companies and you can find ads for companies looking to hire for this skill. And just like we saw with UVM, being able to hire for a certain skill without having to train them for your home-built verification framework is a time and money saver. Another thing that speaks for cocotb is that it uses your regular RTL simulators. This means it poses no threat to the EDA vendors. It just enhances their offering and they can continue to sell licenses for their tools. And with cocotb being a project governed by <a href="https://fossi-foundation.org/">FOSSi Foundation</a>, we clearly see how much more interested the EDA vendors are in collaborating on cocotb compared to many other free and open source silicon projects. Of course, it also works with your favorite open source simulators like Icarus, ghdl or Verilator and this means the proprietary EDA vendors need to compete with the open source tooling on equal terms, where they need to flex the strengths of their tooling rather than the artificial lock-in created because none of the open source tools have any UVM support to speak of.<br /></p><p>So, to sum things up. UVM has been a massive success and has seen industry-wide adoption over the past ten years. But the most important thing UVM did was probably to show the industry the benefit of having a common framework, not being the best framework in itself. My prediction is that UVM will see a slow (everything in EDA is slow) decline in the coming years and it will be relevant for long time, but gradually be replaced by frameworks written in more common languages and that it's a good bet to get to know cocotb specifically a little better. So I think it's time to consider whether UVM sparks joy. Otherwise, it's time to thank it and say good bye.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTbCIPtpirGCszyFTBuBHuyfsdCiu9uDE2JilH83WBKPbH5J5pf3lgTznlzznkLwi0LKNcGwesNC1Hczftz-wk6MovK1TId-s_adekdgZfbax-0DOlLp34xdj1ZuddE48qAVkXf9bgioWx6yKJ6Q9iXlQS6ohqJpLoOxreKJ6DqmHKOtSBGKkBJxZ6/s657/6vctjh.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="657" data-original-width="500" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTbCIPtpirGCszyFTBuBHuyfsdCiu9uDE2JilH83WBKPbH5J5pf3lgTznlzznkLwi0LKNcGwesNC1Hczftz-wk6MovK1TId-s_adekdgZfbax-0DOlLp34xdj1ZuddE48qAVkXf9bgioWx6yKJ6Q9iXlQS6ohqJpLoOxreKJ6DqmHKOtSBGKkBJxZ6/s16000/6vctjh.jpg" /></a></div><br /><p></p><p>Now, if the industry could just agree on a <a href="https://github.com/olofk/fusesoc">common format for describing IP cores</a> and <a href="https://github.com/olofk/edalize">interfacing EDA tools</a>. Oh well. That's another battle for another day.<br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-64653416196769148072022-02-11T10:57:00.000-08:002022-02-11T10:57:14.838-08:00FOSSi Explosion 2021<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiUMXWdQID97nDTFo_6Imt_yLhdvr_yjzpG04D-AKn8bRDb7FFwIf8z0Pw3YqXVsGwzu3i_9n7NyTJrepDDv9lAwHAr_7nUjF-1kZUtpePowGBofF13mrXAZoT2UlprDWRcmmj3-K4eAM2_RfQPYEmH0XiVGGMeLCo9UFCt4qAFQe0XcHx9tk4Ry4kN=s1600" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="900" data-original-width="1600" height="360" src="https://blogger.googleusercontent.com/img/a/AVvXsEiUMXWdQID97nDTFo_6Imt_yLhdvr_yjzpG04D-AKn8bRDb7FFwIf8z0Pw3YqXVsGwzu3i_9n7NyTJrepDDv9lAwHAr_7nUjF-1kZUtpePowGBofF13mrXAZoT2UlprDWRcmmj3-K4eAM2_RfQPYEmH0XiVGGMeLCo9UFCt4qAFQe0XcHx9tk4Ry4kN=w640-h360" width="640" /></a></div><br /> <p></p><p>Do you know what just happened? 2021 just happened. Most years has its ups and downs, but when it comes to 2021 it seems like the prevalent feeling was that everyone just wanted it to be over. And now it is over, except for all those damn retrospectives. So, with the risk of opening up some old wounds I would like to take a look at what happened last year in my corner of the free and open source silicon world.</p><p>In the <a href="https://olofkindgren.blogspot.com/2021/02/fossi-fever-2020.html">2020 retrospective</a> I wrote about a couple of big milestones, like the first vendor-supplied FOSSi FPGA toolchain and the first fully FOSSi ASICs. 2021 was... more of the same I guess. And personally I think this is the interesting part. Everyone is now working hard to actually do stuff with these new opportunities that arose in 2020. Finding new possibilities, hitting limitations and working around them. Solving problems, being creative and coming up with new ideas. Less headline-friendly but will have more impact longer term. And 2021 was by no means void of interesting news. Just look at the FOSSi Foundation newsletter <a href="https://medium.com/librecores">El Correo Libre</a> that was packed to the brim with interesting projects and announcements each month.. It's more that I couldn't think of anything that particularly stood out so I'm moving directly to the more personal events instead. Is that ok? Of course it's ok. I'm writing now!<br /></p><p></p><p><br /> </p><h2 style="text-align: left;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEibDb8wmGSLN3BxvqzgaWdbl0_qMQsWMD3F6qO0hFtw-RbOGL3HflW-qc1AAeOfofMo1m60ahj4sCuyTlPadF_90NN8SN_O1kPy_znhVXw0-GtnnDvtOqXaQVg36Eu8oUKTSjaXHegLFUWzP-B0v9DRJzeJO8OfQbh7RBFMTN8nQyalyW9c65Ln-j0V=s1035" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1035" data-original-width="1035" height="320" src="https://blogger.googleusercontent.com/img/a/AVvXsEibDb8wmGSLN3BxvqzgaWdbl0_qMQsWMD3F6qO0hFtw-RbOGL3HflW-qc1AAeOfofMo1m60ahj4sCuyTlPadF_90NN8SN_O1kPy_znhVXw0-GtnnDvtOqXaQVg36Eu8oUKTSjaXHegLFUWzP-B0v9DRJzeJO8OfQbh7RBFMTN8nQyalyW9c65Ln-j0V=s320" width="320" /></a></div>FuseSoC <br /></h2><p>Let's start by looking at my oldest active open source project, <a href="https://github.com/olofk/fusesoc">FuseSoC</a>, that turned ten years old in 2021. For those who don't already know, FuseSoC is an award-winning package manager for HDL code. Package manager is a concept that is well-known for software developers, from system-level package managers like apt and rpm to language-specific ones like npm, pypi maven and cargo.</p><p>For chip designers, the idea of a ubiquitous package manager has not taken hold and most companies invent and maintain their own incompatible system. Kind of like how we did software up to the mid nineties. Although not as ubiquitous as I had hoped by now, FuseSoC has over its ten years life span still grown to be the most widely used package manger for Verilog/VHDL code and is used internally in large and small companies as well as powering many of the most popular open source silicon projects.</p><p> So how was 2021 for FuseSoC? Frankly, not all that exciting. There was the FuseSoC 1.12 release early 2021 that you can read about <a href="https://olofkindgren.blogspot.com/2021/02/fusesoc-112.html">here</a>. We got to see some new features, like fellow RISC-V Ambassador Carlos Eduardo de Paula showing how to use FuseSoC with Chisel-based designs, but most of the work done on FuseSoC over the year was to prepare for a big, exciting 2.0 release that will happen some time in 2022. Still, it makes sense to mention FuseSoC first because it is used by every single other project written about here, and the number of projects <i>using</i> FuseSoC steadily rises regardless of the activities on FuseSoC itself.</p><p>And just how to get started with FuseSoC for a new design is a question that pops up from time to time. So when Alibaba Group's T-Head Semi released their OpenC910 I did a spur-of-the-moment live coding session, adding FuseSoC support for the core, documenting it through a <a href="https://twitter.com/OlofKindgren/status/1450797391557300225">Twitter thread</a> for everyone to see the process as it unfolded. Check it out if you want to see the unfiltered process of taking a previously unseen core and adding FuseSoC support for it, as well as showing some of the benefits in doing so.<br /></p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjWHVtJHAyZLGvegpQ2i7DAFcqvqcxgJwWYbdP_O-FPVmSyiMzOYIriECiofSKVZQphmJVypCYDQoK4T92Gy_A9xagvLWEh0s82EqgkZz-VySUsNul7Sjl4ebycR6kja_8x8JlYvhwH2LNKrpBu03ddkvRag4u5R2k9G7aHux2AmVZgTVztgl0L9CrP=s130" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="121" data-original-width="130" height="298" src="https://blogger.googleusercontent.com/img/a/AVvXsEjWHVtJHAyZLGvegpQ2i7DAFcqvqcxgJwWYbdP_O-FPVmSyiMzOYIriECiofSKVZQphmJVypCYDQoK4T92Gy_A9xagvLWEh0s82EqgkZz-VySUsNul7Sjl4ebycR6kja_8x8JlYvhwH2LNKrpBu03ddkvRag4u5R2k9G7aHux2AmVZgTVztgl0L9CrP=w320-h298" width="320" /></a></div><br /> <p></p><h2 style="text-align: left;">Edalize</h2><p><a href="https://github.com/olofk/edalize">Edalize</a> started out as a part of FuseSoC but was split out into its own project in 2018. That turned out to be the right decision because it is now used in several different projects other than FuseSoC. And in 2021, Edalize saw far more activity than FuseSoC. In case someone is wondering what Edalize is, it's an abstraction library for EDA tools. Basically, it provides a common API for different EDA tools such as simulators, formal tools, linters, synthesis tools and FPGA toolchains. So instead of writing Makefiles, TCL scripts and other configuration files for 30 different EDA tools manually, you just need to describe it once it the EDAM (EDA Metadata) format and Edalize will generate the correct setup files for your tool of choice. Very handy. The <a href="https://www.youtube.com/watch?v=HuRtkpZqB34">award-winning five minute Edalize introduction video</a> provides more detail about this.</p><p>As mentioned, Edalize saw a lot of activity during 2021. First of all it gained support for three new FPGA toolchains; oxide for Lattice Nexus chips, libero for MicroSemi devices and apicula for Gowin FPGAs. The biggest news in terms of tool support was however the openlane backend which provided the first ASIC flow for Edalize. I wrote about that in <a href="https://olofkindgren.blogspot.com/2021/04/a-first-look-at-edalize-for-asic-flows.html">A first look at Edalize for ASIC flows</a> last year if you want to learn more.</p><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEihxAaE2COZtXEE13mrqWwomYC9txAP0Z88aEVTCzbAO6p7bNXg-DvQiEErc8armgGzs9S4bhuZC_qX-YjWBWlM61kHbWJjK5JQj6Wu6CcFQUfKjR43ZW5lDkF0rnspGLRZ6-9az4a151G1_Npsz6aEei_eqY893mi_7DHdInGzb_dHiTAnOYPjlQ7v=s1312" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="252" data-original-width="1312" height="123" src="https://blogger.googleusercontent.com/img/a/AVvXsEihxAaE2COZtXEE13mrqWwomYC9txAP0Z88aEVTCzbAO6p7bNXg-DvQiEErc8armgGzs9S4bhuZC_qX-YjWBWlM61kHbWJjK5JQj6Wu6CcFQUfKjR43ZW5lDkF0rnspGLRZ6-9az4a151G1_Npsz6aEei_eqY893mi_7DHdInGzb_dHiTAnOYPjlQ7v=w640-h123" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">From cheese to chips with the Flow API<br /></td></tr></tbody></table><br /> </p><p>A large chunk of the work done in 2021 was not immediately visible to users but was done to lay the foundation of the new Flow API, which will add a great deal of more features and flexibility to Edalize in the future. This has been in the works for quite some time and for those wanting to get a rough idea about it, I recommend taking a look at <a href="https://olofkindgren.blogspot.com/2022/01/edalize-030.html">the article accompanying the Edalize 0.3.0 release</a> which contains a brief introduction to the flow API.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjWGQN8TurVlOJCxDnfMUxZEYNjagQpVaWNAms-ugc5JK7yw_OZx7RkEsL-7ndIrUPPe4AusCVV8GNx0bEScymueDgKdh08IIeLpBppNVWfdo6GG3rJvzX1Va6XmY29R3Jahw59sO3cXQuYd_shwLUOpfqtrx2F2wHYhnuoLZ-dICajCAW7IJubUc7k=s1001" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="213" data-original-width="1001" height="136" src="https://blogger.googleusercontent.com/img/a/AVvXsEjWGQN8TurVlOJCxDnfMUxZEYNjagQpVaWNAms-ugc5JK7yw_OZx7RkEsL-7ndIrUPPe4AusCVV8GNx0bEScymueDgKdh08IIeLpBppNVWfdo6GG3rJvzX1Va6XmY29R3Jahw59sO3cXQuYd_shwLUOpfqtrx2F2wHYhnuoLZ-dICajCAW7IJubUc7k=w640-h136" width="640" /></a></div><br /><p><br /></p><h2 style="text-align: left;">SERV</h2><p>Moving on to another of my more well-known projects, the award-winning <a href="https://github.com/olofk/serv">SERV</a>, the world's smallest RISC-V CPU, there's plenty of news to report. The question everyone seems to ask first is if it got any smaller, and yes, it did. I was able to optimize away around 20% of the remaining FFs during 2021, although the combinatorial parts of SERV remained more or less the same size.</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgmUmAovRzOL6fum8hPlEL2JzBr9mtX8Tp9bsh5acLez3tp2ai65a3v6LfQqajv7w6doFVxLnTv0YODmt4beez7vQAGJcfsYVL1Wj2fdHJaSQbeATHxlZJv96tE6Dys7oGhHmlX5yHxFTnfT8WgCC7Oh6hYNypIuRc7ptVe-R86SOYoIIU4VKo1cY0e=s1452" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="795" data-original-width="1452" height="175" src="https://blogger.googleusercontent.com/img/a/AVvXsEgmUmAovRzOL6fum8hPlEL2JzBr9mtX8Tp9bsh5acLez3tp2ai65a3v6LfQqajv7w6doFVxLnTv0YODmt4beez7vQAGJcfsYVL1Wj2fdHJaSQbeATHxlZJv96tE6Dys7oGhHmlX5yHxFTnfT8WgCC7Oh6hYNypIuRc7ptVe-R86SOYoIIU4VKo1cY0e=s320" width="320" /></a></div><br /><p></p><p> But size isn't all that matters. The documentation was massively improved with most of the internal modules now having schematics which are accurate down to the gate-level. And to prove this is actually the fact, I redid the ALU in Digital (a logisim clone) from the schematics and used that as a drop-in replacement of the original ALU. If anyone has the time and interest it would be really cool to see all of SERV implemented in a Logisim-like program and even use that as an interactive documentation somehow.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiBbtW048eYcAF7Aq6SRY9liBprloc2Pl9hhcf-pic4sIsplpKtQ_wTCYO7YxjE0ekwp6DBtV47BnCUraU-SIA6kDcYFvMEdnGDhh1GL1nL6-ghErFIgP7tULfhCb_4R8NTSIB_eFbSETe65n5rNYCJ3bYeRq0VQh1IdRtM9D-6TXa9JI2ru0l1qQcR=s1511" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="829" data-original-width="1511" height="176" src="https://blogger.googleusercontent.com/img/a/AVvXsEiBbtW048eYcAF7Aq6SRY9liBprloc2Pl9hhcf-pic4sIsplpKtQ_wTCYO7YxjE0ekwp6DBtV47BnCUraU-SIA6kDcYFvMEdnGDhh1GL1nL6-ghErFIgP7tULfhCb_4R8NTSIB_eFbSETe65n5rNYCJ3bYeRq0VQh1IdRtM9D-6TXa9JI2ru0l1qQcR=s320" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Working, runnable implementation of the SERV ALU<br /></td></tr></tbody></table> <p></p><p>In addition to schematics, I also added descriptions and timing diagrams for most of the important signal transitions. The ambition is to not only be the world's smallest RISC-V CPU, but also the most well documented. Still got some ways to go but it's already really good. As for new features, SERV got support for the M extension thanks to Zeeshan Rafique who added that as part of Google Summer of Code.</p><p>Another big milestone was that SERV was taped out at least four times during 2021 as part of the OpenMPW programme. Two of those tapeouts, both of them the SERV-based Subservient SoC, were done by my colleague Klas Nordmark and I (mostly Klas) as part of a grant by NLNet Foundation to add the Edalize OpenLANE backend and an accompanying reference project. There will hopefully be more things written about this particular project in 2022, especially when we receive the actual chips.</p><p>I also found some more time in 2021 to talk about SERV and presented at four conferences, with a <a href="https://www.youtube.com/watch?v=Nh-9xfK8Q1g">brand new SERV video</a> premiering at the embedded RISC-V Forum and being subsequently <a href="https://www.youtube.com/watch?v=FWb_oIAHxNc">updated</a> with some additional project ideas for the following events. This new video has shown to be quite popular and goes into more detail on more things that happened during 2021. It's still not as popular as the <a href="https://www.youtube.com/watch?v=xjIxORBRaeQ">SERV talk from WOSH 2019</a> though which apparently has been seen almost 30000 times(!?!?!?)</p><p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgYszQnasITSdYvqa0GwZlGqc4hgc5swVng5JLXYbOcHX4-ahO2frKaFoJrlU8ECpkLwoj0NzAkepc_z_e1TDY53UJRimYnIuQExf9kPSWRqaz-cSMGV7rfwytIsjiF_bxnujzD36S_30Gr4rC_uVeGf6keX3JxL8dWZrtm680FNUZjToSl4miJaF6h=s906" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="535" data-original-width="906" height="189" src="https://blogger.googleusercontent.com/img/a/AVvXsEgYszQnasITSdYvqa0GwZlGqc4hgc5swVng5JLXYbOcHX4-ahO2frKaFoJrlU8ECpkLwoj0NzAkepc_z_e1TDY53UJRimYnIuQExf9kPSWRqaz-cSMGV7rfwytIsjiF_bxnujzD36S_30Gr4rC_uVeGf6keX3JxL8dWZrtm680FNUZjToSl4miJaF6h=s320" width="320" /></a></div><p></p><h2 style="text-align: left;">CoreScore</h2><p><a href="https://corescore.store">CoreScore</a> is one of the more niche uses of SERV... ok, most uses of SERV are pretty niche come to think of it. Anyway, CoreScore is a project that tries to answer the question <i>How big is my FPGA?</i> by simply seeing how many SERV cores we can fit into the FPGA<br /> on different development boards. Pretty straight-forward but also very useful for comparing both FPGAs, and also the efficiency of different toolchains. Going into 2021 the record was 5087 cores in a single FPGA. That number was topped twice in 2021 with 6000 cores being the new world record thanks to Sylvain Lefevbre and his Xilinx VCU128 board. Apparently this made some numbers in the tech media and among other things ended up on <a href="https://www.tomshardware.com/news/6000-risc-v-cores-on-a-xilinx-fpga-break-the-corescore-world-record">Tom's Hardware</a>. That was particularly fun as I have fond memories of my 15 year old self spending hours and hours on Tom's Hardware trying to find which motherboard was best for overclocking my Celeron 300A Mendocino. But it was not just in the top where things happened in CoreScore land. In total there were 19 new scores submitted by different users, almost doubling the number of known CoreScores. And best of all, there's now a beautiful highscore table at <a href="https://corescore.store">corescore.store</a> to keep track of all the numbers.</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhqLJZuhlUS-Tnir0rFBbp5nWfGJmyzoTbJ7ohWlYT6OqFUvM-9p-Nxn9yLev5kHCEq1kD7ZMbjumBwx15e6ieg_Cf4DMfgirsKUxCBVreRbVQ-CFsOZ2AWWJ9jwCoz-PmFq3oJ-2EM6TcHk2I9rhfmmeOujKyoDwbXieIqOLD7-3JJdNRf5Rl4-a0n=s707" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="698" data-original-width="707" height="316" src="https://blogger.googleusercontent.com/img/a/AVvXsEhqLJZuhlUS-Tnir0rFBbp5nWfGJmyzoTbJ7ohWlYT6OqFUvM-9p-Nxn9yLev5kHCEq1kD7ZMbjumBwx15e6ieg_Cf4DMfgirsKUxCBVreRbVQ-CFsOZ2AWWJ9jwCoz-PmFq3oJ-2EM6TcHk2I9rhfmmeOujKyoDwbXieIqOLD7-3JJdNRf5Rl4-a0n=s320" width="320" /></a></div><br />If you're missing your favorite board in the list, don't hesitate to find out the CoreScore and submit a number for it. Love to see more!<p></p><h2 style="text-align: left;">LED to Believe</h2><p>Another less known but somewhat similar project to CoreScore is project <a href="https://github.com/fusesoc/blinky">LED to Believe</a>. The goal is simple. If you have an FPGA board, LED to Believe will be able to generate and FPGA image that blinks a LED on your board. While being a very simple project it does serve two purposes. The first is to act as a pipe cleaner for your toolchain. FPGA toolchains are complex and there's a suprising amount of things that can go wrong. Having the most simple project possible helps verifying that the tools are properly installed and can generate an image before you move on to other projects. The second purpose is to be an entrypoint into using FuseSoC and demonstrate how well-suited FuseSoC is for porting a design to different hardware targets. And I would like to claim that it has been <b>very</b> successful in this regard. Already when the year started we could blink LEDs on 44 different FPGA boards and as the year ended this number had risen to 77 thanks to all fantastic contributions from users all over the world. And again, see a board that's missing? Roll up your sleeves and send me a pull request.<br /></p><h2 style="text-align: left;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhImifno74sc-jEdKxdNjqfpSNbDXX9LC22y24Pt0d2YaGYpTUsWMmIAycXE1sOJyWJVK3cjuNkxU582Sq76rv8yRBNdewZia3ymGQ4dzRqwvz0e3mDM2JMjgrfSKREcGel1xz3dZIi3fWJjTFVVxAdJKq1jVt3D43Tebsl9dd4awvZfeyp9vSpwjZq=s650" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="650" data-original-width="433" height="320" src="https://blogger.googleusercontent.com/img/a/AVvXsEhImifno74sc-jEdKxdNjqfpSNbDXX9LC22y24Pt0d2YaGYpTUsWMmIAycXE1sOJyWJVK3cjuNkxU582Sq76rv8yRBNdewZia3ymGQ4dzRqwvz0e3mDM2JMjgrfSKREcGel1xz3dZIi3fWJjTFVVxAdJKq1jVt3D43Tebsl9dd4awvZfeyp9vSpwjZq=s320" width="213" /></a></div>SweRVolf</h2><p>The final big open source project I took into 2021 is <a href="https://github.com/chipsalliance/Cores-SweRVolf">SweRVolf</a>, a reference platform for the Western Digital SweRV family of RISC-V cores. More recently, SweRVolf is also the foundation of the <a href="https://university.imgtec.com/rvfpga/">RVFPGA Computer Architecture Course</a> from Imagination University Programme. RVFPGA is rapidly gaining popularity and I'm both excited and a bit scared now that thousands of university students will get their first contact with computer architecture, RISC-V, Zephyr, open source silicon and FuseSoC through a SoC I designed. And with that in mind, there has been some work to make SweRVolf even more robust and accessible.</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjUKv3llE7MygUqA2FOaPxlNzOEiss-lVXhC5NAflXfwEvzWBGCNySBsYGQamy0GWeHFgTdClMtxNEvEsSdD9jBdTfbzIYlabJlhcc1wxAsyUPqICXy1zKDAlDMv_Gxc6qNEf23g59XsZoBDouXOVPeV4ew0O8Ghf8-jOAP2J2KfpJjqeznIzpXRLRE=s1139" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="334" data-original-width="1139" height="189" src="https://blogger.googleusercontent.com/img/a/AVvXsEjUKv3llE7MygUqA2FOaPxlNzOEiss-lVXhC5NAflXfwEvzWBGCNySBsYGQamy0GWeHFgTdClMtxNEvEsSdD9jBdTfbzIYlabJlhcc1wxAsyUPqICXy1zKDAlDMv_Gxc6qNEf23g59XsZoBDouXOVPeV4ew0O8Ghf8-jOAP2J2KfpJjqeznIzpXRLRE=w640-h189" width="640" /></a></div><br /> <p></p><p>The year started with landing support for simulating using Vivado XSim in addition to the already supported Verilator and QuestaSim. Software support was improved as well thanks to a port of SweRVolf for the Tock OS. Increased availability could also be seen on the hardware side where it is now possible to use the smaller SweRV EL2 CPU as an alternative its larger sibling SweRV EH1. The EL2 support was also a prerequisite to run SweRVolf on the Digilent Basys3 board, which carries a smaller FPGA than the Nexys A7 and thus can only fit the EL2 CPU. Many of the latest features can be read about in the <a href="https://olofkindgren.blogspot.com/2021/09/and-out-come-swervolf.html">SweRVolf 0.7.4 announcement</a>.<br /></p><h2 style="text-align: left;">ViDBo</h2><p>The last piece of functionality added to SweRVolf is technically a
separate project, but it was born out of a need in RVFPGA and is where it was first used as well. As RVFPGA will become available as an online course, there were some concerns about hardware costs. The online education platform used wasn't totally happy about requiring students to buy an FPGA board. This could be solved by running the course entirely using an RTL simulator but it's really not the same thing as interacting with a board, running your own code and see how it reacts to moving switches and watching LEDs light up from your memory writes. There have been plenty of efforts to visualize simulations by providing some kind of GUI, either in terminal or through some graphics. All of those however seems to be one-off efforts and not easily portable. I wasn't really keen on either repurposing an existing solution nor writing a new single-use system. But then I got an idea. Instead of a tight coupling between simulator and GUI I decided to define a protocol that communicates I/O state over websockets. Websockets are readily available in almost any programming language and most importantly can be used directly in browsers without any complications.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEh95-Y-ttIJA5m5xlgt7yvDShwORo1BJniUaCKshLdUpjmMOXe49b4OJMkOUeQ33ZQONi9Ocr9O1GbXI88kX7NSVqf0V9ttGDjRXTRClbUiehajQlXP_iSokEZvEIGQRDKhQmeMZaBhm35y6bfZb-oh90KmYak2PXCBQgpxpa_p0C6jaIdS25X3v-d4=s762" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="271" data-original-width="762" height="229" src="https://blogger.googleusercontent.com/img/a/AVvXsEh95-Y-ttIJA5m5xlgt7yvDShwORo1BJniUaCKshLdUpjmMOXe49b4OJMkOUeQ33ZQONi9Ocr9O1GbXI88kX7NSVqf0V9ttGDjRXTRClbUiehajQlXP_iSokEZvEIGQRDKhQmeMZaBhm35y6bfZb-oh90KmYak2PXCBQgpxpa_p0C6jaIdS25X3v-d4=w640-h229" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">ViDBo : AKA, SoC over sockets<br /></td></tr></tbody></table> <p></p><p>This allows for adding a small component into the simulation model that sends simulation model outputs and receives inputs over websockets. On the other side of the websockets connection sits a browser with an interactive picture of the board, a Virtual Development Board, or <a href="https://github.com/olofk/vidbo">ViDBo</a>. This gets us as close as we reasonably can to a no-cost FPGA board experience without any simulator- or OS-specific building blocks. And while this first implementation uses an RTL simulator as the backend and a web browser as its frontend, there is nothing that stops us from having a pure software model as the backend or a headless CI system that acts as a frontend, injecting I/O state and observing outputs. VidBo only defines the protocol sent over websockets, not what sits on either side of the protocol. The only drawback of VidBo is that I now have yet another open source project to maintain which probably was the last thing I needed. Oh well, so far it hasn't been all that bad and I have had some very welcome contributions.</p><h2 style="text-align: left;">Other stuff<br /></h2><p>Wow! This turned out far longer than I had anticipated. Sorry about that. But if you
got this far and for some reason still haven't had enough of SERV and FuseSoC or want to
learn a bit more about the history of open source silicon, I also did a
series of video interviews during 2021, covering different topics. First
out was two episodes on open source silicon and RISC-V for the <a href="https://foss-north.se/pod/episodes.html#ep31">FOSS North pod</a> followed by Matt Venn interviewing me for the <a href="https://www.youtube.com/watch?v=xDzfJvdigbk">YosysHQ</a>.
Highly recommend checking out both those channels even if you don't
want to hear more of me. They both have many high quality interviews
with a wide range of topics and guests.<br /></p><p></p><p>I think this covers most of my open source silicon activities over the past year. Wait! One more thing. I made a <a href="https://twitter.com/OlofKindgren/status/1409634477135982598">UART that's small enough to fit in a tweet</a> in case, you know, someone needs a UART that's small enough to fit in a tweet.</p>Finally, I would also like to mention and extend my thanks to Qamcom and NLNet Foundation for funding work on Edalize and Subservient as well as Imagination Technologies and Western Digital who have been funding most of the SweRVolf and ViDBo work during 2021. Take note, all you freeloading companies out there. This is what real support of open source looks like and how you help build a healthy ecosystem.<p>And with those well chosen words we can leave 2021 without any regrets and sail into the bright future of 2022. Bon voyage!<br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-60225806884731762342022-01-07T06:30:00.003-08:002022-01-15T01:04:43.886-08:00Edalize 0.3.0<p></p><div style="text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhKSrGWJielpOoIyRCSp1UdUygcpQU3bnNPk5Z7gaFAcGdoR7HqXV8lixp5RG3Cx1UNIPUJzFwAdxg_F-WpG6hGDpWLFAQaFHJ5O29iIVYAT9X_5tziGyvSkOvZcCH0JOViotrvYPtxQUD5-PeUkOxydjsykTGePek_YzDXjSo99a-DkKMlcimXEzgb=s281" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="141" data-original-width="281" height="141" src="https://blogger.googleusercontent.com/img/a/AVvXsEhKSrGWJielpOoIyRCSp1UdUygcpQU3bnNPk5Z7gaFAcGdoR7HqXV8lixp5RG3Cx1UNIPUJzFwAdxg_F-WpG6hGDpWLFAQaFHJ5O29iIVYAT9X_5tziGyvSkOvZcCH0JOViotrvYPtxQUD5-PeUkOxydjsykTGePek_YzDXjSo99a-DkKMlcimXEzgb" width="281" /></a></div><br /><br /></div><br /> <p></p><p>Looks like it's time for a new Edalize release. During this development cycle, most of the work has been done under the hood with creating a new internal architecture and refactoring many of the backends. Most of those efforts will bear fruit longer term, but we can already today see the initial work on the flow API, that has been planned for at least two years. We also welcome a new backend for Lattice Nexus devices and some miscellaneous feature additions and bug fixes. Read on for the full story on what makes Edalize 0.3.0 the best Edalize (and likely the best EDA tool interfacing framework) ever!<br /></p><h2 style="text-align: left;">Flow API<br /></h2><p>Edalize today has almost 30 backends. That's a lot of backends! Each of these backends map to a primary tool. The icarus backend runs Icarus Verilog. The quartus backend runs Quartus, the Vivado backend runs Vivado and so on. Ok, that's not strictly true. The Vivado backend can also optionally use Yosys for Synthesis. But still, Vivado is the primary tool here. But then we have the Icestorm, Trellis, Apicula backends that first run Yosys, then NextPNR (or in the case of Icestorm optionally Arachne-PnR) and then finally runs some target-specific bitstream generation tool which is what has provided the name for the backend. Even though much of the heavy lifting is done by yosys and nextpnr, it's still reasonable to name it after the distinguishing part.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjUas9pSdgvKzfISjTikIBHq_F6poRcnKRdcP1uE7vOq4GalAC8ZxLKVqFVVPWihkMKTr4wkUnkxYQI8S1ENiIUKLX9sFgdQCKuoFgktkP7f_vvboXNzsl8HDz7AqRKbt1iBHv5DKW_GoPDaacqbz9MV8hSy4wCNTc-ohEDk3eHVF3pB62w76Jv2Wwx=s891" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="171" data-original-width="891" height="122" src="https://blogger.googleusercontent.com/img/a/AVvXsEjUas9pSdgvKzfISjTikIBHq_F6poRcnKRdcP1uE7vOq4GalAC8ZxLKVqFVVPWihkMKTr4wkUnkxYQI8S1ENiIUKLX9sFgdQCKuoFgktkP7f_vvboXNzsl8HDz7AqRKbt1iBHv5DKW_GoPDaacqbz9MV8hSy4wCNTc-ohEDk3eHVF3pB62w76Jv2Wwx=w640-h122" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Current tool-centric Edalize backend with the configure, build and run stages<br /></td></tr></tbody></table><br /> <p></p><p>But what if we want to do a timing simulation of a routed design for a Xilinx device using QuestaSim? In that case we want to run most of the Vivado toolchain before switching over to the simulator. We see both that the naming scheme is starting to fall apart and that the current architecture isn't capabale of doing this. And apart from the use cases that do work really well, we can also find plenty that don't. For example, look at the VUnit and (the currently proposed) Cocotb backends. Both these projects could be far better integrated with Edalize if the backends weren't considered a monolithic thing. The solution to this is the new flow API which allows arbitrary tools to hook up in a flow graph, using EDAM structures to pass information between them.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiYugAQsJsOx6Quar23RgMtENBWaxue7TqyoO6HxG5QgehVgboBSflK8z-LRu07YH2ZZQ9tnQucL9WlFIW-ioOnJiAu7Gtxm9iggxnAvL5yjTz2t4YrD4frAG8t52AocSp1sTRyE2myWGSG98sTlYKEoYiQtFnde64KlMi-PMppIRDXcohQZlUYnRhe=s1312" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="252" data-original-width="1312" height="122" src="https://blogger.googleusercontent.com/img/a/AVvXsEiYugAQsJsOx6Quar23RgMtENBWaxue7TqyoO6HxG5QgehVgboBSflK8z-LRu07YH2ZZQ9tnQucL9WlFIW-ioOnJiAu7Gtxm9iggxnAvL5yjTz2t4YrD4frAG8t52AocSp1sTRyE2myWGSG98sTlYKEoYiQtFnde64KlMi-PMppIRDXcohQZlUYnRhe=w640-h122" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Example of what a timing simulation flow could look like in the new flow API. The flow graph is first set up according to the backend configuration. EDAM structures then carry information between all nodes<br /></td></tr></tbody></table> <p></p><p>Separating the execution of the individual EDA tools and the execution of the flow graph into two distinct problems also allows future improvements such as using cloud orchestration tools or workload managers to direct the tool execution rather than a local Makefile, which is the case today. The new flow API also comes with a<span class="css-901oao css-16my406 r-poiln3 r-bcqeeo r-qvutc0"> new abstraction layer for executing EDA tools also allow us to more consistently add custom launcher for our tools. This has already been used to great effect for seamlessly running a combination of dockerized and local tools.</span></p><p>There are still a lot of things that need to be properly documented, features to add and many of the existing backends still need to be ported over to the new flow API, but the good news is that an initial version of the flow API is shipping with Edalize 0.3.0, so you can try it out right away. And it has already brought some new features that weren't available before like using Surelog or sv2v as frontends to bring SystemVerilog support to tool flows that don't natively support that. Here's a quick example for how to build a blinky for the icestorm flow with the new API<br /></p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">from edalize<span style="color: #333333;">.</span>flows<span style="color: #333333;">.</span>icestorm <span style="color: #008800; font-weight: bold;">import</span> <span style="color: #0e84b5; font-weight: bold;">Icestorm</span>
edam <span style="color: #333333;">=</span> {}
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"Adding files"</span>)
files <span style="color: #333333;">=</span> [{<span style="background-color: #fff0f0;">'name'</span> : <span style="background-color: #fff0f0;">'blinky.v'</span>, <span style="background-color: #fff0f0;">'file_type'</span> : <span style="background-color: #fff0f0;">'verilogSource'</span>}]
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"Setting parameters"</span>)
parameters <span style="color: #333333;">=</span> {
<span style="background-color: #fff0f0;">'clk_freq_hz'</span> : {<span style="background-color: #fff0f0;">'datatype'</span> : <span style="background-color: #fff0f0;">'int'</span>,
<span style="background-color: #fff0f0;">'default'</span> : <span style="color: #0000dd; font-weight: bold;">1000000</span>,
<span style="background-color: #fff0f0;">'paramtype'</span> : <span style="background-color: #fff0f0;">'vlogparam'</span>}}
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"Setting flow options"</span>)
flow_options <span style="color: #333333;">=</span> {
<span style="background-color: #fff0f0;">'nextpnr_options'</span> : [<span style="background-color: #fff0f0;">'--lp8k'</span>, <span style="background-color: #fff0f0;">'--package'</span>, <span style="background-color: #fff0f0;">'cm81'</span>, <span style="background-color: #fff0f0;">'--freq'</span>, <span style="background-color: #fff0f0;">'32'</span>]}
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"Creating EDAM structure"</span>)
edam <span style="color: #333333;">=</span> {
<span style="background-color: #fff0f0;">'name'</span> : <span style="background-color: #fff0f0;">'blinky'</span>,
<span style="background-color: #fff0f0;">'files'</span> : files,
<span style="background-color: #fff0f0;">'toplevel'</span> : <span style="background-color: #fff0f0;">'blinky'</span>,
<span style="background-color: #fff0f0;">'parameters'</span> : parameters,
<span style="background-color: #fff0f0;">'flow_options'</span> : flow_options,
}
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"</span><span style="background-color: #fff0f0; color: #666666; font-weight: bold;">\n</span><span style="background-color: #fff0f0;">Instantiating the Icestorm class with current dir as build directory"</span>)
icestorm <span style="color: #333333;">=</span> Icestorm(edam, <span style="background-color: #fff0f0;">'.'</span>)
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"</span><span style="background-color: #fff0f0; color: #666666; font-weight: bold;">\n</span><span style="background-color: #fff0f0;">configure writes the Icestorm configuration files but doesn't run any of the tools"</span>)
icestorm<span style="color: #333333;">.</span>configure()
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"Now we run the EDA tools"</span>)
<span style="color: #888888;">#This needs the actual EDA tools and the blinky verilog file (https://github.com/fusesoc/blinky/blob/master/blinky.v)</span>
icestorm<span style="color: #333333;">.</span>build()
</pre></div>
<p><br /></p><p><br /></p><p>Or just inspect which options are available for a specific flow</p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;"><span style="color: #008800; font-weight: bold;">from</span> <span style="color: #0e84b5; font-weight: bold;">edalize.flows.icestorm</span> <span style="color: #008800; font-weight: bold;">import</span> Icestorm
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"</span><span style="background-color: #fff0f0; color: #666666; font-weight: bold;">\n</span><span style="background-color: #fff0f0;">Available options for the icestorm flow"</span>)
<span style="color: #008800; font-weight: bold;">print</span>(<span style="background-color: #fff0f0;">"=======================================</span><span style="background-color: #fff0f0; color: #666666; font-weight: bold;">\n</span><span style="background-color: #fff0f0;">"</span>)
<span style="color: #008800; font-weight: bold;">for</span> k,v <span style="color: black; font-weight: bold;">in</span> Icestorm<span style="color: #333333;">.</span>get_flow_options()<span style="color: #333333;">.</span>items():
<span style="color: #008800; font-weight: bold;">print</span>(f<span style="background-color: #fff0f0;">"{k} : {v['desc']}"</span>)
</pre></div>
<p> </p><p>A slightly more involved example can also be found <a href="https://gist.github.com/olofk/5dc68c1f585ef4cadf3554382a8164fa">here</a> <br /></p><p>As for the next step, FuseSoC will be updated to take advantage of the new flow API <br /></p><h2 style="text-align: left;">prjoxide backend</h2><p>A new family of Lattice devices called Nexus have been documented under the name project Oxide. This has resulted in a new yosys->nextpnr->bitstream generation flow, which now has a corresponding Edalize backend.</p><h2 style="text-align: left;">Docker launcher script</h2><p>The Edalize backends are rapidly gaining support for using a custom launcher by setting the EDALIZE_LAUNCHER environment variable before running Edalize. This has been used to great effect already and serves many use-cases and will be the topic of a separate blog post some time in the future. But for now we will look at the major change for Edalize. As of this version, Edalize now ships with an extra script called el_docker, el meaning Edalize Launcher. Since running containerized versions of the open source EDA tools has been a frequent use case of the Edalize launcher mechanism, but required an external launcher script, I decided to ship this along with Edalize for now. So to use this, just set the environment variable EDALIZE_LAUNCHER=el_docker before Edalize gets called. Below is an example of first linting and then creating a GDSII file for SERV without a single local EDA tool. Pretty sweet, ain't it?<br /></p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;"><span style="color: #888888;">#Add SERV to the current workspace</span>
<span style="color: #996633;">$ </span>fusesoc library add serv https://github.com/olofk/serv
<span style="color: #888888;">#Set the launcher command</span>
<span style="color: #007020;">export </span><span style="color: #996633;">EDALIZE_LAUNCHER</span><span style="color: #333333;">=</span>el_docker
<span style="color: #888888;">#Run linting with Verilator</span>
fusesoc run --target<span style="color: #333333;">=</span>lint serv
<span style="color: #888888;">#Make GDSII file of SERV with OpenLANE and sky130 PDK</span>
fusesoc run --target<span style="color: #333333;">=</span>sky130 serv
</pre></div>
<p><br /></p><p></p><h2 style="text-align: left;">Other things <br /></h2><p>Verilator typically generates an executable simulation that is subsequently run, but there are use cases where the model instead should be integrated in a larger system. For this reason, the verilator backend now has an exe option which can be set to false to stop before the final linking<br /></p><p></p><p>This development cycle has also seen a lot of improvements on the CI side, reformatting the source code for consistency with a tool called black, support for newer Libero versions and as usual, a bunch of bug fixes</p><p><br /></p><p>I hope you all enjoy this new version of Edalize. As always, there's plenty of things going on and we would love some help, so if you want to get involved you are most welcome to join the chat at gitter.im/librecores/edalize or look through the code, issues or PRs at https://github.com/olofk/edalize<br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-7541099078379610972021-09-13T09:49:00.000-07:002021-09-13T09:51:51.222-07:00...and out come SweRVolf<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI3rtuS-Nj8WrRZAIE3eCORphb54TYErAqutXnwo9fkeuQtMHMqmeO5Dyv13U3mEIgwHHWYHLH_mJW4EOCTxlHMcy-SNe36KDsS6EYfPAPf9PRQGvgyn3TSIm4nvsLtjqiIqnqX-pfGRg/s650/swervolf_core_red.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="650" data-original-width="427" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI3rtuS-Nj8WrRZAIE3eCORphb54TYErAqutXnwo9fkeuQtMHMqmeO5Dyv13U3mEIgwHHWYHLH_mJW4EOCTxlHMcy-SNe36KDsS6EYfPAPf9PRQGvgyn3TSIm4nvsLtjqiIqnqX-pfGRg/w421-h640/swervolf_core_red.png" width="421" /></a></div><br /> <p></p><p>One of the main FOSSi projects I've been running the last couple of years is <a href="https://github.com/chipsalliance/Cores-SweRVolf">SweRVolf</a>, a <a href="https://github.com/olofk/fusesoc">FuseSoC</a>-based reference platform for Western Digital's family of RISC-V cores collectively called SweRV. I have written about SweRVolf before (e.g. <a href="http://olofkindgren.blogspot.com/2021/02/fossi-fever-2020.html">here</a> and <a href="http://olofkindgren.blogspot.com/2019/12/2019-year-of-risc-v-and-open-source.html">here</a>) so I won't go too much into details other than noting that it was created to provide an easy way to get started with the SweRV cores for both software and hardware developers and be simple enough to grasp for aspiring engineers while still providing enough flexibility to be expanded for advanced use-cases. And it seems to have hit these goals well enough, because Imagination chose to use SweRVolf as a base for their RISC-V-based computer architecture course called <a href="https://university.imgtec.com/rvfpga/">RVFPGA</a>. This means that tens of thousands of students will soon get their first contact with RISC-V, open source silicon and computer architecture through SweRVolf. And this in turn means that SweRVolf needs to be rock solid and provide the necessary features to be used in this context. Fortunately, both Imagination and Western Digital are putting their money where their mouths are and have sponsored the development of several features that have been deemed important for using SweRVolf in an educational context.</p><p>Most of these extra features as well as some other work have now been implemented which means it's time to do another release of SweRVolf, this time called 0.7.4. If you're impatient you can find pre-built FPGA bitstreams <a href="https://github.com/chipsalliance/Cores-SweRVolf/releases/tag/v0.7.4">here</a> and try it out right away, but for those of you with a little more time, let's dig into the changes since the last version.</p><h3 style="text-align: left;">Xilinx XSim support</h3><p>In addition to official support for ModelSim/QuestaSim and Verilator, SweRVolf can now also be simulated with Vivado XSim (versions 2020.1 and later). While the former are still recommended for performance reasons, having XSim as an option is useful, especially if Vivado is already used for building an FPGA version of SwerVolf. Please note that these are only the officially supported simulators, but there has been successful reports of using other simulators such as xcelium or Riviera Pro<br /></p><h3 style="text-align: left;">SweRV EL2 support</h3><p>When SweRV was announced in 2018 the family consisted of SweRV EH1, with other versions coming later. And in early 2020 the EL2 and EH2 variants were released, providing smaller and higher performance options. Of these two versions, adding support for EL2 has been the most requested feature, not least from RVFPGA to optionally allow using lower-cost hardware by selecting a simpler CPU. And in this version the support for EL2 has been finalized. Most of the work has been to provide infrastructure and abstractions both in software and hardware to easily switch between EH1 and EL2 in simulation and FPGA builds. One notable difference is that EH1 can run at 50MHz on the supported FPGA targets while EL2 only runs at 25. By adding hardware support for reporting such differences and making the software aware, most of them can be made transparent for users.<br /></p><p>For targets that support both EH1 and EL2, EH1 will remain the default but EL2 can be used by providing the option <span style="color: #444444;"><span style="font-family: courier;">--flag=cpu_el2</span></span> on the FuseSoC command-line, such as <span style="color: #444444;"><span style="font-family: courier;">fusesoc run --target=nexys_a7 --flag=cpu_el2 swervolf</span></span><br /></p><h3 style="text-align: left;">Demo application</h3><p>The Zephyr-based demo application is intended both as a quick self-test to show that things are working as intended as well as providing an example of how to use some of the functionality found in SweRVolf. This application has been updated to showcase some of the new features of the latest SweRVolf release such as printing out the CPU type and the runtime-detected clock frequency of the system</p><h3 style="text-align: left;">Zephyr support</h3><p><a href="https://www.zephyrproject.org/">Zephyr RTOS</a> is the recommended realtime operating system for SwerVolf and the SweRVolf-specific support functionality (BSP) is occasionally updated to catch up with the latest Zephyr version. This version will not support a newer Zephyr release but instead stays at 2.4. There is however added functionality to handle runtime-detection of system clock frequency, made necessary by the introduction of EL2 mentioned above. This functionality allows having the same UART baud rate and timer frequency across different system clock frequencies<br /></p><h3 style="text-align: left;">GPIO remapping</h3><p>The 32 upper GPIO have been moved on the memory map from 0x80001014 to 0x80001018 to allow space for a GPIO direction word adjacent to each 32-bit GPIO bank. This is one of the rare cases of changing the hardware to simplify software. More specifically, creating a 64-bit GPIO driver in Zephyr turned out to be far more complicated than expected. And since the upper 32 GPIO have not been used in any known SweRVolf implementation it was considered safe to move them, reserving space for a pin direction word to be implemented later.<br /></p><h3 style="text-align: left;">Basys3 support</h3><p>SweRVolf was originally created for the Digilent Nexys A7 board as that was identified as a popular board for a reasonable price with enough I/O and a large enough FPGA for SweRVolf. But it is by no means the cheapest option so SweRVolf has now also been ported to the Digilent Basys3 board which is about half the price. This is also a board that is very popular, not least in universities which hopefully means that a lot more people can get access to SweRVolf this way. And SweRVolf was created to be portable so hopefully the new board support can serve as a template to add support for even more boards in the future.The smaller size of the FPGA on the Basys3 board however only allows for SweRV EL2, not SweRV EH1</p><p></p><h3 style="text-align: left;">Documentation</h3><p>Apart from adding a chapter describing the Basys3 support, an error in the boot switch arrangements was found and corrected for the Nexys A7 target. A link to a port of the Tock OS has also been added together with a link the the project page on LibreCores. And if you are using SweRVolf in any way and would like the world to know, please let me know and I'll add it to the documentation.</p><p>As for the future there is at least one interesting feature in the works that I hope to share soon. Until then, have fun with SweRVolf 0.7.4. Sounds pretty fun, doesn't it? <br /></p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-46594923104135074482021-04-28T13:18:00.000-07:002021-04-28T13:18:11.017-07:00A first look at Edalize for ASIC flows<p>Over the past years there has been a revolution in open source silicon. While there have been open source IP cores and open source chip design tooling available for at least 25 years, a lot of this has been disparate efforts. What we see now is that many of these projects are coming together as a tour de force creating a snowball effect of generating more projects and innovations being built from these earlier efforts. As I mentioned in my <a href="https://olofkindgren.blogspot.com/2021/02/fossi-fever-2020.html">2020 retrospective</a>, we finally reached an important milestone last year where it’s now possible to create an ASIC using only open source code and tools. And within the limitations of the tools and technology this works just fine for one-off designs. Scaling this up has been a problem however. We see the same tasks being manually repeated and RTL files being copied over and over again instead of focusing on making more exciting end products.<br /><br />A big part of this has been the lack of tooling to make it easier to use and reuse existing designs. If we had been developing a software project we would just had used pip, apt, npm, cargo or similar to bring in the bits and pieces in the form of packages that already exist and focus on our core functionality of the project.<br /><br />And similarly if we are developing a complex FPGA product we would use <a href="https://github.com/olofk/fusesoc">FuseSoC</a>, the award-winning package manager for IP cores, to quickly bring in pre-existing IP cores to the design we're working on and send the whole design to your simulator or FPGA toolchain of choice, allowing us to just care about the parts of the design that does not already exist.</p><p>Wouldn't it be nice if we could have that for ASIC implementations as well? The good news is that we are almost there.<br /><br />Aided by funding from the <a href="https://nlnet.nl/project/Edalize-ASIC/">NLNet NGI0 PET fund</a>, <a href="https://www.qamcom.com/">Qamcom</a> is now extending <a href="https://github.com/olofk/edalize">Edalize</a> with a new backend for ASIC implementations, starting with the <a href="https://github.com/efabless/openlane">OpenLANE</a> flow. The work is being done primarily by <a href="https://www.linkedin.com/in/klas-nordmark-33a97244/">Klas Nordmark</a> and me (<a href="http://linkedin.com/in/olofkindgren/">Olof Kindgren</a>)</p><p></p><p></p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAce-W8jGtMQ9fIQyZNiZyfvX1rhmU6gHptpVUSFgnv57R5kMqavbdVJNLTjnW3zj5AWyY6bo1wS-rdjs2OasViVpcXmSjVHM2hnzwYYp2Im50VxZixtyrBnOUhWhH5uoy3BcejzPtSY4/s231/edalasic.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="227" data-original-width="231" height="393" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAce-W8jGtMQ9fIQyZNiZyfvX1rhmU6gHptpVUSFgnv57R5kMqavbdVJNLTjnW3zj5AWyY6bo1wS-rdjs2OasViVpcXmSjVHM2hnzwYYp2Im50VxZixtyrBnOUhWhH5uoy3BcejzPtSY4/w400-h393/edalasic.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Edalize+ASIC=Edalasic...or maybe not<br /></td></tr></tbody></table><br /><p> </p><p>The overarching goal of the project is to allow users to quickly onboard their existing FuseSoC-enabled designs to the OpenLANE flow by just adding a bit of OpenLANE-specific information to the core description file, run FuseSoC and get a GDSII file, making it just as easy as it already is to create an FPGA bitstream or a simulation model.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimdGvRkQ6r9jx-H2RXm2BV9xZbFsUXGBEBLMufeXMSetjxIPuNH760916lXKAI5en1CAUGBL0CtIi5fUxlu4wqIaPOEAg6jX7aq8lkmxtD4zuYE46-vsd2GXygUhL7gab2NGHqMn0ZH-s/s1478/fuseblock.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="486" data-original-width="1478" height="210" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimdGvRkQ6r9jx-H2RXm2BV9xZbFsUXGBEBLMufeXMSetjxIPuNH760916lXKAI5en1CAUGBL0CtIi5fUxlu4wqIaPOEAg6jX7aq8lkmxtD4zuYE46-vsd2GXygUhL7gab2NGHqMn0ZH-s/w640-h210/fuseblock.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><br />The FuseSoC+Edalize flow in all its glory</td></tr></tbody></table><br /><br />To further aid users starting out their ASIC journey, we have started developing a reference project called subservient, which is a small SoC based on the award-winning <a href="https://github.com/olofk/serv">SERV,</a> the world's smallest RISC-V CPU. The subservient SoC can be found <a href="https://github.com/olofk/subservient/">here</a>.<br /><br /> <table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6BGTLQxzTFV398CAUzW4yNfIUTsPeteYdlEfVTXuq-LUPM1QRptB0JHdCzHjModc7YM723ritJwasElBQb15Ot83eKD2dYdm4iTyYO4IF5RpQ5oVk9hQyPeM8zpdA0GJ_vic5SZo4KaQ/s306/subservient_externals.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="220" data-original-width="306" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6BGTLQxzTFV398CAUzW4yNfIUTsPeteYdlEfVTXuq-LUPM1QRptB0JHdCzHjModc7YM723ritJwasElBQb15Ot83eKD2dYdm4iTyYO4IF5RpQ5oVk9hQyPeM8zpdA0GJ_vic5SZo4KaQ/s0/subservient_externals.png" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">subservient: The pocket-sized RISC-V SoC for your every need<br /></td></tr></tbody></table><p><br /><br /><br />We are also working on adding FuseSoC support for the <a href="https://github.com/asicbitch/openlane-examples">OpenLANE examples</a> and would also like to see support in... well, pretty much everything. And here's where you come in my dear readers. As has been the case from day one of FuseSoC development, it’s important to test the flow on as many different designs made by as many different people as possible to make sure to not build in any assumptions we might make from our own designs. So please take your designs through the FuseSoC flow and let us know how it went. If not for our sake, but to see yourself how many gates and how fast your design would be in an ASIC, and make a pretty GDSII file that you can show friends and family. That's one part that I have looking forward to see for my own designs</p><p><br /><br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWyQiWGlX-R03X49FjkSfQGvPg6Rp6XelVQhKp_sFmgyHEOMmCRAiJ_KFEkQOVTEGK8ewoFhcj-j-ZWBDY4MLWbubGBsszinOcEIQd-ml1r2w8OYIsm2F18nPMy7S_OMLXBXECqOEkbNk/s1967/subservient_gds.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1902" data-original-width="1967" height="386" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWyQiWGlX-R03X49FjkSfQGvPg6Rp6XelVQhKp_sFmgyHEOMmCRAiJ_KFEkQOVTEGK8ewoFhcj-j-ZWBDY4MLWbubGBsszinOcEIQd-ml1r2w8OYIsm2F18nPMy7S_OMLXBXECqOEkbNk/w400-h386/subservient_gds.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">subservient SoC in SkyWater's 130nm process: The Mona Lisa of GDSII files</td></tr></tbody></table><br /><p></p><p>Being an open source project with a strong focus on collaboration, perhaps the most important question would be, How can I get involved?<br /><br /> <br />First of all, whether you have some opinions, want to hear how things are going, have questions, need help or just want to be a fly on the wall you can find us in the <a href="https://gitter.im/librecores/edalize">Edalize chat room</a><br /><br />Trying out the reference flows is valuable to make us understand where documentation or implementation is currently lacking, and if you come across any problems please let us know by filing a bug report, suggest improvements to the code or documentation or even fixing the issue you found yourself. Being a work in progress means you might hit some bumps in the road, but it also means you have an opportunity to help out deciding the best solution.<br /><br />And as mentioned before, adding FuseSoC support for your own cores is valuable since it makes it easier for you to run it through different flows and for other people who want to use them as is or as a part of a bigger design. Don’t worry. Adding a FuseSoC core description file is in most cases
very straight-forward and doesn't put any additional requirements on
your code. We’ll help you figure out the problems if it doesn’t work. Also keep in mind that the larger the ecosystem of cores become, the higher chance you will find the cores you need next time you start a project.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4cM9MgRO54y15hFBUVMUuxgHWVZHil_MpQAEMzPqrhtYtkNMQGQGsRo9TRSCo52k3gvOjgenvWF8wAEXE8o2dXoR0sZSFj63kbW3a1-DDgYdHECOCxXDPixvfOz5DoqXe9vHfNdrVAZI/s1691/Corey+v%25C3%25A4nster+upp+m+chip.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="983" data-original-width="1691" height="233" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4cM9MgRO54y15hFBUVMUuxgHWVZHil_MpQAEMzPqrhtYtkNMQGQGsRo9TRSCo52k3gvOjgenvWF8wAEXE8o2dXoR0sZSFj63kbW3a1-DDgYdHECOCxXDPixvfOz5DoqXe9vHfNdrVAZI/w400-h233/Corey+v%25C3%25A4nster+upp+m+chip.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><i><b>“Focus on your core business, not your cores”</b></i> C. McCoreface 2019<br /><i><b></b></i></td><td class="tr-caption" style="text-align: center;"> </td></tr></tbody></table><br /> <p></p><p></p><br /><p> </p>
<br />Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-58276101675627068862021-02-25T13:41:00.001-08:002021-02-25T13:48:23.798-08:00FuseSoC 1.12<p>It's February 25th 2021 today and you all know what that means! It's time for another FuseSoC release! So what happened since last time? Well, let's find out.</p><p></p><div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifAi12VR5EuYzG5nEZI9JrQaBU3kBEOnJPNlXrVnkP2TNXmh8nZyqdMdCA9C2NFN9hOFcLds-GKU7IWn37A6xTTgdFfhqtzeMTnEcga0KWd7RER8z2NcJYn7eBhEGq503pTbvBYIyz72c/s1691/Corey+v%25C3%25A4nster+upp+m+chip.png" imageanchor="1"><img border="0" data-original-height="983" data-original-width="1691" height="233" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifAi12VR5EuYzG5nEZI9JrQaBU3kBEOnJPNlXrVnkP2TNXmh8nZyqdMdCA9C2NFN9hOFcLds-GKU7IWn37A6xTTgdFfhqtzeMTnEcga0KWd7RER8z2NcJYn7eBhEGq503pTbvBYIyz72c/w400-h233/Corey+v%25C3%25A4nster+upp+m+chip.png" width="400" /></a></div><br /> <p></p><p> First of all, as I mentioned in the <a href="https://olofkindgren.blogspot.com/2021/02/fossi-fever-2020.html">2020 retrospective</a>, most of the work during this development cycle has been done by Philipp Wagner. Thanks Philipp! He wasn't the alone though. This release had in total 11 people contributing code and looking at the history this is the most people contributing on a single release ever. As always, I'm really happy to see the project grow, so thanks everyone for helping out.</p><p>This release should perhaps also be seen as a bit of calm before the storm. Practically no user-facing feature additions were made to the code, but a lot of things were done to make sure FuseSoC is in good shape for upcoming changes and to provide users with a more polished FuseSoC experience.<br /></p><h3 style="text-align: left;">Testing</h3><p>There was much focus on improving the testing on FuseSoC this cycle. Tests are vital to make sure that things don't break when the code is changed and that existing code really does what it is supposed to do. <i><span style="font-family: courier;">tox</span></i> is now the preferred method for launching tests and has the benefit of being run in an isolated environment and therefore not requiring FuseSoC to be installed, or accidentally run the tests on another system-installed version of FuseSoC. The latter has actually caused a lot of headaches when you could sometimes make changes that were expected to make the tests fail but they still passed because they were not run against the version you had changed. But that's all in the past now thanks to tox. The tests also cover more functionality, mostly things that were discovered to be broken because there had previously been no test to detect when they broke. Related to testing FuseSoC, switched to using GitHub for CI instead of Travis and Appveyor<br /></p><h3 style="text-align: left;">Cleanup</h3><p>This cycle also contained a lot of my favorite pastime - removing things. Code is a cost, not an asset, and removing things makes it easier to focus on improvements. Cleaning up can be done at almost all time, but recent changes such as dropping Python 2 support, and perhaps more importantly a fresh pair of eyes, resulted in a lot of cleaning up this time. A lot of this was done internally, but also on the user-facing side there were some changes. Up until now there has been potential for mischief by specifying paths in the core files pointing to files outside of the core root. This was never meant to work and users trying this now get a proper scolding.</p><p>Two commands were marked as deprecated, <i>pgm</i> and <i>init</i>. For the former, the equivalent functionality can be accomplished by using the <i>run</i> command instead with the <i>--run</i> switch (Yeah, I know. It's not the most obvious syntax). The latter, which is intended to get the standard FuseSoC core library, can be done with <i>fusesoc library add fusesoc_cores https://github.com/fusesoc/fusesoc-cores</i> instead.<br /></p><p>Also deprecated were the (probably since long broken) <i>logicore</i> and <i>coregen</i> providers. Those were always intended as a stop-gap measure and their job is better handled by a generator, using the EDA tools tcl API to generate IP cores or add .xci files to your core file. The best alternative depends a bit on the situation.</p><p>The last thing to be deprecated is the <i>CAPI1</i> core description format. FuseSoC will keep supporting CAPI1 cores until FuseSoC version 2.0.0 comes along at some point in the future but it is highly recommended to update already now. And thankfully a core conversion tool is now available. The <a href="https://fusesoc.readthedocs.io/en/stable/ref/migrations.html">FuseSoC migration guide</a> goes into more detail on how to use that. And in parallel to this deprecation, all <i>CAPI1</i> cores from the FuseSoC standard library have been converted to <i>CAPI2</i>.</p><p>And finally, the already deprecated build and sim commands were removed in this release. Those commands were written for a <i>CAPI1</i> world which no longer exists other than in our memories. The <i>run</i> command has since long taken over.</p><p>To get your code base ready for FuseSoC 2.0 (which shouldn’t be too far away) we recommend that all users address all deprecation warnings as soon as possible. Deprecated features won’t go away in FuseSoC 1.x, but will be removed in FuseSoC 2.0.<br /></p><h3 style="text-align: left;"> Documentation</h3><p style="text-align: left;">We have good reasons to celebrate the 1.12 release of FuseSoC. One of the most prevalent problems has been fixed, that of unreadable or non-existent documentation. Philipp has done an amazing job in rewriting the documentation pretty much from scratch, dividing it into different sections targeted for users and developers as well as trimming down the <a href="https://github.com/olofk/fusesoc/blob/master/README.md">readme file</a> from its previous stream of consciousness into an elevator pitch for engineers. Also building the documentation should now be easier for those who wish to do so.</p><p style="text-align: left;">So are there really no new features whatsoever? Not really. As mentioned initially, we have been holding things off to make sure there's a solid base to start from when we unleash a flurry of exciting features.</p><p style="text-align: left;">Ok, I snuck in a small feature, which turned out to be pretty much my only contribution this cycle. It is now possible to set parameters for generators directly in the targets. What does this mean? It's probably easiest to show with a small example. Imagine two targets, each using a generator to, say, select the number of really small CPUs to be instantiated in the design. This is configured by setting the <i>count</i> parameter in the generator to the value appropriate for each target.</p><p style="text-align: left;"></p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: medium solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">targets:
target1:
generate:
- morecoregen1
target2:
generate:
- morecoregen2
generate:
morecoregen1:
generator: morecores
parameters:
count : 11
morecoregen2:
generator: morecores
parameters:
count : 73
</pre></div>
<p>
</p><p>Maybe it's just me, but I think there's some obvious areas for improvement here, so from now on, you can do it like this instead.<br /></p><p></p>
<!--HTML generated using hilite.me--><div style="background: rgb(255, 255, 255) none repeat scroll 0% 0%; border-color: gray; border-image: none 100% / 1 / 0 stretch; border-style: solid; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;"><pre style="line-height: 125%; margin: 0px;">targets:
target1:
generate:
- morecoregen:
count: 11
target2:
generate:
- morecoregen:
count : 73
generate:
morecoregen:
generator: morecores
</pre></div>
<p>
</p><p>Pretty nice, ain't it?<br />
</p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-88989482284444434502021-02-23T04:49:00.006-08:002021-02-23T05:43:18.848-08:00FOSSi Fever 2020<p></p><div style="text-align: center;"><div class="separator" style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsAbyozNY2bQEYlXeqhWlV86seDowZ6BKCsSuKf231Qu6GLtWeVwoWJ-1Qz2KuIpTOEh3ilfAV2o_ki79PMrpk4IUM_mzANx4s_inuKEDx_1U_fa-AgAb9MN0cf7nBbX3ygoZhoS-N1C0/s1600/fuckload.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="899" data-original-width="1600" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsAbyozNY2bQEYlXeqhWlV86seDowZ6BKCsSuKf231Qu6GLtWeVwoWJ-1Qz2KuIpTOEh3ilfAV2o_ki79PMrpk4IUM_mzANx4s_inuKEDx_1U_fa-AgAb9MN0cf7nBbX3ygoZhoS-N1C0/w400-h225/fuckload.png" width="400" /></a></div><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiybZrk9QVM-u17xHCRNSUt453yMkSrLoVLktBdzJb8c9IYlCzasAlOXhoUIMp5_smrYKZazBGX7ug4kULLs7goH8dcSZrv8jsA2dOTe3_FvK8u_0C0GKxNVrSm6gAeJvPL1O4YXv43aGY/s1600/fuckload.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"></a></div><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjILCSmLX6FB_SFvhIvobRCE5qsHXFT1VXbN4VDOOmGqN6xJY0_Mn8yPZ-QTfM-vIpdqJbLVdnbZ7FEzrZX-UCoRLybQcHc8ccIBr0jwIS-uBWDTszCJfjgTOw0qfiQ8ZLsXdIQaS6M_gI/s1600/fuckload.png"></a></div><p></p><p>2020 was a year with a lot of bad news and so it feels slightly strange to cheerfully write about a very specific topic in the light of this. But there will always be good and bad things happening in the world. So let's keep fighting the bad things and for now take look at what happened last year within the amazing world of open source silicon. I will start by mentioning the most significant, but by no means the only, milestones for the FOSSi movement as a whole and then take a more personal look at the work where I have been directly involved.<br /><br /></p><h2 style="text-align: left;">OpenMPW<br /></h2><p style="text-align: left;">The biggest story within free and open source silicon this year has undoubtly been the <a href="https://efabless.com/open_shuttle_program">openMPW project</a> involving Google, SkyWater Foundries and eFabless together with a number of other collaborators.<br /><br />Ever since I got involved in open source silicon ten years ago, building a fully open source ASIC has been one of those big milestones. While we have had FOSSi IP cores taped out on chips for at least 20 years and parts of the flow being managed by open source tools, it has always seemed to be too much work and requiring filling in too many gaps to have a fully open source end-to-end flow to produce ASICs. But, over the years people all over the world have filled in the gaps and done the work bit by bit. Sometimes in the context of overarching programmes to advance open source silicon, sometimes in academic settings, sometimes coming from the industry and sometimes as completely unpaid hobby projects. And this year all these efforts came together, helped by funding, to produce four shuttle runs, each loaded with 40 different completely open source designs. The first of these runs are currently being fabricated, and it will be extremely interesting to see them coming back.<br /><br />One of the final pieces in this puzzle was the PDK. And while SkyWater should be rightfully lauded for their decicion to open up their 130nm PDK, it begs to ask the question: Why on Earth did it take this long? What could possibly the fabs have to lose by doing this? What they gain is easy to answer, a completely new market of users who can create chips at their fab. According to people within the project, it's estimated that 75% of the people on the first shuttle define themselves as software engineers. It's very likely that none of these people would ever dream of making an ASIC without this possibility. So I kind of feel that making the EDA industry open up their formats is a bit like trying to get your kids to eat vegetables. It's a lot of groaning and complaining, but was it really all that bad in the end to get some nutritions. Or in the case of ASIC fabs, was it really all that horrible to release your PDK to get some more customers? Let's just hope this opens up the eyes of more fabs. My, and many others, dream is to eventually see the same thing happening to ASIC fabs as has been happening with cheap PCB services over the past ten years. And using that analogy, I'm quite sure it pays off to be early in the race. So, get started folks!<br /></p><h2 style="text-align: left;">QuickLogic and SymbiFlow</h2><p style="text-align: left;">The other big thing happening this year is that we finally have an FPGA-vendor shipping an open source toolchain for their devices. The company that will go down in the annals of history for being the first to do this is <a href="https://www.quicklogic.com/qorc/">QuickLogic</a> and their EOS S3 FPGA. This is by no means the first FPGA with an open toolchain, and the QuickLogic-flavored version of <a href="https://symbiflow.github.io/">SymbiFlow</a> developed by FOSSi veterans <a href="https://antmicro.com/">Antmicro</a> is based on all this prior work. But it is the first time we see a toolchain being created from the FPGA manufacturer's specifications rather than being figured out from compiled FPGA binaries and it's the first toolchain that is supported and funded by the vendor rather than being at best tolerated by them. And again I must ask, why did it take so long for this to happen? If I was running a small FPGA startup with limited resources, I can't for my life understand why I would want to spend a lot of time and money to build and continouosly maintain a big unwieldy toolchain all by myself instead of adding the required device-specific bits to a known good open source toolchain and share the maintenance burden. If nothing else it would free up resources to build other value-add products on top of the tools. It's like if every vendor of computer systems would first build their own operating system and compiler before shipping their products. This is what we had in the 80s and abandonded it for very good reasons. Because it made absolutely no one happy. And you know what? I think the users of FPGAs should put more effort into pushing their vendors to support open source toolchains, because it will save everyone a heap of time and money.<br /><br />Let me illustrate that last point with an example that actually happened when I was porting SERV to the QuickLogic devices. After synthesis I noticed that it used far more resources than expected. Looking at the synthesis logs I realized the memories in the design weren't mapped to on-chip SRAM. So I asked the toolchain developers about this. They pointed me to the file in the toolchain that contained the rules for mapping to SRAM. I quickly found a badly tuned parameter, changed it to a more sensible value and ten minutes later it was working fine. An hour later I had submitted a patch back to the toolchain that fixed the problem for everyone else who would encounter it.<br /><br />let's break this down into numbers. Finding the cause of the bug took about 15 minutes. Fixing it, another five. At that point I could use it myself, but after spending another 15 minutes or so, it was also fixed for everyone else.<br /><br />Now let's do the same exercise for a proprietary closed source toolchain. Finding the cause of the bug takes... well...it depends... Let me explain.<br /><br />I started my professional career at a company which at that point was the world's largest FPGA buyer. Whenever we had problems, they flew in two FAEs to sit in our lap, they could provide us with custom internal builds of their tools and generally tried to make sure the problem quickly went away so that we would continue to buy FPGAs from them. However, most companies are not the world's largest FPGA buyer and does not get this treatment. Instead you will have to wade through layers of support people until you reach someone who is actually qualified enough to acknowledge the issue. I have been in this situation numerous times and would estimate this process usually takes around 2-3 months. Actually fixing the bug probably takes five minutes or so in this case too, but here comes the fun part. In most cases you will now have to wait, I don't know, a year or so until the fixed bug ends up in a released product that you can download. What happens in practice is that the user tends to find a workaround instead. In the example above, the likely solution would be to instantiate a RAM macro instead of relying on inference. This however doesn't come for free as it requires finding all the instances where this is a problem, add special handling for this case which results in a larger code base with more options to verify and maintain. This costs time and this costs money. So the moral of this story is that closed source tools are more expensive for everyone involved and users of FPGAs should get better at telling the FPGA vendors that they are done with this closed source nonsense.<br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuw99yDUZ2ILpiEcVX_-ldpDZGfXAZ7oxRmpDLr9cBt-dR5Yyys4RfzhZ-eD6Yhs1Cw0VDq_DytNitAsdIbZSHG1gIc0qUdt37TXgg71Hq8WG1NiGHanDm8-E0LDQVS8OhANiLyhaWg30/s2048/qorc.jpg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="2048" data-original-width="1536" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuw99yDUZ2ILpiEcVX_-ldpDZGfXAZ7oxRmpDLr9cBt-dR5Yyys4RfzhZ-eD6Yhs1Cw0VDq_DytNitAsdIbZSHG1gIc0qUdt37TXgg71Hq8WG1NiGHanDm8-E0LDQVS8OhANiLyhaWg30/w480-h640/qorc.jpg" width="480" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The QuickFeather. First FPGA board to ship with a FOSSi toolchain<br /></td></tr></tbody></table><br /><p style="text-align: left;"><br /><br /><br />There are numerous other news and projects that are well worth mentioning, but the above two are milestones that we have been waiting for a long time, so they deserved special attention. And if you want to keep up with the latest happenings in open source silicon, I highly recommend subscribing to the <a href="https://www.fossi-foundation.org/ecl">El Correo Libre newsletter</a> which does a fantastic job of providing an overview of what goes on in all corners of the world. So let's move on to some of my more personal victories that aren't necessarily mentioned in other people's year in review.<br /><br />When I am working on and talking about open source silicon I am often
wearing many hats because I'm associated with several different
organizations. Luckily they are all pretty much aligned on this topic
which makes things far easier. But these organizations also have
different motives and goals so I would like to mention a few words about
them here. </p><p style="text-align: left;"></p><h2 style="text-align: left;">Qamcom</h2><p style="text-align: left;">My dayjob is working for <a href="https://www.qamcom.com/">Qamcom Research & Technology</a> and also there it has been more FOSSi work than usual, which I think is a good indication that open source silicon is becoming increasingly more common in chip design in general. The year started off by finishing up some work on <a href="https://github.com/chipsalliance/Cores-SweRVolf">SweRVolf</a> together with a couple of my Qamcom colleagues. SweRVolf is a project under <a href="https://chipsalliance.org/">CHIPS Alliance</a>, an organization that Qamcom has been part of since 2019 to help improve the state for open source and custom silicon. After that I was pulled into a project for doing <a href="https://www.qamcom.com/eiscat-climate-research/">climate research with a huge radar system</a>. My task here was to handle sub-nanosecond time synchronization between systems located hundreds of miles from each other, using the <a href="https://ohwr.org/project/white-rabbit/wikis/home">White Rabbit</a> system developed at CERN. I was pretty excited about getting to know White Rabbit. The timing section at CERN responsible for the White Rabbit project and associated technologies are household names within open source silicon and have a long history here. I know many of the people working there personally and have great respect for their work. But so far I haven't had the chance until now to actually get down and dirty with the technology. Once my job was done there I moved on to another proprietary project that I can't discuss here. I do get to use FuseSoC and Verilator though, so it's fine :)<br /><br /></p><h2 style="text-align: left;">FOSSi Foundation</h2><p style="text-align: left;">The hat I tend to wear most when topic revolves around open source silicon is my FOSSi Foundation director hat. And despite doing a lot less of the things we normally spend time on, it turns out we did a lot of other great things instead. I will however not go into more detail here, but instead point to the <a href="https://www.fossi-foundation.org/2020/12/31/year-recap">excellent summary</a> done by my FOSSi Foundation colleague Philipp Wagner.<br /><br /></p><h2 style="text-align: left;">RISC-V</h2><p style="text-align: left;">Arguably the most well-known project nowadays with ties to open source silicon is RISC-V. My RISC-V ties deepened in the beginning of the year when I was asked to become a <a href="https://riscv.org/community/ambassadors/">RISC-V ambassador</a>. Part of being an ambassador is to create awareness of RISC-V in the fields where I'm active. For well-known reasons the number and nature of events were a bit different from previous years which meant fewer opportunities to weild this new-found power, but I did participate in an ask-the-expert session during the RISC-V global forum and a couple of other events that will be described later. And I also got to be interviewed about RISC-V and open source silicon by Sweden's largest <a href="https://etn.se/index.php/intervju/67308-olofs-oppna-hardvara-forokar-sig.html">electronics</a> and <a href="https://www.nyteknik.se/premium/risc-v-oppet-kisel-standard-i-processorer-inom-tio-ar-7002031">tech news</a> outlets as well as the <a href="https://architecnologia.es/olof-kindgren-interview">Architecnologia blog</a>.<br /><br /><br /><br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhG_7fxu2iYe6-SXpcYJ-E4ttJvd1fe8NgOqNXAHexF67kS44uJOaGjCM3GfmBvkrYvSciA6lMUD5F55T8DA0EJdGwtp0MrU9pi5DgPxiekPrLTG6Qg-62mtF4dcXRJb0_rpA2zsni00cY/s1078/gangof12.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="894" data-original-width="1078" height="520" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhG_7fxu2iYe6-SXpcYJ-E4ttJvd1fe8NgOqNXAHexF67kS44uJOaGjCM3GfmBvkrYvSciA6lMUD5F55T8DA0EJdGwtp0MrU9pi5DgPxiekPrLTG6Qg-62mtF4dcXRJb0_rpA2zsni00cY/w628-h520/gangof12.png" width="628" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Current crop of RISC-V Ambassadors; AKA the Twantasic 12<br /></td></tr></tbody></table><br /><p style="text-align: left;">In addition to my day job and participating in different organizations I
also run a bunch of open source projects, so let's take a look at the progress of the most important ones during 2020.<br /> </p><h2 style="text-align: left;">SweRVolf</h2><p style="text-align: left;"><a href="https://github.com/chipsalliance/Cores-SweRVolf">SweRVolf</a> is an extendable and portable reference SoC platform for the Western Digital / CHIPS Alliance <a href="https://www.westerndigital.com/company/innovations/risc-v">SweRV cores</a>. SweRVolf is designed for software engineers who wants a turn-key system to evaluate SweRV performance and features, for system designers who want a base platform to build upon and for learners of SoC design, computer architecture, embedded systems or open source silicon methodology. To easily achieve the goals of portability and extendability it is powered by <a href="https://github.com/olofk/fusesoc">FuseSoC</a>, which just happens to be one of my other open source silicon projects mentioned later on.<br /><br />During 2020 SweRVolf gained support for booting from SPI Flash but most effort was spent on usability, <span> by</span> making it rock-solid, improve documentation, increase compatibility with more EDA tools, keep the underlying cores up-to-date and follow along with changes in the <a href="https://zephyrproject.org/">Zephyr operating system</a>, which is the officially supported software platform for SweRVolf. <br /><br />But the biggest thing to happen SweRVolf this year is that SweRVolf will be used as the base of a new university course from Imagination University Programme called <a href="https://university.imgtec.com/teaching-download/#CA">RVfpga: Understanding Computer Architecture</a>. I'm very excited (and slightly scared) about soon having thousands of students getting familiar with computer architecture, RISC-V and open source silicon through a SoC that I have designed. And I would like to mention a few things about how SwerRVolf is built because I think it's a great example of how to create chip designs. When I say that I have designed SweRVolf, most of the work has consisted of putting together various pieces and make sure it works well as a whole. Most of the underlying code has been written by other people, and from my perspective, that is really the most successful aspect of SweRVolf because it highlights the rich open source silicon ecosystem. The main CPU core is from Western Digital and governed by CHIPS Alliance. Most of the AXI infrastructure was developed through the <a href="https://pulp-platform.org//">PULP project</a> at ETH Zürich and University of Bologna. The UART and SPI controllers were developed for the <a href="https://openrisc.io/">OpenRISC project</a> during the first wave of open source silicon almost 20 years ago. The <a href="https://github.com/olofk/wb_intercon/">Wishbone infrastructure</a> was developed by me when I started out with open source silicon ten years ago and the memory controller was created by <a href="http://www.enjoy-digital.fr/">Enjoy Digital</a> and is written in Migen as part of the <a href="https://github.com/litex-hub">Litex</a> ecosystem. And to go full circle, the memory controller uses a tiny RISC-V CPU called SERV internally to aid with calibration. <a href="https://github.com/olofk/serv">SERV</a>, the world's smallest RISC-V CPU is written by me. Small world. And of course the whole project is packaged with <a href="https://github.com/olofk/fusesoc">FuseSoC</a> and uses <a href="https://www.veripool.org/wiki/verilator">Verilator</a> by default for simulations, so it's FOSSi all the way. As I hope you understand by now it's not about some lone hero churning out code, but instead all this has been made possible by a huge amount of work by a ton of people over many years, and I'm proud to be one of them.<br /><br /><br /></p><h2 style="text-align: left;">SERV</h2><p style="text-align: left;">Probably the hobby (read unpaid) project I spent most time on during 2020 was <a href="https://github.com/olofk/serv">SERV</a>, the world's smallest RISC-V CPU, which turned from small to even smaller during the year. SERV is very much a project driven by numbers, so lets look at some of these numbers.<br /><br />In February I got hold of an <a href="https://www.xilinx.com/products/boards-and-kits/zcu106.html">ZCU106</a> development board with a huge Xilinx Ultrascale+ FPGA for a project I was assigned to. As this was the largest FPGA I had ever had in my home I got curious to see how many SERV cores I could squeeze into it. The year before, at the 2019 RISC-V workshop in Zürich, I had done a <a href="https://www.youtube.com/watch?v=xjIxORBRaeQ">presentation on how to fit 8 RISC-V cores in a small Lattice iCE40 FPGA</a> (spoiler: it ended up being slightly more than 8 eventually), giving each of them a single I/O to communicate with the outside world. Problem this time was that after stuffing in 360 cores I run out of I/O pins. It would also had been practically impossible to verify that all these external pins actually did what they were supposed to do, so I needed some way of using less than one I/O pin per core. Then it struck me that just a few months earlier I had created a heterogenous sensor aggregation platform based on SERV cores called <a href="https://github.com/olofk/observer">Observer</a>. The idea with Observer was to connect a lot of sensors to an FPGA, each serviced by its own SERV core and then merge the data to an output stream. I gave up on the platform when I realized that while I could fit a lot of SERV cores into the devices, I just had a few sensors so there wasn't much data to to aggregate. But this platform was a very good starting point.</p><p style="text-align: left;"></p><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4wmBYSSq5OTf-AMUe2k5HSO44SFf0EOnLMKeRqEhM7_gPWgjSz24BZNsvOcM57Amd6SP_EfyDDdcEvELby_V1a2_v1BYORPrCIscWW36LYj0JdLa2ZwF2C5JcSFqWhBdE_J38Ktl1zg4/s1755/observer.png" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="936" data-original-width="1755" height="310" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4wmBYSSq5OTf-AMUe2k5HSO44SFf0EOnLMKeRqEhM7_gPWgjSz24BZNsvOcM57Amd6SP_EfyDDdcEvELby_V1a2_v1BYORPrCIscWW36LYj0JdLa2ZwF2C5JcSFqWhBdE_J38Ktl1zg4/w583-h310/observer.png" width="583" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Block diagram of the Observer platform<br /></td></tr></tbody></table><div class="separator" style="clear: both; text-align: left;">By removing all sensor interfaces and just have each core print out an identification message instead I had a system that I could instantiate with any number of cores. Trying this on the ZCU106 I could now run over 600 cores on the FPGA. The next problem then was that I was running out of on-chip RAM way before any of the other FPGA resources. In case you don't know, most FPGAs contain a number of fixed-size SRAM spread out over the devices, each typically being 1-8kB large. For SERV, each core used one for the RF (register file), and another one for the program/data memory. With RISC-V using 32 32-bit registers, this means that only 128 bytes of the RF RAM is used but since the fixed-size SRAM on FPGAs are typically being far larger than that most of the RAM ends up unused. That's bad, but I had a plan. With a bit of work I managed to share RF, program and data in the same RAM so that the RF is allocated to the top 128 bytes of the RAM. This freed up half of the on-chip RAM blocks and I could eventually hit 1000 SERV cores on the ZCU106 board. Of course, at this point I was curious to see what the situation was for other boards after all these optimizations. Taking it one step further I figured I should turn this into a real thing by creating a benchmark so that people can have a quick way to see roughly how large the FPGAs are on different boards. And with that ServMark was born.</div><p></p><p style="text-align: left;"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtoUxx_HDBOn3dZaHzIOzMazqZAThjO1pEepI10xKOwcYfjd_iDZBY4Unw5TMotpmSWDnjI4Q1KOLaq9vIdPSFiWRdosUlbx_tesCBMPmkHuR-lq2PO01vlq7zFYzGkZ_lBzH9p-_Q4Oc/s720/corescore_crop-0.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="500" data-original-width="720" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtoUxx_HDBOn3dZaHzIOzMazqZAThjO1pEepI10xKOwcYfjd_iDZBY4Unw5TMotpmSWDnjI4Q1KOLaq9vIdPSFiWRdosUlbx_tesCBMPmkHuR-lq2PO01vlq7zFYzGkZ_lBzH9p-_Q4Oc/s320/corescore_crop-0.png" width="320" /></a></div><br /> <p></p><p style="text-align: left;"> ServMark lasted for about three minutes until I realized <a href="https://github.com/olofk/corescore">CoreScore</a> was a much catchier name, so that's we have now.<br /></p><p style="text-align: left;"> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtkJpwLkfQlzcG7Qys_8ZAf1g-lSpZqtEjdXuUQQWOLda1FJMo-q3yvEV3uTR_cbskDMr28JgpkpBNOvGxOFpHahcYm3tCvY6SCpEhLh5cNFtkj0KHna6cBwz-Ah8JAaAkdJyWzyCBfp8/s717/corescore_announce.png2.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="411" data-original-width="717" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtkJpwLkfQlzcG7Qys_8ZAf1g-lSpZqtEjdXuUQQWOLda1FJMo-q3yvEV3uTR_cbskDMr28JgpkpBNOvGxOFpHahcYm3tCvY6SCpEhLh5cNFtkj0KHna6cBwz-Ah8JAaAkdJyWzyCBfp8/s320/corescore_announce.png2.png" width="320" /></a></div><p style="text-align: left;">I had originally planned to do a presentation about SERV at Latch-Up in Boston. But for well-known reasons we cancelled all FOSSi Foundation physical events. Instead I accepted an invitation to speak at the <a href="https://www.youtube.com/watch?v=_huTcpAc7sQ">First virtual RISC-V Munich meetup</a>. By this point I had attended a couple of virtual meetups and I hated it. It was in most cases awful to watch a narrated slide deck without a stage and a speaker to bring it to life at least a bit. So, I decided to take a fresh look and look at the possibilities instead of being limited by the medium. I decided to make videos instead. First of all, since people would watch on a computer screen with proper resolution instead of a washed-out image projected on canvas. This meant I could have much more detailed pictures and smaller font sizes. I could also freely mix pictures and animations, fine-tune timings, do several takes of the audio and add sound effects. And despite being done by someone who has pretty much zero experience in these sort of things, I think it turned out pretty well. So on the day of the event, I just introduced myself and let the audience indulge in my <a href="https://diode.zone/videos/watch/0230a518-e207-4cf6-b5e2-69cc09411013">fully immersive multimedia edutainment experience about SERV</a>. Not sure why the Oscars committee hasn't got in touch yet.<br /><br />Is CoreScore the only attempt to put a mind-boggling number of RISC-V cores inside chips? Absolutely not, and during the summer I learned of the Manticore project from Florian Zaruba and Fabian Schuiki (jointly known as Flobian Schuba) from ETH Zürich, both well-known names in the FOSSisphere from their work in the PULP ecosystem. <a href="https://arxiv.org/abs/2008.06502">Manticore: A 4096-core RISC-V Chiplet Architecture for Ultra-efficient Floating-point Computing</a> had been accepted into the prestigious Hot chips conference. Manticore is an impressive project, but I still thought it was a bit unfair that I wasn't invited as well. So I reached out for the biggest FPGA board I could find and then wrote my first academic paper of the year called <a href="https://github.com/olofk/serv/blob/doc/plenticore.pdf">Plenticore: A 4097-core RISC-V SoClet Architecture for Ultra-inefficient Floating-point Computing</a>. Unfortunately I did not recieve an invitation to Hot chips despite this. I assume it must have gotten lost in the mail somewhere.<br /><br />Oh well, let's look at some more numbers instead.<br /><br /></p><ul style="text-align: left;"><li>A number of optimizations was found over the year which, depending on the measure, further shrank the core 5-10%.<br /><br /></li><li>The number of supported FPGA boards for the <a href="https://github.com/olofk/serv/blob/master/servant.core">servant SoC</a> grew from 4 to 17, mostly thanks to other contributors (thanks everyone, love you all!)<br /> </li><li>The SERV support for the Zephyr operating system was rewritten and upgraded from the aging Zephyr 1.13 to 2.4, the latest version at the time of writing.<br /></li></ul><p style="text-align: left;"></p><p style="text-align: left;"></p><p style="text-align: left;"></p><p style="text-align: left;"><br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhs-iPFDPJgHRvwmUmEuu1MHvLUZ6W38db-xdu6hb6EzcxjLKN4uIsL5d4ssxZofLmRwyfSw16RmIyluUb54Gxc4rIARDxS6w0oxE5qyf1D1SXZKIqIxqkTQs14rkc4jWovg0l_LUBjnKE/s1440/serv_resources_210215.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="750" data-original-width="1440" height="334" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhs-iPFDPJgHRvwmUmEuu1MHvLUZ6W38db-xdu6hb6EzcxjLKN4uIsL5d4ssxZofLmRwyfSw16RmIyluUb54Gxc4rIARDxS6w0oxE5qyf1D1SXZKIqIxqkTQs14rkc4jWovg0l_LUBjnKE/w640-h334/serv_resources_210215.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">SERV resource usage over time on a Lattice iCE40 FPGA<br /></td></tr></tbody></table><br /> <p></p><p style="text-align: left;">Coming back to CoreScore, the results right now range from 10 cores on a smaller Lattice iCE40 device up to <a href="https://twitter.com/OlofKindgren/status/1265170129911980032">5087 cores</a> on a large Xilinx device and the high score table can even be <a href="https://corescore.store">viewed interactively online</a>! If you can't find your favorite board there, just send a PR and we'll get it added. And if any people with access to crazy large FPGAs happen to read this, please get in touch with me. I'm very curious to see who will be first to get above 10000 cores.<br /><br />SERV also saw another great improvement in the form of <a href="https://serv.readthedocs.io/en/latest/">documentation</a>. While not completely there yet, the functionality of most SERV modules have been documented together with detailed schematics showing the implementation down the individual gates, muxes and flip-flops. And most changes to the source are now accompanied by a code comment to clarify what is going on. Since SERV is optimized for size rather than readability, many parts of the core are difficult to figure out by just looking at the source code. Hopefully this will make it easier for other who want to understand or work on the core, but frankly it has also been very useful for me since I tend to forget why I did things in a certain way so I have had to spend a lot of time following my own tracks.</p><p style="text-align: left;"></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><img border="0" data-original-height="389" data-original-width="978" height="254" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwCAsKIe6d8kZ9DcouN4MOCalSSRKrc2QePqQKcWZQclnN97g6gorFrc6io8GfYOb6c9O-s2rEV9nAMW9_0pA4jlQAgsZEfI9sRSwt0zYyZn6h1ccjkI8RtqQF7fAqGDizNHFo5JZTChY/w640-h254/serv_ctrl_int.png" style="margin-left: auto; margin-right: auto;" width="640" /></td></tr><tr><td class="tr-caption" style="text-align: center;">Schematic of the SERV control unit from the SERV documentation<br /></td></tr></tbody></table><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwCAsKIe6d8kZ9DcouN4MOCalSSRKrc2QePqQKcWZQclnN97g6gorFrc6io8GfYOb6c9O-s2rEV9nAMW9_0pA4jlQAgsZEfI9sRSwt0zYyZn6h1ccjkI8RtqQF7fAqGDizNHFo5JZTChY/s978/serv_ctrl_int.png" style="margin-left: 1em; margin-right: 1em;"><br /></a></div><p></p><h2 style="text-align: left;">FuseSoC<br /></h2><p style="text-align: left;">The oldest of my open source silicon project still going strong is <a href="https://github.com/olofk/fusesoc">FuseSoC</a>. It is now about to turn ten years old and keeps growing in features and users for each year. Looking back at the changes through 2020 I can see some new trends in the development. The most important one is that for the first year ever, most of the work was not done by me. During 2020, my fellow FOSSi Foundation director and LowRISC employee Philipp Wagner has been pulling the heaviest load of FuseSoC development. And with Philipp came quality. Dr. Wagner has improved FuseSoC in pretty much every aspect. Bugs have been fixed and features has been added. The development experience has been improved by CI testing, automatic code formatting checks and improved testing coverage. And what makes me happiest is that the user experience has been improved not least by a total <a href="http://fusesoc.readthedocs.io/">rewrite of the documentation</a> into something that is actually useful and can be proudly shown to the world. All this is very much needed as FuseSoC is becoming increasingly popular. It has already been picked up by many of the flagship open source silicon projects like <a href="https://opentitan.org/">OpenTitan</a>, <a href="https://github.com/chipsalliance/Cores-SweRVolf">SweRVolf</a>, <a href="https://parallel.princeton.edu/openpiton/">OpenPiton</a> and with the <a href="https://university.imgtec.com/rvfpga/">RVFPGA</a> university programme there will soon be a whole new generation who will get familiar with it as well.<br /></p><h2 style="text-align: left;">Edalize</h2><p style="text-align: left;">In 2018, the part of FuseSoC that interacted with the EDA tools was spun off into <a href="https://github.com/olofk/edalize">Edalize</a>. The reason was that it was believed this part could be useful for others who weren't interested in the whole FuseSoC package. This prediction seems to have been correct and Edalize has very much started a life on its own by now. In addition to FuseSoC, Edalize is now used by several other projects such as <a href="https://github.com/sylefeb/Silice">Silice</a>, <a href="https://clash-lang.org/">Clash</a> and <a href="https://github.com/SymbiFlow/fpga-tool-perf">fpga-perf-tool</a> and over the year Edalize has gained support for 7 new EDA tool flows, bringing the total number up to 25.<br /><br />2020 was also the year when Edalize had it's first taste of being in the spotlight on its own merits. For the <a href="https://woset-workshop.github.io/">Workshop on Open-Source EDA Technology (WOSET) 2020</a> I decided to submit a presentation about Edalize. Being an academic conference this also prompted me to write an accompanying paper as is the common courtesy for these kind of events. <a href="https://woset-workshop.github.io/PDFs/2020/a20.pdf">The paper</a> received a lukewarm response but was accepted anyway. Once again I did not feel like reciting slides to a camera so I turned back to my new-found interest in advanced multimedia productions. And it paid off. <a href="https://www.youtube.com/watch?v=HuRtkpZqB34">The Edalize video</a> won an award for <a href="https://woset-workshop.github.io/WOSET2020.html#best-video">best video at WOSET 2020</a>. Well done Edalize!<br /><br /></p><h2 style="text-align: left;">LED to Believe</h2><p style="text-align: left;">All of the above projects use FuseSoC and Edalize because - well it's kind of why I created FuseSoC in the first place - to easily reuse components and retarget to different devices. But I also realized there was a need for a dead simple project to help people getting started with FuseSoC - the Hello world of silicon, so to speak. And the Hello World of silicon is of course the blinking LED. So in 2018 I created project LED to Believe with the ambitious goal to create FuseSoC-powered LED blinkers for every FPGA board ever made. The project has several aspects that are useful in different ways. It serves as a very simple introduction to FuseSoC and how to make a design that targets multiple hardware. It is also an excellent pipe cleaner for when you receive a new board. If you can run the project successfully and get the LED to blink, it likely means you have managed to install all the EDA tools correctly which is no small feat, and you also have a template to take on bigger projects. And it's also fun to see what boards are available out there. While I have submitted a bunch of the board ports myself, the vast majority have come from all the fantastic contributors out there. And during 2020 the number of supported boards grew from 16 to 44. Perhaps not all the FPGA boards ever made, but a considerable chunk of them. And already in the short amount of 2021 that has passed, there have been numerous more contributions so we're getting closer all the time.<br /><br /><br /><br />In closing, 2020 was a busy year FOSSi-wise. And this has just touched upon the surface of all things that have been happening during the year. And just as we were about to close the books on 2020, I was informed that Lattice had incorporated one of my FOSSi projects into their shiny new award-winning Propel design suite. Which project, you might ask? Was it the similarly award-winning FuseSoC, to give Lattice users immediate access to a rich ecosystem of Open IP cores? Or was it the Rosetta stone of Edalize, with its award-winning video, that would easily provide a coherent interface for a dozen simulators and make it easy to switch between Lattice's multitude of FPGA tools such as Diamond, icecube2 and Radiant? Or was it SERV itself, the award-winning CPU capable of offering a RISC-V experience for all but their absolutely smallest offerings? Well, actually, none of the above. It turns out that Propel now contains ipyxact, my somewhat feature-limited Python library for working with IP-XACT files. Not my first choice, but fair enough. I wonder if they have read <a href="https://olofkindgren.blogspot.com/2016/11/ip-xact-good-bad-and-outright-madness.html">my somewhat complicated relationship with IP-XACT</a>.<br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgb9dkzuwrijU86hmvjjmhTOlyvvcf8DF2AEXpFiE8e3nG62iQA0FnLLedQAZZfZ-twlTxWSQw8CmH8iktbfhAVJv06PGq3FQP-ezogFbwlttgO3LZE36MU3B5Ys13brNTU-v1mjCes1fQ/s768/propel.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="257" data-original-width="768" height="134" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgb9dkzuwrijU86hmvjjmhTOlyvvcf8DF2AEXpFiE8e3nG62iQA0FnLLedQAZZfZ-twlTxWSQw8CmH8iktbfhAVJv06PGq3FQP-ezogFbwlttgO3LZE36MU3B5Ys13brNTU-v1mjCes1fQ/w400-h134/propel.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Finally my work is recognized by big EDA vendors (picture by Gatecat)<br /></td></tr></tbody></table><br /> <p></p><br /><br />Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-13839757490687386162019-12-10T13:20:00.013-08:002021-02-17T13:31:39.281-08:002019 : A year of RISC-V and Open source silicon<p><i>Note: This article was originally posted on LinkedIn in December 2019 and was later posted on this blog with a backdated publishing date</i><br /></p><p>I will unfortunately not make it to the RISC-V summit this year, but
since everyone will be talking about RISC-V this coming week I thought
it would be a good opportunity to highlight some of the work I have done
this year within RISC-V and FOSSi (Free and open source silicon) in
general. And you are more than welcome to contact me if you are
interested in knowing more about any of this work or other things
related to RISC-V, FOSSi or Qamcom</p><h2 style="text-align: left;">SweRVolf</h2><p>Western Digital made a big splash last year when
they announced the release of the open source RISC-V CPU SweRV EH1,
currently the fastest 32-bit RISC-V CPU available. Together with Western
Digital I have created SwerRVolf, an open source portable and
extendible SoC using the SweRV EH1. The intention with this SoC is to
allow users interested in SweRV to quickly get started running software
or building their own customized SoC using SweRV. The whole project is
open source and can be run in a simulator or on supported FPGA targets.
On the software side it can be used to run Zephyr OS and has debugging
support. The code is available at <a href="https://github.com/chipsalliance/Cores-SweRVolf" rel="nofollow noopener" target="_blank">https://github.com/chipsalliance/Cores-SweRVolf</a>
More features will come in 2020 so make sure to check in regularily.
The project has also been featured in presentations at the inagural
CHIPS Alliance workshop as well as the CHIPS Alliance tools November
workshop in Munich. During the latter there was also a tutorial aimed to
get people started using the SoC. This workshop is also freely
available and I'm happy to do variations on this within your company if
you want to get started with a RISC-V SoC.</p><h2>SERV</h2><p>In case you're not aware, I have created SERV, likely
the world's smallest RISC-V CPU and still cabable of running Zephyr OS.
SERV was originally created for the 2018 RISC-V SoftCPU contest, but I
have kept working on the core during 2019. In April I submitted a
presentation for the RISC-V workshop in Zürich called "Bit by bit - how
to fit 8 RISC-V cores on a $38 FPGA board". When there was time to do
the actual presentation I had to update the title since further
optimizations had allowed me to fit 16 cores on the same board. Work
continued after that and in November I was able to fit 53 RISC-V cores
on a $30 FPGA board. The SERV CPU is of course open source and available
here <a href="https://github.com/olofk/serv" rel="nofollow noopener" target="_blank">https://github.com/olofk/serv</a> If you want to learn how to build SERV into your designs and why you should do it, just reach out and I'll get you up to speed.</p><h2>FuseSoC</h2><p>FuseSoC is a package manager for IP cores. It is
created to manage and describe collections of open source and
proprietary cores so that they can be put together to make a SoC.
FuseSoC has been around for eight years now, but the past year has seen a
lot of improvements and a massive growth of available IP cores (over
500 cores!) to use with FuseSoC. This year it has also been adopted by
some major Open source silicon projects such as the manycore OpenPiton
project from from Princeton and OpenTitan, the industry collaboration
project to create a fully open source Root of Trust device. Even though
there are a large number of RISC-V based projects using FuseSoC it is
used in many places as well, most notably this year is perhaps the open
source POWER implementation called MicroWatt released this summer. If
you want help with packaging your RISC-V core to be available for
FuseSoC users or if you want to use FuseSoC within your company to
manage your IP cores, just let me know. FuseSoC can be found here <a href="https://github.com/olofk/fusesoc" rel="nofollow noopener" target="_blank">https://github.com/olofk/fusesoc</a></p><h2>Edalize</h2><p>Closely related to FuseSoC is Edalize, which
originally was part of FuseSoC but now a project of its own. Edalize is a
build tool abstraction which provides a common interface to the
supported EDA tools. It can be used to e.g. target different simulators
with a flick of a switch or easily run the same design on FPGA and
simulation targets. This year has seen many improvements and support for
three new tool flows, which brings up the number of supported tools to
17. Most of this work has been done by contributors, which is a great
indicator that it is actively used by many people. See more here <a href="https://github.com/olofk/edalize" rel="nofollow noopener" target="_blank">https://github.com/olofk/edalize</a>
If you're a user or a tool vendor and feel that your favorite tool is
missing, just let me know and we can discuss how to add it.</p><h2>Observer</h2><p>By combining the flexibility of FuseSoC with the
resource efficiency of SERV I created a project called Observer.
Observer is a software-programmable sensor aggregation platform for
heterogenous sensors, combining the best of HW and SW in an FPGA. It is
built on the idea that FPGAs are excellent for communicating with
various types of external devices, but many types of data processing are
best done in software. By pairing a SERV CPU to each sensor it is
possible to combine the speed of RTL with the flexibility of software to
easily build a sensor fusion system. The project is still in early
stages, but works on a supported FPGA platform already and as a proof of
concept it has been shown possible to collect data from over 50
different sensors simultaneously, each with their dedicated RISC-V CPU
to handle data. Code can be found here <a href="https://github.com/olofk/observer" rel="nofollow noopener" target="_blank">https://github.com/olofk/observer</a> If you want to customize Observer for your particular use case I'm happy to talk more.</p><h2>Qamcom joins RISC-V Foundation</h2><p>This year Qamcom joined the
RISC-V Foundation. As our first exercise upon joing the foundation, we
teamed up with RISC-V veterans SiFive to host the SiFive Tech Symposium
in Stockholm in May. At this event we highlighted how we see that RISC-V
can benefit many of the areas where we provide expert knowledge, such
as AI, automotive, RADAR and 5G. If you are interested in what services
Qamcom can provide within these areas and other, feel free to contact me
or any of my colleagues or read more about us on <a href="https://www.qamcom.se" rel="nofollow noopener" target="_blank">https://www.qamcom.se</a>/</p><h2>Qamcom joins CHIPS Alliance</h2><p>RISC-V is getting a lot of
attention, but an open source ISA is just one of the many challenges we
are facing when it comes to innovating chip design. We see an increasing
need for custom silicon for many of our clients and partners and there
are many keys to unlock to achieve this. CHIPS Alliance is an important
consortium with a combination of small and large forward-thinking
companies that aims to make open source silicon viable by collaborating
on common cores, tools and infrastructure. If you want to be part of the
CHIPS Alliance to accelerate chip design, go to <a href="https://chipsalliance.org" rel="nofollow noopener" target="_blank">https://chipsalliance.org</a>/ to learn more.</p><h2>Qamcom joins Mentor OpenDoor</h2><p>Mentor, a Siemens business, has a
partner program called OpenDoor. Both Mentor and Qamcom sees the
importance of high quality verification of open source silicon and by
joining this program, we will ensure that the work we do within open
source silicon has first-class support for Mentor's EDA tools to allow
new and existing users of these tools to quickly get started using open
source IP cores in their products.</p><h2>FOSSi Foundation</h2><p>In 2015 I co-founded the <a href="https://fossi-foundation.org/" rel="nofollow noopener" target="_blank">FOSSi Foundation</a>
with a mission to promote and assist open source silicon in the
industry, academia and for hobbyists. FOSSi Foundation consists of many
people who work across all levels to acheive these goals but my personal
involvement this year has mostly focused on creating events to bring
people from industry, academia and hobbyists together under a single
roof to exchange experiences. As usual we had <a href="https://orconf.org" rel="nofollow noopener" target="_blank">ORConf</a> in Europe but we also teamed up with the RISC-V Foundation to create the Week of Open Source Hardware (<a href="http://fossi-foundation.org/wosh" rel="nofollow noopener" target="_blank">WOSH</a>)
in Zürich conjoined with the RISC-V workshop there. During the event I
presented SERV, a poster of FuseSoC and won an award for FuseSoC given
by Eurolab4HPC. This was also the year when we did our first conference
on US soil. In May we held a new event called <a href="http://latchup.io" rel="nofollow noopener" target="_blank">Latch-Up</a>
in Portland, Oregeon which was a great sucesss. We are already planning
for three events next year as well. First up is FOSSiStanbul in
Istanbul, Turkey, followed by a new Latch-Up in Cambridge, MA and the
usual ORConf some time in the fall. Check out
https://fossi-foundation.org/events to see where you should book your
tickets.</p><p>Apart from events I was also mentor for Google Summer of
Code for the fourth year in a row. This year I co-mentored Nancy Chauhan
who worked with FOSSi Foundation and did a fantastic job to improve our
CI platform at ci.librecores.org</p><h2>Other stuff</h2><p>I
have had a long and troubling relationship with IP-XACT, as can be seen
in <a href="https://olofkindgren.blogspot.com/2016/11/ip-xact-good-bad-and-outright-madness.html">my most cited article</a>
. I still stand by my point that we need some sort of standard for
describing many of the aspects of IP cores that FuseSoC doesn't care
about such as register maps and how to connect cores to each other. I
haven't done much work in this area for a long time, but a presentation
at Latch-Up by Aliaksei Chapyzhenka on a project called <a href="https://github.com/sifive/duh" rel="nofollow noopener" target="_blank">DuH</a>
prompted me to resume my efforts and I have now started working on
combined IP-XACT/Duh tooling that I hope will be of interest. It's of
course open source as well, but I haven't cleaned up enough to release
it yet :) If you are an IP-XACT user or interested in tooling in this
area, please let me know.</p><p>Wow! This turned out far longer than I
expected. Seem I did a lot of stuff around RISC-V and Open source
silicon in 2019. Let's see what the next decade will bring</p><p>Catch up at Latch-Up!</p>
<p> </p><p> </p><p> </p><p> </p><p> </p>Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-68988121160669182182018-06-26T15:24:00.000-07:002020-08-19T01:37:56.992-07:00FuseSoC 1.8.2FuseSoC 1.9 will have an impact so great that people will divide history into the eras before and after it's release. But before that happens, it's time for a less earth-shattering minor release. Allow me to introduce FuseSoC 1.8.2<br />
<h4>
Backend separation</h4>
The biggest feature is also the least visible for most users. A lot of time since the last release was spent on moving stuff around with the ultimate goal of splitting out the backends (the part that create project files and launches EDA tools) to a separate library. This is now complete and the former backend code now lives in a separate library called edalize, which remains part of FuseSoC for now, but will be moved out at some point. The ideas behind this will be a topic for a separate article at some point, but if you're building some Python tool that wants to use the EDA tool wrappers, look for edalize now.<br />
<h4>
Linter backends</h4>
<span style="font-weight: normal;">FuseSoC.. sorry, Edalize has gained a new backend for Synopsys SpyGlass which is a powerful linter tool. For a less costly linter, it is now possible also to use the linter mode of Verilator by setting mode to lint-only in the verilator section of the tool options in a target like this</span><br />
<br />
<pre style="background: #fff; color: black;">targets:
lint:
tools:
verilator:
<span style="color: #00a33f;">mode: <span style="color: #00a33f;">lint-only</span></span>
</pre>
<br />
<h4>
CAPI2 changes </h4>
The latest core description format has had some minor improvements. The top-level option was originally specified as a list of modules. since there are cases when several top-modules are needed. This however is quite rare, which makes it confusing that it's just a list of one item in most cases. Therefore it can now also be specified as a string. Small improvement, but makes things less annoying. Environment variables are also expanded in file names.<br />
<br />
<h4>
Other changes</h4>
Sometimes you really want to ignore a core that's part of a library. By adding a file called FUSESOC_IGNORE to a directory, FuseSoC will ignore that directory and everything below it. There is also a series of tutorials in the works. These are very rough drafts at this point, but I encourage everyone who wants to get started with FuseSoC to take a look through them anyway. They are located <a href="https://github.com/olofk/fusesoc/tree/master/doc/tutorials">here</a><br />
<br />
That's pretty much it. As usual, a number of bugs were fixed but nothing worth taking up more of your precious time. Thank you for reading. See you again in the post FuseSoC 1.9 eraOlof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-32821077823702071262018-03-22T01:43:00.001-07:002020-08-19T01:38:05.360-07:00FuseSoC 1.8.1With great features come great bugs. FuseSoC 1.8 had a lot of new functionality but it also has some shortcomings. Some of it was intentional. For both the library support and CAPI2 I wanted to push out an early version with the most important functionality, test the waters and add the missing pieces later. (Un)fortunately both these features turned out to be really really good and I came to depend on them immediately. This made it more important to make sure they were useful as I don't want to use the old ways anymore. After some post-release patching I'd say things are in much better shape, so it made sense to do a new release with these things fixed. Therefore I present FuseSoC 1.8.1. It's like 1.8, just a little better.<br />
<br />
What's changed then?<br />
<br />
<h3>
Library fixes</h3>
The library sections in fusesoc.conf has gained a sync-type flag. This allows users to explictly set what mechanism to use for synchronizing libraries against a remote source (e.g. updating). The only two current values are <i>git</i>, which does a git pull of the library when running fusesoc update, and <i>local</i>, which won't try to synchronize at all. The library sync-type options share code with the core providers, so it should be easy to add other synchronization mechanisms (e.g. rsync, webdav, mercurial) when needed. When adding a new library there is also now a --global flag. If this is present, the library will be added to the user-global fusesoc.conf in $XDG_CONFIG_HOME/fusesoc. Otherwise, a fusesoc.conf in the current workspace directory will be used.<br />
<br />
<h3>
CAPI2 fixes</h3>
CAPI2 debuted with support for just a few tools. This was a trade-off to be able to do a quick release. Of course, it soon became apparent that the other tools were needed as well. One other thing that bothered me with CAPI2 was that the tools sections were a hard-coded list in the core class. So to fix both these things at the same time I did some refactoring and let the backends themselves declare which options they use. FuseSoC will then search for available backends at run time and pick up their available tool options. Voilà, all tools are now supported in CAPI2. This also opens up for more easily adding new tool backends without having to change anything else in the code base.<br />
<br />
There are more things missing in CAPI2, but the one that I realized was needed most was the equivalent of the scripts section in CAPI1. I took the opportunity to rearrange things slightly so that I could make this more powerful than in CAPI1. Instead of a list of shell scripts to run, it is now possible to launch arbitrary commands and associate extra files to be exported to the work root and environment variables to be set.<br />
<br />
<h3>
Other fixes</h3>
Other noteworthy things that are added to FuseSoC 1.8.1 is a bash completion script that was contributed almost four years ago but never merged. This was polished up by another contributor and is now available in the extras directory of the FuseSoC repo. It is not installed by default, but has to be copied into the appropriate directory (e.g. /etc/bash_completion.d on my system).<br />
<br />
Finally, FuseSoC no longer writes a fusesoc.log by default. Writing this logfile on every run has annoyed me for almost six years now, but I never got around to fix it. Thankfully there are other contributors who get things done. <br />
<br />
And that's all. Hope you like it!Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-46566246100363258682018-02-05T05:42:00.000-08:002018-02-05T05:42:24.166-08:00FuseSoC 1.8Too tired to write something clever here. Just get it over with. Stuff has changed. Here's what's new<br />
<br />
<h3>
CAPI2</h3>
The main feature of FuseSoC 1.8 is the support for a new core description format, CAPI2, to replace the old CAPI1 format. The need for a new format to solve support some use cases has been apparent for a while. Doing some archaeology I found a <a href="https://github.com/olofk/fusesoc/commit/cc3e1ac201b3366e397e7e46a85c2696d40fe010">commit from March 2, 2013</a> that mentions the next generation format, and yes, after careful evalutation of a few different formats it ended up being based on YAML. Oh well, things take time and there have been other priorities. At least it's here now, or rather, a first experimental version. The CAPI2 support in FuseSoC 1.8 still has many missing features, like documentation and support for IP-XACT and all tools to name a few. There might also be non-compatible changes ahead, but I want to push it out now together with some CAPI2 cores to reach a wider audience.<br />
<br />
So what's so good about CAPI2? I'm hoping to find the time to write a separate article with more details some time in the future, but I have written down some of the benefits.<br />
<br />
<h4>
New tool flows</h4>
Support for other tool types than simulators and synthesis tools. This includes things like formal verification tools and linters. For linting, I have already made a quick PoC using <a href="https://www.veripool.org/wiki/verilator">Verilator</a> in lint mode and there is a <a href="https://www.synopsys.com/verification/static-and-formal-verification/spyglass.html">Spyglass</a> backend in the works. On the formal verification side, I will start to look into what's need to add support for <a href="http://www.clifford.at/papers/2016/yosys-smtbmc/">Yosys-SMTBMC</a> <b> </b><br />
<br />
<h4>
<b>Multiple targets</b></h4>
With the support for new flows for a design there is also a need to decide which flow to use. For this, CAPI2 supports multiple targets in a single core file. There are many uses for different targets. A design might have several testbenches that exercises different parts of the design. These can be specified as different targets using different source files, run time parameters, tool options etc. Some designs have support for targeting multiple FPGA boards. These can also be described as separate targets, with the benefit that they can share all the common parts while freely add target-specific files and options. Targets for linting or formal verification can be separate targets as well<b>.</b><br />
<br />
<h4>
Conditional expressions</h4>
CAPI2 contains a minimal expression parser inspired by the Gentoo ebuild format. An expression can look something like this<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;">flag? (use_if_flag_is_true)
!flag? (use_if_flag_is_false)
</pre>
</div>
<br />
This allows including or excluding features depending on which tool is being used or whether the core is at the root of the dependency hierarchy or being used as a dependency for another core. Examples of this can be to enable technology-specific RTL primitives for certain tools, switch between VPI or DPI extensions depending on tool support or use a C++ testbench for verilator while other simulators use a non-synthesisable verilog version. At the time of writing, these flags are defined internally in FuseSoC depending on current tool, target and some other parameters, but it will be possible in the near future for users to define their own flags and set them in the top-level core file or on the command-line.<br />
<br />
<h3>
Core libraries</h3>
FuseSoC already has the ability to define directory paths which contain core files, either by specifying them with the cores_root option in fusesoc.conf, on the command-line with --cores-root= or through the FUSESOC_CORES environment variable. This is all good, but a bit limited. With FuseSoC 1.8 comes support for core libraries. Each library is specified in fusesoc.conf as a separate section. An equivalent of an old config file looking like this<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #0000aa;">[main]</span>
<span style="color: dodgerblue;">cores_root</span> = <span style="color: #aa5500;">/home/user/.local/share/fusesoc/orpsoc-cores /home/user/cores/fusesoc-cores</span>
</pre>
</div>
<br />
<br />
will now look like this<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #0000aa;">[library.orpsoc-cores]</span>
<span style="color: #0000aa;">[library.fusesoc-cores]</span>
<span style="color: dodgerblue;">location</span> = <span style="color: #aa5500;">/home/user/cores/fusesoc-cores</span>
</pre>
</div>
<br />
So far there isn't much of an improvement over the old style. One thing to notice is that if the location option is missing, it will default to $XDG_DATA_HOME/fusesoc/<library name><br />
<br />
Having separate sections however also allow us to do the following<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #0000aa;">[library.orpsoc-cores]</span>
<span style="color: dodgerblue;">sync-uri</span> = <span style="color: #aa5500;">https://github.com/openrisc/orpsoc-cores</span>
<span style="color: #0000aa;">[library.fusesoc-cores]</span>
<span style="color: dodgerblue;">location</span> = <span style="color: #aa5500;">/home/user/cores/fusesoc-cores</span>
<span style="color: dodgerblue;">sync-uri</span> = <span style="color: #aa5500;">https://github.com/fusesoc/fusesoc-cores</span>
<span style="color: dodgerblue;">auto-sync</span> = <span style="color: #aa5500;">false</span>
</pre>
</div>
<br />
sync-uri lets us to specify the remote source of a library. The initial supported remote location are git repositories, but other source such as mercurial, rsync, webdav etc will be support with a sync-type option in the future. The auto-sync option, which defaults to true, controls if the library shall be updated when running<span style="font-family: monospace;"> fusesoc update.</span>The update command can also take a list of libraries as extra argument to selectively update libraries.<br />
<br />
To support library management from the command-line, FuseSoC has now gained a new library subcommand. The only supported library command is currently add, to register a new library, but additional commands for listing and removing libraries will be added in time. To add a remote library, the following commands can be used<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;">fusesoc add library enigma https://github.com/mmicko/enigmaFPGA
</pre>
</div>
<br />
The resulting fusesoc.conf will look like this<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #0000aa;">[library.orpsoc-cores]</span>
<span style="color: dodgerblue;">sync-uri</span> = <span style="color: #aa5500;">https://github.com/openrisc/orpsoc-cores</span>
<span style="color: #0000aa;">[library.fusesoc-cores]</span>
<span style="color: dodgerblue;">location</span> = <span style="color: #aa5500;">/home/user/cores/fusesoc-cores</span>
<span style="color: dodgerblue;">sync-uri</span> = <span style="color: #aa5500;">https://github.com/fusesoc/fusesoc-cores</span>
<span style="color: dodgerblue;">auto-sync</span> = <span style="color: #aa5500;">false</span>
<span style="color: #0000aa;">[library.enigma]</span>
<span style="color: dodgerblue;">sync-uri</span> = <span style="color: #aa5500;">https://github.com/mmicko/enigmaFPGA </span>
</pre>
</div>
<br />
<br />
There are also optional arguments --location and
--no-auto-sync to explicitly set the location and auto-sync = false<br />
<br />
For adding a directory path as a library, the same command is used, but the sync-uri is treated as a location if FuseSoC detects that it's an existing directory<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;">$ fusesoc library add more_cores ~/other_cores
INFO: Detecting /home/user/other_cores as a local library
</pre>
</div>
<br />
will produce<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #0000aa;">[library.orpsoc-cores]</span>
<span style="color: dodgerblue;">sync-uri</span> = <span style="color: #aa5500;">https://github.com/openrisc/orpsoc-cores</span>
<span style="color: #0000aa;">[library.fusesoc-cores]</span>
<span style="color: dodgerblue;">location</span> = <span style="color: #aa5500;">/home/user/cores/fusesoc-cores</span>
<span style="color: dodgerblue;">sync-uri</span> = <span style="color: #aa5500;">https://github.com/fusesoc/fusesoc-cores</span>
<span style="color: dodgerblue;">auto-sync</span> = <span style="color: #aa5500;">false</span>
<span style="color: #0000aa;">[library.enigma]</span>
<span style="color: dodgerblue;">sync-uri</span> = <span style="color: #aa5500;">https://github.com/mmicko/enigmaFPGA </span>
<span style="color: #0000aa;">[library.more_cores]</span>
<span style="color: dodgerblue;">location</span> = <span style="color: #aa5500;">/home/user/other_cores</span>
</pre>
</div>
<br />
There are more planned featues for core libraries, but this will have to do for today.<br />
<br />
<h3>
Backend features</h3>
<br />
Most of the tool backends have received fixes or new features. All tools now supports file type = user for passing arbitrary files to the build tree that might be neeeded by the tools. For Xilinx ISE, FuseSoC now supports BMM files as an allowed file type and quoting of verilog string parameters should now work. Isim will shut down properly after simulations, GHDL will receive its arguments in the correct order and XSim supports multiple top-levels. The IceStorm backend now supports verilog defines specified as command-line parameters, has gotten a yosys_synth_options parameters to set extra synthesis options and PCF constraint files are recognized as a file type<br />
<br />
<h3>
Other things </h3>
Other things worth mentioning are the new --no-export feature. Before an EDA tool is invoked, FuseSoC has always created a fresh build tree where it places all files and runs the EDA tools to avoid polluting the source directories with files and to not pick up unwanted files that might be lying around in the source trees. This also has the added benefit that the exported build tree is not dependent on FuseSoC and can be archived or sent to non-FuseSoC users if required. I have used that myself to make deliveries of projects to clients. There are however cases where this is not optimal, for example during debugging, when there is a need to make small changes to a file in the source tree without having to recreate the build tree every time. For such use-cases FuseSoC now supports a --no-export option that will reference the original source files instead of copying them to the build tree. For most cases, this should work just as fine, but beware that it might break in some situations, e.g. when multiple cores has an include file with the same name.<br />
<br />
Another improvement related to coping files around is a new copyto attribute for files in filesets. It's used like this:<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #0000aa;">[fileset fs]</span>
<span style="color: dodgerblue;">files</span> = <span style="color: #aa5500;">an/old/file.v[copyto=a/new/name.v]</span>
</pre>
</div>
<br />
or with CAPI2, like this
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #ffffff; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;">filesets:
fs:
files:
- an/old/file.v: {<span style="color: #aa0000;">copyto</span> : <span style="color: #aa0000;">a/new/name.v</span>}
</pre>
</div>
<br />
This will copy the file to a new location, relative to the work root of the EDA tool and reference this version in the EDA API file. This is quite useful in several situations, for example when a file is required to exist in the working directory. Previously this had to be done with a pre_build_script to copy the file, which also had the disadvantage of being platform-specific. It also makes it less awkward to reference files from the source directory in verilog parameters. For example the top-level of the de0_nano system in orpsoc-cores contain <i>bootrom_file = "../src/de0_nano_0/sw/spi_uimage_loader.vh"</i>, which a) assumes source code tree is located in ../src and b) has to be updated on version bumps when the de0_nano_0 name will change. This can now be replaced with <i>bootrom_file = spi_uimage_loader.vh</i> and a <i>copyto = spi_uimage_loader.vh</i> in the .core file. Much better!<br />
<br />
EDA API - the tool-agnostic file format which is used to pass all information needed by the backends such as the list of files to read and tool options - has seen some changes and will continue to do so in the future. For this reason, it has gained a version field so that external projects which want to read EDA API files will know what to expect in the file. Properly formalizing the EDA API is still a task at hand, but is getting more prioritized now as there are external projects interested in using this format so that they can reuse either the FuseSoC core files and dependency handler or the EDA tool wrappers. This means it's pretty rude to make arbitrary changes to the format without at least informing about it.<br />
<br />
There are also some new commands and switches for the FuseSoC 1.8 release. Before CAPI2 you would either <i>build</i> an FPGA image or <i>sim</i> a simulation. Wiht the sight set on new tool types, none of these commands really describe what you do when you run an linter. So there is now a command called <i>run</i>. Going forward, this will be the main command to use when launching EDA tools through FuseSoC. The run command currently has switches for setting the desired target and tool, and can run any of the tree stages <i>setup, build and run</i>. Without any stages being explicitly set it will run them all. The tool can also be derived from the core description in many cases. build and sim will remain as special cases of run for the time being. <i>sim</i> will be the equivalent of <i>run --target=sim</i> and <i>build</i> will evaluate to <i>run --target=sim --setup --build</i>. The build command has also gained --tool and --target switches for overriding the default options. As for new switches, it is now possible to explicitly point out a FuseSoC config file to use with the --config option<br />
<br />
That's all folks. Hope you like it. Please try it out and send me patches, bug reports or perfumed letters if you find anything you like or want to see improved.<br />
<br />
See you later, Verilator<br />
In a while, SynplifyOlof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-21634785703290558792017-11-22T01:32:00.000-08:002020-08-19T01:38:37.503-07:00Resetting reset handlingI will make a bold statement. You are probably doing your reset wrong in your RTL code. Yep, that's right. There are of course plenty of ways to resetting things the wrong way. Asynchronous vs synchronous is one example. Active high or active low is another.<br />
<br />
But that's not why we're here today. Instead I will talk about a bad coding style that is so prevalent that I feel it needs some mentioning. Consider the following verilog code of a component that is most likely pretty worthless in practice, but will serve well as our example<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #f8f8f8; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #aa22ff; font-weight: bold;">module</span> rst_all
(<span style="color: #aa22ff; font-weight: bold;">input</span> clk,
<span style="color: #aa22ff; font-weight: bold;">input</span> rst,
<span style="color: #aa22ff; font-weight: bold;">input</span> valid_i,
<span style="color: #aa22ff; font-weight: bold;">input</span> [<span style="color: #666666;">3:0</span>] data_i,
<span style="color: #aa22ff; font-weight: bold;">output</span> <span style="color: #00bb00; font-weight: bold;">reg</span> valid_o,
<span style="color: #aa22ff; font-weight: bold;">output</span> <span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">3:0</span>] data_o);
<span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">2:0</span>] count;
<span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">3:0</span>] data_r;
<span style="color: #aa22ff; font-weight: bold;">always</span> @(<span style="color: #aa22ff; font-weight: bold;">posedge</span> clk) <span style="color: #aa22ff; font-weight: bold;">begin</span>
<span style="color: #aa22ff; font-weight: bold;">if</span> (rst) <span style="color: #aa22ff; font-weight: bold;">begin</span>
data_o <span style="color: #666666;"><=</span> <span style="color: #666666;">4'd0</span>;
data_r <span style="color: #666666;"><=</span> <span style="color: #666666;">4'd0</span>;
valid_o <span style="color: #666666;"><=</span> <span style="color: #666666;">1'b0</span>;
count <span style="color: #666666;"><=</span> <span style="color: #666666;">3'd0</span>;
<span style="color: #aa22ff; font-weight: bold;">end</span> <span style="color: #aa22ff; font-weight: bold;">else</span> <span style="color: #aa22ff; font-weight: bold;">begin</span>
<span style="color: #aa22ff; font-weight: bold;">if</span> (valid_i)
count <span style="color: #666666;"><=</span> count <span style="color: #666666;">+</span> <span style="color: #666666;">1</span>;
data_r <span style="color: #666666;"><=</span> data_i;
data_o <span style="color: #666666;"><=</span> data_r <span style="color: #666666;">+</span> count;
valid_o <span style="color: #666666;"><=</span> valid_i;
<span style="color: #aa22ff; font-weight: bold;">end</span>
<span style="color: #aa22ff; font-weight: bold;">end</span>
<span style="color: #aa22ff; font-weight: bold;">endmodule</span>
</pre>
</div>
<br />
<br />
All our registers are being reset, as can be seen in the following screenshot from the elaborated code in Vivado.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCW1HdmETdGiN79Pu78_WTXTFjTlc_mODtpuFxhcmz1jtkV-T1PbE-QX9vpjvT0vBcq_tpDxb5lEOsF4lx5FwWNJMGGXvA0GXTd5v1zJrKLOenjMxl2l5-xSwf3JiuvSUh-2_I0DrmUzY/s1600/rst_all.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="434" data-original-width="1090" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCW1HdmETdGiN79Pu78_WTXTFjTlc_mODtpuFxhcmz1jtkV-T1PbE-QX9vpjvT0vBcq_tpDxb5lEOsF4lx5FwWNJMGGXvA0GXTd5v1zJrKLOenjMxl2l5-xSwf3JiuvSUh-2_I0DrmUzY/s1600/rst_all.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br />
<br />
<br />
Now, as good RTL designers we want to minimize the load on the reset network, so we start looking for things that don't really need to be reset. Both data_o and data_r are unnecessary to reset if we only look at the data when valid_o is asserted. Let's remove them and try again<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #f8f8f8; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #aa22ff; font-weight: bold;">module</span> rst_bad
(<span style="color: #aa22ff; font-weight: bold;">input</span> clk,
<span style="color: #aa22ff; font-weight: bold;">input</span> rst,
<span style="color: #aa22ff; font-weight: bold;">input</span> valid_i,
<span style="color: #aa22ff; font-weight: bold;">input</span> [<span style="color: #666666;">3:0</span>] data_i,
<span style="color: #aa22ff; font-weight: bold;">output</span> <span style="color: #00bb00; font-weight: bold;">reg</span> valid_o,
<span style="color: #aa22ff; font-weight: bold;">output</span> <span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">3:0</span>] data_o);
<span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">2:0</span>] count;
<span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">3:0</span>] data_r;
<span style="color: #aa22ff; font-weight: bold;">always</span> @(<span style="color: #aa22ff; font-weight: bold;">posedge</span> clk) <span style="color: #aa22ff; font-weight: bold;">begin</span>
<span style="color: #aa22ff; font-weight: bold;">if</span> (rst) <span style="color: #aa22ff; font-weight: bold;">begin</span>
<span style="color: #008800; font-style: italic;">//data_o <= 4'd0;</span>
<span style="color: #008800; font-style: italic;">//data_r <= 4'd0;</span>
valid_o <span style="color: #666666;"><=</span> <span style="color: #666666;">1'b0</span>;
count <span style="color: #666666;"><=</span> <span style="color: #666666;">3'd0</span>;
<span style="color: #aa22ff; font-weight: bold;">end</span> <span style="color: #aa22ff; font-weight: bold;">else</span> <span style="color: #aa22ff; font-weight: bold;">begin</span>
<span style="color: #aa22ff; font-weight: bold;">if</span> (valid_i)
count <span style="color: #666666;"><=</span> count <span style="color: #666666;">+</span> <span style="color: #666666;">1</span>;
data_r <span style="color: #666666;"><=</span> data_i;
data_o <span style="color: #666666;"><=</span> data_r <span style="color: #666666;">+</span> count;
valid_o <span style="color: #666666;"><=</span> valid_i;
<span style="color: #aa22ff; font-weight: bold;">end</span>
<span style="color: #aa22ff; font-weight: bold;">end</span>
<span style="color: #aa22ff; font-weight: bold;">endmodule</span>
</pre>
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijyML1y50F4K7KRZAfc5uiqSUEGZyBLBwzXrrlOK3qzYvkioyttHN7tRN5Mt-eeH7GdTU93EOqGSJvYsjGDHiyp14KHrSnFun8f8b4D6F4JV0MQYWaCbc_O29KdUOHg0hl5YIi9irbdSg/s1600/rst_bad.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="465" data-original-width="1100" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijyML1y50F4K7KRZAfc5uiqSUEGZyBLBwzXrrlOK3qzYvkioyttHN7tRN5Mt-eeH7GdTU93EOqGSJvYsjGDHiyp14KHrSnFun8f8b4D6F4JV0MQYWaCbc_O29KdUOHg0hl5YIi9irbdSg/s1600/rst_bad.png" /></a></div>
<br />
<br />
Whoa.. what just happened The reset inputs are gone, but we suddenly have two new muxes in the design and clock enable pins on the flip flops. And what's worse, we still have the same load on the reset net. How is this possible?!?! Well, the thing is that we haven't specified what to do with the data_r and data_o signals when rst is low. Therefore, according to verilog rules (the same thing applies to VHDL designs too), we must <b>keep</b> the old value. This is most likely not what we wanted to do. Still, I see this design pattern all the time, and no one is warning about it. What should we do then? One way is to replicate the assignments to data_r and data_o also in the reset section, but that's pretty awkward. The real solution is much simpler, but will probably cause heart attacks among conservative RTL designers.<br />
<br />
We put the reset handling at the end of the process. Oh yes, I just did! And no one can stop me! It looks like this by the way<br />
<br />
<!-- HTML generated using hilite.me --><br />
<div style="background: #f8f8f8; border-width: 0.1em 0.1em 0.1em 0.8em; border: solid gray; overflow: auto; padding: 0.2em 0.6em; width: auto;">
<pre style="line-height: 125%; margin: 0;"><span style="color: #aa22ff; font-weight: bold;">module</span> rst_good
(<span style="color: #aa22ff; font-weight: bold;">input</span> clk,
<span style="color: #aa22ff; font-weight: bold;">input</span> rst,
<span style="color: #aa22ff; font-weight: bold;">input</span> valid_i,
<span style="color: #aa22ff; font-weight: bold;">input</span> [<span style="color: #666666;">3:0</span>] data_i,
<span style="color: #aa22ff; font-weight: bold;">output</span> <span style="color: #00bb00; font-weight: bold;">reg</span> valid_o,
<span style="color: #aa22ff; font-weight: bold;">output</span> <span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">3:0</span>] data_o);
<span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">2:0</span>] count;
<span style="color: #00bb00; font-weight: bold;">reg</span> [<span style="color: #666666;">3:0</span>] data_r;
<span style="color: #aa22ff; font-weight: bold;">always</span> @(<span style="color: #aa22ff; font-weight: bold;">posedge</span> clk) <span style="color: #aa22ff; font-weight: bold;">begin</span>
<span style="color: #aa22ff; font-weight: bold;">begin</span>
<span style="color: #aa22ff; font-weight: bold;">if</span> (valid_i)
count <span style="color: #666666;"><=</span> count <span style="color: #666666;">+</span> <span style="color: #666666;">1</span>;
data_r <span style="color: #666666;"><=</span> data_i;
data_o <span style="color: #666666;"><=</span> data_r <span style="color: #666666;">+</span> count;
valid_o <span style="color: #666666;"><=</span> valid_i;
<span style="color: #aa22ff; font-weight: bold;">end</span>
<span style="color: #aa22ff; font-weight: bold;">if</span> (rst) <span style="color: #aa22ff; font-weight: bold;">begin</span>
<span style="color: #008800; font-style: italic;">//data_o <= 4'd0;</span>
<span style="color: #008800; font-style: italic;">//data_r <= 4'd0;</span>
valid_o <span style="color: #666666;"><=</span> <span style="color: #666666;">1'b0</span>;
count <span style="color: #666666;"><=</span> <span style="color: #666666;">3'd0</span>;
<span style="color: #aa22ff; font-weight: bold;">end</span>
<span style="color: #aa22ff; font-weight: bold;">end</span>
<span style="color: #aa22ff; font-weight: bold;">endmodule</span>
</pre>
</div>
<br />
and the generated design looks like this.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgboS1zcWvN8PxNLMzvCX4nlrnlYeV-YtKtAqfDzdFiEEH0nJ-c23gNvB0nhfQYyzmvb1z_JwreQS3VZ2l4PPNNZ31AtdxJWgcL4zSRjFZ7ZTlMHYNGzwy2QfusdoFyLIt2EhBQkvUJfYI/s1600/rst_good.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="391" data-original-width="1095" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgboS1zcWvN8PxNLMzvCX4nlrnlYeV-YtKtAqfDzdFiEEH0nJ-c23gNvB0nhfQYyzmvb1z_JwreQS3VZ2l4PPNNZ31AtdxJWgcL4zSRjFZ7ZTlMHYNGzwy2QfusdoFyLIt2EhBQkvUJfYI/s1600/rst_good.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<br />
Problem solved!<br />
<br />
A few additional notes: <br />
<ol>
<li>I have put together a FuseSoC core with the source and some notes on how to simulate and build the designs mentioned here in a <a href="https://github.com/olofk/reset_test">git repo</a></li>
<li>This was an example with synchronous resets, but the same thing is true for asynchronous. </li>
<li>I have no idea why Vivado chooses to instantiate the muxes however, as it could just use the CE port directly. Other tools do that. My guess is that CE maybe is always active high, and the mux serves as an inverter.</li>
<li>If you only target FPGA and the reset is just a power-on-reset, you don't need to reset at all. Just provide an init value if you must. Don't be afraid. It works, and will save some load on your reset net. </li>
<li>There are many many more things to say about resets. But we stop here for today </li>
</ol>
Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com7tag:blogger.com,1999:blog-9056950471187689945.post-31210322834606141372017-08-30T05:53:00.000-07:002017-08-30T05:53:04.316-07:00Happy sixth birthday FuseSoCToday FuseSoC is turning six years old. That is probably something like 35 in software years. It has had a colourful past with some breakups and an identity crisis, but has now settled down and realized that it will not change the world in the same way that it used to think. It has spawned a <a href="https://github.com/openrisc/orpsoc-cores">few</a> <a href="https://github.com/fusesoc/fusesoc-cores">child</a> <a href="https://github.com/olofk/ipyxact">projects</a> which are not yet able to handle themselves in the world and still need their loving parent project. Being 35 also means that we can expect a FuseSoC middle-age crisis in a few years where it will try to reinvent itself in a desperate attempt to appear youthful. All in all, it's pretty similar to it's author.<br />
<br />
As with most software, there is no birth certificate, but we will use the date of the first commit to the repo of what would become FuseSoC as the birth date. So what really happened on that fateful day that would become forever etched into history as the day when everything changed? According to <a href="https://en.wikipedia.org/wiki/Portal:Current_events/2011_August_30">Wikipedia</a>, it wasn't a happy day overall, but none of those events are really related to FuseSoC.<br /><br />
As so often, we need to go back further in time and take a look at the events leading up to this day. It all started with the OpenRISC Reference Platform System on Chip version 2, or ORPSoCv2. This project was a combination of RTL code for the OpenRISC CPU together with a bunch of peripheral controller cores, drivers, example applications and miles of makefiles to build everything together into FPGA images that could be loaded onto a few select boards for running OpenRISC-based systems. Despite having one of the least sexy names ever, it was widely used by most people who dealt with OpenRISC and seems to still be in use by some people. But it wasn't without flaws. Due to the tightly integrated nature of the project, everyone who wanted to add support for a new FPGA board or add some extra peripheral driver ended up with their own version of the project, each with their own bugs and features. Fixes were rarely submitted back upstream to the main ORPSoCv2 repo. Also, the RTL code for the CPU and peripheral controllers were copies of other repositories, which quickly started to diverge from their upstream counterparts. Again, none of that code was submitted upstream. There were also other issues with regards to scalability that started to show when more features were added. In short, it was time for something new.<br />
<br />
I started sketching out what I would like to see in a successor, and then started implementing ORPSoCv3. Just like ORPSoCv2 this was a system of makefiles calling into other makefiles, but with a major difference. Instead of storing copies of cores, the upstream versions were fetched when they were requested in a SoC to avoid all the code duplication. After some time, I was ready to present my work in progress to the world. At that time I was working for the company that owned and maintained OpenCores. The git hype had already started to sweep through the software landscape and I had been trying to convince my co-workers that we needed to start making OpenCores support git instead of just SVN. I never managed to convince them, but at least I got them to set up a git server where I could put my project as a trial. Except for three or four outdated clones of other OpenRISC-related projects, I had the only git repo at the now defunct git.opencores.org. On August 30 20111 I made the first commit.<br />
<br />
The better part of the coming year was spent on writing makefiles calling other makefile until one day I had enough and decided that I will never in my life write another makefile calling other makefiles. It was time to kill my darling. I started a new implementation in Python with the lessons learned and soon got to a state where I wanted to present it to the world. As I only had this one git repo and no real understanding of git work flows, my instinct was to clean out the old repo and just push the new code in. Unfortunately I never figured out how to get rid of the first commit, which resulted in this sequence of commits:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaqR85WBfQ6RqUzkLiSXlkNsygyjwlYHdj4cK7erh24YJVzwbpbWZUEx9IXl5T2GjqQ0ZDy-7waAkI6XzUp77UaM6dOjouzMV7IZm2jOgqhLqlopWc-l9ZQbneWgGVYuOYrdfQefmY5nw/s1600/firstcommits.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="109" data-original-width="746" height="92" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaqR85WBfQ6RqUzkLiSXlkNsygyjwlYHdj4cK7erh24YJVzwbpbWZUEx9IXl5T2GjqQ0ZDy-7waAkI6XzUp77UaM6dOjouzMV7IZm2jOgqhLqlopWc-l9ZQbneWgGVYuOYrdfQefmY5nw/s640/firstcommits.png" width="640" /></a></div>
<br />
<br />
<br />
Even after the Python migration, FuseSoC (or ORPSoCv3 really) was still storing a lot of RTL code in the repo. It was a shaky relationship, and in August 2013 there was an inevitable separation of tool and RTL code. The RTL code went into a new project called <a href="https://github.com/openrisc/orpsoc-cores">orpsoc-cores</a>. There wasn't any crying involved an both parties realized that it was best to go separate ways. A day later, the first released version, ORPSoC 3.0 was released.<br />
<br />
Life went on, new features were added, bugs were fixed, ORPSoCv3 became older and fatter, but it became more and more evident that ORPSoC really didn't have anything to do with OpenRISC. Everything that was OpenRISC-specific had already moved to the orpsoc-cores repository and ORPSoCv3 was really a dependency manager and build system for any RTL code. It was once again time to cut some ties. As usual, names are harder than code, and I spent some time trying to figure out what to call the thing I had created. One of the main alternatives was SoCify, but it turned out someone else had already used that name. In hindsight, I'm really grateful for that. SoCify as it is a horrible name. The idea of FuseSoC came from the analogy of fusion reactions to build something bigger from a number of smaller cores. The minimalist in me also considered FuSoC, which is also pretty bad and sounds a bit like F*** you SoC. I do like FuseSoC though. In February 2014 the big rename was made, the project was moved to its <a href="https://github.com/olofk/fusesoc">current location</a> and FuseSoC 1.0 was released.<br />
<br />
Since then not much has happened. New features are added. Bugs are fixed, reintroduced and fixed again. FuseSoC is getting older and fatter. I'm really grateful for all help that I have received over the years. According to github, there have been 20 contributors to the code base, but there are also a number of other people who have submitted bugs or contributed to the RTL code in the standard core library. Big thanks to everyone involved.<br />
<br />
Birthdays usually involve presents. But what can we give to a project that already has everything? How about a logo and a home page? That's the perfect gift for a six year old and on this big day I can proudly announce the brand new <a href="http://fusesoc.net/">home page</a> (Ssshhh...I have had the domain name since 2014, but don't tell FuseSoC) and the FuseSoC logo.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigbmNkPmOh28srqK2Z-Hgqe48zye66tgfS2DdEUV9QMfO_zZK8ersloSPBodBNXmiVfO-9qZ8Ubv3s0kJs-8_YwuKnva6nG9jtlgCu5Lz7T8MGpIy6UtJdHnFx0Ew3KhE5dugf8RtptNA/s1600/logo4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1035" data-original-width="1035" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigbmNkPmOh28srqK2Z-Hgqe48zye66tgfS2DdEUV9QMfO_zZK8ersloSPBodBNXmiVfO-9qZ8Ubv3s0kJs-8_YwuKnva6nG9jtlgCu5Lz7T8MGpIy6UtJdHnFx0Ew3KhE5dugf8RtptNA/s320/logo4.png" width="320" /></a></div>
<br />
Happy birthday FuseSoC! I will now leave the word to the millions of users to tell their stories of how FuseSoC has changed their lives.Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-47608592964595899282017-08-21T00:28:00.001-07:002017-08-21T03:24:21.701-07:00OSDDI: Director's commentaries<div dir="ltr">
Andrew Back of <a href="http://abopen.com/">AB Open</a> and <a href="http://fossi-foundation.org/">FOSSi Foundation</a> has been working on this great series of interviews called <a href="http://abopen.com/blog/category/osddi/">Open Source Digital Design Insights</a>, in which he has been interviewing some of the great minds of the Free and Open Source Silicon movement (+ me). In the fourth episode the turn has come to me. As I watch the video myself, I realize how quickly time moves in the open source silicon world and how many things that have happened since then. I would therefore like to take the opportunity to add some more context as an addendum to the interview.</div>
<div dir="ltr">
The interview was made at <a href="https://orconf.org/">ORConf</a> <a href="https://orconf.org/2015/">2015</a>, the same day as we publicly announced the <a href="http://fossi-foundation.org/">Free and Open Source Silicon Foundation</a>. We had been working on this for a year and it was a great feeling to present our ambitions to the world. The first thing that strikes during this interview is that we hadn't yet embraced the Open Source Silicon epithet ourselves and were still referring to our work as Open Source Hardware.</div>
<div dir="ltr">
Another major theme that can use some more explanation is to role of the <a href="http://openrisc.io/">OpenRISC</a> project nowadays. I would believe that most people coming in contact with open source silicon at this time will do so through the <a href="http://riscv.org/">RISC-V</a> project. When I started out, the RISC-V project was not yet born and OpenRISC was just about to become a teenager. OpenRISC wasn't the only free ISA around at the time. Most notably there were also free implementations of SPARC (both the LEON and the Sun T1/T2) and Lattice Mico 32 (lm32). OpenRISC was likely the most widely used architecture however and is still used in some critical infrastructure, which I'm unfortunately not allowed to speak freely of. Despite being widely used, the OpenRISC ISA hasn't been without faults, and already in 2011, we started work on a successor to the OpenRISC 1000 ISA, called OpenRISC 2000. Some of the things we wanted to fix was removal of the branch delay slots, better support for wider instruction lengths, instruction compression, more modular instruction set, revised memory model and other things. Unfortunately, we never got around to implement any of that, as we were a small group and there was barely enough manpower to do all the necessary work on or1k. Turns out, we never needed to, because a year or two after that, RISC-V came along and did all those things that we had planned for or2k - and more. In that regard, we see RISC-V as the spiritual successor to OpenRISC and we are happy to pass the dutch to RISC-V for future free thinking ISA development.</div>
<div dir="ltr">
So what's the deal with OpenRISC in 2017? Well, it's not seeing as many design starts as it used to do since most new designs are based on RISC-V. My guess is that the ones who make new designs based on OpenRISC do it because they either already have a working OpenRISC environment and have no need to replace that, or because they know that it's a stable code base that has been ASIC-proven numerous times for more than a decade. On the software side we are still pushing to upstream some of the last bits of the toolchains, notably GDB and GCC. There are also some updates and clarifications to the specification, mostly related to the ABI.</div>
<div dir="ltr">
I believe that the greatest legacy of OpenRISC will not be the ISA, but the idea and realization of a free and open source silicon ecosystem. A CPU isn't very useful by itself and much of what came out of the OpenRISC project was IP cores, such as peripheral controllers and a lot of support software. For example, the i2c and ethernet drivers for the controllers that came out from the OpenRISC project has been in the Linux kernel since 2006, which is seven years before the OpenRISC CPU support was added to the kernel. Some of the debug infrastructure that originated from OpenRISC is widely used in RISC-V-based designs. The FOSSi Foundation was born from a group of OpenRISC developers who saw the need for a vendor-independent group to foster the open source silicon ecosystem, regardless of which ISA is currently in vogue. ORConf was originally the OpenRISC conference. We have considered renaming it, but we like the name so we just have to find a good backronym (the best proposal is still Olof's Rock'n'roll Conference). Even <a href="https://github.com/olofk/fusesoc">FuseSoC</a> was born as a tool to make it easier to build OpenRISC-based SoCs, and for the first year or two it was still called ORPSoCv3 (OpenRISC Reference Platform System on Chip version 3)</div>
<div dir="ltr">
Enough said about OpenRISC. I think the most amazing aspect of the interview is that I did not mention <a href="https://github.com/olofk/fusesoc">FuseSoC</a> even once. Nope. Not a single mention of <a href="https://github.com/olofk/fusesoc">FuseSoC</a> in over 8 minutes! And if you think I look a bit like a zombie sloth on heroin in the interview, that's because I usually spend the months leading up to ORConf as Sonic the Hedgehog on amphetamine, so once everyone is seated and the conference starts, that's when I start to relax. It's a lot of work to organize a conference, but I absolutely love doing it and I hope that you will come to visit and enjoy as well. And if you haven't seen the other entries in the OSDDI series, please watch them now. They really are insights in the world of open source silicon from some of the most knowledgeable people in the field (+me).</div>
<div dir="ltr">
<a href="https://github.com/olofk/fusesoc">FuseSoC</a>!</div>
Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-71835250130610040702017-08-12T15:16:00.000-07:002020-08-19T01:38:45.616-07:00FuseSoC 1.7Lock up your wifes and daughters! FuseSoC 1.7 has been unleashed on the world. This unstoppable force will organize your HDL dependencies and provide abstractions to your EDA tools without giving you a chance to defend yourself.<br />
<br />
Actually, there's not that much new on the surface of this release. Most of the work has been spent on internal refactoring in order to bring in two new major features for the next cycle. The first of these is a separation of the frontend - which handles reading core files, maintains the core database and does dependency resolution - and the backends - which launch the EDA tools. There are several reasons for doing this, but I hope to write more about this specifically in another post. The other major feature is the preparation for a new core description format, called CAPI2. This will be added early in the FuseSoC 1.8 cycle, so expect to read more about this in the future as well. If you are interested in taking an early peek, there's a CAPI2 branch of FuseSoC together with corresponding branch of <a href="https://github.com/fusesoc/fusesoc-cores">fusesoc-cores</a> which is used as a playground for now.<br />
<br />
So, onto the actual changes.<br />
<br />
Test coverage has now reached 72% of the code base. Unit testing is something I should had done from day one, as it has uncovered plenty of bugs and been a huge help when doing refactoring. So kids, get tested you too!<br />
<br />
Failure is always an option, and should be handled with the same loving care as success. FuseSoC now exits with an error code when a build or simulation fails, making it easier for external tools to pick up failures. Also, failing scripts now print out the error code on failures to make it easier to analyze what went wrong. Speaking of things going wrong, the parsing of the core files have been made improved to warn for syntax errors instead of leaving the user with a Python stack trace. In general, there has also been many improvements to the logging, so that running with the --verbose option might actually be helpful when debugging strange errors.<br />
<br />
There have been a number of improvements in the tool backends, mostly related to parameter passing. The Vivado backend had a bug that prevented passing multiple parameters to the backend. Quartus now supports passing verilog defines on the command-line. Parameters are properly escaped before being passed to the backend, which fixes string parameters for some backends. Other than that, ISIM now supports multiple toplevels, which is required for example when simulating Xilinx primitives that require glbl.v as a parallel toplevel. The Vivado flow now works on Windows after discovering that Vivado prefer forward regardless of what the OS uses as path separator. The Icarus backend has been rewritten so that it's easier to rebuild the simulation model from an exported build tree.<br />
<br />
In addition to fixes and new features, a few features have been removed. Mostly because they made no sense, were broken or turned out to be hard to maintain with little gain. The system-info command is removed, as all details are shown in core-info anyway. The submodule provider was likely broken for a long time without anyone complaining, and was a bad fit for the FuseSoC depedency model, so it has been removed too. There was also a semi-working feature of the verilator backend that aimed to convert files containing verilog `define statements to a correspondent C header file. As there might be users out there actually using this, I added an entry to the <a href="https://github.com/olofk/fusesoc/blob/master/doc/migrations.adoc">FuseSoC migration guide</a> with information on how to replicate this functionality in newer versions of FuseSoC.<br />
<br />
Other than that, there are some other bug fixes, like FuseSoC now supports putting IP-XACT files in subdirectories of the core tree. There is also a --version command-line option to show, surprise, the current version of FuseSoC.<br />
<br />
That's more or less it. Make sure to upgrade and get prepared for the wild ride that will be FuseSoC 1.8<br />
<br />
Peace out!Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0tag:blogger.com,1999:blog-9056950471187689945.post-79352329719157323622017-03-21T14:54:00.006-07:002020-08-19T01:38:51.889-07:00FuseSoC 1.6.1This is just a quick one. I was asked by fellow <a href="https://fossi-foundation.org/">FOSSi Foundation</a> founder and <a href="http://www.optimsoc.org/">OpTiMSoC</a> creator and lead architect Stefan Wallentowitz to do a point release. OpTiMSoC is currently shipping a forked version of FuseSoC, and while doing some spring cleaning they wanted to see if the upstream version could be used instead. As there has recently been some problems with the FuseSoC dependencies, originally caused by python's sorry excuse for a package manager called pip, this was also a good time to put out a new version. So here it is. Not much changed on the surface, but there has been some refactoring and preparation that is needed for the upcoming CAPI2 core format, which eventually will supersede the current format for .core files. If you have any thoughts about what the new format should look like, please check out the current <a href="https://github.com/olofk/fusesoc/wiki/CAPI2">CAPI2 draft</a>, and yell if something needs to change. Other than that, the most noteworthy addition is that FuseSoC now comes with unit tests. Not sure I like them though. The first thing that happened is that they pointed out a bunch of bugs that I didn't know about. Oh well. I'll get those fixed eventually. That's all. Have fun with the <a href="https://pypi.python.org/pypi/fusesoc/1.6.1">new release</a>!Olof Kindgrenhttp://www.blogger.com/profile/18093695559193556551noreply@blogger.com0