WilhelmVonWeiner has quit [Quit: leaving]
wbraun has joined ##openfpga
<TD-Linux> anyone used vhdl to verilog translators?
<TD-Linux> I want to convert TG68K to verilog
<q3k> nothing f/loss iirc
<q3k> the only thing i've used personally is vhdl -> verilog via verific/yosys
<TD-Linux> bleh. might be a manual transation then :(
<whitequark> daveshah: poke?
wbraun has quit [Quit: wbraun]
GenTooMan has joined ##openfpga
unixb0y has joined ##openfpga
unixb0y_ has quit [Ping timeout: 252 seconds]
<TD-Linux> has anyone done a sdram controller on ice40?
<SolraBizna> Bob_Dole keeps trying to get me to
<SolraBizna> it should be possible
<TD-Linux> what speed do you think you can squeeze out? 25mhz?
<SolraBizna> I have no idea what I'm talking about, but I think more than that should be doable
<TD-Linux> 50mhz would be great
wbraun has joined ##openfpga
<SolraBizna> the sane thing to do to debug my softcore is implement JTAG, right?
<sorear> riscv?
<sorear> i forget what you were doing
<SolraBizna> yep
<whitequark> jtag isnt a super great debug interface
<whitequark> most jtag based debuggers implement a virtual channelover jtag
<whitequark> could as well do that directly
<whitequark> unless you're aiming for compatibility with something existent
<SolraBizna> I'll end up having to write everything on both ends either way, so I'm not attached to compatibility
<SolraBizna> if my softcore was working on a basic level, I could debug it the badass way
<SolraBizna> or if I had an oscilloscope...
<SolraBizna> the only IO I have that is working is that I have intermittently gotten it to affect the LED in a way that is only vaguely related to what I'm doing
m_w has quit [Quit: leaving]
GenTooMan has quit [Quit: Leaving]
<whitequark> oooo
<whitequark> i got lock
<sorear> are you at this point trying to get the lattice demo working?
lovepon has joined ##openfpga
<sorear> SolraBizna: hey if you have blinky working and are sufficiently methodical about it, 1 bit of output is plenty to debug a design ;)
<sorear> SolraBizna: there's the "risc-v external debug specification" which is jtag-based and you could use with unmodified openocd, but i'd be surprised if you can implement it with less than 1000 luts
<whitequark> sorear:
<whitequark> no
<whitequark> lattice demo works fully
<whitequark> im writing my own phy
<sorear> getting lock seems like a challenge when the other side is resetting the link every few microseconds
<whitequark> every 40 ms
<whitequark> and it only needs a few cycles to lock
<gruetzkopf> you locking on pcie?
<whitequark> yes
<gruetzkopf> neat
<sorear> ispCLOCK datasheet defines IDCODE as 00010110, I thought we were saying that couldn't happen
<whitequark> that could
<whitequark> then autodetection just breaks
<azonenberg_work> i didnt think there was a standard for idcode instructions
<azonenberg_work> only idcode *data*
<whitequark> oh wait
<whitequark> yeah
<azonenberg_work> the instruction is defined as "whatever is in IR upon reset"
<azonenberg_work> totally imlementation defined
<whitequark> and capture-ir doesnt give you the idcode instruction iirc
<azonenberg_work> the DR is either bypass (if no idcoded supported) or a 32-bit value
<azonenberg_work> capture-ir in general does not give you the instruciton
<azonenberg_work> ir capture is often used as a status register
<whitequark> yeah
<azonenberg_work> like on coolrunner it gives you done, lock, etc bits
Miyu has quit [Ping timeout: 245 seconds]
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
jevinskie has joined ##openfpga
<sensille> the only tool?
<SolraBizna> my Arduino, still assembled to two other "applications"
<sensille> when all you have is an oscilloscope everything looks like an electric signal to you?
<sensille> ah
<whitequark> is that an upduino?
<SolraBizna> it is
<whitequark> with the scenic route ground trace?
<SolraBizna> probably
<SolraBizna> all of this would have been so much easier if I had things like a spare breadboard or headers or a soldering station or...
<whitequark> gruetzkopf: hm, looks like i can't lock onto commas
<q3k> whitequark: this is using Diamond, right?
<whitequark> q3k: yes
<whitequark> one thing at a time
<q3k> yeah, sure
<sorear> which commas are you trying to lock onto
<sorear> have you read the chapters about Ordered Sets
<whitequark> yes
<whitequark> i've read the entire spec
<whitequark> i have two specified, uhhhh
<whitequark> K28.3
<whitequark> and also 0x83 with disparity error, which is the ones that the Lattice PCIe example uses
<sorear> i suppose I should ask "do you remember X" because after I've read something the length of the pcie spec I remember a third of it, optimistically
<whitequark> actually, right now I took all SERDES parameters from Lattice stuff
<whitequark> and it still can't lock
<sorear> how much visibility do you have into the core? can you connect a uart and dump a few thousand 10b words of deserialized data?
<sorear> or is this just using LEDs for output
<whitequark> i can connect an UART to it
<whitequark> no, not just LEDs
<whitequark> I hooked up a scope to various SERDES status pins
<whitequark> so i can see that uh... gimme a sec
<sorear> are you currently testing it as a root complex or as an endpoint?
<whitequark> endpoint
<whitequark> it's plugged into my cursed thunderbolt box
<whitequark> ok, so i'm looking at the "disparity error" pin
<whitequark> there are several patterns i can see but it goes down for 8ns each 64ms interval
<whitequark> that kinda sounds like the bitslip in the LSM? let me try disabling LM
<whitequark> *LSM
<whitequark> nnnnope, disabling LSM and comma aligner makes precisely zero difference
<whitequark> so it kinda sounds like they dont work?
<whitequark> yeah thats not super useful ok
<whitequark> let me grab some 10b bits
egg|zzz|egg is now known as oeuf
<whitequark> q3k: are you sure the uart in migen versa ecp5 5g definition isn't swapped?
<q3k> i'm fairly sure it is :)
<q3k> sorry, I have a backlog of shit to fix in that definition
<q3k> never got to doing it
<q3k> alto it's litex, not migen, right?
<whitequark> well, it is in migen now
<q3k> i need to catch up on the state of the two :D
<whitequark> because i put it there.
<whitequark> yesterday.
<whitequark> hmm
<whitequark> ok, no, isn't swapped
<whitequark> something's fucky elsewhere
<whitequark> oh gross
<whitequark> i hit that migen footgun again
<whitequark> nvm
<whitequark> sorear: ok, i have uart
GuzTech has joined ##openfpga
<whitequark> okay done
<whitequark> let me grab data
<whitequark> ok, I have half a millisecond of 10b symbols
<whitequark> thats enough right
<q3k> whitequark: i'm surprised you went through the lattice SERDES samples
<q3k> whitequark: and didn't see this cursedness:
<q3k> always @(X) begin // add code from "PRBS_Calculator.xls" here...
<q3k> (or maybe you're just numb to this)
<q3k> i think that's in the loop/echo example
<whitequark> q3k: i did not look at that
<whitequark> i just looked at the parameters to see which ones i need
<whitequark> and which ones i can safely discard
<q3k> bleh i need to finish boring $dayjob stuff and upstream my PLL generator for Migen/ECP5
<q3k> unless you already wrote one
<whitequark> no
<whitequark> i dont use the pll other than inside the serdes
<whitequark> the *DCO* generator would be warmly welcome
<q3k> don't have that, only other thing I have is the RX_SYNC softcore for IDDR/DDRDLLA sequencing
<daveshah> morning whitequark/q3k
<whitequark> sorear: got 10b data
<whitequark> there are no repetitive patterns there at all
<whitequark> actually, wait
<whitequark> actually, this whole thing seems fucky, hm
<daveshah> There's a possibility it's to do with how you reset the SERDES
<daveshah> The vendor stuff in some modes does seem to add some extra lock/reset logic
<whitequark> i need to reset it?
<whitequark> :p
<daveshah> I don't know, tbh
<whitequark> the fucky part is the uart not quite working i think
<daveshah> ah
<whitequark> is it not supposed to run at 250 MHz?
<whitequark> uh, let me add clock constraints i guess
<daveshah> It might be a bit on the high side
<whitequark> i'm so not used to a real toolchain
<daveshah> Also, you're not driving the uart off the cursed pcie clock are you?
<whitequark> i am doing exactly that
<whitequark> i am driving it off the recovered pcie clock
<sorear> I'm guessing the fdti chip couldn't handle 250 MHz regardless
<whitequark> um
<whitequark> i use 115200
<whitequark> lol
<daveshah> are you are it is accurate enough?
<whitequark> it's just the system uart clock
<whitequark> yeah i measured it with my scope
<sorear> just trying to cover all the possibilities
<whitequark> when it's locked that clock is very nice
<daveshah> OK, that sounds fine then
<q3k> daveshah: hi ho
<daveshah> so did you work out all the magic pll parameters for your migen thing then?
<daveshah> in particular, LPF_RESISTOR and ICP_CURRENT?
<whitequark> i copied a few blocks from the pcie example
<whitequark> but i worked out most of them
<whitequark> DCO, CMU and SET* parameters are the only ones i don't know what to do with
<daveshah> ah, my last message as for q3k about his pll stuff
<whitequark> ah
<daveshah> For the DCO stuff it's probably just a case of running a load of designs through diamond and seeing what actually changes
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark> what's the syntax for "FREQUENCY" when it's not for a port?
<daveshah> FREQUENCY NET
<daveshah> I believe
<whitequark> thank
<daveshah> Sometimes the net name has _c appended to it
<whitequark> hm
<whitequark> no
<whitequark> didnt help
<whitequark> let me try to move the UART into a less fucked clock domain
ym has joined ##openfpga
<daveshah> another thought is that the recovered clock might glitch at startup and mess things up
<daveshah> Maybe hold it in reset during lol
<whitequark> mhm
<whitequark> oooooooh
<whitequark> moving UART to another clock domain makes *way* more sensibe results
<whitequark> clear repeating pattern
<daveshah> Interesting
<daveshah> I guess the lol was fucking the uart or something
<whitequark> except none of it makes any sense
<whitequark> let me add a reset
<whitequark> and some CDC sync
<daveshah> sounds sensible
wbraun has quit [Quit: wbraun]
<whitequark> done
<whitequark> let's see
<whitequark> no. this is not any better.
<whitequark> weird.
<daveshah> As you're using diamond anyway, could always use the reveal logic analyser if it helps?
<whitequark> ew.
<whitequark> no.
<whitequark> i hate the gui.
<whitequark> ok, figured it out
<_florent_> whitequark: to speed up tests and have more visibility, you should use probably use microscope (or litescope), connect control/status signals to CSRs and control all that over uart with a script?
<whitequark> i transmit AABBAABB...
<whitequark> 00000000 00 00 94 bb 67 9b ef 5a f7 a3 d9 ef 5a f7 a3 d9 |....g..Z....Z...|
<whitequark> 00000010 ef 5a f7 a3 d9 ef 5a f7 a3 d9 ef 5a f7 a3 d9 ef |.Z....Z....Z....|
<whitequark> 00000020 5a f7 a3 d9 ef 5a f7 a3 d9 ef 5a f7 a3 d9 ef 5a |Z....Z....Z....Z|
<whitequark> this is what i receive.
<daveshah> so you are transmitting now?
<whitequark> via UART.
<whitequark> for the logic analyzer.
<daveshah> So no serdes in this path?
<whitequark> nope
<daveshah> this feels a bit like a baud rate issue
<whitequark> _florent_: well, microscope needs an uart
<whitequark> and i don't have it working
<whitequark> lol
<whitequark> daveshah: yes
<whitequark> oh *facedesk*
<whitequark> 100 MHz, not 125 MHz
<_florent_> whitequark: ah sorry, strange because i tested uart with ECP5 the other day
<whitequark> maybe I should've like... turned on paritu...
<whitequark> _florent_: no, it is my bug
<whitequark> and my uart anyway
<whitequark> the glasgow uart
<whitequark> ok, i have working uart
<whitequark> AH
<whitequark> now it works
<whitequark> 00000000 02 aa 02 aa 02 a2 03 2a 02 1f 02 3a 02 ba 03 9c |.......*...:....|
<whitequark> 00000010 02 48 02 8b 02 aa 02 aa 02 aa 02 aa 02 aa 02 aa |.H..............|
<whitequark> 00000020 02 aa 02 aa 02 a2 03 2a 02 1f 02 3a 02 ba 03 9c |.......*...:....|
<whitequark> 00000030 02 48 02 8b 02 aa 02 aa 02 aa 02 aa 02 aa 02 aa |.H..............|
<whitequark> 10b data
<whitequark> I'm looking for uh...
<whitequark> 3e0 3e0 3e0 right?
<sorear> D21.5?
<whitequark> n-no
<whitequark> K28.3
<whitequark> oh
<whitequark> what the fuck
<whitequark> my ISP just blocked example.org on the edge
<whitequark> and... apparently every website that isn't in .ru?
<whitequark> yep
<whitequark> did you know that K28.3 is "Acute gastrojejunal ulcer without hemorrhage or perforation"
m_t has joined ##openfpga
<azonenberg_work> whitequark: wut?
<whitequark> ICD-10
<whitequark> billable code
<whitequark> D21.5 is Benign neoplasm of connective and oth soft tissue of pelvis
<whitequark> idea: communication through diagnoses after first doing 8b10b encoding
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
* sorear wonders how 4.3.5.6. Receiver detection works with a SERDES
<whitequark> there's a special feature in SERDES for that :P
<whitequark> literally just for PCIe
<whitequark> it's pretty cool
<sorear> so iiuc the host should be in Polling.Active and sending TS1s if you have that implemented but aren't sending meaningful data
<whitequark> yep
<whitequark> that's my understanding
<whitequark> also "that implemented" is just termination
<azonenberg_work> whitequark: ... oh
<azonenberg_work> ICD-10 codes
<azonenberg_work> I was thinking 8b10b codes :p
<azonenberg_work> if you want fun icd-10 codes i think V97.33XD is probably top
<sorear> is it actually the case that you can never form a K28.5 from the last N bits of one symbol and the first 10-N of another?
<whitequark> subsequent encounter.
<azonenberg_work> whitequark: you dont think someone sucked into a jet engine would be released after one doctor visit, do you? :p
<whitequark> oh
<whitequark> i thought it's subsequent encounter with the *jet engine*.
<azonenberg_work> it might be
<azonenberg_work> not sure
gnufan has joined ##openfpga
<azonenberg_work> whitequark: X52
<azonenberg_work> "prolonged stay in weightless environment, accidental encounter"
<whitequark> wtf
<azonenberg_work> you know, for when somebody stowed away in the landing gear well of the space shuttle instead of a 737
<azonenberg_work> Or the Vomit Comet
<azonenberg_work> "This left me to ponder what situation might cause a person to be accidentally/involuntarily exposed to a prolonged stay in a zero gravity environment, and I could only come to one conclusion -- alien abduction."
<azonenberg_work> "So I guess the good news is that, if you’re ever abducted by aliens and forced to endure a prolonged state of weightlessness, your primary care physician will be able to properly code it when the extraterrestrials are finally done experimenting on you."
<azonenberg_work> "V91.07 – Burn due to water skis on fire"
<whitequark> alien abduction.
<sorear> trying to stowaway in freight transport, but due to an epic miscalculation you wind up in orbit
<azonenberg_work> lol
<sorear> why was K28.3 mentioned above? i don't see where you should be getting that except for a few cycles during Polling->Detect transitions
<whitequark> hm.
Miyu has joined ##openfpga
<whitequark> I might have misread
Miyu has quit [Ping timeout: 268 seconds]
<sorear> I found your commas
<sorear> they're bit reversed
<whitequark> oh?
<whitequark> wait
<sorear> actually I just messed up
<whitequark> let me work on a more friendly display
<whitequark> in a bit
<whitequark> one hdl bug
<whitequark> 1101010101 1101010101 1101010101 1101010101 1110010101 1100001011 1100011101 1101011101
<whitequark> 1111001110 1100100100 1101000101 1101010101 1101010101 1101010101 1101010101 1101010101
<whitequark> 1101010101 1101010101 1101010101 1101010101 1110010101 1100001011 1100011101 1101011101
<whitequark> 1111001110 1100100100 1101000101 1101010101 1101010101 1101010101 1101010101 1101010101
<whitequark> 1101010101 1101010101 1101010101 1101010101 1110010101 1100001011 1100011101 1101011101
<whitequark> also:
<whitequark> 1101110001 1101010001 1011101000 1001101101 1010101101 1010101010 1010101010 1010101010
<whitequark> 1010101010 1010101010 1010101010 1010101010 1010101010 1010101010 1000111010 1101111010
<sorear> what does the "also:" signify, is that not 7*8*10 consecutive bits off the wire?
<whitequark> also: is a different part of dump
<sorear> mm
rohitksingh has joined ##openfpga
m4ssi has joined ##openfpga
<whitequark> aaaaaaaah
<whitequark> it cannot lock because
<whitequark> the polarity is inverted lol
<whitequark> i think
<daveshah> heh
<daveshah> that is configurable at least
<whitequark> yeah
<whitequark> needs to be switched at runtime...
jevinskie has joined ##openfpga
<sorear> there's something else wrong here
<whitequark> oh?
<sorear> a gen1 TS1 should have 100 bits of (01)* (symbols 6-15)
<sorear> i can't get 100 consecutive transitions out of what you've posted by any means
<whitequark> mh
WilhelmVonWeiner has joined ##openfpga
<whitequark> oh
<whitequark> it should sync to either comma or inverted comma
<whitequark> but
<whitequark> why does it specify K28.3?..
<whitequark> oh that's K28.5 actually
<whitequark> hmmmm.
lovepon has quit [Ping timeout: 276 seconds]
Bike has joined ##openfpga
Bike has quit [Client Quit]
Bike has joined ##openfpga
<sorear> are UDF_COMMA_A and UDF_COMMA_B taken from the lattice example?
<whitequark> I derived them myself and verified that they match
* sorear no longer looking at it
<whitequark> at commas or just data?
<whitequark> i think i'm not driving the LSM right...
<whitequark> oh.
<whitequark> I did not enable it.
<gruetzkopf> .
<whitequark> i mean i've expected something like that.
* whitequark stares
<whitequark> lol what
<whitequark> i... enabled it and...
<whitequark> i never see any comma anymore
IanMalcolm has joined ##openfpga
<daveshah> on my loop tests, I find the ecp5 serdes either tends to sync to the comma at reset or not at all
<daveshah> but that could be a dodgy setup issue
<whitequark> huh.
<whitequark> @E: CG596 :"/home/whitequark/Projects/Yumewatari/build/top.v":607:2:607:18|Illegal or Unsupported Syntax within black box. Use: // synthesis translate_off { unsupported Verilog } // synthesis translate_on
<whitequark> @E: CG596 :"/home/whitequark/Projects/Yumewatari/build/top.v":607:2:607:18|Alternatively, set the builtin compiler directive IGNORE_VERILOG_BLACKBOX_GUTS in the Verilog tab of the UI or set `define IGNORE_VERILOG_BLACKBOX_GUTS in any Verilog file.
<whitequark> this is when doing
<whitequark> p_CH0_SIGNAL_DETECT="0b1",
<whitequark> interesting
<daveshah> I think there's also a pin for signal detect?
<whitequark> yes
<whitequark> that one seems to do the above
<whitequark> I never see a K28.5 again
<sorear> there are no K28.5s in any of what was posted on IRC
<whitequark> even shifted?
<whitequark> sec
rohitksingh has quit [Ping timeout: 268 seconds]
<sorear> that said I saw the twitter post
<whitequark> yeah
<whitequark> wait.
<whitequark> hm.
<whitequark> I have an idea
<whitequark> no, nvm
<whitequark> if I disable the LSM they're here
<whitequark> 105:1010101011 1010101011 1010101011 1001111101 0000101011 1000101011 1010100111 0011100011
<whitequark> 107:1010101011 1010101011 1010101011 1001111101 0000101011 1000101011 1010100111 0011100011
<whitequark> 4th word plus 1 bit
<sorear> with the comma aligner enabled, do you still have a 16 byte periodicity, or does it drop to 14/15
<whitequark> let me see
<sorear> actually that doesn't make sense since you're capturing a word on every clock edge, and the serdes isn't going to omit clock edges for commas
<whitequark> it is 16-periodic
<whitequark> 0101010101 0101010101 0101010101 0011111011 0001010111 0001010111 0101001111 0111000101
<whitequark> 1001110101 0101010101 0101010101 0101010101 0101010101 0101010101 0101010101 0101010101
<whitequark> i... hang on
* whitequark stares
<sorear> are the 10-bit blocks big or little endian, and how certain are you
<whitequark> the first bit on the wire is the one on the left
<whitequark> i am very certain
<whitequark> i had to fix a bug related to this
<whitequark> wtf
<whitequark> it looks like it aligns
<whitequark> and then
<whitequark> it changes the data?!
<whitequark> oh I recall seeing something about
<gruetzkopf> does it stay in 10bit raw mode?
<whitequark> yes, in theory
<gruetzkopf> or is it being annoying
<whitequark> i mean
<whitequark> 50:0011111011 0001010111 0001010111 0101001111 0111000101 1001110101 0101010101 0101010101
<whitequark> 52:0011111011 0001010111 0001010111 0101001111 0111000101 1001110101 0101010101 0101010101
<whitequark> look at this
<whitequark> word *and* OS aligned
<whitequark> except
<whitequark> it starts with K28.13
<whitequark> instead of K28.5
<whitequark> what...
<whitequark> oh hm
<whitequark> CH0_WA_MODE...
<whitequark> that changes between barrel shift and bitslip
<whitequark> hm, doesn't seem to make any difference
<whitequark> oh well, why the fuck is it K28.13
<whitequark> oh WAIT
<sorear> what is a k28.13, neither wikipedia 8b10b nor the pcie spec has heard of that code
<whitequark> well
<whitequark> i take CH0_WA_MODE = "0b0"
<whitequark> er
<whitequark> i take 0011111011
<whitequark> split it into 001111 and 1011
<whitequark> wait
<whitequark> no
<whitequark> i'm wrong
<whitequark> sec
<whitequark> ok, it is K28.0
<whitequark> i think
<daveshah> whitequark: just testing with my own setup
<daveshah> locks rock solid
<daveshah> this sends two K28.5s every 1024 words
<daveshah> if that helps
<whitequark> daveshah: what about RLSM?
<whitequark> does that go high?
<whitequark> er
<whitequark> o_CH0_FFS_LS_SYNC_STATUS
<whitequark> this on
rohitksingh has joined ##openfpga
<daveshah> whitequark: no, it seems to stay low
<whitequark> rigt, i think i know why
<whitequark> lemme check
<whitequark> nope
<whitequark> no iea
<sorear> if the datasheet is to be believed enable_cg_align is ignored in pcie mode
<daveshah> also, I need to reset it before it syncs
<daveshah> it doesn't sync immediately after power up, but does lock and sync after every reset subsequently
<whitequark> i do not need to reset it
<whitequark> i added some code to toggle SIGNAL_DETECT
<whitequark> when it's locked, it's always on 0011111011
<whitequark> when it's not locked, it's on 00111 11010
<whitequark> weird.
<whitequark> hm
<whitequark> .... do i just have that bit stuck high???
<whitequark> lmao yes
<whitequark> it's always set
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
<whitequark> gruetzkopf: oh ffs
<whitequark> 12:01 < gruetzkopf> does it stay in 10bit raw mode?
<whitequark> it IS being annoying
<whitequark> it logically ORs some status bits with the bits beyond what in 8-bit mode is the K bit
<whitequark> afaict
<gruetzkopf> wat
<whitequark> exactly
<whitequark> the fpga bus is multiplexed with data and control
<gruetzkopf> well, 8bit + k + d bit should work too?
<whitequark> no, it's not a d bit
<whitequark> it's just... one
<whitequark> always
<sorear> it might assume that pcie always uses the 8b10b decode
<sorear> looking at the TN1261 page 9 table
rohitksingh has quit [Ping timeout: 240 seconds]
<gruetzkopf> i mean if you throw it into 8bit out mode
<whitequark> yeah
<whitequark> it assumes that i think
<whitequark> that you never bypass decoder
rohitksingh has joined ##openfpga
Bike is now known as Bicyclidine
rohitksingh has quit [Ping timeout: 250 seconds]
Laksen has joined ##openfpga
rohitksingh has joined ##openfpga
<felix_> using the high voltage (3.3v or 2.5v) mode of the coolrunner2 io block with either 3.3v or 1.8v shouldn't be a problem apart from the slew rate in the 1.8v case being a bit slower, right? (i'm planning to use a cr2 as a buffer for a spi flash programmer with 1.8 and 3.3v support)
rohitksingh has quit [Ping timeout: 272 seconds]
Miyu has joined ##openfpga
azonenberg_work has quit [Ping timeout: 244 seconds]
<whitequark> daveshah: any idea what is "rg_en"?
<whitequark> it's not documented at all
m_t has quit [Read error: Connection reset by peer]
<daveshah> whitequark: no, no idea
<whitequark> ok, I can receive ordered sets
<daveshah> \o/
<sorear> !!!
<whitequark> except
<whitequark> they dont make any fuckin sense
<whitequark> instead of D10.2 I get D10.5
<daveshah> Benign neoplasm of other parts of oropharynx?
<whitequark> yes
<whitequark> exactly
<whitequark> oh *lolsob*
<whitequark> I forgot inversion turned on
<whitequark> and then proceeded to misread D.10 as D.21
<whitequark> well, the other way around
<whitequark> I am an idiot
<whitequark> wtf
<whitequark> if you invert commas, they stay commas?!
<whitequark> this is REALLY FUCKIN CLEVER
<daveshah> yes, just tested my loopback example
<daveshah> and it detects commas with no encoding errors when the pair is swapped
<daveshah> just the output data is garbage
<sorear> whitequark: the inverted COMMA_A is COMMA_B, that's why you have two of them…
<sorear> daveshah: 3.0 §4.2.4.4 requires all pcie devices to handle "oops RX+/RX- were swapped"
<sorear> (this is detected by way of D.10 in the TS1…)
<cr1901_modern> If you swap outputs the main effect is that 0=>1 and 1=>0, correct?
<sorear> correct
<whitequark> sorear: no, i mean, they decode to the same value
<whitequark> after 10b8b
<whitequark> so in software i detect them the same
<sorear> ah
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 260 seconds]
GuzTech has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work> felix_: hmm, i dont know what Vih in high voltage mode is (check datasheet)
<azonenberg_work> it certainly wont hurt the chip
<azonenberg_work> and outputs should work fine, though slower
plaes has quit [Ping timeout: 245 seconds]
msgctl has quit [Ping timeout: 272 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
plaes has joined ##openfpga
msgctl has joined ##openfpga
<felix_> hmm, vin_h might be a problem; the datasheet doesn't say anything about this though; only for the io banks being used with the specified voltage
<azonenberg_work> it doesnt say Vih in lvcmos33 mode?>
<felix_> yeah, but only for vccio = 3.3v. for lvcmos25 at 2.5v the vin_h value is lower even though it's the same io thing being used
<felix_> https://github.com/azonenberg/openfpga/blob/master/doc/coolrunner/xc2c32a-notes.txt said that the cr2 only has two different io settings and i'm not sure if it only selects the outpus stage being used or also the input stage
azonenberg_work has quit [Ping timeout: 240 seconds]
<felix_> the precentage of the vccio voltage at which vin_h is, is about the same for lvcmos33, lvcmos25 and lvcmos18
<felix_> xapp785 says that the io characteristics scale linearly between lvcmos33 and lvcmos25
<felix_> so yeah, my main question is if the io voltage bit only affects the output or also the input
azonenberg_work has joined ##openfpga
jevinskie has joined ##openfpga
Laksen has quit [Remote host closed the connection]
m4ssi has joined ##openfpga
inode has joined ##openfpga
wbraun has joined ##openfpga
<whitequark> daveshah: does EXTCLKB work yet?
<whitequark> i wanna try this on FOSS tools...
<daveshah> whitequark: yes but I think it will break on this design
<daveshah> will try and fix tonight
<daveshah> was trying to get your code working with Diamond first
m4ssi has quit [Remote host closed the connection]
<daveshah> can't get it working with my TX2 tho
<whitequark> what is TX2?
<whitequark> have you flashed ispCLOCK?
<whitequark> you need the -100MHz file
<daveshah> yes, flashed ispclock and reference seems fine
<daveshah> tx2 is jetson tx2
<daveshah> had to patch the kernel to stop it turning off pcie if detection failed
<daveshah> but what I get is LOS turning on and off at regular intervals (this is OK I believe), but LOL stays high
<daveshah> fix for the extrefb should be pushed
<whitequark> hm, ok
<whitequark> which branch of nextpnr should i use?
<daveshah> dcu
<daveshah> also need this libtrellis first: https://github.com/SymbiFlow/prjtrellis/tree/dcubels
<whitequark> ok lets see
<daveshah> also, will need to set the BEL attribute on the DCUA
<daveshah> as in the example I linked
<daveshah> haven't sorted this yet
<whitequark> daveshah: i just rebuild nextpnr right?
<whitequark> or ecppack too?
<daveshah> first run download-latest-db.sh in trellis, rebuild libtrellis and reinstall
<daveshah> then do the nextpnr
<whitequark> ok
<daveshah> it seems to be choking on the design anyway
<daveshah> something tristate or iobuf related
<whitequark> hrm
<daveshah> seemed the direction of the pcie out pins was wrong
<daveshah> they were incorrectly inputs
<whitequark> oh
<whitequark> oops
<daveshah> anyway, now something is breaking deep in the packer
<whitequark> daveshah: hm, can't seem to grab the dcu branch
<whitequark> where is it?
<daveshah> ah, i don't think its on origin
<sorear> is there much use in documenting ispclock or can everything they do be done cheaper and better with other parts
<daveshah> ah, the packer crash was me being stupid with yosys
<daveshah> nvm
<daveshah> well, it claims to build now at least
<whitequark> ok let's see
<daveshah> you also need this yosys https://github.com/daveshah1/yosys/tree/ecp5_bb
<daveshah> for the blackboxes
<whitequark> gah
<whitequark> okay
renze has quit [Ping timeout: 240 seconds]
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
renze has joined ##openfpga
television has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Ping timeout: 252 seconds]
<daveshah> heh, it seems the tx2 is working now
<daveshah> I didn't change anything, just left everything turned off for a half an hour
television has joined ##openfpga
<whitequark> huh
<daveshah> seems to work with trellis too!!
<sorear> the pcie thing?
<daveshah> yeah, I think
<daveshah> I need to see if the K-codes are correct
<daveshah> but at least it's syncing and giving some kind of reasonable pattern
<whitequark> lemme see
<whitequark> yosys is 46% built
<SolraBizna> I didn't have enough LCs left over for a giant shift register
wbraun has quit [Quit: wbraun]
<whitequark> daveshah: can confirm it gives correct TS1
<whitequark> wtf, this is much faster
<whitequark> gonna use nextpnr for development now
<daveshah> \o/
<daveshah> have fun
<whitequark> thanks :3
wbraun has joined ##openfpga
Maylay has quit [Read error: Connection reset by peer]
Maylay has joined ##openfpga
<q3k> okay, so the emard openocd patch for ulx3s programming is indeed slow as fuck
<q3k> is there any better f/loss option for programming the ulx3s?
<q3k> (from an SVF or .bit)
<daveshah> The official Lattice vme way is about 25 seconds, as a benchmark
<q3k> yeah, i had similar results
<q3k> openocd takies ~1m30
<q3k> *takes
<q3k> let me see if i can bump up the khz
<q3k> right now i'm at 1MHz
<q3k> (default from the openocd trellis configs)
<daveshah> Versa at 1MHz was still only about 8 seconds though
<q3k> bumping up the khz did nothing
<q3k> exact same time
<q3k> i would add support to jtaghal but i have no idea how to build it
<daveshah> The other option would be libxsvf
<azonenberg_work> q3k: jtaghal is easy to build, it's just cmake
<q3k> well
<q3k> it needs to be within antikernel, no?
<azonenberg_work> o, i refactored it out months ago so it can be used standalone
<azonenberg_work> no*
<azonenberg_work> all you have to do is install a supported backend (ftdi blob driver or digilent blob driver, or glasgow but i dont know how well developed that backend is atm)
<azonenberg_work> and compile it
<azonenberg_work> q3k: you're using the wrong repo
<q3k> you're documenting things poorly :)
<q3k> i know it's in the readme
<q3k> but it's not really visible
<azonenberg_work> yeah the intent is for the lib repo to be integrated into a larger project if you want to build all your dependencies at once
<azonenberg_work> jtaghal-cmake is the parent repo with the client applications and the library plus a parent build system
<azonenberg_work> this also lets me pull it into antikernel and build with splash etc too
<q3k> your splash buildsystem seems to be a rewrite of a buildsystem inspired by blaze
<q3k> now that there's bazel, maybe it's time to migrate :P
<azonenberg_work> It's a from-scratch blaze inspired system that predates bazel
<azonenberg_work> bazel lacks parallel build support afaik
<q3k> no it doesn't lol
<azonenberg_work> it did when i last checked
<q3k> what do you mean by parallel
<azonenberg_work> the continuous background hashing of files etc depended on GFS
<azonenberg_work> i mean building on hundreds of cores across dozens of nodes
<q3k> you go bazel build and it spawns all the threads
<q3k> oh, there's a beta for that too
<azonenberg_work> With a globally shared cache across the whole organization
<q3k> also GFS is dead since 10 years now
<q3k> caching is supported for a year now or so
<q3k> i use it for a customer
<azonenberg_work> with a client-server model?
<azonenberg_work> like, if i build some code and push my changes
<azonenberg_work> then you pull
<azonenberg_work> if we're in the same bazel cluster, do you get an instant binary?
<q3k> more or less
<azonenberg_work> or do you have to recompile everything
<q3k> some things are still fucky
<q3k> like local proto compilers
<azonenberg_work> sounds like i was early to the party then
<azonenberg_work> i built all of these features (buggily since i didnt have time to fully debug it) after going to a tech talk on "google build system"
<azonenberg_work> (the name blaze wasnt public yet)
<azonenberg_work> at some point i heard the name and decided to call mine Splash as a pun
<azonenberg_work> the other thing is, as of when i talked to the google engineer at this talk in 2011
<azonenberg_work> it didn't support nondetrministic builds like FPGA tools
<q3k> that's by design
<azonenberg_work> well that was an absolutely mandatory feature for me :p
<q3k> its whole point is deterministic builds
<azonenberg_work> So splash doesn't use hashes of file *content*
<azonenberg_work> It uses hash of *inputs* to the build process
<azonenberg_work> toolchain version, source files, flags, etc
<azonenberg_work> then runs the build once and that artifact is the one you use
<q3k> right, but that's how bazel works as well.
<q3k> i think we're confused somewhere.
<azonenberg_work> But if the same compiler with the same inputs is run twice, and produces different outputs
<azonenberg_work> as long as the outputs are logically equivalent it doesnt break splash
<azonenberg_work> also things like timestamps in ELF headers
<q3k> i'm fairly sure it also doesn't break bazel either
<azonenberg_work> which, as of when i talked to the guy in 2011, were a big problem
<azonenberg_work> they had gone as far as to patch out elf/pe timestamps to all zeroes in the compielr
<q3k> but i don't know, i rarely write my own skylark extensions
<azonenberg_work> to ensure bit for bit reproducibility
<q3k> i should try writing some for verilog/yosys/nextpnr, that would ben eat
<q3k> *be neat
<q3k> also yosys and nextpnr are already deterministic :P
<azonenberg_work> yeah but i cant rely 100% on the open tools
<azonenberg_work> yet
<azonenberg_work> anyway, it sounds like bazel has evolved considerably over the past 8 years
<azonenberg_work> and may be to the point that i can consider using it
<q3k> also i'm fairly sure it's used internally with vendor tools
<azonenberg_work> i wrote splash before bazel existed, it was a google-internal tool
<azonenberg_work> when it came out, it was too immature and didnt support distributed builds whatsoever
<q3k> i get that part
<azonenberg_work> WHich was a must to me, running 20+ ISE builds simultaneously for parallel in-hardware unit testing
<azonenberg_work> oh, that was the other bit
<azonenberg_work> i have build steps that are test operations too
<azonenberg_work> also, splash is explicitly multiarch-aware from the start
<azonenberg_work> all compiles, without exception, are cross-compiles
<azonenberg_work> you specify in the build script a list of triplets you want to target
<azonenberg_work> (or fpga board support files)
Bicyclidine is now known as bike
<azonenberg_work> so it doesnt matter if you're stiting on a linux desktop or a chromebook or an old ppc mac
<azonenberg_work> you get build/x86_64-linux-gnu/jtagd
<azonenberg_work> or build/xilinx-ac701/foobar.bit
<azonenberg_work> actually there's a config in there too so it's like build/xilinx-ac701/release/foobar.bit
<daveshah> crazy cursed thought: would an FPGA serdes be capable of broadcasting an 802.11 SSID?
<azonenberg_work> daveshah: wifi over serdes has been proposed a few times
<daveshah> used as a very fast 1 bit dac
<azonenberg_work> i havent seen it actually successfully implemetend yet
<azonenberg_work> that's not to say it cant be done
<azonenberg_work> but i dont think anyone's gone from theory to practice
<azonenberg_work> q3k: anyway, in order to better support embedded tools using weird compilers, i also had what I called "meta-flags"
<azonenberg_work> you didn't do things like -fstack-protector, you had something like security/stackguard
<azonenberg_work> which would turn into -fstack-protector or /Gs or whatever the option for your compiler du jour was
<azonenberg_work> i.e. the flag in your build script reflects the semantics of the flag, then it's turned into technology dependent flags when the final command line is generated
<azonenberg_work> that's a feature i've never seen anywhere else
<azonenberg_work> and if you want to try to compile the same code for 6 different ISAs using 4 different compilers, it's a must :p
<q3k> ioctl(10, USBDEVFS_CLAIMINTERFACE, 0x7ffd206afbcc) = -1 EBUSY (Device or resource busy)
<q3k> ugh
<q3k> oh, the openocd ft232r driver doesn't use libftd2xx!
<q3k> that's nice.
<q3k> so if I first run fleajtag FT_OpenEx works
<q3k> when I replug it it doesn't.
<q3k> (fleajtag also use libftd2xx)
<q3k> ah yes.
<q3k> ftdi_sio, that explains it.
<q3k> grr.
<q3k> i though I blacklisted it.
<q3k> oh no wait. fleafpga uses ftd2xx only on windows, libftdi otherwise
<q3k> okay, no, fuck this.
<q3k> what even is going on here
<q3k> what even are those numbers
<q3k> fairly sure if we wanted to support the ulx3s/fleafpga style ft231x jtag adapter in jtaghal we'd have to write an entirely separate stack
<daveshah> This is the problem with the ulx3s/fleafpga approach, imo
inode has quit [Quit: ]
<q3k> because the ft231x bitbanding is totally different from the ft2322 bitbanging
<daveshah> All the downsides of ftdi hassle without the speed or compatability of the ftx232h
<q3k> maybe we should just tape out a non-shit usb/jtag adapter-on-a-chip
<daveshah> Glasgow on a chip lol
<daveshah> Actually that could just be fx2 and ice40up5k dice in a mcm
<q3k> have a new glasgow api that instead of flashing an applet orders a tapeout from MOSIS
GenTooMan has joined ##openfpga
<mithro> Wow, I didn't know that the Spartan 6 went down to LX4 -> https://store.digilentinc.com/cmod-s6-breadboardable-spartan-6-fpga-module/