How to 'report_timing' in CologneChip proprietary PNR tool?

[chili-chips-ba]

Here is a good question from @TurboVega:

"... does anyone know how (command line option, maybe) to get more detailed information out of the P/R tool, such that we can determine exactly what "paths" are responsible for the maximum clock rates computed by the tool? In its output, it just labels the clocks with generated names, as it does when referring to various FPGA internal components, making it hard to know what Verilog source entities are involved. Knowing what parts of the source affect long paths helps in optimizing speed..."

[pu-cc]

Due to mapping and various optimizations during implementation in P&R, it is not possible to keep all signals and names for cross-referencing. However, registers remain identical, and can be found in the *.crf output. The file is generated automatically after P&R if the +crf flag is set.

Here is an example: You find the critical path information with highlighted start and end in the P&R log:

The CPE names are made up of the component number (_a) and the CPE part (/1) or (/2). In this example, the starting flip-flop has component number 110, part 2 (110/2 or _a110/OUT2). You find it in the CRF file as follows:

In the post-synthesis netlist (*_synth.v), it has the instance name _3208_, and you will find the flip-flop with reference to downsampler_inst.generalcounter[15] in your code:

Similarly, we also find the target flip-flop (100/1 or _a100/OUT1) in the CRF:

In the post-synthesis netlist, you find it as instance _3199_:

In order to optimizing your critical path, you could now examine the path between thegeneralcounter[{15,6}] registers in your code and optimize it if necessary.

[TurboVega]

Thanks very much for your reply.

On Thu, Jul 11, 2024, 2:19 AM Patrick Urban @.***> wrote:

Due to mapping and various optimizations during implementation in P&R, it is not possible to keep all signals and names for cross-referencing. However, registers remain identical, and can be found in the *.crf output. The file is generated automatically after P&R if the +crf flag is set.

Here is an example: You find the critical path information with highlighted start and end in the P&R log: image.png (view on web) https://github.com/chili-chips-ba/openCologne/assets/14027986/a0c46fa0-62ce-4606-b3d9-a4926fafbcfa

The CPE names are made up of the component number (_a) and the CPE part (/1) or (/2). In this example, the starting flip-flop has component number 110, part 2 (110/2 or _a110/OUT2). You find it in the CRF file as follows: image.png (view on web) https://github.com/chili-chips-ba/openCologne/assets/14027986/1a44d24b-7768-446b-8344-389665e2fe2e

In the post-synthesis netlist (*_synth.v), it has the instance name 3208, and you will find the flip-flop with reference to downsampler_inst.generalcounter[15] in your code: image.png (view on web) https://github.com/chili-chips-ba/openCologne/assets/14027986/c15bf2fc-5e71-4ff0-85a6-9957c18f0c1d

Similarly, we also find the target flip-flop (100/1 or _a100/OUT1) in the CRF: image.png (view on web) https://github.com/chili-chips-ba/openCologne/assets/14027986/f7fcb4d4-ce25-406b-bfd6-51db9f7bf303

In the post-synthesis netlist, you find it as instance 3199: image.png (view on web) https://github.com/chili-chips-ba/openCologne/assets/14027986/40982851-1cd4-4dd3-a2c7-6454827e8553

In order to optimizing your critical path, you could now examine the path between thegeneralcounter[{15,6}] registers in your code and optimize it if necessary.

— Reply to this email directly, view it on GitHub https://github.com/chili-chips-ba/openCologne/issues/18#issuecomment-2222122625, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFUATMPO2IR5JTJMGRRJ6DZLYPXLAVCNFSM6AAAAABKWDWKN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRSGEZDENRSGU . You are receiving this because you were mentioned.Message ID: @.***>

[chili-chips-ba]

@pu-cc good tips 💯

Still, how do we do random timing queries (such as report_timing) in the CologneChip framework?

Is there a document that describes scripts and procedures to use if they are not based on the de-facto industry standard SDC?!

[chili-chips-ba]

@pu-cc - How do we go about specifying timing constraints for GateMate?

• primary clock period
• generated clocks (such as from internal PLL) or RTL dividers
• exceptions: MCP, FP
• I/O delays

From earlier experience (see this, nextpnr is not very too timing-savvy, if at all (@MikeReznikov for additional comment).

While we expect CologneChip proprietary P_R tool to be better than nextpnr in terms of timing awareness, this is to seek additional info on that topic.