joewing / scalapipe Goto Github PK

Currently it is necessary to use either "returns" or "output" in a function to specify the return type. It should be possible to infer the return type from the "ret" statement.

Currently, it is not possible to set a parameter, such as queueDepth, on a per-edge basis.

There are lots of remnants from the past in the generated C and HDL code that should be removed/cleaned up.

Currently, config parameters appear as ASTNode objects, so they can't be used as the size for a Vector.

Currently, the FIFOs between kernels for HDL kernels are single registers. ScalaPipe should instead use FIFOs of the specified size and only use a register for FIFOs that are 1 deep.

Currently individual kernels can have config options that are set in the Application DSL, but there's no way to set config options for the Application DSL.

Currently AutoPipeBlock and AutoPipeFunction exist. These should be replaced by AutoPipeKernel. It should be possible to use a kernel with zero or one outputs as a "function". To deal with having separate code, separate header files and code should be generated to handle kernels that are used as functions (within other kernels) and kernels used as streaming kernels (within the application DSL).

Currently if an output is connected to multiple inputs, ScalaPipe will generate invalid C code. It should instead automatically insert dup blocks. At the very least it should warn about the situation rather than generating invalid code.

It is currently possible to specify a config parameter on the command line (issue #18), but there is currently no way to route those parameters to a Kernel that is mapped to an FPGA device. Further, config parameters that affect sizing of Vectors (issue #20) are particularly problematic. The simplest solution is to disallow config parameters for FPGA kernels on the command line.

Currently ScalaPipe does not set CPU masks for threads. It should set a mask if one is specified.

The old "While", "If", etc. functions should be removed since ScalaPipe uses Scala Virtualized.

Functions for the OpenCL target are not currently supported.

For kernels mapped to an FPGA, the RAM signals should be combined via an arbiter and exposed through the top level with an optional memory subsystem. Currently, each kernel gets it own RAM backed by block RAMs.

Currently the "<>" operator is used for inequality instead of != due to problems overriding the != operator.

The "autopipe" package should be replaced with "scalapipe" and the "AutoPipe" classes should be replaced with "ScalaPipe".

Currently ScalaPipe will allow a program to read from an output port. This should be flagged as an error.

As currently implemented, ScalaPipe applications do not cleanly shut down when one or more kernels are mapped to hardware. At least in the case of simulation, it should be possible to add another signal to and from simulation to properly handle shutdown.

An AutoPipeFunction can be used as either a block or a function in a ScalaPipe program. However, attempting to use it as both causes problems since the emitted code is different, but will be stored in the same place.
A possible solution is to name blocks and functions differently, but this causes problems with external blocks.

The scheduler tries to run blocks when they cannot be run due to the unavailability of inputs and/or outputs. There is a hack fix for this by surrounding the code that tries to read/write from the input/output with an avail() check before reading from or writing to the stream.

Right now the HDL optimizations take way too long with large kernels. State space compression is particularly bad.

Floating point transcendental functions are not yet implemented for HDL blocks. This includes sin, cos, tan, log, and exp.

Integer square root is not yet implemented for HDL kernels.

The width of multipliers for FPGA kernels should depend on the resources available. For example, Xilinx FPGAs have DSPs that can be inferred from 18-bit multipliers.
Currently, the code assumes 18-bit multipliers are available.

Currently, classes that describe kernels use a separate DSL from classes that describe the application topology. Merging the two DSLs into one would make it possible to specify mapping information at a more granular level.