Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: m-labs/artiq
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 4048568d8edb
Choose a base ref
...
head repository: m-labs/artiq
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 6f7d74a76591
Choose a head ref
  • 2 commits
  • 5 files changed
  • 1 contributor

Commits on May 3, 2015

  1. Copy the full SHA
    2adf9d9 View commit details
  2. Copy the full SHA
    6f7d74a View commit details
Showing with 11 additions and 5 deletions.
  1. +1 −0 .gitmodules
  2. +1 −1 artiq/coredevice/core.py
  3. +1 −1 benchmarks/pulse_rate.py
  4. +6 −1 doc/manual/faq.rst
  5. +2 −2 doc/manual/getting_started.rst
1 change: 1 addition & 0 deletions .gitmodules
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
[submodule "soc/runtime/lwip"]
path = soc/runtime/lwip
url = git://git.savannah.nongnu.org/lwip.git
ignore = untracked
2 changes: 1 addition & 1 deletion artiq/coredevice/core.py
Original file line number Diff line number Diff line change
@@ -129,6 +129,6 @@ def get_rtio_time(self):
return cycles_to_time(syscall("rtio_get_counter"))

@kernel
def recover_underflow(self):
def break_realtime(self):
t = syscall("rtio_get_counter") + 125000
at(cycles_to_time(t))
2 changes: 1 addition & 1 deletion benchmarks/pulse_rate.py
Original file line number Diff line number Diff line change
@@ -20,7 +20,7 @@ def run(self):
delay(cycles_to_time(T))
except RTIOUnderflow:
T += 1
self.core.recover_underflow()
self.core.break_realtime()
else:
self.pulse_rate = cycles_to_time(2*T)
break
7 changes: 6 additions & 1 deletion doc/manual/faq.rst
Original file line number Diff line number Diff line change
@@ -4,6 +4,11 @@ FAQ
How do I ...
============

prevent my first RTIO command from causing an underflow?
--------------------------------------------------------

The RTIO timestamp counter starts counting at zero at the beginning of the first kernel run on the core device. The first RTIO event is programmed with a small timestamp above zero. If the kernel needs more time than this timestamp to produce the event, an underflow will occur. You can prevent it by calling ``break_realtime`` just before programming the first event.

override the `sysclk` frequency of just one DDS?
------------------------------------------------

@@ -12,7 +17,7 @@ Override the parameter using an argument in the DDB.
organize parameters in folders?
-------------------------------

Use gui auto-completion and filtering.
Use GUI auto-completion and filtering.
Names need to be unique.

enforce functional dependencies between parameters?
4 changes: 2 additions & 2 deletions doc/manual/getting_started.rst
Original file line number Diff line number Diff line change
@@ -47,7 +47,7 @@ Modify the code as follows: ::
@kernel
def run(self):
s = input_led_state()
self.core.recover_underflow()
self.core.break_realtime()
if s:
self.led.on()
else:
@@ -63,7 +63,7 @@ You can then turn the LED off and on by entering 0 or 1 at the prompt that appea

What happens is the ARTIQ compiler notices that the ``input_led_state`` function does not have a ``@kernel`` decorator and thus must be executed on the host. When the core device calls it, it sends a request to the host to execute it. The host displays the prompt, collects user input, and sends the result back to the core device, which sets the LED state accordingly.

The ``recover_underflow`` call is necessary to waive the real-time requirements of the LED state change (as the ``input_led_state`` function can take an arbitrarily long time). This will become clearer later as we explain timing control.
The ``break_realtime`` call is necessary to waive the real-time requirements of the LED state change (as the ``input_led_state`` function can take an arbitrarily long time). This will become clearer later as we explain timing control.

Algorithmic features
--------------------