<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)
<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.
<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.
<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.