| 00:00.26 | ka6sox | cool |
| 00:17.14 | ka6sox | finished with presentation...next is to make flyers |
| 00:17.57 | ka6sox | and print 250 |
| 00:35.27 | AchiestDragon | ok just ordered some bits ,, and ordered a couple of those connectors , so will have a look at them when they get here , mon or tue |
| 00:40.55 | AchiestDragon | starts doing footprint for the connector |
| 00:44.21 | AchiestDragon | by the way , on the subject of cable prices , i remeber a while back someone moaning over having to pay £6000 for one , they had acidentaly chopped though a ibm mainframe to teminal prossesor cable it was a 500way cable , and all the individual wires inside it where yellow |
| 00:44.47 | AchiestDragon | took 2 weeks to repair the cable for them |
| 00:52.59 | AchiestDragon | what was lucky is repiring the cable managed to get the guys job back who cut though it , but only when the contracters that where filling the hole back up managed to cut through the new one |
| 00:56.05 | ka6sox | ha ha ha |
| 00:57.05 | AchiestDragon | that was back in 1987 so £6000 then would be like 20,000 now |
| 00:59.24 | AchiestDragon | the cable was underground betwen 2 buildings , they did eventualy fit a proper cable duct for it |
| 01:01.59 | AchiestDragon | jcb's and undrground cables dont mix well together |
| 01:03.00 | ka6sox-office | I had a guy wrap up the transmission line feeding a Medium wave station...they hit the cable 5 times with the post hole digger. |
| 01:05.14 | AchiestDragon | remember at a plae i on worked at , there was area in the road where the gas , electric water and phone lines all seemed to cross |
| 01:06.56 | AchiestDragon | first a water leek , 4 weeks of roadworks , becasue they cut the electric, , then a week after the gas , because it got damaged filling it in , then the phone , who broke the water pipe again when filling it back up |
| 01:07.20 | AchiestDragon | in 2 years they dug up that spot 48 times |
| 01:07.48 | ka6sox-office | lol! |
| 01:08.17 | AchiestDragon | i dont know if there still doing it , as i dont work there any more |
| 01:08.39 | AchiestDragon | but it had been going on foryears before i started there also |
| 02:19.54 | *** join/#openjtag ChadP (n=cpage@netblock-68-183-40-90.dslextreme.com) |
| 02:23.00 | *** join/#openjtag ByronT (n=byron-po@nslu2-linux/ByronT) |
| 02:51.40 | AchiestDragon | http://www.whipy.demon.co.uk/pcmcia.pdf |
| 02:52.15 | AchiestDragon | updated conector , it fits pritty well |
| 06:34.10 | *** join/#openjtag toi (n=pleemans@d5152D12D.access.telenet.be) |
| 06:49.58 | *** join/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 07:13.33 | velinp | ~seen lennert |
| 07:13.35 | purl | lennert is currently on #openjtag (7d 23h 39m 29s). Has said a total of 97 messages. Is idling for 15h 22m 36s, last said: 'but i have a bunch of patched lined up already'. |
| 08:14.14 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 08:21.29 | ka6sox | yo? |
| 08:29.07 | ka6sox | guess everyone is sleeping. |
| 14:30.57 | *** join/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 14:46.35 | *** join/#openjtag vmaster_ (i=vmaster@p549B5FE0.dip.t-dialin.net) |
| 14:53.15 | *** join/#openjtag ka6sox-web (i=www-data@limax.nslu2.osuosl.org) |
| 15:00.33 | ka6sox-web | morning |
| 15:00.45 | AchiestDragon | hi |
| 15:01.18 | ka6sox-web | howdy |
| 15:01.28 | ka6sox-web | here at SCALE now |
| 15:01.44 | AchiestDragon | kool |
| 15:02.20 | ka6sox-web | gonna be fun but very busy. |
| 15:02.36 | AchiestDragon | k |
| 15:02.59 | ka6sox-web | I'll be online today from my lappy and will check in ;) |
| 15:03.09 | AchiestDragon | :) |
| 15:04.47 | ka6sox-web | cya after a bit! |
| 15:05.05 | AchiestDragon | k |
| 17:33.33 | lennert | i'm here |
| 18:12.27 | AchiestDragon | question , tms,tck, tdi ,tdo and if used rtck need to run at full speed , but do jtag1,2 and 3 ? and nTRST need clocking at the same rate ?? |
| 18:16.05 | AchiestDragon | and second question are they required to be in sync with the jtag timing , from what i can see from the data these are indipendent lines that are ether in a stable state during jtag opperations or are used to initiate a feature |
| 18:16.41 | vmaster | hmm? |
| 18:16.53 | AchiestDragon | so there state is not likely to be changed half way though a jtag burst read |
| 18:17.01 | vmaster | jtag1, 2, 3? |
| 18:17.28 | AchiestDragon | on the ep1200 board |
| 18:17.41 | AchiestDragon | 1 min |
| 18:18.43 | vmaster | jtag1 is rtck |
| 18:19.09 | AchiestDragon | yes |
| 18:19.20 | vmaster | not sure what 2 and 3 are used for |
| 18:19.39 | vmaster | they're neither specified by jtag nor by arm micros for example |
| 18:20.01 | vmaster | ah, could be that these are dbgrq and dbgack |
| 18:20.07 | AchiestDragon | on the 20 pin arm jtag 2 would be bgreq , and |
| 18:20.08 | vmaster | but this isn't used anywhere |
| 18:20.09 | AchiestDragon | yes |
| 18:20.28 | AchiestDragon | k , but there fitted here |
| 18:20.29 | vmaster | if they're used they're asynchronous |
| 18:21.08 | AchiestDragon | but there use dose not relate to the normal jtag signal streem |
| 18:21.14 | vmaster | no |
| 18:21.24 | AchiestDragon | like nRESET |
| 18:21.27 | vmaster | yep |
| 18:21.42 | AchiestDragon | that is indipendent |
| 18:25.31 | AchiestDragon | if we need to clock thease at the jtag clock rate then s be it , but if there seperate from it its easyer to sort out a jtag speed dubbler in the head |
| 18:33.57 | vmaster | they're independent, and don't have to be clocked at the jtag clock rate |
| 18:35.32 | AchiestDragon | kool,, thats for the arm pinout ,, what about emu0 and emu1 on the ti/tms jtag pinout ? |
| 19:19.16 | *** join/#openjtag beewoolie-afk (n=beewooli@206.124.142.26) |
| 19:19.53 | beewoolie-afk | ka6sox-office: ping? |
| 19:30.36 | AchiestDragon | ka6sox-office: is ... <ka6sox-web> here at SCALE now |
| 19:31.07 | AchiestDragon | may be on for a bit later |
| 20:24.23 | beewoolie-afk | Right. I remember that he was going to that. |
| 20:24.30 | beewoolie-afk | thx. |
| 20:24.46 | beewoolie-afk | AchiestDragon: Are you at SCALE, too? |
| 20:25.08 | AchiestDragon | no |
| 20:25.16 | AchiestDragon | bit far for me |
| 20:25.20 | beewoolie-afk | That's what I thought. |
| 20:25.37 | beewoolie-afk | I was wondering about the way we plan to set the JTAG TCK clock speed. |
| 20:25.57 | beewoolie-afk | In the ATP protocol, I left this somewhat vague since I don't know how best to encode it. |
| 20:26.00 | AchiestDragon | a dds chip |
| 20:26.11 | beewoolie-afk | That's what ka6sox wrote earlier. |
| 20:26.22 | beewoolie-afk | What does that mean for configuration? Do we set it with an integer frequency? |
| 20:26.48 | AchiestDragon | 1 min |
| 20:27.37 | AchiestDragon | the dds provides a frquancy from 0 to 50 mhz |
| 20:27.48 | beewoolie-afk | what is the smallest step? |
| 20:27.52 | AchiestDragon | where multiplying this in the fpga |
| 20:28.11 | AchiestDragon | but its about 1hz or 10hz |
| 20:28.39 | beewoolie-afk | so we could let the config set the frequency in Hz and round down to the closest acceptable value. |
| 20:28.41 | AchiestDragon | the frequancy is set by sending it setup inof on a spi |
| 20:28.56 | beewoolie-afk | OK. I'm looking to solidify the protocol. |
| 20:29.23 | beewoolie-afk | It looks like a 32 bit number carrying the frequency will be the most appropriate. |
| 20:29.24 | AchiestDragon | AD9834 chip from analog devices |
| 20:31.19 | AchiestDragon | the chip needs 28 bits |
| 20:32.03 | AchiestDragon | and its 0 to 25mhz output with a .2hz step |
| 20:32.26 | AchiestDragon | more than adiquate |
| 20:34.13 | beewoolie-afk | That isn't the question. |
| 20:34.29 | beewoolie-afk | If we are going to set a protocol element for this, we need to make sure that it makes sense. |
| 20:35.54 | beewoolie-afk | It looks like we can let it be a frequency. A 32 bit number is sufficient although we won't be able to reach the slowest frequency. |
| 20:36.35 | beewoolie-afk | I think we can be OK with 1Hz as the slowest, but we could allow for four bits of a fraction. |
| 20:36.48 | beewoolie-afk | That would give us a 268MHz peak frequency. |
| 20:37.35 | AchiestDragon | k ,, the freq that isset by the dds is fraction of the actual feq anyway |
| 20:37.56 | beewoolie-afk | Right. But again, that isn't the issue. |
| 20:38.06 | beewoolie-afk | It doesn't matter how it's implemented. |
| 20:38.12 | AchiestDragon | as we have programable multiplication of the frequancy *2 , *4 or *8 |
| 20:38.19 | beewoolie-afk | what I'm talking about is what the user can set as the frequency. |
| 20:38.36 | beewoolie-afk | It is somewhat arbitrary, but we do want to make a reasonablechoice. |
| 20:39.06 | beewoolie-afk | There are two constraints. It is not good if our encoding prevents users from setting useful frequencies. |
| 20:39.11 | AchiestDragon | then maybe better to have it store the frequancy in xxx.xxx Mhz |
| 20:39.14 | beewoolie-afk | We're unlikely to make this choice. |
| 20:39.37 | beewoolie-afk | What if the user wants to set a 10Hz JTAG clock? |
| 20:39.52 | AchiestDragon | there is no need for a fine scale than that |
| 20:39.57 | AchiestDragon | that slow / |
| 20:39.59 | beewoolie-afk | The question is not so much how it is implemented but what range of frequencies do we want to offer. |
| 20:39.59 | AchiestDragon | ? |
| 20:40.12 | beewoolie-afk | So, the slowest is 1KHz. |
| 20:40.28 | AchiestDragon | that should be fine |
| 20:41.02 | beewoolie-afk | The we can get away with a 16 bit count of KHz for the frequency. |
| 20:41.05 | AchiestDragon | the top beeing 999Mhz is over what we can do atm , but in 5 years who knows |
| 20:41.21 | beewoolie-afk | It isn't BCD. It's binary. |
| 20:41.29 | AchiestDragon | yes |
| 20:41.29 | beewoolie-afk | So, the limit would be 65MHz. |
| 20:41.42 | beewoolie-afk | Which matches the design. |
| 20:41.51 | AchiestDragon | were looking at 300mhz |
| 20:42.05 | AchiestDragon | as the system speed not the osc speed |
| 20:42.17 | beewoolie-afk | the user only cares about the TCK speed. |
| 20:42.35 | AchiestDragon | yes a 300mhz tck |
| 20:43.14 | beewoolie-afk | OK. Then maybe it should be a 16 bit count of 10KHz. That's 655 MHz |
| 20:43.54 | AchiestDragon | k kool , |
| 20:43.58 | beewoolie-afk | THX |
| 20:44.16 | beewoolie-afk | I may bring it down to a count of 5KHz so that we can reach a little lower. |
| 20:45.05 | AchiestDragon | think in the future higher may be better ,,, |
| 20:45.18 | beewoolie-afk | But this design isn't going to go faster than that. |
| 20:45.40 | beewoolie-afk | The idea is to make the protocol stable for this design. |
| 20:45.53 | beewoolie-afk | Modifying it for a different encoding is reasonable in a different design. |
| 20:46.20 | beewoolie-afk | Heck, I suppose we could just go for a 32 bit number and forget about it. |
| 20:46.25 | AchiestDragon | the head is the limiting factor atm because the chips we can get limit that to 375mhz top , but the rest could drive the head to 600 if the head couldrun at that |
| 20:46.26 | beewoolie-afk | It's not like we're saving anything. |
| 20:47.03 | AchiestDragon | so in 1 or 2 years when there are faster chips it could do that |
| 20:47.29 | beewoolie-afk | OK. I'll just leave it at a simple 32 bit frequency. That gives us plenty of room for faster designs. 4.2 GHz. |
| 20:49.13 | AchiestDragon | looking at the specs of some of the cpu's there jtag is 1/16th of the cpu clock so a 4.7Ghz cpu can have a 293.75Mhz tclk |
| 20:50.15 | AchiestDragon | when they get a 9.4hz cpu thats 587.5Mhz ,, possabaly 2 to 4 years away |
| 20:50.32 | beewoolie-afk | This can be a tough call. using a 32 bit number is probably over the top, but it does make it clear. Alternatively, we could encode the frequency in a field saving room for expansion without requring a change to the protocol. |
| 20:50.48 | beewoolie-afk | I think there is a good reason we haven't gotten CPUs that fast. |
| 20:51.03 | beewoolie-afk | I've read that they aren't planning to go that fast. It's cheaper to put in more cores. |
| 20:51.30 | beewoolie-afk | CPU clock frequencies have been kinda static for some years. |
| 20:51.41 | AchiestDragon | maybe ,but 4.7Ghz is already avalable on some , its the intel chipset that has maxed out |
| 20:52.02 | AchiestDragon | the die size for it is its limit |
| 20:52.03 | beewoolie-afk | I'm OK using a 32 bit frequency value. |
| 20:52.24 | beewoolie-afk | We aren't likely to encounter problems and we don't need to conserve two bytes. |
| 20:53.20 | AchiestDragon | that should allow for a 0 to 4.2G range at 1hz steps yes |
| 20:53.38 | beewoolie-afk | Zero is reserved for adaptive clocking. |
| 20:54.22 | AchiestDragon | yes , and there nees to be a upper an lower limit |
| 20:55.07 | AchiestDragon | defineable somewhare as a constant or varible , dependent on the hardware |
| 20:55.31 | beewoolie-afk | That is another issue. |
| 20:55.44 | beewoolie-afk | There are a couple of ways of handling this. |
| 20:56.00 | beewoolie-afk | We can implement a query function so that the host can find out what frequencies are available. |
| 20:56.14 | AchiestDragon | im looking at trying to auto detect the head atached also somehow |
| 20:56.16 | beewoolie-afk | Or, we can simple round down when we get a very high frequency. |
| 20:56.41 | beewoolie-afk | I'm not worried about this ATM. It doesn't have to affect the protocol. |
| 20:57.08 | AchiestDragon | true , that can be sorted in the aplication |
| 20:57.39 | beewoolie-afk | The BSDL files define limits on TCK. |
| 20:58.22 | AchiestDragon | and if over the system speed then the system just runs as fast as it can |
| 20:58.45 | beewoolie-afk | Indeed. |
| 21:08.12 | *** join/#openjtag ulf_k (n=ulf_kypk@p54BDC3B1.dip0.t-ipconnect.de) |
| 22:31.58 | *** join/#openjtag bullet (n=bullet@64.21.79.83.cust.bluewin.ch) |
| 22:43.15 | [g2] | hey beewoolie-afk |