10:20 <daveshah> _florent_: I think I've found a Diamond bug that affects litedram. ECP5 PIO hardware has a "hi-z enable" rather than "output enable" input. This means that T0/T1 of a TSHX2DQA are always tristate enable (ie !output enable) **even if your subsequent logic suggests otherwise**

10:21 <daveshah> So when using the DDR hardware primitives, something like `t_dq ? pre_dq : 1'bz` is actually treated `t_dq ? 1'bz : pre_dq`

10:52 <_florent_> daveshah: interesting, i'll have a look. I did a quick test on hardware this morning. The DDR3 should be configured to output the MPR pattern and i just want to see if i get data from the DDR3, but i don't see activity at the IDDRX2DQA output for now. Your finding could explain what i see. I'm going to do another test.

12:00 <_florent_> daveshah: i'm now able to see the MPR (not each time, but that's a first good step :))

12:00 <daveshah> \o/

12:02 <_florent_> daveshah: that's all for today on my side, but i'll continue testing tomorrow morning

14:18 <somlo> catplant: looking for a good one to follow -- any recommendations?

14:19 <tnt> daveshah: btw, not sure if that's of interest, but I have a design that's quite a bit slower with heap (>10% slower in average over 20 runs) and one that just doesn't route (next-pnr just hangs a 100%)

14:28 <daveshah> tnt: happy to take a look, neither case awfully surprising though as it does produce higher wirelengths than SA for most designs

14:28 <daveshah> But some tweaking of heuristics can improve things

14:34 <tnt> daveshah: http://people.osmocom.org/~tnt/stuff/heap-tests.tar.bz2

14:41 <daveshah> Cheers!

16:54 <mossmann> azonenberg: Do you know if the SLG4662x configuration protocol is documented anywhere? I'd like to put some on a GreatFET neighbor.

17:05 <TD-Linux> somlo, whitequark's blog posts were immensely helpful

17:05 <TD-Linux> https://lab.whitequark.org/notes/2016-10-18/implementing-an-uart-in-verilog-and-migen/

17:05 <TD-Linux> https://lab.whitequark.org/notes/2016-10-19/implementing-a-simple-soc-in-migen/

17:13 <somlo> TD-Linux: Thanks -- saw those linked from http://m-labs.hk/migen/

17:14 <somlo> I'll be sure to read them carefully :)

20:18 <azonenberg> o/ mossmann

20:18 <azonenberg> So, good news and bad news

20:18 <azonenberg> Bad news: it's not publicly documented

20:19 <azonenberg> Good news: it's trivial to reverse engineer, basically SPI plus Vpp and a few mode pins

20:20 <azonenberg> Good news: I have access to their internal docs for the programming protocol on a "please dont share" gentlemans agreement basis, no written NDA (so I can share it within the open hardware community to some extent if there's a good reason)

20:20 <azonenberg> basically they dont want to deal with supporting it

20:20 <azonenberg> so they dont want it published

20:20 <azonenberg> Buuuut it isn't really usable as an in circuit programming protocol

20:21 <azonenberg> You have to keep in mind, until fairly recently greenpaks were intended to be sold as ASICs and being one-time programmable was just a way to cut mask costs

20:21 <azonenberg> So the programming protocol is an extension of the wafer-test mode

20:21 <azonenberg> Which means once you apply the right strap pins and Vpp, for example, random GPIOs turn into test points for analog IP blocks

20:22 <azonenberg> (for calculating trim values etc)

20:22 <azonenberg> So to properly in circuit program a 46620 you basically need to be able to tristate every pin with an analog mux, and you need ~7.5V tolerance on whatever is connected to pin... 2? i think

20:23 <azonenberg> you also have to be able to parallel strap a bunch of pins to set the mode (program sram, program otp, read sram, read otp, etc)

20:23 <azonenberg> in addition to the spi-esque "load bitstream" function

20:23 <azonenberg> the greenpak5 parts are I2C based and i think fully in system programmable

20:23 <azonenberg> in system programming of 4 i strongly recommend against

21:01 <mossmann> azonenberg: Yikes! Thanks for all the info!

21:04 <mossmann> azonenberg: Yeah, it sounds like we should go with a GP5. We were hoping to use SLG46621 because of the dual supply voltage ranges, number of I/O pins, and ADC.

21:05 <mossmann> azonenberg: (We plan to use it for a level shifting neighbor with fancy features for probing target systems.)

21:07 <azonenberg> It's not a bad part for the application as long as you pre-program

21:07 <azonenberg> The other benefit to GP5 for your application, though, is that via i2c you can load new bitstreams at run time

21:07 <azonenberg> So you dont even necessarily have to flash the otp at all

21:08 <mossmann> azonenberg: We definitely don't want to pre-program. We planned to load at run-time.

21:08 <azonenberg> you can dump a new bitstream on each boot like people do with a fx2

21:08 <azonenberg> Downside to gp5: no open HDL flow support yet

21:08 <azonenberg> i've been way too busy on my hosue to put any time into porting

21:09 <mossmann> Yeah, that's a major drawback, but it is something we could throw resources at too.

21:09 <azonenberg> the bitstream is documented, the only blocker is time and personnel

21:09 <azonenberg> I also wanted to do a major refactoring of my P&R

21:10 <azonenberg> the bitstream gen library is good, but my annealing algorithm sucks

21:10 <azonenberg> i was thinking of retooling it to use nextpnr as a bac kend

21:10 <azonenberg> in particular, my current algorithm does not handle "these two tiles share the same bitstream address and are mutually exclusive" well

21:11 <azonenberg> gp4 has only a handful of sites like that

21:11 <mossmann> It looks like SLG46538 is probably our best choice, but we have to deal with the toolchain problem and the lack of ADC.

21:11 <azonenberg> whereas with gp5 almost every tile can be either a lut or a digital IP block

21:11 <azonenberg> but not both at once

21:11 <mossmann> oh interesting

21:11 <azonenberg> So the placer has to be a lot more intelligent

21:11 <azonenberg> greenpak uses COTS TSMC 180nm efuse macros for the bitstream

21:11 <azonenberg> they're limited to exact power of two capacity and it isnt super dense

21:11 <azonenberg> So they optimize heavily for minimal bitstream size

21:12 <daveshah> On the subject of GreePAK, saw this recently https://twitter.com/AnttiBrain/status/1095404939378130944 / https://github.com/micro-FPGA/meM

21:12 <azonenberg> vs xilinx, say, has no problem makign the bitstream bigger to add more features

21:13 <azonenberg_work> daveshah: interesting

21:13 <azonenberg_work> thats only the second "virtualized FPGA" i've seen

21:13 <azonenberg_work> the other being my coolrunner-in-7-series

21:14 <daveshah> azonenberg_work: https://github.com/PrincetonUniversity/prga

21:14 <azonenberg_work> Actaully sorry third

21:14 <daveshah> Although it's not based on a real COTS FPGA in this case

21:15 <azonenberg_work> kurt rosenfeld from google/nyu did a thesis proposal for one

21:15 <azonenberg_work> i dont know how far he went

21:15 <azonenberg_work> (the committee rejected the ide)