Factor out DDR3.

[StephanvanSchaik]

The following commit factors out any instance of the Resource function specifying a 'ddr3' resource with a call to DDR3Resource. See also issue #15. The following boards have been updated to use DDR3Resource:

• Alchitry Au
• Arty A7
• Arty S7
• ECPIX5
• Genesys2
• OrangeCrab r0.1, r0.2
• versa_ecp5, versa_ecp5_5g

As DDR3 uses differential signalling, DDR3Resource accepts diff_attrs in addition to attrs. Some board also specify different attributes for specific pins like the rst, dq and dqs pins.

[whitequark]

The main concern I have with this PR is the complex interplay between the various attrs parameters. It seems hard to understand looking at the call site. Moreover, the way attributes are overridden both implicitly (by the platform code) and explicitly (by the or clauses) seems like it would make writing correct definitions challenging.

[StephanvanSchaik]

The main concern I have with this PR is the complex interplay between the various attrs parameters. It seems hard to understand looking at the call site. Moreover, the way attributes are overridden both implicitly (by the platform code) and explicitly (by the or clauses) seems like it would make writing correct definitions challenging.

I agree, I am not sure myself what the best way forward is if we want to have a DDR3Resource abstraction. One way is to keep it simple and only have an attribute for the general resource and another for the differential signals, as there are a few boards where it is that simple, and to just write out the Resource for anything more complicated.

Similarly with the Arrow DECA platform I have been noticing that the peripherals are not as straight-forward, as most of the resources have pins that require two different I/O standards (e.g. 1.2V and 1.8V).

[whitequark]

One way is to keep it simple and only have an attribute for the general resource and another for the differential signals, as there are a few boards where it is that simple, and to just write out the Resource for anything more complicated.

This is what I've leaned towards so far. There's nothing inherently wrong with writing out the Resource explicitly within the board definition framework as it's currently designed. Ideally we'd have some kind of type system for resources, though.

[StephanvanSchaik]

One way is to keep it simple and only have an attribute for the general resource and another for the differential signals, as there are a few boards where it is that simple, and to just write out the Resource for anything more complicated.

This is what I've leaned towards so far. There's nothing inherently wrong with writing out the Resource explicitly within the board definition framework as it's currently designed. Ideally we'd have some kind of type system for resources, though.

All right, that is clear! I will work on this in my next cycle.

[StephanvanSchaik]

This is a simplified version of the previous commit where the DDR3Resource only has the usual attrs, as well as diff_attrs for the differential signalling. As a consequence, only the Alchitry Au board uses DDR3Resource, whereas every other board defines the 'ddr3' resource explicitly, because they need more explicit control over the attributes of clk, dq and/or dqs`.

[whitequark]

Thank you!