Do i really need to study monstrously long intel manual?

[Cyao]

Given this thread topic, I think I ought to mention that a complexity-hating former friend hates Verilog, preferring VHDL. I have no idea how subjective or objective this is, but complexity-haters might want to compare the two languages to see how they get on. It didn't stop my friend from implementing all sorts of stuff in Verilog for a SBC, so perhaps it's not too bad.

I also hate Verilog as your friend (but I use it since I don't want to rewrite my project), my reason of hate is that verilog is super hard to read - especially when everything is mashed together and not correctly indented. And in verilog, code might simulate right but not work right on hardware (aka not all code is synthesizable). And in the opposite, VHDL is very strict (and readable according to me):

Verilog is what happens when you let Mentor Graphics into your standards committee.
VHDL is what happens when you allow the military to write the standard.

Also here is also a little post about verilog: https://danluu.com/why-hardware-development-is-hard/ after you read it you will probably understand your friend.

[rdos]

A 12-core thread-ripper processor is far more effective at general processing tasks than a CPU core in a FPGA.

I think you rather miss the point. I'm not trying to produce the next Threadripper or i9 anymore than I'm trying to produce the next OS X or Windows.

I'm just having fun.

Me too.

However, I see no fun in having to code for Linux/Unix like platforms and to use GCC, so I avoid pi and FPGA-based cores. If a FPGA-based CPU core could run x86 protected mode assembler-code, I might find it more worthwhile.

I would find it interesting to build a CPU-core from scratch, write an assembler for it (from scratch) and maybe even a C compiler, but I certainly find no fun in adapting GCC to a new CPU.

Also, I've coded a lot of PCI drivers for my OS, and creating my own PCI device & writing a driver for it, certainly is a lot of fun, and an interesting project.

[rdos]

I also hate Verilog as your friend (but I use it since I don't want to rewrite my project), my reason of hate is that verilog is super hard to read - especially when everything is mashed together and not correctly indented. And in verilog, code might simulate right but not work right on hardware (aka not all code is synthesizable). And in the opposite, VHDL is very strict (and readable according to me):

I like Verilog. I don't know VHDL, but since Xilinx appeared to mainly use Verilog, I decided to learn Verilog and not VHDL.

Also here is also a little post about verilog: https://danluu.com/why-hardware-development-is-hard/ after you read it you will probably understand your friend.

I don't think FPGA programming is for dummies, much like OS programming isn't either. I have a fairly good knowledge of digital logic (it was part of my MSc I took in the 80s), so I don't make that kind of mistakes. I know that the code is translated to flip-flops & hardware primitives, and so I don't use multiply or divide in Verilog, and I certainly don't wonder how to output a string on a monitor.

I very much doubt that VHDL can make sure that code is possible to translate to logic. For instance, how does it know if a 64-bit adder could be implemented in a single cycle at 750 MHz clock frequency in the target FPGA device?

Actually, the toughest stuff is clock domain crossings, how to declare them in contraints files, and that has no relation to Verilog at all.

[eekee]

Given this thread topic, I think I ought to mention that a complexity-hating former friend hates Verilog, preferring VHDL. I have no idea how subjective or objective this is, but complexity-haters might want to compare the two languages to see how they get on. It didn't stop my friend from implementing all sorts of stuff in Verilog for a SBC, so perhaps it's not too bad.

I also hate Verilog as your friend (but I use it since I don't want to rewrite my project), my reason of hate is that verilog is super hard to read - especially when everything is mashed together and not correctly indented. And in verilog, code might simulate right but not work right on hardware (aka not all code is synthesizable). And in the opposite, VHDL is very strict (and readable according to me):

Verilog is what happens when you let Mentor Graphics into your standards committee.
VHDL is what happens when you allow the military to write the standard.

Also here is also a little post about verilog: https://danluu.com/why-hardware-development-is-hard/ after you read it you will probably understand your friend.

Thanks, that does help me understand. Readability, appropriateness to the task, and the inelegance of a design which makes correct simulation (or any other task) much more complex than it needs to be will all have mattered to my friend.

I very much doubt that VHDL can make sure that code is possible to translate to logic. For instance, how does it know if a 64-bit adder could be implemented in a single cycle at 750 MHz clock frequency in the target FPGA device?

I understood it as comparable to explicit types in a coding language. For example, some things expressible in C result in undefined behaviour, but specifying the types of variables for the compiler to catch is still worthwhile.