Stormwind_mobile has quit [Ping timeout: 240 seconds]
ali_as has quit [Quit: Bye!]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<niklas>
when compiling a bitstream for an ECP5, is there any way to "tune" the result?
<niklas>
I'm very slightly missing timing, which I notice by some glitches on the HUB75 panels
<niklas>
but only very slightly
<niklas>
like, wenn I remove one 64bit wide, completely unused reg it works just fine
rappet has quit [Ping timeout: 272 seconds]
rappet has joined #glasgow
Stormwind_mobile has joined #glasgow
futarisIRCcloud has joined #glasgow
<tnt>
niklas: when you say "very slightly" ... what does the timing report say ?
<niklas>
well...
<niklas>
Warning: Max frequency for clock '$glbnet$clock': 85.82 MHz (FAIL at 125.00 MHz)
<niklas>
Info: Max frequency for clock '$glbnet$display_clock': 78.36 MHz (PASS at 25.00 MHz)
<niklas>
Warning: Max frequency for clock '$glbnet$rgmii_rx_clk$TRELLIS_IO_IN': 109.90 MHz (FAIL at 125.00 MHz)
<tnt>
nextpnr timing are pretty pessimistic, so I'm a bit surprised that a "slight" timing error would cause anything in practice.
<tnt>
Ok, so 85 vs 125 is _not_ "very slightly"
<niklas>
very slightly as in "it works sometimes, sometimes not" :P
<tnt>
You can try different seed on nextpnr. You can try abc9 on yosys (if not already using that). But that kind of difference you probably need to change your design to fix the critical path.
<niklas>
okay thanks
<niklas>
I already did solve this issue by making that additional buffer even bigger, at some point it the just works again :D
<niklas>
is there any way to flash an ECP5 using glasgow?
<niklas>
programming works fine, but now I want to burn the flash
<tnt>
I think there is a script somewhere to generate a SVF that does that.
<whitequark>
then at first make the BSCAN sequences at host
<tnt>
\o/
<whitequark>
which will be very slow
<whitequark>
and maybe then somehow optimize it so it isn't
<whitequark>
I was thinking about this for a while but I hven't been able to spend much time workign lately
<tnt>
whitequark: huh ? This isn't using bscan AFAIK, the ecp5 has a spi tunnelling mode.
<whitequark>
oh
<whitequark>
ok that's much easier then
<whitequark>
how does it work?
<tnt>
There is a small init sequence to put it in that mode, then after, each 'Shift DR' or N bits will end up on the SPI bus and you get the result on TDO lagging by 16 bits.
<whitequark>
16 bits? not 8?
<tnt>
Apparently. I find it weird too ...
<whitequark>
ok if you give me some example i can just implement it
<whitequark>
i have a versa here
<tnt>
But like : SDR 32 TDI (00000050) TDO (A8FFFFFF) MASK (FF000000); this reads SR0
<whitequark>
tnt: I just need to enter SPI mode, right?
<whitequark>
one SIR;SDR
<tnt>
Mmm ... at some point you probably want to deconfigure the fpga or you won't have access to the spi pins right ?
<tnt>
I'm assuming that's why there is the "clear / erase".
<daveshah>
There is actually a bitstream setting for background SPI flash programming, but I would need to patch nextpnr to make it easy to set
<daveshah>
Also it comes with the significant compromise that once enabled you can't access SPI flash from the fabric at all, even if JTAG isn't used afaik
<daveshah>
The clear/erase works around that by clearing out the bitstream first
<tnt>
I guess sending that part could be a cli option if/when background spi flash is implemented and enabled.
<whitequark>
ah
niklas has quit [Ping timeout: 246 seconds]
diverger has quit [Read error: Connection reset by peer]
diverger has joined #glasgow
andres19 has joined #glasgow
gregdavill has joined #glasgow
_whitelogger has joined #glasgow
gregdavill has quit [Ping timeout: 246 seconds]
andres19 has quit [Quit: Ping timeout (120 seconds)]
ali_as has joined #glasgow
Stormwind_mobile has quit [Remote host closed the connection]
Stormwind_mobile has quit [Read error: Connection reset by peer]
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
andres48 has joined #glasgow
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #glasgow
andres48 has quit [Remote host closed the connection]
niklas has joined #glasgow
noobos has joined #glasgow
ali-as has joined #glasgow
ali_as has quit [Ping timeout: 246 seconds]
<_whitenotifier-3>
[glasgow] whitequark commented on issue #179: python modules not found after install - https://git.io/JvDID
Stormwind_mobile has quit [Ping timeout: 240 seconds]
ExeciN has quit [Ping timeout: 264 seconds]
<Spida>
what is the current time estimate for the crowdsupply?
<Spida>
I would be willing to populate a board myself, but I cannot do BGA/DFN/QFN...
<whitequark>
cc esden
<esden>
humm... I have a hard time giving any estimates at the moment. All I can say is that I am back on the campaign front this week. But I can't say for sure how long it will take to fill in the gaps and launch it though.
<esden>
Spida: what does it mean that you would be willing to populate the board but you can't do BGA/DFN or QFN... that is a contradictory statement ;)
<esden>
Does it mean, "the will is there but the flesh is weak?" ;)
<whitequark>
esden: I was thinking you'd answer that, and I'm wondering if we should make "no ETAs" a well visible policy
<whitequark>
in certain aftermarket Android firmware communities asking for a ETA is a bannable offense, I think doing that is a bit too far but I certainly see where they come from
<esden>
I will have to commit to ETA as soon as we launch the campaign. But those are generally understood that it is a crowd funding campaign and "things can happen", but that said, I have the rythm of one update a week during campaign and one update a month after the campaign until fulfillment is done.
<esden>
and those updates have to reflect the progress
<esden>
whitequark: ohh well... asking for ETA beyond that is annoying but understandable
<electronic_eel>
the question also is if esden wants to produce revC1 nearly as it is or incorporate most of niklas changes into it
<electronic_eel>
incorporating the changes incl. new parts would mean at least one round of testing
<whitequark>
yup
<electronic_eel>
the pricing possible with the new parts is really tempting...
<whitequark>
I think that pricing isn't something esden could provide
<whitequark>
but the yield improvement by ditching the current shifter package still seems significant, not to mention making assembly easier for everyone
<esden>
I will definitely go trough the BOM and create two of them. One with the current set of parts, and another with the easier to assemble parts.
<electronic_eel>
sure, he can't beat jlcsmt, but I think there still is significant price improvement possible
<esden>
I will be also sourcing proper quotes for the campaign. Then we can decide if it is worth waiting to incorporate the changes and go through another round of validation.
<whitequark>
makes sense
<esden>
the revC1 can be assembled reliably, if you turn a few of the stencil aperture and solder paste application knobs.
<esden>
it is only really a problem for the "casual assembler"
<esden>
or if you make a hand full at lcsc who does not put any effort into optimizing the process
<whitequark>
hm
<whitequark>
or for rework
<esden>
right
<esden>
still the as I said before, I like the changes ... especially if the new packages for the parts are easier to source and lower cost
<electronic_eel>
whitequark: I know you like to minimize risks and such...but when we do another round of validation, what do you think of replacing the ADC with the INA233 in revC2?
<esden>
electronic_eel: sbtw, the test jig board is finally being shipped to me this week.
<electronic_eel>
I would really like to have the ability to set a current limit
<electronic_eel>
electronic_eel: nice, lets hope it goes out with all the corona limits...
<whitequark>
electronic_eel: I'm open to that idea
<electronic_eel>
I meant esden of course
<whitequark>
since we have to revalidate revC2 anyway
<whitequark>
and it might also reduce cost further
<electronic_eel>
I think the costs are about the same, it has just much more features for us
<whitequark>
it removes a few passives, right?
<whitequark>
possibly a few passive values
<Spida>
esden: basically, yes :-) if anybody has an oven to reflow the bga and DFN, I could do the rest :-)
<electronic_eel>
yeah, you don't need the voltage dividers on the input
<whitequark>
that could make esden very happy :p
<whitequark>
Spida: what about hot air?
<whitequark>
not trivial, I know, but with some experimentation on sacrificial boards it's doable
Stormwind_mobile has joined #glasgow
<Spida>
whitequark: I do have hot air, but wasn't able to do QFN reliably in the past.
<electronic_eel>
in my experience you can do qfn with a bit of practice, but bga needs a more controlled environment to work well
<whitequark>
I only really reworked BGA, never actually assembled it from scratch
<electronic_eel>
and you can't re-do bga if it failed without a full reballing
<whitequark>
and I didn't find it -that- bad
<whitequark>
but I know it might take me more than one try with a Glasgow board if I tried
<whitequark>
now, reballing is an incredible pain in the butt
<electronic_eel>
I had some printer interfaces that had a manufacturing defect (bad soldering in the first years after rohs)
<esden>
We will also have to discuss the LVDS connector situation a bit too. There is a bit of a circular dependency between it being TH/SMD with location pins, Test jig top probes/not top probes or even added test pads on the bottom of the board.
<tnt>
My attempt at reballing a 0.5mm pitch ecp5 with just the "normal" stencil (i.e. same one I used for the whole board) didn't quite work out, too thin.
<esden>
Several people mentioned that they would love to use the LVDS connector for "things" so I think we should populate it. But if we do we have to test it.
<electronic_eel>
I got about 50% to work with a reflow, couldn't get the others to work
<esden>
I actually think the connector has to be tested even if we don't populate that connector.
<esden>
or rather pads have to be tested that the signals are not shorted or something
<whitequark>
doesn't your fab offer 100% etest?
<whitequark>
or do you mean assembly issues?
<esden>
yes
<whitequark>
I think we could use, uhm
<esden>
if the bga is connected correctly
<electronic_eel>
esden: ah, yeah the lvds testing we talked about
<whitequark>
boundary sc... we don't have boundary scan on ice40, damnit
<tnt>
esden: buy an xray :p
<whitequark>
we could use a test bitstream that does the same thing as bscan
<esden>
tnt: I am seriously consideridng it! no joke!
<electronic_eel>
we don't need boundary scan, we could use the test bitstream
<electronic_eel>
unfortunately the ice40 just has pullups, not pulldowns
<whitequark>
can bitblast it
<whitequark>
well, test bit by bit
<whitequark>
it'll be just a few milliseconds if we look for hard shorts
<esden>
that is already better than nothing whitequark
<esden>
if we connect the test jig to the pins, I will have to at least use a connector that has locating pins, so that is a small change to the pcb to add those holes
<esden>
honestly having that connector well located is useful for the user too
<whitequark>
definitely true
<whitequark>
but... no space for it I think
<whitequark>
it's super tight there
<esden>
no space for locating pins? humm, I will have to take a look then.
<electronic_eel>
esden: you mean soldering the connector and then try to hit the pads with a jig from above?
<esden>
no if we stay with the SMD connector, we would go with cup pogopins onto the pins themselves
<esden>
if we don't populate the connector, we go onto the pads
<esden>
if we change to a TH (that will be really hard, there is not really enough routing space for that) then we can go from the bottom with cup pogopins.
<electronic_eel>
yeah, if we don't populate that isn't that hard.
<electronic_eel>
the smt connector is quite expensive, right?
<esden>
not really, only if we get a samtec connector it is expensive
<esden>
I would source it from a korean or chinese manufacturer instead
<electronic_eel>
have you checked for alternatives in this size that aren't samtec?
<esden>
they make to order connectors, but you have to buy 5k of them or so
<electronic_eel>
hmm 5k glasgows...
<electronic_eel>
isn't that a bit too many?
<whitequark>
it's quite a few
<esden>
I did things like that in the past. I have bags of some connectors still sitting here for an old project. At the end it was still cheaper than buying existing connectors from an established manufacturer.
<electronic_eel>
but still a part of your earnings end up in dead stock
<esden>
Yeah, but I would have spent even more on COGs if I went with the more expensive connectors. The price difference can be 1/10th of the price if not less.
<esden>
so if you buy a 100 of the expensive connector you can buy 1000 of the cheap one. And who knows how many glasgows will sell? The interest is there. :)
<electronic_eel>
I have seen that samtec offers these connectors with locating pins on the bottom. that would improve positioning accuracy without the need to go full tht
<esden>
yeah exactly and I would try to find an alternate source that is less expensive than samtec for those.
<esden>
anyways, first we need to see if I can add the locating pins at all to the board layout...
<esden>
and I will do that based on the samtec locating pin diagrams
<electronic_eel>
hmm, when I look at the layout adding the locating pins seems completely easy to me
<electronic_eel>
at least the samtec ones are at like the second row on each side, between the pads
<electronic_eel>
we have just vias to gnd at that position, we could easily move these above
<whitequark>
ah I misunderstood
rappet has quit [Quit: No Ping reply in 210 seconds.]
<esden>
I did order ACES connectors in the past... (they make really nice black picoblade compatible connectors)
<electronic_eel>
they look nice!
<esden>
I will contact them and ask for samples.
<esden>
I am happy to stock those connectors in the future for those that want to put their own glasgows together. (I do that already for the jtag connectors so not a big deal)
<electronic_eel>
could you also ask them for mating connectors?
<electronic_eel>
I checked the samtec ones, they are nice but like 5$ each
<esden>
Yeah of course. Just smd?
<esden>
or TH too... TH is usually a bit of a pain to route...
<electronic_eel>
I'd say yes, just smd with these positioning pins
<whitequark>
niklas: I think the test board actually has an ina233 already
<electronic_eel>
niklas: I don't have finished schematics yet, but I described what I want to do in the issue tracker
<electronic_eel>
whitequark: no, it is another variant on the test jig board
<whitequark>
ohh
<electronic_eel>
ina260
<electronic_eel>
i found the ina233 like two or three weeks after we selected the ina260 for the test jig board
Stary has joined #glasgow
<whitequark>
i see
<electronic_eel>
niklas: do you have published your schematics changes with the new parts and so on somewhere?
<electronic_eel>
the current that the ina233 should measure is the current over the 0.68 ohms resistor after the TPS73101
<electronic_eel>
the voltage to measure is directly the vsense input, without voltage divider (since it can measure up to 37v, but the tvs diode will prevent going so high)
<electronic_eel>
we could also use a different tvs diode, but I'm not sure that its worth it
<niklas>
so no more Vsense?
<electronic_eel>
vsense yes, but no more vsamp
<awygle>
the voltage divider is at least in part to a) filter the input to the ADC and b) increase the impedage on the vsense line so it's not too much of a draw on the DUT
<awygle>
... "impedage"? impedance.
<electronic_eel>
the ina233 has a high impedance input that can go up to 37v, so no voltage divider necessary