00:07 <d1b2> <icb> And someone bought 100 boards

00:07 <d1b2> <Attie> O_O really?!

00:08 <d1b2> <icb> It was at 1314, refreshed and it's at 1414 now

00:08 <d1b2> <Attie> wow, quite a jump

00:08 <d1b2> <Attie> (don't forget the +200 early bird boards!)

00:08 <d1b2> <icb> Yup

00:15 <whitequark> wow

00:31 <d1b2> <davoid> thx for tips! true about the SPI needing multiple data lines. I'll see if I can manage to make a SPI ctrl variant to roll several data pins

02:57 <sorear> o_O

09:19 <d1b2> <mwick83> Hi everyone, I'm currently working on getting SWD supported in openocd (itself) and the jtag-openocd applet. Well, basically, I got it working, but I'm unable to get a pin treated as BiDi (TMS in this case, but tried with a non-jtag one, too) in the applet. Are there any restrictions? I had a look in the schematic, and I think that should work when the corresponding DIR-pin of the Levelshifter is driven properly. Any pointers where I should have a look

09:19 <d1b2> into?

09:22 <hell__> sorear: if it's about who bought 100 boards, I presume it's someone from an organization. As to why, I have no clue (although optimistic me likes to think it's to use them for development)

15:44 <d1b2> <DX-MON> @mwick83 What you want to do is look in the applet and specifically at the usage of the pin nominated as TMS at how its .i, .o and .oe signals are being used - that's the incoming, outgoing and output enable data signals

15:45 <d1b2> <DX-MON> even if the level shifter is driven perfectly, if the FPGA isn't also switching the pin to an input, then that'd explain why you were having trouble

15:49 <d1b2> <mwick83> @DX-MON Yeah, I know. I did that and modified the OE, O and I logic at the TMS pin. But I can only read back what is driven at O, even though OE is low, no matter what I do externally. And reading the RTLIL is a bit had for me... Reading a technology mapped Verilog netlist is easier for me 😉

15:49 <d1b2> <DX-MON> you want to read back via the .i pin

15:49 <d1b2> <DX-MON> *sub-pin

15:50 <d1b2> <DX-MON> which goes through an IBUF from the pad of the FPGA

15:50 <d1b2> <DX-MON> the .o pin is an input into an OBUF

15:50 <d1b2> <mwick83> @DX-MON: yes, I do: in the submodule "FFSynchronizer(pads.tms_t.i, self.tms_i),"

15:50 <d1b2> <DX-MON> ok

15:51 <d1b2> <mwick83> I have the feeling that the muxing logic around the I and OBUFs is wrong...

15:52 <d1b2> <mwick83> and thas for the O and OE in the comb section: pads.tms_t.oe.eq(~self.tms_z), pads.tms_t.o.eq(self.tms),"

15:52 <d1b2> <DX-MON> well the latter has no negative effect..

15:53 <d1b2> <DX-MON> if you're holding self.tms_z so that the output enable is low (off), the value of self.tms_i will be w/e is on the physical pin

15:53 <d1b2> <DX-MON> .oe.eq(1) enables the output, and .oe.eq(0) disables it

15:53 <d1b2> <mwick83> Ha... I got an idea... I think I might be driving tms_z wrong...

15:54 <d1b2> <mwick83> I'm not too used to nMigen yet... I guess I got combinatorical and synchonous logic wrong...

15:55 <d1b2> <DX-MON> self.tms_i is synchronous to the system clock

15:55 <d1b2> <DX-MON> the OE signal is being constantly driven

15:55 <d1b2> <DX-MON> you can make changes to self.tms_z synchronously and they will immediately be applied to the OE sub-pin

15:56 <d1b2> <DX-MON> but that ~ on the front makes it so self.tms_z is active-low

15:56 <d1b2> <DX-MON> doing a m.d.sync += [self.tms_z.eq(1)] will disable output

15:57 <d1b2> <mwick83> hm, I already did it right: "m.d.sync += bus.tms_z.eq(~out_fifo.r_data[:5])"

15:58 <d1b2> <DX-MON> not sure why bus there rather than self.. but ok

15:59 <d1b2> <DX-MON> also, if you're doing that.. make it tms_oe and get rid of the ~'s there and in the comb logic (m.d.comb += [pads.tms_t.oe.eq(self.tms_oe)]) so it's easier to reason about

15:59 <d1b2> <mwick83> that's how it's done in the code already there. bus is a local shorthand vriable, which is also assigned to self.bus

16:00 <d1b2> <mwick83> yes, I would prefer oe also, bit the JTAGBus uses _z for the trst, so I wanted to be in line with the code that is already there

16:00 <d1b2> <DX-MON> that way you can say "if tms_oe is enabled, then the value in tms_o is on the pin, otherwise", etc

16:01 <d1b2> <mwick83> JTAGProbeBus is what I meant

16:02 <d1b2> <DX-MON> which applet is this exactly again?

16:03 <d1b2> <DX-MON> I'll give it a look over and see if that helps me provide any more useful advise

16:06 <d1b2> <Attie> have a look at another applet that uses the pin for bidi... e.g: I2C?

16:07 <d1b2> <Attie> ... I2C will set the O low, and toggle OE (effectively open drain), but the concept should hold aside from that

16:07 <d1b2> <mwick83> @Attie: I already did, that's why I'm a bit puzzled, but I think I got it... My command decoding was wrong, I guess. Just checking that out

16:08 <d1b2> <Attie> nice

16:09 <d1b2> <DX-MON> looks like the person who wrote the JTAGProbeBus type was thinking in terms of 'is high-z' rather than the more natural 'is output enabled'

16:09 <d1b2> <mwick83> yes, that was it... damn ASCII codes 😉

16:09 <d1b2> <DX-MON> I think it's quite safe to depart from that way of thinking and use the nMigen way

16:09 <d1b2> <mwick83> sorry, for the noise. But talking about it often helps 😉

16:10 <d1b2> <DX-MON> aye, that's fine

16:10 <d1b2> <DX-MON> this channel is for Glasgow dev, so 🙂

16:10 <d1b2> <DX-MON> actually rather nice to hear of someone else who's working on new and improving existing applets for Glasgow

16:11 <d1b2> <mwick83> yeah, as an ASIC design, I usually also think about o and oe rather than high-z-ing something 😉

16:11 <d1b2> <DX-MON> b/c it's easier and less brain load, right?

16:12 <d1b2> <mwick83> could be, or it is just what one is used to / trained for 😉

16:12 <d1b2> <DX-MON> heh, fair

16:13 <d1b2> <mwick83> I actually plan to submit a pull request, once I got it in shape

22:25 <_whitenotifier> [glasgow] mwick83 opened pull request #266: applet.interface.jtag_openocd: Add SWD support - https://git.io/Jt4AF

22:35 <_whitenotifier> [glasgow] mwick83 opened pull request #267: applet.interface.jtag_openocd: Add option to ignore unsupported commands - https://git.io/Jt4xz