Reusing delay model infrastructure for area

[Jonathan Bailey]

Hi all,

I need an area estimate model for a project I am working on (xls/contrib/integrator) and it looks like the infrastructe for delay characterization is very similar to what I need (e.g. https://github.com/google/xls/commit/6b60a48192ff2191ef2fc4d21283483b46880661 and other stuff in xls/xls/delay_model/).  

I was wondering what is the best way to reuse the delay model infrastructure for area.  Ideally, we'd instead hava a general FeatureModel / CostModel that we sublass for delay / area etc.  However, area estimation is a very minor part of my project, so It doesn't seem worthwhile to do all the refactoring needed for this. 

Barring that, I'm thinking the least-effort approach might be to just use the delay model stuff directly.  However, this creates some ugliness. 1) Although I'd be storing area (in terms LUTs on FPGA or similar), the code will stiff refer to delay.  Could add comments or abuse #define / add wrapper functions for my uses, but still akward.  2) Generated models are registered with a single, persistent delay model manager (see xls/delay_model/generate_delay_lookup.tmpl).  In order to avoid my area model registering with the actual delay models, I'd probably have to do some genrule shenanigans e.g. have a genrule that copies generate_delay_lookup.tmpl into my directory build but replace the text for registering a model so that my model is registered to a different manager that is contained within my project.  Could probably work, but again akward.

3rd option:  Don't try to reuse infrastucture.  The regression / logical effort models in the delay model probably arent' a great fit for what I need right now anyway, so maybe I can just write a simple lookup-only or interpolation model for my use case.  The downside is that it doesn't seem like good code design to have similar functionality implemented in two different places.

Let me know what you think,
Jonathan

 

[Mark Heffernan]

The delay models are added by linking them in. So you can create your own delay model under xls/contrib/integrator and it will have no effect on the rest of XLS. I think it's fine to use the delay model as an area model in your code as is. You might want a thin wrapper around DelayEstimator class which has method names with "area" in them to make the code which uses it clear.

On a different note, it probably makes sense for the integrator stuff to live in xls/experimental rather than xls/contrib. I think "experimental" is a more accurate reflection of the state of things than "contrib" which suggests some that might be production worthy at the moment, but just not maintained by the core devs.

Mark

Mark

--
You received this message because you are subscribed to the Google Groups "xls-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xls-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xls-dev/21d020ca-4d66-4790-8db5-81122c65f682n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.