Quicklogic deduplication

[Ravenslofty]

Presently the Quicklogic codebase has a lot of duplicated cells, especially between the ArcticPro 2 and PolarPro 3.

One of the biggest contributors to that is the flop models, but the hardware flop appears to be a dffepc.

I have already filed #3 to use dfflegalize to lower directly to dffepc, and the next step would be to deduplicate flop models.

The question is how aggressive to be with that:

• the least invasive approach would be to use a common file for the AP2/PP3 flop models, but otherwise keep them as-is.
• the more minimalist approach would be to only model dffepc, but this is effectively a breaking change, since whatever code that uses the other cells would no longer be accepted by the flow.

[kgugala]

@mkurc-ant can you take a look at this

[mkurc-ant]

@Ravenslofty So in PP3 the underlying hardware behaves like dffepc indeed. The same is for AP3, I would need to double check for AP2.

The toolchain must definitely understand different types of flip-flops at the input in case if somebody wants them to be explicitly instantiated. I'd recommend to leave all flip-flop simulation models as they are. I see no problems with Yosys emitting dffepc only.

I've been told that AP2 is more similar to AP3 than to PP3. I'd need to check the status of AP2 support with QuickLogic. Maybe something isn't complete there yet.

[Ravenslofty]

But would you be okay with the common file for the AP2/PP3 flops? That makes my life a bit easier when annotating them with the necessary metadata for ABC9, and upstream will be happier when they have to review this too.

[mkurc-ant]

I agree. My concern is that I'm not sure whether they should be common. I'm waiting for confirmation from QuickLogic.

[mkurc-ant]

@Ravenslofty I've confirmed that with QuickLogic: we should have common flip-flops for AP2/AP3, PP3 are different (at least in terms of cell definition).

[Ravenslofty]

It's odd that AP2/AP3 are the families with flops in common; AP2 uses dffepc and friends, but AP3 uses FF. If I try to deduplicate those two, one of the flows is going to use the wrong flop.

[mkurc-ant]

I mean it may be incorrect that PP3-like FFs are defined for AP2 already.

[Ravenslofty]

Might not be a bad idea to ask them what the flop cells should be for which family.

[Ravenslofty]

There are other areas which seem like they could use deduplication:

• the AP2/AP3 $alu mapping files are the same apart from AP2 using full_adder and AP3 using FULL_ADDER. Would it be feasible to simply use consistent capitalisation for both?
• AP2/AP3 I/O buffer mapping files are also pretty similar aside from using d_buff differently; AP2 takes in a constant wire, while AP3 has the constant as a parameter. Is there a technical reason for these being different, or could they be unified in some way?