I have a UVM testbench that uses configurations to replace a VHDL component that is deep within the design. Each test that I create has to use a verilog configuration to replace that component. Is there a way to use a variable for the hierarchical path so that I don't have to update each configuration if the VHDL design changes?
There is no way to use a variable to represent a hierarchical path, except for virtual interface variables used to represent the hierarchical path to interface instances.
You will need to show use an example of how each test changes the VHDL component to give us a better idea for a solution; maybe you can use a macro.
I found a solution that does what I would like it to do. I have used macros to define the instances that I want to configure. The following is a an example of what I have done:
`define USE_TB_COMP instance top.u_mod1.u_sub_mod1.u_comp use tb_comp;
config test1_c;
`USE_TB_COMP
endconfig
config test2_c;
`USE_TB_COMP
endconfig
....
Related
I'm looking to create my own scripting language, highly based off of lua (im planning on it being lua but easier to understand for me) so I need to know where the predetermined functions / variables file is, because I would like to edit that. If you have a solution, please comment and let me know!
Every table in the standard library is defined in its own C file. In the src directory of the Lua source package, look for the file whose name is similar to the library name. Global functions are defined in lbaselib.c.
Pytorch documentation provides a concise way to apply MiDaS monocular depth estimation network for depth extraction. But how should I modify their code to extract network representation at some intermediate layer? I know that I could download the model from github and modify forward function to return what I want, but I am interested in the simplest solution, leaving outer code as is.
I'm aware of subclassing the model class and writing my own forward function, like here, but I don't know how to access the class in the code. The model instance is created straight away with midas = torch.hub.load("intel-isl/MiDaS", model_type). Maybe an example of using a forward hook will be easier.
As you said, using a forward hook on a nn.Module is the easiest way to go about it. Consider the documentation: https://pytorch.org/docs/stable/generated/torch.nn.Module.html#torch.nn.Module.register_forward_hook
Basically you just have to define a function that takes three inputs (module, input, output) and then does whatever you want with that data. To find at what Module you want to place that hook you obviously need to be familiar with the structure of the model. You can just print(midas) to get a pretty-printed representation of all the modules available. I just chose some random one, and used the print() function as a hook:
midas.pretrained.model.blocks[3].mlp.fc2.register_forward_hook(print)
This means whenever we call midas(some_input), the hook (print in this case) will be called with the corresponding arguments. Of course instead of print you can write a function that saves those files to e.g. a list that you can access from the outside, or write them to a file etc.
There are some things that I would like to modify in the OpenAI environments. If we use the Cartpole example then we can edit things that are in the class init function but with environments that use Box2D it doesn't seem to be as straightforward.
For example, consider the BipedalWalker environment.
In this case, how would I edit things like the SPEED_HIP or SPEED_KNEE variables?
Yes, you can modify or create new environments in gym. The simplest (but not recommended) way is to modify the constants in your local gym installation directly, but of course that's not really nice.
A nicer way is to download the bipedal walker environment file (from here) and save it to a file (say, my_bipedal_walker.py)
Then you modify the constants in the my_bipedal_walker.py file, and then just import it in your code (assuming you put the file in a path that is importable, or the same folder as your other code files):
import gym
from my_bipedal_walker import BipedalWalker
env = BipedalWalker()
Then you have the env variable being an instance of the environment, with your defined constants for the physics computation, which you can use with any RL algorithm.
An even nicer way would be making your custom environment available in the OpenAI gym registry, which you can do by following the instructions here
You can edit the bipedal walker environment just like you can modify the cartpole environment.
All you have to do is modify the constants for SPEED_HIP and SPEED_KNEE.
If you want to change how those constants are used in the locomotion of the agent, you might also want to tweak the step method.
After making changes to the code, when you instantiate the environment, the new instance will be using the modifications you made.
In the autoconf manual, it is noted that
AC_INIT (package, version, [bug-report], [tarname], [url])
defines multiple macro names such as AC_PACKAGE_NAME and PACKAGE_NAME.
Running configure also generates a config file with definition like the following:
define HAVE_LIBGMP 1
As I am writing C++ code, I find these macros annoying yet useful. In fact, it happened many times that I needed to link with a library that uses the autotools and thus has these macros in its headers. So the situation is that there is conflict on headers macros such as:
define PACKAGE_NAME "library"
define PACKAGE_NAME "mine"
So, I was wondering if there was a way to tell the autotools to define at least some of these macros inside some kind of structure as follows:
`struct header_information{
static string package_name;
static bug_report;
....
}`
and then initialize it with the right macro names.
This solution would keep these informations encapsulated and does not pollute the global namespace ?
It seems to me like you want to abuse a package-private, build-system-ony configuration header file (config.h) that just so happens to define a convenient macro name that you'd like to use. I think the pretty obvious answer is "don't do that", or else you're on your own.
Unless I'm misunderstanding you?
Those defines are there so that the particular library can use them. It's not meant for other things to include. In fact, the majority of the things in config.h are completely useless outside of the particular package.
That doesn't mean that the library that config.h file belongs to couldn't provide what you're looking for, by defining a public struct in a header that uses those variables. Or perhaps a library that uses pkg-config (if you're just looking for package names) can provide some of information for you. But I don't think that autotools would or should provide that information to you.
I've read many times and agree with avoiding the use of globals to keep code orthogonal. Does the use of the config file to keep read only information that your program uses similar to using Globals?
If you're using config files in place of globals, then yes, they are similar.
Config files should only be used in cases where the end-user (presumably a computer-savvy user, like a developer) needs to declare settings for an application or piece of code, while keeping their hands out of the code itself.
My first reaction would be that it is not the same. I think the problem with globals is the read+write scenario. Config-files are readonly (at least in terms of execution).
In the same way constants are not considered bad programming behaviour. Config-files, at least in the way I use them, are just easy-changable constants.
Well, since a config file and a global variable can both have the effect of propagating changes throughout a system - they are roughly similar.
But... in the case of a configuration file that change is usually going to take place in a single, highly-visible (to the developer) location, and global variables can affect change in very sneaky and hard to track down ways -- so in this way the two concepts are not similar.
Having a configuration file ususally helps with DRY concepts, and it shouldn't hurt the orthogonality of the system, either.
Bonus points for using the $25 word 'orthogonal'. I had to look that one up in Wikipedia to find out the non-Euclidean definition.
Configuration files are really meant to be easily editable by the end user as a way of telling the program how to run.
A more specialized form of configuration files, user preferences, are used to remember things between program executions.
Global is related to a unique instance for an object which will never change, whereas config file is used as container for reference values, for objects within the application that can change.
One "global" object will never change during runtime, the other object is initialized through config file, but can change later on.
Actually, those objects not only can change during the lifetime of the application, they can also monitor the config file in order to realize "hot-change" (modification of their value without stopping/restarting the application), if that config file is modified.
They are absolutely not the same or replacements for eachother. A config file, or object can be used non-globally, ie passed explicitly.
You can of course have a global variable that refers to a config object, and that would be defeating the purpose.