<awygle> mm
<awygle> how different i wonder
<sorear> well this is a FPGA, so the O(20 ps) gate delays are going to be swamped by wire delay in most cases
<awygle> yeah but wire delay is symmetrical
<awygle> so in terms of duty cycle/asymmetry it'd be the buffers, right?
<sorear> to the extent that wire delay is a function of distributed capacitance (and not transmission-line effects) it could be affected by asymmetrical drive current
<awygle> hm, that's true
* sorear has a very poor grasp of on-chip inductive effects
s_frit_ has quit [Remote host closed the connection]
s_frit has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
azonenberg_work has quit [Ping timeout: 245 seconds]
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/2ee309db8980...f44acd0a9d72
<openfpga-github> Glasgow/master ea54b02 whitequark: applet.spi.flash_25c: query JEDEC database to identify flash.
<openfpga-github> Glasgow/master f59e1a1 whitequark: applet.spi.master: implement optimized reads/writes....
<openfpga-github> Glasgow/master f44acd0 whitequark: applet.spi.flash_25c: use optimized reads/writes.
<whitequark> sorear: f44acd0a9d72e
<whitequark> errrr
unixb0y has quit [Ping timeout: 264 seconds]
<whitequark> sorear: 23:59 < sorear> which, well, CMOS, so the rise and fall times are going to be different
<whitequark> doesn't all modern CMOS have larger PMOS transistor than NMOS?
<whitequark> like just in the standard cells
unixb0y has joined ##openfpga
Miyu has joined ##openfpga
<sorear> I wouldn't know
<sorear> but even with compensation it won't be exactly the same
Miyu has quit [Ping timeout: 240 seconds]
<sorear> so running a clock through a large number of simple CMOS buffers is not the best idea
<whitequark> mh, true
<travis-ci> whitequark/Glasgow#107 (master - f44acd0 : whitequark): The build has errored.
futarisIRCcloud has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/f44acd0a9d72...7176c8520bc8
<openfpga-github> Glasgow/master 7176c85 whitequark: applet.spi.flash_25c: add protect command.
<openfpga-github> Glasgow/master 3900447 whitequark: applet.spi.flash_25c: check for command completion success.
<openfpga-github> Glasgow/master 76d4c8d whitequark: applet.spi.flash_25c: add verify command.
* sorear wonders if this is what differential buffers are for
ym has quit [Quit: Leaving]
lovepon has joined ##openfpga
<travis-ci> whitequark/Glasgow#108 (master - 7176c85 : whitequark): The build has errored.
<awygle> early results indicate my 20% duty cycle was not the result of routing buffers but a very badly implemented clock mux
unixb0y has quit [Ping timeout: 272 seconds]
Xark_ has left ##openfpga ["Leaving"]
unixb0y has joined ##openfpga
Xark has joined ##openfpga
emeb has left ##openfpga [##openfpga]
pie_ has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
noobineer has joined ##openfpga
Ekho- is now known as Ekho
azonenberg_work has joined ##openfpga
<azonenberg_work> awygle: i imagine they try to design internal buffers to be as symmetric as possible
<azonenberg_work> because otherwise you end up having the slower path be your performance bottleneck
<azonenberg_work> if you size the fets right then both paths are about equal
<awygle> sure
noobineer has quit [Ping timeout: 264 seconds]
<azonenberg_work> awygle: also https://i.imgur.com/q1T9ZBG.png
<azonenberg_work> Took me a while but i managed to bang together a test firmware that drives the DAC on the ams101 eval board
<azonenberg_work> then digitizes it with the xadc
<azonenberg_work> and streams to a PC via UDP packets (512 12-bit samples padded to 16 bits each, total 1024 bytes, per packet)
<azonenberg_work> Now to go make a proper viewer app...
<azonenberg_work> This is only 16 Mbps of data so it shouldn't be that big a deal, but it's still more than my wimpy Cairo renderer can handle i think
<azonenberg_work> And it's at least enough that I can make a good test for my OpenGL renderer
<azonenberg_work> Time to dust off all of my GL notes and setup code that i haven't used in years...
<awygle> That's cool
s_frit has quit [Remote host closed the connection]
<awygle> doing a real bad job leaving work at work tonight lol
s_frit has joined ##openfpga
<awygle> finally figured out insane duty cycle, want to make thing work
<awygle> can't till Monday
<awygle> frustrating
Bob_Dole has quit [Read error: Connection reset by peer]
<azonenberg_work> awygle: lol i figured out a way to break out of a sandboxed environment i was in for work just before leaving today
<azonenberg_work> Felt like a good stopping point, i knew if i started exploring the whole thing that afternoon i'd never stop
<azonenberg_work> Aaaand it seems like gtkglextmm no longer exists for gtk3
<azonenberg_work> now to figure out the current state of the art for this...
<awygle> state of the art is vulkan :-P
<awygle> thing is three days late, if I could work on it I would but I need input from colleagues....
<azonenberg_work> awygle: yeah but that doesnt seem to be supported on debian stable
<awygle> Debian stable might as well be the middle ages cmv
<azonenberg_work> It's what i run in production, and any tools i develop have to run there
<azonenberg_work> period
<azonenberg_work> Stretch was released in june 2017 so not too long ago
<awygle> you're un-fun to troll due to your tendency to take me seriously
<azonenberg_work> I know full well it's old :)
<awygle> Debian must support vulkan, just not in gtk. Yes?
<azonenberg_work> Probably
<azonenberg_work> But then again i'm running on a 2015-vintage thinkpad with integrated graphics
<azonenberg_work> that doesnt even support opengl >3
<sorear> petition for "integrated graphics" on laptops to mean "does not have a hard req on an eGPU"
<whitequark> huh?
<whitequark> oh
<whitequark> yeah
<whitequark> azonenberg_work: wtf
<whitequark> my '16 xps13
<whitequark> has nice intel graphics
<awygle> I have "integrated graphics" - a gtx1050
<whitequark> hahaha
<azonenberg_work> whitequark: $ lspci | grep VGA
<azonenberg_work> 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
<whitequark> wtf ancient
<azonenberg_work> $ glxinfo | grep "OpenGL version"
<azonenberg_work> OpenGL version string: 3.0 Mesa 13.0.6
noobineer has joined ##openfpga
<whitequark> oh
<whitequark> >3
<whitequark> i thought that's a smiley
<whitequark> sorry
<azonenberg_work> LOL no
<azonenberg_work> not a scissor either :p
<azonenberg_work> althoguh that would be more >8 i guess?
<azonenberg_work> But yeah, this is what i am developing on until i unpack my desktop gear
<azonenberg_work> So whatever i build has to target this at minimum
<sorear> that's what, HSW?
pie_ has quit [Ping timeout: 246 seconds]
<azonenberg_work> ... oh thats cool, gtk now has a built in gtk rendering widget
<azonenberg_work> that's convenient
<awygle> ... Gtk can render gtk now?
<awygle> good for gtk I guess...
<SolraBizna> $ glxinfo | grep "OpenGL version"
<SolraBizna> OpenGL version string: 2.1 Mesa 18.1.7
<SolraBizna> >_>
<SolraBizna> it would be 3.x but it's missing some single feature that was in core
<azonenberg_work> built in gl*
<azonenberg_work> SolraBizna: what annoys me more is that i have a very nice quadro sitting in the basement in a box
<awygle> yes, gtkglarea
<azonenberg_work> that i cant use :p
<SolraBizna> ouch
<awygle> Gtk4 has a gtkvulkanarea apparently
<azonenberg_work> Because i have nowhere to set up a desktop that isn't a construction site
<azonenberg_work> awygle: yeah and i'm using 3.22
<awygle> but not stable yet
<azonenberg_work> Which just barely has gtkglarea
<sorear> i'm not sure a 68040 macintosh will be an improvement from a haswell thinkpad
<SolraBizna> you just need to accelerate to relativistic speeds
Bob_Dole has joined ##openfpga
iximeow_ is now known as iximeow
rofl_ has joined ##openfpga
jcarpenter2 has quit [Ping timeout: 252 seconds]
lovepon has quit [Ping timeout: 276 seconds]
genii has joined ##openfpga
rohitksingh has joined ##openfpga
noobineer has quit [Ping timeout: 240 seconds]
Bike has quit [Quit: Lost terminal]
noobineer has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
genii has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rqou has quit [Remote host closed the connection]
rqou has joined ##openfpga
ym has joined ##openfpga
s_frit has quit [Ping timeout: 272 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
s_frit has joined ##openfpga
_whitelogger has joined ##openfpga
futarisIRCcloud has joined ##openfpga
rohitksingh has joined ##openfpga
lovepon has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
keesj has quit [Ping timeout: 252 seconds]
<travis-ci> whitequark/Glasgow#109 (master - 7176c85 : whitequark): The build has errored.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
pie_ has joined ##openfpga
rohitksingh has joined ##openfpga
lovepon has quit [Ping timeout: 264 seconds]
vup has quit [Quit: The Lounge - https://thelounge.github.io]
vup has joined ##openfpga
Laksen has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
pie_ has quit [Ping timeout: 244 seconds]
pie_ has joined ##openfpga
Bike has joined ##openfpga
Miyu has joined ##openfpga
_whitelogger has joined ##openfpga
carl0s has joined ##openfpga
Hamilton has joined ##openfpga
pie_ has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
pie_ has joined ##openfpga
Hamilton has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh1 has joined ##openfpga
rohitksingh1 has quit [Client Quit]
rohitksingh1 has joined ##openfpga
rohitksingh1 has quit [Client Quit]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh1 has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
rohitksingh has joined ##openfpga
rohitksingh1 has quit [Quit: Leaving.]
Bob_Dole has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
noobineer has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
Laksen has quit [Quit: Leaving]
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
Bob_Dole has joined ##openfpga
rohitksingh has quit [Ping timeout: 252 seconds]
<mithro> Just for everyone's information, we are trying to move a lot of the SymbiFlow discussion into the #symbiflow IRC channel -- it will be only for on topic discussion however
rohitksingh has joined ##openfpga
<mithro> Anyone want to give me hints on what is the smallest possible config of the parameters for Clifford's picorv32 on the ice40up5k? (https://github.com/cliffordwolf/picorv32/blob/master/picorv32.v#L57-L83)
<tnt> mithro: looking at the doc ... seems you set everything to 0 for min size.
<tnt> mithro: I'm curious what size and fmax you get ...
<daveshah> However, beware that some of them make it longer rv32i
<daveshah> Disabling ENABLE_REGS_16_31 makes it closer to rv32e
<sorear> that should have ~no effect on ice40up5k
<sorear> since the BRAMs are 256 deep
<sorear> going to rv32e only helps if you don't have BRAMs
rohitksingh has quit [Ping timeout: 245 seconds]
<mithro> So, looks like p_ENABLE_REGS_16_31=0 increases the ICESTORM_LC usage from 3967 -> 3988!?
<cr1901_modern> mithro: Accessing x16-x31 in rv32e is supposed to fault. picorv32 doesn't impl this, but I imagine there's a separate check in the reg fields of the opcodes, so that picorv32 knows to ignore insns using x16-x31
<sorear> mithro: you do need a few more LCs to latch rs1[4], rs2[4], and rd[4]
<sorear> oh, the other way around
<mithro> Any idea why p_CATCH_ILLINSN=0 would *increase* the resource usage?
<sorear> it shouldn't
<sorear> at this point I suspect that your control inputs are being inverted or otherwise misinterpreted
<sorear> is it possible to confirm in simulation that you've actually built a core that hangs on illegal instructions?
<mithro> sorear: Possibly
<daveshah> Also check how many LUTs/FFs Yosys is synthesising
<daveshah> Look at the end of synthesis
<daveshah> It could be that LC usage increases because LUTs and FFs don't pack so well, even if there are fewer cells in total
<mithro> Smallest config of our SoC seems to be Info: ICESTORM_LC: 3872/ 5280 73%
<sorear> 3872 is rather silly
<daveshah> How much of that is from the SoC though?
<tnt> mithro: fmax ?
<mithro> tnt: Faster than whatever our clock is...
<daveshah> picorv32 itself seems to be about 1755 LCs in a small config, based on the wrapper design we used for nextpnr benchmarks early on
<sorear> roughly how much features does the soc have
<mithro> sorear: Not a huge amount...
lovepon has joined ##openfpga
<mithro> I may have been a little to aggressive....
<mithro> Info: ICESTORM_LC: 1/ 5280 0%
<mithro> Looks like it might be the UART...
<daveshah> mithro: for the record. picorv32 in a small config, UART, QSPI flash and a CSI-2 receiver with downsampler and GPIO is just 3474 LCs
<daveshah> So something in your design is eating LCs
<mithro> It looks like it might be the FIFO buffers in the UART...
<daveshah> That would make sense, if they don't map well to ice40 BRAMs
carl0s has quit [Quit: Page closed]
<mithro> Info: ICESTORM_LC: 3604/ 5280 68% - Before Info: ICESTORM_LC: 3090/ 5280 58% - After
<mithro> So it looks like 514 ICESTORM_LCs are being used to implement the FIFO for the uart
<daveshah> Seems like a minimal SoC with picorv32, UART and flash is 2633 LCs for me
<mithro> daveshah: flash == XIP flash?
<daveshah> Yeah
<daveshah> 2527LCs with the catches and two stage shift disabled
<mithro> Yeah, that sounds much closer to what I would expect
<mithro> daveshah: How does one check that the following verilog code is getting converted to block ram? https://github.com/enjoy-digital/litex/issues/117#issuecomment-433658810
<daveshah> mithro: You can either grep the Yosys output for the memory name (should be storage/storage_1) in this case
<daveshah> Or just build a test case
<daveshah> Here it appears to have an async read port "rdport" which will be ruining things
* mithro goes to add stuff to cr1901_modern Todo list :-P
<mithro> daveshah: aren't async read ports pretty common for memory?
<daveshah> mithro: yes, they are
<daveshah> However they are never supported by BRAM
<daveshah> Most FPGAs have distributed RAM that does support them
<daveshah> And is also good for smaller memories like this
<daveshah> Sadly the ice40 doesn't have dist RAM
<cr1901_modern> Interesting...
<cr1901_modern> well I knew all this :P
<cr1901_modern> I meant interesting there was an async RAM in liteX
<daveshah> Coincidentally, fixed a bug in Yosys last week handling memories with one async and one sync read port
<daveshah> This was for the openrisc demo on ECP5
<cr1901_modern> did it accidentally infer a BRAM when it shouldn't?
<sorear> tangentially, am excite about DDR3 in prjtrellis
<daveshah> cr1901_modern: it actually threw away one of the ports after correctly inferring two distributed RAMs
<cr1901_modern> Oh I don't see how that would be disasterous. Nope, not at all
<daveshah> Because it added a register on the second port with a clock of 1'bX, which was then thrown away
<daveshah> Fun to debug the fact the TLB was thus broken
<cr1901_modern> debug + TLB == not fun
<daveshah> Seems to be used with fwft
<mithro> EBR contents are preserved (write protected) during configuration, assuming that voltage supplies are maintained
<mithro> throughout. Consequently, data can be passed between multiple iCE40 configurations by leaving it in an EBR block and then skipping pre-loading during the subsequent reconfiguration.
<sorear> what exactly is the ice40 bram reset glitch?
<sorear> i know there's a thing where they're unusable for a certain length of time after global reset
<daveshah> mithro: Beware that from my understanding of the hardware that would *not* apply to the SPRAM, only the real BRAM
<daveshah> sorear: I think they are usable but not initialised for a few us after the fpga boots
<mithro> Any idea what fwft acronym might stand for?
<daveshah> mithro: first word fall through
<daveshah> Common feature of FIFOs
<cr1901_modern> mithro: Perhaps the best thing to do is add a "buffered_uart=False" arg to the BaseSoC constructor
<cr1901_modern> and just eat the one cycle cost
<cr1901_modern> what does first word fall through mean?
<daveshah> The first word written to an otherwise empty FIFO will be put on the output without doing a read first
<cr1901_modern> How does that help you?
<daveshah> It's not something I've ever needed to actually use
<sorear> it saves a cycle or two of latency if you need to use a decoupling fifo somewere like a CPU fetch queue
<daveshah> Yes, this is true
<cr1901_modern> I feel like I'm not visualizing this correctly
<daveshah> Should probably be able to implement one without going for an async read port by having some explicit bypass logic
<cr1901_modern> Guess I'll do some research after I rest
<daveshah> I guess migen assumed it would always end up in distributed RAM because it was too small for BRAM anyway
<daveshah> Forgetting about the ice40
<cr1901_modern> daveshah: Migen, for a very long time was Xilinx-oriented
<cr1901_modern> nowadays ice40 backend has some parity w/ Xilinx
<cr1901_modern> SO yes, I totally believe that
<cr1901_modern> The reason navre doesn't fit into ice40hx1k (small AVR core) is because it uses dist RAM instead of BRAM
<daveshah> Plenty of cores in general don't map well to the ice40 without distributed RAM
<daveshah> I think Dan had some problems with the ZipCPU too
* ZipCPU reads backlog
<daveshah> We are discussing the lack of distributed RAM in the ice40 and how that causes the FIFO in migen to map poorly when first word fall through is enabled
<ZipCPU> Ahh ...
<ZipCPU> Yes, I had an unexpected hiccup porting the ZipCPU to the iCE40. The register file wasn't registered on read, and the iCE40 block RAM's don't allow this
<mithro> I have a strange feeling of deja vu with this pull request...
<mithro> cr1901_modern: ping?
inode has joined ##openfpga
<mithro> daveshah / ZipCPU: Appreciate your feedback on https://github.com/cliffordwolf/picorv32/issues/99 ?
* ZipCPU takes a look
<ZipCPU> I've heard several discussions regarding how to handle this
<ZipCPU> Last I heard, between daveshah and clifford the two knew how to handle it, it was just a matter of time, energy, and priority
<ZipCPU> I could be wrong, but that's what I remember from that last conversation
<sorear> i wonder if the techmap works for smaller multiplies
<ZipCPU> Part of the issue has been all of the various ways multiplication units can be configured.
<ZipCPU> The abundance of potential configurations has ... slowed down the development of this capability
<sorear> since that's a 33x33 multiply and the up5k only has 16x16 multipliers
<sorear> the UP5k has 8 16-bit multipliers, so you could break down the 32-bit multiply that way
<sorear> (although it'd make more sense for the core to spread out the multiply over 4 cycles)
sgstair has quit [Remote host closed the connection]
sgstair has joined ##openfpga