**** BEGIN LOGGING AT Thu Jan 19 02:59:58 2006 Jan 19 05:09:20 * lennert got his fluke today Jan 19 05:37:14 lennert: there? Jan 19 05:45:53 <[g2]> lennert congrats ! Jan 19 05:46:37 thanks! Jan 19 06:13:21 lennert: u've succeded to run a linux on a PPC of a Xilinx ? Jan 19 06:19:03 well Jan 19 06:19:09 i wouldn't use a 'divisor' for the tck rate Jan 19 06:19:27 lennert: why ? Jan 19 06:19:33 divisor implies a base speed (divisor=1) and just isn't too fine-grained enough Jan 19 06:19:47 i.e. what if your base rate is 50mhz and you want to run at 40? you have to run at 25.. Jan 19 06:20:14 if the device implements it with a clock divider, it should be free to choose the next lower speed, i think Jan 19 06:20:36 i like that it's a byte protocol Jan 19 06:20:44 what i didn't find is what happens when there is a crc error Jan 19 06:20:46 why would you reduce the speed of your PPC to run a linux ? Jan 19 06:21:02 you throw the frame away.. and the other end will wait indefinitely? Jan 19 06:21:16 loool Jan 19 06:21:21 is it a robot ? Jan 19 06:21:25 i'm talkin to a robot ? Jan 19 06:21:44 sounds like the answer have nothing to see with the questions :) Jan 19 06:21:57 vmaster ? :) Jan 19 06:22:08 key2: this is just a guest, but i remember him introducing you to his ignore list Jan 19 06:22:12 -t Jan 19 06:22:15 +s Jan 19 06:22:18 as to SEEK_STATE.. there can be many ways of arriving in a certain state Jan 19 06:22:48 vmaster: really ? Jan 19 06:22:51 hahah Jan 19 06:23:08 talk to him see if he answers :) Jan 19 06:23:50 vmaster: what's funny? Jan 19 06:24:29 lennert: key2 thought you were answering his question Jan 19 06:24:51 [14:14] < key2> lennert: u've succeded to run a linux on a PPC of a Xilinx ? Jan 19 06:24:52 [14:19] < lennert> well Jan 19 06:24:52 [14:19] < lennert> i wouldn't use a 'divisor' for the tck rate Jan 19 06:24:52 [14:20] < key2> lennert: why ? Jan 19 06:25:25 but obviously he's still on your ignore list, so you didn't see this Jan 19 06:28:04 right, indeed Jan 19 06:32:37 vmaster: past that Jan 19 06:32:48 lennert: could u remove me from the ignore list ? Jan 19 09:16:46 lennert, morning Jan 19 09:19:09 ka6sox: morning Jan 19 09:23:58 lennert, ka6sox: morning, guys; (evening would be more appropriate here in BG :) Jan 19 09:28:30 managed to cross-compile apex-1.3.13; played a bit with make menuconfig; Marc Singer said yeah; but my problem is I still can't test it - hdw not ready :(; Jan 19 09:45:05 velinp, w00t Jan 19 09:45:25 Lennert: does the V2p have Rocket I/O? Jan 19 09:46:19 ka6sox, now looking thru apex to see what CONFIG_SDRAM_BANK1 really does; Jan 19 09:46:27 most of the v2p range have Jan 19 09:47:16 some of the package options dont have any rocket io ports Jan 19 09:48:03 morning btw :) Jan 19 09:50:01 velinp, cool Jan 19 09:50:05 AchiestDragon, thanks. Jan 19 09:50:22 time for me to "start" my day....cya laters online here. Jan 19 10:41:38 * ByronT-Away is back after 1h2m: home_-_sleep_required Jan 19 11:12:09 ka6sox: yeah, i think it does have (rocket i/o) Jan 19 11:12:23 velinp: good evening Jan 19 11:14:05 velinp: or as they say, Добър вечер Jan 19 11:14:20 lennert: I can't read that Jan 19 11:14:42 lennert: please, transcribe Jan 19 11:14:49 dober vecher Jan 19 11:14:59 more like dob"r Jan 19 11:15:15 lennert: dobyr vecher; glad to see/hear you Jan 19 11:16:25 lennert: how are you doing? Jan 19 11:16:31 problem with transliterating cyrillic is that everyone does it differently.. Jan 19 11:16:51 dobpe sym? s"m? Jan 19 11:16:56 dobre Jan 19 11:17:06 some people even write sha as 'w' Jan 19 11:17:13 because the w looks like a sha Jan 19 11:17:35 yes, but cp-1251 seems to be the std (for BG); how does it happen your bulgarian is quite good Jan 19 11:17:54 right, cp1251. that's also what allofmp3.com uses for russian tracks. Jan 19 11:18:09 it's really annoying if your mp3 player insists on utf8 Jan 19 11:18:29 well, i know a bit of russian, and like 10 words of bulgarian Jan 19 11:18:44 been in bg? Jan 19 11:18:53 nope Jan 19 11:19:22 intend to? nice ski/sea here; not that i do either much ... Jan 19 11:19:28 hehe Jan 19 11:19:32 i live 5km from the sea where i am Jan 19 11:19:39 (it's a bit cold here though) Jan 19 11:19:50 i came back on monday from lithuania and there was lots of snow there Jan 19 11:20:15 baltic; i've dipped a finger in it; you parents in law live there; you in nl? Jan 19 11:20:29 yes Jan 19 11:20:38 note that lithuanian and latvian are very different from estonian Jan 19 11:20:58 it's good to have you mother-in-law in a different country :) Jan 19 11:21:03 haha Jan 19 11:21:06 yes, sometimes :) Jan 19 11:21:29 well, my mother in law is a very kind woman, it's mostly the culture differences that i can't get used to Jan 19 11:21:35 like, them offering me food every 5 minutes Jan 19 11:21:47 instead of a drink? :) Jan 19 11:21:54 i take the drinks but not the food :) Jan 19 11:22:05 i mean, it's like we speak different languages Jan 19 11:22:25 "do you want to eat X?" "no, thank you, i'm not hungry." "do you want to eat Y?" didn't i just say i wasn't _hungry_? Jan 19 11:22:46 there is a nice bulgarian word - meze; it's same as the russian zakusivat Jan 19 11:23:19 my dictionary doesn't have that word.. Jan 19 11:23:56 i remember m. sholohov; not before the third glass ... Jan 19 11:24:46 which of them?? :) Jan 19 11:25:49 it was about a nazy camp; the guy was 'invited'; he had to drink in order to take some food to his fellow prisoner's; not sure by m.s. Jan 19 11:26:41 i got quite a lot of practise in the last few weeks Jan 19 11:27:56 me too; but i do it 'moderately'; i mean i drink with my wife :) Jan 19 11:28:21 and when she drops down drunk, you stop too? :) Jan 19 11:28:49 <[g2-lap]> lennert I thought you'd get a kick out of this http://www.picocomputing.com/products/cards.php Jan 19 11:29:57 [g2-lap]: looks like it'd be expensive Jan 19 11:30:51 <[g2]> it is, but that doesn't make it totally uncool (around $2.8K) Jan 19 11:31:07 * lennert 's yaw drops Jan 19 11:31:26 * [g2] muses we're in the wrong business :) Jan 19 11:31:37 well, yeah Jan 19 11:31:53 $2800, jeeez Jan 19 11:32:14 <[g2]> but it is fun to daydream about plugging one into the Loft's CF slot Jan 19 11:32:48 sure Jan 19 11:32:59 i like daydreaming about having $RANDOM_EXPENSIVE_THING Jan 19 11:33:03 * [g2] goes back to work Jan 19 11:33:13 <[g2]> yeah it's fun for a little while Jan 19 11:37:16 lennert: thanks for the chat; how do you get this slant font (like [g2] goes back to work)? Jan 19 11:37:32 velinp: use /me ? Jan 19 11:37:35 /me blah Jan 19 11:37:36 * lennert blah Jan 19 11:38:11 lennert: ok, thanks; Jan 19 11:39:46 (OT = I went to bulgaria skiing a few years ago - the skiing was crummy (not much snow) but the partying was excellent. A fine country. Jan 19 11:40:05 particularly liked the sweet red wines Jan 19 11:40:42 wookey__: I like it too; except some things :) Jan 19 11:43:23 wookey__: hehe i want to visit belgium sometime to go on a tour of the abbeys Jan 19 11:44:27 lennert: the lnode80 is only slightly larger than a cf card Jan 19 11:44:39 lennert: basically its the same size as a 802.11b cf card Jan 19 11:45:45 i particularly like the liqour in lithuania Jan 19 11:45:51 its most redeeming quality being that it's cheap Jan 19 11:46:00 and available everywhere at any time of day Jan 19 11:46:00 hehe Jan 19 11:46:18 lennert: hehe, kind of like rum here in barbados Jan 19 11:46:24 hic Jan 19 11:46:50 and Taquila here Jan 19 11:49:33 in holland mostly just wine Jan 19 11:49:59 i fell in love with vodka the first time i went to .lt, about 3.5 yrs ago Jan 19 11:50:24 uh oh...at least you haven't hit the Schnapps. Jan 19 11:50:38 i can't drink schnapps Jan 19 11:50:57 and Gin just is revolting Jan 19 11:51:10 (mother liked Gin) Jan 19 11:51:45 agree Jan 19 11:52:04 the less contaminated the alcohol is, the better Jan 19 11:53:33 okay enough of drinking before local noon...back to work! Jan 19 11:53:36 bye for now Jan 19 11:56:08 Hard to believe that PICO card is $2.8k Jan 19 11:57:25 ah, beewoolie-afk Jan 19 11:57:29 i wrote some comments on your proposal Jan 19 11:57:34 but i think you weren't there when i did Jan 19 11:58:03 lennert: share? Jan 19 11:58:15 < lennert> i wouldn't use a 'divisor' for the tck rate Jan 19 11:58:18 BTW, I updated part of it since the DELAY opcode wasn't useful. Jan 19 11:58:22 < lennert> divisor implies a base speed (divisor=1) and just isn't too fine-grained enough Jan 19 11:58:29 < lennert> i.e. what if your base rate is 50mhz and you want to run at 40? you have to run at 25.. Jan 19 11:58:29 Certainly. Jan 19 11:58:36 < lennert> if the device implements it with a clock divider, it should be free to choose the next lower speed, i think Jan 19 11:58:39 < lennert> i like that it's a byte protocol Jan 19 11:58:43 < lennert> what i didn't find is what happens when there is a crc error Jan 19 11:58:47 We could use an integer/fraction encoding. Jan 19 11:58:50 < lennert> you throw the frame away.. and the other end will wait indefinitely? Jan 19 11:59:09 CRC errors should return a result indicating that the transaction failed. Jan 19 11:59:13 beewoolie-afk: i would just specify the rate in mhz or something Jan 19 11:59:24 Problem is that we may not know the ID if it's garbled. Jan 19 11:59:27 beewoolie-afk: but what if the result packet has a crc error/ Jan 19 11:59:40 Yeah, that's always a problem. Jan 19 11:59:57 At least, this way we can detect the error. Jan 19 12:00:02 is a crc error really a possible scenario? Jan 19 12:00:13 Well, it's good policy and it's cheap. Jan 19 12:00:25 vmaster: if you run it over serial, sure.. Jan 19 12:00:43 Bits in memory *can* rot. Jan 19 12:01:04 but crc/fcs protects against transmission errors.. Jan 19 12:01:46 okay, but this protocol is to be used on a short point-to-point connection, between the uC and the fpga, right? Jan 19 12:02:14 Ever read this: http://research.microsoft.com/~lampson/33-Hints/WebPage.html Jan 19 12:02:53 Read 4. fault tolerance Jan 19 12:05:32 Error detection and recovery should be end-to-end. Jan 19 12:05:57 Depending on intermediate checks doesn't give the system reliability. Jan 19 12:06:50 lennert: The problem with setting the clock frequency as a frequency is that it may not be achievable. Jan 19 12:06:59 beewoolie-afk: so you choose a lower one Jan 19 12:07:05 yeah, hence my question if it's really a possible scenario that data might get corrupted in our setup Jan 19 12:07:13 Yeah, but the user may nowbe able to kow it. Jan 19 12:07:33 beewoolie-afk: the device might not support divisor=1 either Jan 19 12:07:39 vmaster: that's a short sighted point of view. Jan 19 12:07:48 The CRC is cheap and it guarantees correctness. Jan 19 12:08:06 Without out it, there is no way to know if the intervening layers did the right thing. Jan 19 12:10:20 And, the cost of including it is negligible. Jan 19 12:10:45 lennert: of course it supports divisor 1. How coult it not? Jan 19 12:11:41 lennert: I don't really care how to encode the frequency, but it need to be such that most or all of the encodable values are valid. Jan 19 12:12:29 It is sloppy to encode 80% of values that don't do what the user requests. Jan 19 12:54:03 lennert: Do you understand how we have to handle missing transactions? Jan 19 13:03:36 hi Jan 19 13:03:40 in office now. Jan 19 13:04:07 Lennert: ping? Jan 19 13:05:46 you can use either dividers OR DPLL's in the FPGA's to provide clocks. Jan 19 13:06:22 I can think of two good questions. Jan 19 13:06:37 1) what values for tclk frequency are likely to be needed? Jan 19 13:06:50 2) how accurately will the user expect to set these values? Jan 19 13:07:39 ah, RTCK would be useful, too Jan 19 13:07:57 The BSDL files I've seen have a maximum clock value, usually in the for Vx10^E where V is a small integer and E is usually 6. Jan 19 13:08:09 What is RTCK? Jan 19 13:08:17 the returned TCK Jan 19 13:08:26 synthesizable arm cores use it Jan 19 13:08:43 Can you explain a little more? Jan 19 13:09:08 Is this the variable clocking that some JTAG emulators refer to? Jan 19 13:09:24 the TCK enters the ARM and gets syncronized with the processor clock, and this is output on RTCK Jan 19 13:09:53 they're using adaptive clock for two different things - one is rtck, and one is driving the tck as high as long as the device can follow Jan 19 13:10:29 ah, so they drive tck faster until rtck doesn't keep up? Jan 19 13:10:43 I haven't seen a lot of devices with RTCLK Jan 19 13:10:57 ka6sox-office: Have you seen any? Jan 19 13:11:23 on SOME MIPS and a few of the Freescale procs. Jan 19 13:11:37 I don't know ARM well enough Jan 19 13:11:57 would this be ejtag? Jan 19 13:12:05 well, i only know it from arm Jan 19 13:12:33 vmaster: any example cores we can look at? Jan 19 13:12:42 I don't know about the Xscale Jan 19 13:12:45 ARM7TDMI-S, ARM926EJ-S are the most common Jan 19 13:13:05 mhh, xscale is a hard core, so it doesn't need the rtck Jan 19 13:13:06 Is the -S the variant with this feature? Jan 19 13:13:19 all -S variants require rtck Jan 19 13:13:28 you can go without, but that limits you to 1/6th pclk Jan 19 13:13:30 * beewoolie-afk starts searching Jan 19 13:13:35 http://www.arm.com/support/faqip/3732.html Jan 19 13:15:17 Well, 1/6 of 200MHz is 33MHz. Far better than any JTAG emulator that I've used so far. Jan 19 13:16:14 we might have devices that can't go that fast either Jan 19 13:16:21 soooo...we may need to divide them down. Jan 19 13:17:12 we would use the divided clock for creating the TCLK that would drive our logic. Jan 19 13:17:41 we might have to go as low as 4mhz Jan 19 13:17:50 (wouldn't be for something like the Xscale Jan 19 13:18:32 the ARM9 core on the TS7200 is capable of this clock change? Jan 19 13:18:53 ka6sox-office: BTW, I added that link, but it needs approval. I suppose this is goatse.cx protection? Jan 19 13:20:10 I can see that RTCK is an important feature to support. The only way to test that it works, though, is to have a core that requires it. Jan 19 13:20:20 if there is a device data base for the chip types , then the max tclock should be in the data , so it could be made to set up auto for that Jan 19 13:20:51 get a 30$ lpc board - they are all arm7tdmi-s Jan 19 13:20:57 you can software set the clock on the ts7200 Jan 19 13:20:58 beewoolie-afk, yes thats right Jan 19 13:21:05 I need Tiersten to approve it :) Jan 19 13:21:19 * ka6sox-office forgets the PW. Jan 19 13:22:40 and the 1/6th seems to be best-case - i can't reliably debug an lpc2294 running at 60mhz with the ft2232c at 6mhz Jan 19 13:23:00 I found this interesting page in the FAQ. Jan 19 13:23:07 vmaster, how many bits in the bsdl? Jan 19 13:23:17 ARM uses a file in the format that I was originally thinking of for test. Jan 19 13:23:22 http://www.arm.com/support/faqip/3845.html Jan 19 13:23:50 I'm not now sure this is the right way for us to handle test, but it is easy. Jan 19 13:23:59 ka6sox-office: the lpcs have no boundary-scan chain, the debug register is 33 bits long Jan 19 13:25:09 beewoolie-afk: did you read the svf spec? Jan 19 13:25:39 I read it over, but I didn't comprehend what they were doing. I may have missed part of the spec. Jan 19 13:26:17 vmaster, ah Jan 19 13:26:40 well, all they really do is specify states in which to end a scan, and then the IR and DR scans, the value to be scanned in, and the expected result Jan 19 13:26:54 beewoolie-afk: if you have a high-speed and a low-speed jtag device, then one of them won't be able to support divisor=1, or the high speed one can't run faster than low speed Jan 19 13:27:21 lennert: That's true no matter how the frequency is encoded. Jan 19 13:27:31 lennert: with this protocol you're likely to have only device Jan 19 13:27:37 ype Jan 19 13:27:42 20:11 < beewoolie-afk> lennert: of course it supports divisor 1. How coult it not? Jan 19 13:27:50 just responding to your statement Jan 19 13:27:53 so a slow CPLD would slow down a fast proc Jan 19 13:27:59 Yeah, but that's the same as saying FREQ=40MHz. Jan 19 13:28:22 sigh Jan 19 13:28:38 feeling frustrated? Jan 19 13:29:03 I agree that some parts won't go as fast as others. Jan 19 13:29:23 The questions is how do we describe the TCLK rate. Jan 19 13:29:27 we will have to have a method for determining what speed we can sustain. Jan 19 13:29:53 beewoolie-afk, its a register value in the fpga that is written by the proc. Jan 19 13:29:55 We can use a slow rate to read the IDCODES of the core on the chain. Jan 19 13:30:10 Once we ID the cores, we know what rates they can sustain. Jan 19 13:30:29 Then it's a matter of setting the rate. Jan 19 13:30:50 we can pass that information to the TS and then have it set a register. Jan 19 13:30:55 lennert suggested that we specify this in MHz. I'm OK with that as long as we can really set the rate to the value requested. Jan 19 13:31:15 I think that we will have divisors that can be defined. Jan 19 13:31:25 (and thus we can set it by mhz) Jan 19 13:31:48 ka6sox-office: this was about the use of a divisor in the protocol. We just need to make the protocol describe something that the FPGA can use. Jan 19 13:32:06 It could be a predefined table of values. Jan 19 13:32:28 if we define the reference oscillator frequency we can do that. Jan 19 13:33:06 ka6sox-office: remember, this is about making the protocol make sense. We don't want to hard-code the protocol so that it only works with this version of the FPGA. Jan 19 13:33:16 The best method is something that is flexible and clear. Jan 19 13:33:32 Divisors aren't so good in the protocol because they're dependent on FPGA implementation. Jan 19 13:33:37 the VHDL code is mostly portable with *some* specific things related to the hardware. Jan 19 13:34:08 ka6sox-office: It isn't about that. We may implement the protocol with something other than hardware. Jan 19 13:34:26 what could that be? Jan 19 13:34:26 e.g. SW implementation to drive parallel port dongle. Jan 19 13:35:05 the parallel port dongle is just a buffer...doesn't have *any* logic Jan 19 13:35:16 and so... Jan 19 13:35:37 We still need a way to verify testing procedures. Jan 19 13:35:51 we have logic and we want to set the frequency..that is done by setting a register that controls a divisor. Jan 19 13:35:57 Right. Jan 19 13:36:37 Look at it this way. Jan 19 13:36:42 the way that is set depends on what devices you have in your toolkit (for each FPGA type) Jan 19 13:36:50 Let's say we implement a second version that is *way* faster than the first. Jan 19 13:37:07 The first one can only go 4 MHz because we borked it. It's still useful, tho. Jan 19 13:37:28 it would be helpful if there were a way for the controlling software to gracefully handle these cases. Jan 19 13:37:49 We want to be able to cope with changes in the interpreting hardware. Jan 19 13:38:21 the clock freq and divisors are the determinant elements. Jan 19 13:38:36 thats a function of hardware. Jan 19 13:38:42 so, the second implementation can go to 11 (i.e. 400MHz). there shouldn't be anything precluding a testing stream that works OK with this. Jan 19 13:39:00 then perhaps we need a way to query the hardware to know how it handles clocking? Jan 19 13:39:10 Ask the FPGA what it's base frequency is? Jan 19 13:39:36 that would have to be a hard coded thing or we can just say "the clock freq is 40mhz" period. Jan 19 13:39:57 ka6sox-office: But if we plug in another device that can go faster, how is the SW going to know this? Jan 19 13:40:00 we can then run the FPGA at 240mhz interanl. Jan 19 13:40:10 faster than 40mhz? Jan 19 13:40:51 above 100mhz wire length becomes an issue. Jan 19 13:40:52 OK. It is fine to say that the base frequency is 40MHz. Period. Jan 19 13:41:05 from that we can divide down Jan 19 13:41:06 do we then use a divider? Jan 19 13:41:12 yes Jan 19 13:41:16 :-) Back to the beginning! Jan 19 13:41:22 yep Jan 19 13:41:25 can we divide by fractions? Jan 19 13:41:33 Should the divider be INT/FRAC? Jan 19 13:41:37 sometimes the clock dividers can do that. Jan 19 13:41:58 I would have to look at the S3 (but it may) Jan 19 13:45:05 phone Jan 19 14:04:48 off phone Jan 19 15:44:15 guess that it could be easy to do a auto max speed detect ,, Jan 19 15:44:34 ya Jan 19 15:45:06 the best thing would be to read the ID_CODES and then have the Proc set the max value for the chain. Jan 19 15:45:34 run a jtag read , at a low speed , run it again comparing the results at a faster speed ,,, and again , untill it starts showing diferences , so then drop it back one Jan 19 15:46:18 yeah, that's what I wrote. Jan 19 15:46:29 which one? Jan 19 15:46:30 :) Jan 19 15:47:12 they should both work. Jan 19 15:47:27 And that's fine as far as it goes, but a) we have to have accurate BSDL files, and b) the user still needs to be able to change the speed. Jan 19 15:47:44 as far as the speed setting to the program it would be a register in the fpga , could be read write so that the program will be able to know the speed Jan 19 15:47:50 As far as I can tell from my very small sample, BSDL files are notorously error prone. Jan 19 15:48:07 beewoolie-afk, I suspect you are correct. Jan 19 15:48:23 AchiestDragon: but remember that the issue is that we need to put something into the protocol to allow that register to be written. Jan 19 15:48:26 *if* you are using a file with the app from the vendor (proprietary) it works. Jan 19 15:48:47 Uh, huh. So, you mean to steal those files? Jan 19 15:49:01 I've been musing about this for some time. Jan 19 15:49:06 sometimes they are available and sometimes not Jan 19 15:49:08 BSDL files will always be a problem. Jan 19 15:49:16 yep Jan 19 15:49:23 plus if the spec for a chip says it can do 40mhz it may only work at 30mhz in the circut the device under test is fitted to Jan 19 15:49:26 My plan has been to augment BSDL files with data that helps us detect the specifics. Jan 19 15:49:35 good plan Jan 19 15:49:44 that way we can flesh them out. Jan 19 15:49:48 brb Jan 19 15:49:51 for example, there may be several cores with the same ID, but the target has variations. Jan 19 15:50:20 So, we have detect clauses in the extra meta-data that helps us determine exactly which target we're talking to. Jan 19 15:50:29 for example, we can read CP15 registers on ARM cores. Jan 19 15:51:02 and if a board has a chain of them there may be diferent devices with diferent max clocking rates , plus delays that may accur with chaining them Jan 19 15:51:07 And, SoCs have more registers we can poll to make sure we're talking to the specific vendor's chip. Jan 19 15:51:17 Of course. Jan 19 15:51:31 But we have to scan out all of the IDCODES and probe each one to find out. Jan 19 16:04:08 sounds like fun Jan 19 16:05:59 vmaster: ping? Jan 19 16:42:26 ka6sox-office: ping Jan 19 16:43:31 8-) Jan 19 16:44:12 ok the ram tracks fin on 2 layers , the pc104 with the link options for ts7200 or std pc104 seems to work on 2 layers ( still got some signals to test route there ) Jan 19 16:44:50 and got 18 i/o lines for the jtag / analizer interface to play with Jan 19 16:45:00 so looking good Jan 19 16:45:09 w00t Jan 19 16:46:57 18 lines is good because we can have triggers :) Jan 19 16:47:27 problem or portential problem i spotted , on the jtag connector as used the arm20pin format is not the same as the ieee std one http://www.interfacebus.com/Design_Connector_JTAG_Bus.html Jan 19 16:47:48 there diferent pinouts Jan 19 16:49:22 well going to need 1 bit for selecting the analizer buffers from that 18 Jan 19 16:50:14 the 20 pin ARM one has all the functions. Jan 19 16:50:32 so does the ieee one Jan 19 16:50:49 AchiestDragon, I understand thats why I said we have a bit for a trigger :) Jan 19 16:51:01 k Jan 19 16:51:39 (assuming we have 16 bits we care to capture) Jan 19 16:52:06 have been thinking about it also as i would like it to support the 10 pin jtag version that is used oftern also Jan 19 16:53:19 yes , you should be able to triger on a state of any of the bits or a specific state of 2 or more bits Jan 19 16:54:25 think the extra 17th bit would be better use if it was a clock input so it could sync to the unit its analizing Jan 19 16:55:07 ep1220's board has adapters to make this all happen. Jan 19 16:55:18 5 or 6 different formats. Jan 19 16:55:58 I think that all the common ones are covered. Jan 19 16:56:12 k, have been thinking about useing the extra 100mm*60mm spare pcb space for some adaptors Jan 19 16:57:32 next time you see ep1220 ask him about it...he may not have placed his order and we could put them on your spare space. Jan 19 16:57:49 he shows up fairly regularly and is in .at. Jan 19 17:00:36 k , by changing his design slightly fitting 8 bit dual voltage buffers rather than 4 it is posible to use the same circut for both the jtag and logic analizer functions , but would require a non std cable to the adaptors Jan 19 17:01:18 ah...we should discuss this with him next time he comes onboard. Jan 19 17:02:32 k Jan 19 18:16:53 ka6sox-office: what's ep1220's board ? Jan 19 18:19:42 a universal interface (voltage/connector) for JTAG. Jan 19 18:20:12 ka6sox-office: url ? Jan 19 18:20:26 there isn't one yet. Jan 19 18:20:30 its an Alpha board. Jan 19 18:20:45 what is it based on? Jan 19 18:21:26 fpga ? Jan 19 18:24:16 FT2232 currently Jan 19 18:24:28 it's slow Jan 19 18:24:44 i tryed jtag with it Jan 19 18:24:53 honestly, u can't really do anything with it Jan 19 18:25:08 it's almost as slow as parallal Jan 19 18:25:20 since the latency of the USB port is high Jan 19 18:25:22 which is why all the discussion about how to make it faster using other methods. Jan 19 18:25:33 well Jan 19 18:25:35 then I have an idea Jan 19 18:25:49 that would be quiet good but lil more expensive Jan 19 18:26:25 ka6sox-office: you take a little FPGA and put all the JTAG operation in it (read/write/readwrite...) Jan 19 18:26:51 thats what we are discussing Jan 19 18:27:03 you stick a little arm7 to it Jan 19 18:27:05 well Jan 19 18:27:07 i've done it Jan 19 18:27:19 i tryed first doing it with a scenix Jan 19 18:27:23 that can bitbang quiet fast Jan 19 18:27:38 but it's a 8bit microcontroller so it's not fast enough for handling everything Jan 19 18:27:52 i think the best idea is this one Jan 19 18:28:01 fpga + arm + ft2232 Jan 19 18:28:25 one part of the ft2232 would be used for reprogramming the ARM the other part for communicating with it Jan 19 18:29:13 so basically you could for example if you have a MIPS, use a special binary u made with GCC to burn into the ARM, then you have your protocol with the ARM via USB but the other part of the 2232 Jan 19 18:29:50 you use it as a parallel for communicating with the ARM and the serial part of the 2232 for reprogramming the arm7 Jan 19 18:30:29 and then if you need to adjust the voltage of the JTAG, you use a simple double buffer.. Jan 19 18:30:51 it would cost at the end about 40euros each PCB included Jan 19 18:31:04 there is a lot more to it since some targets provide voltage and some don't Jan 19 18:31:20 some targets use a 6 pin connector and some use a 20 pin connector. Jan 19 18:31:24 you can use a switch Jan 19 18:31:33 thats one way. Jan 19 18:31:39 well 20 pins for having just 4 of them really used ? Jan 19 18:31:49 yes that is sometimes true. Jan 19 18:31:57 but its what we need to talk to. Jan 19 18:32:06 its not for just one platform. Jan 19 18:32:12 well then you can eventually reprogramm the ucf of the fpga Jan 19 18:32:31 that is a PITA Jan 19 18:32:32 and put a standard 20 pins ribbon connector Jan 19 18:32:36 PITA ? Jan 19 18:32:55 what we plan on doing is putting the StD connector and adapters Jan 19 18:33:07 that will allow us to work universally Jan 19 18:33:17 Pain In The ARse. Jan 19 18:33:51 ASS Jan 19 18:33:51 ok Jan 19 18:33:52 got it Jan 19 18:34:10 ka6sox-office: but the board has to be something we would sell ? Jan 19 18:34:21 or it would be something that the user has to make himself ? Jan 19 18:34:38 either way Jan 19 18:34:48 I'm up for whatever makes it go. Jan 19 18:34:50 well Jan 19 18:34:54 just debating if to use the high dencity ribbon cable like used on ata133 ide drives , that may give us a 80Mhz jtag clock rate Jan 19 18:35:06 it's nto that easy to get a single FPGA Jan 19 18:35:26 how fast has to be the clock rate ? Jan 19 18:35:51 most of the FPGA's I have will clock internally to 260mhz and externally at least 1/2 of that. Jan 19 18:36:04 PPL ? Jan 19 18:36:53 PPL? Jan 19 18:38:20 well basically you have an external clock of 50mhz and with the PLL u get it up to 100 if you multiply by 2 Jan 19 18:38:21 oh Jan 19 18:38:22 sorry Jan 19 18:38:23 PLL Jan 19 18:38:24 .. Jan 19 18:40:10 the reference in our case is 40mhz and I'll PLL it up to 240mhz. Jan 19 18:40:21 * ka6sox-office doesnt' care about power consumption. Jan 19 18:40:35 what kind of xilinx would you use Jan 19 18:40:44 what would be big enough just for a state machine Jan 19 18:40:57 so we can put all the JTAG function in it Jan 19 18:41:18 a xc3s400-4tq144c Jan 19 18:41:31 bga? Jan 19 18:41:42 144pin tqfp Jan 19 18:41:58 oh k Jan 19 18:42:01 NO BGA... Jan 19 18:42:06 not possible to fix. Jan 19 18:42:22 what is it ? Jan 19 18:42:27 spartan 2 ? 3 ? Jan 19 18:42:30 2 Jan 19 18:42:32 er 3 Jan 19 18:43:07 sounds good Jan 19 18:43:14 and bga would need a 4 or more layer pcb , its a dubble sided pcb if it routes ok , and thats looking good atm Jan 19 18:44:23 so one of those plus one ARM so anyone could programm it with a GCC for it's own stuff plus a bft2232 for reprogramming the ARM and communicating with and some bullshit for adjusing the voltage would be fine right ? Jan 19 18:45:14 and we could bitbang up to 100Mhz easy Jan 19 18:45:59 with the pc104 vesion we should not need the bdi2232 unit , that woulde be a lower speed alternative Jan 19 18:46:35 10Mhz Jan 19 18:46:38 that's quiet slow Jan 19 18:46:58 plus you need sometimes to do a lot of calculation between each bit Jan 19 18:47:02 dunno if it's great Jan 19 18:47:22 oh Jan 19 18:47:24 sorry Jan 19 18:47:32 what at 10mhz Jan 19 18:47:33 ? Jan 19 18:47:44 well without the ft2232 you won't be able to communicate fast Jan 19 18:48:00 or we're not talkin about the same pc104 Jan 19 18:48:46 we got 32mb / 64mb of sdram attached to the fpga Jan 19 18:49:23 what for ? Jan 19 18:49:37 not sure you need that much for JTAG Jan 19 18:49:38 .. Jan 19 18:50:05 it's not a mem issue it's more a bitbanging issue Jan 19 18:50:10 maybe not , but its cheaper than sram and that size is cheep Jan 19 18:50:33 gimme url of the pc104 Jan 19 18:51:08 16 bit wide , so the max bit bang rate is going to be 16 times the read / write cycle time of the ram Jan 19 18:51:43 AchiestDragon: what PC104 u talkin about ? Jan 19 18:52:20 key2, the RAM is helpful for doing captures and standalone operation. Jan 19 18:52:21 the fpga board im working on at for this Jan 19 18:52:34 at = atm Jan 19 18:55:18 the S3/RAM combo will give us a lot of flexibility Jan 19 18:55:53 but the 32Mbit are not included into the FPGA Jan 19 18:56:00 that's something you wanna put apart Jan 19 18:56:01 rigjht ? Jan 19 18:56:17 http://www.whipy.demon.co.uk/JTAG.PS < block diagram of the card Jan 19 18:59:27 of what card ? Jan 19 18:59:34 don't have postscript reader Jan 19 19:00:12 the high speed fpga jtag tester card Jan 19 19:00:42 / logic analizer card Jan 19 19:03:52 who made it Jan 19 19:04:31 we are making it :) Jan 19 19:16:41 AchiestDragon: nice picture Jan 19 19:18:22 ty Jan 19 23:03:58 ~seen Tiersten Jan 19 23:04:08 tiersten is currently on #nslu2-linux (11h 42m 22s) #openjtag (11h 42m 22s) #openslug (11h 42m 22s), last said: 'The wiki hasn't been updated lately sorry'. Jan 19 23:05:11 Tiersten: when you have time could you please approve the url that beewoolie has on the info:JTAGprotocol page? Jan 20 01:38:50 morning Jan 20 01:40:26 morning Jan 20 01:40:42 morning Jan 20 01:42:09 a question regarding achiest's 2-layer design - are 2 layers enough for good signal conditions? Jan 20 01:48:47 vmaster, it depends Jan 20 01:48:59 if done right it works just fine. Jan 20 01:49:10 done poorly its a nightmare. Jan 20 01:53:13 I've done boards that operate at 450mhz in 2 sided that have no problems at all. Jan 20 01:53:41 oh, ok Jan 20 01:55:06 I'm confident that we can do this correctly in 2 layer (and save about $40/board) Jan 20 01:55:50 the real reason for needing 4layer is if we don't have room for adequate traces for Power and Ground. Jan 20 01:59:56 Lennert: when you were poking around in the JTAG chain of the FPGA that you were playing with were you able to just "figure out" what they were doing? Jan 20 02:02:51 ka6sox: the s3? yeah, pretty much. Jan 20 02:03:34 did you have bsdl files? Jan 20 02:03:53 yup Jan 20 02:04:29 how far off were they? Jan 20 02:05:01 it seemed pretty accurate, as far as idcode, opcodes, DR scan chain and IR format goes Jan 20 02:05:14 i did't check _everything_ but the things i did check were very accurate Jan 20 02:09:45 thanks. Jan 20 02:09:57 we had a discussion earlier about BSDL files and accuracy. Jan 20 02:14:14 what part of the bsdl file would be inaccurate? Jan 20 02:14:55 sometimes bit functions are either not explained or marked "reserved" with no explaination. Jan 20 02:15:29 well, ok, but some things you can't describe in the bsdl file anyway Jan 20 02:15:39 true Jan 20 02:15:47 for example, the sp3 bsdl file doesn't explain what the CFG_IN opcode does, you need to look at the application notes for taht Jan 20 02:17:24 okay so a little research and we might be able to "discover" thing that we will need for working with the various targets. Jan 20 02:17:38 s/thing/things Jan 20 02:18:59 time for sleep here...nite all Jan 20 02:19:29 nite **** ENDING LOGGING AT Fri Jan 20 02:59:58 2006