Reading this , i came across the term "Clock tick".
In this case, what is this clock tick?
Clock tick is an interrup sent by the hardware internal clock every X cycles (or X nano seconds).
This is used a reliable timer that stops you from whatever you are doing every constant period.
Related
When sending an esp32 device to sleep for approximately a day, it wakes up 3.34% earlier than expected. This amounts to approx 48 minutes.
Is this the expected accuracy of this device or can it be tuned to be more accurate?
The concrete device is an ESP32-CAM and it is running at 80MHz at approx 25°C room temperature.
Code to send the device to sleep:
unsigned int time_to_sleep_sec = 86400;
esp_sleep_enable_timer_wakeup(1ULL * unsigned int time_to_sleep_sec * 1000 * 1000);
esp_deep_sleep_start();
Instead of 86400 seconds, the device woke up after approx 83465 seconds.
the default RTC clock source is only 5% accurate, so it's within spec. Check the info:
The RTC timer has the following clock sources:
Internal 150kHz RC oscillator (default): Features lowest deep sleep
current consumption and no dependence on any external components.
However, as frequency stability is affected by temperature
fluctuations, time may drift in both Deep and Light sleep modes.
External 32kHz crystal: Requires a 32kHz crystal to be connected to
the 32K_XP and 32K_XN pins. Provides better frequency stability at the
expense of slightly higher (by 1 uA) Deep sleep current consumption.
External 32kHz oscillator at 32K_XN pin: Allows using 32kHz clock
generated by an external circuit. The external clock signal must be
connected to the 32K_XN pin. The amplitude should be less than 1.2 V
for sine wave signal and less than 1 V for square wave signal. Common
mode voltage should be in the range of 0.1 < Vcm < 0.5xVamp, where
Vamp is signal amplitude. Additionally, a 1 nF capacitor must be
placed between the 32K_XP pin and ground. In this case, the 32K_XP pin
cannot be used as a GPIO pin.
Internal 8.5MHz oscillator, divided by
256 (~33kHz): Provides better frequency stability than the internal
150kHz RC oscillator at the expense of higher (by 5 uA) deep sleep
current consumption. It also does not require external components.
So if you aren't able to add components, the 5uA 'expense' appears to be reasonable. Otherwise the best solution is to add an external 32kHz crystal.
Or you wakeup the device during sleep to correct the time with help of the internet like SNTP.
I would like to know if it is possible to modify easily perf linux with stat module to create an interval of cycles (or instructions by cycle) instead of an interval of time ? The goal is to optimize the precision of the counters got by interval. The time unit is not accurate enough.
I have a friend which submits this idea but I looked the source code a little and I understood (maybe I have wrong) that we :
create a condition for a time calculated with the rdtsc library (some clock_gettime)
create a "wait" in the perf processus
launch the program to test
test if we respect the time condition : we continue or we break the wait function with a save on the mapped register system information in perf (and call the wait function if it is not over)
I would like this result :
cycles counts unit events
10000 25000 instructions
10000 450 branch-misses
20000 21000 instructions
20000 850 branch-misses
Unfortunately, I'm seeing a big problem if I want to use the result of a counter like a condition I have not yet. Or should I get all the time this or these counter(s) which define my "interval condition" ? I also saw that for a time interval, we shouldn't get counters with a frequency lower than 100ms because it generates overhead. If I get some counters every 10000 cycles, would I have the same problems ? I don't know where is this overhead (calls system ?).
I have designed an algorithm-SHA3 algorithm in 2 ways - combinational
and sequential.
The sequential design that is with clock when synthesized giving design summary as
Minimum clock period 1.275 ns and Maximum frequency 784.129 MHz.
While the combinational one which is designed without clock and has been put between input and output registers is giving synthesis report as
Minimum clock period 1701.691 ns and Maximum frequency 0.588 MHz.
so i want to ask is it correct that combinational will have lesser frequency than sequential?
As far as theory is concerned combinational design should be faster than sequential. But the simulation results I m getting for sequential is after 30 clock cycles where as combinational there is no delay in the output as there is no clock. In this way combinational is faster as we are getting instant output but why frequency of operation of combinational one is lesser than sequential one. Why this design is slow can any one explain please?
The design has been simulated in Xilinx ISE
Now I have applied pipe-lining to the combinational logic by inserting the registers in between the 5 main blocks which are doing the computation. And these registers are controlled by clock so now this pipelined design is giving design summary as
clock period 1.575 ns and freq 634.924 MHz
Min period 1.718 ns and freq 581.937.
So now this 1.575 ns is the delay between any of the 2 registers , its not the propagation delay of entire algorithm so how can i calculate propagation delay of entire pipelined algorithm.
What you are seeing is pipelining and its performance benefits. The combinational circuit will cause each input to go through the propagation delays of the entire algorithm, which will take at up to 1701.691ns on the FPGA you are working with, because the slowest critical path in the combinational circuitry needed to calculate the result will take up to that long. Your simulator is not telling you everything, since a behavioral simulation will not show gate propagation delays. You'll just see the instant calculation of your combinational function in your simulation.
In the sequential design, you have multiple smaller steps, the slowest of which takes 1.275ns in the worst case. Each of those steps might be easier to place-and-route efficiently, meaning that you get overall better performance because of the improved routing of each step. However, you will need to wait 30 cycles for a result, simply because the steps are part of a synchronous pipeline. With the correct design, you could improve this and get one output per clock cycle, with a 30-cycle delay, by having a full pipeline and passing data through it at every clock cycle.
is there any function that returns channel busy time? I use veins-2.2, mac and decider 802.11p. if there is not such function, how measuring the channel busy time is possible?
Channel busy time in Veins 2.2 is measured at two points: in the Phy layer and in the Mac layer. Both record a corresponding scalar value at the end of the simulation. Note that there is a difference in meaning between the two:
Mac busy time is (in almost all cases) what you want to record: it records how many seconds the Mac treated the channel as busy. Divide the scalar totalBusyTime by the total simulation time and you know the fraction of time that the Mac could not send.
Phy busy time is calculated very different: its value busyTime increases for each frame received above the sensitivity threshold. To give an example, if 1 frame is being received at any given time during the simulation, the value of this scalar would be 100%. If 4 frames are interfering for all of your simulation, the value of this scalar would be 400% (which is different to the Mac busy time you probably want).
I'm writing a state machine which controls data flow from a chip by setting and reading read/write enables. My clock is running at 27 MHz giving a period of 37 ns. However the specification for the chip I'm communicating with requires I hold my 'read request' signal for at least 50 ns. Of course this isn't possible to do in one cycle since my period is 37 ns.
I have considered I could create an additional state which does nothing but flag the next state to be the one I actually complete the read on, hence adding another period delay (meaning I hold 'read request' for 74 ns), but this doesn't sound like good practice.
The other option is perhaps to use a counter, but I wonder if there's perhaps yet another option I haven't visited yet?
How should one implement delay in a state machine when a state should last longer than one clock period?
Thanks!
(T1 must be greater than 50 ns)
Please see here for the full datasheet.
Delays are only reliably doable using the clock - adding an extra "tick" either via an extra state or using a counter in the existing state is perfectly acceptable to my mind. The counter has the possibility of being more flexible if you re-use the same state machine with a slower external chip (or if you use a different clock frequency to feed the FPGA) - you can just change the maximum count, instead of adding multiple "wait" states to the state machine.