**** BEGIN LOGGING AT Sat Dec 24 02:59:57 2005
Dec 24 03:49:55 <lennert> vmaster: i had a + in my email address
Dec 24 03:50:08 <lennert> vmaster: they don't escape that in the link they send you.. so your browser translates it to %20
Dec 24 03:50:19 <lennert> vmaster: if you make it %2B by hand it works.. but it still doesn't let you log in
Dec 24 04:38:52 <vmaster> i've been able to log in
Dec 24 04:39:06 <lennert> yeah, i mean
Dec 24 04:39:16 <lennert> i've re-registered with an email address that did not contain a +, and that worked
Dec 24 04:39:20 <vmaster> ah, ok
Dec 24 04:39:25 <vmaster> yeah, but only without ssl
Dec 24 04:39:31 <lennert> but if you have a + in your email address, and you hack your way through the registration, you still can't login
Dec 24 04:39:36 <vmaster> hehehe
Dec 24 04:39:41 <lennert> hmm, haven't tried with ssl :)
Dec 24 04:40:37 <lennert> i wonder if you can put "'; drop table blah;'" in your email address
Dec 24 04:40:51 <lennert> and what happens if you do =p
Dec 24 04:49:32 <lennert> vmaster: you have a minute?
Dec 24 04:50:33 <vmaster> sure
Dec 24 04:52:25 <lennert> you wrote an (x)svf player, right?
Dec 24 04:52:55 <vmaster> just xsvf
Dec 24 04:53:44 <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"
Dec 24 04:54:07 <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
Dec 24 04:54:58 <lennert> the xilinx systemace .ace files are just some kind of embedded xsvf, apparently
Dec 24 04:55:34 <lennert> and indeed, you need to specify the entire jtag chain when you make the .ace file
Dec 24 04:55:58 <lennert> if your jtag chain changes (for example, if you connect a daughterboard to the xilinx board), all your .ace files just become invalid
Dec 24 04:56:03 <vmaster> xsvf doesn't have the ability to add dynamic predecessors and sucessors
Dec 24 04:57:17 <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
Dec 24 04:57:36 <lennert> there is some kind of prepend you can set, right?
Dec 24 04:57:46 <vmaster> not for xsvf
Dec 24 04:58:16 <lennert> darn, i thought i read that somewhere
Dec 24 04:58:36 <vmaster> svf has that possibilty
Dec 24 04:58:51 <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
Dec 24 04:58:55 <lennert> ah, right
Dec 24 04:59:02 <lennert> but that'd make it non-standard
Dec 24 04:59:16 <lennert> are there any alternatives to svf/xsvf that can do this?
Dec 24 04:59:22 <vmaster> stapl
Dec 24 04:59:34 <vmaster> seems to be the most advanced specification
Dec 24 04:59:43 <lennert> advanced as in complicated? :)
Dec 24 04:59:44 <vmaster> more like a jtag scripting language
Dec 24 04:59:47 <vmaster> hehe, yep
Dec 24 04:59:48 <lennert> right
Dec 24 05:00:07 <vmaster> i do it that way in my xsvf player
Dec 24 05:00:15 <vmaster> the user has to specify the chain layout
Dec 24 05:00:36 <vmaster> then he's able to "xsvf #chainnum file"
Dec 24 05:00:48 <vmaster> all other devices are set into bypass
Dec 24 05:00:57 <lennert> yeah
Dec 24 05:01:12 <lennert> when you program a xilinx fpga, there's no 'load' instruction
Dec 24 05:01:19 <lennert> you just shift all the config bits into the DR
Dec 24 05:01:35 <lennert> so there's not a more efficient way than programming the devices one-by-one and keeping the other ones in BYPASS
Dec 24 05:01:40 <lennert> so that sounds fair enough
Dec 24 05:02:20 <vmaster> mhh, yeah, programming multiple devices concurrently wouldn't work without knowning exactly what every xsvf file does
Dec 24 05:02:38 <lennert> yeah, but there's no way to do it inside the xsvf file either
Dec 24 05:03:04 <lennert> well.. i could imagine that you f.e. have two devices that you want to program in turn and then activate them both
Dec 24 05:03:34 <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?
Dec 24 05:04:01 <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)
Dec 24 05:05:53 <vmaster> mhh, that would only work if the algorithms for the devices match
Dec 24 05:06:10 <lennert> yeah, but that's up to the creator of the xsvf file :)
Dec 24 05:06:24 <lennert> all the player has to do is prepend/append the right number of ones
Dec 24 05:06:55 <lennert> well, hm.. not quite.  there's this 'expected pattern on TDO' that'll be delayed by N clocks, too.... hmmmm.
Dec 24 05:07:33 <vmaster> that's not really a problem
Dec 24 05:08:00 <lennert> you can't just shift in extra zeroes or ones to make the TDO bits shift out?
Dec 24 05:09:03 <vmaster> if we have a chain like that: <dummy1> <dummy2> <target1> <target2> <dummy3>
Dec 24 05:09:47 <vmaster> we just shift through
Dec 24 05:10:02 <vmaster> ir scans write 1s into the IR registers of all dummys
Dec 24 05:10:14 <vmaster> and the value from the xsvf for the targets
Dec 24 05:10:36 <vmaster> for dr scans, we shift one 1 for every dummy
Dec 24 05:10:36 <lennert> indeed, that's what i had in mind (1111 = BYPASS)
Dec 24 05:10:46 <lennert> yes, because the BYPASS DR reg is 1 bit wide
Dec 24 05:11:06 <vmaster> when the scan is finished, we'll have every bit shifted out
Dec 24 05:11:20 <lennert> uhm, no?
Dec 24 05:11:36 <lennert> in the chain you give..
Dec 24 05:11:49 <lennert> if the xsvf file assumed the chain <target1> <target2>
Dec 24 05:12:21 <lennert> responses will come out of the chain 1 bit delayed, no?
Dec 24 05:12:38 <vmaster> yeah, but we take care of that by shifting a 1 for the dummys
Dec 24 05:13:07 <lennert> well
Dec 24 05:13:12 <lennert> if you're programming an sp3
Dec 24 05:13:22 <lennert> you can't actually shift the dummy bits for dummy1 and dummy2 into target1
Dec 24 05:13:29 <lennert> (let's say that target1 is an sp3)
Dec 24 05:13:38 <lennert> because it'll assume that those are the first bits of the next programming word
Dec 24 05:13:58 <vmaster> oh, there's test-logic action while shifting?
Dec 24 05:14:07 <lennert> (admittedly, in that case you wouldn't be interested in the TDO bits)
Dec 24 05:14:09 <vmaster> i've only looked at the xilinx cplds so far
Dec 24 05:14:14 <lennert> yes, when you load the bitstream
Dec 24 05:14:30 <lennert> you load a special IR insn, and then shift the bitstream through DR without issuing any other commands
Dec 24 05:14:43 <vmaster> okay, i guess impact isn't able to program chains with spartans concurrently then either
Dec 24 05:14:53 <lennert> no, i don't think so
Dec 24 05:15:04 <lennert> that's what i was trying to say above -- you can't program fpgas concurrently because of this
Dec 24 05:15:09 <vmaster> ah, ok
Dec 24 05:15:22 <vmaster> well, yeah, then just program one after the other, keep the others in bypass
Dec 24 05:15:30 <vmaster> makes life a lot easier, too
Dec 24 05:16:35 <lennert> yeah, ok
Dec 24 05:16:42 <lennert> so now let's assume that xilinx fpgas don't exist
Dec 24 05:16:49 <lennert> i think there's still a tiny problem
Dec 24 05:17:13 <lennert> <dummy1> <dummy2> <target1> <target2> <dummy3>
Dec 24 05:17:28 <lennert> the dummies are in BYPASS, and the targets in some mode where the DR length is 4
Dec 24 05:17:43 <lennert> 1 1 aaaa bbbb 1 is what you shift in, rightmost bit first
Dec 24 05:18:02 <lennert> (or 0 0 aaaa bbbb 0, doesn't matter)
Dec 24 05:18:21 <lennert> oh, hmmm
Dec 24 05:18:28 <lennert> no, ok
Dec 24 05:18:32 <lennert> that's only relevant for the sp3
Dec 24 05:18:36 <lennert> you do get all the bits out
Dec 24 05:19:02 <lennert> okay, i'm seeing a problem that isn't there (only with sp3s)
Dec 24 05:19:14 <vmaster> yeah, but even without xilinx fpgas, i think it's not worth the effort trying to program multiple devices concurrently
Dec 24 05:19:33 <lennert> so how does it go with cplds?
Dec 24 05:19:34 <vmaster> after all, it only works for devices whose programming algorithm match
Dec 24 05:19:55 <vmaster> some init commands to erase the device
Dec 24 05:20:07 <vmaster> then a command to start programming
Dec 24 05:20:33 <vmaster> and then programming, validating the result from the last scan, and run-test for x cycles
Dec 24 05:20:44 <lennert> right, so you can't reprogram then without reflashing
Dec 24 05:20:48 <vmaster> yep
Dec 24 05:21:00 <lennert> but it doesn't use the DR until you issue another command or leave shift-DR state, then?
Dec 24 05:21:07 <vmaster> yes
Dec 24 05:21:18 <lennert> (i wonder if the sp3 'using' the DR register while in shift-dr violates the jtag spec somehow)
Dec 24 05:21:21 <vmaster> cplds are more ieee compliant in that regard
Dec 24 05:21:23 <vmaster> yes, it does
Dec 24 05:21:45 <vmaster> the data shifted into the devices should only become valid in update-dr
Dec 24 05:21:55 <lennert> okay
Dec 24 05:22:13 <lennert> we could say we don't deal with noncompliant devices but they're a big part of the market :)
Dec 24 05:22:19 <vmaster> yep
Dec 24 05:22:37 <vmaster> and i'd say almost every device is non-compliant in some regard
Dec 24 05:22:56 <lennert> (on the sp3, the insn in question is CFG_IN)
Dec 24 05:22:59 <lennert> oh, i'm sure of that
Dec 24 05:23:13 <lennert> people just can't get stuff right :)
Dec 24 05:23:48 <vmaster> mhh... guess they're trying to optimize for their own little world, without keeping an eye on the world outside
Dec 24 05:25:15 <lennert> the "if we break the spec it's easier for us" argument
Dec 24 05:25:23 <vmaster> yep
Dec 24 05:25:33 <vmaster> and more efficient, as in the spartan example
Dec 24 05:25:39 <lennert> yeah, definitely
Dec 24 05:25:45 <lennert> going back and forth would be much slower
Dec 24 05:26:04 <vmaster> yeah, and that way, there's also no real penalty from having to program one device after the other
Dec 24 05:26:11 <vmaster> almost no overhead
Dec 24 05:26:50 <lennert> indeed, because all the other devices will only occupy 1 bit in the chain
Dec 24 05:27:25 <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
Dec 24 05:28:31 <vmaster> i'd love to have a look at the 1532 docs - but it's a bit too much money to satisfy my curiosity
Dec 24 05:28:34 <lennert> in fact, in most cases you'll only be talking to one device at a time
Dec 24 05:28:51 <lennert> except if you're (for example) doing JSTART on all devices in the chain simultaneously
Dec 24 05:30:42 <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
Dec 24 05:31:46 <lennert> svf spec is 26 pages.. shortest spec i've seen in a while
Dec 24 05:31:54 <lennert> vmaster: it should be possible to get the 1532 specs _somewhere_.. :)
Dec 24 05:32:24 <vmaster> svf is rather simple
Dec 24 05:32:38 <vmaster> and the spec leaves enough questions unanswered ;)
Dec 24 05:33:23 <lennert> like the system ace 'specs' (puke)  :)
Dec 24 05:35:18 <lennert> the pdf for 1532 is $92
Dec 24 05:35:51 <vmaster> for ieee members, iirc?
Dec 24 05:35:56 <lennert> probably
Dec 24 05:37:17 <lennert> if we knew the pdf file name it'd be a lot easier ;)
Dec 24 05:37:38 <vmaster> hehehe, that worked with 1149, but i've had no luck with 1532
Dec 24 05:38:33 <vmaster> it's 1532-2002.pdf
Dec 24 05:38:41 <vmaster> http://standards.ieee.org/catalog/olis/testtech.html
Dec 24 05:43:00 <lennert> it's $83 at ansi
Dec 24 05:43:03 <lennert> http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FIEEE+1532%2D2002
Dec 24 05:59:04 <vmaster> okay... time for food
**** ENDING LOGGING AT Sun Dec 25 02:59:56 2005