CRDs list things like instructions, CSRs, and traps that aren't in the configuration

[james-ball-qualcomm]

[james-ball-qualcomm]

There is only one I extension, not an RV32I and a RV64I. Therefore, when I ask the I extension for all its instructions, I get 32 and 64 versions. I see there is an optional base field in the instruction schema. I assume I should filter out instructions based on the portfolio's base value. Is this correct?

[dhower-qc]

Correct. You can do something like ext.instructions.select { |i| i.base != 64 }

[james-ball-qualcomm]

Seems like I should be asking the Extension object for a list of instructions and pass it enough information for it to figure out what is present or not. I don't know if an Extension has things like base or maybe even parameters that control what instructions are actually present. BTW, are there any cases yet like that where a parameter controls what instructions are present? If not, is that something we should plan for? Same goes for CSRs. Since everything in UDB is built around extensions, seems like I should be asking the extension for its instructions and CSRs.

BTW, I see this function below in the Extension class that calls arch_def.implemented_instructions. Seems like we should relax this to accept a partially defined arch_def too. Why don't we?

# @return [Array<Csr>] the list of CSRs implemented by this extension version (may be empty)
  def implemented_instructions(archdef)
    raise "should only be called with a fully configured arch def" unless archdef.fully_configured?

    return @implemented_instructions unless @implemented_instructions.nil?

    @implemented_instructions = archdef.implemented_instructions.select do |inst|
      inst.defined_by?(self)
    end
  end
end

[james-ball-qualcomm]

Waiting for Derek to refactor arch_def to have one Ruby object for everything possible in the RISC-V architecture standards and another Ruby object to have just what is in a particular configuration (whether configured, partially configured, or fully configured).

[james-ball-qualcomm]

After refactoring (see PR #386) was able to fix this for instructions and CSRs on my own. I created in_scope_instructions and in_scope_csrs in ExtensionVersion. I use the minimum extension version that meets the extension requirements and then call this code (similar for CSRs). The main addition is the extra conditions around the base.

  # @param design [Design] The design
  # @return [Array<Instruction>] List of instructions in-scope for this design for this extension version (may be empty)
  #                              Factors in effect of design's xlen in the appropriate mode for the instruction.
  def in_scope_instructions(design)
    raise ArgumentError, "Require a Design object but got a #{design.class} object" unless design.is_a?(Design)

    return @in_scope_instructions unless @in_scope_instructions.nil?

    @in_scope_instructions = @arch.instructions.select do |inst|
      inst.defined_by?(self) &&
      (inst.base.nil? || (design.possible_xlens.include?(inst.base)))
    end
  end
end

[james-ball-qualcomm]

I did some work on exception codes and interrupt codes and then paused it until I get Derek's help.

I created in_scope_exception_codes and tried copying from implemented_exception_codes in Design as follows

But the problem is that I don't have good understanding/examples of how an extension should make it codes conditional. I see there's some provision for this with "when" statements in the ext schema and some use of it in the copied code. However, what I don't see is something in extension arch files making certain exception codes conditional. For example, the instruction address misaligned exception can't occur if the C extension is present. This "when" condition doesn't seem to be present in the database.

[james-ball-qualcomm]

Just saw this code in the Certificate/Profile ERB templates. Maybe should be asking instructions which exception they generate instead of asking extensions which exceptions they generate?

[james-ball-qualcomm]

Hummm, reachable_exceptions has it problems too. For example, it claims lb can generate misaligned exception. And page fault (this is for MC100-32 without virtual memory).