On Sun, Jun 23, 2013 at 02:47:33AM -0400, Evan Foss wrote: > It would be nice to just drop a BSDL file into OpenOCD. Boundary scan > was built into the JTAG standard in a way that makes this mostly > possible.
OpenOCD is called OCD (On Chip Debug) for a reason. It was created specifically to make use of non-standard JTAG extensions that vendors added for debugging (and flashing). > I use gEDA and as a long term thing I was thinking it would be nice to > have some way to make my hardware development toolchain actually > interact with the final hardware. Board level testing based on an > exported and post processed netlist for example. That would be an interesting setup indeed. But I can't fully visualise the workflow from your description. Still, assuming you use some workstation (and not some constrained embedded device) for your EDA work, I can't see any objections to using a separate tool for that, without hooking into OpenOCD internals too much. What would you miss for such a tool? If a facility would be added to execute a single SVF line from telnet interactively and get back the BSR value (when appropriate), would that suffice? I do not really know how people use or want to use Boundary scan so it's still absolutely unclear for me what changes to OpenOCD might be needed. > Not to start the my language is better than yours but I don't do > python. Most of my tools are built in C and I am too lazy to learn > another language just to parse JTAG. A language is just a tool, and choosing appropriate tools affect outcome immensely. C++11 can usually provide the same or better performance as C with the resulting source code being much more maintainable and error-prone, but learning enough of C++11 is hard indeed. And when performance is not critical, some other modern languages are worth looking into, and almost any will do nicely, be it Perl (when used sensibly) or Python (very smooth learning curve, plenty of examples and experts online) or Ruby, or Haskell, Ocaml, Scheme, CL etc. I am sure that choosing a modern proper tool will both lead to your target goals faster and produce the source code that would have less bugs, would be easier to understand and extend. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
