Conversation
| { | ||
| } | ||
| for @index = 0; @index < @loop ; @index = @index + 1; do | ||
| test_number_loop_increment = 0 |
There was a problem hiding this comment.
What's this test_number_loop_increment ?
There was a problem hiding this comment.
@info-rchitect is this something that just needs to be removed from here?
| else | ||
| { | ||
| } | ||
| for @index = 0; @index < @loop ; @index = @index + 1; do |
There was a problem hiding this comment.
I doubt this is valid smt8, its fine to not support it on SMT8 yet, but in that case either output nothing and emit a warning, or else raise an error rather than generating garbage.
There was a problem hiding this comment.
@info-rchitect can you look at this? adding it in a tester.smt7? check should be okay
|
@rlaj Can you please review this PR as it uses the ATP |
| if index_flag.is_a?(String) | ||
| line "for @#{index_flag} = #{loop_start}; @#{index_flag} < #{loop_end} ; @#{index_flag} = @#{index_flag} + #{loop_inc}; do" | ||
| else | ||
| line "for @index = #{loop_start}; @index < #{loop_end} ; @index = @index + #{loop_inc}; do" |
There was a problem hiding this comment.
I think you need to generate something more unique than just @index, e.g. consider the case of nested loops.
If you look around in here there should be other examples of generating unique ids.
There was a problem hiding this comment.
@ginty Is that the responsibility of Origen? Seems like that should be up to the user similar to how one would use different variables in a C for loop.
There was a problem hiding this comment.
Yes, this is the kind of detail that a framework should take care of
There was a problem hiding this comment.
Also consider the Origen API is trying to be as ATE-agnostic as possible. If a user only wants to loop X times, then they should be able to express that without worrying about flow vars. Such things may not even make sense on other platforms.
There was a problem hiding this comment.
Also consider the Origen API is trying to be as ATE-agnostic as possible. If a user only wants to loop X times, then they should be able to express that without worrying about flow vars. Such things may not even make sense on other platforms.
The current ATP loop API allows the user to pass an integer or a string representing a flow variable for the to option. Wouldn't we just handle that in each of the tester generators? If a particular generator does not use an option available in the ATP flow method then it errors and instructs the user.
There was a problem hiding this comment.
This is the way Origen works man, with the current loop API I would and should expect this to just work:
loop from: 1, to: dut.number_of_x, step: 1 do
loop from: 1, to: dut.number_of_y, step: 1 do
func :some_test
end
endIf the v93k needs a flow var to be defined to enable that to work, then its Origen's responsibility to create one (if the user doesn't care about what it's called), and make sure what it is creating will work in cases like the above.
Open questions:
thx