rdaly525/coreir

coreir's Issues

Update Generators and TypeGens to use a method called 'run' instead of a function pointer

Currently I have an ugly function pointer attached to the generators and Typegens. This should definitely just be a normal method.

One way to maintain usage of passing in a function pointer is to allow these classes to be inherited from the base class like:

class PassFunPtr : Typegen {
FunPtrType f;
PassFunPtr(FunPtrType f) : f(f) {}
Type* run(...) {
f(...)
}
}

Python API should never cause CoreIR to die

Update C and Python bindings such that you cannot get coreIR to die using the Python API

RunGenerator behavior needs to be fixed to prevent segfault

I am changing the runGenerator behavior to have the following api

//Will return a module after running the typegen
Generator::getModule(Args)

//Will set the moduleDef by running the generator
Generator::setModuleDef(Module,Args)

//Will run the generator based off the genargs that instance has
Instance::runGenerator()

pycoreir dies on opening symlinked files

Trying to open a symlink results in:

ERROR: Cannot open file ../test.json


I AM DYING!

Clearly not a high priority bug

Codebase cleanup

• Remove all "using namespace xxx" from any header files

• Add License file for freeBSD license

• Create a generic file comment header and add to every source file.

• Audit all the decisions to use class vs struct

• Go through all 'TODO's in code and resolve or move to a github issue

• Change code to use References rather than pointers when possible

• Add const when I can to the api.

• Add 'explicit' to all class constructors.

• Move defaults from class constructors to class data.

Why is flattening not segfaulting?

It seems like I am unsafely editing iterators

Add custom assert function that you can pass in a string

And update the asserts to use that one.

len(type) -> type.bit_width

Makes it more explicit and then we can have Bit.bit_width return 1

Create a Directed Graph view of CoreIR

This is HIGH priority so that Caleb can work on his stuff

Things we need to do to get this working.

• Create light wrapper classes around Module/Instances/Edges to represent directed graph
• Construct view by first verifying that it can be represented as such (error if not)
• Create c accessor and iterator functions (Should we change c api to have iterator operations instead of returning c arrays?)
• Update python bindings accordingly

Implement Verilog code generation

Implement uniquifying names for modules, generators and namedtypes

Fix bug in Instance.get_config_value

@cdonovick Can you provide a simple example of where get_config_value returns a string for a constant?

[python-bindings] Fix interface consistency issues with `get_config_value`

Make the interface consistent with instance.generator_args.

• instance.get_config_value(name) -> instance.config[name]
• Return an Arg object rather than the raw value

Cache the typegen generated types in the typegen instead of namespace

Also maybe cache the results of running the generator ModuleDef

C API segfaults when calling CORELoadModule on _add4Gen.json from unit tests.

I can load _simple.json fine, so if it's still an issue due to how I'm using the API then there probably needs to be a way of describing what libraries/etc. a json module file needs.

API Problems and Requests

This is a general issue for discussing problems with the coreIR API

Please comment on this github issue with API problems labeled with C++, C, or Python

Does a function cause a segfault? (If so please file a separate issue)
Does a function cause coreIR to falsely error?
Does a function produce unhelpful error messages?
Is the name of the function confusing?
Is there some basic function you want and cannot do?

Embed all of coreir into coreir-c.so

Specifically create a shared library module for coreir-c.so which does not need to include coreir.so

Define set of fundamental stdlib primitives and types

Types:
Clk, Reset, Signed, Unsigned, Fixed Point, Floating Point

Primitives:
Logical: not, and, nand, or, nor, xor, xnor, concat, slice
Arithmetic: add,sub,mult,div, constants, terminators
Stateful : FF, Register, Ram, Rom

Add Caleb's python loadability test to coreir python tests

https://github.com/cdonovick/SMT-PNR/blob/master/src/design/core2graph.py

Add to typechecking: Make sure the select paths never result in an AnyType for connections

Write some formal docs

Possible formats I've encountered in past projects:

• raw markdown files in a docs directory. Simplest, can read via text editor or github's web interface
• github wiki. Easiest collaboration, keeps commit history separate from doc changes.
• mkdocs Generates a website from markdown pages. Fanciest, requires some setup but I've done this before.

I'm open to suggestions for other options. I'd just like us to choose one so we can use a constant format across the codebase (i.e. for the Python bindings, the pass framework, etc...). As soon as we decide on one I can start adding documentation. Would also be a good exercise for me to learn other parts of the code that I don't know yet by writing docs for them.

passes.hpp file extension

All other header files in the include directory use .h while include/coreir-pass/passes.hpp uses a .hpp extension. I propose to switch this file to passes.h for consistency.

Migrate C/Python API to use iterator pattern

Iterator API

• CORE{type}{member}GetFirst
• CORE{type}{member}GetLast
• CORE{type}{member}GetNext

Functions that need to be updated

• module_def.instances
• TODO: List out the rest

@rdaly525 Any feedback on this proposed API?

Support getting the width of a connection

Caleb needs this for PNR.
Syntax proposals: len(connection) or connection.width
Should be simple for a normal connection (just get the width of one of the wireables)

For directed connections (which Caleb is using) the current way to do it is a bit clunky (need to follow the select path to get a wireable which you can query for the type and then width). This is because connection.source returns a select path instead of a wireable. @rdaly525 Could directedconnection.{source,sink} return Wireables instead?

Make JSON writer produce nice looking output

Add connections unit test

Check invariance of adding the same connection multiple times

Update Python c bindings to correctly find shared library files

Use branch 'libreorg' in order to:

• Change python bindings to expect the shared libraries to come from bin/
• Have an easy way of loading coreir-libs into python.
• Update README to describe what is required to add a new library

The load library call will always have a C++ function signature:
Namespace* CoreIRLoadLibrary_(Context* c);

For example for stdlib:
Namespace* CoreIRLoadLibrary_stdlib(Context* c);

Memory leak with construction of 'connections'

Valgrind shows an uninitialized value error when adding a new connection (ModuleDef.wire(...)).

Implement isEqual for modules

Should this be a pass? or embedded function.

C API updates (class inheritance)

I think it would be good to make consistent and simplify the C API. It is annoying to port over class inheritance structures. And I think I have been a bit ad hoc about it.

In general if there is an inheritance hierarchy, only define the Base class type for the C API. And have all the functions in all of the class hierarchy take in that one Base class type and internally cast it.
For example, change COREInstance to COREWireable.
In addition, have enumeration of all the 'kind's. COREWireableGetKind() This will return an enumeration of either a select, an instance, or an interface. This allows one to determine the type.

Concrete tasks

• Remove CORESelect and COREInstance, and replace with COREWireable.
• Add COREWireableGetKind() and an enumeration for the wireable kinds
• Remove CORE*Type and replace with COREType
• Add CORETypeGetKind() and an enumeration for the type kinds
• Remove CORE*Arg and replace with COREArg
• Add COREArgGetKind(). The enumeration should just be COREParam

All the functions should use cast<> or dyn_cast<> to cast to the correct c++ type. Note: cast<> will assert on failure. dyn_cast returns null on failure.

Change all BitOut to just Bit

Also add functions:

Type* In(Type*) to convert all Bits to BitIns
Type* Out(Type*) to convert all BitIns to Bits

Make Top level README up to date

Rename COREModuleAddDef to COREModuleSetDef

Reflects change to Module API, python bindings should be updated as well

• coreir-c.{h,c}
• __init__.py

Add support for Connections to Python API

Change all the get functions which return strings to return a reference to the string

Generator Params vs. TypeGen Params

Currently, the Generator constructor requires that the Params provided to the Generator match the Params provided to the TypeGen. There are cases where you would like the Generator to take additional parameters over the TypeGen. For example, consider a line buffer.

The line buffer needs to know at least 5 things: the width and height of the taps you want, the width of the image, the height of the image, and the bits per pixel. On the other hand, the type of the line buffer is very easily represented, it is just a single pixel in, and width*height pixels out. The TypeGen does not require any knowledge about the width and height of the image.

Instead, I propose that the Parameters provided to the Generator be a superset of the Parameters provided to the TypeGen.

Bug in get_config_args:

1 import coreir
2 import sys
3
4 def load_core(file, *libs):
5 context = coreir.Context()
6 for lib in libs:
7 context.load_library(lib)
8
9 top_module = context.load_from_file(file)
10 top_def = top_module.get_definition()
11 for inst in top_def.get_instances():
12 print(inst.module_name())
13 if 'PE' == inst.module_name()[0:2]:
14 print(inst.get_config_value('op'))
15
16
17 load_core("./CGRAMapper/mapped2.json", "stdlib", "cgralib")

where mapped2.json is from CGRAMapper:cgralib
./build/map caleb_example2.json mapped2.json

Define Rigel operators/Types

Create a library of rigel operators. Only declarations

Types:
Ready-valid handshake...

Map, Reduce, Zip...

Try SWIG for generating API wrapper

http://www.swig.org/

Could allow us to automatically generate Python and Lua bindings

Ability to get type and bit width of connection

Need to add this in C++, C, and python API

Option 1:
implement Type.getRawWidth()

Option 2:
Port over the isa, and cast functions, and ArrayType.getLen()

Refactor Python bindings

The __init__ file has become unwieldly

• split classes into separate modules
• convert object APIs to be idiomatic python (i.e. using @Property methods)

Implement a generic class for iterables

That is, move next/prev logic used for the moduleDef.instances iterator to the Instances themselves by inheriting from a generic class that defines the next/prev API.

Create an Instance Pass framework

This should be a framework for iterating over all instances in the design and performing some set of actions on the instance.

An initial step would basically implement 1 to 1 replacement.
A second step would be able to swap out multiple things.

[python-api] support getGenargs

• instance.generator_args
• type.generator_args

Add function to inline instances

Change SelectPath to be a deque instead of a vector.

I find myself inserting stuff at the beginning more often than inserting at the end.

Update codebase to use llvm-style RTTI

http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html#classof-contract

This is partially implemented right now by using the 'kind' discriminator. Should create a casting.hpp file similar to LLVM's in order to use isa(), cast(), and dyn_cast()

Add Generators into Json

Directed View should be invalidated when the module changes (like flatten)

Add a pattern matching search and replace framework

An awesome feature to have which would make mapping, and many peep-hole compiler optimizations.

The interface would be something along the lines of:

patternMatch(Module* pattern, Module* replacement, string startinst)

This would go through all instances and see if it matches the pattern defined in pattern.def starting with the pattern.startinst.

It will then go and replace all of the matches

Implications:
This would make it very easy to write fusion passes