Generate Quartus specific code

[christiaanb]

Looking, for example at:

clash-compiler/clash-lib/prims/verilog/CLaSH_Explicit_BlockRam.json

Lines 27 to 39 in c9d7812

	always @(posedge ~ARG[1][1]) begin : ~GENSYM[~COMPNAME_blockRam][4]~IF ~VIVADO ~THEN
	if (~ARG[1][0]) begin
	if (~ARG[4]) begin
	~SYM[0][~ARG[5]] <= ~ARG[6];
	end
	~SYM[1] <= ~SYM[0][~ARG[3]];
	end~ELSE
	if (~ARG[4] & ~ARG[1][0]) begin
	~SYM[0][~ARG[5]] <= ~ARG[6];
	end
	if (~ARG[1][0]) begin
	~SYM[1] <= ~SYM[0][~ARG[3]];
	end~FI

we can see that the generated code for Vivado is actually the most reasonable, and it is the non-Vivado path, the one used for Quartus, that is slightly more convoluted. The reason for this is, that, historically, Clash has only done conditional code-gen for Xilinx/Vivado.

So what needs to be done is to add Quartus-specific codegen paths, so that all non-Quartus synthesis tools get to see the reasonable code for examples such as the one mentioned above.

[expipiplus1]

FWIW using the vivado codegen with quartus has always worked for us.

[christiaanb]

I would be surprised if that wasn't the case for the 0.7 branch. However, now that the master branch has explicit clock lines and clock enables, I wouldn't know if that was necessarily the case for i.e. the blockRam# primitive. That is, I'm not 100% convinced Quartus will infer a blockRam if you have a gated clock and use the Vivado code-path.

The reason being that, Xilinx blockRams have complete chip-enables, while Intel/Altera blockRams only have read and write enables; and the generated HDL in Vivado code-path corresponds to a chip-enable. So when you have a gated clock, and you use the Vivado code-path, I'm not 100% sure that Quartus will infer a blockRam with read and write enables.

[thoughtpolice]

I think it'd be better to generalize the argument to clash and the template language. For example, make the argument a freeform string and pass it to a template and allow matching against it. I invoke[0]:

$ clash -fclash-synthesis=vivado ...

And I have a blackbox like:

~IF ~MATCH(~SYNTHESIS_TOOL, "vivado") ~THEN
...
~ELSE
~ERROR("invalid synthesis target for this blackbox", ~SYNTHESIS_TOOL)
~FI

This would allow users to more easily extend or provide libraries that target other HDL toolchains. In practice there are a wide combination of them so this might be more useful. For example, I believe Microsemi tools use Synopsys for the synthesis tool but have their own place-and-route. Yet, there is also the Lattice Semiconductor iCE40 FPGAs, where iCECub2 (EDA toolchain) can use Synopsys, or their own synthesis engine. And I've seen different results between them for techmapping and e.g. inference results. So you might have synopsys-microsemi or synopsys-lattice, lattice, yosys, etc etc.

I think in practice we may only want to target a couple, but this is just a suggestion.

[0] (The imaginary -fclash-synthesis argument is a theoretical rename of -clash-hdlsyn but that's only because I'm a bikeshedding pedant and I'd like to change the clash argument style; I'll put that in another ticket.)