Comment by nickpsecurity | Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

Parent Full thread

Chisel is a nice toolkit that proved itself in the Rocket processor. One of the more unusual uses of it was Chisel-Q for quantum computing:

http://www.cs.berkeley.edu/~kubitron/papers/qarc/pdf/Chisel-...

Chisel is pretty well-known in academic, hardware community. So, here's a few that you might have not heard of.

Caisson - language-based security meets HDL http://www.cs.ucsb.edu/~chong/papers/109-Caisson-pldi.pdf

SHard - a scheme to hardware compiler http://scheme2006.cs.uchicago.edu/05-saint-mleux.pdf

Cx-Lang - A statically-typed, c-like, HLL for hardware http://cx-lang.org/

Note: I'd love for some people familiar with ASIC or FPGA design to check out Cx-Lang to see if it's good for beginners getting results on FPGA's. The I.P. they sell is so cheap that it's either (a) crap or (b) the result of a productive, synthesis tool (Cx). Just like to know if it's a decent HLS tool compared to FPGA or EDA company offerings. Additional advantage that it's open so it can be reviewed for subversion if one is willing to invest the effort.

Just took at look at the cx-lang website. I think it may be too weird for a beginner looking for results. I've been in ASIC & FPGA engineering for 15+ years. The design flow I think they use is more like writing a program that gets translated into hardware. Very different from the regular methodology. Sounds great but there's a big leap between that and getting your FPGA working. For a beginner, it's too much to take on.

I think maybe Chisel and those others would be easier.

Yeah, I was actually hoping it was a high-level synthesis tool. I appreciate your review on the ease-of-use aspect.

I think it is a high level synthesis tool like a SystemC etc.

My concern for a beginner would be how to get your high level design integrated into the FPGA. For a beginner, there are a lot of what-ifs that they are probably going to stumble on.

Chisel is not high level synthesis, which is one of the reasons why I love it. You are actually describing the circuit itself, with is what a hardware description language is supposed to do. While describing the function of a circuit like MyHDL and many other languages have tried to do it cute, they have never come close to a real engineer thinking of how to solve the problem with registers and combinational logic directly.

You have it completely backwards. The best "real engineers" do not "think directly" on how to solve the problem with registers and combinational logic. They think about how to solve the problem functionally and let synthesis take care of the logic as much as possible. MyHDL is ideal for that.

That is how ASICs/FPGAs have been designed by the best teams for the last 2 decades. And it is much more productive than the textual schematic entry you are describing. There is simply no comparison. Synthesis works.

As for your word-playing attempt: "description" stands for a number of things, among those "describing behavior". Just check the Verilog/VHDL LRM or MyHDL manual.

Exactly. It's crazy to even think, outside of analog, that someone would want to build a modern SOC with RTL directly. Even the full-custom folks like Intel, correct me if I'm wrong, essentially use a hardware approach where they can abstract away from and use EDA to synthesize to the stuff they hand-craft. Most SOC builders simply don't have the labor to waste working at RTL for a complex design & its inevitable problems. It's why they pay so much to the Big Three for synthesis tools.

For software people following, it would be like trying to build Microsoft Word with assembler while competition was using C/C++.

Note: Chuck Moore of Forth fame may be the exception to this rule in SOC design. Then again, he's an exception to a lot of them. ;)

http://www.ultratechnology.com/okad.htm

It depends on the project.

For SOCs that I was involved with (DSPs, mobile phone SOC, wifi SOC), you are bringing together a lot of different IP from various sources. There's no way to use these HLS tools unless the third parties feel like writing a model for their IP in your choice of HLS tool language. This means you would have gaps in your HL design everywhere their stuff fits in. Verification in the high level language would be tough work until those gaps are filled.

No doubt guys like Intel can use the fancy HLS tools on their SOC because they own every module in the design. Same goes for the RISCV stuff: They can run Chisel sims because they wrote every part of the design in Chisel.

The rest of us idiots are doing straight Verilog RTL because SOC level is more about gluing a lot of different modules together with low level logic. Maybe there's a tool here or there that generates a little Verilog from some other language for you but that is very piecemeal.

It really is like building Word with assembler. But your job is more about linking together static libraries that already work. It's grunt work and nothing special. Being able to discover a bug via verification is the skillful part.

This is where the cosimulation that MyHDL supports is so handy. Reading up on it a bit more, it sounds very promising for the future. The Verilog RTL parts run in the Verilog simulator while the MyHDL parts run in the MyHDL simulator.

" There's no way to use these HLS tools unless the third parties feel like writing a model for their IP in your choice of HLS tool language."

I worried about that as it's a common problem in any domain integrating different languages or models. Sounds like hardware equivalent of wrappers in cross-language, software development.

"The rest of us idiots are doing straight Verilog RTL because SOC level is more about gluing a lot of different modules together with low level logic."

That's actually good news and hopeful for people my research supports given stuff you worked on. If it's really grunt work, then all these amateurs digging into actual HDL wanting to do great things might get it done if they leverage FPGA or ASIC-proven I.P. With at least one pro on team, maybe two if mixed signal. People like me wanting to cheat it without RTL are apparently screwed lol.

"Being able to discover a bug via verification is the skillful part."

Two have said that in one day. The other person said this: "People can do a design without much skill and it might mostly work right. People screwing up on verification can mess up the whole thing." Rings true as I think of mask costs and Intel's recall.

"This is where the cosimulation that MyHDL supports is so handy."

All this time, I thought co-simulation (i.e. equivalence checking w/ tests) was standard in your industry. I know Sandia's HW people did it and high assurance does it between abstraction levels too to catch their gaps. It was essential to me in the latter as an assumption or structural detail would change to throw off safety/security properties. You saying equivalence checking at each layer is not normal in commercial, SOC design? That it's essentially only the shops using the best EDA tools and such?

Just surprising is all. Would also seem easy if you just use the execution-trace-based, equivalence checks. You can script those to a degree in most domains and languages. They're not perfect but I thought that MyHDL feature was a knockoff of what industry was already doing haha.

You saying equivalence checking at each layer is not normal in commercial, SOC design? That it's essentially only the shops using the best EDA tools and such?

We have a difference in terminology. Co-simulation and equivalence checking refers to different things in HW and neither are what you are referring to.

Co-sim is when you have two models running in simulation and you could possibly compare them through time for mismatches. Or you run some sub-modules of the design in a Verilog simulator and other sub-modules in your HLS tool simulator and the modules can interact.

Equivalence checking is usually referring to different type of tool called the formal equivalence checker (FEC). It performs analysis of the two models without doing simulation with weird algorithms like decision trees. This is usually used to compare the Verilog RTL to the gate-level netlist as an additional quality control measure. If you can imagine the synthesis tool, it's optimizing the logic you expressed in RTL and possibly put a lot of different gates and signals. The FEC checks that usually.

When you have two cycle-accurate models, you usually would try to do FEC. But it's typically both Verilog models! There's probably no Chisel-Verilog FEC or "any HLS"-Verilog FEC tool!

So what you are referring to as co-simulation is typically just called simulation. That IS standard at each layer so you would be correct: everyone does simulation. It's just a question of how thorough.

What MyHDL offers in co-simulation is something more. The ability to mix the MyHDL designs and Verilog RTL designs into one simulation. So if you had a 3rd party mem cache in Verilog you could connect it to your MyHDL CPU and run a simulation.

Industry tools do support co-simulation as well! But for me it's a good surprise that MyHDL manages to knockoff that feature because the other HLS don't seem to be able to. Maybe they can though, I am not sure. E.g. Chisel can create a C++ model. I am sure I could hack something together given time.

Of course it's not. That's why real HW types use it and people like me don't. ;) One of my goals on HW security side is to bring synthesis to a level that non-HW people can use it for an OK solution. I found Cx when looking at the awesome Qflow method and tools.

Since you post a lot, what's your opinion on Cx as a HLS tool for programmers without expertise as HW engineers? And outside big EDA, what is your recommendation for lowest cost vs effectiveness HLS for those wanting to clean-slate their hardware or at least accelerate things on FPGA's?

While describing the function of a circuit like MyHDL and many other languages have tried to do it cute, they have never come close to a real engineer

I agree with you on that. For a beginner I think a high level language is the wrong direction to go because it's taking them further away from the method of designing a HW solution. It's adding another layer of abstraction.

That's what people said about going to 3GL's. I'm glad, for my day-to-day computing, that most went in the other direction (pro 3GL's). Software people can't get the kind of results hardware people can while using HLS techniques. That's obvious. Yet, the existing research shows they should be able to get quite a bit of results with little knowledge of hardware. EDA tools actually solved most of the hard parts. Only thing that's lacking are tools to accomplish this and at prices most people can afford.

Two paths developed in parallel. One for those trying to boost their software with hardware generation. One for hardware designers trying to improve their own craft. And with the benefit that one's tools can integrate the other. Best of both worlds.

So, I look for both.

I think maybe the HLS can get you a core design but then when you try to use it and integrate into an FPGA you will have to deal with the low level issues of registers and combinatorial logic. This is fine for the experienced HW person, but not for the beginner. In other words, the HLS is better for the experienced HW designer than the beginner even though it looks like its easy.

Unfortunately there is no infrastructure for you to build onto. It's like a blank slate. All the I/O needs to be done right. It's very seldom just instantiating wires unless your design is blazingly simple. And if it were simple you wouldn't need an FPGA in the first place. A generic coprocessor would kick most FPGAs butts.

Ok that all makes more sense. One of my potential flows was actually having the amateurs build lost of functionality (eg accelerators, device protocols) with HLS tools that a hardware engineer could finalize for FPGA. Would save on the rare labor. What do you think of that model vs exclusively leveraging HW people?

Far as ASIC's, I'd just get HW people, haggle on the tools, use free one's if possible (see Qflow), and do a MPW run for prototyping/production. eASIC's 90nm maskless stuff, potentially. Start it on 180nm-350nm, though, as there's lots of cheap masks and fab capacity there.

What do you think of that model vs exclusively leveraging HW people?

Sounds good.

Cheap fab I am not sure whether the costs make sense. Depends on the project I guess. I don't have a lot of experience with those manufacturing processes.

Still , Cx - lang is having a real hard time to find customers. So what's missing ?

That's part of what I'm trying to find out. To be fair, most open-source, high-level synthesis tools don't have a lot of customers. Even Chisel doesn't have near as many users as its successes deserve. That's common for ASIC or FPGA tools that aren't the big name.

For now, my preliminary answer is that people: (a) just use Altera and Xilinx HLS tools for FPGA because they're cheap and work well with their products; (b) use HLS tools from big three EDA companies on ASIC design; (c) straight up do HDL (majority probably) for ASIC as experienced HW engineers are used to doing anyway and use good RTL synthesis. Against the competition, there's no comparison of free/open synthesis tools except in price and subversion risk. Those are my reasons for investigating them, though, so I continue to get feedback on what I find.

Note: Not sure of your HW expertise. If you're not a HW person, I'll note that anything synthesized for ASIC's needs to have a rock-solid method because mistakes are expensive. Even older processes still cost hundreds of thousands for the masks that print an instance of a design. Production engineers are hesitant to use unproven technology when $$$ are on the line.

Matthieu, co-founder of Synflow here. Maybe I could help? Don't hesitate to send me an email!

I probably will soon since you took the time to show up. :) I think what I'll do is form a list of questions to assess the nature and capabilities of your method. These will represent what a lot of different kinds of people would ask. Then, your answers might get packaged up in FAQ's, blog posts, whatever that clarify things for more people than just me. How's that sound?

Sounds great! I'll do my best to answer all questions :-) My email is matthieu.wipliez@synflow.com

Reply on news.ycombinator.com