search

phanrahan / mantle

mantle library
Other
42 stars 10 forks source link

CounterModM Broken When Compiling To CoreIR #60

Closed David-Durst closed 6 years ago

David-Durst commented 6 years ago

When compiling to CoreIR, CounterModM crashes with the following error:

ERROR: Counter5Mod2: Cannot wire together inst1.O : Bit inst0.RESET : coreir.rstIn

My test is: https://github.com/David-Durst/aetherling/blob/master/tests/test_up.py#L83

Through debugging, I've tracked down that this crash occurs while in the compiledefinition call for the Counter5Mod2 module (the line https://github.com/phanrahan/magma/blob/master/magma/backend/coreir.py#L261).

David-Durst commented 6 years ago

Also, are UInt types legacy? Why does the counter5mod2 have 5 uints rather than 5 bits?

leonardt commented 6 years ago

UInt types are not legacy, see https://github.com/phanrahan/magma/wiki/Types,-Operators,-and-Functions for some info on them

leonardt commented 6 years ago

@rdaly525 Looks like the issue is wiring the output of some arbitrary logic to a reset port of type coreir.rstIn. Is there a way to "cast" types in coreir? (e.g. in this case, we want the output of an and instance of type Bit to be a coreir.rstIn.

leonardt commented 6 years ago

@David-Durst Can't reproduce this with aetherling, I get the following error

aetherling/modules/up.py:5: in <module>
    from magma.coreirModuleWrapper import ModuleFromGeneratorWrapper
E   ModuleNotFoundError: No module named 'magma.coreirModuleWrapper'

are you on a local branch for magma? Can you share that with me somehow? (easiest is to push the branch to the magma repo so I can just check it out)

David-Durst commented 6 years ago

Please use the counterModMTest branch of aetherling. The counterModM test now doesn't require any of my changes to magma/pycoreir/coreir. I have some in all three repos that need to get pull requested in.

leonardt commented 6 years ago

On counterModM, still getting

aetherling/modules/up.py:5: in <module>
    from magma.coreirModuleWrapper import ModuleFromGeneratorWrapper
E   ModuleNotFoundError: No module named 'magma.coreirModuleWrapper'
leonardt commented 6 years ago

The error indicates that it's trying to import something from magma that I don't have

David-Durst commented 6 years ago

Please pull and retry the test now. The includes should be removed now

David-Durst commented 6 years ago

Also, here's the backtrace of the error from lldb. 

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff6d58de3e libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff6d6cc150 libsystem_pthread.dylib`pthread_kill + 333
    frame #2: 0x00007fff6d4ea312 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff6d4b2368 libsystem_c.dylib`__assert_rtn + 320
    frame #4: 0x000000010506e185 libcoreir.dylib`CoreIR::Context::die() + 133
    frame #5: 0x00000001051f933a libcoreir.dylib`CoreIR::ModuleDef::connect(CoreIR::Wireable*, CoreIR::Wireable*) + 4186
    frame #6: 0x000000010466d147 libcoreir-c.dylib`COREModuleDefConnect + 71
    frame #7: 0x00000001019f6884 libffi.6.dylib`ffi_call_unix64 + 76
    frame #8: 0x00000001019f5e8b libffi.6.dylib`ffi_call + 939
    frame #9: 0x000000010267bcf8 _ctypes.cpython-36m-darwin.so`_ctypes_callproc + 552
    frame #10: 0x0000000102676222 _ctypes.cpython-36m-darwin.so`PyCFuncPtr_call + 242
    frame #11: 0x0000000100009df1 python`_PyObject_FastCallDict + 177
    frame #12: 0x0000000100163348 python`call_function + 392
    frame #13: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #14: 0x00000001001635fc python`fast_function + 188
    frame #15: 0x00000001001632ac python`call_function + 236
    frame #16: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #17: 0x00000001001635fc python`fast_function + 188
    frame #18: 0x00000001001632ac python`call_function + 236
    frame #19: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #20: 0x0000000100154589 python`_PyEval_EvalCodeWithName + 425
    frame #21: 0x00000001001636aa python`fast_function + 362
    frame #22: 0x00000001001632ac python`call_function + 236
    frame #23: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #24: 0x00000001001635fc python`fast_function + 188
    frame #25: 0x00000001001632ac python`call_function + 236
    frame #26: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #27: 0x00000001001635fc python`fast_function + 188
    frame #28: 0x00000001001632ac python`call_function + 236
    frame #29: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #30: 0x0000000100154589 python`_PyEval_EvalCodeWithName + 425
    frame #31: 0x00000001001636aa python`fast_function + 362
    frame #32: 0x00000001001632ac python`call_function + 236
    frame #33: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #34: 0x0000000100154589 python`_PyEval_EvalCodeWithName + 425
    frame #35: 0x0000000100163e15 python`_PyFunction_FastCallDict + 373
    frame #36: 0x0000000100009e80 python`_PyObject_FastCallDict + 320
    frame #37: 0x0000000100031468 python`method_call + 136
    frame #38: 0x00000001000114ee python`PyObject_Call + 62
    frame #39: 0x00000001000b3065 python`slot_tp_init + 117
    frame #40: 0x00000001000b75b1 python`type_call + 241
    frame #41: 0x0000000100009df1 python`_PyObject_FastCallDict + 177
    frame #42: 0x0000000100163348 python`call_function + 392
    frame #43: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #44: 0x00000001001635fc python`fast_function + 188
    frame #45: 0x00000001001632ac python`call_function + 236
    frame #46: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #47: 0x0000000100154589 python`_PyEval_EvalCodeWithName + 425
    frame #48: 0x00000001001ac63c python`PyRun_FileExFlags + 252
    frame #49: 0x00000001001abdee python`PyRun_SimpleFileExFlags + 366
    frame #50: 0x00000001001d1dd6 python`Py_Main + 3718
    frame #51: 0x0000000100001e7d python`main + 509
    frame #52: 0x00007fff6d43e115 libdyld.dylib`start + 1
    frame #53: 0x00007fff6d43e115 libdyld.dylib`start + 1
rdaly525 commented 6 years ago

Is this port supposed to be used as an asynchronous reset or a synchronous reset? If it is the latter, it is a bug. if it is the former, I have something called coreir.wrap which will wrap a bit into a named type.

leonardt commented 6 years ago

@rdaly525 if I understand correctly, a synchronous reset should use a standard bit type, not the rst named type.

rdaly525 commented 6 years ago

Yes, that is correct. It is on my TODO list to rename the rst type to "async_reset" or something like that

leonardt commented 6 years ago

Fixed by: https://github.com/phanrahan/mantle/commit/eab6f26ec41fa0f31ec005c65bbe38b899c9cadf and 1b317d85ffa3c68dba1d85dc149bee4103456e39 https://github.com/phanrahan/magma/commit/1b317d85ffa3c68dba1d85dc149bee4103456e39

Will open a separate issue to resolve the RESET type semantics and matching them up with coreir