| 00:45.55 | *** join/#openjtag ka6so1 (n=tom@pool-71-102-140-145.snloca.dsl-w.verizon.net) |
| 01:06.03 | *** join/#openjtag vmaster_ (i=vmaster@p549B5A98.dip.t-dialin.net) |
| 04:11.33 | *** join/#openjtag beewoolie-afk (n=beewooli@206.124.142.26) |
| 09:37.46 | vmaster_ | lennert: avnet registration works if you replace the https:// with http:// |
| 10:49.53 | lennert | vmaster: i had a + in my email address |
| 10:50.06 | lennert | vmaster: they don't escape that in the link they send you.. so your browser translates it to %20 |
| 10:50.17 | lennert | vmaster: if you make it %2B by hand it works.. but it still doesn't let you log in |
| 11:38.50 | vmaster | i've been able to log in |
| 11:39.04 | lennert | yeah, i mean |
| 11:39.14 | lennert | i've re-registered with an email address that did not contain a +, and that worked |
| 11:39.18 | vmaster | ah, ok |
| 11:39.23 | vmaster | yeah, but only without ssl |
| 11:39.29 | lennert | but if you have a + in your email address, and you hack your way through the registration, you still can't login |
| 11:39.34 | vmaster | hehehe |
| 11:39.39 | lennert | hmm, haven't tried with ssl :) |
| 11:40.35 | lennert | i wonder if you can put "'; drop table blah;'" in your email address |
| 11:40.49 | lennert | and what happens if you do =p |
| 11:49.30 | lennert | vmaster: you have a minute? |
| 11:50.31 | vmaster | sure |
| 11:52.23 | lennert | you wrote an (x)svf player, right? |
| 11:52.53 | vmaster | just xsvf |
| 11:53.42 | lennert | what i don't really like about svf is that you can't say "find the jtag device with ID X and send it these commands" |
| 11:54.05 | lennert | but not knowing the IR lengths of all jtag devices in the universe makes it kind of hard to do that in an embedded and automated way |
| 11:54.56 | lennert | the xilinx systemace .ace files are just some kind of embedded xsvf, apparently |
| 11:55.32 | lennert | and indeed, you need to specify the entire jtag chain when you make the .ace file |
| 11:55.56 | lennert | if your jtag chain changes (for example, if you connect a daughterboard to the xilinx board), all your .ace files just become invalid |
| 11:56.01 | vmaster | xsvf doesn't have the ability to add dynamic predecessors and sucessors |
| 11:57.15 | vmaster | what would work is creating the .ace/xsvf file for a single device in the chain, and let the xsvf player handle the chain |
| 11:57.34 | lennert | there is some kind of prepend you can set, right? |
| 11:57.44 | vmaster | not for xsvf |
| 11:58.14 | lennert | darn, i thought i read that somewhere |
| 11:58.34 | vmaster | svf has that possibilty |
| 11:58.49 | lennert | in any case, yeah, an opcode where you can say "i want jtag device ID X (and an optional sequence # in the chain)" and it'll handle the BYPASS prepend/append for you |
| 11:58.53 | lennert | ah, right |
| 11:59.00 | lennert | but that'd make it non-standard |
| 11:59.14 | lennert | are there any alternatives to svf/xsvf that can do this? |
| 11:59.20 | vmaster | stapl |
| 11:59.32 | vmaster | seems to be the most advanced specification |
| 11:59.41 | lennert | advanced as in complicated? :) |
| 11:59.42 | vmaster | more like a jtag scripting language |
| 11:59.45 | vmaster | hehe, yep |
| 11:59.46 | lennert | right |
| 12:00.05 | vmaster | i do it that way in my xsvf player |
| 12:00.13 | vmaster | the user has to specify the chain layout |
| 12:00.34 | vmaster | then he's able to "xsvf #chainnum file" |
| 12:00.46 | vmaster | all other devices are set into bypass |
| 12:00.55 | lennert | yeah |
| 12:01.10 | lennert | when you program a xilinx fpga, there's no 'load' instruction |
| 12:01.17 | lennert | you just shift all the config bits into the DR |
| 12:01.33 | lennert | so there's not a more efficient way than programming the devices one-by-one and keeping the other ones in BYPASS |
| 12:01.38 | lennert | so that sounds fair enough |
| 12:02.18 | vmaster | mhh, yeah, programming multiple devices concurrently wouldn't work without knowning exactly what every xsvf file does |
| 12:02.36 | lennert | yeah, but there's no way to do it inside the xsvf file either |
| 12:03.02 | lennert | well.. i could imagine that you f.e. have two devices that you want to program in turn and then activate them both |
| 12:03.32 | lennert | can you specify, for example, that the xsvf file you want to program assumes a 2-device chain while the actual chain has 4 devices, for example? |
| 12:03.59 | lennert | (then you could program one and keep the other in BYPASS, program the second and keep the first in BYPASS, and then Run test/idle them both) |
| 12:05.51 | vmaster | mhh, that would only work if the algorithms for the devices match |
| 12:06.08 | lennert | yeah, but that's up to the creator of the xsvf file :) |
| 12:06.22 | lennert | all the player has to do is prepend/append the right number of ones |
| 12:06.53 | lennert | well, hm.. not quite. there's this 'expected pattern on TDO' that'll be delayed by N clocks, too.... hmmmm. |
| 12:07.31 | vmaster | that's not really a problem |
| 12:07.58 | lennert | you can't just shift in extra zeroes or ones to make the TDO bits shift out? |
| 12:09.00 | vmaster | if we have a chain like that: <dummy1> <dummy2> <target1> <target2> <dummy3> |
| 12:09.45 | vmaster | we just shift through |
| 12:10.00 | vmaster | ir scans write 1s into the IR registers of all dummys |
| 12:10.12 | vmaster | and the value from the xsvf for the targets |
| 12:10.33 | vmaster | for dr scans, we shift one 1 for every dummy |
| 12:10.34 | lennert | indeed, that's what i had in mind (1111 = BYPASS) |
| 12:10.44 | lennert | yes, because the BYPASS DR reg is 1 bit wide |
| 12:11.04 | vmaster | when the scan is finished, we'll have every bit shifted out |
| 12:11.18 | lennert | uhm, no? |
| 12:11.34 | lennert | in the chain you give.. |
| 12:11.47 | lennert | if the xsvf file assumed the chain <target1> <target2> |
| 12:12.19 | lennert | responses will come out of the chain 1 bit delayed, no? |
| 12:12.36 | vmaster | yeah, but we take care of that by shifting a 1 for the dummys |
| 12:13.05 | lennert | well |
| 12:13.10 | lennert | if you're programming an sp3 |
| 12:13.20 | lennert | you can't actually shift the dummy bits for dummy1 and dummy2 into target1 |
| 12:13.27 | lennert | (let's say that target1 is an sp3) |
| 12:13.36 | lennert | because it'll assume that those are the first bits of the next programming word |
| 12:13.56 | vmaster | oh, there's test-logic action while shifting? |
| 12:14.05 | lennert | (admittedly, in that case you wouldn't be interested in the TDO bits) |
| 12:14.07 | vmaster | i've only looked at the xilinx cplds so far |
| 12:14.12 | lennert | yes, when you load the bitstream |
| 12:14.28 | lennert | you load a special IR insn, and then shift the bitstream through DR without issuing any other commands |
| 12:14.41 | vmaster | okay, i guess impact isn't able to program chains with spartans concurrently then either |
| 12:14.51 | lennert | no, i don't think so |
| 12:15.02 | lennert | that's what i was trying to say above -- you can't program fpgas concurrently because of this |
| 12:15.07 | vmaster | ah, ok |
| 12:15.20 | vmaster | well, yeah, then just program one after the other, keep the others in bypass |
| 12:15.28 | vmaster | makes life a lot easier, too |
| 12:16.33 | lennert | yeah, ok |
| 12:16.40 | lennert | so now let's assume that xilinx fpgas don't exist |
| 12:16.47 | lennert | i think there's still a tiny problem |
| 12:17.11 | lennert | <dummy1> <dummy2> <target1> <target2> <dummy3> |
| 12:17.26 | lennert | the dummies are in BYPASS, and the targets in some mode where the DR length is 4 |
| 12:17.40 | lennert | 1 1 aaaa bbbb 1 is what you shift in, rightmost bit first |
| 12:18.00 | lennert | (or 0 0 aaaa bbbb 0, doesn't matter) |
| 12:18.19 | lennert | oh, hmmm |
| 12:18.26 | lennert | no, ok |
| 12:18.30 | lennert | that's only relevant for the sp3 |
| 12:18.34 | lennert | you do get all the bits out |
| 12:19.00 | lennert | okay, i'm seeing a problem that isn't there (only with sp3s) |
| 12:19.12 | vmaster | yeah, but even without xilinx fpgas, i think it's not worth the effort trying to program multiple devices concurrently |
| 12:19.31 | lennert | so how does it go with cplds? |
| 12:19.32 | vmaster | after all, it only works for devices whose programming algorithm match |
| 12:19.53 | vmaster | some init commands to erase the device |
| 12:20.05 | vmaster | then a command to start programming |
| 12:20.31 | vmaster | and then programming, validating the result from the last scan, and run-test for x cycles |
| 12:20.42 | lennert | right, so you can't reprogram then without reflashing |
| 12:20.45 | vmaster | yep |
| 12:20.58 | lennert | but it doesn't use the DR until you issue another command or leave shift-DR state, then? |
| 12:21.05 | vmaster | yes |
| 12:21.16 | lennert | (i wonder if the sp3 'using' the DR register while in shift-dr violates the jtag spec somehow) |
| 12:21.19 | vmaster | cplds are more ieee compliant in that regard |
| 12:21.21 | vmaster | yes, it does |
| 12:21.43 | vmaster | the data shifted into the devices should only become valid in update-dr |
| 12:21.53 | lennert | okay |
| 12:22.11 | lennert | we could say we don't deal with noncompliant devices but they're a big part of the market :) |
| 12:22.17 | vmaster | yep |
| 12:22.35 | vmaster | and i'd say almost every device is non-compliant in some regard |
| 12:22.54 | lennert | (on the sp3, the insn in question is CFG_IN) |
| 12:22.57 | lennert | oh, i'm sure of that |
| 12:23.11 | lennert | people just can't get stuff right :) |
| 12:23.46 | vmaster | mhh... guess they're trying to optimize for their own little world, without keeping an eye on the world outside |
| 12:25.13 | lennert | the "if we break the spec it's easier for us" argument |
| 12:25.21 | vmaster | yep |
| 12:25.31 | vmaster | and more efficient, as in the spartan example |
| 12:25.37 | lennert | yeah, definitely |
| 12:25.43 | lennert | going back and forth would be much slower |
| 12:26.02 | vmaster | yeah, and that way, there's also no real penalty from having to program one device after the other |
| 12:26.09 | vmaster | almost no overhead |
| 12:26.48 | lennert | indeed, because all the other devices will only occupy 1 bit in the chain |
| 12:27.23 | lennert | if you'd program N devices concurrently.. and each device had a (say) 32bit register that would need loading in every Update-DR, every DR shift will take N times longer |
| 12:28.29 | vmaster | i'd love to have a look at the 1532 docs - but it's a bit too much money to satisfy my curiosity |
| 12:28.32 | lennert | in fact, in most cases you'll only be talking to one device at a time |
| 12:28.49 | lennert | except if you're (for example) doing JSTART on all devices in the chain simultaneously |
| 12:30.40 | vmaster | yeah, that's also true for debugging tasks - you talk to every device independently, and only when you're about to restart the cores you do something with all of them at once |
| 12:31.44 | lennert | svf spec is 26 pages.. shortest spec i've seen in a while |
| 12:31.52 | lennert | vmaster: it should be possible to get the 1532 specs _somewhere_.. :) |
| 12:32.22 | vmaster | svf is rather simple |
| 12:32.36 | vmaster | and the spec leaves enough questions unanswered ;) |
| 12:33.21 | lennert | like the system ace 'specs' (puke) :) |
| 12:35.16 | lennert | the pdf for 1532 is $92 |
| 12:35.49 | vmaster | for ieee members, iirc? |
| 12:35.54 | lennert | probably |
| 12:37.15 | lennert | if we knew the pdf file name it'd be a lot easier ;) |
| 12:37.36 | vmaster | hehehe, that worked with 1149, but i've had no luck with 1532 |
| 12:38.31 | vmaster | it's 1532-2002.pdf |
| 12:38.39 | vmaster | http://standards.ieee.org/catalog/olis/testtech.html |
| 12:42.58 | lennert | it's $83 at ansi |
| 12:43.01 | lennert | http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FIEEE+1532%2D2002 |
| 12:59.27 | vmaster | okay... time for food |
| 21:48.58 | *** join/#openjtag bullet (n=bullet@60.60.62.81.cust.bluewin.ch) |
| 22:19.08 | *** join/#openjtag bullet (n=bullet@60.60.62.81.cust.bluewin.ch) |
| 23:40.08 | *** part/#openjtag bullet (n=bullet@60.60.62.81.cust.bluewin.ch) |