digshadow has quit [Ping timeout: 250 seconds]
digshadow has joined ##openfpga
<azonenberg> whitequark: Thoughts on always IDing the chip in the programmer?
<azonenberg> Even if you don't specify any further args?
<azonenberg> it seems like a reasonable default if you specify no args is to ID the board and chip
<azonenberg> Anybody else have input here? if you run gp4prog with no arguments
<cr1901_modern> That seems to be a convention for programmer tools
<azonenberg> That was my thought too
<cr1901_modern> I would prob put a string "use -h for help" if I were writing it, just so newbies don't get too lost (yea I know -h is universal, but still)
<azonenberg> Look good?
<cr1901_modern> Wonderful :D!
<cr1901_modern> (Can you tell I get annoyed when ppl say "Use -h for help is redundant"?)
<cr1901_modern> FWIW, I love that say, xc3sprog will automatically do JTAG scan, so I can be notified that the connection to my current target is crap and barely works :)
<azonenberg> lol
<azonenberg> I auto-detect in libjtaghal but don't default to doing a chain integrity test
<azonenberg> doing say half a second of idcode looping couldn't hurt
<azonenberg> then have it complain if it gets unstable results
<cr1901_modern> I don't think I could run 200 rounds of idcode looping and have them all return the same result XD
<cr1901_modern> let alone half a second (whatever that comes out to in iterations)
<azonenberg> lol
<azonenberg> yeah with my current setup using ftdi dongles i get a few errors per GB
<azonenberg> iirc
<azonenberg> i should try calculating the BER
<azonenberg> I should also add a crc to my jtag debug protocol
m_w has joined ##openfpga
<azonenberg> also woo got an email from nathan at silego
<azonenberg> They're sending me a bunch of slg46621 samples (the last greenpak4 part i do not already have in stock)
<azonenberg> as well as a second dev board i can dedicate to hardware-in-loop test cases
<whitequark> rqou: i went through the machine that eats your HKID in the airport this time
<whitequark> the fuck it fingerprints me for?!
<azonenberg> whitequark: if we set up build/test VMs on all 3 boards (my 2 + your 1
<azonenberg> and give each other ssh access to them
<whitequark> i do not have any way to provide consistent ssh access
<whitequark> actually, hm
<whitequark> i could plug it at the lab. (lab.m-labs.hk)
<azonenberg> then we can have realtime access to all 3 boards
<azonenberg> set up some kind of job manager so we can do CI builds when an interactive job isn't running
<azonenberg> but not step on a debug job if the board is actively reserved
<azonenberg> Just an idea
<azonenberg> but it'd be nice to have CI tests available for all 3 hardware platforms
<whitequark> it seems harder than adding an analog switch that selects between n sockets
<azonenberg> if not, i can dedicate one board to the 46620 and one the the 46140
<azonenberg> and just live with the fact that the 46621 is essentially the same
<whitequark> i mean... thats literally a pin socket and a set of identical switches
<whitequark> whereas this way we need to write software
<azonenberg> well, switching would require software too
<azonenberg> if you wanted analog switches
<azonenberg> under sw control
<whitequark> oh, hm.
<whitequark> that's true
<whitequark> pity the UDB FW is not OSS...
<azonenberg> fundamentally, there needs to be some way for both of us to access one of each chip for debugging code
<azonenberg> and some way to run unit tests on one of each chip
<azonenberg> i'm open to ideas, but it seems the sanest option is one board per chip somewhere
<whitequark> can you just request another board from silego? ;p
<azonenberg> Lol :P
<azonenberg> for the short term, i think i'll dedicate my 2 boards to the 4662x and the 46140
<azonenberg> then not run tests on the other board
<azonenberg> on the other chip*
<azonenberg> once i get the 46621 supported, the 46620 is kinda working implicitly (just one extra GPIO)
<azonenberg> So then i just need to set up two test VMs on my own box
<azonenberg> then figure out some way to arbitrate access between me and CI jobs
<whitequark> ... *two* test VMs?
<whitequark> oh
<whitequark> arbitration
<whitequark> ok
<azonenberg> one per board
<azonenberg> Until and unless we add support for >1 board in the same box in gp4prog
<azonenberg> I might bang that up once the new board arrives
digshadow has quit [Ping timeout: 265 seconds]
digshadow has joined ##openfpga
<rqou> whitequark: I'm pretty sure the machine uses the fingerprint to verify that you are indeed the holder of that HKID
<rqou> and not e.g. stolen somebody else's
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<whitequark> rqou: oh
<azonenberg> yeah that's how the global entry cards work in the USA
<azonenberg> (for expedited customs clearance at automated kiosks)
m_w has quit [Quit: leaving]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
bibor has quit [Ping timeout: 250 seconds]
bibor has joined ##openfpga
maaku has quit [Ping timeout: 260 seconds]
maaku has joined ##openfpga
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/vPbzJ
<openfpga-github> yosys/master aa72262 Clifford Wolf: Added avail params to ilang format, check module params in 'hierarchy -check'
kuldeep has quit [Ping timeout: 250 seconds]
<openfpga-github> [openfpga] azonenberg opened issue #52: Support for multiple devices in gp4par https://git.io/vPbzz
<azonenberg> whitequark: well, i guess it works
<azonenberg> So, do you think that we should have a default value for the part arg in gp4par?
<azonenberg> or should specifying the target device be mandatory
kuldeep has joined ##openfpga
<azonenberg> i'm leaning toward mandatory
<azonenberg> whitequark: also, right now gp4par takes --usercode as hex and gp4prog takes it as decimal
<azonenberg> we should probably unify that at some point
<azonenberg> any preferences for which to pick as canonical? most other stuff (e.g. xilinx) uses hex id codes
<azonenberg> some of the 5-series silego parts take 2-byte IDs
scrts has quit [Ping timeout: 268 seconds]
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
scrts has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 2 new commits to master: https://git.io/vPbgR
<openfpga-github> openfpga/master 955304f Andrew Zonenberg: gp4par/tests: Added --part argument to gp4par so we can support more than just the SLG46620V. Fixes #52.
<openfpga-github> openfpga/master 6782ca9 Andrew Zonenberg: gp4prog: running with no args now detects part before exiting
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPbgu
<openfpga-github> openfpga/master 73279da Andrew Zonenberg: greenpak4: Fixed two tests that had incorrect parameter names
<azonenberg> whitequark: 73279da is proof of why we needed that yosys fix :p
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 75f2d56 to d432936: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages d432936 Travis CI User: Update documentation
<azonenberg> whitequark: so, question
<travis-ci> azonenberg/openfpga#137 (master - 955304f : Andrew Zonenberg): The build was broken.
<azonenberg> whitequark: Rather than hard coding hex bitstreams in gpdevboard
<azonenberg> what are your thoughts on compiling gp4par first, then compiling a provided source file
<azonenberg> then pulling that in at gpdevboard build time
<azonenberg> that would let us write e.g. the loopback test bitstream once (for a given package, at least)
<azonenberg> then just build for different target devices
<azonenberg> this is what i did in my other projects for indirect flash programming bitstreams etc
<azonenberg> i dont like shipping hard coded bitstreams even if they're easy to re-generate, just because it makes changing things a pita
<travis-ci> azonenberg/openfpga#138 (master - 73279da : Andrew Zonenberg): The build passed.
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from d432936 to 76e41bb: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 76e41bb Travis CI User: Update documentation
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPbgy
<openfpga-github> openfpga/master 5240d91 Andrew Zonenberg: tests: Added STQFN14 loopback test bitstream. Probably should be moved to another directory at some point.
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 76e41bb to 8c26341: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 8c26341 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#139 (master - 5240d91 : Andrew Zonenberg): The build passed.
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPb2Z
<openfpga-github> openfpga/master 7206024 Andrew Zonenberg: gp4par/greenpak4: Very early SLG46140V support. PAR now fails with "no nodes of type X" for any object in the netlist, but doesn't segfault. Progress!
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 8c26341 to 1c95cbf: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 1c95cbf Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#140 (master - 7206024 : Andrew Zonenberg): The build was broken.
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPb2B
<openfpga-github> openfpga/master 2175d15 Andrew Zonenberg: xbpar: Sanity check now indents errors
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 1c95cbf to 229c4a5: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 229c4a5 Travis CI User: Update documentation
<azonenberg> welp, lots of spam about failing builds because i accidentally committed the cmake code to run a test i was still writing
<travis-ci> azonenberg/openfpga#141 (master - 2175d15 : Andrew Zonenberg): The build is still failing.
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPb26
<openfpga-github> openfpga/master 38c899d Andrew Zonenberg: tests: Temporailry disabled SocketTestLoopback_STQFN14 since it's not fully implemented
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 229c4a5 to 18ab76d: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 18ab76d Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#142 (master - 38c899d : Andrew Zonenberg): The build was fixed.
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
Bike has quit [Quit: shiiiiiining]
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
doomlord has joined ##openfpga
Bike has joined ##openfpga
digshadow2 has joined ##openfpga
digshadow2 has quit [Read error: Connection reset by peer]
digshadow2 has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
eric_j has quit [Read error: No route to host]
<whitequark> azonenberg: mandatory --part. hex --usercode
<whitequark> azonenberg: nak about building bitstreams from scratch every time
<whitequark> ideally these should never be rebuilt
<whitequark> so that's optimizing something that should never happen
<azonenberg> whitequark: i meant more for device support
<azonenberg> but olk
<azonenberg> do you have a script or something for turning a bitfile into hex?
<whitequark> but the bitstreams are different for different devices...
<whitequark> re bitfile into hex: yes, gp4prog --debug -e foo.txt :p
<azonenberg> lol
<whitequark> there's even a method that will submit frames in the same format as they are printed
<whitequark> assumign you fixed the logindenter bug
<azonenberg> its still there, i have to think a bit about how best to do it
<azonenberg> probably just add a flag indicating "last write ended in \n"
<azonenberg> and if not set, don't indent the next write
<azonenberg> it was kinda low priority
<whitequark> ack
<azonenberg> well this is good news
<azonenberg> so far it looks like the IOB config for the 46620 and 46140 are the same bitstream layout
<azonenberg> so i should be able to get that working fairly soon
<azonenberg> havent checked any other hard ip
<azonenberg> i know the shregs have changed
<azonenberg> since the 140 has a single 3-tap shreg
<azonenberg> and the 620 has two 2-tap ones
kuldeep has quit [Ping timeout: 256 seconds]
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
<azonenberg> whitequark: interesting
<azonenberg> so, the 46140 is a 3-tap shreg with two programmable taps
kuldeep has joined ##openfpga
<azonenberg> plus one fixed tap at offset `1
<azonenberg> offset 1*
<azonenberg> For the short term, if i never use that extra output
<azonenberg> i can treat it just like a normal GP_SHREG cell
<azonenberg> I may add a GP_SHREG_ADV cell that adds support for the extra tap but not allow it for inference for a while
<azonenberg> also *this* is interesting, lol
<azonenberg> i kinda want to test this now
<azonenberg> look at figure 44 of 46140 datasheet
<azonenberg> it seems like you have a 3-bit LUT and a shift register sharing the same inputs
<azonenberg> with two "always shreg" outputs and one "shreg or lut" output
<azonenberg> i wonder if it'd be possible to use both at once :p
<azonenberg> assuming you had a situation that called for rst/in/clk of a ff to also be used as inputs to a lut
<azonenberg> oh, and with lut truth table equal to the output selectors on the shreg :p
<azonenberg> i dont plan to support it, but it might be posible
<azonenberg> oh interesting there are still two shregs on the 46140
<azonenberg> but one is shared and one dedicated
<azonenberg> for some raeson i thought there was only one, total
maaku has quit [Ping timeout: 260 seconds]
maaku has joined ##openfpga
kuldeep has quit [Ping timeout: 256 seconds]
tecepe has quit [Remote host closed the connection]
tecepe has joined ##openfpga
<azonenberg> whitequark: ooh there's a reserved bit at <787> in pin 6 of the 46620v
<azonenberg> 46140v*
<azonenberg> wonder what it does
<azonenberg> and <810> of pin 10
<azonenberg> in fact, all of the type B IOBs
<openfpga-github> openfpga/master da2ef5f Andrew Zonenberg: greenpak4/gp4par: Continued initial SLG46140V support. Can now PAR a valid-looking SLG46140 bitstream consisting solely of GPIO pins and constants.
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPNIm
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 18ab76d to ce7abce: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages ce7abce Travis CI User: Update documentation
<azonenberg> woop, gp4par can now compile a minimal bitstream for the 46140, that gp designer seems to accept as valid (havent tried flashing the chip yet)
<azonenberg> next step is to code this bitstream as the socket-test bitstream (gee, wonder why i used that as the first test...)
<azonenberg> and try a test
<travis-ci> azonenberg/openfpga#143 (master - da2ef5f : Andrew Zonenberg): The build passed.
kuldeep has joined ##openfpga
rah has quit [Ping timeout: 250 seconds]
rah has joined ##openfpga