<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>
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
<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>
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?