Hi Adam, > Even better, I was able to > talk to the BSCAN_VIRTEX5 block on the chip using urjtag!
If not already seen, you might want to have a look at the fjmem bus driver that comes with a generic Xilinx BSCAN / Altera JTAG interface design. > The bad news -- aside from the fact that xpc_ext is pretty slow -- is > the fact that the SVF parser has serious problems coping with large > SVF files. The lexer is designed to lex the bitstring of an "SDR" > command as one gigantic token (in my case, a 31MB token), but > unfortunately flex's performance is O(n+m^2) where m is the length of > the longest token in the file -- it's not meant for large tokens. > So, while the programming was successful, it took over an hour *just to > read in the SVF file*. That's really bad news. The larges device I came accross so far was a XC3S5000 which got configured in reasonnable time (SVF file size was ~6.6 MByte). > Does anybody see an easy fix? The only solution I can see is to > change the grammar so that each character of a bitstring is a lexene > and the parser gangs them together (bison can handle long sequences of > lexenes with linear performance if you write the grammar properly). It might be an approach worth trying. However, I've got no idea how to implement and optimize this right away. Would need some investigation and experimenting. Even with some support from your side since you seem to deploy a different league of FPGAs than I can get my hands on :-) So do you know of any examples or further information on how to approach this performance issue with flex? > But this is a pretty hard thing to do unless one is very familiar with > the particular svf_bison.y that urjtag uses. This is where I'm familiar with. As soon as the direction is clear, there shouldn't be any obstacles on this part. > Thanks again for this great project! You're welcome! > PS, are there any USB cables that can sustain 12mbit/sec using urjtag? I doubt for USB full speed cables where 12mbit/sec is the bandwidth on the physical wire. > If not, which cable is the fastest when using the latest SVN > version of urjtag? I guess that we pushed the FT2232 based cables and the Altera USB Blaster (+clones) to the limit in terms of what can be achieved with UrJTAG. My feeling is that the FT2232 performs better for random in/out shifts (e.g. RAM or flash programming) while the USB Blaster might yield better results for monotonic shifts due to its 12MHz maximum bit rate (max 6MHz for FT2232). > PPS, has anybody else noticed that the number of .bdsl files in the > "bdsl path" greatly degrades the amount of time required for > "detect"? This is sort of a bummer, because it means we can't > just dump the entire collection of bdsl's from Xilinx's kit into > urjtag's directory -- we have to carefully select just the > minimum number to get the job done. Two comments on this: detect will scan through all the files until it finds one with matching IDCODE. It'll do this for each device in the chain. Since this involves parsing the VHDL/BSDL files, it tends to become slow with a large number of files. The alternative is to skip detect, build the chain with addpart and load the BSDL files via include afterwards. Next, it's not a good idea to feed virtually every BSDL file Xilinx provides into detect. You have to narrow down the collection to the correct packages at least. Since detect has no chance to determine the package variant (Xilinx and others use the same IDCODE for a device in all its different packages - it's probably the same silicon just bonded differently). detect will simply take the first file with matching IDCODE. But it's quite likely that this is the one for the wrong package. Best regards Arnim ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
