Hardware design discusion
From Openjtag
this page was recovered from the old wiki discussing the options and problems faced
at the end of this is original text i have added some of my comments on this and an update
Design for the dongle for Stage 1 of the OpenJTAG project has beendecided upon. It will be based on the FTDI 2232C chip, a USB to serialconverter which has the capability of doing USB to JTAG conversion. With suitable drivers, this dongle will be able to do JTAG directly from any Linux/OSX/Unix-like box with a USB host port available. Current plans call for a CPLD to be included for programmed controlof the JTAG interface voltages. Pads for an i2c serial eeprom will also be provided for possible future use as configuration storage.Also included in the design will be connector exposing both the standardJTAG signals as well as an 8 bit parallel interface suitable for plugginginto external devices, in particular the Digilent S3 board.Initially, the driving application will provide a command line interfacesuch that it can be compiled and used on Linux,OSX and other Unix-like OSboxes.Interested people should contact project management about sources ofsupply for the pcb and chips used for the dongle on IRC #openjtag
As I see it, this can be a very popular and useful project for not just hardcore
developers such as the core openjtag group, but also for many more casual users
who manage to brick-build when testing embedded system software on a wide range
of Linux based gadgets and gizmos. To this end, we are hopping to offer something
that will both be accessible to the typical advanced user and still be reasonably
inexpensive.
To this end, we are building an intelligent dongle. A dongle because, in order to run jtag as fast and reliably as possible, we need to dedicate a processor to the task. Right now, timing constraints are somewhat of an imponderable... rather than chasing our tail debugging jtag problems that may be caused by jitter in the output stream, we let our processor do nothing but tend to the bit banging of the TDI data, TCLK generation and dealing with TDO input as necessary. The host development system is just not suitable for these tasks due to latency and speed
concerns. We need real time response and you won't get that from a full Linux system. Until some jtag expert steps in and says this concern is misplaced, I think this is the only sensible way to proceed.
While using things such as the very sweet CY7C68013 USB chip has been proposed, this idea has a show-stopping impediment in my mind...the IP is locked. While we could use the Digilent USB cable, their Adept software is not open and is tied to Windows/Visual C. DMCA makes it illegal for most of us to even look at how they actually implement their protocols and software interface in a way that would be useful to the project. While it would be nice to build around the 68013, I can't see that the resources are available. Cypress' EZ-USB Dev kit doesn't see the Digilent chip so I think it is safe to say steps have been taken to hide the things we would need to do the job quickly and I don't see anyone willing to finance a production run is we did. If we can't get the info to base our work around the Digilent chip, it is a closed issue. Counter arguements welcome on #openjtag.
One possibility is to do something with the FDTI FT2232C chip. A USB dongle has the advantage of perhaps being cheaper and less of a problem for a wider range of people not experienced with embedded system software building as it could be done with mostly
host based software. It certainly seems a viable alternative worthy of discussion before final design decisions are made.
We could look at hardware accelerator things like this until we are blue in the face, but eventually you have to face the fact that hardware is expensive, both in development software cost and time/learning curve. Microprocessors are still the way to go on low volume projects. Putting everything on a 1cm x 1 cm chip would be nifty but can't be one of our design goals. Using VHDL is slightly out of our reach because we don't really have enough design people/resources and unless we produce a low cost, manufactured board, it really limits the number of people that it would be useful too. It basically comes down to is it easier/quicker to do this in VHDL or C. Given the groups joint abilities and the size of the task, I think the answer is obvious. **IF** we can find a suitable USB interface with all that we need to handle the jtag signal generation at high speed, fine...but if not, we need to get down to brass tacks with a embedded Linux board
If you accept my arguments so far, then it comes down to picking a candidate board to become the dongle or get busy on the USB dongle. As I see it, there are really only 2 candidates at the moment for use as the embedded Linux board. The first is the NSLU2 aka Slug. It has the advantage that it is cheap, fast enough and most people involved already have one. One the down side is that GPIOs, while avaialble, are not exposed, USB is host only, and I don't need to mention that ethernet involves the CSR. All things considered, it has to be the front runner at this point though based on the fact that it has zero cost to most of us.
The second candidate is the gumstix. It is not as inexpensive as the Slug but does have advantages. First, it has a USB client built in. It comes in both 200 and 400 mhz varieties so speed isn't a real issue, has 4 mb flash and 64 mb of dram. It uses an XScale pxa255 so the hardware is pretty familiar. U-Boot is used which some might consider an advantage and there is a 2.6.9 kernel and a Buildroot system in CVS. There are breakout boards available so GPIOs are exposed including one adapter board that allows the Gumstix to be directly plugged into a USB host to obtain its power and provides the possibility to connect to the usb client port directly. Serial is available on some boards and there is an somewhat eclectic assortment of accessory boards which would make interfacing easier than on the Slug. On the downside, the gumstix tends to be a bit flimsy due to its small size and uses some slightly oddball connectors. The 'stix itself is physically the size of a stick of gum but all the daughterboards are larger. AFAIK, two of the group own 'stix and one has had one on his shopping list for ages. They are small, kewl, nifty but not without their warts. If everyone were starting from zero, I think the Gumstix would be a better choice, but that is a big 'if'. From the perspective of other users who don't currently have an NSLU2, or have a bricked one, obtaining a Slug may not be their first choice.
Other choices I have seen proposed are generally too expensive and don't offer any compelling advantages. This group has experience with Arm XScale processors so it seems sensible to leverage what little advantage that provides. We know the tools. Doing OpenSlug on another processor seems a non-starter to me. While the OE thing seems overkill from my limited perspective, group members have put a huge amount of effort into it. It is accepted that it will be the basis of our ongoing efforts. Having said this, there will need to be a certain level of handholding whilst this gal get dragged, kicking and screaming, into the Brave New World of OE ;). If anyone objects, they better speak up soon cuz if there is anything here close to being etched in stone, this is it.
Thus using C/GCC on a Linux based host for development is a given here. The host will have little involvment in the jtag process other than to pass bulk data to the dongle and to watch for status messages coming back. The dongle will essentially own the hardware on the dongle while the jtag software is in use. All interrupts not being used directly by the jtag application/driver will be turned off for the duration. The jtag app will insmod our driver which will then control gpios generating all the necessary signals. Once the jtag process it done, the simpliest thing to do would be to reset the dongle so that its normal, non-jtag functions are restored. Jtag will only borrow the hardware and won't change its capabilities or operation in any way during its normal, everyday use.
These issues need to get settled once and for all so we can start building something. I propose that a concrete hardware spec be developed so that it can be posted here on the wiki by 2/10/2005.
update on the high speed solution
it seems the project has 2 designs on the go a usb only adaptor and a high speed unit appologies as i have been rather bussy working on the high speed solution that i have not had chance to keep uptodate on how the other solution has progressed ,, and this page needs rewriting and bringing up to date
it seems both the ftdi usb adaptor has been looked into
also but there still seems a lot of interest in this also
ok so it does not have the higher end speed but i feel
it would still be usefull to some
from what has been discovered even using a embedded micro like a ep9302 the dio limit on that still only hits a maximum of around 5Mhz
i started work on the aztag originaly to offer a pc/104 fpga based card that would provide the speed the project needed but limitations to the pc/104 bus limited its usefulness for other tasks
i started the geep project to produce a embedded arm based system with a fpga , but although a nice board in itself it looked like it was going to cost well in exccess of the proposed $250 budjet for this project
but all is not lost ,, at the moment we are just about ready to start building the first prototypes for the geep-b this project is seperate from openjtag but is ideal for use here also i decided it was better to develop it seperate as its a more genaral pourpous board so not just limited to jtag but as a genearal purpouse fpga control board with a wide range of uses
the geep-b is a modular fpga based unit , based on a xilinx xc3s400 fpga , it also is equipped with 32MB ram and 512mb flash it has a atmega169 that provides some control and debug interface and 4 i/o channel interfaces
for use in the openjtag project all that is needed is a i/o chan adaptor for the level translator and connector format conversion
it offers usb host connection and should allow it to operate upto 100Mhz jtag clock rates
when i started designed it i realised that it would need a
4 layer pcb , but becasue of the cost in developing the board
it was apparent that just developing it with a single use
in mind would be a waste of time this is because from a home
constructors point of view having to buy 10 pcbs for just one
function is not ideal you may use 10 universal controlers
but not 10 jtag dongles and the minimum order would need to be
10 pcb's at once for 4 layer boards
there are some issues rased over using just a fpga based design in that where rased in the original proposals but i feel confidant that this can be handled
there are a number of good softcores avalable at www.opencores.org that could be used but for pure jtag testing it is better to stream the jtag from or to ram using pure vhdl code needing only a small low power cpu core to handle the communications to the host development machine over usb
the geep-b project site is http://www.gnugeep.org
besisded beeing able to do the jtag , a Logic analiser adaptor and DSO adaptor are also planned so this unit would be a mutch more usefull peace of kit as a logic analiser it would be capable of 16 bit at 100M samples a second ,, and as a DSO would provide 100M samples a second with 12bit resolution or dual channel at 8 bit resolution , the limit being dew to ram access speeds
site navigation
back to Main Page
