**** BEGIN LOGGING AT Sat Oct 22 02:59:56 2005
Oct 22 04:18:43 <lennert> vmaster: when i come home from running i'd like to have a chat about your jtag proposal
Oct 22 04:18:51 <lennert> vmaster: is today a good day/time?
Oct 22 04:19:02 <vmaster> heh, as good as any other day/time
Oct 22 04:19:15 <lennert> okay
Oct 22 04:19:33 <vmaster> just highlight me a bit when you're back :)
Oct 22 04:20:41 <lennert> okay
Oct 22 04:20:48 <lennert> i have http://mmd.ath.cx/epp_jtag/
Oct 22 04:20:55 <lennert> and there's some other link you sent but i keep forgetting.. ?
Oct 22 04:22:37 <vmaster> openocd.berlios.de
Oct 22 04:22:49 <lennert> thanks
Oct 22 04:22:54 <vmaster> the eppjtag is already a bit outdated, i.e. i know that it has a serious flaw
Oct 22 04:23:02 <lennert> the clock divider is fucked
Oct 22 04:23:31 <vmaster> mhh, maybe, but the parallel port interfacing is even worse ;)
Oct 22 04:24:02 <vmaster> if tck goes below 1mhz or maybe 500khz, epp timesouts are going to occur
Oct 22 04:24:04 <lennert> okay :)
Oct 22 04:24:09 <lennert> hmm
Oct 22 04:24:14 <lennert> didn't look at it very carefully
Oct 22 04:24:20 <vmaster> laurent gauch from amontec started working on a new version
Oct 22 04:24:27 <vmaster> which he's going to release with complete vhdl code
Oct 22 04:24:42 <vmaster> but i haven't heared from him the last two weeks
Oct 22 04:24:48 <lennert> okay
Oct 22 04:24:55 <lennert> is the protocol documented somewhere?
Oct 22 04:25:48 <vmaster> epp?
Oct 22 04:25:56 <lennert> no, the epp jtag thing
Oct 22 04:26:17 <vmaster> uhm, on a piece of paper on my desk ;) - it's rather simple
Oct 22 04:26:57 <vmaster> ah, i guess i wrote about it in an email, i'll see if i can find it
Oct 22 04:27:21 <dyoung-away> this is all so wonderful
Oct 22 04:27:57 <vmaster> There are three access methods:
Oct 22 04:27:57 <vmaster> - Scan (EPP data write)
Oct 22 04:27:57 <vmaster> - Write cfg (EPP address write)
Oct 22 04:27:57 <vmaster> - Read Scan (EPP data read)
Oct 22 04:27:57 <vmaster> The configuration latch holds the number of bits to be scanned (cfg(2:0)), 
Oct 22 04:27:59 <vmaster> whether the scan should go to TMS or TDI (cfg(3)), the desired clock divider 
Oct 22 04:28:00 <lennert> vmaster: great, thanks
Oct 22 04:28:01 <vmaster> (cfg(5:4)), srst (cfg(6)) and trst (cfg(7)).
Oct 22 04:28:02 <lennert> dyoung-away: what?
Oct 22 04:29:40 <lennert> okay, that's indeed fairly simple
Oct 22 04:29:42 <dyoung-away> VHDL and stuff
Oct 22 04:30:00 <dyoung-away> I can almost wrap my tiny brain around it.
Oct 22 04:30:10 <dyoung-away> The light bulb didnt quite go on yet.
Oct 22 04:30:15 <lennert> vmaster: if the scan goes to TMS, TDI is a don't care, and if it goes to TDI, TMS is a zero?
Oct 22 04:30:32 <lennert> dyoung-away: maybe it'll help to read the xst.pdf guide
Oct 22 04:30:45 <lennert> dyoung-away: there are only a dozen patterns that you can make in vhdl that the synthesizer will recognise
Oct 22 04:30:45 <vmaster> if a scan goes to TMS, TDI is Data(7)
Oct 22 04:31:03 <vmaster> if a scan goes to TDI, TMS is zero
Oct 22 04:31:17 <vmaster> because you want to stay in Shift-D/IR
Oct 22 04:31:29 <lennert> ok, so when you want to scan the last bit of the D/IR, you have to issue a scan to TMS
Oct 22 04:31:43 <vmaster> yep
Oct 22 04:31:44 <lennert> (because when you leave shift-dr/ir, the bit in tdi is still shifted in)
Oct 22 04:31:46 <lennert> okay
Oct 22 04:31:58 <vmaster> that's the way it's handled on ft2232c for example
Oct 22 04:32:18 <lennert> yeah, that doesn't sound hard to implement at all
Oct 22 04:32:51 <lennert> do the openwince jtag tools support this kind of interface?
Oct 22 04:32:54 <vmaster> no
Oct 22 04:33:00 <lennert> just bit-banging?
Oct 22 04:33:24 <vmaster> yes
Oct 22 04:34:01 <vmaster> while it wouldn't be much of an effort to port them to that kind of interface, it would require a lot of work to port them to a high-latency interface like usb
Oct 22 04:34:18 <lennert> parallel port is also fairly high latency
Oct 22 04:34:26 <lennert> and the latency is going up with newer chipsets
Oct 22 04:34:46 <vmaster> mhh, yeah, but you can do epp accesses in microseconds
Oct 22 04:34:53 <vmaster> usb accesses take miliseconds
Oct 22 04:35:16 <lennert> shifing in a million bits takes 10 seconds on my work pc
Oct 22 04:35:29 <lennert> so that's.. yeah, about 200 000 parallel port writes per second
Oct 22 04:35:51 <lennert> about 12000 processor clock cycles each
Oct 22 04:36:38 <vmaster> with the ft2232c, writing the data out takes <1ms, but waiting for the result takes >10ms
Oct 22 04:37:31 <lennert> is that a chip quirk or something unfixable in the usb protocol?
Oct 22 04:37:44 <lennert> of course, we can always make a jtag pci board ;)
Oct 22 04:39:19 <vmaster> usb 1.1 transmits data in frames of 1ms length
Oct 22 04:39:21 <lennert> my home box does it much faster, about 4 seconds for the code download, but that's an older chipset
Oct 22 04:39:41 <lennert> right, that sucks then
Oct 22 04:40:29 <vmaster> usb 2.0 uses 125us frames, but there's no solution as easy as the ft2232c available
Oct 22 04:41:11 <vmaster> the latency isn't that much an issue when you design your application for high-latency operation
Oct 22 04:42:05 <lennert> the only case where we really care about both what we shift in and what we shift out is SAMPLE/EXTEST
Oct 22 04:42:25 <lennert> so i.e. we issue a SAMPLE, shift out the sampled data while we shift in the new test vector, and issue EXTEST
Oct 22 04:42:35 <lennert> but with that parallel i/f, you can do that 8 bits at a time, right?
Oct 22 04:42:42 <vmaster> yes
Oct 22 04:42:53 <lennert> in theory we can do that in larger groups
Oct 22 04:43:07 <lennert> i.e. we could just write the entire scan vector, and then read out the old scan vector
Oct 22 04:43:12 <lennert> is there any other case where the latency matters?
Oct 22 04:43:26 <vmaster> yes
Oct 22 04:43:33 <vmaster> when debugging arm7/arm9 systems for example
Oct 22 04:43:54 <lennert> can you describe what the issue is there?
Oct 22 04:44:36 <vmaster> okay, you write target memory by shifiting instructions into the pipeline that write the core registers, and an instruction that stores them to main memory afterwards
Oct 22 04:45:00 <vmaster> after that, you have to poll a special scan chain for an acknowledgment
Oct 22 04:45:20 <vmaster> the arm has 16 core registers, one has to be used as a base register, the last ist the program counter
Oct 22 04:45:20 <lennert> right
Oct 22 04:45:28 <lennert> yes
Oct 22 04:45:34 <lennert> okay, that's annoying
Oct 22 04:45:37 <vmaster> that gives your 14 usable registers, or 56 bytes at a time, before having to wait
Oct 22 04:46:16 <lennert> there's something similar with xilinx fpga's in that you have to keep polling the IR after you program the chip and issue JSTART, because the IR has the 'done' bit
Oct 22 04:46:29 <lennert> but that's only once
Oct 22 04:47:10 <lennert> hmmm
Oct 22 04:47:21 <vmaster> on xc9500 cplds, you have to check the result of many writes, and enter an exception handling process if the result didn't match
Oct 22 04:47:25 <lennert> this kind of thing just makes you want to shift the control logic to the jtag interface instead of the host pc
Oct 22 04:48:23 <lennert> which is also problematic
Oct 22 04:48:39 <vmaster> yeah, you have a tradeoff between flexibility and performance
Oct 22 04:49:16 <vmaster> mpeforth has a nice usb arm-jtag debugger, but it's tailored to arm debugging - not much use for other tasks
Oct 22 04:49:33 <vmaster> they do all the work with an onboard arm7 uc
Oct 22 04:49:42 <lennert> makes sense
Oct 22 04:50:08 <lennert> pci writes/reads are still thousands of cycles each, so that wouldn't even be very much faster than parallel
Oct 22 04:50:46 <vmaster> pci would just allow you to do writes of more than 8bit, but that's not the order of magnitude we're looking for
Oct 22 04:52:46 <lennert> there's the 'long scan' case, where we benefit from burst writes, and the 'poll scan chain' case where we benefit from fast turnaround time
Oct 22 04:56:11 <vmaster> ideally, there's a sophisticated jtag interface/api that may be implemented completely in hardware, or partly in hardware and partly on the host pc
Oct 22 04:56:22 <vmaster> *there'd be
Oct 22 04:57:23 <vmaster> for wigglers (which still many are going to use) or other bitbanging interfaces, this would be implemented by generic host software, while advanced devices could offload work to the hardware
Oct 22 04:57:34 <lennert> yeah
Oct 22 04:57:46 <lennert> i was thinking about converting my spartan3 loader to the epp interface you suggested
Oct 22 04:57:55 <lennert> and then to write a shim layer to convert the epp stuff into bitbang stuff
Oct 22 04:58:01 <lennert> epp->bitbang is trivial in software
Oct 22 04:58:05 <vmaster> yep
Oct 22 04:58:15 <lennert> so indeed, have the s/w speak some protocol that is latency-insensitive and offloadable
Oct 22 04:58:23 <lennert> and then decide what you do in s/w and what you offload to h/w
Oct 22 04:58:27 <vmaster> see my jtag api at openocd.berlios.de
Oct 22 04:58:29 <lennert> okay, my running partner has arrived
Oct 22 04:58:37 <vmaster> heh, cya later then
Oct 22 04:58:42 <lennert> i will when i get back
Oct 22 04:58:45 <lennert> i'm off for running now
Oct 22 04:58:49 <lennert> be back in ~1.5 hrs
Oct 22 04:58:53 <lennert> ciao :)
Oct 22 04:58:55 <lennert> thanks for the conversation so far
Oct 22 06:02:41 <lennert> ok, back
Oct 22 06:02:57 <lennert> need a shower though
Oct 22 06:29:01 <vmaster> wb
Oct 22 06:29:20 <lennert> thanks
Oct 22 08:09:37 <ka6sox> ep1220: ping?
Oct 22 08:10:04 <ep1220> ka6sox: pong
Oct 22 08:10:14 <ka6sox> how goes it?
Oct 22 08:10:40 <ep1220> the PCBs arrived yesterday, late afternoon.
Oct 22 08:10:49 <ka6sox> excellent.
Oct 22 08:10:57 <ep1220> all parts i ordered are here as well
Oct 22 08:11:11 <ep1220> just promsied to spend the weekend with the family
Oct 22 08:11:19 <ep1220> so work has to wait till monday
Oct 22 08:11:24 <ep1220> unless it rains tomorrow
Oct 22 08:11:35 <ka6sox> family first....*unless it rains*
Oct 22 08:11:39 <ka6sox> :)
Oct 22 08:11:46 <ep1220> :-)
Oct 22 08:12:08 <ka6sox> my  4yr old should be waking up anytime soon.
Oct 22 08:13:06 <ep1220> so he will want breakfeast ...
Oct 22 08:13:27 <ka6sox> ya...his mother is sleeping in today.
Oct 22 08:14:50 <ka6sox> vmaster was worried about the speed of the drivers that are available for the ftdi parts...
Oct 22 08:16:39 <ep1220> i did measure on Windos, and did not see more dealy than I expected due to USB
Oct 22 08:16:49 <ep1220> on Linux I used libusb
Oct 22 08:17:09 <ep1220> as i understood on datatransfers it directly calls into the OS driver
Oct 22 08:17:50 <ep1220> but did no benchmarks
Oct 22 08:17:58 <ka6sox> yes...
Oct 22 08:18:13 <ka6sox> I don't think that there is a mpsse driver written yet.
Oct 22 08:19:03 <ep1220> there is a lib_fdti (not by FTDIchip)  which supports JTAG and uses libusb as well 
Oct 22 08:19:44 <ka6sox> ah...okay cool.
Oct 22 08:19:55 <ep1220> when I looked into it  libusb team said they change API
Oct 22 08:20:10 <ka6sox> k
Oct 22 08:20:19 <ep1220> i did not feel comfortable having to support this lib-ftdi
Oct 22 08:20:30 <ep1220> so i wrote my own layer
Oct 22 08:20:46 <ka6sox> oh excellent
Oct 22 08:21:07 <ep1220> Now i have same API on windos and Linux
Oct 22 08:21:17 <ka6sox> this is very good.
Oct 22 08:21:25 <vmaster> ah, nice
Oct 22 08:21:56 <ep1220> there seem to be a few quirks in libusb regarding device detection
Oct 22 08:22:10 <vmaster> mhh, that's working fine for me
Oct 22 08:22:23 <vmaster> but performance aint that good, using libftdi as well as ftd2xx
Oct 22 08:22:47 <ka6sox> so it maybe ftd2xx that is the issue
Oct 22 08:22:58 <ep1220> on my system there were differences between what libusb detected and what usbview showed
Oct 22 08:23:27 <ep1220> at that time libusb had anounces anew version soon, so i did not investigate
Oct 22 08:23:44 <vmaster> with your own driver: do you use multi-threading?
Oct 22 08:23:49 <ep1220> vmaster: were do You see the performance probs
Oct 22 08:23:53 <ep1220> vmaster: no
Oct 22 08:24:57 <vmaster> on ftd2xx (at least with the current version on a vanilla 2.6.13 kernel) there's a deadlock - FT_Read wont return, even though the data was received by the OS
Oct 22 08:25:23 <vmaster> ftdi support suggested to use FT_GetQueueStatus and a sleep, to wait until the data is there
Oct 22 08:25:30 <vmaster> that's a nightmare for latency
Oct 22 08:26:04 <vmaster> with libftdi, i had problem when writing too much data
Oct 22 08:26:36 <vmaster> so i had to limit the amount of data, giving reduced throughput, as the latency is ~10ms
Oct 22 08:26:54 <vmaster> ftd2xx solves this by using multi-threading
Oct 22 08:27:10 <vmaster> they have one thread continously reading from Bulk-In
Oct 22 08:27:59 <ep1220> i guess one has to be carefull when sending lots of data
Oct 22 08:28:22 <ep1220> the chip writes out data slower than the it can receive data from USB
Oct 22 08:28:25 <vmaster> mhh, i guess it's rather about reading the data soon enough
Oct 22 08:28:44 <vmaster> which is why libftdi fails, but ftd2xx not
Oct 22 08:29:11 <vmaster> ftd2xx initiates writes of 4096 byte, but libftdi would fail when i wrote ~700 byte
Oct 22 08:29:31 <vmaster> the only difference is that ftd2xx has concurrent reads
Oct 22 08:29:47 <vmaster> unfortunately, libusb is synchronous, so you have to use another thread for reading
Oct 22 08:30:03 <vmaster> and if you're not carefull enough with that, you get the deadlocks i'm experiencing with ftd2xx
Oct 22 08:30:14 <lennert> forcing people to use blocking i/o is one of the things i hate
Oct 22 08:31:35 <vmaster> i asked ftdi about some low-level information about the chip, but that was friday afternoon, and i guess they've already left for the weekend
Oct 22 08:35:48 <ep1220> sorry, the family calls ..
Oct 22 08:36:22 <ka6sox> bye!
Oct 22 08:36:24 <ka6sox> have fun.
Oct 22 08:36:33 <vmaster> cya
Oct 22 09:55:43 <lennert> is there an easy way to find out whether an input pin is unconnected?  check whether it's randomly oscillating?
Oct 22 09:58:30 <vmaster> mhh, wouldn't it be technology dependant?
Oct 22 09:59:58 <lennert> yup
Oct 22 10:00:22 <lennert> do non-cmos fpga's exist?
Oct 22 10:00:57 <vmaster> heh, probably not
Oct 22 10:04:12 <lennert> what's your opinion on openwince jtag stuff?
Oct 22 10:04:37 <ka6sox> lennert, yes they do...but they are VERY expensive
Oct 22 10:05:34 <lennert> ka6sox: what's the point.. higher switching speed?
Oct 22 10:05:40 <ka6sox> yes.
Oct 22 10:05:44 <ka6sox> very fast parts.
Oct 22 10:05:53 <lennert> high power consumption
Oct 22 10:05:57 <ka6sox> GHZ+ parts and RAD hard.
Oct 22 10:05:58 <lennert> low gate counts
Oct 22 10:06:02 <lennert> wow, ghz+
Oct 22 10:06:43 <lennert> great for implementing a fast arm core :P
Oct 22 10:07:52 <ka6sox> the ARM police might be out....
Oct 22 10:07:57 <lennert> hehe
Oct 22 10:09:04 <lennert> i wouldn't exactly call them police
Oct 22 10:09:24 <lennert> police are supposed to fight for the good cause
Oct 22 10:10:10 <ka6sox> yes indeed
Oct 22 10:10:52 <vmaster> openwince jtag seems to be written for a limited purpose
Oct 22 10:12:30 <ka6sox> parallel wigglers on windows?
Oct 22 10:12:49 <vmaster> uhm, windows and linux, but that's about it
Oct 22 10:13:23 <ka6sox> that is what was cheap.
Oct 22 10:13:24 <vmaster> it just wont scale to anything else but low-performance boundary-scan flash writing
Oct 22 10:16:09 <lennert> okay
Oct 22 10:16:15 <lennert> so it's better not to bother with it?
Oct 22 10:16:30 <vmaster> mhh, what do you want to achieve?
Oct 22 10:16:45 <lennert> one package that can do everything! :)
Oct 22 10:17:02 <vmaster> heh, i may be biased, but i wouldn't bother with openwince then
Oct 22 10:18:29 <ka6sox> I wouldn't bother with it..there are better starting places....
Oct 22 10:19:00 <ka6sox> black(something) looks better to me (another opensource jtag thingo)
Oct 22 10:19:03 <ka6sox> (software)
Oct 22 10:19:39 <lennert> i kind of have in my head what i want things to look like
Oct 22 10:20:02 <lennert> but if we start from scratch, there'll be Yet Another jtag tool out there
Oct 22 10:20:05 <lennert> and we already have too many
Oct 22 10:21:45 <ka6sox> look for black(something) on freshmeat
Oct 22 10:24:42 <vmaster> hmm... freshmeat only gives 6 hits on 'jtag', and nothing with black in it
Oct 22 10:25:08 <ka6sox> jelie is interesting (as we are playing with Xscale devices)
Oct 22 10:26:48 <lennert> jelie?
Oct 22 10:27:03 <vmaster> jelie.org
Oct 22 10:27:06 <vmaster> a pxa250 debugger
Oct 22 10:27:10 <lennert> oh
Oct 22 10:28:08 <lennert> Manuel de l'utilisateur (seulement en français)
Oct 22 10:28:11 <lennert> that's nice
Oct 22 12:48:28 <[g2]> so are you guys following the cell phone hacking at all ?
Oct 22 13:53:14 <lennert> [g2]: nope
Oct 22 13:56:04 <ka6sox> that is a BIG usage I hear of jtag...reprogramming the phones.
Oct 22 14:59:10 <dyoung-away> lennert, vmaster, can you remind me what the file is that may  need twiddling for the Xserver to work with the webpack ?
Oct 22 15:01:24 <ka6sox> time for me to setup s3projects.org?
Oct 22 15:02:58 <dyoung-away> http://fjtag.sourceforge.net/ mght be of interest too
Oct 22 15:07:16 <ka6sox> back in 30 minutes
Oct 22 16:14:11 <ka6sox> dyoung-away: if I setup s3projects.org will you please help populate it?
Oct 22 16:15:00 <ka6sox> (since I think its time for it to be setup :)
Oct 22 16:39:23 <lennert> ka6sox: okay
Oct 22 16:39:29 <lennert> ka6sox: i will help populate it
Oct 22 16:39:35 <lennert> ka6sox: i have a subversion tree with vhdl crap
Oct 22 16:39:45 <lennert> dyoung-away: libXm.so.something and libcurl.so.2.0.2
Oct 22 16:40:11 <dyoung-away> lennert, I have those; the WindU thingo wasnt starting
Oct 22 16:40:36 <dyoung-away> I eventually found the right config file to hack out "nolisten" from
Oct 22 16:41:30 <lennert> dyoung-away: /etc/X11/somewhere
Oct 22 16:42:11 <dyoung-away> it was /etc/kde3/kdm/kdmrc
Oct 22 16:43:07 <lennert> ah
Oct 22 16:43:11 <lennert> depends on which dm you use
Oct 22 16:43:14 <lennert> i tend to use gdm
Oct 22 22:13:28 <ka6sox> okay so I'm going to like setup s3projects.org tonight...
Oct 22 22:13:45 <ka6sox> (if I don't fall asleep first)
**** ENDING LOGGING AT Sun Oct 23 02:59:57 2005