00:29 <kc8apf> "which of the 5 tools for programming actually works for _this_ board?" "None" 🤷‍♂️

00:57 <cr1901_modern> https://www.edn.com/electronics-news/4028388/Lattice-finally-enters-the-FPGA-race?utm_source=eetimes&utm_medium=relatedcontent Huh, so Lattice's first FPGA was called ispXPGA (it's a unselected option in the ispLEVER installer)

07:27 <omnitechnomancer> I should update the ReadMe on my fork

09:43 <daveshah> cr1901_modern: that's really interesting, I hadn't seen those parts before

09:43 <daveshah> Interestingly the arch looks further away (at least in terms of naming) from modern Lattice parts than the Lucent stuff. So I guess they dropped their own arch in favour of the one the bought soon afterwards

12:44 <kbeckmann> Has anyone here managed to configure an ECP5 using the Slave SPI mode? I'm able to send commands like READ_ID and get the correct result back, however I don't quite understand how to send the bitstream. The docs refer to WRITE_EN and WRITE_INC commands which I can't find any documentation for at all... And if I just send the bitstream as raw spi data it doesn't seem to work (this works with Serial mode).

12:44 <kbeckmann> Any ideas?

13:00 <ZirconiumX> daveshah might know

13:01 <daveshah> Afraid I don't, I've only ever used JTAG or master SPI

13:01 <daveshah> In JTAG mode you basically send LSC_BITSTREAM_BURST (0x7A) followed by the whole bitstream

13:02 <daveshah> however, you might have to be a bit careful with bit/byte ordering

13:03 <kbeckmann> thanks. i did try this but i will experiment a bit more with it!

15:15 <OmniMancer> do parallel input LCD controllers have strict requirements on the pixel clock?

15:17 <daveshah> In general not really

15:18 <daveshah> I managed to overclock one quite significantly a while ago (some 1024x600 75Hz panel, think I got it up to 150Hz)

15:19 <OmniMancer> Oh the datasheet for the controller seems to give a maximum pixel clock but not a minimum

15:19 <OmniMancer> my question is more around can I drive it slower than typical

15:20 <tnt> How much slower are you talking about ?

15:20 <OmniMancer> 24MHz instead of 33

15:20 <tnt> Oh yeah, should be just fine.

15:21 <tnt> I've driven panel at ~ half their typ speed and never had issues.

15:21 <OmniMancer> I want a design I can try on nextpnr that doesn't require me to go figure out how to route stuff to the PLLs

15:21 <OmniMancer> I would suspect it just cuts the refresh rate down to do that

15:22 <daveshah> Yeah, it does, there's no frame buffer or anything so it would have to

15:22 <daveshah> So long as its not actually DC it will probably be alright

15:22 <daveshah> idk what period panel damage starts to happen at

15:22 <OmniMancer> cool

15:22 <daveshah> But imagine it's a low slower than half clock

15:27 <sorear> what kind of thing is damaged by DC clock input

15:27 <daveshah> It deteriorates the liquid crystals somehow

15:27 <daveshah> Electrolysis perhaps?

15:29 <sorear> is the panel clock somehow derived from the pixel clock, such that putting DC on the pixel interface would cause the internal clocks to fail?

15:33 <daveshah> I think this how simpler controllers work

15:33 <daveshah> *this is

15:33 <OmniMancer> I think most panels do PWM to provide full colour depth?

15:34 <OmniMancer> or dithering atleast

15:34 <daveshah> Yes, I'm sure those controllers are more intelligent

15:37 <OmniMancer> there are minimum cycle times for the input clock and a duty cycle requirement that seems to be 10% either side of 50%

15:50 <tnt> OmniMancer: yup it's called FRC.

15:50 <tnt> For instance, I know my laptop panel is 6 bit + 2 bit FRC.

15:56 <OmniMancer> indeed

15:59 <kbeckmann> daveshah: i got the spi slave stuff to work.. i did exactly what you are doing in the .svf but doing separate spi transfers for each TDI/TDO transfer, including the afaik undocumented opcodes 0xc6 and 0x1c

23:26 <eddyb> so I uhh finally got into nmigen and I have to say I was wrong about Python https://gist.github.com/eddyb/e3afeb490874f110b75f04cbd20dc20b

23:26 <eddyb> at least in terms of my ability to do something in it comfortably

23:28 <eddyb> whitequark: I'm wondering if there are any plans for reusable components like the UART example to be either in `nmigen/lib` or somewhere else, I don't feel like I should e.g. publish a github repo with a copy of your UART in it

23:29 <tpw_rules> eddyb: there is nmigen-stdio but the uart in it is broken

23:29 <tpw_rules> (last i checked)

23:29 <eddyb> (not for copyright reasons, just duplication etc. - not that I'm doing anything interesting yet, just seeing how much I could push my iCEstick with silly things)

23:31 <eddyb> tpw_rules: huh. cool, but also, how so? I mean, when `nmigen` itself has an UART example that "Just Works". maybe I got lucky :P

23:32 <tpw_rules> eddyb: the nmigen one works i think

23:32 <whitequark> it's broken because i never got around to finish that branch properly

23:32 <whitequark> i'll do it eventually, just other things took priority

23:33 <eddyb> ah okay don't mind me :)

23:33 <tpw_rules> or me

23:37 <eddyb> overall I'm really happy with my silly state machines, the `m.d.sync += ...` syntax is really clear as "will be observable next cycle" (not 100% sure that's accurate but I haven't hit anything where it didn't match my expectations)

23:44 <whitequark> yes, that's what it means

23:49 <eddyb> wow so I was going to try to do https://adventofcode.com/2019/day/1 (having misremembered its `x/3-2` as `x*3/2`) but 5-digit (17-bit) div by 3 puts me at 101% LC utilization (and I need 7 digits for realistic input data)

23:51 <whitequark> you don't ever use division in HDL

23:51 <whitequark> (and multiplication too, in general)

23:51 <whitequark> the only value those operations have are for simulation code

23:51 <eddyb> yeah I was expecting it to be bad, but I was hoping the constant divisor might help a bit

23:53 <whitequark> it would probably have been much worse with a non-constant divisor

23:53 <whitequark> (you can check it)

23:53 <whitequark> eddyb: the way it works is it does this: https://courses.cs.vt.edu/~cs1104/BuildingBlocks/divide.030.html

23:54 <eddyb> for decimal output (which is entirely unnecessary, I know :P) I ended up decrementing digits from most significant to least, which takes up to ten times more cycles, but it's not like UART is doing much while that's going on

23:54 <whitequark> so even for /3, it builds up a gigantic tree of subtractors and comparators

23:57 <eddyb> I guess it being a constant (as opposed to a 2-bit variable) simplifies about half of all that? the other half getting a nice avalanche from all the XOR-ing

23:58 <whitequark> dunno. try it out and see what happens

23:58 <eddyb> so right now with 4-digit / 14-bit I have:

23:58 <eddyb> > Info: ICESTORM_LC: 890/ 1280 69%

23:58 <whitequark> nice