We are in process to migrate our TB to UVM.
I am working on first IP that will be verified using UVM.
I have to find out if it is possible to reuse my uvm_sequences in SOC that remains in OVM mean time.
In case it is possible , like find example how it's done.
Thanks in advance.
You cannot mix OVM and UVM that way. You should be able to write your uvm_sequence in such a way that it work in both by simply changing your u's to o's. You would have to limit your sequence to functionality that exists in both.
If you use UVM RAL. there is a package that integrates that functionality back into OVM.
There is another package, ovm_container, that gives you the functionality of uvm_config_db.
Related
Roald has written an excellent guide for the Twincat Eventlogger.
https://roald87.github.io/twincat/2020/11/03/twincat-eventlogger-plc-part.html
https://roald87.github.io/twincat/2021/01/20/twincat-eventlogger-hmi-part.html
For us this is exactly what we want, there is however 1 thing I haven't figured out. How to get the sourcename of the alarm in multiple languages in the HMI. params::sourceName gives the path in the software (example: MAIN.fbConveyor1.Cylinder1) This path can be customized when initializing the alarm (as Roald has shown). This doesn't work in my case, since I would like to define a generic alarm (example: "Cilinder not retracted within maximum time") that is instantiated multiple times.
I was thinking of using the source as a way to show the operator where the alarm occurs. We use this way (path) already for saving machine settings among other things. The machines we build are installed all over the world, so multilanguage is a must.
Beckhoff does support multilanguage alarm names (when defined), but the source is not defined, but dynamically generated.
Anyone have an idea how this problem can be solved?
If I understand your question correctly, then being able to parameterize the event text with information of the source of the problem should help you out.
If you define the event text as Cylinder {0} has not retracted in time. then you can add the arguments of that text during runtime.
IF bRaiseAlarm THEN
bRaiseAlarm := FALSE;
fbAlarm.ipArguments.Clear().AddString('Alice');
fbAlarm.Raise(0);
END_IF
However, since this also stated in the articles you mentioned, I am unsure if this would solve your problem.
'Alice' in this example, can be hard to localize. The following options come to my mind.
The string can be based on an ENUM. Enums can have textlist support, so if you add your translations there, that should allow multilingual output. However... this does require a lot of setup, placing translations inside your code, and making sure the PLC application is aware of the language that the parameter should use.
Use tags to mark the source device, as tags can be language invariant. It is not the most user-friendly method, but it could work for you. It would become something like: "Cylinder 'AA.1123' did not retract in time.". 'AA.1123' as a tag would have to be stored inside your PLC code as a string. You will have to trust that your operator can relate the tag back to the actual source.
Hopefully, this helped, or else please help me understand the problem better.
I'm just kinda curious if there is a way to use the mocker driver alongside or instead of the docker one? How does fn even decide which one to use if there is more than one? The reason would be that if it's possible I might try to implement another real driver for another container engine.
So far I managed mocker to show up as a driver but still haven't found out how to get fn to use that instead of docker.
There is an example for building an fn with extensions located here: https://github.com/fnproject/fn/blob/master/examples/extensions/main.go#L16 -- for building with a custom driver, at the moment it requires using that same process (i.e. there's no way to configure another driver at runtime from fn core's binary without extending it).
In order to build with an alternative driver such as mocker, a user would use the agent.WithDockerDriver option to specify a driver when creating the agent, documented here https://godoc.org/github.com/fnproject/fn/api/agent#AgentOption and sample follows:
func main() {
mocker := mock.New()
// configure logstore, mq
da := agent.NewDirectCallDataAccess(logstore, mq)
magent := agent.New(da, agent.WithDockerDriver(mocker))
fns := server.New(server.WithAgent(magent), /*other options*/)
fns.Start(context.Background())
}
we need to tidy up the agent interface to make them easier to create (data access stuff is convoluted), but is not too bad. most of this can be stolen from this file https://github.com/fnproject/fn/blob/master/api/server/server.go -- we need to name it to WithDriver as well :)
assuming you're looking at using something like rkt or a more robust driver on the backend, it's possible to hook this up by implementing the driver interface and in the past we have tried it but we are not maintaining it at present since it was not a viable option (performance issues, perhaps improved since). would be cool to see if you manage to get rkt working, gladly take a PR for it and figure out where to put it :)
I'm interested in using the qlot library from inside of a Lisp image to manage multiple local instances of quicklisp.
There doesn't seem to be any documentation on how to use it, except through a non-Lisp CLI interface, and the obvious
(qlot:with-local-quicklisp (#P"/a/path/here/") (qlot:install :skippy))
or
(qlot:with-local-quicklisp (#P"/a/path/here/") (qlot:quickload :skippy))
give me
Component "skippy" not found
[Condition of type ASDF/FIND-SYSTEM:MISSING-COMPONENT]
What I'm looking for is a way to install a particular library by name. Basically, exactly how one would use ql:quickload, but targeting a specific, local directory instead of ~/quicklisp. What am I doing wrong?
It looks like the intent is to modify dynamically scoped variables in a way that makes using ql:quickload directly possible.
So
(qlot:with-local-quicklisp (#P"/a/path/to/some/quicklisp/")
(qlot/util:with-package-functions :ql (quickload)
(quickload :skippy)))
will result in skippy being installed in the quicklisp instance at #P"/a/path/to/some/quicklisp/" instead of the default location.
This leaves me a bit perplexed as to what qlot:quickload is for; its describe output doesn't shed additional light.
I'm working on a script to convert a Simulink library to a plain model, meaning it can be simulated, it does not auto-lock etc.
Is there a way to do this with code aside from basically copy-pasting every single block into a new model? And if it isn't, what is the most efficient way to do the "copy-paste".
I was not able to find any clues as how to approach this problem here, or on Google, or on the official documentation or on the MathWorks forum so I'm at a loss on how to proceed.
Thank you in advance!
I don't think it's possible to convert a library to a model, but you can programmatically add library blocks to models like so:
sys = 'testModel';
new_system(sys);
open_system(sys);
add_block('Simulink/Sources/Sine Wave', [sys, '/MySineWave']);
save_system(sys);
close_system(sys);
sim(sys);
You could even use the find_system command to list all the blocks in a library and then loop through them all and create a new model for each using the above code.
I was wondering if it's currently possible to have an 'external' (.so/.dylib) LLVM plugin (module) pass scheduled at LTO time? The reason for wanting this is a inter-modular optimization I want to add.
I also found this topic; How to write a custom intermodular pass in LLVM?
But a separate tool is not an option for me.
Thanks
I think the most helpful thing here might be to understand how passes are run and what the state of the code is during LTO.
First of all, when optimization passes are run by the compiler, they are done as a set that has been added to a PassManager. This means that LLVM/Clang, when passed something like -O3 will create a copy of a PassManager and subsequently provide it the set of passes expected to provide O3 level of optimization. This is very different from what you are doing with an external library which must be provided manually and cannot be fit into the pass pipeline normally.
Then we have the state of things when doing LTO. During Link Time Optimization, all of the individual translation units have been consolidated and are now a single Module. This means that an optimization which runs on each function will run on every function in the code base. Similarly, a per-module optimization will run on the full Module and therefor offer Inter-Procedural Analysis/Optimization.
If you're looking to use an Intra-Modular Pass then there is no reason to do this at LTO time and instead you can simply make a ModulePass and run that on each unit.