make python dependency optional (?) about ecto HOT 10 CLOSED

See also the russian troll's input on closed/duplicate #16

from ecto.

My comment was somewhat misunderstood. I think the issue "make python dependency optional" is obvious to desire, my point goes somewhat deeper- python is just one incarnation of things that get in the way of porting a useful c & c++ core to hardware.

from ecto.

Okay, point well taken. But you don't actually propose to e.g. generate VHDL for a graph containing a module that takes something of type boost::shared_ptr<std::map<std::string, variant<int, float, double> > >?

from ecto.

um, well stuff like shared pointers and even more so boost::variant are a huge pain to try to map to hardware. It makes it really hard to statically discern what memory and clock cycles you actually need. Generating VHDL might be provably impossible, because the main (huge) difference there is explicit timing, you can't have a multi-type object where it might take X or Y operations to free it.

I think consciously saying "Ecto is NOT meant for prototyping for mapping to hardware" is acceptable too btw, I just think its a missed opportunity because slightly less trickiness with the types and scriptable wrappers would allow easy hardware mapping.

from ecto.

Mapping to hardware is way out of scope for ecto.

Anything VHDL or what not is either very device specific or so different from C++ constructs that it would be too constraining for modules not intended for an FPGA.

Also, we're focused currently on single process, synchronous graphs, with the same memory address space. What does it mean to translate this to an FPGA?

from ecto.

Compilers exist that will automatically parallelize "raw ansi C and simple
C++" for statically timed code.

It would be cool if a module that wanted to do this could be tested with
Ecto. As opposed to there being so much overhead that one have to start from
scratch rather than remove the wrapping once prototyping was finished.

I am thinking of something like nlopt; part of the reason why I hesitate to
touch the details is that imposing structure from ecto or nlmagick reduces
low-level reusability.

If I can run nlmagick or routines from "numerical recipes in C++" from
multiple ecto modules connected together, my concern is addressed ;-)
On Jun 7, 2011 9:34 PM, "ethanrublee" <
[email protected]>
wrote:

Mapping to hardware is way out of scope for ecto.

Anything VHDL or what not is either very device specific or so different
from C++ constructs that it would be too constraining for modules not
intended for an FPGA.

Also, we're focused currently on single process, synchronous graphs, with
the same memory address space. What does it mean to translate this to an
FPGA?

Reply to this email directly or view it on GitHub:
#10 (comment)

from ecto.

But, when have you ever gone from a PC app, to an FPGA and not rewritten at least most of the code?

from ecto.

Boggles my mind. Costs a shit ton, but its quite magical ...

http://en.wikipedia.org/wiki/Catapult_C

http://www.lisha.ufsc.br/teaching/esl/exercise/catapult_docs/catapult_cpp_hw_gd_uv.pdf

http://users.ece.utexas.edu/~gerstl/ee382v-ics_f09/lectures/lecture_14.pdf

On Tue, Jun 7, 2011 at 10:27 PM, ethanrublee
[email protected]
wrote:

But, when have you ever gone from a PC app, to an FPGA and not rewritten at least most of the code?

Reply to this email directly or view it on GitHub:
#10 (comment)

from ecto.

The target audience for ecto is vision/perception researchers. Elegance of interface and scriptability very clearly take priority over the theoretical future ability to cross-compile to VHDL or Verilog. Even assuming that we could in fact purchase or write something like "Catapult C", there is absolutely NO chance that we will follow the "recommendations on how to write C++ code" in the "Catapult C Synthesis C++ to Hardware Concepts" document. This is completely out of the question.

from ecto.

Moving beyond VHDL generation from ecto...

It will be valuable to serialize some description of a graph made in python and reconstruct the graph in a c++ program.

The two use cases are, just run a predetermined graph, or use the graph in some custom main program.

from ecto.