Flea86 has joined ##openfpga
amclain has joined ##openfpga
noobineer has quit [Remote host closed the connection]
amclain has quit [Client Quit]
greg__ has quit [Quit: Leaving]
noobineer has joined ##openfpga
C_Elegans has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
unixb0y has quit [Ping timeout: 245 seconds]
unixb0y has joined ##openfpga
Bob_Dole has joined ##openfpga
Bob_Dole has quit [Remote host closed the connection]
GenTooMan has quit [Quit: Leaving]
C_Elegans has quit [Ping timeout: 250 seconds]
noobineer has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
dx has quit [Quit: RIP]
Guest85560 has joined ##openfpga
Guest85560 has quit [Changing host]
Guest85560 has joined ##openfpga
Guest85560 is now known as dx
Miyu has quit [Ping timeout: 272 seconds]
pie__ has joined ##openfpga
pie___ has quit [Ping timeout: 268 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 246 seconds]
ZipCPU|Laptop has joined ##openfpga
s_frit has quit [Ping timeout: 245 seconds]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 244 seconds]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
mumptai has joined ##openfpga
_whitelogger has joined ##openfpga
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
_whitelogger has joined ##openfpga
rohitksingh has joined ##openfpga
Asu` has quit [Quit: Konversation terminated!]
Asu has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
Miyu has joined ##openfpga
rohitksingh has quit [Ping timeout: 272 seconds]
rohitksingh has joined ##openfpga
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 250 seconds]
finsternis has quit [Excess Flood]
finsternis has joined ##openfpga
Zorix has quit [Quit: Leaving]
Zorix has joined ##openfpga
<adamgreig> yay, my ip stack replies to ping as well as arp... most of the time
<tnt> \o/ nice. Is that fully hw, or running in a soft core ?
<adamgreig> fully hw
<adamgreig> at 100MHz
<tnt> ecp5 ?
<adamgreig> ice40hx
<tnt> hah right, there are also the hx in the 'fast enough' list :)
<adamgreig> yea i think i'd have to slow it down a bit on the up5k :P
<adamgreig> the 10/100 MAC RMII interface runs in its own domain so you can just run the ip core at whatever speed i guess
<adamgreig> it does one byte per clock
<tnt> yeah. You can run stuff at 100M on there ... but has to be very careful :p
<adamgreig> i already have to get a bit lucky with the seed to meet timing
<adamgreig> Info: Max frequency for clock 'mac_clk': 100.85 MHz (PASS at 100.00 MHz)
<tnt> :)
<adamgreig> but twiddling the seed a bit gives me +-20MHz
<adamgreig> next problem is working out why it sometimes ignores packets
<adamgreig> or perhaps adding udp
rrika has left ##openfpga ["Leaving"]
<adamgreig> 1477 packets transmitted, 1344 received, 9% packet loss, time 2144ms
<adamgreig> rtt min/avg/max/mdev = 0.053/0.057/0.105/0.008 ms, ipg/ewma 1.452/0.056 ms
<adamgreig> 57µs rtt though
<tnt> :)
<adamgreig> not bad for a 100Mbps link
<Bob_Dole> remember when hardware accelerated IP-stacks with proprietary firmware were being sold to consumers because pentium 4's could get bogged down on handling gigabit ethernet?
<adamgreig> and now 500 lines of python and a £4 fpga eats it up ;)
<Bob_Dole> not sure if they handled udp or just tcp
<adamgreig> i suspect those implemented a lot more of tcp/ip than my thing does though
<adamgreig> this is definitely not fully compliant ;)
<Bob_Dole> thinking about it, I wonder if the folks still nursing along their amigas and putting them on the net would appreciate hardware accelerated tcp/ip stacks...
<Bob_Dole> the C64 folks like the ESP mcu ones at least.
<gruetzkopf> we amiga people jumped to "plain ip over printer port" for the cheapo solution
the_new_lfsr has joined ##openfpga
<pie__> extra credit for if youre just printing IP packets
rohitksingh has quit [Ping timeout: 250 seconds]
<jn__> pie__: then you have a IPoAC gateway
rohitksingh has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
the_new_lfsr has quit [Ping timeout: 256 seconds]
ZipCPU|Laptop has quit [Ping timeout: 246 seconds]
ZipCPU|Laptop has joined ##openfpga
the_new_lfsr has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
C_Elegans has joined ##openfpga
<azonenberg> Bob_Dole: i'm doing hardware accelerated TCP for 1/10GbE
<azonenberg> But it's not because the CPU is too slow, it's because it's on an FPGA board that *has* no cpu :p
the_new_lfsr has quit [Ping timeout: 256 seconds]
C_Elegans has quit [Ping timeout: 264 seconds]
ZipCPU|Laptop has quit [Remote host closed the connection]
<cr1901_modern> IME tcp/ip stacks aren't the thing that need hardware accelerating (I can live with a 10Mbps link); it's the crypto that needs accelerating and Idk a good solution for SSL other than "use a Pi/some other SBC several times more powerful than the vintage machine to do it for you"
<cr1901_modern> And that's no fun
<azonenberg> cr1901_modern: most stm32s have hardware AES
<cr1901_modern> Slowest machine I've heard of doing SSL under it's own power is a 25MHz 68030
<azonenberg> curve25519 isnt too cpu hungry and you only need to do it when you open the link
<cr1901_modern> azonenberg: Well certainly I'm not against like an ISA card crypto accelerator :).
<cr1901_modern> I just don't want to cheat w/ a Pi/SBC
<azonenberg> lol
<cr1901_modern> Assign two Port I/O locations, feed it your input on one port, read the status on the same port, and read out the result on the second port a few hundred to few thousand clk cycles later
<adamgreig> woo, all my packet loss was due to poorly thought out cdc
<adamgreig> 132085 packets transmitted, 132084 received, 0% packet loss, time 8433ms
<adamgreig> rtt min/avg/max/mdev = 0.041/0.054/0.247/0.009 ms, ipg/ewma 0.063/0.057 ms
<adamgreig> who would have thought "DummyAsyncFIFO" might not be legit
the_new_lfsr has joined ##openfpga
gsi_ has joined ##openfpga
the_new_lfsr has quit [Quit: Page closed]
noobineer has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
ZipCPU|Laptop has joined ##openfpga
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 245 seconds]
mkdir has joined ##openfpga
<mkdir> does block ram just act like cache
<mkdir> or rather, how does cache differ from main memory
<pie__> ...distributed memory sounds more appropriate, depending on what youre doing? (i'unno)
<adamgreig> are you asking in general or for fpgas or what?
<adamgreig> on a typical desktop computer, main memory is separate on the motherboard, made from DRAM, so is slower but cheaper and smaller for the same capacity compared to SRAM which you typically use for cache
<adamgreig> but there's probably several layers of SRAM cache, getting slower and bigger the closer to the dram it gets
<adamgreig> on an fpga.. it's all whatever you want it for
<adamgreig> cache is just one thing you might use memory for
feuerrot has quit [Ping timeout: 264 seconds]
<mkdir> thanks for your response, well i'm just curious how fetching items from block ram is different than fetching items from main memory
<mkdir> is it similar to fetching items from cache i.e very fast
<tpw_rules> depends on the memory
<mkdir> fetching / reading data
<tpw_rules> block ram is just ram on the fpga
<adamgreig> typically accessing block ram is fast, it's usually just you put an address on the address pins and 0-2 clock cycles later you get data on the data pins
<tpw_rules> but there's nothing stopping you from wiring up an equally capable chip to the fpga
<adamgreig> compared to external DDR DRAM where you have to do a whole bus transaction to request data, it's usually going to be quicker
<mkdir> i see
<mkdir> i guess the reason i'm asking from a cpu perspective (i.e main memory and cache structure) is because im trying to learn fpgas
<adamgreig> the distinctions are between sram and dram (sram is faster but lower capacity), and onboard the fpga or not (onboard is easy but you often don't have much of it)
<mkdir> currently do firmware only :9
<tpw_rules> block ram is whatever you want it to be. in most of my designs, it's all the ram the design uses, since it's enough
<Bob_Dole> dram is "slow", and SRAM is expensive to get even a few MB of truly fast SRAM.
<tpw_rules> but i only do lame small designs
<adamgreig> but the fpga is sort of made of sram too
<mkdir> can block ram be configured as sram or dram
<mkdir> os it only one type?
<adamgreig> no, sram or dram is defined by the hardware silicon
<tpw_rules> but you do get all kinds of config operations
<adamgreig> they're physically different ways to store data
<tpw_rules> how wide, how deep, how much latency, how many ports
<Bob_Dole> sram is 6 transistors, dram is 1-3 transistors and a capacitor
<mkdir> i see
<mkdir> thanks guys, i have to read more now before i ask more questions
<Bob_Dole> the dram cells need to be a lot more complicated because of the need to keep the capacitors refreshing their charge, and being able to handle the reads and replenishing the cap after, and then all the extra stuff and features added since. an SRAM will just maintain itself as long as it has power and is always ready to be read or written.
<Bob_Dole> s/dram cells/dram memories/\
<tpw_rules> i would be surprised of m/any fpgas had block dram
<Bob_Dole> edram is a thing so it'd be possible
<adamgreig> you can get fpga+hbm in one package
<adamgreig> but it's not what you'd call 'block ram' really :P
<Bob_Dole> but adds fabrication cost, think it requires some slightly different production processes than is suited for large logic chips? I think the xbox 360 used a few hundred MB of it.
<Bob_Dole> I mean the edram, not hbm obviously
<Bob_Dole> (not that HBM is anything beginning to resemble cheap.)
mumptai has quit [Quit: Verlassend]
<daveshah> There are a few FPGAs with a bog standard DRAM (SDRAM, DDR2 or PSRAM) in the package
<daveshah> Gowin and Anlogic have them iirc
futarisIRCcloud has joined ##openfpga
feuerrot has joined ##openfpga
Asu has quit [Remote host closed the connection]
<Thorn> why is there never on-chip dram though? does it require completely different process than logic or something?
mkdir has quit [Ping timeout: 256 seconds]
X-Scale has quit [Ping timeout: 245 seconds]
feuerrot has quit [Ping timeout: 264 seconds]
feuerrot has joined ##openfpga
<sorear> Thorn: yes. DRAMs need a bunch of extra steps to create large capacitors
Miyu has quit [Ping timeout: 246 seconds]