On Sun, Jun 23, 2013 at 6:53 AM, Paul Fertser <[email protected]> wrote: > On Sun, Jun 23, 2013 at 11:26:30AM +0400, Paul Fertser wrote: >> > 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've studied the SVF format and UrJTAG documentation a bit and came to > the conclusion that OpenOCD implementation is much more flexible and > useful as it supports TIR, TDR, HIR, HDR commands properly, that > apparently enables using Xilinx and other random SVF files without any > additional tricks/conversions and also provides a basis for a real > multi-device EXTEST functionality. > > Also OpenOCD boasts a simple RPC interface to the TCL intepreter so > best course of actions as I see it is to write an external tool that > would integrate with EDA software (KiCAD or gEDA) and would generate > appropriate SVF commands.
Both of the following paths (cad/automated test) are a long way out. Yes it is nice to think about them for architectural reasons but for now the point is just to add the ability to pull info out of a BSDL file and use it in OpenOCD. I have looked at both sides of this. Your conclusions about OpenOCD are right. However, SVF is not really what the CAD tools should be using. The future is using the CAD tools to be interactive. I can write a plugin to gEDA for this. In the meantime simply automating the process of testing the connections between jtag aware devices on a netlist is simple and useful. If you want to generate automated testing that code still ends up being done with a lot of human involvement. There are just so many things that you can make hardware do while running an automated test that can break it. Having a human in the loop is a requirement. That is such a larger thing it does require a tool on it's own. Bottom line I have to code a BSDL library and get the interface to it + some added commands for it to be useful included in OpenOCD. > To allow synchronisation with external hardware tools (needle bed, > anyone?) or manual actions I also propose to allow executing arbitrary > SVF commands directly via the TCL interface, to provide the external > software with fine-grained control over what happens when. > > That's of course all talking about serious mass-production > industry-level testing. But considering many hobby or debugging tasks > many of us face regularly, isn't my semi-manual (easily automated > thanks to the embedded TCL intepreter) BS procedure adequate enough? Fine grained control means things like including proper descriptions of the cells and etc. The best way to get that info is from the BSDL file. Yes TCL is a good interface to such a tool but it should not be the language you implement the whole thing in. Most of those industrial tools use TCP/IP. Perhaps another telnet interface or dbus is called for here. gEDA/PCB is already working on using dbus in a lot of places. It is not finalized yet but it will get there. Look I thought I could join a group doing this but apparently there isn't one. I am just going to go it alone and come back when I am done. I hate these damned debates on unending email threads. > -- > 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
