odmkSeijin

Not with the same exact source files / same software version. But sometimes small changes in the design, or changing tool versions can cause the design to not meet timing. It's just the nature of map / place and route.

I understand there is some validity with this criticism. Xilinx has always been slow to adopt standard software development practices. But really, Xilinx tools have never cost 'multi-tens of thousand dollar's. The most expensive tools are several thousand dollars. There are also free tools for smaller devices / certain flows. Source control is done with tcl scripting (simple text files) and standard source control tools. It's not as bad as it was in the past. Cheers.

You have your principles backwards. Non-technical founders should not stay the owners of a technology company if shit happens. The ownership should be usurped by technically proficient people. It is called 'nerd's revenge'.

James Damore did not write a 'sexist article'. Anyone can read what he wrote and also listen to him explain his thoughts. He doesn't write or say anything that is intentionally anti women in tech. His motivation for writing in the first place seems to be because he wanted to be helpful in some way, then people threw him under the bus, which seems to be what you are doing now.

What you are describing is just one aspect of programming with HDL that sounds similar to what one would do with a schematic editor. Fortunately, with HDL you can work at either a primitive level, or a more abstract behavioral level or anywhere in between. What if someone wants to design a library without knowing the specific device that will be targeted? You could use behavioral algorithmic style code using parameterized functions and lots of generate statements that could support multiple architectures. In that case there would be a lot of 'code' that does not have anything to do with the actual circuit but is still perfectly valid HDL. It is the software-like functionality of HDL that made schematic editors obsolete in my opinion.

Uh, yes, that is all true (except maybe the processor with feedback bit is debatable..). I agree with all this, and yet my arguments for why C++ HLS is a good thing remain the same.

Forget about Xilinx marketing. I am curious, what did you find causes a design fall outside the '20%' usecase situation? Are you talking about asynchronous clocks? feedback? IO configurations? or what? Why do you say HLS should not be based on C++? Is this related to concurrency or something else? I am not disagreeing with you necessarily. I would say that C++ has the good/bad quality that it is possible to express the same thing 20 different ways. Also, the behavioral simulation is vastly faster. Given that a design has to be done in a limited amount of time realistically, there is an advantage to being able to iterate rapidly and make many structural changes to optimize a large design for both area and clock frequency. Only trivial designs or very specific blocks would be hand placed. I want the compiler to do register re-balancing and other optimizations. The same way that almost no-one could beat the performance of a modern C compiler by typing in machine code. Definitely Vivado is not there yet, but it should be.

I don't agree with this, but I think I see what you are trying to say. I think typically a full design would include some interface portion with maybe DMA or PCIe or whatever that would be done in HDL, and maybe a processor or not. HLS works for the processing that is done inside the FPGA. If this is what you mean by DSP-like, then sure, but it does not have to be image processing, it could be anything done in fabric. It is possible to write a specific truth-table, and similar basic elements in C++, so why would you be forced to do any specific type of application? Where did you get %20 percent number? At least for Xilinx HLS, I don't think that has anything to do with anything (maybe for some other compiler??). If you take some generic C or C++ code and try to put it in an FPGA, the number will be more like 80%. The results will be horrible. On the other hand, if you write code in a way that naturally maps to the hardware you are using then the results can be every bit as good RTL. But this is not necessarily easy to do. I think that this has more to do with the quality of the current compilers, not some inherent limitation with the concept. I like HDL, but I would much much rather program in C++. It is a more sophisticated language. I think Intel/Altera is supposed to release some HLS tool, and I know there are others that I haven't tried. What I am saying is that it would be nice if enough effort was put into these tools to not have to worry about whether there are limitations. Even more so since I think the newer C++ standards are moving towards multi-threading/concurrency.

Both. The differences are not that great. I don't believe anyone who says they can done something in one that can't be done in another, they just don't now how to do it. After staring at a large design day after day, it is a pleasure to switch to the other one just to break up monotony. If you inherit someone else's design, I prefer to have the component list in VHDL to get an overall picture of what is going on. I guess it is easier to write Verilog, but easier to read someone else's VHDL.

I programmed FPGAs using both VHDL and Verilog for many years. Recently I have started at a start-up where we predominantly program using C++ HLS. I never want to go back to full-time HDL again. We have found it is possible to get the same performance as carefully written RTL, but you still have to write with the underlying device architecture in mind. There are advantages with HLS, simulation is vastly faster, and C++ templates can be used. This makes it easy to try many iterations and find clever optimizations. If you try to do the same with HDL it would be a nightmare with a large design. More people should move to HLS and push for the tools to improve. the world would be a better place.