SystemC vs other HDLs

You're at university and studying (presumably) to be an engineer. As an engineer you should understand how things work at a low level. In order to achieve this you need to strip away layers of abstraction, not add them.

For this reason, my advice is that you don't use SystemC for this project. You may end up using it in your professional career, but that's for the future.

If you choose to use it anyway then you should speak to your lecturer first. When I did a similar task at university, we were explicitly told not to use SystemC for the reason that I've outlined above.

Your friend either misunderstood what you are doing or was thinking of SystemC as a preliminary step. An HDL is the only choice In any case, and I would suggest you use synthesizable SystemVerilog that is powerful enough to do a lot of exploration whole being essentially the same as Verilog for everything else.

1. Partially. You distinguished between Verilog as an HDL, SystemVerilog as a verification language, and said that SystemC has higher abstraction but also a synthesizable subset. There are two errors here. First, SystemVerilog is also an HDL with a fully synthesizable subset that could be resumed as a Verilog with obvious fixes (e.g. one single logic type for wires) and many synthesizable abstraction mechanisms (e.g. Interfaces). It is supported by many tools including Vivado. SystemC on the other hand, is not directly synthesizable (not even any subset), it is meant for higher level modeling and architectural exploration though some subset of it can be fed in a High Level Synthesis tool such as Vivado HLS that then translates it into synthesizable (though human-unreadable) Verilog.

2. Verilog and the synthesizable subset of SystemVerilog are languages for HW design, usually used to describe HW at a register-transfer level, i.e. as a set of blocks like registers, combinational functions, finite-state machines etc. Verilog-2001 can also appropriately describe hw as a gate-level netlist, while SV can also be used to a much higher level of abstraction hence its verification capabilities. On the other hand, SystemC is appropriate for high level modeling of systems in which entire blocks are described only in a high level behavioral fashion. It is also very powerful for architectural exploration, i.e. varying parameters and characteristics of an architecture and evaluate changes in the overall performance.

3. That is true only if you try to describe things in a non-RTL fashion while developing an RTL model. For example, the right way to describe a block performing a repetitive multiply-accumulate is a finite state machine driving a combinational multiplier, a combinational adder, and a register - if by behavioral you meant describing this as in software (a for loop) then yes, behavioral code won't work. If you meant describing each of the blocks I described (mult, add, reg and FSM) via always blocks, that is perfectly fine and will work out in a netlist realizing exactly what you specified with excellent results (often better than a exceedingly structural approach that limits the capability of the synthesis tool to optimize logic). In fact, SystemC high level synthesis will often result in good results only if you stick to very similar patterns, effectively obliterating any advantage in using a higher level language. In any case, SystemC is a poor choice for implementing a processor.

4. Architecture is a very broad term that is not limited to the ISA, in fact in modern processors ISA design is only a small piece of the puzzle. In the context of the design of a system, architecture usually means the set of system-level choices (e.g. can the DMA be controlled by any core or just one special one? Is the L1 cache fully or set associative? Do you have a cache at all, or manage memory in SW?), including the ISA and also the processor micro architecture . I think what your friend meant is that you are exploring various configurations of your processor, which is in fact architectural exploration (or micro architectural exploration if you prefer). However, he might have missed the fact that you are going to implement this on an FPGA, which makes the SystemC option nonsensical.

5. This is wrong. If you are designing a very simple accelerator, such as a streaming filter, that might be true because HLS tools allow to easily insert pipeline stages, whereas you would have to do that manually in RTL (or use datapath retiming, but I think that's not possible in Vivado). In all other cases, and especially in a highly complex and structured object such as a processor, HLS will result in bloated, undebuggable and often plain wrong Verilog that then has to be synthesized - the tools are simply not designed for this job.