ZipCPU|Laptop has quit [Ping timeout: 250 seconds]
X-Scale has joined ##openfpga
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 268 seconds]
noobineer has quit [Ping timeout: 252 seconds]
Flea86 has joined ##openfpga
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
xdeller_ has quit [Read error: Connection reset by peer]
xdeller_ has joined ##openfpga
gsi_ has quit [Ping timeout: 250 seconds]
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 240 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
s_frit has joined ##openfpga
rohitksingh_work has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
<tnt>
adamgreig found your bug ?
gsi_ has joined ##openfpga
_whitelogger has joined ##openfpga
jeandet has quit [*.net *.split]
nats` has quit [*.net *.split]
nats` has joined ##openfpga
jeandet has joined ##openfpga
ZipCPU|Laptop has quit [Remote host closed the connection]
ZipCPU|Laptop has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]
zem has quit [Ping timeout: 244 seconds]
zem has joined ##openfpga
Flea86 has joined ##openfpga
m4ssi has joined ##openfpga
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 250 seconds]
Asu has joined ##openfpga
<adamgreig>
tnt: bad CDC :p
<azonenberg>
adamgreig: not even knowing anything about your design or bug
<azonenberg>
i'm not surprised :p
<adamgreig>
Yea :p it was in the dummy (depth 1) async FIFO I wrote...
<adamgreig>
So no surprises there
<azonenberg>
I actually have such a block that i wrote that I call RegisterSynchronizer
<azonenberg>
Since the primary intended use is pushing config registers from a slow (jtag etc) clock domain into the main system clock
<adamgreig>
So nmigen has a built in for doing a register chain, which is what I was using, and maybe soon will get an async fifo, which is what the design really wants
<adamgreig>
But in the meantime I was using a register chain from fast to slow and not holding the state valid in fast for long enough to get samples by slow
<adamgreig>
(and no handshake in the other direction)
<azonenberg>
yeah flow control is a must when the speeds differ significantly
<tnt>
adamgreig: another common bug is ethernet checksum error for short frames
<tnt>
(ones that need padding)
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
<adamgreig>
tnt: yep, my MAC adds the checksums itself but its first bug was straight up not adding any padding and wondering why my packets weren't getting through :p
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Miyu has joined ##openfpga
<azonenberg>
adamgreig: mistakes everyone makes
<azonenberg>
you know what i really need to do at some point?
<azonenberg>
make a bunch of f/oss ethernet verification IP
<azonenberg>
that people can use for testing
<adamgreig>
that'd be nice
<azonenberg>
i already have a fake GMII PHY that bridges to a linux tap device, but i need to package it up in a more useable format
<azonenberg>
maybe eventually add some fake MDIO buses and everything
<azonenberg>
and lots of logging and detection of invalid behavior
<azonenberg>
right now it doesn't check the outbound CRC for example
<adamgreig>
wouldn't linux flag that once it got through the phy?
<azonenberg>
There isn't a phy, though
<adamgreig>
I mean the fake gmii phy to tap
<azonenberg>
/dev/net/tun works with "layer 2.5" frames
<adamgreig>
but on reflection i don't think taps do check ethernet fcs
<adamgreig>
yea
<azonenberg>
802.3 framing but without the preamble or fcs
<azonenberg>
Right now, i add a preamble and 0xdeadbeef FCS in the tap-to-gmii direction and set a register in my mac to ignore the fcs
<adamgreig>
i guess it's more of a fake phy+mac
<azonenberg>
then in the gmii-to-tap direction i discard both
<azonenberg>
But if i wanted a proper verification IP block i'd need to implement fcs checking/generation in the bridge, take the pipe filenames as arguments instead of hard coding them
<azonenberg>
and generally sanity check more
<adamgreig>
seems like it would be less effort to have the phy just check the fcs :P
<azonenberg>
This is very much on my todo though, having somebody interested in it makes it higher on my priority list
<azonenberg>
To start, it will be gigabit only and not support 10/100 mode
<azonenberg>
but i'll be adding that next
<adamgreig>
at the moment all my test/sim is in nmigen which probably makes cosimulation with a verilog tb a bit of a faff, but i can always dump the module to verilog and simulate that normally
<adamgreig>
this one is rmii but now i have a taste for it i wanna make up an ecp5 board with rgmii
<azonenberg>
This is systemverilog, i'm using vivado
<azonenberg>
however i can probably make it work with straight verilog
<azonenberg>
most of the bridge logic is actually a C native application
<azonenberg>
that talks to the simulator via $fscanf() and $fdisplay() on a pair of pipes :p
<adamgreig>
haha
<adamgreig>
of course
<azonenberg>
(linux only for now)
<azonenberg>
VPI is a nightmare to use in most simulators
<azonenberg>
it segfaults vivado so hard the entire gui crashes, not just the simulator process
<azonenberg>
So i gave up
<azonenberg>
pipes work in isim, vivado, and vcs
<azonenberg>
(i havent tried any other simulators yet)
<azonenberg>
if you're interested in testing what i have set up right now, check out azonenberg/starshipraider
<azonenberg>
the last few days of commits should include the relevant files
<azonenberg>
no promises it will work in your deployment and it's not what i would consider a shipment ready verification solution, but i'd love to hear if you got it working in another simulator
<adamgreig>
might see if icarus can handle it
<azonenberg>
And if i have some spare time over the coming days i will probably add more extensive sanity checking to it
<azonenberg>
and maybe even write some documentation :p
<adamgreig>
that's when you know you have too much spare time :p
<azonenberg>
it will probably eventually move to antikernel-ipcores which is where i put modules i expect to get used by other people
<azonenberg>
right now its in the starshipraider repo as that's the only project i've even attempted to test with it
<daveshah>
adamgreig: the Versa has RGMII (and SGMII)
<adamgreig>
yes that would definitely be the sensible option...
<azonenberg>
when i hear "versa" i think the fei dual beam sem/fib
<azonenberg>
somehow assuming this isn't what you mean
<azonenberg>
adamgreig: i'd like to make one for rgmii and sgmii too
<daveshah>
ECP5-Versa
<azonenberg>
most of my boards are rgmii but they have a gmii-to-rgmii bridge internally
<azonenberg>
so i just bodge the tap interface on before the bridge
<daveshah>
It has two 88E1512 PHYs both wired for RGMII or SGMII
futarisIRCcloud has joined ##openfpga
<daveshah>
both with magjacks
<azonenberg>
daveshah: nice
<azonenberg>
i havent done any sgmii yet, successfully :p
<azonenberg>
i've done mii, rgmii, gmii, plus rolled my own 1000base-X and 10Gbase-R PCS
<azonenberg>
there is a rmii link on my integralstick board between the fpga and mcu but i haven't brought it up yet
<adamgreig>
daveshah: but for twice as much money i could make my own board with a single probably-broken rgmii!
<azonenberg>
then i have a vcu118 with a sgmii phy that i had trouble getting working, need to get back to that at some point
<adamgreig>
i like the idea of rmii direct between the fpga and mcu
<azonenberg>
It was easier for me to pull one lane off the QSFP+ interface and run that at 10G
<azonenberg>
than to get the sgmii phy working :P
<adamgreig>
lol
<azonenberg>
i felt bad moving a few Kbps of UDP traffic
<azonenberg>
over a 10GbE link, occupying one lane of a 40GbE optic
<azonenberg>
sitting in a 100GbE socket
<azonenberg>
massive waste :p
<adamgreig>
just in case you wanna watch several simultaneous blu-rays while sending your kbps of control data
<azonenberg>
Lol
<azonenberg>
don't you mean several simultaneous *uncompressed* 4kp120 video streams? :p
<azonenberg>
maybe make them 3d on top of that, it's only double the bandwidth
<adamgreig>
the optic will barely notice
<adamgreig>
hmm, my ice40 rmii interface meets timing at 125MHz, I wonder if i could push it to rgmii on the ice40
<adamgreig>
even if i I could, the actual packet core couldn't hope to keep up
<adamgreig>
azonenberg: does your ip stack start processing packets as soon as they start coming in, or do you wait for a full packet to get received and fcs checked first?
<adamgreig>
i use a bram to move packet data between the clock domains, and the mac only tells the ip stack there's a valid packet there after it's checked the fcs
<azonenberg>
My previous stack ran in the rx clock domain and was fully realtime
<daveshah>
I think RGMII on hx8k should be doable
<azonenberg>
the new stack is meant to handle multiple ports so you can't do that, clock domain crossing is unvaoidable
<adamgreig>
azonenberg: so it processed bytes as they appeared from the wire and didn't store them at any point?
<azonenberg>
Yeah
<adamgreig>
how did you handle a bad fcs?
<azonenberg>
i'll get to that in a sec :)
<azonenberg>
anyway, the new stack has a cross clock FIFO on the input that i made specifically for processing packetized data
<azonenberg>
it has commit/rollback semantics where the pointer for the RX side isn't updated until the TX asserts the "commit" signal
<azonenberg>
"rollback" restores the write pointer to its value at the start of the packet
<adamgreig>
daveshah: yea.. i might try making up a simple rgmii ice40 board to try it out
<azonenberg>
So if there'
<azonenberg>
if there's a bad FCS, I just roll back the packet
<azonenberg>
Once the packet is in the IP stack clock domain, however, i handle errors differently
<azonenberg>
everything is streaming from there on out
<whitequark>
TD-Linux: um, so i received your revB
<whitequark>
the USB connector works *very* badly
<azonenberg>
I have a bus with a flag for start, data valid, the data itself (32 bits per clock)
<azonenberg>
number of bytes valid (only checked for end of packet, must be 4 until the end)
<azonenberg>
then commit and drop flags
<azonenberg>
so if you have a bad checksum or something you assert drop, then the upper layer protocol discards any pending state changes and doesn't reply to the packet
<azonenberg>
whereas if the checksum is good, you assert commit and then the upper level protocol can actually act on the packet
<azonenberg>
but all the parsing is done in a streaming fashion
<adamgreig>
makes sense
<azonenberg>
the only store-and-forward is at the MAC, because i have to jump clock domains
<adamgreig>
once my data is in the ip domain it's similar, the packet streams continuously from bram through all the parsing which starts streaming tx packet data back as it goes
<azonenberg>
my switch fabric will be similarly structured, store and forward FIFO into the switch fabric domain
<azonenberg>
then streaming from there
<adamgreig>
what sort of depths are those fifos?
<azonenberg>
the CDC fifo is one packet plus a little extra, i think 2KB?
<azonenberg>
the fifo for the switch fabric will be deeper because the fabric can block in some cases
<azonenberg>
also, because all the crossbar paths in the fabric are 10G but some interfaces are 1G
<adamgreig>
does the packet fully stream into the fifo before it starts coming out?
<azonenberg>
(also, its 3am and i need some sleep)
<adamgreig>
lol fe :P
<azonenberg>
yes, that's where the commit/rollback semantics come in
<adamgreig>
i am being called away anyway, thanks for the chat
<adamgreig>
bbl
<azonenberg>
the rx sees the fifo as empty until the tx hits commit
<azonenberg>
at which point an entire packet appears instantly
<azonenberg>
the fifo also supports random access reads within a packet, which i don't use here but have when parsing other protocols
<azonenberg_work>
INTEGRALSTICK prototype is assembled, need to make a breakout to test still
<azonenberg_work>
Bad footprint on the mac address eeprom requiring a bit of rework
<azonenberg_work>
But if you aren't using the ethernet, are OK with hard coding a mac address in the bitstream or MCU firmware / burning it into flash, or are willing to generate a random MAC from the FPGA serial # you can just DNP the eeprom
azonenberg_work has quit [Ping timeout: 246 seconds]
emeb has joined ##openfpga
<keesj>
azonenberg: what are the flat wires you used to rework the eeprom?
azonenberg_work has joined ##openfpga
<mwk>
what kind of capabilities does the ECP5 ff have?
<mwk>
clock + clock enable + set/reset input, can be set sync or async, set/reset value has to match init value?
<daveshah>
Ah, this is a fun one
<daveshah>
Yes
<mwk>
so
<daveshah>
It also has a preload mode which Diamond doesn't use but I discovered recently
<mwk>
how is that last part handled in yosys?
<mwk>
... preload?
<daveshah>
Where the set reset pin loads the value, sync or async, from the slice "M" input
<daveshah>
So it will just set the set/reset value to match init if SR isn't used
<mwk>
ahh, thanks
<daveshah>
If it is used and matches it does nothing
<mwk>
this is exactly what's needed for spartan6 as well
<daveshah>
If it doesn't match, it will convert sync resets back to logic and warn on async resets that don't match
<daveshah>
Huh
<daveshah>
It's a common design pattern I guess, having ff init done by global set/reset
<mwk>
it has CLB identical to series7, except SRVAL has to be equal to INIT
<daveshah>
Interesting
<mwk>
Xilinx tools use the exact same primitives for both, and emulate / yell at you if there's a conflict
<mwk>
for spartan 6
<whitequark>
daveshah: the JTAGG primitive looks weird to me
<whitequark>
how does it work
<daveshah>
I don't know
<daveshah>
Just copied the blackbox so far
rohitksingh has quit [Read error: Connection reset by peer]
<mwk>
"For Spartan®-6, Xilinx recommends that the INIT value always matches the polarity of the set or reset. For this element, the INIT should be 0. If set to 1, an asynchronous circuit must be created to recommend."
<mwk>
I guess this means log_error for us
<daveshah>
Traditionally in Yosys unhandled init values are warnings
<daveshah>
Because ignoring them altogether is perfectly legal for synthesis
<daveshah>
indeed icecube does, for example
<mwk>
ugh, this language
<whitequark>
daveshah: oh, i have a request
<whitequark>
if a reg is assigned from always @* block, the init value should be removed (or maybe not emitted)
<whitequark>
do you think you can fix that?
<daveshah>
I don't know
<daveshah>
I don't have much spare time over the next few weeks
<whitequark>
ah ok
<whitequark>
that's fine then
<mwk>
daveshah: alright then, I'll do something similiar
<mwk>
thanks for the pointer
m4ssi has quit [Remote host closed the connection]
<azonenberg_work>
whitequark: yeah i agree that should be fixed
<azonenberg_work>
its caused problems for me with yosys in the past
<azonenberg_work>
and sometimes you cant remove the init value, because say you have a module that's parameterizable to have different pipeline depths
<azonenberg_work>
and if deeper you want the init
<whitequark>
azonenberg_work: yep
<whitequark>
nmigen generates rtlil that yosys later infers as init value, too
<whitequark>
hm
<whitequark>
actually i can probably fix this in nmigen
<whitequark>
which might lead to slightly more readable code, too?
<_whitenotifier-c>
[Glasgow] smunaut commented on pull request #90: Add iCE40 boards flashing support - https://git.io/fhgq0
<azonenberg_work>
whitequark: i'd rather fix in yosys since it will work for straight verilog too
<_whitenotifier-c>
[Glasgow] whitequark commented on pull request #90: Add iCE40 boards flashing support - https://git.io/fhgq6
<whitequark>
azonenberg_work: oh sure
<whitequark>
i was more thinking, whether i should fix this in nmigen *as well*.
<whitequark>
the nmigen fix would be trivial.
<TD-Linux>
whitequark, you mean it didn't reflow correctly?
<TD-Linux>
unfortunately I only plugged it in long enough to do all of the selftests, so I would have missed spotty mechanical connection
zng has quit [Quit: ZNC 1.8.x-nightly-20181211-72c5f57b - https://znc.in]
zng has joined ##openfpga
zng has quit [Client Quit]
zng has joined ##openfpga
zng has quit [Client Quit]
zng has joined ##openfpga
ZipCPU has joined ##openfpga
ZipCPU|Alt has joined ##openfpga
<_whitenotifier-c>
[Glasgow] gregdavill commented on pull request #90: Add iCE40 boards flashing support - https://git.io/fhgCh
ZipCPU|Alt has quit [Ping timeout: 268 seconds]
ZipCPU|Alt has joined ##openfpga
<_whitenotifier-c>
[Glasgow] mithro commented on pull request #90: Add iCE40 boards flashing support - https://git.io/fhg8M
noobineer has joined ##openfpga
<azonenberg_work>
adamgreig: re your 1us ping times
<azonenberg_work>
what phy are you using, and what OS/NIC?
<azonenberg_work>
i have a hard time getting below ~30 us
<azonenberg_work>
Even with a 10G link that loops back right after the MAC
<azonenberg_work>
i think it's mostly interrupt handling latency on my PC
<adamgreig>
the ping time to my desktop is 40µs, the fpga processing time is 1µs
<azonenberg_work>
ooooh
<azonenberg_work>
ok that makes a lot more sense
<adamgreig>
the 100Mbps link takes about 10µs just to relay the packet
<azonenberg_work>
yeah
<azonenberg_work>
this is 10/100 not gig? especially good then
<adamgreig>
yea, 100Mbps rmii
<azonenberg_work>
on gig i think 39 us is my best round trip time
<adamgreig>
and through a gig switch to my desktop
<adamgreig>
would like to try plugging it directly to desktop but foolishly made it PoE only and don't have any 802.3af injectors
<azonenberg_work>
Lol
<azonenberg_work>
oops
<azonenberg_work>
time to pick one up?
<adamgreig>
yea probably :p
<adamgreig>
that or respin a gige rgmii and remember to put a power header on it
<azonenberg_work>
then you can get a T-shirt with a picture of a 4-channnel center tapped transformer going to a buck converter
<azonenberg_work>
and the caption "I'm 802.3 AF"
* azonenberg_work
hides
<adamgreig>
hah
<adamgreig>
perfect work attire
<adamgreig>
at least one of my colleagues is in here, don't give them ideas :P
<azonenberg_work>
i've wanted that shirt for a while
<azonenberg_work>
never had the time to do the artwork
<azonenberg_work>
it would have to be some kind of circuit diagram depicting PoE in some way
<adamgreig>
azonenberg_work: ok, i bodged up a power supply and plugged it direct
<adamgreig>
33µs best rtt
<adamgreig>
rtt min/avg/max/mdev = 0.033/0.038/0.095/0.007 ms
<sorear>
so, time for a fpga board that just does icmp echo requests and times the replies with minimum overhead? :)
<adamgreig>
hehe
<adamgreig>
I could shave 5µs off this by starting to reply before it finishes receiving the packet
<adamgreig>
but not sure it's really worth the incredible faff :P
<adamgreig>
if only i'd brought up two boards, i could just plug them in to each other
Asu has quit [Remote host closed the connection]
<sorear>
the 802.3af injector doesn’t add measurable latency or does it?
<adamgreig>
i wouldn't expect so, it should just passively patch the data pairs right through
<azonenberg_work>
sorear: how long are the wires?
<azonenberg_work>
multiply by 0.6*C...
paul_99 has quit [Read error: Connection reset by peer]
<gruetzkopf>
azonenberg_work: don't give me ideas for what tshirt to make next