Updated after discussion on 10 june by Daniel, Harm Jan and Eric

tools/oneclick/prestudy/oneclick_prestudy_readme.txt

@@ -24,45 +24,76 @@ This file keeps some historical notes on the OneClick prestudy results.
   chain of BG > MUX > DB. Threads provide parallelism however in Python they
   all run in one process, so on one core.
   
-  - Remarks:
-  a modelling fanin is not needed, because this does not occur in the digital
+3)Agreed remarks, 10 june 2014:
+  a the model should reflect the digital problem domain, i.e. like a schematic.
+    this approach can help to decide what to model and how much. The model 
+    (the solution) should not be more complex than the reality (the problem).
+  b if the oneclick tool is setup well structured with a few basic concepts
+    then also apperently sophisticated features of modelling and code
+    generation will come for free.
+  c modelling fanin is not needed, because this does not occur in the digital
     domain
-  b modelling fanout does occur, e.g. mux connects to 2 DB, or a stream that
+  d modelling fanout does occur, e.g. mux connects to 2 DB, or a stream that
     also connects to a dp_bsn_monitor.
-  c components can connect using there default IO indexing like bg > mux, but
+  e connections can be modelled by queues or pipes. The queue builds on top of
+    pipe, pipe simulates faster, is using pipe sufficient for our modelling
+
+4)Open remarks:
+  a components can connect using there default IO indexing like bg > mux, but
     there are also use cases for connecting components per stream using
     alterantive indexing, e.g. to use only one output of dp_split or e.g. to
     connect bg[0] > mux[1] and bg[1] > mux[0]
-  d connections can be modelled by queues or pipes. The queue builds on top of
-    pipe, pipe simulates faster, is using pipe sufficient for our modelling
-  e where is the is the connection modelled, as a seperate object, as part of 
-    every component snk (to support fanout)? 
-  f the statement bg > mux > db has multple '>' connectors per statement, this
+  b where is the is the connection modelled, as a seperate object, as part of 
+    every component snk (to support fanout)?
+  c do we need to model something like VHDL signals? Note that the signals in
+    VHDL are kind of objects with methods like 'EVENT. What about the other
+    items in VHDL like ports, generics?
+  d the statement bg > mux > db has multple '>' connectors per statement, this
     works because bg > mux returns the output of mux as input for db. Does this 
     properly reflect the digital domain.
-  g what does the connector '>' reflect, is it the data transport or also the
+  e what does the connector '>' reflect, is it the data transport or also the
     structure. The data transport function is important for the functional
     simulation of the model. The structure function is important for
     the code generation from the model.
-  h does the structure need hierarchy or does flat interconnect better match
+  f does the structure need hierarchy or does flat interconnect better match
     the problem domain. For a multi node model using hierarchy seems
     appropriate. Similar for creating higher level components in Python,
     provided 
-  h MyHDL uses the return of functions that model the RTL processes to create
+  g MyHDL uses the return of functions that model the RTL processes to create
     the structure.
-  i what about defining also an '=' operator like in d = bg > mux. Does the '='
+  h what about defining also an '=' operator like in d = bg > mux. Does the '='
     create hierarchy or is d merely an auxiliary variable. The purpose of 
     hierarchy is to facilitate reuse (i.e. multple instances) or to make the
     code more clear. 
-  j what about using '(' and ')' like in d = bg > mux > (db0, db1), is that
+  i what about using '(' and ')' like in d = bg > mux > (db0, db1), is that
     useful or too much
-  k having 800 processes per machine seems sufficient, but can it been
+  j having 800 processes per machine seems sufficient, but can it been
     increased and how.
-  l The model should reflect the digital problem domain, i.e. like a schematic.
-    this approach can help to decide what to model and how much. The model 
-    (solution) should not be more complex than the reality (the problem).
-
-  - next steps:
-  DS investigate c)
-  HJP investigat b), d)
+  k d = a > b > c and then d.generate() generates the VHDL. The toplevel of d
+    gets the input of a and the output of c. There structure canbe constructed
+    in two steps, first instantiate a, b, c with signals on there ports and
+    then assign these signals to make the connections.
+  l propagate all generics to the top entity d or fill in all generics and
+    propagate no generic to the top entity, or some intermediate scheme. If
+    the composite d needs to be reused then it may be useful to still keep 
+    some generics.
+  m using p = a > b and then d = p > c and then d.generate() creates VHDL 
+    with hierachy p. using d = a > b > c and then d.generate() creates a flat
+    structural VHDL.
+  n using p = a > b and q = a > e and then d = p > c and then d.generate()
+    creates VHDL for d and to no VHDL for q, i.e. q and the connection from
+    a to e only exist at the modelling level.
+    
 
+5) next steps:
+  
+  It is to early to actually start implemeting e.g. parts of the code
+  generation like parsing a VHDL entity, first we need to:
+  
+  a get more clear what is needed for a python base class for modelling and
+    code generation.
+  b think of more use cases to find out what we need to represent and how.
+  
+  DS  propose a python setup in SVN for the oneclick prestudy investigations
+  HJP .
+  EK  .