**** BEGIN LOGGING AT Mon Feb 13 10:59:56 2006
Feb 13 22:42:27 <[g2]> bb in several hours
Feb 13 22:43:55 <ka6sox-office> ba ba!
Feb 13 22:45:57 <beewoolie-afk> ka6sox-office: I've updated the protocol somewhat and I'm curious if it looks to be implementable.
Feb 13 22:46:10 <ka6sox-office> is it on the wiki?
Feb 13 22:46:13 <beewoolie-afk> Yeah.
Feb 13 22:46:17 <ka6sox-office> cool
Feb 13 22:46:19 <ka6sox-office> I'll look
Feb 13 22:46:35 <beewoolie-afk> I changed the clock setup and have tweaked the bulkio.
Feb 13 22:46:55 <ka6sox-office> k
Feb 13 22:47:23 <beewoolie-afk> I've implemented an interpreter for the simple parallel port adapters.
Feb 13 22:47:29 <ka6sox-office> k
Feb 13 22:47:32 <beewoolie-afk> And I'm working on it for the FTDI.
Feb 13 22:47:49 <ka6sox-office> sounds good.
Feb 14 00:39:25 <beewoolie-afk> Argh.  It seems that the FTDI protocol has some annoying inefficiencies.
Feb 14 03:28:32 <[g2]> hey beewoolie-afk 
Feb 14 03:28:42 <beewoolie-afk> [g2]: hey
Feb 14 03:28:54 <beewoolie-afk> What's new?
Feb 14 03:29:04 <[g2]> oh lots of stuff
Feb 14 03:29:41 <[g2]> I got a pointer to setting up dnsmasq for multiple LANs today
Feb 14 03:29:54 <beewoolie-afk> Hey, that's nice.
Feb 14 03:30:08 <[g2]> so now it hands out DHCPs for LAN and WAN for the the wifi
Feb 14 03:30:16 <[g2]> s/WAN/WLAN/
Feb 14 03:30:17 <purl> [g2] meant: so now it hands out DHCPs for LAN and WLAN for the the wifi
Feb 14 03:30:59 <beewoolie-afk> Very nice.
Feb 14 03:31:04 <[g2]> I heard openssh is going to support VPNs
Feb 14 03:31:19 <beewoolie-afk> That would be handy, too.
Feb 14 03:31:27 <beewoolie-afk> There is that project called...hamachi?  I think
Feb 14 03:31:37 <beewoolie-afk> Is it the same idea?
Feb 14 03:31:42 <[g2]> so I'll just put wep on there and then OpenSSH VPN over the wifi and be done with it
Feb 14 03:31:55 <[g2]> too many open-sourcers! :)
Feb 14 03:32:10 <beewoolie-afk> open-sorcerers
Feb 14 03:32:20 <[g2]> those too!
Feb 14 03:33:31 <[g2]> how the JTAG'ing going ?
Feb 14 03:33:39 <beewoolie-afk> Really well.
Feb 14 03:33:51 <beewoolie-afk> I've recoded everything to use ATP.
Feb 14 03:33:52 <[g2]> that doesn't surprise me
Feb 14 03:33:57 <[g2]> You're working on it :)
Feb 14 03:34:02 <beewoolie-afk> Now, the parallel port driver is just an interpreter for ATP.
Feb 14 03:34:16 <beewoolie-afk> I'm adding support for the FTDI right now.
Feb 14 03:34:19 <[g2]> cool
Feb 14 03:34:20 <beewoolie-afk> It's starting to work.
Feb 14 03:34:35 <[g2]> that's the digilent adapter right ?
Feb 14 03:34:38 <beewoolie-afk> I'll add a driver for the GW hardware as well.
Feb 14 03:34:39 <beewoolie-afk> Right.
Feb 14 03:34:46 <beewoolie-afk> The parallel adapters are both Xilinx compatible.
Feb 14 03:35:00 <beewoolie-afk> The FTDI is the first one I've tackled that has SRST support.
Feb 14 03:35:13 <beewoolie-afk> It is looking really good.
Feb 14 03:35:33 <beewoolie-afk> Once we have hardware that uses ATP, we can simply pass the codes along to the hardware and be done with it.
Feb 14 03:35:37 <[g2]> I'm wondering if I can JTAG my RV042 with the parallel
Feb 14 03:35:57 <beewoolie-afk> There shouldn't be any issues.
Feb 14 03:36:16 <beewoolie-afk> The openwince code should tell you if it is present.
Feb 14 03:40:10 <ka6sox> beewoolie-afk, hi there
Feb 14 03:40:14 <beewoolie-afk> ka6sox: hey
Feb 14 03:40:32 <ka6sox> just now getting time to start reading...which areas did you change?
Feb 14 03:41:04 <beewoolie-afk> The frequency setup mainly.
Feb 14 03:41:26 <beewoolie-afk> There are a lot of subtlties to the protocol, so it isn't easy to tell you where to focus.
Feb 14 03:41:37 <ka6sox> did you know that we put a DDS circuit on the board so we have frequency resolution of 2hz
Feb 14 03:41:54 <beewoolie-afk> Yeah.  I talked with AchiestDragon about that.
Feb 14 03:42:25 <AchiestDragon> on the hat board not the aztag
Feb 14 03:42:36 <ka6sox> I hope on the AZTAG too!
Feb 14 03:42:36 <ka6sox> :)
Feb 14 03:42:40 <beewoolie-afk> I could optimize that opcode for a 16 bit field, for example a count of 10s of Hz, but AD wasn't willing to let go of the fact that we might go as high as 600MHz
Feb 14 03:43:03 <beewoolie-afk> It was easier to let the opcode be a simple frequency.
Feb 14 03:43:06 <ka6sox> there are issues with going that high.
Feb 14 03:43:17 <beewoolie-afk> well, what is the upper bound?
Feb 14 03:43:26 <ka6sox> like the cable alone is a fifo of 2 samples.
Feb 14 03:43:45 <beewoolie-afk> Interesting way to put it.
Feb 14 03:44:06 <beewoolie-afk> I'd be fine setting the limit lower.
Feb 14 03:44:34 <ka6sox> at this point it would be safe to say: its only software (the old DSP mantra)
Feb 14 03:44:44 <beewoolie-afk> For example, we could make it a count of KHz.  The range would be 1KHz to 655MHz.
Feb 14 03:44:44 <AchiestDragon> 300mhz is what  i am aiming for 
Feb 14 03:45:01 <ka6sox> AchiestDragon, I agree with the 300mhz number
Feb 14 03:45:18 <beewoolie-afk> OK. Then I'm going to scale the opcode back to a 16 bit field.
Feb 14 03:45:32 <beewoolie-afk> It will have a lower bound of 1KHz.
Feb 14 03:45:47 <beewoolie-afk> And I'll reserve a zero value for adaptive clocking, if we ever get there.
Feb 14 03:46:02 <beewoolie-afk> ka6sox: The other issue is whether you are comfortable with the way that the bulk IO works.
Feb 14 03:46:40 <beewoolie-afk> I believe it is better than the encoding used by the FTDI.  It is orthogonal and it has a couple of features that are handy.
Feb 14 03:46:51 <ka6sox> lemme look in that area as we need to be able to deal with large quantities of data to sift thru to find patterns.
Feb 14 03:47:02 <ka6sox> k
Feb 14 03:47:07 <beewoolie-afk> There is also the piece about seeking states.
Feb 14 03:47:20 <ka6sox> k
Feb 14 03:47:25 <beewoolie-afk> I've discovered that there is a shortcut that can be taken in the implementation.
Feb 14 03:47:38 <beewoolie-afk> I've done this for the parallel port interpreter.
Feb 14 03:48:10 <beewoolie-afk> Simply put, given a start state and an end state, we can statically determine an optimal path through the FSM in five or fewer steps.
Feb 14 03:48:18 * [g2] tries to scan the dsm-g600
Feb 14 03:48:23 <[g2]> bbiab
Feb 14 03:48:57 <beewoolie-afk> It can be a table lookup where the table entries are a count and a value which is passed to the TMS opcode
Feb 14 03:49:09 <beewoolie-afk> I just want to make sure you're comfortable with the way it works.
Feb 14 03:49:18 <ka6sox> bbiab (dinner is on the table)
Feb 14 03:49:26 <ka6sox> 32bit CRC
Feb 14 03:49:28 <beewoolie-afk> k
Feb 14 03:49:34 <ka6sox> not 16bit...too weak
Feb 14 03:49:44 <ka6sox> we can do it in hardware
Feb 14 03:49:45 <beewoolie-afk> That's what I was thinking, too.
Feb 14 03:49:47 <beewoolie-afk> right.
Feb 14 03:49:52 <beewoolie-afk> I'll change that as well.
Feb 14 04:05:00 <ka6sox> Delay is expressed in units of time in one case and clock cycles in another case...needs to be expressed in clocks I think.
Feb 14 04:05:18 <beewoolie-afk> ka6sox: Dined already?
Feb 14 04:05:21 <ka6sox> yes.
Feb 14 04:05:24 <beewoolie-afk> That is on purpose.
Feb 14 04:05:43 <ka6sox> the FPGA is not good at doing time calcs
Feb 14 04:05:45 <beewoolie-afk> It is better from the perspective of the user to be able to specify different kinds of time.
Feb 14 04:05:58 <beewoolie-afk> Really?
Feb 14 04:06:02 <ka6sox> yes
Feb 14 04:06:07 <beewoolie-afk> Isn't is just a multiple of the clock?
Feb 14 04:06:37 <beewoolie-afk> So, is this about the fact that it isn't good at multiplication?
Feb 14 04:06:39 <ka6sox> it means we have to have a clock reference register (telling it what clock frequency is)
Feb 14 04:06:46 <beewoolie-afk> yeah.
Feb 14 04:06:47 <ka6sox> ya
Feb 14 04:07:05 <beewoolie-afk> Is it the reference register that's a problem, or the multiply?
Feb 14 04:07:13 <ka6sox> multiply
Feb 14 04:07:21 <beewoolie-afk> OK.  I'll change it.
Feb 14 04:07:27 <ka6sox> (that building block is a HUGE thing)
Feb 14 04:07:34 <beewoolie-afk> :-)
Feb 14 04:07:52 <ka6sox> adders are good.
Feb 14 04:08:13 <beewoolie-afk> One problem may be the range.
Feb 14 04:08:24 <ka6sox> and it is fairly good at 2^X
Feb 14 04:08:57 <beewoolie-afk> It'll be fine it we allow the delay to be a 32 bit count of clocks.
Feb 14 04:09:06 <beewoolie-afk> Or, something similar.
Feb 14 04:09:18 <beewoolie-afk> I'll have to do some fiddling.
Feb 14 04:09:34 <beewoolie-afk> I'd like to allow for clock frequencies that are very low.
Feb 14 04:09:37 <beewoolie-afk> As low as 1Hz.
Feb 14 04:09:44 <beewoolie-afk> It's handy for certain kinds of testings.
Feb 14 04:09:58 <beewoolie-afk> Are you OK with that?
Feb 14 04:10:15 <ka6sox> okay shift registers could give us resolution down to 1hz
Feb 14 04:10:16 <beewoolie-afk> I'd encode it with a bit.  0 is low-speed range and 1 is high-speed range.
Feb 14 04:10:20 <beewoolie-afk> Yeah.
Feb 14 04:10:34 <ka6sox> the DDS can give us frequencies that are very low.
Feb 14 04:10:37 <beewoolie-afk> Well, 2 Hz is OK as well, but I'd let the protocol encode to 1Hz.
Feb 14 04:10:52 <beewoolie-afk> I don't mean to specify the lowest possible frequency.
Feb 14 04:11:05 <ka6sox> the DDS can go as low as 1hz
Feb 14 04:11:06 <beewoolie-afk> it's more about allowing that the lowest frequency *not* be 100KHz.
Feb 14 04:11:10 <beewoolie-afk> K.
Feb 14 04:12:23 <ka6sox> AchiestDragon, I think that the reference clock should be 40mhz so that I can get 260mhz internal clocking on the FPGA
Feb 14 04:13:53 <AchiestDragon> np , the same xtal osc module should be available in 25 , 40, 50 or  80 mhz maybe more 
Feb 14 04:14:45 <AchiestDragon> 33mhz and 66mhz seem to be other values 
Feb 14 04:14:53 <[g2]> what mode should my  parallel port be in ?
Feb 14 04:15:04 <beewoolie-afk> [g2]: for openwince?
Feb 14 04:15:07 <[g2]> nod
Feb 14 04:15:22 <beewoolie-afk> [g2]: I have been using SPP.  I suspect that I could use other modes, but I've not tried.
Feb 14 04:15:57 <[g2]> Ok I've got bi-directional, EPP and ECP
Feb 14 04:16:15 <beewoolie-afk> Hmm.  No non-bidirectional mode?
Feb 14 04:16:28 <[g2]> output only ?
Feb 14 04:16:44 <beewoolie-afk> That would be it.
Feb 14 04:17:00 <[g2]> ok THX, I'll try
Feb 14 04:24:16 <AchiestDragon> well been desoldering some components tonight  http://www.whipy.demon.co.uk/bits.jpg
Feb 14 04:24:39 <AchiestDragon> been trying an easy way  
Feb 14 04:25:32 <ka6sox> beewoolie-afk, one mode I want is a "bulk programmer" mode that looks at the RAM memory on the aztag card and uses that to program a flash memory.
Feb 14 04:25:43 <ka6sox> (the data)
Feb 14 04:25:46 <beewoolie-afk> Can you be more specific?
Feb 14 04:25:59 <beewoolie-afk> Are you talking about having a buffer on the card?
Feb 14 04:26:11 <ka6sox> yes 64MB of RAM
Feb 14 04:26:25 <AchiestDragon> cook for 5 mins at about 200c in toaster overn , remove board , turn it upside down and tap 
Feb 14 04:26:39 <beewoolie-afk> Keep in mind that this protocol doesn't have any sort of knowledge of FLASH memory.
Feb 14 04:26:56 <beewoolie-afk> So, in order to do something like that, we need to specify how that memory shall be used.
Feb 14 04:27:21 <beewoolie-afk> So far, all I've tackled is basic JTAG operations.
Feb 14 04:27:50 <beewoolie-afk> Meta-operations such as 'program my flash you heap of junk' haven't come to bear.
Feb 14 04:27:51 <ka6sox> k
Feb 14 04:28:12 <ka6sox> k
Feb 14 04:28:13 <beewoolie-afk> One reason for the version number is that it makes it easy to extend the instruction set.
Feb 14 04:28:23 <beewoolie-afk> I, too, would like a bulk programming mode.
Feb 14 04:28:42 <beewoolie-afk> So far, I haven't *quite* gotten how that can be done uniformly.
Feb 14 04:29:06 <ka6sox> I like the look of the bulk IO stuff...it makes sense (but keep MSB mode)
Feb 14 04:29:06 <AchiestDragon> using the aztag as a serial programmer should be possible ,but data rate and handshaking needs to be soted in the fpga it would need to use apropriate inputs or outputs that are right for the buffer arangment 
Feb 14 04:29:09 <beewoolie-afk> Presently, I have code that can take a BSDL file and with a little extra data, it can perform flash write operations.
Feb 14 04:29:16 <ka6sox> bbiaw..I need to get food for the week.
Feb 14 04:29:19 <beewoolie-afk> Right.
Feb 14 04:29:22 <beewoolie-afk> lol
Feb 14 04:29:43 <AchiestDragon> and would probabaly need a connector adaptor cable making for it 
Feb 14 04:29:50 <beewoolie-afk> AchiestDragon: That's where I haven't, yet, come to an encoding for the protocol to do that.
Feb 14 04:30:39 <beewoolie-afk> So far, it looks like flash devices are similar in the way that IO is handled, but there seem to be some places where it gets really crazy.
Feb 14 04:30:53 <beewoolie-afk> The jflash utility, for example, has to swizzle the bits to get them in the right places.
Feb 14 04:31:32 <AchiestDragon> you have 4 output lines and 4 input lines to play with , there use for jtag is defined ,but could have a diferent use if needed for other things 
Feb 14 04:31:49 <beewoolie-afk> I'm not sure I understand what you are talking about.
Feb 14 04:32:15 <beewoolie-afk> We can do the programming through the TAP, but we don't yet know how to do this in a general way.
Feb 14 04:33:06 <AchiestDragon> ha  jtag programming ,, i was thinking of spi or i2c  type programming 
Feb 14 04:34:34 <beewoolie-afk> Ah.  That would be yet another mode.
Feb 14 04:34:38 <beewoolie-afk> We could do that as well.
Feb 14 04:34:46 <AchiestDragon> yes
Feb 14 04:34:47 <beewoolie-afk> Clearly.
Feb 14 04:36:52 <AchiestDragon> the hat (with yet another adaptor ) could support parallel boot mode programming of a fpga , but not planning on implimenting the adaptor for that
Feb 14 04:39:53 <AchiestDragon> so could be tricked into performing programming of parallel flash boot devices 
Feb 14 04:40:22 <beewoolie-afk> I don't think I know what parallel flash boot devices are.
Feb 14 04:41:16 <AchiestDragon> flash rom that is not serial but parallel , 8 or 16 bits wide data 
Feb 14 04:43:12 <beewoolie-afk> Ah.  That's the kind of flash programming I'm talking about.  I *think* that's what ka6sox is interested in doing as well.
Feb 14 04:43:29 <ka6sox> beewoolie-afk, AchiestDragon yes that is what I'm talking about!
Feb 14 04:44:23 <beewoolie-afk> What is this part about 'tricking' it into performing flash programming?
Feb 14 04:45:02 <AchiestDragon> now not shure if the parallel devices are serial programable 
Feb 14 04:45:03 <ka6sox> are our chains only 1 device long or are we working on multiple devices?
Feb 14 04:45:20 <beewoolie-afk> ka6sox: The protocol doesn't care about the lengths of the chains.
Feb 14 04:45:48 <ka6sox> AchiestDragon, what you do is manipulate the memory and data pins and program the flash that way.
Feb 14 04:45:52 <beewoolie-afk> I'm only working with one device at the moment, but I'd like to make sure this works with multiple cores.
Feb 14 04:46:03 <beewoolie-afk> ka6sox: That's what I've been doing.
Feb 14 04:46:07 <ka6sox> s/memory/adddress
Feb 14 04:46:44 <beewoolie-afk> ka6sox: I believe we can get better performance from the CPU specific methods when a CPU is present.
Feb 14 04:46:49 <ka6sox> beewoolie-afk, okay so we are looking to implement dummy chains to be able to target a specific device in the chain and ignor the other ones.
Feb 14 04:46:51 <AchiestDragon> st , intel and amd do flash chips the programming modes are discribed in there data sheets 
Feb 14 04:47:10 <beewoolie-afk> If we're talking about optimizing the scan-chain method, then we may need to go down another path, as well.
Feb 14 04:47:26 <beewoolie-afk> ka6sox: I don't know what you mean by a dummy chain.
Feb 14 04:47:48 <beewoolie-afk> As far as I can tell, when there is more than one device, we put the uninteresting devices in BYPASS mode.
Feb 14 04:47:58 <beewoolie-afk> That makes their scan chains 1 bit long.
Feb 14 04:48:10 <ka6sox> k
Feb 14 04:48:29 <ka6sox> forgot about that one...been a while since I read the spec.
Feb 14 04:48:33 <beewoolie-afk> BYPASS mode happens to be an instruction of all 1's.
Feb 14 04:49:15 <beewoolie-afk> As for optimizing the boundary-scan chains, we could do as was suggested in defining a virtual scan register.
Feb 14 04:49:22 <beewoolie-afk> I commented on this on the wiki.
Feb 14 04:49:30 <ka6sox> beewoolie-afk, nod
Feb 14 04:50:32 <beewoolie-afk> If we allow the user to define a hold register and then we give him a way to update portions of that register quickly, we can improve the scan time.
Feb 14 04:51:03 <beewoolie-afk> The harder part is letting the FPGA know which signals are used for OE, WE, and whether or not these signals are active low.
Feb 14 04:51:35 <beewoolie-afk> Then, we need to describe the organization of the flash.
Feb 14 04:51:51 <beewoolie-afk> Sometimes we have one 16 bit device.  Sometimes we have two 16 bit devices.
Feb 14 04:52:01 <beewoolie-afk> Sometimes we have one thirty-two bit device.
Feb 14 04:52:09 <ka6sox> I know that we have been resisting the temptation to "customize" the fpga
Feb 14 04:52:13 <beewoolie-afk> The programming is different in all of these cases.
Feb 14 04:52:32 <ka6sox> yes
Feb 14 04:52:37 <beewoolie-afk> Yeah.  If I could come up with a good way to describe this that is general purpose enough, I'd be all over it.
Feb 14 04:52:52 <beewoolie-afk> So, I'd like to start with something simple that we know will be useful.
Feb 14 04:52:58 <ka6sox> k
Feb 14 04:53:08 <beewoolie-afk> We can enhance later when we have the hardware working.
Feb 14 04:53:19 <ka6sox> we have to do "discovery" first anyways.
Feb 14 04:53:25 <ka6sox> even if we know what is out there.
Feb 14 04:53:26 <beewoolie-afk> Sure.
Feb 14 04:53:37 <beewoolie-afk> That's what my code is doing right now.
Feb 14 04:53:48 <ka6sox> k
Feb 14 04:53:56 <beewoolie-afk> I only tell it how the address and data bus map to the BSDL cells.
Feb 14 04:54:09 <beewoolie-afk> The rest is handled algorithmically.
Feb 14 04:54:26 <ka6sox> we have RAM memory out there that we can use for discription registers.
Feb 14 04:55:32 <AchiestDragon> seams to remeber the flash have a readable divice discription regiser 
Feb 14 04:55:42 <beewoolie-afk> AchiestDragon: right.
Feb 14 04:55:56 <beewoolie-afk> But you have to know the organization before you can read it.
Feb 14 04:56:01 <beewoolie-afk> Bit of a catch-22.
Feb 14 04:56:28 <beewoolie-afk> What we do write the ID command in different ways and then probe for the ID data in a known pattern.
Feb 14 04:57:09 <ka6sox> beewoolie-afk, if we are working boards they *have* the covers off..and we can see what devices we have.
Feb 14 04:57:27 <beewoolie-afk> ka6sox: That get you most of the way there.
Feb 14 04:57:35 <ka6sox> so we can then write the organization table
Feb 14 04:57:35 <beewoolie-afk> Here's how I look at it.
Feb 14 04:58:04 <beewoolie-afk> It would be great if we could start with what is easy to identify and let the hw and sw probe for what it does well.
Feb 14 04:58:14 <[g2]> I dunno
Feb 14 04:58:18 <beewoolie-afk> This probing can be done efficiently 
Feb 14 04:58:38 <beewoolie-afk> Then, we download something to the FPGA telling it how the flash is organizaed along with the data to program
Feb 14 04:58:39 <[g2]> jtag detects the digilent board but not the XScales
Feb 14 04:58:45 <beewoolie-afk> Then we say GO!
Feb 14 04:58:57 <ka6sox> beewoolie-afk, exactly
Feb 14 04:59:01 <beewoolie-afk> [g2]: I'm able to detect the Xscales with the dilligent
Feb 14 04:59:15 <beewoolie-afk> It isn't the adapter that's the problem.
Feb 14 04:59:27 <[g2]> heh
Feb 14 04:59:39 <beewoolie-afk> ka6sox: The point is that we don't yet have a complete picture of the parameters.
Feb 14 04:59:50 <beewoolie-afk> Or, better put, *I* don't.
Feb 14 04:59:52 <ka6sox> agreed
Feb 14 04:59:58 <ka6sox> *I* don't either
Feb 14 05:00:02 <beewoolie-afk> Once we know how to describe this, the rest is easy.
Feb 14 05:00:05 <beewoolie-afk> Right.
Feb 14 05:00:08 <[g2]> beewoolie-afk do you have a pull-up/down somewhere ?
Feb 14 05:00:18 <ka6sox> but we are planning on making the FPGA re-programmable on the fly.
Feb 14 05:00:32 <beewoolie-afk> and the reason I'm working on this jtag code is so that we can explore the possibilities
Feb 14 05:00:35 <beewoolie-afk> ka6sox: Right!
Feb 14 05:00:44 <beewoolie-afk> I'm counting on it.
Feb 14 05:00:49 <beewoolie-afk> [g2]: Nothing special.
Feb 14 05:00:50 <[g2]> or do you drive nReset or nTSRT
Feb 14 05:00:58 <ka6sox> meaning *if* we know what we are dealing with we can "personalizing" the FPGA to optimize performance.
Feb 14 05:01:04 <beewoolie-afk> [g2]: Neither
Feb 14 05:01:12 <beewoolie-afk> ka6sox: Sure.
Feb 14 05:01:28 <ka6sox> okay so first blush is find out what is there and define the chain and targets.
Feb 14 05:01:30 <beewoolie-afk> Honestly, I think we're going to get the best performance form custom CPU drivers.
Feb 14 05:01:41 <beewoolie-afk> s/form/from/
Feb 14 05:01:42 <purl> beewoolie-afk meant: Honestly, I think we're going to get the best perfromance form custom CPU drivers.
Feb 14 05:01:45 <ka6sox> like the i=cache in xscale.
Feb 14 05:01:58 <beewoolie-afk> tee hee
Feb 14 05:02:02 <beewoolie-afk> ka6sox: Exactly.
Feb 14 05:02:17 <beewoolie-afk> It isn't really hard to do once we have the right JTAG hw.
Feb 14 05:02:35 <ka6sox> yep
Feb 14 05:02:47 <beewoolie-afk> [g2]: I've used your cable to detect the XScale without trouble.
Feb 14 05:02:49 <ka6sox> okay I like the changes to the protocol.
Feb 14 05:03:04 <beewoolie-afk> I've done quite a few since we talked. I'll post them later this evening.
Feb 14 05:03:26 <[g2]> beewoolie-afk and you just power-up the device and do "detect" after the "cable" command right ?
Feb 14 05:03:38 <beewoolie-afk> Oh, I don't use openwince at all.
Feb 14 05:03:45 <beewoolie-afk> My code has no problem detecting the device.
Feb 14 05:04:00 <beewoolie-afk> I don't recall whether or not openwince does.
Feb 14 05:04:15 <[g2]> ah
Feb 14 05:04:32 <[g2]> would I be able to try that out sometime ? :)
Feb 14 05:04:35 <beewoolie-afk> ka6sox: I've made the delay this way: (count+1)*2^(8*s) where count is 1-256 and s is 0-3.
Feb 14 05:04:41 <beewoolie-afk> [g2]: RSN.
Feb 14 05:04:52 <ka6sox> beewoolie-afk, re: non-compliant devices, we need to be able to deal with them. *If* the hardware has a known issue then we deal with it.
Feb 14 05:05:06 <ka6sox> beewoolie-afk, nod on DELAY
Feb 14 05:05:08 <beewoolie-afk> ka6sox: That's something that I've been thinking about.
Feb 14 05:05:18 <beewoolie-afk> It really depends on the range of non-compliance.
Feb 14 05:05:24 <ka6sox> true
Feb 14 05:05:47 <beewoolie-afk> For example, the Sharp LH79520 changes the value of TDO on the rising clock instead of the falling clock.
Feb 14 05:05:57 <beewoolie-afk> That makes it 1/2 cycle late on sending out the data.
Feb 14 05:06:16 <beewoolie-afk> The work-around is to not use the external test scan chain.
Feb 14 05:06:37 <beewoolie-afk> Now, we could allow for this sort of craziness, but I'm not sure that we could ever account for all of them.
Feb 14 05:06:45 <beewoolie-afk> After all, a standard is a standard.
Feb 14 05:07:02 <beewoolie-afk> So, I added the transact opcode as a worst case catch-all.
Feb 14 05:07:09 <ka6sox> that particular one we hope is a standalone device on the chain.
Feb 14 05:07:10 <beewoolie-afk> It allows us to do anything we can imagine.
Feb 14 05:07:23 <ka6sox> "its only VHDL"
Feb 14 05:07:33 <ka6sox> we can deal with that kind of craziness.
Feb 14 05:07:36 <beewoolie-afk> Sure.  And the LH79520 can be programmed with the ARMv4 embedded ice hardware.
Feb 14 05:07:54 <ka6sox> there you have it.
Feb 14 05:07:55 <beewoolie-afk> The trouble is that TRANSACT isn't very efficient.
Feb 14 05:08:11 <beewoolie-afk> It allows us to do anything, but the penalty is performance.
Feb 14 05:08:30 <beewoolie-afk> IMHO, it is an adequate catch-all.
Feb 14 05:08:48 <beewoolie-afk> We *can* claim that we can work with anything, no matter how broken.
Feb 14 05:08:56 <ka6sox> remember during the "detect" phase we are looking to figure out what we have..*then* download the personality to deal with what we find.
Feb 14 05:09:21 <beewoolie-afk> ka6sox: Please note.  This is exactly the reason that I haven't gotten to the point of specifying this custome personality stuff.
Feb 14 05:09:36 <ka6sox> nod
Feb 14 05:09:42 <beewoolie-afk> ka6sox: Sure.  But even with the custom personality, it would be good to have a standard protocol interface.
Feb 14 05:09:50 <ka6sox> yes
Feb 14 05:09:51 <beewoolie-afk> In other words, we download a library of functions.
Feb 14 05:09:58 <ka6sox> nod
Feb 14 05:10:06 <beewoolie-afk> :-)
Feb 14 05:10:36 <beewoolie-afk> There is quite a bit of room in the standard opcode space.  And we can extend with a version number on the transaction header.
Feb 14 05:10:45 <ka6sox> k
Feb 14 05:13:06 <beewoolie-afk> ka6sox: I updated the wiki for ATP.
Feb 14 05:13:16 <beewoolie-afk> You can use the history feature to see the diff.
Feb 14 05:13:27 <ka6sox> ya
Feb 14 05:15:10 <ka6sox> back to hacking on katie.
Feb 14 05:15:24 <ka6sox> (or at least trying to figure it out)
Feb 14 05:15:53 <AchiestDragon> bed for me , nn 
Feb 14 05:16:29 <beewoolie-afk> NN
Feb 14 05:18:10 <ka6sox> beewoolie-afk, nite
Feb 14 05:27:10 <[g2]> nite AchiestDragon 
Feb 14 05:28:07 <ka6sox> nite AchiestDragon 
Feb 14 05:28:19 * ka6sox misread who was padding off to bed.
Feb 14 05:32:28 <ka6sox> [g2], you on west coast time these days?
Feb 14 06:07:56 <[g2]> ka6sox nah... just a little busy
Feb 14 06:11:14 <beewoolie-afk> ka6sox: I have a Q about the ep1220 board.
Feb 14 06:11:31 <beewoolie-afk> I'm not getting anything on TDO. It's always 3.3V
Feb 14 06:12:27 <beewoolie-afk> Wait, I have another thing to try.
Feb 14 06:17:15 <beewoolie-afk> Never mind.  It looks like an FTDI protocol issue.  The TDO line responding to the TAP.
Feb 14 06:29:36 <ka6sox> k
Feb 14 07:20:33 <beewoolie-afk> Man o man.  Thei FTDI protocol is worse than I thought.
Feb 14 09:14:12 <ka6sox-zzzz> ~seen velinp
Feb 14 09:14:16 <purl> velinp <n=velinp@c88-163.cable.netissat.bg> was last seen on IRC in channel #openjtag, 2d 18m 18s ago, saying: 'good luck with it :) ka6sox was asking about you ~1 hour ago from 'Lost Angles'; bye from me :)'.
**** ENDING LOGGING AT Tue Feb 14 10:59:56 2006