<whitequark[cis]>
Never implement digital designs.
<whitequark[cis]>
Please don't. Cause of failure
<whitequark[cis]>
This may be the cause
<Wanda[cis]>
it's worse when you're also implementing the underlying HDL
<whitequark[cis]>
Not possible to implement an HDL and have it work.
<whitequark[cis]>
It is not possible
redstarcomrade has quit [Read error: Connection reset by peer]
<Wanda[cis]>
uh-huh
<Wanda[cis]>
the scope has been pulled out
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<whitequark[cis]>
currently debugging a completely unhinged issue where a comb signal enters the FPGA perfectly square, and after some comb propagation, exits it glitchy
<sorear>
no LUTs, just wires?
<Wanda[cis]>
... hopefully so
<Wanda[cis]>
current status: looking at nextpnr gui to check
<Wanda[cis]>
and by that, I mean current status: assertion failure in nextpnr
<whitequark[cis]>
that was just the wrong architecture being loaded, coupled with great error reporting
<whitequark[cis]>
but yeah
<whitequark[cis]>
so we have pin A7 (glasgow connector) SB_IO driven on D_OUT_0 with multiplexer_port_a_1__io__i
<whitequark[cis]>
i am sorry this is fucking what?
<whitequark[cis]>
moreover, we've been seeing glitches even with a register added
<whitequark[cis]>
which is how we started investigating this with a simple comb connection in first place
<whitequark[cis]>
it doesn't even go through LUTs
<whitequark[cis]>
it's just two span4 wires and some local interconnect
<whitequark[cis]>
what
<whitequark[cis]>
if it wasn't the fact that we've been seeing glitches in flop outputs i would have suspected the somewhat sketchy wiring harness
<whitequark[cis]>
but this seems to be the FPGA? what is going on
M87910[m] has joined #glasgow
<M87910[m]>
This is very close to one of the things I'm most excited to measure with the SLJ scope when I get my glasgow
<whitequark[cis]>
measurement artifact, it looks like
<whitequark[cis]>
not sure what's up with the flops. and also it still doesn't seem to transmit
<whitequark[cis]>
despite all of the rx data being perfectly looped back
redstarcomrade has quit [Read error: Connection reset by peer]
trh has quit [Quit: weg]
trh has joined #glasgow
FFY00 has joined #glasgow
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
duskwuff[m] has quit [Quit: Idle timeout reached: 172800s]
jstein has joined #glasgow
jstein has quit [Quit: quit]
redstarcomrade has joined #glasgow
q3k[cis] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
Attie[m] has quit [Quit: Idle timeout reached: 172800s]
jstein has joined #glasgow
tomkeddie[m] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has quit [Read error: Connection reset by peer]
maj1030[m] has quit [Quit: Idle timeout reached: 172800s]
siriusfox has quit [Ping timeout: 255 seconds]
siriusfox has joined #glasgow
notgull has joined #glasgow
notgull has quit [Ping timeout: 260 seconds]
Guest74 has joined #glasgow
Guest74 has quit [Client Quit]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
coflynn[m] has joined #glasgow
<coflynn[m]>
Used Glasgow to dump a NAND/DDR combo chip I had broken out a few months ago & put aside as it was going to be a hassle... basically just worked(TM)! Thanks for the project!
<coflynn[m]>
Yeah, memory-onfi, played around with some of the RTL generation and pretty amazing being able to change on the fly!
<coflynn[m]>
Had some SI issues due to my very terrible breakout... which made me think of making a breakout for glasgow with R/C slew limiters. Is there an name for hat/breakouts/etc?
<esden[m]>
Now I can finally finish packing the care package for Wanda 😉
<whitequark[cis]>
niiiiice
<whitequark[cis]>
1 Gbit per chip?
<esden[m]>
no just 512 per chip but 1Gb for the bodule.
<Wanda[cis]>
looks nice!
<esden[m]>
*module
<whitequark[cis]>
no, total
<esden[m]>
I will eventually make nicer stickers that indicate the type of the RAM-Pak and spans the tops of both chips. To avoid confusion.
<esden[m]>
But I do think I will just make the 1Gbit paks... it makes most sense at the moment.
<whitequark[cis]>
yeah, plus we can detect it via software easily enough
<whitequark[cis]>
one for me, one for Wanda?
<esden[m]>
I will assemble more of them now that I know they work. So yes, there is definitely one for you Catherine. 😄
<whitequark[cis]>
(mainly asking since 1 Gb density will need to be validated and there's also software to write that adds the ram-pak type in EEPROM, etc
<esden[m]>
nanographs also wants some
<whitequark[cis]>
* EEPROM, etc)
<whitequark[cis]>
hell yeah nanographs
<esden[m]>
Ohh I know! Don't worry 😄
<whitequark[cis]>
sticker suggestion: "✔ Bee Movie Proven"
<esden[m]>
LOL! Yes 😄
<tpw_rules>
i would like one if there are spares...
<esden[m]>
After I send the allocated units to the core devs. I will probably make the rest available in the store for eager early adopters. So we can shake things out. There is a bunch of stuff I have to figure out if I want to regularely manufacture the ram-paks... the 0.5mm thin PCBs are an interesting challenge.
<Wanda[cis]>
oh holy shit I just now realized it wits within the case
<Wanda[cis]>
s/wits/fits/
<esden[m]>
Yeah it does 😄
<esden[m]>
It was an interesting packing challenge 😄
<cyrozap>
Wow, I was literally just about to ask about that--really glad to hear it fits!
<esden[m]>
this is why we used the reverse entry socket.