when I'm running a sequence library in UVM, I got such error: "[SEQLIB/START] Starting sequence library top_random_seq_lib_v1 in unknown phase: 10 iterations in mode UVM_SEQ_LIB_RANDC". I'm confused why there is message on "unknown phase" because I start this sequence library in main phase. It seems this sequence library doesn't work correct. Can anybody help me to identify where could be the problem? thanks.
My code is something like this:
class digit_top_base_random_test2 extends digit_top_base test;
......
top_random_seq_lib_v1 m_seq_master; // this is my sequence library for master
top_random_seq_lib_v1 m_seq_slave; // this is my sequence library for slave
base_sequence m_base_seq_master;
base_sequence m_base_seq_slave;
........
virtual function void build_phase(uvm_phase phase);
....
m_seq_master=top_random_seq_lib_v1::type_id::create("m_seq_master");
m_seq_slave=top_random_seq_lib_v1::type_id::create("m_seq_slave");
endfunction
virtual task configure_phase(uvm_phase phase);
super.configure_phase(phase);
m_seq_master.selection_mode = UVM_SEQ_LIB_RANDC;
m_seq_master.min_random_count=1;
m_seq_master.max_random_count=5;
m_seq_master.add_typewide_sequence(m_base_seq_master.get_type());
m_seq_slave.selection_mode = UVM_SEQ_LIB_RAND;
m_seq_slave.min_random_count=1;
m_seq_slave.max_random_count=5;
m_seq_slave.add_typewide_sequence(m_base_seq_slave.get_type());
m_seq_master.init_sequence_library();
m_seq_slave.init_sequence_library();
endtask
........
virtual task main_phase(uvm_phase phase);
super.main_phase(phase);
phase.raise_objection(this);
m_seq_master.start(m_digit_top_env.m_agent_master.m_seqr0);
m_seq_slave.start(m_digit_top_env.m_agent_slave.m_seqr0);
phase.drop_objection(this);
endtask
endclass
After several day's debug, finally I found the answer: I typed wrong code which result in wrong sequencer allocation. That wrong code doesn't show in my post. After correct that mistake the code works fine. Thanks for those people who have reviewed this post.
Related
Reading through https://docs.perl6.org/language/packages#Package-qualified_names it outlines qualifying package variables with this syntax:
Foo::Bar::<$quux>; #..as an alternative to Foo::Bar::quux;
For reference the package structure used as the example in the document is:
class Foo {
sub zape () { say "zipi" }
class Bar {
method baz () { return 'Þor is mighty' }
our &zape = { "zipi" }; #this is the variable I want to resolve
our $quux = 42;
}
}
The same page states this style of qualification doesn't work to access &zape in the Foo::Bar package listed above:
(This does not work with the &zape variable)
Yet, if I try:
Foo::Bar::<&zape>; # instead of &Foo::Bar::zape;
it is resolves just fine.
Have I misinterpreted the document or completely missed the point being made? What would be the logic behind it 'not working' with code reference variables vs a scalar for example?
I'm not aware of differences, but Foo::Bar::<&zape> can also be modified to use {} instead of <>, which then can be used with something other than literals, like this:
my $name = '&zape';
Foo::Bar::{$name}()
or
my $name = 'zape';
&Foo::Bar::{$name}()
JJ and Moritz have provided useful answers.
This nanswer is a whole nother ball of wax. I've written and discarded several nanswers to your question over the last few days. None have been very useful. I'm not sure this is either but I've decided I've finally got a first version of something worth publishing, regardless of its current usefulness.
In this first installment my nanswer is just a series of observations and questions. I also hope to add an explanation of my observations based on what I glean from spelunking the compiler's code to understand what we see. (For now I've just written up the start of that process as the second half of this nanswer.)
Differences (if any) between Package::<&var> vs &Package::var?
They're fundamentally different syntax. They're not fully interchangeable in where you can write them. They result in different evaluations. Their result can be different things.
Let's step thru lots of variations drawing out the differences.
say Package::<&var>; # compile-time error: Undeclared name: Package
So, forget the ::<...> bit for a moment. P6 is looking at that Package bit and demanding that it be an already declared name. That seems simple enough.
say &Package::var; # (Any)
Quite a difference! For some reason, for this second syntax, P6 has no problem with those two arbitrary names (Package and var) not having been declared. Who knows what it's doing with the &. And why is it (Any) and not (Callable) or Nil?
Let's try declaring these things. First:
my Package::<&var> = { 42 } # compile-time error: Type 'Package' is not declared
OK. But if we declare Package things don't really improve:
package Package {}
my Package::<&var> = { 42 } # compile-time error: Malformed my
OK, start with a clean slate again, without the package declaration. What about the other syntax?:
my &Package::var = { 42 }
Yay. P6 accepts this code. Now, for the next few lines we'll assume the declaration above. What about:
say &Package::var(); # 42
\o/ So can we use the other syntax?:
say Package::<&var>(); # compile-time error: Undeclared name: Package
Nope. It seems like the my didn't declare a Package with a &var in it. Maybe it declared a &Package::var, where the :: just happens to be part of the name but isn't about packages? P6 supports a bunch of "pseudo" packages. One of them is LEXICAL:
say LEXICAL::; # PseudoStash.new(... &Package::var => (Callable) ...
Bingo. Or is it?
say LEXICAL::<&Package::var>(); # Cannot invoke this object
# (REPR: Uninstantiable; Callable)
What happened to our { 42 }?
Hmm. Let's start from a clean slate and create &Package::var in a completely different way:
package Package { our sub var { 99 } }
say &Package::var(); # 99
say Package::<&var>(); # 99
Wow. Now, assuming those lines above and trying to add more:
my Package::<&var> = { 42 } # Compile-time error: Malformed my
That was to be expected given our previous attempt above. What about:
my &Package::var = { 42 } # Cannot modify an immutable Sub (&var)
Is it all making sense now? ;)
Spelunking the compiler code, checking the grammar
1 I spent a long time trying to work out what the deal really is before looking at the source code of the Rakudo compiler. This is a footnote covering my initial compiler spelunking. I hope to continue it tomorrow and turn this nanswer into an answer this weekend.
The good news is it's just P6 code -- most of Rakudo is written in P6.
The bad news is knowing where to look. You might see the doc directory and then the compiler overview. But then you'll notice the overview doc has barely been touched since 2010! Don't bother. Perhaps Andrew Shitov's "internals" posts will help orient you? Moving on...
In this case what I am interested in is understanding the precise nature of the Package::<&var> and &Package::var forms of syntax. When I type "syntax" into GH's repo search field the second file listed is the Perl 6 Grammar. Bingo.
Now comes the ugly news. The Perl 6 Grammar file is 6K LOC and looks super intimidating. But I find it all makes sense when I keep my cool.
Next, I'm wondering what to search for on the page. :: nets 600+ matches. Hmm. ::< is just 1, but it is in an error message. But in what? In token morename. Looking at that I can see it's likely not relevant. But the '::' near the start of the token is just the ticket. Searching the page for '::' yields 10 matches. The first 4 (from the start of the file) are more error messages. The next two are in the above morename token. 4 matches left.
The next one appears a quarter way thru token term:sym<name>. A "name". .oO ( Undeclared name: Package So maybe this is relevant? )
Next, token typename. A "typename". .oO ( Type 'Package' is not declared So maybe this is relevant too? )
token methodop. Definitely not relevant.
Finally token infix:sym<?? !!>. Nope.
There are no differences between Package::<&var> and &Package::var.
package Foo { our $var = "Bar" };
say $Foo::var === Foo::<$var>; # OUTPUT: «True»
Ditto for subs (of course):
package Foo { our &zape = { "Bar" } };
say &Foo::zape === Foo::<&zape>;# OUTPUT: «True»
What the documentation (somewhat confusingly) is trying to say is that package-scope variables can only be accessed if declared using our. There are two zapes, one of them has got lexical scope (subs get lexical scope by default), so you can't access that one. I have raised this issue in the doc repo and will try to fix it as soon as possible.
does anyone use arima.rob() function described by Eric Zivot and Jiahui Wang in { Modelling Financial Time Series with S-PLUS } ?
I have a question about it:
I used a dataset of network traffic flows that has anomaly, and I tried to predict the last part of dataset by robust ARIMA method (Arima.rob() function) .I compare this model with arima.mle of S-PLUS. But Unexpectedly, arima.rob’s prediction did not better than that.
I’m not sure my codes are correct and may be the reason of fault is my codes.
Please, help me if I used Arima.rob inappropriately?
tmp.rr<-arima.rob((tmh75)~1,p=2,d=1,q=2,freq=24,maxiter=4,max.fcal=80000)
tmp.for<-predict(tmp.rr,n.predict=10,newdata=df1,se=T)
plot(tmp.for,tmh75)
summary(tmp.for)
my code for classic arima:
`model <- list(list(order=c(2,1,2)),list(order=c(3,1,2),period=24))
fith <- arima.mle(tmh75-mean(tmh75),model=model)
foreh <- arima.forecast(tmh75,n=25,model=fith$model)
tsplot(tmh75,foreh$mean,foreh$mean+foreh$std.err,foreh$mean-foreh$std.err)
`
I have a virtual sequencer from which I execute three transactions in parallel, each one on its corresponding sequencer. So I have something like this:
class top_vseqr extends uvm_seqr extends uvm_sequencer;
type_a_seqr seqr_a;
type_b_seqr seqr_b;
type_c_seqr seqr_c;
...
endclass: top_vseqr
class simple_vseq extends uvm_sequence;
`uvm_declare_p_sequencer(top_vseqr)
type_a_seq seq_a;
type_b_seq seq_b;
type_c_seq seq_c;
...
virtual task body();
fork
`uvm_do_on(seq_a, p_sequencer.seqr_a)
`uvm_do_on(seq_b, p_sequencer.seqr_b)
`uvm_do_on(seq_c, p_sequencer.seqr_c)
join
endtask: body
endclass: simple_vseq
But now I want to be able to drive specific transactions into the virtual sequencer, depending on the test I am running. To do so, I have a class with an analysis import that is updated every time the monitor sees a transaction in the interface, and a function that returns the next transaction to be driven. So now I want to do something like the following:
class test extends uvm_test;
model model_a;
simple_vseq seq;
top_vseqr virt_seqr;
...
task run_phase(uvm_phase phase);
...
seq = simple_vseq::type_id::create("seq", this);
seq.seq_a = model_a.get_sequence();
seq.start(virt_seqr);
...
endtask: run_phase
Digging through the UVM documentation I have seen that there is a 'uvm_send macro, but it doesn't allow you to select the sequencer to run the sequence on (i.e. I haven't seen a 'uvm_send_on or something like that). What can I do?
Thanks!
You can implement the contents of the uvm_do_on macro without the call to randomize() (like you showed in the second snippet) without any worries. This is anyway the suggested practice by some experts, because the sequencer/driver handshake mechanism is pretty simple. The `uvm_do* macros are not the norm, they're just there to help you out in the beginning.
I don't think there is a `uvm_send_on macro but there is a `uvm_create_on(SEQ_OR_ITEM, SEQR) macro which you can use. From the UVM documentation, this is the same as `uvm_create except that it also sets the parent sequence to the sequence in which the macro is invoked, and it sets the sequencer to the specified ~SEQR~ argument. In fact, the `uvm_create macro calls `uvm_create_on macro internally by passing m_sequencer by default. You can override it using the `uvm_create_on call.
Alternatively, you could also do a set_sequencer on your sequence_item object so that it sets the m_sequencer variable.
Hope this helps.
`uvm_do_on_with may statisfis your requirement, and you can also delete rand in your packet to disable randomization or add constraint
I try to learn EasyMock 3.2 by refactoring tests using jMock. Excuse me if the answer is obvious, but currently I cannot find it. I know there is a 'strict' mock which detects if the order of expected calls is wrong. But I was surprised that I don't get an error if some expectations are left. Example:
// This test passes as expected
#Test
public void connectShouldPass() {
expect(sessionMock.setTimeout(10000)).andReturn(true);
replay(sessionMock);
sessionMock.setTimeout(10000);
}
// Here I would expect an fail but it passes too
#Test
public void connectShouldPass() {
expect(sessionMock.setTimeout(10000)).andReturn(true);
expect(sessionMock.setTimeout(10000)).andReturn(true);
replay(sessionMock);
sessionMock.setTimeout(10000);
}
Is it possible to check (maybe in the #After method) if more expectations were defined than called?
Thanx, Andi
[OP found their own answer. Providing answer as an answer, rather than a comment]
EasyMock.verify(mock) does the job.
I could use some general assistance with a simple bit of Apex code. Just so you know I am a newbie to Salesforce.com, but not to web application programming (12 years but with Coldfusion and some Perl and am used to the MVC architecture), although I have not been exposed deeply to Java or C#.
So I am working on a simple controller that I'll use in a simple VF page. I'd just like to return the value and display it on the page but Im running into some syntax issues during compile. Here's my code so far:
Controller - mytest.cls
public with sharing class myTest {
public class addNewFolder {
String tmpFolderName = 'MyTestFolder';
String tmpObjectID = '22K22';
String tmpResult = 'Whoo-hoo!';
System.debug('XIX|' + tmpResult);
return tmpResult;
}
}
Error
Description Resource Path Location Type
Save error: expecting a right parentheses, found 'XIX|' mytest.cls /PREPROD/src/classes line 15 Force.com save problem
As I understand
addNewFolder
is a METHOD. So instead of writing
public class addNewFolder
you must write
public string addNewFolder() {... return tmpResult;}
I hope it will help you.
It looks like the | character is causing the error. You could try escaping the | character like this:
System.debug('XIX\\|' + tmpResult);
Or, you could use a different character:
System.debug('XIX-' + tmpResult);
Update: Upon looking more carefully at your code, I realized superfell is right (see his comment on your question above).