GateMate Constraint File Pin Declaration Format

[tarik-hamedovic]

The current constraint format for GateMate chips requires the declaration of pin directions both in the constraint file and the HDL file such as Pin_in, Pin_out, Pin_inout. This approach is unconventional and differs from other vendors, creating challenges in implementing Amaranth HLS for GateMate chips. The primary issue is the inability to create a general constraint file due to the necessity of specifying pin directions in the constraint file.

Proposed Solution

To resolve this issue, it is suggested to use a general pin constraint format that only requires the pin identifier, without the need to specify its direction in the constraint file. This would align with common practices and facilitate easier implementation and integration with Amaranth HLS.

By adopting this improvement, the workflow for developing with GateMate chips would become more streamlined and user-friendly, aligning better with industry standards.

[chili-chips-ba]

@pu-cc , @whitequark for awareness. Also see: amaranth-lang/amaranth#1372 (comment)

[chili-chips-ba]

... given Yosys SV problems, one option to consider is to move all new design creation to Amaranth. While that's a no brainer for other vendors, these CologneChip constraints peculiarities stand in the way of adopting such development flow for GateMate.

[whitequark]

I am not a part of your team nor am I responsible for addressing this issue.

[chili-chips-ba]

@DadoCCAG , given that it seems very difficult for Amaranth to adapt to this GateMate uniqueness of the constraints' format, what's your assessment from CologneChip side on the chance for providing an option that would align it with other FPGA vendors?

The objective is to enable GateMate in Amaranth flow, making the first critical step towards HLS, and opening a whole new set of possible applications.

[pu-cc]

With the upcoming P&R update, CCF will now offer the option of specifying the keyword “NET” instead of the pin direction. P&R then retrieves the direction information from the buffer primitives in the netlist. This is compatible with the UCF file format.

As soon as the update is online, I will report it here to close #10.

[chili-chips-ba]

... that's a wise approach, one that both retains compatibility with CC legacy, and gains compatibility with everything else 💯

[pu-cc]

We updated the P&R binary yesterday. CCF now supports the “NET” keyword as described here. You can download the latest build it here:

https://colognechip.com/downloads/cc-toolchain-linux.tar.gz
https://colognechip.com/downloads/cc-toolchain-win.zip

Thanks for your help.