I’m using e coverage for sampling signals in my DUT.
In order to sample the covergroup, I’m emitting the coverage sample event inside a DPI code (defined in c interface of e, called in my hdl code).
But it seems like when emitting this event there is a lot of overhead which is not related to the coverage collection.
What can I do in-order to reduce this overhead?
Try to define, emit and handle all coverage groups and event in e.
That way you'll not get the overhead of transition between languages.
Instead of emitting the event, use the API for procedural sampling of the event (covers.sample_cg())
For example if you have a covergroup named cg1, defined in a type t1, and you’d like to sample it for t1_inst of t1, then instead of calling :
emit t1_inst.cg;
call :
covers.sample_cg(“t1.cg1”, t1_inst);
You should define event(s) that is more relevant to the needed signals.
You can also define event on specific bits of a bus change.
Related
In:
https://docs.omnetpp.org/tutorials/tictoc/part5/
and
https://doc.omnetpp.org/omnetpp/manual/#sec:simple-modules:declaring-statistics
it's shown how network statistics can be processed after a simulation.
Is it possible to get network parameters dynamically?
TL;DR: Use signals (not statistics) and hook up your own simple module on these signals and compute the required statistics in that module.
You cannot access the value of #statistics in your code, and there is a reason for this as this would be an anti pattern. NED based statistics were introduced as a method to add calculations and measurements to your model without modifying your models behavior and code. This means that statistics are NOT considered part of a model, but rather they are considered as a configuration. Changing a statistics (i.e. deciding that you want to measure something else) should never change the behavior of your model. That's why the actual value of a given statistic is not exposed (easily) to the C++ code. You could dig them out, but it is highly discouraged.
Now, this does not mean that what you want to achieve is not legitimate but the actual statistics gathering must be an integral part of your model. I.e. you should not aim for using built-in statistics, but rather create an explicit statistics gathering submodule that should hook up on the necessary signals (https://doc.omnetpp.org/omnetpp/manual/#sec:simple-modules:subscribing-to-signals) and do the actual statistics computation you need in its C++ code. After that, other modules are free to access this information and make decisions based on that.
I am trying to rename a signal in a way that minimizes computational cost.
Let's say I have an input called statusA. Then I have a bus creator with format specified by the definition of busDef that includes a signal called status.
It is not possible to change the signal names of statusA and busDef because of architectural constraints.
For safety reasons I enforce strong data typing when creating busDef. When I connect the signal to the bus creator, this results in an error/warning saying that statusA does not match the bus definition, which is status.
For now I solve this with a Convert block that takes statusA as input and then I rename the output to status. This way the signal name that arrives to busDef is always status so there are no complaints.
I was wondering if there is a more optimal solution than having to use a convert block.
One easy way that I have used for this same task is to put Goto/From blocks inline with the signal who's name you want to change. You can rename the signal that is coming out of the From block to the desired new name, without any computational overhead. This will satisfy the check for name consistency in the bus creator block.
This is the context:
There is an input event stream,
There are some methods to apply on
the stream, which applies different logic to evaluates each event,
saying it is a "good" or "bad" event.
An event can be a real "good" one only if it passes all the methods, otherwise it is a "bad" event.
There is an output event stream who has result of event and its eventID.
To solve this problem, I have two ideas:
We can apply each method sequentially to each event. But this is a kind of batch processing, and doesn't apply the advantages of stream processing, in the same time, it takes Time(M(ethod)1) + Time(M2) + Time(M3) + ....., which maybe not suitable to real-time processing.
We can pass the input stream to each method, and then we can run each method in parallel, each method saves the bad event into a permanent storage, then the Main method could query the permanent storage to get the result of each event. But this has some problems to solve:
how to execute methods in parallel in the programming language(e.g. Scala), how about the performance(network, CPUs, memory)
how to solve the synchronization problem? It's sure that those methods need sometime to calculate and save flag into the permanent storage, but the Main just need less time to query the flag， which a delay issue occurs.
etc.
This is not a kind of tech and design question, I would like to ask your guys' ideas, if you have some new ideas or ideas to solve the problem ? Looking forward to your opinions.
Parallel streams, each doing the full set of evaluations sequentially, is the more straightforward solution. But if that introduces too much latency, then you can fan out the evaluations to be done in parallel, and then bring the results back together again to make a decision.
To do the fan-out, look at the split operation on DataStream, or use side outputs. But before doing this n-way fan-out, make sure that each event has a unique ID. If necessary, add a field containing a random number to each event to use as the unique ID. Later we will use this unique ID as a key to gather back together all of the partial results for each event.
Once the event stream is split, each copy of the stream can use a MapFunction to compute one of evaluation methods.
Gathering all of these separate evaluations of a given event back together is a bit more complex. One reasonable approach here is to union all of the result streams together, and then key the unioned stream by the unique ID described above. This will bring together all of the individual results for each event. Then you can use a RichFlatMapFunction (using Flink's keyed, managed state) to gather the results for the separate evaluations in one place. Once the full set of evaluations for a given event has arrived at this stateful flatmap operator, it can compute and emit the final result.
I was watching this video (see image below) and it made me wonder whether Elm's Signal is the same as Conal's Behaviour.
I think they are the same but I am not 100% sure. Are they the same?
Here are a few related questions:
1) What is a Elm's Signal (Conal's Behaviour) in RX ? Is there such a concept in RX at all? Perhaps ReplaySubject?
2) How can I turn an RX Observable into a Signal (Behaviour) in RX ?
In Sodium there is the hold function for this purpose.
3) What is RX's Observable ( AFAIK RX's Observable corresponds to Conal's Event ) in Elm? Is there such a thing in Elm?
Thanks for reading.
Here are the questions expressed in a table:
Snapshot from the Elm talk:
Here is a partial answer :
Sodium author Stephen Blackheath writes :
Elm is an example of a system that has one type Signal that combines
Stream and Cell.
Source:
https://forums.manning.com/posts/list/35274.page
A note on about Sodium's naming convention:
Sodium's Stream is Conal's Event and Sodium's Cell is Conal's Behaviour.
EDIT:
RX BehaviorSubject = Conal's Behavior.
RX Observable = Conal's Event.
I believe the answer to your question above is that potentially your initial assumptions are wrong. I believe that the observable sequence is (more) analogous to Behaviour and Signal (Vary over continuous time, can be/are infinite, synchronous by default). Conal seems to indicate that an Event is a specific state at a point in time, a "happening" e.g. "the event describing the first left-button press after time t0" [*1]
|Rx |Conal |ELM |
|--------------|--------|------|
|T |Event | ? |
|IObservable<T>|Behavior|Signal|
I believe that an Event in Conal's description is the actual value at a point in time. So be more specific, I think this is even more accurate
|Rx |Conal |ELM |
|---------------------------|--------|------|
|TimeStamp<T> |Event | ? |
|ReplaySubject<TimeStamp<T>>|Behavior|Signal|
I believe that here a ReplaySubject<TimeStamp<T>> more closely represents a Behaviour as I understand it (contain state and time, can fetch value at a point in time). However as a ReplaySubject does not really allow you just pull the state from a point in time, they are not like-for-like. In my opinion, an EventStore is a closer match.
So to be clear, in my understanding an Observable Sequence (Rx IObservable<T>) and Conal's Behaviour share a similar definition up to a point. They both represent an ordered sequence of values over time. However in Rx, this is all an observable sequence is. Remembering that Rx is purely a library to allow you to query streams of events. There are some features that allow you to cache data (Replay/Buffer) or work with windows of data (Window/GroupJoin) and you can even enrich data with timestamps (TimeStamp/TimeInterval).
However where Conal's Behaviours diverge from Observable Sequences, is in it's features of persistence and historical querying. As I understand it, Conal's Behaviour in addition to Rx's features also specify that you are able to pluck a value of a sequence at any given point in time. For example with there was a price tick at time 00:00:01 of $1.23 and then another price tick at time 00:00:05 of $2.34, a consumer could ask for a value at time 00:00:02 and would be given back the value of $1.23 (the most recent value at the point in time).
time [t1 ] [t2] [t3] [t4] [t5 ]
prices ----[$1.23]--------------------[$2.34]--->
price#t2 -------------[$1.23]|
Rx doesn't provide any support for this, but one could go to great lengths to write custom operators to support this.
//A forced example of querying historical data.
// Be carefull as Replay() uses an unbounded buffer!
var source = Observable.Interval(TimeSpan.FromMilliseconds(250))
.Timestamp()
.Replay();
var connection = source.Connect();
var time2 = DateTimeOffset.Now+TimeSpan.FromSeconds(2);
var valueAtTime2 = source.TakeWhile(ts=>ts.Timestamp <= time2)
.LastAsync();
valueAtTime2.Dump(); //LinqPad feature to output the result
Systems that can (could?) support this kind of retrospective querying could be systems like CEP (Complex Event Processing) engines or EventStore style databases.
[*1]. http://conal.net/papers/icfp97/icfp97.pdf
I read Deprecating the Observer Pattern with Scala.React and found reactive programming very interesting.
But there is a point I can't figure out: the author described the signals as the nodes in a DAG(Directed acyclic graph). Then what if you have two signals(or event sources, or models, w/e) depending on each other? i.e. the 'two-way binding', like a model and a view in web front-end programming.
Sometimes it's just inevitable because the user can change view, and the back-end(asynchronous request, for example) can change model, and you hope the other side to reflect the change immediately.
The loop dependencies in a reactive programming language can be handled with a variety of semantics. The one that appears to have been chosen in scala.React is that of synchronous reactive languages and specifically that of Esterel. You can have a good explanation of this semantics and its alternatives in the paper "The synchronous languages 12 years later" by Benveniste, A. ; Caspi, P. ; Edwards, S.A. ; Halbwachs, N. ; Le Guernic, P. ; de Simone, R. and available at http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1173191&tag=1 or http://virtualhost.cs.columbia.edu/~sedwards/papers/benveniste2003synchronous.pdf.
Replying #Matt Carkci here, because a comment wouldn't suffice
In the paper section 7.1 Change Propagation you have
Our change propagation implementation uses a push-based approach based on a topologically ordered dependency graph. When a propagation turn starts, the propagator puts all nodes that have been invalidated since the last turn into a priority queue which is sorted according to the topological order, briefly level, of the nodes. The propagator dequeues the node on the lowest level and validates it, potentially changing its state and putting its dependent nodes, which are on greater levels, on the queue. The propagator repeats this step until the queue is empty, always keeping track of the current level, which becomes important for level mismatches below. For correctly ordered graphs, this process monotonically proceeds to greater levels, thus ensuring data consistency, i.e., the absence of glitches.
and later at section 7.6 Level Mismatch
We therefore need to prepare for an opaque node n to access another node that is on a higher topological level. Every node that is read from during n’s evaluation, first checks whether the current propagation level which is maintained by the propagator is greater than the node’s level. If it is, it proceed as usual, otherwise it throws a level mismatch exception containing a reference to itself, which is caught only in the main propagation loop. The propagator then hoists n by first changing its level to a level above the node which threw the exception, reinserting n into the propagation queue (since it’s level has changed) for later evaluation in the same turn and then transitively hoisting all of n’s dependents.
While there's no mention about any topological constraint (cyclic vs acyclic), something is not clear. (at least to me)
First arises the question of how is the topological order defined.
And then the implementation suggests that mutually dependent nodes would loop forever in the evaluation through the exception mechanism explained above.
What do you think?
After scanning the paper, I can't find where they mention that it must be acyclic. There's nothing stopping you from creating cyclic graphs in dataflow/reactive programming. Acyclic graphs only allow you to create Pipeline Dataflow (e.g. Unix command line pipes).
Feedback and cycles are a very powerful mechanism in dataflow. Without them you are restricted to the types of programs you can create. Take a look at Flow-Based Programming - Loop-Type Networks.
Edit after second post by pagoda_5b
One statement in the paper made me take notice...
For correctly ordered graphs, this process
monotonically proceeds to greater levels, thus ensuring data
consistency, i.e., the absence of glitches.
To me that says that loops are not allowed within the Scala.React framework. A cycle between two nodes would seem to cause the system to continually try to raise the level of both nodes forever.
But that doesn't mean that you have to encode the loops within their framework. It could be possible to have have one path from the item you want to observe and then another, separate, path back to the GUI.
To me, it always seems that too much emphasis is placed on a programming system completing and giving one answer. Loops make it difficult to determine when to terminate. Libraries that use the term "reactive" tend to subscribe to this thought process. But that is just a result of the Von Neumann architecture of computers... a focus of solving an equation and returning the answer. Libraries that shy away from loops seem to be worried about program termination.
Dataflow doesn't require a program to have one right answer or ever terminate. The answer is the answer at this moment of time due to the inputs at this moment. Feedback and loops are expected if not required. A dataflow system is basically just a big loop that constantly passes data between nodes. To terminate it, you just stop it.
Dataflow doesn't have to be so complicated. It is just a very different way to think about programming. I suggest you look at J. Paul Morison's book "Flow Based Programming" for a field tested version of dataflow or my book (once it's done).
Check your MVC knowledge. The view doesn't update the model, so it won't send signals to it. The controller updates the model. For a C/F converter, you would have two controllers (one for the F control, on for the C control). Both controllers would send signals to a single model (which stores the only real temperature, Kelvin, in a lossless format). The model sends signals to two separate views (one for C view, one for F view). No cycles.
Based on the answer from #pagoda_5b, I'd say that you are likely allowed to have cycles (7.6 should handle it, at the cost of performance) but you must guarantee that there is no infinite regress. For example, you could have the controllers also receive signals from the model, as long as you guaranteed that receipt of said signal never caused a signal to be sent back to the model.
I think the above is a good description, but it uses the word "signal" in a non-FRP style. "Signals" in the above are really messages. If the description in 7.1 is correct and complete, loops in the signal graph would always cause infinite regress as processing the dependents of a node would cause the node to be processed and vice-versa, ad inf.
As #Matt Carkci said, there are FRP frameworks that allow loops, at least to a limited extent. They will either not be push-based, use non-strictness in interesting ways, enforce monotonicity, or introduce "artificial" delays so that when the signal graph is expanded on the temporal dimension (turning it into a value graph) the cycles disappear.