<rqou>
the "exit QSPI" command is the standard 0xF5
<rqou>
but it still has to be sent as QSPI :P
<azonenberg_hk>
Lol
<azonenberg_hk>
Oh joy
<azonenberg_hk>
I always have used 1-1-4 or 1-4-4 read timing
<azonenberg_hk>
because i am not doing execute-in-place or othr stuff thats performance criticla
<azonenberg_hk>
i just want a fast load of a large rom image or something as a linear read
<azonenberg_hk>
saving time on the address seems pointless
Lord_Nightmare has joined ##openfpga
<rqou>
even if you do XIP the command probably takes very little time vs the data
<azonenberg_hk>
Well
<azonenberg_hk>
8-bit command + 24-bit address
<azonenberg_hk>
for say a 128-bit cache line
<azonenberg_hk>
that's a 20% overhead
<azonenberg_hk>
in x1 or x4 mode
<azonenberg_hk>
25%*
<azonenberg_hk>
now if you do command+address in x1 that's 32 clocks for setup plus 32 for data
<azonenberg_hk>
Which is 100% overhead
<azonenberg_hk>
Cutting 64 clocks down to 40 seems worth it, no?
<rqou>
hmm I expected it might fetch multiple cache lines
<azonenberg_hk>
if you do prefetching etc sure
<azonenberg_hk>
that was just an examplethough
<azonenberg_hk>
there are situations where it helps a lot
<azonenberg_hk>
And others, like loading an FPGA image, where it doesnt
<rqou>
I wonder what esp8266 does?
<rqou>
supposedly it's just cache over the qspi rom
<azonenberg_hk>
i saw some stm32 clone somewhere that was all sram iirc
<cr1901_modern>
azonenberg_hk: Bite me :)
<azonenberg_hk>
booted from die-bonded spi flash
<rqou>
yeah, giga device
<azonenberg_hk>
cr1901_modern: you're not in hong kong, and too big to fit in my mouth
<azonenberg_hk>
so sorry i'll have to pass
<rqou>
my dad knows a guy that knows the founder of that company
<azonenberg_hk>
:P
<azonenberg_hk>
oh?
<azonenberg_hk>
thats 3 levels of indirection
<azonenberg_hk>
in the bay area surprised it's that high
<azonenberg_hk>
:p
maaku has quit [Quit: No Ping reply in 180 seconds.]
<rqou>
lol
<rqou>
but it's a Chinese company, does that heuristic still apply?
maaku has joined ##openfpga
<azonenberg_hk>
bay area to china is just an ocean :p
<azonenberg_hk>
prob 99% of hardware companies in ht ebay area outsource manufacture to china
<azonenberg_hk>
so...
<azonenberg_hk>
i guess 3 levels is about right
* cr1901_modern
is only sporadically paying attention
mithro has quit [Ping timeout: 258 seconds]
<cr1901_modern>
Well I suppose nothing in principle prevents me from talking to a custom Ethernet device using something lower-level than TCP
<cr1901_modern>
though Idk if Windows would like me trying that
flaviusb has quit [Ping timeout: 258 seconds]
<azonenberg_hk>
both windows and linux allow raw sockets if you're root
<azonenberg_hk>
and UDP is easy enough to do in hardware i'd argue there's no reason not to use it
marcus_c has quit [Ping timeout: 258 seconds]
<azonenberg_hk>
ethernet provides a link layer CRC which is kinda important over long wires
<cr1901_modern>
I mean keep the Ethernet part of the packet, ditch the TCP/IP part
<azonenberg_hk>
Yeah
<azonenberg_hk>
what i meant is, UDP is not hard to implement
<azonenberg_hk>
and port numbers let yo uhave the equivalent of multiple usb endpoints
<azonenberg_hk>
for different types of traffic
<cr1901_modern>
UDP might be okay, but from my own experience, I end up doing a lot of bookkeeping crap in software
<cr1901_modern>
b/c there's no acknowledgement that the xfer even worked
<azonenberg_hk>
Well yeah
<azonenberg_hk>
The alternative is full TCP
marcus_c has joined ##openfpga
<azonenberg_hk>
But then again with usb there's always the possibility of certain kinds of packets being dropped too
<rqou>
warning about raw Ethernet packets:
<cr1901_modern>
Idk if USB has the same problem with acknowledgment
<rqou>
on windows the Intel wired Ethernet driver can eat 802.1q headers
<rqou>
silently
<rqou>
(on RX only)
<azonenberg_hk>
rqou: lol wut
* azonenberg_hk
runs 802.1q to his linux desktop without problems
<azonenberg_hk>
i have like three vlan interfaces
<rqou>
linux works fine
<rqou>
only Windows
<azonenberg_hk>
one to the internet-connected network and two to private test networks w/o intenret access
<cr1901_modern>
azonenberg_hk: Does USB have the same ack problem when I send data?
<rqou>
and only if the Intel driver can feature is disabled
<azonenberg_hk>
its so much easier to debug a prototype on a LAN segment that doesnt have anything talking
<rqou>
*vlan feature
<azonenberg_hk>
cr1901_modern: i know certain kinds of transfers are best-effort
<azonenberg_hk>
I don't know what happens to the others if there's a crc error
<rqou>
I found this out at my Broadcom internship
<azonenberg_hk>
I know i have seen the ftdi stack drop packets occasionally at high data rates but idk if thats usb layer or app layer or silicon issues
<rqou>
I also found that libpcap gets really sad when you dump an actual 1gbps at it :P
<cr1901_modern>
If I used an FTDI FIFO chip, I could be reasonably confident a new entry made it into the FIFO without checking in my own software
<azonenberg_hk>
cr1901_modern: I wish
<azonenberg_hk>
lol
<azonenberg_hk>
You can have reasonable confidence that point to point udp over a short ethernet cable will too
<azonenberg_hk>
But if you try to push say 10 Mbps of JTAG traffic through a FT232H's MPSSE
<azonenberg_hk>
after a few gigabytes you're all but certain to drop a packet
<azonenberg_hk>
and things will get confused
<azonenberg_hk>
i dont know what layer this is happening at
<rqou>
btw funny thing about the way Broadcom's code works
<azonenberg_hk>
USB may well not be responsible
<rqou>
it basically assumed 802.1q is always enabled
<cr1901_modern>
azonenberg_hk: The idea was I thought the USB driver would check to ensure the data got delivered
<rqou>
I think the SDK would assign a default vlan to untagged packets internally
<lain>
in usb you have isochronous, bulk, and interrupt transfers
<azonenberg_hk>
cr1901_modern: I know usb can drop packets at the link layer
<azonenberg_hk>
due to crc fails
<azonenberg_hk>
I know there are recovery mechanisms at upper layers
<azonenberg_hk>
I do not know what level the failure in the ftdi stuff is
<lain>
isochronous are constant-time (audio, usually), and dropped packets are lost forever
<azonenberg_hk>
i also have not tried pcapping mpsse traffic to see what kind of transfers it uses
<lain>
interrupt are polled from the host since all comms are initiated from the host, despite the name (this may differ in usb3, I haven't looked much. I'll be an expert soon enough lol)
<azonenberg_hk>
if memory serves me right the old ft232r used interrupt transfers for everything
<lain>
there's a guaranteed polling interval you can set, I forget how interrupt transfers deal with packet loss / corruption
<cr1901_modern>
recovery mechanisms at upper layers?
<lain>
and bulk are intended for large packets, they are automatically retried
pie_ has quit [Ping timeout: 250 seconds]
<lain>
though I've seen plenty of embedded devices that don't wait for the ack from the host, and just go ahead and load the next packet into the buffer regardless, resulting in corrupt/wrong data
<lain>
*cough* flir *cough*
<azonenberg_hk>
lol
<lain>
actually the flir code is worse than that
<azonenberg_hk>
cr1901_modern: so basically just like tcp :p
<cr1901_modern>
See, USB has an ACK!
<cr1901_modern>
So no I would not trust UDP for most things
<cr1901_modern>
that *I* want to do
<lain>
hehe
<azonenberg_hk>
cr1901_modern: this is why tcp exists
<lain>
U Drop Packets, etc
<cr1901_modern>
azonenberg_hk: You *just* *said* to use UDP ;)
<azonenberg_hk>
But you may find UDP plus application layer retry is better for your application
<azonenberg_hk>
cr1901_modern: And i was speaking about FTDI specifically not being super reliable
<azonenberg_hk>
YMMV but i have seen FT232H's pushing GB of data drop messages
<azonenberg_hk>
And i have not had the time or inclination to debug
<cr1901_modern>
Well I haven't sent out any boards to a fab yet. During Christmas I'll have time to play with Microchip
<azonenberg_hk>
It's to the point that i have retry code in my FTDI JTAG stack
<cr1901_modern>
s SPI Ethernet controllers
<azonenberg_hk>
to work around dropped packets
<azonenberg_hk>
because they happened often enough to interfere with my testing
<cr1901_modern>
how do you know messages are dropped ;)?
<cr1901_modern>
so maybe it might be worth the trouble to replace the FTDI chip with that Microchip IC and a microcontroller
<cr1901_modern>
but idk
<azonenberg_hk>
Because i sent a read command to the board and got nothing back
<azonenberg_hk>
It only takes about 13 minutes to push 1GB of data over 10 Mbps JTAG if you are running flat out
<azonenberg_hk>
1 Gbit is less than 2 minutes
<azonenberg_hk>
What this means is, if you have a 1E-9 error rate you'll have a CRC fail in a packet about every 2 minutes
<azonenberg_hk>
and if 3% of those errors aren't handled you'll have the jtag adapter hang once every hour
<azonenberg_hk>
now multiply that out by a farm of say ten devkits
<azonenberg_hk>
you see the problem? :P
<azonenberg_hk>
i'm pulling these numbers out of my butt but i can say i observed multiple failures per hour in normal use across my test cluster
<lain>
gotta justify this Adobe CC subscription somehow...
<cr1901_modern>
excellent :D
<lain>
:D
* lain
adds a new alias, /great
<rqou>
hmm apparently I got a gpu-related hard lockup
<rqou>
of the host
<rqou>
iommu fail?
<lain>
the bug in the 5520 was so weird, the errata was like... if you do a specific sequence of IO operations, then it'll just go corrupt random memory
<lain>
and they couldn't patch it
<lain>
so they had to just disable that feature... but lots of bios vendors didn't update... so like linux kernel and such have quirks to ignore the iommu supported flags on that one :P
<rqou>
idk what bug I have here
<rqou>
I was updating the VM GPU drivers for what that's worth
<lain>
no idea
<lain>
I hear there are lots of interesting problems around pcie passthrough with gpus, but I don't know enough about it to understand why gpus might be different
<rqou>
at some point I should figure out if it is possible to pass through only one port of my Intel x520 just for extra bugs
<lain>
lol
<rqou>
afaik this is supposed to be possible
<rqou>
as in, one of the features
<lain>
ah
<lain>
magic
<rqou>
it's an enterprise nic
mithro has joined ##openfpga
<felix_>
rqou: it would be awesome if you could buy me the ath10k card with qca9880 (hw version 2) and bring it to the 33c3. do you want paypal now or cash (euro) at the congress?
doomlord has joined ##openfpga
<felix_>
i'll probably also have an openwrt router with that chipset there, but when i poke stuff the vendor didn't intend to be poked randomly, i'd like to have a second chip/card in case i fry the first one ;)
<balrog>
see ya there I guess?
<felix_>
yep
<felix_>
i'm there from day 0-4
<felix_>
i'd highly recommend arriving at day 0 and not day 1; it's effectively a day more congress
<balrog>
I'm arriving afternoon of the 26th
<felix_>
also much less waiting time to get the entry wristband (not sure if that's the correct term in english)
<felix_>
yep, thats day 0
<balrog>
specifically around 3pm
<felix_>
iirc i'll arrive at about 4pm
massi has joined ##openfpga
woddy has joined ##openfpga
amclain has joined ##openfpga
cr1901_modern has quit [Read error: Connection reset by peer]
massi has quit [Ping timeout: 264 seconds]
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
massi has joined ##openfpga
maaku has quit [Ping timeout: 260 seconds]
maaku has joined ##openfpga
Bike has joined ##openfpga
maaku has quit [Ping timeout: 260 seconds]
maaku_ has joined ##openfpga
pie_ has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Changing host]
mifune has joined ##openfpga
mifune has quit [Read error: Connection reset by peer]
mifune has joined ##openfpga
mifune has quit [Changing host]
mifune has joined ##openfpga
massi has quit [Remote host closed the connection]
rvense has quit [Read error: Connection reset by peer]
rvense has joined ##openfpga
maaku_ has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
flaviusb has joined ##openfpga
<jhol>
felix_: I wish I could join the fun - I will have to settle for watching via Kodi from a semi-compatible time-zone
<jhol>
I saw that repo, but it look's very GreenPak-ish from the title on the main page
scrts has joined ##openfpga
<pie_>
well i think openfpga is greenpak at this point?
digshadow has joined ##openfpga
<pie_>
i mean thats what it supports
<pie_>
but idk, i kinda just hang around in here because there's bound to be a bunch of cool stuff :P
<jhol>
uwe_: how many mediawikis are running on that sigrok's VM? I wonder if these folks could be furnished with a proper wiki instead of this GitHub buisiness
<jhol>
- something to think about
doomlord has joined ##openfpga
<pie_>
pointfree, if nothing else, you might start collecting stuff on an etherpad or something
<pointfree>
pie_: I'm adding a section to the wiki right now.
<pointfree>
Anyone have the reference for the icestorm paper?
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<pointfree>
...actually, every one of these papers has a code repository of sorts, so I think these could all go into the section "Other Projects"
<pie_>
pointfree, but what if you find something htat doesnt? :P
qu1j0t3 has quit [Ping timeout: 258 seconds]
firebird_ has quit [Ping timeout: 240 seconds]
<pointfree>
pie_: I can't think of any such papers where the authors didn't implement anything. If the code is unavailable we can link to the paper and the link to the repo will just be unclickable text (I can't think of any examples). IMHO proprietary projects are out of scope. This organization can all be changed whenever.
<rqou>
hmm anyone here familiar with vhdl footguns?
<rqou>
if i am reading the vhdl formal grammar correctly, a'b'c can be interpreted as a "name"
<rqou>
even though the middle part looks like a character literal
<pie_>
isnt vhdl a footgun? </imjoking>
<rqou>
sure
cr1901_modern has joined ##openfpga
<rqou>
ok, apparently vhdl managed to not footgun themselves
<rqou>
a'b'c is a valid production according to the EBNF
<rqou>
but it can't ever actually occur
<rqou>
because you can't assign an attribute to an attribute
<rqou>
only to a simple_name
<rqou>
i think?
azonenberg_hk has quit [Ping timeout: 260 seconds]
<cr1901_modern>
vhdl is an unrestricted grammar IIRC
<cr1901_modern>
so you're fucked trying to parse it anyway
<cr1901_modern>
Idk how it works tho; prob similar to how C++ grammar is undecidable, but I never understood why.
<rqou>
afaik vhdl isn't undecidable
<rqou>
hilariously enough, perl is undecidable
<rqou>
i think vhdl just happens to have a really shitty reference ebnf
<mtp>
perl is undecidable for much the same reason that C++ is
<cr1901_modern>
How does one parse an undecideable grammar. Most parsing books only talk about the context-free case (and C is close enough that the extra logic you have to add is more of a pain in the ass to write than "difficult to understand")
<rqou>
you have to parse and evaluate simultaneously
<cr1901_modern>
s/books/reference/
<cr1901_modern>
evaluate *what* exactly?
<pie_>
cr1901_modern, part of c++ undecidability is that templates are turing complete i think
<rqou>
templates for C++, something that I don't understand for perl
<pie_>
idk if theres anything past templates making the issue
<rqou>
my favorite (/s) parser is php's
<pie_>
cr1901_modern, for fun times, probably try SKI calculus
<rqou>
it generates bytecode directly from the parser
<rqou>
because they had no idea what they were doing
<rqou>
not to be confused with lua's ad-hoc parser that also generates bytecode directly from the parser as a deliberate choice to make the parser faster and simpler
<rqou>
*make the interpreter
<rqou>
btw scala accidentally made themselves undecidable too
<rqou>
but afaik it's not at the parse stage
<rqou>
it's at the type evaluation stage
<rqou>
scala's type system can implement an ski calculus
<rqou>
but apparently if you actually try it the compiler will stack overflow
<cr1901_modern>
I've seen it long ago, but thanks :P
<azonenberg_hk>
rqou: well i know c/c++ macros allow a lot of stuff
<azonenberg_hk>
not sure if turing complete or not
<azonenberg_hk>
i know c++ templates are
<rqou>
macros are explicitly designed to not be turing complete
woddy has joined ##openfpga
<rqou>
although it becomes turing complete if you can loop the output back through the preprocessor again
<pie_>
macros are like, one or two pass maybe i think_
<pie_>
?
<azonenberg_hk>
rqou: you can #include yourself
<azonenberg_hk>
which allows recursion
<rqou>
afaik that's not sufficient
<azonenberg_hk>
most compilers will crash after too many levels
<pie_>
hm.
<azonenberg_hk>
but the spec allows it
<pie_>
ah heh xD
<azonenberg_hk>
I once saw a macro that implemented a ~14 bit ALU out of bitwise operations
<rqou>
oh you missed me talking about vhdl earlier
<azonenberg_hk>
and calculated the prime numbers up to... 2048?
<azonenberg_hk>
statically at compile time, lol
<rqou>
according to the vhdl ebnf, a'b'c is a valid example of a "name"
<azonenberg_hk>
Took many GB of RAM and only one compiler the author could find would build it without segfaulting
<azonenberg_hk>
i saw that, wow
<rqou>
but apparently that can't actually happen
<rqou>
i don't know if you saw that part, but afaik you can't assign an attribute to another attribute
<pie_>
i cant look it up right now but theres a fun thing, probably unrelated, about generating the llargest possible error message when compiling c++ i think?
<pie_>
its somewhere on stackoverflow
<rqou>
you can only assign an attribute to a "simple_name"
<azonenberg_hk>
pie_: there is a contest for that
<pie_>
golf probably
<pie_>
*codegolf
<azonenberg_hk>
for largest ratio of gcc stderr size to source file size
<rqou>
so apparently the vhdl designers actually thought about footguns but just did a terrible job writing the ebnf
<azonenberg_hk>
lol
<pie_>
something something vhdl wasnt designed for the purpose its used for
<pie_>
but i could be wrong
<pie_>
well im thinking of verilog. idk about vhdl
<rqou>
both were designed as simulation modeling languages
<rqou>
not for synthesis
<pie_>
yeah that
<rqou>
vhdl doesn't talk about how to do synthesis at all