<kc8apf> "which of the 5 tools for programming actually works for _this_ board?" "None" 🤷‍♂️
<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)
Bob_Dole has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Ping timeout: 276 seconds]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` is now known as X-Scale
parataxis has joined ##openfpga
_whitelogger has joined ##openfpga
nrossi has joined ##openfpga
_whitelogger has joined ##openfpga
Bike has quit [Quit: Lost terminal]
Maylay has quit [Ping timeout: 250 seconds]
OmniMancer has joined ##openfpga
Maylay has joined ##openfpga
OmniMancer1 has joined ##openfpga
Maylay has quit [Ping timeout: 276 seconds]
OmniMancer has quit [Ping timeout: 240 seconds]
Maylay has joined ##openfpga
_whitelogger has joined ##openfpga
Maylay has joined ##openfpga
Maylay has quit [Ping timeout: 250 seconds]
_whitelogger has joined ##openfpga
Maylay has quit [Ping timeout: 276 seconds]
<omnitechnomancer> I should update the ReadMe on my fork
m4ssi has joined ##openfpga
parataxis has quit [Ping timeout: 268 seconds]
OmniMancer1 has quit [Quit: Leaving.]
m4ssi has quit [Quit: Leaving]
_whitelogger has joined ##openfpga
Maylay has quit [Ping timeout: 268 seconds]
Jybz has joined ##openfpga
Maylay has joined ##openfpga
Zorix has quit [Ping timeout: 246 seconds]
Maylay has quit [Ping timeout: 268 seconds]
Jybz has quit [Ping timeout: 276 seconds]
Zorix has joined ##openfpga
Maylay has joined ##openfpga
_whitelogger has joined ##openfpga
<daveshah> cr1901_modern: that's really interesting, I hadn't seen those parts before
<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
Asu has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Ping timeout: 268 seconds]
Bob_Dole has joined ##openfpga
OmniMancer has joined ##openfpga
Jybz has joined ##openfpga
synaption[m] has quit [Quit: killed]
jfng has quit [Quit: killed]
scream has quit [Quit: killed]
omnitechnomancer has quit [Read error: Connection reset by peer]
xobs has quit [Quit: killed]
promach3 has quit [Quit: killed]
pepijndevos[m] has quit [Read error: Connection reset by peer]
<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).
<kbeckmann> Any ideas?
Bike has joined ##openfpga
<ZirconiumX> daveshah might know
<daveshah> Afraid I don't, I've only ever used JTAG or master SPI
<daveshah> In JTAG mode you basically send LSC_BITSTREAM_BURST (0x7A) followed by the whole bitstream
<daveshah> however, you might have to be a bit careful with bit/byte ordering
<kbeckmann> thanks. i did try this but i will experiment a bit more with it!
jfng has joined ##openfpga
synaption[m] has joined ##openfpga
promach3 has joined ##openfpga
xobs has joined ##openfpga
swedishhat[m] has joined ##openfpga
pepijndevos[m] has joined ##openfpga
scream has joined ##openfpga
henriknj has joined ##openfpga
omnitechnomancer has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
<OmniMancer> do parallel input LCD controllers have strict requirements on the pixel clock?
<daveshah> In general not really
<daveshah> I managed to overclock one quite significantly a while ago (some 1024x600 75Hz panel, think I got it up to 150Hz)
Asu has quit [Remote host closed the connection]
<OmniMancer> Oh the datasheet for the controller seems to give a maximum pixel clock but not a minimum
<OmniMancer> my question is more around can I drive it slower than typical
<tnt> How much slower are you talking about ?
<OmniMancer> 24MHz instead of 33
<tnt> Oh yeah, should be just fine.
<tnt> I've driven panel at ~ half their typ speed and never had issues.
<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
<OmniMancer> I would suspect it just cuts the refresh rate down to do that
<daveshah> Yeah, it does, there's no frame buffer or anything so it would have to
<daveshah> So long as its not actually DC it will probably be alright
<daveshah> idk what period panel damage starts to happen at
<OmniMancer> cool
<daveshah> But imagine it's a low slower than half clock
<sorear> what kind of thing is damaged by DC clock input
<daveshah> It deteriorates the liquid crystals somehow
<daveshah> Electrolysis perhaps?
<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?
<daveshah> I think this how simpler controllers work
<daveshah> *this is
<OmniMancer> I think most panels do PWM to provide full colour depth?
<OmniMancer> or dithering atleast
<daveshah> Yes, I'm sure those controllers are more intelligent
<OmniMancer> there are minimum cycle times for the input clock and a duty cycle requirement that seems to be 10% either side of 50%
<tnt> OmniMancer: yup it's called FRC.
<tnt> For instance, I know my laptop panel is 6 bit + 2 bit FRC.
<OmniMancer> indeed
<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
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
freemint has quit [Ping timeout: 240 seconds]
parataxis has joined ##openfpga
Asu has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
Asu has quit [Ping timeout: 276 seconds]
Asu has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 240 seconds]
ZombieChicken has joined ##openfpga
Asu` has quit [Ping timeout: 276 seconds]
Bob_Dole has joined ##openfpga
Asu` has joined ##openfpga
Asu` has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
Asu has quit [Ping timeout: 265 seconds]
Asu has joined ##openfpga
m_w has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
nrossi has quit [Quit: Connection closed for inactivity]
Jybz has quit [Quit: Konversation terminated!]
Bike has quit [Ping timeout: 252 seconds]
eddyb has joined ##openfpga
<eddyb> so I uhh finally got into nmigen and I have to say I was wrong about Python https://gist.github.com/eddyb/e3afeb490874f110b75f04cbd20dc20b
<eddyb> at least in terms of my ability to do something in it comfortably
<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
<tpw_rules> eddyb: there is nmigen-stdio but the uart in it is broken
<tpw_rules> (last i checked)
<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)
<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
<tpw_rules> eddyb: the nmigen one works i think
<whitequark> it's broken because i never got around to finish that branch properly
<whitequark> i'll do it eventually, just other things took priority
<eddyb> ah okay don't mind me :)
<tpw_rules> or me
<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)
<whitequark> yes, that's what it means
<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)
<whitequark> you don't ever use division in HDL
<whitequark> (and multiplication too, in general)
<whitequark> the only value those operations have are for simulation code
<eddyb> yeah I was expecting it to be bad, but I was hoping the constant divisor might help a bit
<whitequark> it would probably have been much worse with a non-constant divisor
<whitequark> (you can check it)
<whitequark> eddyb: the way it works is it does this: https://courses.cs.vt.edu/~cs1104/BuildingBlocks/divide.030.html
<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
<whitequark> so even for /3, it builds up a gigantic tree of subtractors and comparators
<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
<whitequark> dunno. try it out and see what happens
<eddyb> so right now with 4-digit / 14-bit I have:
<eddyb> > Info: ICESTORM_LC: 890/ 1280 69%
<whitequark> nice