Is it possible to realize the condition <=1 or =1 with any switch of the simulink library?? The idea is to use it for priority. For example the device with the priority 1 should be selected for further signal processing?
The Switch block can do exactly this.
You can configure the Switch block to route one of two signals depending on the "control input signal" which can be a logical operator such as <=1 or <1.
You could also use Flowcharts in Stateflow to allow selection of different devices when more complex logic exists.
Related
Could anyone explain in short what signal filtering feature of AUTOSAR COM module does? I can't find any concrete explanation in AUTOSAR_SWS_COM specification.
Actually, AUTOSAR_SWS_Com chapter "7.2.4 Filtering" pretty much describes exactly that.
On transmission side, the filter specifies the transmission mode conditions in order to trigger a PDU to be transmitted -> think of old CAN event or event-periodic messages. "OnChange" or "OnWrite", "CyclicOnActive" ...
On receiver side, the filter masks are used e.g. to discard certain signal/signalgroup processing within a PDU.
Com signal filters for Transmission pdus will be used to select the Transmission mode ComTxModeTrue / ComTxModeFalse. Signal value of that particular signal filter will be evaluated based on the selected modes.
by using this feature - Application can control the PDU flow.
Filter modes
I have some questions about reg initialization.
Can I put Initial blocks in the design? Is that a good way?
How to initial regs in my bottom design? Do I need to create ports in each level and give initial value from top to bottom? For each simulation, initial values are different.
Point 1:
We recently had a discussion about initial statements on the Electronics forum.
Initial statements in test benches are normal. In fact without initial statements it becomes a lot more difficult to write test code.
Initial statements are not possible in ASICs, CPLDs or hard programmed FPGAs.
You can use initial statements in a most RAM based FPGAs where the state is valid after the FPGA is loaded. However if you would have a 'reset' pin or command that would not restore the initial state. As such, the FPGA condition after such a reset could well be different from your start-up state and thus your design might not work correctly.
There are some cases where an initial state in an actual synthesize-able module is allowed or even mandatory for the module to work. See examples below.
Example 1: You have a divide by two register without reset coded as:
divide_by_two <= ~divide_by_two;
or
divide_by_two <= not(divide_by_two);
In simulation that will always remain 'X' but in reality it will start in a 0 or 1 conditions and then toggle between the two. To work around the 'X' in simulation you have the set an initial condition. Your code should work independent if the initial condition is '1' or '0'.
Example 2: You have a divide by four register without reset coded as:
divide_by_four[1:0] <= {divide_by_four[0],~divide_by_four[1]};
or
divide_by_four[1:0] <= divide_by_four[0] & not(divide_by_four[1]);
The reason why this is allowed is that during operation the two registers go through every of the four possible states: 00, 01, 11, 10. It does not matter in which of the four it starts, the sequence will always be repeated. Again to work around the 'XX' in simulation you have the set an initial condition. Your code should work independent if the initial condition is 00, 01, 10 or 11.
A lot of designers feel that, apart for examples like above, the use of initial statements in synthesized code is dangerous and it is better to avoid them.
Point 2:
Instead of initial statements you can use a 'reset' signal with the appropriate HDL code to set the start condition. It is normal for the reset to go to every module which has registers.
Depends on your target design.
You can usually use initial blocks with FPGAs. You can initialization the registers in the same module that declares it. Hierarchically assignment is not allowed. You can also initialization registers with a synchronous reset if you add a reset input. Most FPGAs have a limited number of flops with asynchronous reset/preset (if any). Hence initial blocks and synchronous resets are the best options FPGA.
ASICs typically do not synthesize initial blocks. Initialization of flops is done with reset condition in synchronous logic. This is commonly an asynchronous reset but not required. In sort, synchronous or asynchronous reset for ASIC.
For both cases, to be synthesizable the initialization value needs to be deterministic and determined by constants. It cannot be derived on an input port or the current state of another register.
It is a good idea to follow these guidelines even if you plan to never synthesize. Otherwise is extra challenging to debug.
I'm using Pure Data for a project where I'll be playing several audio files at the same time to different speakers.
Let's say I have two files, and I want one to be played on the left channel of the soundcard, and the second one on the right channel, so that's the first and second inlet of the dac~ 1 2 object.
How can I route the audio signal depending on another value?
I'm basically looking for something like the route object, but with some extra parameter, or some way to pack the audio signal with the channel number (1, 2) and use the number to route the signal.
I just found out that Yves Degoyon's "unauthorized" library has the spigot~ object that does what I want, but only with two channels. In the end I would like to be able to output different sounds to eight or nine channels.
Pd-extended is not maintained any more. You can install Zexy for Vanilla Pd via the Debian package or the Deken plugin. Then you will have the demultiplex~ object available. However, there might be good reasons why you might not wanting to use an external at all. Here is one way to patch a kind of a switchboard. Additional benefit: You can specify your favorite fade time and type.
You can use [demultiplex~] from the Zexy library to route one incoming signal to one of several outlets. For instance, [demultiplex~ 1 2 3 4] will have one inlet and four outlets. The single inlet takes both an incoming signal (which will be routed) as well as an single float which selects the outlet to which the signal will be routed. For the opposite behaviour (several incoming signals to several inlets, and only one of them being output by the single outlet) try [multiplex~].
Also note that you can use [mux~] and [demux~] as they are aliases for these same objects.
Based on Max N answer, you can also use a toggle to modify the volume of the signal and know where it redirects :
In this case, if the toggle is active, the signal will be sent on the left outlet. If it is inactive, the right outlet will receive the signal.
Simply put, I want to manipulate two motors in parallel, then when both are ready, continue with a 3rd thread.
Below is image of what I have now. In two top threads, it sets motors B and C to "unlimited", then waits until both trigger the switches, then sets a separate boolean variable for both.
Then in 3rd thread, I poll these two variables with 1 second interval, until AND operation gives true to the loop termination condition.
This is embedded system and all, so it may be ok here, but in "PC programming", this kind of polling loop would be rather horrible thing to do.
Question: Can I do either of both of
wait for variable without this kind of polling loop?
wait for a thread to finish without using a variable at all?
Your question is a bit vague on what you actually want to achieve and using which language. As I understood you want to be able to implement a similar multithreaded motor control mechanism in Labview?
If so, then the answer to both of your questions is yes, you can implement the wait without an explicitly defined variable (other than the error cluster, which you probably would be passing around anyway). The easiest method is to pass an error cluster to both your loops and then use Merge errors to combine the generated errors once the loops are finished. Merge errors will wait until both inputs have data, merges the errors, and passes the merged error cluster on. By wiring the merged error cluster to your teardown function you effectively achieve the thread synchronization you described. If you require thread synchronization for the two control loops, you would however still have to use semaphores, rendezvous', notifiers, and other built-in synch methods.
In the image there's an init function that opens two serial devices (purple wire) and passes them to the control loops, which both runs until an error (yellow-black wire) occurs. The errors from both are merged and passed to the teardown function that releases the serial devices. Notice that in this particular example the synchronization would occur at the end of program as long as there's at least one wire coming from each loop to the teardown function.
Similar functionality in a text based programming language would necessitate the use of more elaborate mechanisms, though some specialised language for parallel programming might help here.
I went over a few Verilog tutorials and reviewed the topics a couple times and a few questions have been lingering in my head from since the concepts were first introduced and if anyone could shed them light on them, that would be very helpful.
What's the purpose of strength on a net?
Often times in examples parameters exact names are used to also describe registers. For example:
module x (…,in1,…);
…
input in1;
reg [7:0] in1;
…
endmodule
Does this declare the input port as a type of data or are they separate? If the former is true, what other kinds of quantities can I do this with (integers, scalars, etc.)? If the latter is true which item am I referring to when I say “in1” inside the module?
Initial blocks at the beginning of a simulation all get executed in “parallel” but when you’re inside the block, the instructions are executed serially. Does the simulation tool you’re using determine what order the serially executed instructions are done in? For instance you have 2 initial blocks, do we execute all of one first, or jump back and forth?
4 .Why are initial values in simulation X? If Verilog’s job is to represent real life why doesn’t it have a pseudo random engine and pick the same random order of bits for all the values at the beginning? You run into a lot of issues with unique case statement warnings and it seems like a design flaw or at least an incongruity between system Verilog and Verilog.
Lets you have multiple drivers on a net and determine the value of the resulting signal; see 7.10 in the LRM
They're all the same in1 - very verbose. In V-2001 you can write a single input reg[7:0] in1 in the port list instead. You can do this for anything that you connect through a port.
Note that initial's are not guaranteed to be executed before always, and there is no guaranteed order of execution between any initial/always blocks in your design. In practice, the simulator chooses a block, and executes it until it reaches a suspend point (a timing control), at which point the sim schedules another initial or always, and executes that until it suspends, and so on.
This is essentially philosphy, but why would you want to assign initial random values to anything? This is basically what 'unknown' (X) means (or Z for nets). If everything is X or Z at the beginning of time, then you know that it's uninitialised and will remain so until you do something to it. If the tool gave everything initial random valid values you'd never know that.
In case of a contention strength helps to resolve to a known value. Last time I saw something like this in a design was it 10 years ago. And even then it was considered to be a bad design practice.
As EML says it.
No and No. The statements in any procedural block such as initial block are executed sequentially within the same time-slot. The initial blocks begin execution at time 0. The simulator executes all the statements in the order they appear inside the initial block as per the verilog event queue. The variables are updated as per the schedule dictated by the event queue. All of this is part of the standard (LRM 8.10). If you are not familiar with verilog event queue and the notion of time-slots and simulation time then Cliff Cumming's paper is a great reference. It doesn't matter if the simulator executes the statements from different initial blocks interleaved or any other way. The simulation time doesn't advance and the variables are only updated based on the event queue.
What is not standard is which initial block the simulator should begin with. This becomes important because this creates dependency on the simulator if variables are assigned in one initial block and used in the other procedural block within the same event queue. Cumming's paper referenced above explains this scenario very nicely.
It's not just about the unresolved state of the net. But also about starting the simulation from a predictable state. Therefore, randomly picking the resolved state of the inputs to the design would not provide the predictability in starting the simulator from the same point everytime. In addition to EML's suggestion, you may use the 2-state datatypes provided in SystemVerilog. Ofcourse, these are not synthesizable. Because, to accurately model the hardware you want the output state to be unknown if the inputs are unknown.