I think maybe Chisel and those others would be easier.

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.

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.

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

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.