I am somewhat confused about debugging arm processors through the jtag port using gdb. There does not seem to be a complete GPL based option. I see alot of commercial software for which I do not have the thousands to spend on and I see bits and pieces of software that looks like it could be integrated to provide jtag debug access, but nothing fully integrated.
I have experiemented with implementing the openrisc processor with uclinux in a gate array. When I have worked with the openrisc emulator I am used to doing something in gdb like jtag://localhost to do a debugging session. Yet there does not quite seem to be something like that with arm.
If your are searching the lowest cost on the market, try the Chameleon POD ( by Amontec.com ). This is an JTAG emulator compatible with the Macraigor Raven. It can operate as a RAVEN at 8MHz TCK frequency. Raven or Wiggler can works over GNU GDB or all other popular Debugger tools. A nice solution for ARM.
I've got a JTAG interface from my PC, and I even have documentation on how it works. What I wish I had is information on how to actually use it to program EPROMs and CPLDs and things. Is this kind of stuff generally kept close to the manufacturer's chests, or can they be prompted to divulge?
I see there is some open source work afoot -
formatting link
- but they don't cover my Lattice Semi MACH cPLDs!
What would be nice is a huge online repository containing the core JTAG specs, programming examples for common JTAG adapters for PCs, and a load of specifications for using them for things other than boundary scan testing. Any volunteers? :-)
I have seen the Chameleon, Raven and Wiggler. The problem with these is that the binary software is freely available, but not the source.
I have a usb/fpga card from Mesa Electronics with some basic jtag software included. One requirement of my project is that all software be opensource. If necessary I will write it.
I just did a small test project with two Xilinx 32 macrocell cplds. In my case I generated an SVF and played that through the jtag software that came with my board. You may be able to do something similar your Mach CPLD.
For the flash in my project, I will use the jtag from the arm processor I am using to bit bang the flash. I do not consider that to be too major a project.
Generating SVF is an option in the Xilinx Impact Utility. You can also chain together multiple devices into one chain and generate a single SVF to program them both.
If you build your own boards, the 32 macrocell cplds are only a few dollars a piece from Nu-Horizons. Nice for when you are just getting started and do not want to risk a more expensive chip.
So a dependency upon the Xilinx software :-( Which I bet they don't provide a version of that will run on a Z80 to dynamically reconfigure an IO glue FPGA, eh? :-)
Mmmm - I have a Lattice Semi evaluation / programming board that does MACH devices. Very handy. Lots of I/O pins and space for some quite complex designs!
If you are talking about using different bit streams, then you don't need anything special on the Z80 other than the code to bit bang the configuration data into the part. If you are talking about *changing* the bit stream in the Z80, then you are working on a very long and tedious project.
I'd like to be able to generate my own bit stream. I'm not worried about the requirements of compiling a logical specification to a description of how the PLD should wire itself up, based upon the documentation of the PLD's routing capabilities; I can do that, it's just that I can't find documentation for how to generate the actual bit stream that will make the PLD wire itself up as I wish.
I've experimented with compiling hardware descriptions for my own design of *simulated* PLD :-)
PLDs come in two flavors, simple and complex. There *are* specs for the simple PLDs because they consist of only the AND fuse array (AFAIK). All 16L8's use the same fuse map, for example.
The complex CPLDs are all different. But if you are smart enough to write your own routing software, you should be clever enough to reverse engineer the parts from various downloads. This may be tedious, but it will work. The structures in a CPLD are very regular so that you only need to figure out a part of the device and you then have a much larger hunk.
FPGAs are a whole new level of complexity. But again a lot of the device is very regular. But there is a lot more to the irregular part.
You don't have to be very smart to write software to decide how to program a PLD unless you're doing what the development tools do and accepting arbitrary logic equations. Then you need to allocate logic to PALs (or across multiple PALs) within the device based on what macrocells need to be connected to what and the capacities of the PALs, but then in the PAL generation phase you may find enough common terms between equations in a given PAL that it has space left over so other bits of logic could be implemented there, saving interconnection matrix space... All textbook optimisation techniques, but tricky to develop due to a lot of details that need attention.
My application would more be to hand-produce a number of 'macrocell' designs, and then at run time decide which 'macrocell' to put into each of a number of 'slots', and how to wire them to each other. Which is relatively trivial - just compose the bit streams for each macrocell to create the fuse maps for the PAL blocks, then work out an interconnect fuse map to tie them together.
The ones I have lying around consist of four PALs with special I/O macrocells (that can be a range of flip flops, mainly) connected with an interconnect matrix to each other and the outputs of the chip. I reckon the four PAL blocks should be relatively easy to find in the fusemaps, particularly since I could probably isolate them by compiling designs with varying options for the macrocells to see where the macrocells are defined... but it would be much nicer to just get the programming documentation for the part :-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.