Honored Contributor
Honored ContributorThe hybrid approach Tricky suggests is typically what I go with. Normally I start with a software only approach, identify bottlenecks, then move those bottlenecks into hardware. Implementing an entire application in hardware is normally overkill as certain types of algorithms are no faster in dedicated logic than performed by a CPU. Here is an example:
do { a = b * 2.3; c = b * 6.2; while (c < 100000); In that case a CPU with a floating point unit could keep up with dedicated hardware since there isn't much opportunity for parallelization (in it's current form). In cases like that it makes more sense to use reusable hardware (a CPU) than wasting LEs/ALUTs that will be underutilized. .... And since you want something modular and maintainable I recommend microcore based design. If you haven't heard of this before it is basically a design approach where you design smaller cores and stitch them together for a specific purpose. It has many positive attributes such as: - use standard interfaces and let the tools handle adapting the differences (SOPC Builder/Qsys) - smaller cores are easier to verify - microcores can be replaced while leaving everything else intack - microcores will be easier for someone else to understand than a gigantic core - Qsys/SOPCB let you create components made up of smaller components I can go on and on about this but I think you can see why I like microcore design :)
