asyncvlsi / dflowmap Goto Github PK

Hi, I have download the source code of dflowmap, and install it by following steps:
unzip dflowmap-main.zip
cd dflowmap-main
sh build.sh
cd ..

But the process has some error:
No rule to make target libexpropt.a, needed by src/dflowmap Stop.

How to solve the problem?

Thanks!

I think there might be a bug when using bool channels:
Consider the following act code:

defproc test(chan?(bool) a; chan!(bool) b)
{
	dataflow {
		a -> [1] b
	}
}

This produces the following chp code:

defproc test (chan(bool)? a; chan(bool)! b)
{
chan(int<1>) b_bufIn;
func_0W1W1 b_bufIn_inst(a, b_bufIn);
lib::onebuf<1> b_inst(b_bufIn, b);
}

It keeps the bool channels for the interface, but then uses int<1> channels internally. Loading this code using interact's act:read command then yields:

ERROR: File `test_chp.act', line 9, col 31
	Typechecking failed on connection! (position: 0)
	Types `chan(int<1>)?' and `chan(bool)?' are not compatible

The specification of the dataflow sublanguage at (https://avlsi.csl.yale.edu/act/doku.php?id=language:langs:dflow) states that if the number of buffer stages in brackets is not specified the default value is 1.

From that I would conclude that test1 and test2 should be semantically equivalent:

defproc test1(chan?(int<1>) a; chan!(int<1>) b)
{
	dataflow {
		a -> b
	}
}

defproc test2(chan?(int<1>) a; chan!(int<1>) b)
{
	dataflow {
		a -> [1] b
	}
}

However, when converted to CHP there is a difference. test1 looks fine with func_0W1W1 containing the buffer.

defproc func_0W1W1(chan?(int<1>)in0; chan!(int<1>) out0) {
  int<1> x0;
  int<1> res0; /* out */
  chp {
    *[
      in0?x0;
      log("receive (", x0, ")");
      res0 := x0;
      out0!res0;
      log("send (", res0, ",", ")")
    ]
  }
}

defproc test1 (chan(int<1>)? a; chan(int<1>)! b)
{
func_0W1W1 b_inst(a, b);
}

However, test2 gets two buffers. One in func_0W1W1 and another one in the actual test2 process.

defproc test2 (chan(int<1>)? a; chan(int<1>)! b)
{
chan(int<1>) b_bufIn;
func_0W1W1 b_bufIn_inst(a, b_bufIn);
lib::onebuf<1> b_inst(b_bufIn, b);
}

Did I misunderstand the documentation or is this actually a bug? If its bot a bug, I think, it would be a good idea to clarify the difference in the documentation.