Synflow – Guest Bloggerhttps://www10.edacafe.com/blogs/guest
Just another EDA Blogs weblogWed, 31 May 2017 05:58:46 +0000en-UShourly1https://wordpress.org/?v=4.79656901A young entrepreneur’s take on EDAhttps://www10.edacafe.com/blogs/guest/2014/02/20/a-young-entrepreneurs-take-on-eda/
https://www10.edacafe.com/blogs/guest/2014/02/20/a-young-entrepreneurs-take-on-eda/#respondThu, 20 Feb 2014 16:35:53 +0000http://www10.edacafe.com/blogs/guest/?p=206You’ve all read many times the opinions of EDA veterans concerning this industry, so for a change I’ll humor you with my opinion as a young entrepreneur and EDA company founder. This post originally appeared on my company’s official blog (see original post). What prompted me to write this piece is Gabe’s article on Starting A New EDA Company.

In his post, Gabe is hoping for “disruption” and “a new business model”, yet he notes the “total lack of new ideas from younger people”. Hmm. Well I’m young, and I certainly do think that younger people have lots of ideas, and that they’re actually having a huge success, it’s just that it’s happening in other industries, like, for instance, the software industry. I’m talking about the Facebook, Twitter, Instagram, Snapchat, and whatnot. Now why is that? Why are young people having success in software but not so much in semiconductor? Could it be that there is something specific about the semiconductor industry? After all, until its recent acquisition by Cadence, Forte was still called a start-up. After 16 years (it was founded in 1998). And VCs seem to agree that the money is elsewhere. So what is it?

It turns out that to create a “new successful EDA company”, you should “understand thoroughly the application industry [your company] serves”. Ok, but how is it possible for young people to do that exactly? The semiconductor industry today is mainly about designing SoCs, and that requires many different skills and companies and people working together. It takes years to become proficient in designing quality hardware with RTL, and this is only the first step to making a chip! Then you need to learn about verification (and SystemC, and SystemVerilog, and UVM, and equivalence checking, and I don’t know what else, after all I’m not a verification engineer!), and back-end, and DFT, etc. How are you supposed to thoroughly understand all this without 10 or 15 years of experience?

Maybe this explains that. I have the impression that the semiconductor industry has kind of an “old” feeling attached to it, as if the hardware industry were lagging behind the software industry. Remember when all you had was proprietary software products that were incompatible with each other? This is EDA today. Where else do you need an NDA to read a datasheet or a tool’s documentation? Where else are you forbidden to compare competing products? Sad but true: for example if you read Xilinx’s license, you will see in section 4. Restrictions, sub-section (b) General Restrictions, the following: “Licensee is not licensed to, and agrees not to: (iii) publish or disclose the results of any benchmarking of the Software”. Cadence goes further in its website’s terms of use: “Any postings to chat rooms, forums, message boards, contests, or similar information you submit, as well as any computer code, bug fix, or other creative idea you provide, shall be deemed, and shall remain, the property of Cadence“.

This kind of attitude is part of the problem. Let’s take another example. Most EDA software use the same licensing program, the well-known FlexLM. That stuff is 26 years old. Surely by now you’d imagine we would have a better solution? Well there are alternatives. So why does EDA keep using this one? Is it because this industry is a conservative triumvirate? Is it because these three are just too big? But being a behemoth has never prevented innovation! Agreed, it does make it more difficult, because of the innovator’s dilemma, but many bigger companies still manage to innovate a lot. Google’s revenue for 2013 is about $60 billion, that’s respectively around 30, 40, and 60 times the revenue of Synopsys, Cadence, and Mentor Graphics. If being big does not prevent innovation, what else could?

I think this is a cultural problem. We have a kind of chicken and egg problem, with users who have become afraid of change (including new EDA software) because change has all too often caused problems, and with companies that do not change things because they fear this is is going to cause problems or to make users angry. And in the end, users are the ones who give you money, so you try to listen to them. That’s actually fine, as long as you keep in mind that only a small percentage of users are actually innovators and early adopters, and these are the ones willing to change first; if you convince them, you have a much better chance of convincing the others (more or less easily, see Crossing the Chasm, and the post I wrote about this Are you pre-chasm?). This is a distinctive trait of the semiconductor industry in my opinion: we seem to hear the late majority (to quote the original research, “older and fairly conservative”) voice its opinion much more than one would otherwise expect.

Despite all that, though, I love writing EDA software for all hardware designers who are open to the possibility of improving their design flow. It makes me pretty happy when I meet or talk with them And of course I love designing hardware with the Cx language that we created!

]]>https://www10.edacafe.com/blogs/guest/2014/02/20/a-young-entrepreneurs-take-on-eda/feed/0206Human-readable RTL code generationhttps://www10.edacafe.com/blogs/guest/2013/10/10/rtl-code-generation/
https://www10.edacafe.com/blogs/guest/2013/10/10/rtl-code-generation/#respondThu, 10 Oct 2013 15:59:47 +0000http://www10.edacafe.com/blogs/guest/?p=123Every now and then I meet somebody (compiler writers most of the time, but not only) who believes that generating human-readable RTL code is worthless. They claim that nobody should need to look at generated code, among other things because they should just trust the compiler, like software engineers do. It is time to examine the facts.

1. The majority of the hardware engineers that we’ve met with Synflow want to be able to understand the generated RTL, because they want to be able to reuse, verify, optimize or modify the generated code themselves. This includes people from big companies such as STMicroelectronics, Samsung, Renesas, ARM, as well as medium enterprises like Thomson Video Networks, RivieraWaves, ScaleoChip. Although this is only a subset of all hardware designers and semiconductor companies, I think we can consider it a reasonably representative sample. As a matter of fact, the rest of designers may not care whether the generated code is human-readable, but no designer has ever told us that he or she would prefer incomprehensible code, or even worse a netlist. Actually, that is probably because…

2. RTL is a de facto standard for IP cores. Like it or not, unless you are buying IP cores for FPGAs, in which case you can (but don’t have to) get a netlist, virtually every IP is available as RTL. In other words, forget it if your tool generates netlist. Now RTL might be low-level like assembly is low-level, but the comparison goes no further. Target-specific assembly languages are untyped, and have a well-defined syntax and semantics, whereas the languages in which cores are written (VHDL and Verilog) can be used in wildly different ways. So much that EDA tool vendors had to define coding styles that you must respect if you want the tool to do something useful out of your code. If your tool generates spaghetti code that is too low-level and does not respect a good coding style, linters (that check code will synthesize well) and synthesizers alike will print a ton of warnings. Is that really what you want your customers to see when they use your IP?

3. RTL is not assembly. First of all, hardware and software are different. When you write software, the source code is where things happen, and what you spend most time reading/writing. From time to time you may need to look at assembly, and write some for optimization purposes, and that’s it. In hardware, either (1) you write RTL yourself (so it is the source code), or (2) you generate it from a higher-level language like Cx or with HLS. Assembly is the last step in the source code to binary instructions path, whereas RTL is at the beginning of the source code to transistor path, which includes synthesis, P&R, and other steps further down the design flow. Virtually no tool in software will reference the assembly, but in hardware any information that is given to you by back-end tools references the RTL. Good luck if tools identify a problem in the generated RTL and it is not human-readable!

4. Synthesizing RTL to efficient hardware is hard. So much that synthesizers were once the leading products of the large EDA companies. Even now, an EDA company called Oasys Design Systems has come up with a new “chip synthesis” that optimizes at the RTL rather than at the gate level, and combines synthesis and P&R to reduce the whole process to hours instead of days. Translating assembly to binary is absolutely straightforward compared to that The fact that there are still new companies innovating in RTL synthesis should be a strong indication that it makes much more sense to generate synthesis-friendly RTL than to synthesize it yourself. After all, as Oasys says in their whitepaper:

ESL tools all have an extremely coarse view of implementation trade-offs.

So there you have it, the main reasons why Synflow Studio generates human-readable, target-agnostic RTL

]]>https://www10.edacafe.com/blogs/guest/2013/10/10/rtl-code-generation/feed/0123Bitcoin mining IP core with Synflow Studiohttps://www10.edacafe.com/blogs/guest/2013/09/15/bitcoin-mining-ip-core-with-synflow-studio/
https://www10.edacafe.com/blogs/guest/2013/09/15/bitcoin-mining-ip-core-with-synflow-studio/#respondSun, 15 Sep 2013 15:48:37 +0000http://www10.edacafe.com/blogs/guest/?p=103To design an ASIC Bitcoin miner, the first thing you will need is a Bitcoin IP core, a piece of silicon that performs a double SHA-256 (if the previous sentence is Klingon to you, I’d advise you to read the gentle introduction to Bitcoin mining). You can buy a SHA-256 IP from numerous IP vendors on the net, you can also find one free of charge on OpenCores. Or you can design one yourself. If you are aware of what’s wrong with RTL, or you know that High-Level Synthesis might not help you much, or you are an innovator, and/or simply you just want to see what Synflow Studio can do, keep reading!

First, you can take a look at the videos in this post or on our YouTube channel, where I show how to get started with Synflow Studio, create the main loop of SHA-256, and complete and test the IP. You can read the C~ code (as well as the VHDL and Java code generated by Synflow Studio) on our Github repository, where the IP is under MIT license. Keep in mind that at this point (commit 5f5f25131a…) I have only written a behavioral description of the IP, which mainly consists of a straightforward implementation, kind of a copy-paste from the FIPS 180-4 standard. My implementation only hashes one block, and currently its performance is limited:

The IP is not pipelined, so it spends 64 cycles to compute W, but this could be done in parallel to the main loop.

The ‘K’ constant array should be moved to its own task to ensure proper inference as a synchronous ROM. Doing so will require scheduling the reads of ‘K’ one cycle in advance, because a synchronous ROM by definition has a 1-cycle latency.

The ‘W’ array should be implemented as a RAM rather than as a register-based array. Doing so will require additional registers: the computation of W[t] is dependent on four values, W[t – 2], W[t – 7], W[t – 15], W[t – 16], but we can only do one read per cycle.

Finally, we’ll need to extend the implementation to handle multi-block messages, but this should be trivial.