Fake part with Fake timings

[bartokon]

Hi,
I'm thinking if it is possible to create a fake part with fake timings, so whole place and route could take seconds (Cached synthesis p&r?) That part should have unlimited resources and each path delay could be for example 1.5*logic_delay. Logic delay could be avg from different FPGA families. All latency finding algorithms could much faster to iterate...

For example generate netlist from Pipeline parsed code then generate fake timing paths depending on logic depth and wire length.

[JulianKemmerer]

so whole place and route could take seconds depends on what you mean?
In theory yes - but depending on how much of GHDL->Yosys->nextpnr I want to fake it could be a rather large undertaking to do so.

I mentioned in another issue there is two slow syn+pnr processes

1. Get comb. logic delay for all modules (so I know where to put pipeline regs)
2. Run syn+pnr with guess pipeline params based on where I think they should go (refine guess, repeat)

Right now its plausible to reduce the time spent doing 1) (the smaller of the two chunks since not iterative, and highly parallelizeable, but still quite slow) by not synthesizing all functions, but instead only synthesizing the most primitive operations (i.e. in cache) and lego-bricking building up a fake guess of how much delay larger user C functions have (quickly, as opposed to running full syn+pnr on all user code).

For 2) though - building up a fake map of pipelined params -> timing delays ... thats like creating a whole other tool , practically my own syn+pnr flow idk 🥴

[bartokon]

Yes, you are right.

For syn+pnr, I'm thinking about TerosHDL generating generic schematic with help of Yosys, so it gives us netlist to analyze.
Now we could find an amount of logic levels to next register and assume that regardless of what wire or reg delay is always some 1 unit for example 1ns and passing reg is 1.5 unit and sum the worst path delay ang logic delay, put registers there. We don't even need to place and route, just use schematic to estimate performance.

Idk I'm looking at:

and I see that there is correlation in implementation, so few fake synth runs, and you could predict what latency gives you what frequency.
Just use hard-coded values for Virtex/Artix family idk average path delay in some basic implementation and use it as base unit.

[bartokon]

So basically you will add pyrtl support to pipelinec and accelerate functionality many times 🗡️

I'm waiting for some sneak peek on your work!

Btw. Don't forget about more knobs :3

[JulianKemmerer]

Precisely about more knobs - especially for that last step I mentioned slowly work in integrating pyrtl-the-python-library as the default fast estimator even for when using other tools (estimate with pyrtl, final syn with vivado or something)

There will need to be some tuning of how the pyrtl estimator maps to vivado results
So when we are doing doing our many times accelerated estimation stuff - it is getting towards the goal for vivado too (it should be in the ballpark to start I think)

[JulianKemmerer]

And im sure you want more pipelinec knobs too ;)

[JulianKemmerer]

You wanted to see it as soon as it happened @bartokon
Just pushed what looks like working support for basic pyrtl use

Comment out your #pragma PART line and if you have pyrtl installed it will default to it
And I tested with --coarse since its a single pipeline example we've been using

[JulianKemmerer]

Will be trying bigger examples this evening hopefully

[bartokon]

Okay Julian, I will research this myself and if I find something usable I will write about it here :)

PS. Are use using incremental synthesis or similar flow that could speedup synth process?

[JulianKemmerer]

Lovely - I await hear on what you find in your research 🤓

I am not using any flows like you are thinking I don't believe. Right now each module that is synthesized is simply its own top level, run independently in an out-of-context mode synthesis (talking Vivado here). I havent done partial/incremental synthesis since I dont think designs are large enough / partitioned well enough (i.e. into separate large chunks) for that be beneficial most of the time

[bartokon]

Look at this:
https://support.xilinx.com/s/article/976545?language=en_US
adding reg and re-synth 50% synth time.
It should find target latency faster for at least Vivado :)

[bartokon]

I will try to test synthesis model reuse by using open tools to create base model and then try to move it to Vivado :p

[JulianKemmerer]

Hmm interesting - ive never seen incremental synthesis used.

It is not very frequent that I even have the 5 RTL Partitions of size greater than 10K instances size requirement to trigger parallel synthesis.

But yeah once reaching that size this does seem like it would speed things up. Good to know about!

[JulianKemmerer]

I will get to your other comments @bartokon but btw
I really appreciate these constructive conversions we are having regarding improving PipelineC

I am often on this Discord's #hdl-other channel talking about PipelineC
https://discord.com/invite/pY2wJvnCMY
If you are into that sort of thing - stop on by, spark up some conversation there :)

[JulianKemmerer]

See issue #46
for further work+discussion