Sorry if I had this stupid question...I've been trying to google for answer but couldn't find one. :(
I have a problem assigning a variable to a virtual interface. For example:
Param.sv
...
string MyInput[3];
MyInput[0] = Signal_CLK; //Storing SignalName to in an Array.
MyInput[1] = Signal_Tx;
MyInput[2] = Signal_Rx;
...
MyInterface.sv
...
Signal_CLK = dut.MicroController.Source.clk; //Signal destination
Signal_Tx = dut.MicroController.Tx_01;
Signal_Rx = dut.MicroController.Rx_01;
...
Test.sv
virtual MyInterface my_vif
logic [7:0] read_value;
....
for (i = 0; i <3; i++ )
begin
read_value = my_vif.My_Input[i];
..
//some logic to compare read_value with spec//
..
end
The problem is when compiling, it doesn't translate my_vif.My_Input[0] into my_vif.***dut.MicroController.Source.clk***. Instead, it thinks that the path is my_vif.***My_Input[i]***.
The reason the compiler thinks you are trying to access my_vif.My_Input[i] is because you are. The My_Input[] array is a completely separate string array; not part of the virtual interface. When using the "thing.thing.thing" syntax, the compiler will loyally follow it, so it will expect there to be something called My_Input that has some elements (as its an array) as a member of the interface given by my_vif.
However, looking over youre code, you are trying to have My_Input[i] replaced at compile time, which is very different. The compiler will not run your loop, look in My_Input[i] and find the string "Signal_CLK" and replace that as part of the path to get the path my_vif.Signal_CLK. Nor can it do that at run time.
I dont know of a generic solution to looking over any variables in an interface; though Im also not sure if thats really what you want. IF you provide more details on the rest of your checker, we might be able to help you more.
You cannot use strings to look up identifiers by name within SystemVerilog. There are tool specific and C interfaces that may let you do this, but that would be very inefficient. The best way to do this by using a combination of abstract/concrete classes and the bind construct. See these references: http://events.dvcon.org/2012/proceedings/papers/01P_3.pdf and http://www.doulos.com/knowhow/sysverilog/DVCon08/DVCon08_SysVlog.php
Related
suppose in my test bench, i had following signals
top.module0.expect
top.module1.expect
yes, we instantiates module0/1 with same module
now, in a function get_expect_sig(int module_idx) (module_idx could be 0 or 1), i want to get the signal according to module_idx
what i'm currently do is as follow:
if (module_idx == 0) return top.module0.expect;
else if (module_idx == 1) return top.module1.expect;
this solution is pretty ugly.
if there any brilliant method that help me with this? because i got 32 modules, not 2 modules
thanks!
A case statement would be slightly less ugly. Since your design choose to instantiate the modules with unique names instead of an array of instances, there is no way to iterate over them.
Some tools allow you to look up a signal's value using a string name. Then you could format the string using the index value. You'll need to read your tools manual.
If this is testbench code (non-synthesizable), if module 0 and module 1 are instances of the same module, you could bind an interface to it. A bind statement will cause this interface to be instantiated in all instances of the module. You could then put some helper code in this interface to 'register' with a configuration class. In UVM, this could be the config db, but in SystemVerilog you could use a static or singleton class.
Example: https://www.edaplayground.com/x/5ZUG
This uses a few concepts (abstract-concrete polymorphic interfaces) that you may need to read about. But hopefully the example is clear enough.
I'm having a look at the code at this page:
http://golang.org/pkg/net/http/
And there's one thing I don't understand - at some point, a new structure is created and initialized like this:
client := &http.Client{
CheckRedirect: redirectPolicyFunc,
}
Why use & when creating this structure?
I've also read this blog post and structs are initialized like this:
r := Rectangle{}
What is the difference between both and how should I know which one to use?
The difference is in the type of your variable.
client := &http.Client{
makes client of type *http.Client
while
client := http.Client{
builds a http.Client.
The top one is returning a pointer. It is a Go idiom instead of using new. The second one is just a value object. If you need a pointer use the top.
Check the effective go doc for more about this
http://golang.org/doc/effective_go.html#allocation_new
In object-oriented programming, in order for an object to have dynamic lifetime (i.e. not tied to the current function call), it needs to be dynamically allocated in a place other than the current stack frame, thus you manipulate the object through a pointer. This is such a common pattern that in many object-oriented languages, including Java, Python, Ruby, Objective-C, Smalltalk, JavaScript, and others, you can only deal with pointers to objects, never with an "object as a value" itself. (Some languages though, like C++, do allow you to have "objects as values"; it comes with the RAII idiom which adds some complexity.)
Go is not an object-oriented language, but its ability to define custom types and define methods that operates on that custom type, can be made to work very much like classes and methods. Returning a pointer to the type from the "constructor" function allows the "object" to have a dynamic lifetime.
When we use reference, we use a single item throughout the program runtime. Even if we assign that to a new variable or pass through a function. But when we use value, we make new copies of individual items.
( Reference is not right word according to golang convention. "Address of value" would be more appropriate here https://golang.org/ref/spec#Package_initialization )
An example will make it much clear I hope.
type Employee struct {
ID int
Name string
Address string
}
func main() {
andy := &Employee{}
andy.Name = "Andy"
brad := andy
brad.Name = "Brad"
fmt.Println(andy.Name)
}
The result of this code block would be:
Brad
As we made new variable from it but still referring to same data. But if we use value instead of reference and keep the rest of the code same.
// from
andy := &Employee{}
// to
andy := Employee{}
This time the result would be:
Andy
As this time they both are individual items and not referring to same data anymore.
Can a variable be named with a string or character array, in any language? Basically I want something like:
Var_String = "varname"
Var_String as double
And then I could fill the double varname.
If it helps im trying to make a program that can declare variables on the fly, while running. Even if thats not possible, I am open to workarounds even if they're impractical, although I would prefer that workarounds be in VB6, C++, or PHP, because I know those languages already, but they dont have to be.
Javascript is completely capable of declaring variable names on the fly. A javascript object can be treated "associatively" as a dictionary. Observe:
var testyObject = function()
{
Awesome = "hello";
};
var myObject = new testyObject();
alert(myObject.Awesome); // creates an alert window that says hello
alert(myObject['Awesome']); // the same as above
myObject[myObject.Awesome] = "woo!"; // We just created a property on the object with the name "hello"
alert(myObject.hello); // creates an alert window that says "woo!"
I also believe you can add them to your immediate scope rather than as properties on other objects by using this["whatever you want it named"] = "woo!"; but I'm not certain, someone can correct me on that if such does not work.
You can read more about associative arrays at http://www.quirksmode.org/js/associative.html
The usual way to do something like this is called a hash. You store name/value pairs and given the name, can look up its value. You can generally define them to store any sort of object. In fact, in some languages, objects themselves are essentially hashes with a few extra properties.
You can find more information on wikipedia: http://en.wikipedia.org/wiki/Hash_table
I am making a simple debugger window in ActionScript for myself where I can add and remove variables I want to track. I was to be able to add variables to the list by just doing something like
DebuggerMonitor.trackVar(variable).
My question is, is there any way I can turn "variable" itself (the name, not the value) into a String to be added into a text field?
Depending on how "intelligent" your debugger should be, you could just pass the name along:
DebuggerMonitor.trackVar( variable, "variable" );
since obviously, when used in a context like this, the name should be known at the time you are writing the program.
You can also do some reflection magic to get instance variable names, but it won't work for temp variables (their names are dropped at compilation time):
public function getVariableName( instance:*, match:* ):String {
var typeDescription:XML = describeType( instance );
var variables:XMLList = typeDescription..variable;
var accessors:XMLList = typeDescription..accessor;
for each(var variable:XML in variables)
if(matchesXMLName( instance, variable, match ))
return variable.#name;
for each(var accessor:XML in accessors)
if(matchesXMLName( instance, accessor, match ))
return accessor.#name;
return "No name found.";
}
private function matchesXMLName( instance:*, xml:XML, match:* ):Boolean {
return match == instance[xml.#name.toString()];
}
var varName:String = getVariableName ( myObject, variable );
Using reflections like this will also be quite costly, if used often - you will have to think of a way to cache the type descriptions.
I recommend you check out the as3commons reflections package - there is a lot of useful functionality in there...
Short answer - No :(
You can access the type name but not individual instance names, as these are lost at run-time.
There is a confusion caused by the keyword 'var' because it is used to create several types of bindings.
Lexical bindings (the keyword 'var' was used inside a function).
Dynamic bindings (the keyword 'var' was used to declare a class' field).
Lexical bindings are interpreted by the compiler at compile time as addresses of the registers of the registers space occupied by the function. The names given to lexical bindings perish at this time and it is not possible to restore them at runtime - therefore you can't get the "name" of the variable.
Dynamic bindings are a kind of "public API" of the objects that declare them, they may be accessed from the code that was not compiled together with the code that created them, this is why, for the purpose of reflection the names of these bindings are stored in compiled code. However, ActionScript has no way of referencing LHS values, so you cannot, even if you know the name of the variable and the object declaring it, pass it to another function. But you can look it up in the debugger or by calling describeType on the object declaring the variable. Note that describeType will not show information on private variables even if you are calling it from the scope of the object in question.
Some time recently, I heard someone espousing the fact that a domain model should not allow updating the domain objects via properties with a subsequent Save call. But rather all updates should be done through explicit methods. Example of how I understand what was said:
Bad Code (that seems pretty normal to me):
var x = _repository.GetCustomerByID(5);
x.Firstname = "Travis";
x.Lastname = "Laborde";
_respository.SaveCustomer(x);
The Code that I believe this person was pitching would look like:
var x = _repository.GetCustomerByID(5);
x.UpdateCustomerName("Travis", "Laborde");
_repository.SaveCustomer(x);
I'd like to learn more - is there a name to this pattern so that I can Google it on Bing?
I'm not aware of this pattern having a specific name, but from what you describe, there's a basic practical reason for this:
Writing x.Firstname = "Travis" does not let the x object know that the Firstname value was changed. This makes it hard to implement a SaveCustomer function that only uses UPDATE on the fields that were changed.
Of course, in a language that does support treating member assignment as a function call (like, say, C# does with its properties), this pattern becomes much less interesting.