On Sun, Jun 23, 2013 at 3:26 AM, Paul Fertser <[email protected]> wrote: > 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).
It appears I will be going my own way. Look I will do this and the rest of you can argue including it or not. >> 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. I was going to write a library in C and add a little bit of code to OpenOCD to connect to it. I would rather do an outside library for BSDL because I have seen a lot of JTAG projects come and go. I think OpenOCD finally has hit on a good architecture for the long term. If I can do that and get that work included into OpenOCD then I would move on to connecting to a CAD tool. Until that point it is all just talk. I am tired of this discussion. I would rather be coding. OT: A coworker for good reason is trying right now to build something to support programming the DSP56L002 via OnCE for the next 50 years. >> 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. BSDL is a subset of VHDL. OpenOCD is built in C and TCL. UrJTAG also uses C among a few others used primarily by the BSDL parser. gEDA uses C and guile to run scheme not to mention SPICE, Verilog/VHDL. If I ever manage to get my work included in ether project it would help if it isn't in yet another language. People have been trying to push a third language on the mainline gEDA developers for years and it has never made it in. The momentum of the programming world favors my choice here. At some point just to be productive you have to choose to limit the number of languages you use to get something done. > 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. I am not taking the bate. This thread will just devolve if we go into that fight. > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:[email protected] -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/ ------------------------------------------------------------------------------ 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
