Incremental verilate on large designs?
I'm wondering if there are any strategies or features to reduce build time when small changes are made to large designs? I can use ccache to speed up the C++ compile, but the verilator still takes a very long time to generate that mostly identical C++ because it does everything from scratch on any change... Is there any concept of an incremental compile that I might've missed in the docs, or some way that people hack one together themselves...?
RE: Incremental verilate on large designs? - Added by Wilson Snyder over 1 year ago
Not currently, sorry.
It's not really incremental, but one method is to manually piece your design into SystemC modules, then use the SystemC kernel to connect them. Then only one needs to re-verilate. Ideally this would be handled by verilator itself someday, e.g. perhaps similar to what's discussed in this thread: https://www.veripool.org/boards/3/topics/2348
RE: Incremental verilate on large designs? - Added by Stan Sokorac 12 months ago
Revisiting this... one thing that seems problematic to me about breaking up the design into multiple ones and then creating a wrapper is that if any of the outputs from the models are not coming directly from flops, you'd have to evaluate the whole model twice on every clock, right?
I.e. if you have model A and B, you can evaluate A, then take outputs and drive inputs into B.. then you evaluate B, but now outputs of B that don't come from flops might've changed, and you have to re-evaluate A. (that's assuming that you don't have A->B->A paths without flops, in which case you have some big problems... )
Am I thinking through this correctly? "Every output must be coming from a flop, or your performance drops to 1/2" seems like a pretty big limitation on how you can divide up a model.
RE: Incremental verilate on large designs? - Added by Wilson Snyder 12 months ago
Yes, multiple sub-evals are needed. The assumption is the sub-module verilation will determine many combo sub-evals each listing inputs and outputs for that sub-eval. Thus the upper level can call/order only what sub-eval is needed just like if there was an "always" with certain i/o.