I am confused as I have seen that in some cases it increases the delay and in some cases it reduces the delay
There is no such thing as a "digital path" in electronics. VLSI is a connection of transistors involving analog voltage(V), current(I), and resistance(R). We have abstracted that all away from you in the form of digital hardware description languages. But in the end, a device needs to drive VIR to a collection of fanout receivers. The transistors in the driver needs to be properly sized to handle that fanout. But generally the larger the fanout, the longer the delay becomes. Adding buffers can help redistribute the fanout and improve the delay.
Related
I seem to have coded myself into a corner with the following issue: I'm trying to control a motor on a robot through a slow RS485-based bus connection. Unfortunately, I don't have access to the firmware on the motor, so I'm stuck with the current setup.
The biggest issue is that I can only control the motor's target speed. While I can retrieve its absolute position through a built-in encoder, there is no positioning function built into the firmware on the motor itself.
The second issue is that the bus connection is really slow, the somewhat awkward protocol needs 25 ms for a full cycle - is controlling a position via speed adjustments even feasible this way?
I have a tried a naive approach of estimating the position 25 ms ahead, subtracting the current position and dividing by 25 ms to calculate the speed required to the next desired position. However, this oscillates badly at certain speeds when targeting a fixed position, I assume due to the high cycle times producing a lot of overshoot.
Maybe a PID controller could help, but I am unsure what the target value would be -- every PID I have used so far used a fixed target. A completely moving target (i.e. the position) is hard to imagine, at least for me.
What's the usual way to deal with a situation like this? Maybe combine the naive approach and add PID-control only for an additional offset term? Or do I need to buy different motors?
If you want to keep the benefits of rs485 (it has some great positive things), then you likely would need to rethink how you drive this engine.
It might be easier to change the motor control, so that you only have to send some numeric data as "end position" and leave it to you smart control to handle that. In that situation your rs485 communication is minimal.
I always tend to think keep the "brains" at place where they are needed in industrial environments so you keep your IO down, or else someday you end up with behemoths such as industrial ethernet.
I need to realize a source-synchronous receiver in a Virtex 6 that receives data and a clock from a high speed ADC.
For the SERDES Module I need two clocks, that are basically the incoming clock, buffered by BUFIO and BUFR (recommended). I hope my picture makes the situation clear.
Clock distribution
My problem is, that I have some IOBs, that cannot be reached by the BUFIO because they are in a different, not adjacent clock region.
A friend recommended using the MMCM and connecting the output to a BUFG, which can reach all IOBs.
Is this a good idea? Can't I connect my LVDS clock buffer directly to a BUFG, without using the MMCM before?
My knowledge about FPGA Architecture and clocking regions is still very limited, so it would be nice if anybody has some good ideas, wise words or has maybe worked out a solution to a similar problem in the past.
It is quite common to use a MMCM for external inputs, if only to cleanup the signal and realize some other nice features (like 90/180/270 degree phase shift for quad-data rate sampling).
With the 7-series they introduced the multi-region clock buffer (BUFMR) that might help you here. Xilinx has published a nice answer record on which clock buffer to use when: 7 Series FPGA Design Assistant - Details on using different clocking buffers
I think your friends suggestion is correct.
Also check this application note for some suggestions: LVDS Source Synchronous 7:1
Serialization and Deserialization Using
Clock Multiplication
I'm trying to troubleshoot drops in FPS. I see that Metal Flushes are what takes up most of the rendering time. Is that a good thing?
I am not sure about this, since Apple does not seem to have documented what exactly a "Metal Flush" is anywhere, but I'll answer based on previous experience with OpenGL:
During the execution cycle of a GPU-powered application, the CPU will push data to the GPU, wait for the GPU to finish operating on this data (possibly doing other work in the meantime), and as soon as the GPU is done, push more data and request more operations. Typically, "flushing" would mean that the CPU is waiting on the GPU to finish operations ("flushing out old data") so that it can push more data to the GPU.
So, if my interpretation is correct, that would mean that "Metal flush" measures the time the CPU spends waiting on video memory to free up so it can push more data and request operations to the GPU. In that case, it could be a good thing or a bad thing:
There will always be some communication overhead between the CPU and the GPU, so if most of your rendering time is being taken up by "Metal Flush", it might mean that your application is just running fast enough that most of the delay between frames is just communications overhead. In that case, it would be a good thing.
On the other hand, you might be pushing a lot of data to the GPU and the time needed to copy the data and process it might be causing delays. In that case, it would be a bad thing.
In the end, the important thing here is to ensure your FPS is consistently high. If your FPS is dropping due to "Metal Flush", you might want to try to space out your data transfers - for instance, storing textures in chunks and/or using lower resolution textures would probably help with that.
I have a lab project that uses mainly PyAudio and to further understand its way of working I made some measurements, in this case time between callbacks (using callback mode).
I timed it, and got an interesting result
(#256 chunk size, 44.1k fs): 0.0099701;0.0000365;0.0000201;0.0201579
This pattern goes on and on.
Between two longer calls, we have two shorter calls and sometimes the longer call is shorter (mind you I don't do anything else in the program than time the callbacks).
If we average this out we get our desired callback time:
1/44100 * 256 (roughly 5.8ms)
Here is my measurement visualized:
So can someone explain what exactly happens here under the hood?
What happens under the hood in PortAudio is dependent on a number of factors, including:
Which native audio API PortAudio is talking to
What buffer size and latency parameters you passed to Pa_OpenStream()
The capabilities of the audio hardware and its drivers, including its supported buffer sizes, buffering model and timing characteristics.
Under some circumstances PortAudio will request larger buffers from the native audio API and then invoke the PortAudio user callback multiple times in quick succession. This can happen if you have selected a small callback buffer size and a long latency.
Another scenario is that the native audio API doesn't support the buffer size that you requested for your callback size (framesPerBuffer parameter to Pa_OpenStream()). In this case PortAudio will be forced to use a driver-supported buffer size and then "adapt" between that buffer size and your callback buffer size. This adaption process can cause irregular timing.
Yet another possibility is that the native audio API uses a large ring buffer. Each time PortAudio polls the native host API, it will work to fill the native ring buffer by calling your callback as many times as needed. In this case irregular timing is related to the polling rate.
The above are not the only possibilities.
One likely explanation of what is happening in your case is that PortAudio is calling your callback 3 times in fast succession (a guess would be that the native buffer size is 3x your callback buffer size), for one of the reasons above.
Another possibility is that the native audio subsystem is signalling PortAudio irregularly. This can happen if a system layer below PortAudio is doing similar kinds of buffering to what I described above. I have seen this happen with DirectSound on Windows 7 for example. ASIO4ALL drivers will exhibit +/- 1ms jitter (which is not what you're seeing).
You can try reducing the requested stream latency to 0 and see if that changes the result. This will force double-buffering, which may or may not produce stable output. Another thing to try is to use the paFramesPerBufferUnspecified parameter, which will cause the callback to be called with the native buffer size -- then you can observe whether there is greater periodicity, what that buffer size is, and also whether the buffer size varies from callback to callback.
You didn't say which operating system and host API you're targetting, so it's hard to give more specific details than the above.
The internal buffering models used by the various PortAudio host API backends are described in some detail on the PortAudio wiki.
To answer a related question: why is it like this? Aside from the cases where it is a function of the lower layers of the native audio subsystem, or the buffer adaption process, it is often a result of specifying a large suggested latency to Pa_OpenStream(). Some PortAudio host APIs will relax the buffer periodicity if the specified latency is very high, in order to reduce system load that would be caused by high-frequency timer callbacks.
I'm looking to do some high precision core motion reading (>=100Hz if possible) and motion analysis on the iPhone 4+ which will run continuously for the duration of the main part of the app. It's imperative that the motion response and the signals that the analysis code sends out are as free from lag as possible.
My original plan was to launch a dedicated NSThread based on the code in the metronome project as referenced here: Accurate timing in iOS, along with a protocol for motion analysers to link in and use the thread. I'm wondering whether GCD or NSOperation queues might be better?
My impression after copious reading is that they are designed to handle a quantity of discrete, one-off operations rather than a small number of operations performed over and over again on a regular interval and that using them every millisecond or so might inadvertently create a lot of thread creation/destruction overhead. Does anyone have any experience here?
I'm also wondering about the performance implications of an endless while loop in a thread (such as in the code in the above link). Does anyone know more about how things work under the hood with threads? I know that iPhone4 (and under) are single core processors and use some sort of intelligent multitasking (pre-emptive?) which switches threads based on various timing and I/O demands to create the effect of parallelism...
If you have a thread that has a simple "while" loop running endlessly but only doing any additional work every millisecond or so, does the processor's switching algorithm consider the endless loop a "high demand" on resources thus hogging them from other threads or will it be smart enough to allocate resources more heavily towards other threads in the "downtime" between additional code execution?
Thanks in advance for the help and expertise...
IMO the bottleneck are rather the sensors. The actual update frequency is most often not equal to what you have specified. See update frequency set for deviceMotionUpdateInterval it's the actual frequency? and Actual frequency of device motion updates lower than expected, but scales up with setting
Some time ago I made a couple of measurements using Core Motion and the raw sensor data as well. I needed a high update rate too because I was doing a Simpson integration and thus wnated to minimise errors. It turned out that the real frequency is always lower and that there is limit at about 80 Hz. It was an iPhone 4 running iOS 4. But as long as you don't need this for scientific purposes in most cases 60-70 Hz should fit your needs anyway.