<whitequark>
you'll need to hack download_bitstream in device/hardware.py or something
<whitequark>
my revA, revB and revC0 work just fine... it's only this revC1 that misbehaves. why
<tnt>
That bitstream works fine here :/
<whitequark>
ran it a few times with 100M?
<tnt>
Ran it 2 times with 1G
<whitequark>
yeah, should have done it
<whitequark>
it's very marginal
<daveshah>
Tried a different seed?
<whitequark>
let me try
<whitequark>
works with a different seed.
<daveshah>
Interesting
<whitequark>
my original problem is not fixed tho
<whitequark>
which is that the SPI applet hangs.
<whitequark>
though... it hangs with SA too
<daveshah>
Although if it works with HeAP changing the seed then it's probably just random
<daveshah>
Rather than significantly related to the placer
<daveshah>
Is this the FPGA that got overvolted?
<whitequark>
hm, the SPI applet hangs on revC0 with SA too
<whitequark>
so this is likely a logic bug
<daveshah>
Or a Yosys bug....
<whitequark>
ok, let's try yosys from april
<whitequark>
revC0 seems stable on benchmarks
<tnt>
whitequark: I guess it's only in specific cases that it hangs ? (because I used both a revB and revC1 to flash some spi flash yesterday just fine)
<whitequark>
tnt: with very large read sizes
<whitequark>
like >0x1000
<whitequark>
there is always 1 or 2 bytes left that are not transmitted for some reason
<whitequark>
oh I see
<whitequark>
this only happens with auto_flush=True
<whitequark>
this is likely a logic error in the arbiter then
<whitequark>
it could also be a ZLP issue.
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 3 commits to master [+0/-0/±5] https://git.io/fjDxL
<whitequark>
the problem with COBS is that i need to know the packet size beforehand
<whitequark>
yes
<tnt>
There is always HDLC ...
* tnt
goes hiding
* gruetzkopf
tapes a siemens tertiary rate HDLC controller to tnts head
<whitequark>
I think COBS is very nice because after each zero byte I can just encode the number of the applet or whatever
<whitequark>
sub-pipe
<whitequark>
and it can be decoded in-place without moves
<whitequark>
the cost is uhm... maintaining a BRAM with zero byte indexes?
<whitequark>
I wonder if that can actually be avoided somehow
<tnt>
yeah looks like you need to at least delay the input by up to 254 bytes.
<electronic_eel>
why not use a simple escape sequence for packetization?
<electronic_eel>
like 0x00 is the escape sequence
<electronic_eel>
0x00 0x01 means next packet for applet 1
<electronic_eel>
0x00 0x02 means next packet for applet 2
<daveshah>
You can also combine an escape sequence with a scrambler to avoid the pathological case of an applet sending the escape character repeatedly causing excessive overhead
<electronic_eel>
and 0x00 0xff means a 0x00 data
<whitequark>
electronic_eel: what daveshah said
<whitequark>
this can cause pathological expansion
<whitequark>
daveshah: maybe... but the thing is, I think being able to see applet data going by with an openvizsla, wireshark, etc is valuable
<daveshah>
yup, this is true
<whitequark>
added latency of 254 bytes when the applets are streaming data is not actually bad at all
<whitequark>
because USB sucks and adds a lot of latency all on its own, and applets have to handle it well anyway
<whitequark>
and when you are sending short packets, you don't need that much lookahead
<whitequark>
since you can terminate the packet early pessimistically (I think?)
<electronic_eel>
how would COBS help against pathological expansion? doesn't it create a sub-packet with a length-byte for every 0x00 in the data stream?
<whitequark>
nope
<whitequark>
it replaces each 0x00 with a pointer to the next 0x00
<whitequark>
so it adds at most one 0x00 byte per each 254 bytes
<whitequark>
that's kind of the point of COBS, to avoid pathological expansion
<electronic_eel>
ahh, I see
m4ssi has quit [Remote host closed the connection]
<marcan>
whitequark: yeah mine passes everything
<whitequark>
could be the abused ice40...
<whitequark>
ok
<whitequark>
let's assume that.
<whitequark>
can someone like... send me an ice40hx8k-bg121
<electronic_eel>
and how do you want to solder it in?
<marcan>
whitequark: we already have USB packets; it seems silly to introduce another framing layer
<marcan>
we already have to deal with That Problem
<marcan>
so just do what FTDI does (lol glasgow) and stick a header into USB packets
<whitequark>
marcan: hrm
<marcan>
fwiw openvizsla does its own packetization/framing stuff since it uses the same FIFO for both control packets and data
<marcan>
so you might want to check that for inspiration
<marcan>
but that's a more limited use case than glasgow
<marcan>
but yeah, the framing can be as simple as 1 byte applet ID, up to 511 bytes data per USB bulk packet
<marcan>
the FPGA needs to keep track of packet boundaries but that is just a counter
<marcan>
as long as we understand how the FX2 packetizes it's fine
<whitequark>
marcan: the FPGA already tracks packet boundaries
<marcan>
ZLPs etc are still the same issue, except we can replace them by 1-byte packets (which can even fix some corner cases)
<whitequark>
due to pipelining
<whitequark>
it's impossible to make it work reliably otherwise
<marcan>
so then this is easy
<whitequark>
not... quite
<whitequark>
the thing is that currently the crossbar will shuffle bytes between FIFOs and FIFOs without necessarily committing the IN packet
<whitequark>
this is actually kinda required if you want the transfers to be remotely fair
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
ali_as has quit [Remote host closed the connection]
carl0s has joined #glasgow
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow-Archive] whitequark pushed 1 commit to master [+1/-0/±0] https://git.io/fjyeS
<whitequark>
yeah, i sure am glad someone who actually understands analog stuff can help out with that
<whitequark>
because it's waaay out of my domain
<electronic_eel>
I just pretend I understand it ;)
<electronic_eel>
next step is esd protection for the inputs
<electronic_eel>
regular tvs diodes for high speed circuits won't work as they are usually for 5v or lower
<danilonc>
I know glassgow is not in mass production yet but is there a way to buy the C1 right now?
<danilonc>
I dont want to mess with BGA
<danilonc>
=P
<tnt>
danilonc: not really no.
<tnt>
There is only 2 people having built the revC AFAIK.
<tnt>
and in very small qty.
<electronic_eel>
you'll have to find someone who can mess with bga for you
<electronic_eel>
or wait a few months
<danilonc>
I will wait then, thank you guys!
<tnt>
I was digging into the ESD testing required to apply the CE mark, and damn, they'll basically zap everything exposed to the outside ...
<electronic_eel>
yes. without a case everything is outside so you don't stand a chance
danilonc has quit [Quit: WeeChat 1.9.1]
<electronic_eel>
tnt: you have a working revC1, right?
<tnt>
electronic_eel: I do
<electronic_eel>
do you have a case for it?
<tnt>
electronic_eel: Yeah, I 3d printed something. The print didn't turns out great (warping because the only 3dprinter I have access to is not great), but it works.
<electronic_eel>
you could use the spark generator from an electric lighter as a cheap & crude simulation of a esd gun
<electronic_eel>
isn't calibrated and so on, but if glasgow still runs it has a good chance of passing a proper esd test
<electronic_eel>
passing the esd test for ce usually means that the device must automatically resume normal operation afterwards
<tnt>
electronic_eel: the " if glasgow still runs " is a bit of an issue :p I only have one and no way to make another :p
<whitequark>
Glasgow is not subject to CE, is it? as test equipment
<whitequark>
I've never seen CE marks on devboards I think...
<electronic_eel>
if you want to sell test equipment it must have ce and pass all the tests
<whitequark>
interesting.
<tnt>
whitequark: I didn't actually find any exception for test equipment ...
<electronic_eel>
you just don't need ce if you build a one-off thing for your own (commercial) lab
<electronic_eel>
a lot of devboard manufacturers don't know better, don't care or fly under the radar
<whitequark>
I see
<tnt>
If sold without a case and no accessories, it might pass as "components" rather than finished product and then requirement are lighter I think.
<electronic_eel>
IIRC the rule is if a regular user can connect it with common tools, like plugging in a cable
<electronic_eel>
if it needs some special skills, like soldering, then it is a unfinished good / component
<whitequark>
it would be extremely expensive to go for wave soldering for the large connectors... so soldering is probably a given
<electronic_eel>
so a network card or graphics card for your pc needs ce, because a regular user can just plug it in
<tnt>
Well, if you pick 100 random people and give them a glasgow, chances are none of them will run anything.
<electronic_eel>
I know
<tnt>
whitequark: Ah yeah, good point.
<tnt>
(and obviously without the IO connectors it can't acomplish its primary purpose)
<electronic_eel>
yeah, no worries for glasgow
<electronic_eel>
but I am still curious if the esd protection we now have works
<whitequark>
oh I was actually going the other way around
<electronic_eel>
but it will have to wait until esden made some more so we can sacrifice one
<whitequark>
we shouldn't look at CE requirements but rather look at our own
<whitequark>
which might even be harsher
<electronic_eel>
I have a spark generator from an old car lying around somewhere...
<esden>
just as a heads up... I am still very time constrained due to icebreaker production... I will remain in that mode at least until mid August.
<electronic_eel>
esden: do you want to look over my test jig schematics or should I just start with the layout?
<esden>
I believe tnt gave you reasonable feedback.
<electronic_eel>
ok. how about form factor?
<whitequark>
esden: btw, did you send me the revC1 that underwent 3V3 on Vcore stress test?
<esden>
whitequark: sorry that I made a mistake on your glasgow.... :( This should not happen when the ESD diodes are placed with the machine not by hand. It is pretty good about doing repetitive tasks and keeping orientation right.
<whitequark>
it shows some really strange behavior and I'm worried if this is a gateware bug or a hardware issue
<esden>
It is possible... not sure. I can send you a replacement ice40 chip if you want to replace it.
<whitequark>
ideally yes. also a level shifter or a few
<whitequark>
that would let me restore it to a near pristine condition, hopefully.
<esden>
Also, the ESD diode packages are indeed pretty cursed... I am concerned about production reliability. I think removing the center pads is a good idea.
<esden>
then they end up being essentially QFN packages.
<whitequark>
mm, yeah
<whitequark>
makes sense
<electronic_eel>
esden: I think slim and longish with the sockets on the long side? If the fixture looks similar to https://twitter.com/xobs/status/1148781580330176512, you can then mount it on the underside of the lid. This keeps the cables short
<gruetzkopf>
i can give the current layout a cursory glance using rail tech regs meant for 80s digital logic, but that wouln't be useful
<esden>
electronic_eel: I got the contact to the same factory xobs used now. I did not have the time to contact them yet but I think I will get the same type of tester as I have that contact.
<electronic_eel>
ok, good to know. will go ahead with the layout then
<electronic_eel>
esden: I'll need a glasgow to test the test jig. Sometime around end of august to september. Can you make me one in that timeframe?
<esden>
ask me again next month when I have a better grasp on my workload
<electronic_eel>
ok
<esden>
I need to finish assembling ~600 icebreakers and 500 hdmi pmod and 500 led panel driver pmod first.
<whitequark>
that's a lot
<esden>
yes... it is
<gruetzkopf>
that's quite the run
<esden>
and that is only the first batch... aka half of what I need to finish before december.
<electronic_eel>
ugh, only the first batch?
<gruetzkopf>
c3 workshop again?
<esden>
gruetzkopf: hopefully
<electronic_eel>
no thoughts about outsourcing?
<gruetzkopf>
\o/
<esden>
I also had to squeeze in 200 bitmagic basic last weekend for Joe Fitz class...
<gruetzkopf>
outsourcing that is also annoying
<esden>
electronic_eel: lol... no that would take way longer and introduces a lot of risk
<gruetzkopf>
(especially so if you have to use certified manufacturer (or certify one) for rail safety things
<gruetzkopf>
and have annoying stuff like DIP4 optocouplers and MiniMELF resistors..
<electronic_eel>
hmm, don't know. timeframe "till december" seems realistic for outsourcing to me
<gruetzkopf>
(both unavoidable here)
<electronic_eel>
especially if you already got all the components
<esden>
electronic_eel: it is more complicated than that
<whitequark>
heh, MiniMELF
<whitequark>
round ones?
<esden>
if I ended up sending things to assemble I would now have ended up with hundreds of icebreakers that I can't send to backers... because I did it here I only screwed up 60
<esden>
I ordered wrong LED by accident...
<gruetzkopf>
big round ones :P
<esden>
no 200mcd vs 20mcd
<gruetzkopf>
(not micromelf)
<miek>
esden: got any spare bitmagic basic? can i buy one? :p
<esden>
miek: yep they are listed in the US store. :D
<gruetzkopf>
i absolutely *need* the pad distance AND the failure characteristics
<miek>
oh nice, cheers. can i get it from you at BH/DC?
<electronic_eel>
melf is quite nice, unless you have to assemble it ;)
<esden>
miek: YOU? NEVER! :P ... no of course I will have a bunch with me. :D
<miek>
:D
<gruetzkopf>
also wq definitly needs better optics for projecting her avatar. soo much chromatic abberation :D
<whitequark>
gruetzkopf: um.
<whitequark>
that's ... nevermind
<gruetzkopf>
only stereo display i have here takes interleaved R/L, not r/b :P
<whitequark>
gruetzkopf: cursed idea
<whitequark>
use nrf24le1 with glasgow for galvanic isolation
<whitequark>
wireless glasgow.
<gruetzkopf>
ooh
<gruetzkopf>
low bitrate (iirc 2MBit/s max?) but could be useful
<whitequark>
yes
<whitequark>
certainly enough for like,
<whitequark>
connecting to random I2C buses around your house
<gruetzkopf>
isolated actually working uart
<whitequark>
yes
<whitequark>
also if i ever get around to LU1 it would be a wireless usb uart
<gruetzkopf>
yes!
<gruetzkopf>
usb dongles with lu1+ are like 10USD
<whitequark>
it needs crypto tho.
<gruetzkopf>
(the large ones with PA and LNA)
<whitequark>
it has AES and i'm thinking PSK with Blake2s HMAC should do the job
<whitequark>
now, how do i implement AES
<whitequark>
(it only has a galois multiplier)
<gruetzkopf>
(i've never actually used the auto-retransmit 1:6 thingie made for wireless HID applications, currently trying to make a atmega128RF1A talk to them)
<whitequark>
oh cool
<gruetzkopf>
(because the semicursed smartresposne XE thingies contain the M128RFA1, and i don't have a full classroom kit to hack)
<miek>
are you not tempted to go for the nrf51822? i know it's not quite dirt cheap, but still under £2 for a board and.. it's arm :p
<gruetzkopf>
and it won't run with completely foss RF code
<miek>
it can
<whitequark>
1) fuck BLE 2) fuck RF blobs
<miek>
you can ditch the RF blob and just use the radio peripheral for whatever you want
<gruetzkopf>
sadly the atmel SAMR21 "only" includes some atmel RF TRX as a spi peripheral, not memory mapped like on the M128RFA1
<electronic_eel>
why not hook up the glasgow to a raspi with battery pack and use wifi?
<whitequark>
3) fuck raspi
<whitequark>
this is the sort of ridiculous non-solution i detest.
<whitequark>
you could solve something with a device that works off a coin cell for five years, and you solve it with a device that couldn't even boot off that cell.
<whitequark>
not to mention it's overpriced, flakey, and badly designed in general
<electronic_eel>
if you want to upload new gateware the rf ic would have to coordinate with the fx2 somehow
<electronic_eel>
seems like a can of worms to me with i2c multimaster and all
<whitequark>
no, the other way around
<whitequark>
the rf constellation is to use glasgow's tools for manipulating spi and i2c over air
<whitequark>
as well as getting an isolated uart
<whitequark>
e.g.: tired of reflashing your laptop's boot flash? stick an nrf inside and forget about wires.
<whitequark>
boot flash with a clip*
<electronic_eel>
ahh, I thought connecting from the pc to glasgow over rf
<whitequark>
right, no, that would probably just be a bad idea overall...
<electronic_eel>
but then you lose all the nice gateware, level shifters, protection,...
<whitequark>
it's a tradeoff, and it is my view that Glasgow is half software
<whitequark>
so being able to use half of it is still valuable
<electronic_eel>
but wouldn't you have to completely reimplement all the applets that handle connections to the dut to make it run on a microcontroller instead of an fpga?
<whitequark>
they already use an abstraction layer!
<whitequark>
SPIMasterInterface and so on.
<whitequark>
that was actually a part of my plan from the beginning; don't tie things like SPI to Glasgow gateware specifically
<gruetzkopf>
not like you can't map that to onboard peripherals (as long as they're not horrible)
<whitequark>
yeah the abstraction is pretty high level
<electronic_eel>
but nice stuff like the proper uart autobaud is often not part of microcontroller peripherals
<whitequark>
unfortunately.
<gruetzkopf>
hmm, a few years ago the mini-dongle nrf24lu1 boards didn't hide as much
<whitequark>
hide?
<gruetzkopf>
don't see any on aliexpress right now (may also simply be too tired to fight their search=