Differences

This shows you the differences between two versions of the page.

--- tools:chp2prs [2025/10/14 02:47] – [External Constants] karthi
+++ tools:chp2prs [2025/11/04 03:06] (current) – [External Constants] karthi
@@ Line 21: / Line 21: @@
 i.e. a (possibly empty) semi-colon separated list of initializations to a subset of variables used in the CHP, followed by an infinite repetition of an arbitrary CHP program P. The values ''vi'' must evaluate to constants. There are no restrictions on ''P'', but some forms of ''P'' will lead to circuits that are much more expensive compared to others, as we will see later. Further, the channel implementation leads to all receives being passive and all sends being active. This means that (currently) only the receiving side may probe a channel. At the process level, the ports of a process may only be channels or Booleans (see section below on external constants for usage).
+===== Synthesis Commands =====
+The standard synthesis steps to produce a bundled-data circuit looks like this:
+ <code>
+synth2 -F decomp -p proc -o mid.act in.act
+synth2 -F ring -ref=1 -C bd -p decomp_proc -o out.act mid.act
+</code>
+You can then simulate at PRS-level with:
+<code>
+actsim -ref=2 out.act ring_decomp_proc
+</code>
+Note that user-defined channel-types are not allowed for synthesis. Only the built-in ''chan'' type is supported. The implementation of the channel is chosen during synthesis with the ''-C'' flag that chooses the datapath type.
+If your CHP has no nested loops or multiple-channel accesses (more about this below), then you can (optionally) skip the first step and directly do:
+ <code>
+synth2 -F ring -C bd -p proc -o out.act in.act
+</code>
+and simulate at PRS-level with:
+<code>
+actsim -ref=1 out.act ring_proc
+</code>
+This two-step process will soon be integrated into one command (TODO). To know more about what the ''-ref=n'' flags mean, please see this page: [[language:langs:refine|Refinement]].
 ===== Program Structure =====
@@ Line 74: / Line 97: @@
 <code>
-[ c      -> y:=huge_expensive_computation
+[ c    -> y:=huge_expensive_computation
 []else -> y:=0
 ]
@@ Line 164: / Line 187: @@
 Maelstrom allows Booleans as input ports to any process to facilitate chip-level configuration bits. These booleans are assumed to be constant for the entire runtime of the circuit, i.e. these are set to a certain value before or during chip reset and never changed after that. Hence, these Booleans are also not latched, the values on the wires are used directly as if they are logical constants, such as ''Vdd'' or ''GND''.
-These are useful for global configuration. For example, consider a neuromorphic core where all the state-update function of all the neurons need to be set to something. Instead of sending a config bit to each of the potentially thousands of neurons, one can simply use a ''bool'' and save on the communication and latching overhead, since it is known that this will not change during the runtime of the core:
+These are useful for global configuration. For example, consider a neuromorphic core where the state-update functions of all the neurons need to be set to something. Instead of sending a config bit to each of the potentially thousands of neurons, one can simply use a ''bool'' and save on the communication and latching overhead of broadcasting a single bit from one process to thousands, since it is known that this bit will not change during the runtime of the core:
 <code>
-defproc neuron ( ... , bool model_select )
+defproc neuron ( ... ; bool model[2] )
 {
 ...
 chp
  {
-*[
+ *[
   ...
-    [  model_select -> state := lif(state)
+    [ ~model[0] & ~model[1] -> state := lif(state)
-    []~model_select -> state := izhikevich(state)
+    []~model[0] &  model[1] -> state := aif(state)
+    [] model[0] & ~model[1] -> state := hodg_hux(state)
+    [] model[0] &  model[1] -> state := izhikevich(state)
     ];
   ...
@@ Line 181: / Line 206: @@
  }
 }
 </code>