<openfpga-bot> [jtaghal] azonenberg pushed 3 new commits to master: https://git.io/fAGeH
<openfpga-bot> jtaghal/master 0ea4bc3 Andrew Zonenberg: Moved a bunch more stuff into FTDIDriver
<openfpga-bot> jtaghal/master 9bac008 Andrew Zonenberg: Refactored a lot of shared functionality out of FTDIJtagInterface into new FTDIDriver class
<openfpga-bot> jtaghal/master 57a7fe7 Andrew Zonenberg: Removed support for "recoverable errors"
futarisIRCcloud has joined ##openfpga
inoor has quit [Quit: inoor]
Miyu has quit [Ping timeout: 252 seconds]
pie_ has quit [Ping timeout: 272 seconds]
digshadow has left ##openfpga [##openfpga]
<whitequark> awygle: ok yeah this is *definitely* fx2 side issue.
<whitequark> i wrote an spi core and shorted mosi/miso inside the fpga
<whitequark> i can write e.g. 0f0f0f0100 just fine
<whitequark> but trying to write 00000001 breaks sync
<whitequark> actually, it's more like that packets of exactly 4 bytes don't work very well...
<sorear> .oO( need logic analyzer to debug logic analyzer )
<cr1901_modern> start by bootstrapping a one channel LA out of sand
sorear has quit []
sorear has joined ##openfpga
kem_ has quit [*.net *.split]
benreynwar has quit [*.net *.split]
Mimoja has quit [*.net *.split]
specing has quit [*.net *.split]
Mimoja has joined ##openfpga
benreynwar has joined ##openfpga
specing has joined ##openfpga
kem_ has joined ##openfpga
specing has quit [Changing host]
specing has joined ##openfpga
futarisIRCcloud has quit [Read error: Connection reset by peer]
futarisIRCcloud has joined ##openfpga
digshadow has joined ##openfpga
AlexDaniel-old[m has quit [*.net *.split]
finsternis has quit [*.net *.split]
utzig has quit [*.net *.split]
lain has quit [*.net *.split]
dingbat has quit [*.net *.split]
kc8apf has quit [*.net *.split]
esden has quit [*.net *.split]
utzig has joined ##openfpga
finsternis has joined ##openfpga
lain has joined ##openfpga
kc8apf has joined ##openfpga
dingbat has joined ##openfpga
lain is now known as Guest29485
<awygle> whitequark: interesting. how fast is that bus, 30 MHz?
* awygle starts digging through misc test equipment
AlexDaniel-old[m has joined ##openfpga
Guest29485 has quit [Client Quit]
esden has joined ##openfpga
lain__ has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
<whitequark> awygle: yeah
<awygle> i'm not sure i have anything that can sample a bus that wide that fast
lain__ has quit [Client Quit]
<awygle> i can get up to 4 signals though, which might be enough to see something
lain__ has joined ##openfpga
<gruetzkopf> deserialise it and bring it to 60V logic level, then i can help
unixb0y has joined ##openfpga
lain__ is now known as lain
<awygle> i have plans for tonight, but i'll try and take some images and stuff either this evening or tomorrow
mmicko has quit [Read error: Connection reset by peer]
mmicko_ has joined ##openfpga
<gruetzkopf> (at up to 2000ch currently :P
<awygle> "ch"?
<gruetzkopf> channel
<awygle> oh
<gruetzkopf> only 10kHz sample rate
<awygle> that number was far enough out of bed with my expectations of # of channels i assumed "ch" was the german equivalent of "Hz" as an abbreviation or something
<gruetzkopf> this is prototype stage
<gruetzkopf> it'll have to scale at least to 100x that
<whitequark> awygle: jesus christ on a stick
<awygle> .... yes?
<whitequark> awygle: https://imgur.com/a/PYoIYUF
<whitequark> CS, SCK, MOSI, MISO
<awygle> .... that's a thing.
<awygle> ah shit i literally cannot look at this right now. back in ~3h
<whitequark> SCK and MOSI are adjacent in a ribbon cable.
<whitequark> ... we're gonna have to recommend using those ultradma cables don't we
<gruetzkopf> hehe, i've solved a fair amount things in this design with software that should really be hardware
<gruetzkopf> (like the bitbanged 8*SPI interface)
digshadow has quit [Ping timeout: 260 seconds]
<whitequark> awygle: 4 signals should be enough
<whitequark> if I use only every other pin this goes away
<whitequark> and I can read the SPI flash properly
<sorear> How is the ribbon cable involved?
<gruetzkopf> coupling the channels
<sorear> Trying to remember where on the board the ribbon is
<whitequark> it isn't
<whitequark> it's how I connect Glasgow to DUT
<whitequark> but it's not just that
<whitequark> the channels are coupled on the board itself too
GenTooMan has quit [Quit: Leaving]
renze has quit [*.net *.split]
balrog has quit [*.net *.split]
marcan has quit [*.net *.split]
jhol has quit [*.net *.split]
daveshah has quit [*.net *.split]
jeandet has quit [*.net *.split]
grummel has quit [*.net *.split]
Xark has quit [*.net *.split]
G33KatWork has quit [*.net *.split]
Prf_Jakob has quit [*.net *.split]
ayjay_t has quit [Write error: Connection reset by peer]
jhol` has joined ##openfpga
G33KatWork has joined ##openfpga
daveshah has joined ##openfpga
Xark has joined ##openfpga
Prf_Jakob has joined ##openfpga
marcan has joined ##openfpga
grummel has joined ##openfpga
jeandet has joined ##openfpga
Xark has quit [Changing host]
Xark has joined ##openfpga
renze has joined ##openfpga
<whitequark> awygle: remember i asked you to file a request with fairchild about their goddamn level shifter?
<whitequark> did they respond anything?
renze is now known as Guest76140
ayjay_t has joined ##openfpga
balrog has joined ##openfpga
_whitelogger has joined ##openfpga
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 268 seconds]
<awygle> whitequark: no, no response
<awygle> do I remember right that the pinout of the connector should put a ground between each signal pair?
<awygle> In case of idc ribbon that is
<awygle> If there's crosstalk on the board it has to be before the level shifter, the traces fan out after it and there's very little length for coupling anyway
<awygle> so I'd guess whatever there is is being amplified by the level shifter
<whitequark> awygle: right, it was just that I used a single row ribbon
<whitequark> not idc
<whitequark> and I think that it's before level shifter too
<awygle> oh okay, that makes me feel better
<whitequark> i'm going to sleep now but i'm very interested in your thoughts on how to proceed from heree
<awygle> if it was coupling through a guard ground, or i'd f'd up the pinout, i was gonna be scared or ashamed respectively
<awygle> okay, sleep well. i sort of think we might be fine with the termination added to rev B but we should be able to spread the traces out a fair bit as well
<awygle> i'd like to get a scope shot of the actual crosstalk but that'll have to wait for tomorrow for me as i need sleep too
<cr1901_modern> 300 lines... Jesus Christ ._.
<cr1901_modern> I need to get in on this newfangled riscv thing...
<awygle> it does sound like you
* awygle zzz
m_w has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg_work has joined ##openfpga
mIKEjONES is now known as mIKEjONES2
<rqou> arrgh seriously why are triac packages all so friggin huge?
<prpplague> rqou: i know right, it's so triagic....
* prpplague smirks at his "dad joke"
<rqou> apparently nobody wants sot-23 triacs?
<rqou> hmm that's interesting
<rqou> china seems to have some
<rqou> but they're not the normal packages for the part
<azonenberg_work> rqou: something something IEC 60950
<azonenberg_work> Chinesium devices dont have to worry about being UL listed :p
<azonenberg_work> you know, the types of gizmos that have usb port shields floating at 120VAC?
<rqou> wait, how is this a safety issue?
<azonenberg_work> There is a minimum spacing between line and low voltage
<azonenberg_work> That may not be possible to achieve with a small package
<rqou> i thought this is only for line-connected equipment?
<azonenberg_work> Some boards go so far as to have slots in the FR4 to provide a full airgap
<azonenberg_work> That's for any HV to anything a user can touch, afaik
<rqou> hmm really?
<rqou> even things like plasma globes
<rqou> ?
<rqou> or demonstration van de graff generators?
<azonenberg_work> I dont have the full standard in front of me, it's paywalled
<azonenberg_work> but my gut feeling is that there are no small triacs because its impossible to meet safety standards for line voltage using a small package
<azonenberg_work> And there isnt enough demand for weird triacs in tiny spaces for them to make small packages for niche applications
<rqou> i'm not actually trying to switch line voltage though
<azonenberg_work> Doesnt matter, they're built for the mass market
<azonenberg_work> not for weird applications like segmented EL displays
<azonenberg_work> (is that even a thing?)
<rqou> no it isn't :P
<rqou> basically only me and another hobbyist have tried it
<azonenberg_work> Which explains why custom silicon thats only useful for that purpose doesn't exist :p
<rqou> except china claims to have cloned these triacs into sot-23 packages
<rqou> i wonder what those are for?
<daveshah> Cheap flashing Christmas lights would be my guess
<rqou> i thought those are usually LED?
<azonenberg_work> Yes
<azonenberg_work> Do you know how cheap christmas lights work?
<rqou> also, that _does_ actually have safety concerns unlike my EL hacks
<rqou> bimetallic strips? :P
<azonenberg_work> no i dont mean the flashers
<azonenberg_work> i mean cheap LED strings
<azonenberg_work> You take strings of LEDs and hook them in series until Vf = ~110V, put a small resistor in series with that string
<azonenberg_work> Then put two of those back to back
<azonenberg_work> and feed them with mains
<azonenberg_work> they alternate flickering at 60 Hz
<azonenberg_work> It looks awful but is cheap
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 252 seconds]
m4ssi has joined ##openfpga
m_w has quit [Ping timeout: 246 seconds]
m4ssi has quit [Ping timeout: 245 seconds]
scrts has quit [Ping timeout: 252 seconds]
m4ssi has joined ##openfpga
scrts has joined ##openfpga
<rqou> azonenberg_work: whelp, a 14-segment decoder doesn't fit in an slg46620v
<rqou> what are these things useful for exactly?
<rqou> azonenberg_work: how did you fit an ethernet autonegotiation logic into this?!
<azonenberg_work> rqou: lol
<azonenberg_work> The pattern generator
<azonenberg_work> i generated a single canned autonegotiation codeword with it, then used timers to send at the correct interval
<azonenberg_work> Ignored the inbound data
<rqou> but still, *how*?!
<azonenberg_work> Then after a while started sending idle pulses on another timer
<rqou> i can't get a 14-seg decoder to fit
<rqou> you know, what people build for class for fun or something
<azonenberg_work> i made extensive use of the hard IP
<azonenberg_work> you know, how you're supposed to use these things
<azonenberg_work> And i wasnt filling the chip either
<azonenberg_work> i think i had room to do more fun stuff
<azonenberg_work> for example, i bet with some effort i could have actually implemented checking the autonegotiaiton ACK bit plus detecting remote link state properly
<azonenberg_work> rqou: What does a 14-seg decoder do?
<azonenberg_work> your biggest problem honestly is going to be I/O pin limitations IMO
<rqou> you know, digital electronics 101
<rqou> i actually run out of LUTs
<azonenberg_work> So, first off
<azonenberg_work> Do you actually need the blank mode?
<azonenberg_work> Or can you just cut power to the display somehow
<rqou> traditionally people had this :P
<azonenberg_work> That would remove 14 2:1 muxes
<rqou> still no good
<rqou> abc returns 28 $luts
<azonenberg_work> Let's see, so your "state" is a shift reg fed by the input?
<rqou> yeah
<rqou> and that does infer correctly
<azonenberg_work> It does infer two GP_SHREGs?
<rqou> just one?
<azonenberg_work> One GP_SHREG has two outputs
<azonenberg_work> You are probably using lut+ff logic for the other two
<azonenberg_work> Sounds like it didnt infer right
<rqou> oh hmm actually idk
<azonenberg_work> Try explicit GP_SHREG instantiation
<rqou> it was inferring correctly before i added the actual decode logic :P
<azonenberg_work> Lol
<azonenberg_work> Check
<azonenberg_work> The inference logic for shregs works well for 2 outputs, and i think supports cascading for >16 bits depth
<rqou> but seriously this should just work
<azonenberg_work> but i dont know if i have support for 3+ bit shregs
<rqou> this is like EE101-style code
<azonenberg_work> And well, you are really pushing lut capacity
<azonenberg_work> On a slightly larger part it would work fine
<azonenberg_work> The problem is that i havent had the time to implement the extremely aggressive area optimizations that you need to fit a complex design into a chip this tiny
<rqou> well, it's not like we support any of the larger parts do we :P
<azonenberg_work> Things like using a counter's LSB as a spare DFF when you run out
<rqou> don't make me actually go write ShinyKinglerPAR
<azonenberg_work> The 46620 is actually one of the biggest greenpaks in terms of lut capacity
<azonenberg_work> many of the newer ones have fancy hard IP but actually *less* general fabric logic
<azonenberg_work> They also have a lot more shared tiles so they may seem to have a lot of stuff but the number of usable sites isnt that much
<azonenberg_work> e.g. most of the counters conflict with a lut so you cant use both
<azonenberg_work> in the 46620 almost nothing is shared
<azonenberg_work> Which makes it both easy to PAR for, and greatly increases usable capacity
<azonenberg_work> Basically, i think your RTL as written is impossible to fit in a 46620 but i suspect that if you abuse the hard IP just right, it can be made to fit
<azonenberg_work> Since you are so close to fitting
<rqou> but you see how this really seems like it should work right? :P
<azonenberg_work> But fix the shregs first, then send me the placement report
<rqou> people would be quite sad to find that it doesn't
<azonenberg_work> That doesnt seem like it should work
<azonenberg_work> Just look at the io count, you're using every pin with complex combinatorial logic (wide input muxing)
<rqou> i actually have no idea how to instantiate a shreg
<azonenberg_work> that's the kind of thing that a product term CPLD excels at
<azonenberg_work> But it eats luts
<azonenberg_work> Coolrunner would eat this for breakfast
<rqou> yup, like i said, EE101 :P
<azonenberg_work> Pastebin me the yosys and gp4par logs?
<azonenberg_work> actually just yosys
<rqou> oooh right i forgot, gp4par has a *manual*
<azonenberg_work> Hmmm
<azonenberg_work> So i have a guess as to what might be going on
<azonenberg_work> You'd have to play with the synthesis script to test
<azonenberg_work> shregmap is run after nlutmap
<rqou> i'll test this later
<azonenberg_work> So it doesn't actually extract the shreg cells until after the luts are mappe
<azonenberg_work> mapped*
<azonenberg_work> But i dont think shregs would normally use luts
<azonenberg_work> so i dont think it makes a difference
<azonenberg_work> I think your design is just too big
<rqou> whelp
<rqou> it's really hard to find an application where greenpak is actually good
<rqou> btw azonenberg_work did you see my message that you need to go shill to these people? https://hackaday.io/project/28389-andxor-dc26-badge/log/146680-yet-another-way-to-debounce-a-button
<azonenberg_work> yeah i saw
<azonenberg_work> and greenpaks are meant for control
<azonenberg_work> Not datapath
<azonenberg_work> they can do small to medium sized state machines with a fair number of inputs and decently complex transitions just fine
<azonenberg_work> What they suck at is wide combinatorial logic
<azonenberg_work> The exact opposite of something like a coolrunner where a 32-bit shreg uses up all of your fabric
<azonenberg_work> but a bunch of big 8:1 muxes are just fine
<azonenberg_work> An xc2c32a can, for example, fit a 16-bit 2:1 mux while using exactly all of the io pins
<azonenberg_work> The hard IP in greenpak can make up for some, but not all, of the limited lut capacity
<azonenberg_work> counters and shregs are common in control plane applicatoins and not having those in fabric lets you do surprisingly complex stuff
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
jhol` is now known as jhol
Prf_Jakob has quit [Changing host]
Prf_Jakob has joined ##openfpga
m4ssi has quit [Ping timeout: 240 seconds]
WilhelmVonWeiner has quit [Quit: leaving]
WilhelmVonWeiner has joined ##openfpga
m4ssi has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
ironsteel has quit [Remote host closed the connection]
sgstair_ has joined ##openfpga
sgstair has quit [Disconnected by services]
sgstair_ is now known as sgstair
pie_ has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
mumptai_ has quit [Quit: Verlassend]
X-Scale has quit [Ping timeout: 244 seconds]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
esden_cloud_ has quit []
esden_cloud_ has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
marcan has quit [Quit: Now where's my screwdriver...]
marcan has joined ##openfpga
rohitksingh has joined ##openfpga
X-Scale has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
m_w has joined ##openfpga
Miyu has joined ##openfpga
<shapr> rqou: did you get that ancient russian plasma panel working?
<shapr> I've been ignoring mine in favor of learning verilog
<rqou> whoops, backlog
<qu1j0t3> shapr: I'm also interested in anything about that panel, as an owner
<shapr> I haven't looked to see if that hackaday project was updated
<qu1j0t3> the older one hasn't
<qu1j0t3> i think i didn't stumble on the newer one with the pcb etc
<qu1j0t3> recently
kuldeep has quit [Ping timeout: 264 seconds]
kuldeep has joined ##openfpga
<prpplague> rqou: just had to go check my bottle
mumptai has joined ##openfpga
<rqou> um... did somebody try to PM me?
<rqou> i just got "[13:26] (Error) This message is encrypted, but no key is set."
<etrig> the /msg is coming from inside the house!
<rqou> quite possible
<rqou> znc messes with stuff quite a bit
azonenberg_work has quit [Ping timeout: 245 seconds]
GenTooMan has joined ##openfpga
azonenberg_work has joined ##openfpga
Zorix has quit [Read error: Connection reset by peer]
Zorix has joined ##openfpga
Zorix has quit [Remote host closed the connection]
Zorix has joined ##openfpga
<openfpga-bot> [jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fAZHs
<openfpga-bot> jtaghal/master 3120a2c Andrew Zonenberg: Continued initial SWD implementation
Zorix has quit [Remote host closed the connection]
Zorix has joined ##openfpga
Bike has joined ##openfpga
m_w has quit [Quit: leaving]