delay_model textproto; operationand OpCode

[xls interested]

Happy New year!

I am seeking some clarification on the intended "op" value within delay_model textproto models and the excellent timing_characterization_client util.py
I noticed that op field in delay_model textproto are used both for the operation and OpCode, is this by design, if not what might be the correct usage?

As example the xls/delay_model/models/data_points/sky130.textproto {
show:
  operation {
    op: "kIdentity"
    bit_count: 1
...

The xls/synthesis/timing_characterization_client util.py generates:
data_points {
  operation {
    op: "identity"
    bit_count: 1

...
   
Thanks for any help and clarification

[Leary, Chris]

(Sorry I missed this, went to spam for whatever reason.)

Good observation -- the short answer is I think it should be kIdentity. :-) The long answer might be informative though.

We conceptually decouple collecting characterization data points (the `DataPoint` protobuf message, which is decribed by the `Operation` that is being characterized; https://github.com/google/xls/blob/24e43640ea34b39a5ea474d9031b4e1c48142c9a/xls/delay_model/delay_model.proto#L37) from the way an XLS delay model /resolves the delay/ for an XLS node, which is ultimately saying "I think that this XLS Node, with its xls::Op opcode and these operands / bit widths / etc -- has delay N ps!". The abstract C++ object that does that latter task is called the DelayEstimator ( https://github.com/google/xls/blob/24e43640ea34b39a5ea474d9031b4e1c48142c9a/xls/delay_model/delay_estimator.h#L28 ). The datapoints and specifications of how those datapoints should be interpolated /are/ put in the /same/ .textproto file right now, but conceptually we figured you collect data and then you layer on top how you'd like those data points to be interpolated, then that specification turns into C++ objects. [*]

So, before we added SpecializationKind ( https://github.com/google/xls/blob/24e43640ea34b39a5ea474d9031b4e1c48142c9a/xls/delay_model/delay_model.proto#L60 -- which was introduced in Mar 2020 before we were open sourced) we had /fake/ operation names like kMulSquare (to represent that the mul had the same operands as the left hand side and right hand side), and then it was the responsibility of the delay model generator to slurp up the data points with these extended operation names and spit out code that would use normal C++ xls::Node opcodes and the node's properties.

Of course, making the schema more expressive, so it could describe the scenarios without relying on fake operations encoded as strings, was a clearer way to do it, so SpecializationKind was added.

As a result, we could/should now probably make sure the "op" field corresponds to an actual XLS Op as in the C++ enum-class. We'd just need to extend our Op generator to spit out op.proto and then we could use that in the schema instead of the stringy solution we have now.

Hope that helps put it into context!

- Leary

---

Aside: just talking out loud tracing some things backwards, the op value is used directly as a member of the XLS "Op" (C++ enum-class) here:

https://github.com/google/xls/blob/24e43640ea34b39a5ea474d9031b4e1c48142c9a/xls/delay_model/generate_delay_lookup.tmpl#L33

That is the DelayModel Python object:

https://github.com/google/xls/blob/24e43640ea34b39a5ea474d9031b4e1c48142c9a/xls/delay_model/generate_delay_lookup.py#L49

Whose ops come from the "op models":

https://github.com/google/xls/blob/24e43640ea34b39a5ea474d9031b4e1c48142c9a/xls/delay_model/delay_model.py#L662

Which is the "op" field of OpModel proto messages:

https://github.com/google/xls/blob/24e43640ea34b39a5ea474d9031b4e1c48142c9a/xls/delay_model/delay_model.proto#L252

---

.. [*] Right now we generate the C++ for the DelayEstimator implementation from Python via a template, but it'd be kind of nice to remove the generation step if we could find substitutes for the scipy interpolation routines we're using that wouldn't take on large dependencies -- code generation is powerful but this is one of those cases where it doesn't feel essentially necessary.

--
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/87a7545b-32f7-4bde-a4f3-0a5ac9983bcdn%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[xls.int...@gmail.com]

Thank you so much for the extremely useful information.

It’s very helpful and makes perfect sense to me.

 

Thank again!