Corrected some help contents
diff --git a/plugins/org.eclipse.app4mc.amalthea.model.help/docu/dev_model_xsd.textile b/plugins/org.eclipse.app4mc.amalthea.model.help/docu/dev_model_xsd.textile
index 22b8ba0..99bfe6f 100644
--- a/plugins/org.eclipse.app4mc.amalthea.model.help/docu/dev_model_xsd.textile
+++ b/plugins/org.eclipse.app4mc.amalthea.model.help/docu/dev_model_xsd.textile
@@ -15,7 +15,7 @@
The AMALTHEA model references an external model definitions:
- The Ecore model (http://www.eclipse.org/emf/2002/Ecore)
-The XSD file for the Ecore model can be found on the "Eclipse EMF download page":http://www.eclipse.org/modeling/emf/downloads/
+The XSD file for the Ecore model can be found on the "Eclipse EMF download page":https://download.eclipse.org/modeling/emf/emf/builds/index.html
Download the __Models__ package from __Latest Releases__. The download contains a folder "org.eclipse.emf.ecore_*". This folder contains the XSD schema for Ecore.
---
diff --git a/plugins/org.eclipse.app4mc.amalthea.model.help/docu/model_hw.textile b/plugins/org.eclipse.app4mc.amalthea.model.help/docu/model_hw.textile
index 0683164..c690b46 100644
--- a/plugins/org.eclipse.app4mc.amalthea.model.help/docu/model_hw.textile
+++ b/plugins/org.eclipse.app4mc.amalthea.model.help/docu/model_hw.textile
@@ -172,7 +172,7 @@
A _HwFeature_ is an abstract element to represent any kind of special functionality of a _ProcessingUnitDefinition_. _HwFeatures_ could be reused several times by different definitions and organized within _HwFeatureCategories_. Currently this _HwFeatureCategories_ are directly referenced out of the Software Model in future the cost function (_Recipes_) of an algorithm will be placed in an additional intermediate layer. More information can be found in the User Guide --> Concepts --> Hardware.
-<em>NOTE: The _Recipes_ and the _HwFeatures_ concept is still work in progress. Changes to the _HwFeatures_ are probable.</em>
+_NOTE: The concepts "Recipe" and "Hardware Features" are work in progress. Changes to the already implemented HwFeatures are probable._
!(scale)../pictures/hardware/hw_feature_example.png!
diff --git a/plugins/org.eclipse.app4mc.amalthea.model.help/docu/user_timing.textile b/plugins/org.eclipse.app4mc.amalthea.model.help/docu/user_timing.textile
index 7047c91..252e34c 100644
--- a/plugins/org.eclipse.app4mc.amalthea.model.help/docu/user_timing.textile
+++ b/plugins/org.eclipse.app4mc.amalthea.model.help/docu/user_timing.textile
@@ -11,7 +11,7 @@
Stimulation of task execution with corresponding stimuli events, and scheduling in general, is not further discussed here. In the following, we focus on timing of execution at processing units. The basic mechanism to specify execution time at a processing unit is the modeling element *ticks*. Ticks are a generic abstraction of time. Regarding hardware one may think of ticks as clock ticks or cycles of the processor. You can specify ticks at several places in the model, most prominently as a runnable item of a runnable. The ticks value together with a mapping to a specific processing unit that has a defined frequency then allows computation of an execution time. For instance, 100 ticks require 62.5ns simulated time at a processing unit with 1.6GHz, while 100 ticks require 41.6ns at a processing unit with 2.4GHz.
-In general, the runnable items of a runnable are specified as a directed, acyclic graph (DAG). Processing this DAG from perspective of a discrete event simulator then defines the timing of executing the runnable at a specific processing unit. Amalthea allows for many different types of runnable items that can be categorized as: items that branch paths of the DAG (runnable mode switch, runnable probability switch); items that signal other parts of the model (custom event trigger, runnable call, etc.); items that specify data access (channel receive/send, label access); and items that translate in execution time (ticks, execution needs). When the discrete event simulator simulates execution of a runnable at a processing unit, it actually processes runnable items and translates their semantics into simulation events. We already discussed the runnable item ticks: when ticks are processed, a corresponding simulation time value is computed based on the executing processing unitÂ’s frequency, and a simulation event is stored in the list of simulation events for when the execution will finish. While ticks denote a fixed (static) timing, data accesses may result in series of simulation events, depending on access paths and mapping of data to memory. The timing of data accesses then depends on parameters such as delay and state of hardware structure elements such as connection handlers.
+In general, the runnable items of a runnable are specified as a directed, acyclic graph (DAG). Processing this DAG from perspective of a discrete event simulator then defines the timing of executing the runnable at a specific processing unit. Amalthea allows for many different types of runnable items that can be categorized as: items that branch paths of the DAG (runnable mode switch, runnable probability switch); items that signal other parts of the model (custom event trigger, runnable call, etc.); items that specify data access (channel receive/send, label access); and items that translate in execution time (ticks, execution needs). When the discrete event simulator simulates execution of a runnable at a processing unit, it actually processes runnable items and translates their semantics into simulation events. We already discussed the runnable item ticks: when ticks are processed, a corresponding simulation time value is computed based on the executing processing unit's frequency, and a simulation event is stored in the list of simulation events for when the execution will finish. While ticks denote a fixed (static) timing, data accesses may result in series of simulation events, depending on access paths and mapping of data to memory. The timing of data accesses then depends on parameters such as delay and state of hardware structure elements such as connection handlers.
Note that the current version of Amalthea (0.9.3) also prepares an additional concept for specification of execution timing besides using ticks: *execution needs*. Execution needs will allow sophisticated ways of execution time specification, as required for heterogeneous systems: Execution needs define the number of usages of user-defined needs; a later version of Amalthea (> 0.9.3) then will introduce recipes that translate such execution needs into ticks, taking hardware features of the executing processing unit into account. Note that, by definition, a sound model for timing simulation always allows to compute ticks from execution needs. Consequently, for timing analysis using discrete event simulation as described above, we first translate execution needs into ticks, resulting in a model we call ticks-only model. Thus, execution needs can be ignored for timing analysis.
