Does origen_testers V93K support test method libraries with different classes? - origen-sdk

We have custom test method libraries that support a couple different test method classes. For example:
test93k.common.Functional
test93kcustomext.common.Functional
Would I need to create different test method libraries in our test interface using the add_tml method or can they both exist in the same test method library? In the end, we need the correct class to show up in the generated flow as so:
testmethods
tm_jtag_regular:
testmethod_class = "test93k.common.Functional";
tm_jtag_extension:
testmethod_class = "test93kcustomext.common.Functional";
What controls the test that goes above?
regards

You can apply a class_name: option to both the library and the individual tests, so you could try:
add_tml :my_tml,
class_name: '', # Try setting this to nothing
functional: {
class_name: 'test93k.common.Functional',
},
functional_ext: {
class_name: 'test93kcustomext.common.Functional',
}
There's a chance that the final name might end up with a leading ., though it should be a simple patch to make it inhibit that if the TML class name is blank.
Defining them as two separate TMLs would definitely work too, and is probably how it should be handled:
add_tml :regular,
class_name: 'test93k.common',
functional: {
class_name: 'Functional', # May not even need this
}
add_tml :ext,
class_name: 'test93kcustomext.common',
functional: {
class_name: 'Functional', # May not even need this
}
See here for more - https://origen-sdk.org/origen/guides/program/v93k/#Custom_Test_Methods

Related

test_ids gem allow for bin grouping based on test metadata?

Is there a way for the test_ids gem to group tests such that the same softbin gets assigned? For example, here are 3 tests passed in the flow file:
func :test1, speed: 1000, vdd: :vmin
func :test2, speed: 1200, vdd: :vmin
func :test3, speed: 1000, vdd: :vmax
Would like to be able to tell test_ids gem to group by :vdd and get the following softbins assigned (assume the range is 200-299):
200, func_vmin
201, func_vmax
If I passed speed as the grouping arg I would get the following softbins:
200, func_1000
201, func_1200
The examples shown above only pass one piece of metadata but the ask would be that any combination of test metadata could be used to create the softbin group name.
thx
With no special options, the test IDs plugin will use the test name as a unique ID. In that case, tests with different names will be assigned different test numbers, bins and softbins, while tests with the same name will use the same numbers.
Sometimes, like in this case, it is desired for differently named tests to share all or some of their number allocations, and there are a few options available to control this.
Firstly, you can supply a test_id: option, this explicitly defines the ID that should be used for the test when assigning numbers, now your tests will all have the same test numbers, bins and softbins:
func :test1, speed: 1000, vdd: :vmin, test_id: :t1
func :test2, speed: 1200, vdd: :vmin, test_id: :t1
func :test3, speed: 1000, vdd: :vmax, test_id: :t1
This can be further fine-tuned by supplying number:, bin: and/or softbin: options with symbol values and these will be used as the test ID when assigning that specific number type.
For example, this will assign the softbin as you want based on vdd:
func :test1, speed: 1000, vdd: :vmin, softbin: :func_vmin
func :test2, speed: 1200, vdd: :vmin, softbin: :func_vmin
func :test3, speed: 1000, vdd: :vmax, softbin: :func_vmax
This is covered in the docs here - https://origen-sdk.org/test_ids/#Multiple_Instances_of_the_Same_Test
Use your test program interface to programatically assign the IDs based on your business rules, for example in your func method:
def func(name, options)
options[:softbin] = "func_#{options[:vdd] || :nom}".to_sym
# ...
end
It is recommended to have all of your test handlers like this func method handover to a single method to add the test to the flow - https://origen-sdk.org/origen//guides/program/interface/#Detecting_Changes_in_the_Execution_Context
That would then give you a single place to implement more global rules like using vdd. vs. speed to group by.
For example, if you wanted to group by the test type and then speed, you could do something like:
def func(name, options)
options[:softbin] = "func"
# ...
add_to_flow(my_test, options)
end
def add_to_flow(test, options)
if group_by_speed?
options[:softbin] = "#{options[:softbin]_#{options[:speed] || 1000}".to_sym
else
options[:softbin] = "#{options[:softbin]_#{options[:vdd] || :nom}".to_sym
end
# ...
end

How do I declare and use a variable in the yaml file that is formatted for pyresttest?

So, a brief description of what I want, what my issue is, and what I have tried.
I want to declare and use a dictionary variable for my tests in pyrest, specifically for the [url, body] section so that I can conduct my POST tests targeting a specific endpoint and with a preformatted body.
Here is how mytest.yml file is structured:
- data:
- id: 63
- rate: 25
... a sizable set of field for reasons ...
- type: lab_test_authorization
- modified_at: ansible_date_time.datetime # Useful way to generate
- test:
- url: "some-valid-url/{the_url_question}" # data['special_key']
- method: 'POST'
- headers : {etc..etc}
- body: '{ "data": ${the_body_question} }' # data (the content)
Now the problem starts in my lack of understanding why (if true) does pyrest does not have support for dictionary mappings. I understand yaml supports these feature but am not sure if pyrest can parse through it. Knowing how to call and use dictionary variable in my url and body tags would be significantly helpful.
As of right now, if I try to convert my data Sequence into a data Dictionary, I will get an error stating:
yaml.parser.ParserError: while parsing a block mapping
in "<unicode string>", line 4, column 1:
data:
^
expected <block end>, but found '-'
in "<unicode string>", line 36, column 1:
- config:
I'm pretty sure there are gaps in my knowledge regarding how yaml and pyresttest interact with each other, so any insight would be greatly appreciated.

Sub_block base_address override?

Is there a way to assign a different base_address to the sub_blocks of a sub_block?
I have a case where I have something like this:
dut.rb:
sub_block ipBlock base_address: 0x11000000
and so the registers at this level all start with 0x110000000
But ipBlock also has its own sub_blocks:
ipblock.rb:
sub_block subIPBlock base_address: 0x0
with its own registers that due to an interface difference require a 0 base_address.
Unfortunately, when I add registers to subIPBlock they still have the base address of the top-level ipBlock:
sub_ipblock.rb:
add_reg :reg0, 0x0, 16, reset: 0xFFFF ...
Is there is a way to easily reassign the base address of the sub_block of a sub_block?
I believe you can use sub-block domains to achieve what you want.
sub_block :subx2, class_name: "SubX", base_address: { ips: 0x2000_0000, ahb: 0x3000_0000 }
dut.subx1.reg1.address(domain: :ips) # => 0x2000_0200
dut.subx1.reg1.address(domain: :ahb) # => 0x3000_0200
regards
In addition to the other answer, also note that reg.offset will return the block relative address, which it sounds like you want here.
All Origen drivers should override the register's address when an :address option is given, so within your model you could implement a read/write register method to add an :address option:
def write_register(reg, options = {})
if your_criteria_to_use_local_address
options[:address] = reg.offset
end
dut.write_register(reg, options) # Handover for original write
end
You could also force/override the base address within your model by implementing the following method:
def reg_base_address(options = {})
0
end
Finally, note that when using the domains per #rchitect-of-info's answer, you can define two domains when you instantiate a parent sub-block, then when you instantiate a child of that sub-block you can pick which of the available domains it is assigned to.
See this example from the documentation linked to in the other answer:
$dut.subx2.suby1.reg1.address # => 0x2000_0300
$dut.subx2.suby2.reg1.address # => 0x3000_0300

hiera() function and YAML hash lookups

How do I rewrite this YAML so it is more structured, then reference it in Puppet using hiera function?
Currently, I am working with a hieradata syntax that looks very flat and hard to read.
service::proxy::behind_reverse_proxy: true
service::proxy::proxy_timeout: 300
service::proxy::serverlist:
- host1.fqdn
- host2.fqdn
And grabbed these in a params.pp file, for example
$behind_reverse_proxy = hiera('service::proxy::behind_reverse_proxy', 'False')
$serverlist = hiera('service::proxy::serverlist')
I thought I could rewrite the YAML like so in an effort to make it more readable...
service::proxy:
behind_reverse_proxy: true
proxy_timeout: 300
serverlist:
- host1.fqdn
- host2.fqdn
And updated the params.pp file according to
Hiera Key.subkey syntax
interacting with structured data
$behind_reverse_proxy = hiera('service::proxy.behind_reverse_proxy', 'False')
$serverlist = hiera('service::proxy.serverlist')
However upon puppet agent -t that resulted in
Error 400 on SERVER: Could not find data item service::proxy.serverlist in any Hiera data file and no default supplied
I think these are relevant
[user#server ~]$ facter -y | grep 'version'
facterversion: 2.4.4
puppetversion: 3.8.2
Following up on my comment about how you can access your restructured data:
service::proxy:
behind_reverse_proxy: true
proxy_timeout: 300
serverlist:
- host1.fqdn
- host2.fqdn
In your manifest, instead of this ...
$behind_reverse_proxy = hiera('service::proxy.behind_reverse_proxy', 'False')
$serverlist = hiera('service::proxy.serverlist')
... you might do this:
$proxy_info = merge(
{ 'behind_reverse_proxy' => false, 'serverlist' => [] },
hiera('service::proxy', {})
)
$behind_reverse_proxy = $proxy_info{'behind_reverse_proxy'}
$serverlist = $proxy_info{'serverlist'}
The merge() function is not built-in, but rather comes from Puppet's (formerly PuppetLabs's) widely-used stdlib module. There's a good chance that you are already using that module elsewhere, but even if not, it may be well worth your while to introduce it to your stack.
I've never used Hiera, but I think the problem is that you have a sequence (array) when you wanted a mapping (hash).
In the below YAML, the value of the service::proxy key is a sequence with three elements, each of which is a mapping with one key:
service::proxy:
- behind_reverse_proxy: true
- proxy_timeout: 300
- serverlist:
- host1.fqdn
- host2.fqdn
What you probably wanted, though, was for service::proxy to be a mapping with three keys:
service::proxy:
behind_reverse_proxy: true
proxy_timeout: 300
serverlist:
- host1.fqdn
- host2.fqdn
The examples in the Hiera docs you linked to seem to support this.

Alex lex.x compilation : Not in scope 'begin'

I have the below statements in Lex.x to parse block comments.
<0> "//".* { tokWValue LTokComment }
<0> "/*" { begin blockcomment }
<blockcomment> "*/" { begin 0 }
<blockcomment> . { tokWValue LTokComment }
But If I generate Lex.hs using Alex, it does not add the 'begin' function.
This results in the below compilation error.
src/Lex.x:367:18: Not in scope: ‘begin’
src/Lex.x:368:18: Not in scope: ‘begin’
Any idea what might be wrong?
I am using wrapper 'posn'
Start codes are only available when using any of the monad-... wrappers.
If you read the docs for the monad wrapper -- Section 5.3.3 - The "monad" wrapper -- you see that it is the first wrapper which keeps track of the start code.
You can also verify this by finding the alex wrapper files -- look for the directory containing the files AlexWrapper-basic, AlexWrapper-posn, etc. On OS X when installing the Haskell Platform they are located in a directory like /Library/Haskell/ghc-7.10.2-x86_64/share/alex-3.1.4. The functions begin and andBegin only occur in the monad-related wrappers.

Resources