TTNN Operation Parameter Consistency: Problem Statement & Parameter Builder Solution

[rpavlovicTT]

TTNN Operation Parameter Consistency: Problem Statement & Parameter Builder Solution

Executive Summary

The tt-mlir compiler has two distinct paths for invoking TTNN operations that risk parameter inconsistency:

1. OpModel Path: Uses ::ttnn::graph::query_op_constraints() for validation
2. Runtime Path: Direct TTNN operation calls for execution

This document analyzes the parameter consistency challenges and proposes a Parameter Builder Pattern to ensure both paths use identical parameters.

Problem Statement

The Dual Invocation Challenge

The tt-mlir compiler architecture requires two different invocation paths for the same logical operations:

Path 1: OpModel Query Path (lib/OpModel/TTNN/TTNNOpModel.cpp)

• Purpose: Validate operation parameters and estimate constraints
• Uses ::ttnn::graph::query_op_constraints() to query operation feasibility
• Parameters derived from MLIR attributes via conversion:: functions
• Heavy use of std::nullopt for optional parameters

Path 2: Runtime Execution Path (runtime/lib/ttnn/operations/*/)

• Purpose: Execute operations on actual tensors
• Direct TTNN operation calls for real execution
• Parameters from flatbuffer with utils:: conversion functions
• May populate optional fields that OpModel leaves as defaults

Concrete Example: Conv2d Operation Inconsistency

OpModel Conv2d Query (TTNNOpModel.cpp:3264-3276):

auto conv2dOpQuery = [=]() {
  return ::ttnn::graph::query_op_constraints(
      ::ttnn::conv2d, device, inputSpec, weightSpec, device, in_channels,
      out_channels, batch_size, input_height, input_width,
      conversion::convertLLVMArrayRefToStdArray<uint32_t, 2>(kernel_size),
      conversion::convertLLVMArrayRefToStdArray<uint32_t, 2>(stride),
      conversion::convertLLVMArrayRefToMultiSizeStdArray<uint32_t, 2, 4>(padding),
      conversion::convertLLVMArrayRefToStdArray<uint32_t, 2>(dilation),
      groups, outputDtype, biasSpec, conv2dConfigConverted,
      deviceComputeKernelConfigConverted,
      detail::getNullableMemoryConfig(outputLayout));
};

Runtime Conv2d Call (runtime/lib/ttnn/operations/conv/conv2d.cpp:78-82):

ResultWithOptions result = ::ttnn::conv2d(
    input, weight, &targetDevice, op->in_channels(), op->out_channels(),
    op->batch_size(), op->input_height(), op->input_width(), kernelSize,
    stride, padding, dilation, op->groups(), outputDtype, bias, conv2dConfig,
    computeConfig, outputMemoryConfig, /*dram_slice_config_=*/std::nullopt);

Identified Parameter Inconsistencies

1. Conv2d Configuration:

   • OpModel: conv2dConfigConverted = conversion::getConv2dConfig(conv2dConfig)
   • Runtime: conv2dConfig = utils::createConv2dConfig(op->conv2d_config())

2. Compute Configuration:

   • OpModel: deviceComputeKernelConfigConverted = conversion::getDeviceComputeKernelConfig(deviceComputeKernelConfig)
   • Runtime: computeConfig = utils::createDeviceComputeKernelConfig(op->compute_config())

3. Memory Configuration:

   • OpModel: detail::getNullableMemoryConfig(outputLayout)
   • Runtime: outputMemoryConfig = createMemoryConfigIfNeeded(getTensorRefMemoryConfig(op->out()))

4. Missing Parameters:

   • OpModel: Missing dram_slice_config parameter entirely
   • Runtime: Explicitly passes /*dram_slice_config_=*/std::nullopt

Impact of Inconsistencies

• Validation Mismatch: OpModel may approve operations that fail at runtime
• Performance Differences: Different configurations may lead to different execution paths
• Debugging Complexity: Hard to trace whether issues come from parameter differences
• Maintenance Burden: Two separate codepaths for the same logical operation

Solution: Parameter Builder Pattern

Core Architecture

The Parameter Builder Pattern centralizes parameter construction logic by creating unified parameter packs that both invocation paths use:

// lib/OpModel/TTNN/ParameterBuilders/Conv2dParameterBuilder.h
namespace tt::opmodel::ttnn::params {

struct Conv2dParameterPack {
  // Core parameters (always required)
  uint32_t in_channels;
  uint32_t out_channels; 
  uint32_t batch_size;
  uint32_t input_height;
  uint32_t input_width;
  std::array<uint32_t, 2> kernel_size;
  std::array<uint32_t, 2> stride;
  std::variant<std::array<uint32_t, 2>, std::array<uint32_t, 4>> padding;
  std::array<uint32_t, 2> dilation;
  uint32_t groups;
  
  // Optional parameters (with explicit defaults)
  std::optional<::ttnn::DataType> output_dtype = std::nullopt;
  std::optional<::ttnn::Tensor> bias = std::nullopt;
  ::ttnn::operations::conv::Conv2dConfig conv2d_config = {};  // Default constructed
  std::optional<::ttnn::DeviceComputeKernelConfig> compute_config = std::nullopt;
  std::optional<::ttnn::MemoryConfig> output_memory_config = std::nullopt;
  std::optional<::ttnn::operations::conv::conv2d::Conv2dSliceConfig> dram_slice_config = std::nullopt;
  
  // Factory methods
  static Conv2dParameterPack fromMLIR(const Conv2dOp& op, ::ttnn::TensorSpec inputSpec);
  static Conv2dParameterPack fromFlatbuffer(const ::tt::target::ttnn::Conv2dOp* op, 
                                           ProgramContext& context);
  
  // Validation
  void validate() const;
  bool isEquivalent(const Conv2dParameterPack& other) const;
  
  // Invocation helpers
  template<typename OpFunc>
  auto invokeQuery(OpFunc opFunc, ::ttnn::MeshDevice* device, 
                   const ::ttnn::TensorSpec& input, const ::ttnn::TensorSpec& weight) const;
                   
  template<typename OpFunc>  
  auto invokeExecution(OpFunc opFunc, const ::ttnn::Tensor& input, 
                       const ::ttnn::Tensor& weight, ::ttnn::MeshDevice* device) const;
};

}

Key Innovation: Single Configuration Constructor

Instead of dual conversion functions, the parameter pack uses one unified builder:

// Current (Inconsistent)
auto config1 = conversion::getConv2dConfig(mlirAttr);      // May have different defaults
auto config2 = utils::createConv2dConfig(flatbuffer);     // May have different defaults

// Parameter Pack (Consistent)
auto pack1 = Conv2dParameterPack::fromMLIR(mlirOp);       // Same builder
auto pack2 = Conv2dParameterPack::fromFlatbuffer(fbOp);   // Same builder
// pack1.conv2d_config == pack2.conv2d_config (guaranteed identical)

Implementation Strategy

1. Adapter Pattern for Source Normalization

// Abstract interface
class ConfigSource {
public:
  virtual bool hasWeightsDtype() const = 0;
  virtual DataType getWeightsDtype() const = 0;
  virtual bool hasActivation() const = 0;
  virtual std::string getActivation() const = 0;
  // ... other config fields
};

// MLIR adapter
class MLIRConfigAdapter : public ConfigSource {
  Conv2dConfigAttr attr_;
public:
  bool hasWeightsDtype() const override { 
    return attr_ && attr_.getWeightsDtype(); 
  }
  DataType getWeightsDtype() const override { 
    return conversion::getDataType(attr_.getWeightsDtype().value()); 
  }
  // ...
};

// Flatbuffer adapter  
class FlatbufferConfigAdapter : public ConfigSource {
  const tt::target::ttnn::Conv2dConfig* config_;
public:
  bool hasWeightsDtype() const override { 
    return config_->weights_dtype() != nullptr; 
  }
  DataType getWeightsDtype() const override { 
    return utils::toTTNNDataType(*config_->weights_dtype()); 
  }
  // ...
};

2. Unified Factory Methods

// Single source of truth for building configs
static Conv2dConfig buildConv2dConfig(const ConfigSource& source) {
  Conv2dConfig config; // Default constructed
  
  // Unified logic for all config fields
  if (source.hasWeightsDtype()) {
    config.weights_dtype = source.getWeightsDtype();
  }
  if (source.hasActivation()) {
    config.activation = source.getActivation();
  }
  // ... all other fields with same logic
  
  return config;
}

// Factory methods use the SAME builder
static Conv2dParameterPack fromMLIR(const Conv2dOp& op) {
  Conv2dParameterPack pack;
  MLIRConfigAdapter adapter(op.getConv2dConfig()); 
  pack.conv2d_config = buildConv2dConfig(adapter);  // ← Same function
  return pack;
}

static Conv2dParameterPack fromFlatbuffer(const Conv2dOp* op) {
  Conv2dParameterPack pack;
  FlatbufferConfigAdapter adapter(op->conv2d_config());
  pack.conv2d_config = buildConv2dConfig(adapter);  // ← Same function  
  return pack;
}

3. Unified Invocation Points

// OpModel usage (TTNNOpModel.cpp)
auto conv2dOpQuery = [=]() {
  auto paramPack = Conv2dParameterPack::fromMLIR(op, inputSpec);
  return paramPack.invokeQuery(::ttnn::conv2d, device, inputSpec, weightSpec);
};

// Runtime usage (conv2d.cpp)
void run(const ::tt::target::ttnn::Conv2dOp *op, ProgramContext &context) {
  auto paramPack = Conv2dParameterPack::fromFlatbuffer(op, context);
  paramPack.validate(); // Runtime validation
  
  ResultWithOptions result = paramPack.invokeExecution(
    ::ttnn::conv2d, input, weight, &targetDevice);
  // ...
}

4. Built-in Validation & Testing

void Conv2dParameterPack::validate() const {
  assert(kernel_size[0] > 0 && kernel_size[1] > 0);
  assert(stride[0] > 0 && stride[1] > 0);
  // ... other validations
}

bool Conv2dParameterPack::isEquivalent(const Conv2dParameterPack& other) const {
  return in_channels == other.in_channels &&
         out_channels == other.out_channels &&
         // ... compare all fields including optional ones
         conv2d_config.weights_dtype == other.conv2d_config.weights_dtype;
}

// Test
TEST(Conv2dParameterConsistency, SameParametersFromBothSources) {
  auto mlirPack = Conv2dParameterPack::fromMLIR(mlirOp, inputSpec);
  auto runtimePack = Conv2dParameterPack::fromFlatbuffer(fbOp, context);
  
  EXPECT_TRUE(mlirPack.isEquivalent(runtimePack));
}

Benefits of the Parameter Builder Pattern

1. Single Source of Truth

• Parameter defaults defined once in the parameter pack struct
• Both paths use identical default values and conversion logic
• Changes to parameter handling happen in one place

2. Explicit Default Management

• No more relying on implicit TTNN defaults that may change
• All optional parameters have explicit, documented defaults
• Default construction ensures consistency across invocation paths

3. Validation & Testing

• Built-in parameter validation catches issues early
• isEquivalent() method enables automated consistency testing
• Clear contract for what constitutes "same parameters"

4. Maintainability

• Parameter handling logic centralized and reusable
• Adding new parameters requires updates in one place
• Type-safe parameter passing reduces runtime errors

5. Debugging Support

• Parameter packs can be logged/inspected for debugging
• Clear separation between parameter construction and invocation
• Easier to trace parameter transformation from source to TTNN call

6. Future-Proofing

• Easy to extend for new operation types
• Template-based design supports operation-specific customization
• Compatible with existing codebase architecture

Implementation Roadmap

1. Phase 1: Implement Conv2d parameter pack as prototype
2. Phase 2: Add validation and testing framework
3. Phase 3: Extend to other high-priority operations
4. Phase 4: Migrate remaining operations systematically

---

Current Parameter Inconsistencies Across All Operations

Operations Analysis Summary

Based on analysis of the codebase, 64 runtime operation files contain TTNN calls, while the OpModel contains 50+ query_op_constraints calls. Here are the major operations with dual invocation paths and their parameter inconsistencies:

1. Conv2d Operations

Files: conv/conv2d.cpp, conv/prepare_conv2d_weights.cpp, conv/prepare_conv2d_bias.cpp

OpModel Query:

::ttnn::conv2d, device, inputSpec, weightSpec, device, in_channels,
out_channels, batch_size, input_height, input_width, kernelSize, stride,
padding, dilation, groups, outputDtype, biasSpec, 
conv2dConfigConverted,                    // ← conversion:: function
deviceComputeKernelConfigConverted,       // ← conversion:: function
detail::getNullableMemoryConfig(outputLayout)

Runtime Call:

::ttnn::conv2d(input, weight, &targetDevice, op->in_channels(), op->out_channels(),
op->batch_size(), op->input_height(), op->input_width(), kernelSize,
stride, padding, dilation, op->groups(), outputDtype, bias, 
conv2dConfig,                             // ← utils:: function
computeConfig,                            // ← utils:: function
outputMemoryConfig, /*dram_slice_config_=*/std::nullopt)

Inconsistencies:

• Config construction: conversion::getConv2dConfig() vs utils::createConv2dConfig()
• Compute config: conversion::getDeviceComputeKernelConfig() vs utils::createDeviceComputeKernelConfig()
• Missing dram_slice_config in OpModel query

2. Matmul Operations

File: matmul/matmul.cpp

OpModel Query:

::ttnn::matmul, device, inputSpecA, inputSpecB, transposeA, transposeB,
outputMemoryConfig, outputDataType, matmulProgramConfig

Runtime Call:

::ttnn::matmul(lhs, rhs, op->transpose_a(), op->transpose_b(), outputMemoryConfig,
outputDataType, matmulProgramConfig,
/*activation=*/std::nullopt, /*compute_kernel_config=*/std::nullopt,
/*core_grid=*/std::nullopt, /*output_tile=*/std::nullopt,
/*optional_output_tensor=*/std::nullopt)

Inconsistencies:

• OpModel missing 5 optional parameters (activation, compute_kernel_config, core_grid, output_tile, optional_output_tensor)
• Program config construction: different conversion paths

3. Sigmoid Operation

File: eltwise/unary/unary.cpp

OpModel Query:

::ttnn::sigmoid, device, inputSpec, vectorMode, approximateMode,
detail::getNullableMemoryConfig(outputLayout)

Runtime Call:

::ttnn::sigmoid(in, static_cast<int>(::ttnn::operations::unary::VecMode::RC),
/*parameter=*/false, outputMemoryConfig, std::nullopt)

Inconsistencies:

• Different vectorMode values: OpModel uses VecMode::RC directly, Runtime casts to int
• Different approximateMode handling
• Missing output tensor parameter in OpModel

4. Softmax Operation

File: normalization/softmax.cpp

OpModel Query:

::ttnn::softmax, device, inputSpec, dimArg,
detail::getNullableMemoryConfig(outputLayout), std::nullopt, numericStable

Runtime Call:

::ttnn::softmax(in, dimension, outputMemoryConfig, std::nullopt, numericStable)

Inconsistencies:

• Parameter order difference: OpModel has compute_kernel_config between memory_config and numeric_stable
• OpModel passes std::nullopt for compute_kernel_config, Runtime omits it entirely

5. Reshape Operation

File: data_movement/reshape.cpp

OpModel Query:

::ttnn::reshape, device, inputSpec, conversion::getShape(outputShape),
detail::getNullableMemoryConfig(outputLayout)

Runtime Call:

::ttnn::reshape(in, shape, memoryConfig)

Inconsistencies:

• Memory config construction: Different helper functions
• Shape handling: OpModel uses conversion::getShape(), Runtime uses direct vector

6. Slice Operations

File: data_movement/slice.cpp

OpModel Query:

::ttnn::slice, device, inputSpec, beginsSpan, endsSpan, stepSpan,
detail::getNullableMemoryConfig(outputLayout), std::nullopt, std::nullopt

Runtime Call:

::ttnn::slice(in, begins, ends, step, memoryConfig)

Inconsistencies:

• OpModel passes extra std::nullopt parameters that Runtime omits
• Different span vs vector types

Common Parameter Inconsistency Patterns

Pattern 1: Dual Configuration Constructors

• OpModel: conversion::getXXXConfig()
• Runtime: utils::createXXXConfig()

Operations Affected: Conv2d, Matmul, DeviceComputeKernel configurations

Pattern 2: Missing Optional Parameters

• OpModel queries often missing optional parameters that Runtime calls include
• Example: Matmul missing 5 optional parameters

Operations Affected: Matmul, Linear, Most unary operations

Pattern 3: Memory Configuration Handling

• OpModel: detail::getNullableMemoryConfig(outputLayout)
• Runtime: createMemoryConfigIfNeeded(getTensorRefMemoryConfig(op->out()))

Operations Affected: All operations with memory configuration

Pattern 4: Parameter Order Differences

• Same parameters passed in different orders between OpModel and Runtime

Operations Affected: Softmax, some ternary operations

Impact Assessment by Priority

High Priority (Immediate Risk)

1. Conv2d: Most complex config objects, highest inconsistency risk
2. Matmul: Missing 5 parameters, widely used operation
3. Memory Config: Affects all operations, different construction logic

Medium Priority

4. Softmax: Parameter order inconsistency
5. Sigmoid: Different mode handling
6. Unary Operations: Inconsistent approximation mode handling

Low Priority

7. Reshape: Minor shape conversion differences
8. Slice: Extra nullopt parameters in OpModel

Estimated Operations Requiring Parameter Builders

Based on the analysis:

• 20+ operations have significant parameter inconsistencies
• 40+ operations have minor inconsistencies (memory config, optional params)
• 64 runtime files total would benefit from unified parameter handling

The parameter builder pattern would address all these inconsistencies by providing a single, unified parameter construction and validation system for each operation type.

[rpavlovicTT]

Additional Critical Issue: ConstantOp API Divergence

Beyond the parameter inconsistencies documented above, there is a more fundamental API-level inconsistency affecting ConstantOp:

ConstantOp Dual API Problem

OpModel Implementation:

return ::ttnn::graph::query_op_constraints(
    ::ttnn::from_buffer, device, rawData, getShape(value),
    getDataType(value), device, metalLayout,
    detail::getNullableMemoryConfig(outputLayout));

Runtime Implementation:

::ttnn::Tensor out = utils::toTTNNTensor(op->data(), shape, dtype, meshDevice, layout, memoryConfig);
// Which internally calls:
::ttnn::Tensor tensor = ::ttnn::Tensor::from_vector(data, tensorSpec, device);

The Problem

This represents a fundamental architectural inconsistency where:

• OpModel uses ::ttnn::from_buffer API directly
• Runtime uses ::ttnn::Tensor::from_vector via wrapper functions

This goes beyond parameter mismatches - it's entirely different TTNN APIs being used for the same logical operation, potentially causing different tensor creation behavior, memory layouts, and runtime characteristics.

Solution Integration

The parameter builder pattern should be extended to handle API consistency in addition to parameter consistency. For ConstantOp, this means:

struct ConstantOpParameterPack {
  // Unified data and parameters
  // Single tensor creation method that both paths use
  ::ttnn::Tensor createTensor() const;
  auto queryConstraints(device) const;
};

This ensures both validation and execution use identical tensor creation logic, eliminating both parameter inconsistencies and API-level divergence.

[azecevicTT]

This would also be solved with the common API. if I got it right,

  ::ttnn::Tensor createTensor() const;
  auto queryConstraints(device) const;

these two functions would still be implemented independently, so the risk of having inconsistent implementation would still be there, albeit it would be smaller because the implementations are physically closer in the code.

[azecevicTT]

I'm probably missing something, but I don't see how this would result in a consistent result across components. The biggest issue is that the input into the runtime and OpModel conversions are different, though they are transitively related. As I understand it, isEquivalent is something that should verify that FB and TTNN dialect, which represent inputs to the runtime and OpModel conversions, respectively, result in the same output configuration. As you've mentioned here

// Test
TEST(Conv2dParameterConsistency, SameParametersFromBothSources) {
  auto mlirPack = Conv2dParameterPack::fromMLIR(mlirOp, inputSpec);
  auto runtimePack = Conv2dParameterPack::fromFlatbuffer(fbOp, context);
  
  EXPECT_TRUE(mlirPack.isEquivalent(runtimePack));
}

this can indeed be useful for testing, but what I'm struggling with is that I cannot find some other place where this would be useful (at least as it stands for now). What we have is

TTNN dialect -- OpModel --> TTNN lib
    |                            ^
 TTNN2FB                         |
    |                            |
    v                            |
    FB --- runtime conversions ---

and what we want is to verify that starting from the same TTNN dialect op, we end up with the same lib op. So the question of composability can be (and should be) tested regardless of which approach we take. There are a few problematic configs like (Conv2dConfig, MatmulProgramConfig etc.) where we should test that

opmodel_conversion::x(ttnnAttr) == fb_to_runtime::x(ttnn_to_fb::x(ttnnAttr));

This, of course, wouldn't guarantee that the calls won't be inconsistent, but at least if would give us some level of confidence that individual parameters are correctly converted. We can sync offline tomorrow to iterate faster through this idea, as there might be important pieces that I miss here.

One idea that I had for some time now is that we should design our own TTNN API (let's call it ttmlirnn for the sake of discussion). It would be a thin wrapper around TTNN library. It does have some similarities with your suggestion, but it's probably a more lightweight version of it. Basically, most functions would look like

ttnn::Tensor ttmlirnn::add(ttnn::Tensor a, ttnn::Tensor b, whatever) {
  return ttnn::add(a, b, whatever);
}

but there could also be something like

ttnn::Tensor ttmlirnn::sigmoid(ttnn::Tensor input, ttnn::MemoryConfig memoryConfig) {
  return ttnn::sigmoid(input, VecMode::RC, false, memoryConfig);
}

IMO, this has several advantages:

• some params that we don't model at all at the dialect level (like VecMode in sigmoid) are guaranteed to be fixed and consistent across components
• some params like MemoryConfig that is std::optional in TTNN shouldn't be optional in our use case; again, this guarantees some level of consistency
• when TTNN API changes we only have to make a change in one place; currently we are doing it in at least three places (runtime, OpModel, EmitC)
• some ops that don't map directly to some TTNN op could be implemented here
• this is bonus advatage that I can't guarantee would work, but I'm pretty confident that without function overloading we could circumvent explicit calling of conversion::llvmArrayRefEtc(...) etc., and just do calls with LLVM and FB types directly and do the appropriate conversion under the hood, which would make a nice interface addition

Some disadvantages:

• graph_query_op_constraints.hpp would have to reside in tt-mlir; if we are the only users of this API perhaps it's not a disadvantage, and this API should reside in tt-mlir repo?
• if we do this for EmitC as well, we lose the portability, so the choice would have to be made regarding EmitC, but having our own API, and using TTNN directly for EmitC is also a sound option

To add to the last point, we would also have to add a pybindings for EmitPy if we want to use that new API, albeit I think we would still want to use TTNN directly for EmitPy for portability reasons.

With proper testing of the aforementioned non-trivial conversions, this would mitigate almost all of the risks of inconsistency, even though it wouldn't be able to always guarantee consistency (I'm pretty sure that's impossible with the current architecture).

[rpavlovicTT]

I agree we can't reach ultimate single point definition for conversions. My proposal is more towards having unified operation call builder. So we avoid inconsistencies where we call different API for an operation, or we pass different number of parameters because some of them have defaults.

Also, we can reduce number of utilities across our code. For example in conv2d op invocation we use

TTNNOpModel.cpp

conversion::convertLLVMArrayRefToMultiSizeStdArray<uint32_t, 2, 4>(
            padding),

conv2d.cpp

  std::variant<std::array<uint32_t, 2>, std::array<uint32_t, 4>> padding;
  if (op->padding()->size() == 2) {
    std::array<uint32_t, 2> symPadding;
    std::copy_n(op->padding()->begin(), 2, symPadding.begin());
    padding = symPadding;
  } else {
    std::array<uint32_t, 4> asymPadding;
    std::copy_n(op->padding()->begin(), 4, asymPadding.begin());
    padding = asymPadding;
  }

Another potential idea comes to me, and that is to have Flatbuffer as our main OP representation (like you mentioned thin wrapper), but instead of having 3rd IR format, let's use existing one from FB. And then all we need to do is to convert MLIR->FB and from then on all conversions and builders are same.

For example:

  Simplified Parameter Pack

  struct Conv2dParameterPack {
    // Factory methods
    static Conv2dParameterPack fromMLIR(const Conv2dOp& op, ...) {
      // Convert MLIR to flatbuffer using existing infrastructure
      auto fbBuilder = convertOpToFlatbuffer(op);
      auto fbOp = getFlatbufferOp(fbBuilder.get());

      // Use single canonical path
      return fromFlatbuffer(fbOp, context);
    }

    static Conv2dParameterPack fromFlatbuffer(const ::tt::target::ttnn::Conv2dOp* op, ...) {
      // This is now the ONLY implementation
      return Conv2dParameterPack{
        .conv2d_config = utils::createConv2dConfig(op->conv2d_config()),
        .compute_config = utils::createDeviceComputeKernelConfig(op->compute_config()),
        // ... all using utils:: functions
      };
    }
  };

What makes this easy solution is that we already have TTNNToFlatbuffer lib. Anyway let's talk in person and discuss.

[azecevicTT]

That makes a lot of sense to me. With that approach, this picture

TTNN dialect -- OpModel --> TTNN lib
    |                            ^
 TTNN2FB                         |
    |                            |
    v                            |
    FB --- runtime conversions ---

becomes

TTNN dialect                TTNN lib
    |                            ^
 TTNN2FB                         |
    |                            |
    v                            |
    FB --- runtime conversions ---

which means we no longer need to 'prove' commutativity of the graph, because there is only one path.

If we take that approach, isEquivalent now becomes pretty much redundant, and validate could be a private member function that's called after each construction (depending on the API and implementation, but the idea is that it should be called each time in debug mode and never in the release).