clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
seldridge has joined #yosys
promach_ has quit [Quit: WeeChat 2.1]
knielsen has quit [Read error: Connection reset by peer]
knielsen has joined #yosys
emeb has quit [Quit: Leaving.]
quigonjinn has quit [Ping timeout: 248 seconds]
emeb_mac has joined #yosys
dxld has quit [Quit: Bye]
dxld has joined #yosys
m_w has quit [Quit: Leaving]
dxld has quit [Quit: Bye]
dxld has joined #yosys
seldridge has quit [Ping timeout: 240 seconds]
<daveshah> mithro: yeah, they are much better
promach has quit [Quit: WeeChat 2.1-dev]
promach has joined #yosys
dys has joined #yosys
xerpi has joined #yosys
xerpi has quit [Remote host closed the connection]
xerpi has joined #yosys
emeb_mac has quit [Ping timeout: 248 seconds]
xerpi has quit [Remote host closed the connection]
xerpi has joined #yosys
dys has quit [Ping timeout: 260 seconds]
<keesj> my presentation was .. alright. I hope I did not tell to many fairy tales. I can not look into more details into those LUT4 thingies and ice040
<keesj> (also I have a few tinyFPGA boards comming my way, next to the icestick and .. the beaglebone capes)
<keesj> I need to chose to either port my can controller to verilog/ice40 e.g. https://keesj.github.io/can-hdl/ or do home automation (emulating 433.92 Mhz remote and controlling my beamer using IR)
<tpb> Title: Can HDL documentation Can HDL documentation (at keesj.github.io)
<keesj> but if I understand correctly the ghdlsynth-beta might allow me to compile vhdl code on ice040 https://github.com/tgingold/ghdlsynth-beta
<tpb> Title: GitHub - tgingold/ghdlsynth-beta: VHDL synthesis (based on ghdl) (at github.com)
<keesj> Is anybody interested in VHDL in here?
<daveshah> keesj: ghdlsynth is very experimental
<daveshah> No, I think most people here are Verilog people
<keesj> Thanks. I will try to focus more on the second project. it is probably a little to simple to learn about verilog but will be cool for better understanding yosys
promach has quit [Quit: WeeChat 2.1-dev]
jwhitmore has joined #yosys
Kokjo has joined #yosys
<Kokjo> Would it be possible to implement a fpga inside another fpga. I do understand the it would not be efficient, but how would i do it and can it be done? what it the simplest way to do this?
<daveshah> Kokjo: sure
<daveshah> I think there are even some projects like that
<daveshah> can't remember any names, but I know I've seen them before
<Kokjo> daveshah: can you point me in the right direction, googling "fpga in fpga" leads nowhere...
<daveshah> Kokjo: this is for coarsegrained interconnect
<tpb> Title: InterSynth - Example-Driven Interconnect Synthesis (at www.clifford.at)
<keesj> it it possibly also possible to run a simluator on a soft core
<Kokjo> daveshah: you are the one reverseing the ECP5 fpga, right?
<daveshah> Kokjo: s/reversing/documenting
<daveshah> be careful
<daveshah> Edmund will tell us off otherwise
<Kokjo> im not sure i understand the difference...
<daveshah> one word has negative/illegal connotations, the other one doesn't
<cr1901_modern> Someone must've gotten a stern warning for this in practice. E.g. the terms "reversing/HX4K" used to be casually discussed.
<cr1901_modern> (on Twitter anyway)
<Kokjo> daveshah: oh, i see. I did not know that, maybe i have been playing too much ctf, reverse engineering to has a very neutral connotations to me. reverse engineering to me is just the process of obtaining enough knowlegde about the internals of something to make it do funny things.
<daveshah> I don't think we were told off by anyone in the FPGA companies.
<daveshah> It's more a general approach of attempting to work more with them more I suppose
jwhitmore has quit [Ping timeout: 240 seconds]
xerpi has quit [Quit: Leaving]
jwhitmore has joined #yosys
jwhitmore has quit [Ping timeout: 244 seconds]
promach has joined #yosys
m_t has joined #yosys
jwhitmore has joined #yosys
<cr1901_modern> What does "always @(negedge 1'hx) begin" mean in verilog (yosys generates it sometimes while I experiment)?
<daveshah> cr1901_modern: do you have a nice example where it is generated?
<daveshah> it seems like it would come from a flip-flop without a clock
jwhitmore has quit [Ping timeout: 260 seconds]
<cr1901_modern> Run yosys on this file: https://hastebin.com/yemomedoko.nginx >>
<cr1901_modern> with this script: https://hastebin.com/lonilutuqo.rb (up until/not including extra)
<cr1901_modern> I.e. yosys -qp 'script bram-man.ys :extra' -l bram_man.yrp
<cr1901_modern> The output file bram-man-noinf will have it
<cr1901_modern> I'm trying to force yosys to use LUTs for RAM to experiment w/ something
<daveshah> cr1901_modern: what Yosys version are you on? not seeing it locally
<cr1901_modern> Actually I lied, that was the wrong script
<cr1901_modern> https://hastebin.com/eqexagakaq.rb Try this one
<daveshah> thanks, looking into it now
<daveshah> cr1901_modern: looking at the RTLIL it seems that the memory still uses read and write port cells internally, which Yosys doesn't dump to Verilog very nicely
<daveshah> I don't think write_verilog is really supported without a `memory` pass first
<cr1901_modern> There is a "memory" pass (minus "memory_dff"). I just did it manually.
<cr1901_modern> But whatever, this is par for the course any time I need to black box test yosys. I modify one thing, and yosys generates stuff I don't expect
<cr1901_modern> meaning I'll have to spend time reading thousands of lines of C++ just to understand what's going on, decide it's not worth it, and it forever remains a mystery
<daveshah> I think it is memory_dff that you need, that merges the write flipflop into the write port
<cr1901_modern> But that's what I deliberately removed to see if yosys would fallback to LUT RAM!
X-Scale has quit [Ping timeout: 244 seconds]
<cr1901_modern> I didn't expect that removing the memory_dff pass would make it so yosys couldn't properly utilize LUTs
[X-Scale] has joined #yosys
[X-Scale] is now known as X-Scale
<cr1901_modern> https://github.com/YosysHQ/yosys/blob/master/techlibs/common/simlib.v#L28-L30 I like how when I run memory_collect on this toy design, $mem cells are _not_ generated
<tpb> Title: yosys/simlib.v at master · YosysHQ/yosys · GitHub (at github.com)
<daveshah> cr1901_modern: memory_dff and memory_collect works for me
<daveshah> afail memory_dff is pretty much required
<daveshah> *afaik
<cr1901_modern> memory_collect doesn't generate a $mem cell for me even when memory_dff is enabled
<cr1901_modern> and even though the code path to generate a $mem cell is travered
<cr1901_modern> bleh, I'm going back to bed
pie_ has joined #yosys
maartenBE has quit [Ping timeout: 276 seconds]
maartenBE has joined #yosys
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern has joined #yosys
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #yosys
quigonjinn has joined #yosys
seldridge has joined #yosys
promach_ has joined #yosys
sandeepkr has joined #yosys
<tinyfpga> cr1901_modern: ICE40 cannot use LUTs as RAM, only ROM
<daveshah> tinyfpga: hi! just got the 85k board from Edmund, thanks
<daveshah> Good encouragement to fix the current performance issue in my Trellis to PnR database importer
<tinyfpga> daveshah: ill upload the kicad layout today so you can find the JTAG, SPI ports and know how the pins are mapped
<daveshah> tinyfpga: Awesome, that would be great
promach_ has quit [Ping timeout: 260 seconds]
m_t has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
pie_ has quit [Ping timeout: 256 seconds]
digshadow has joined #yosys
pie_ has joined #yosys
digshadow has quit [Ping timeout: 240 seconds]
xdeller_ has quit [Ping timeout: 268 seconds]
digshadow has joined #yosys
jwhitmore has joined #yosys
<mithro> daveshah: I was going to complain to you about that :-P
<mithro> daveshah: (The speed of the Treills database importer :-)
<daveshah> mithro: i will port it to c++ from that crappy snek thing
<daveshah> that fixed the routing graph builder, should fix the database deduplicator too
<mithro> daveshah: Actually, I think it was the compiling side of things that was taking a long time? I didn't have a lot of time to investigate before I had to run and catch a train
<daveshah> mithro: that shouldn't be more than 20-30 secs max and could easily be fixed. It takes 6-8 minutes to build the data first
<daveshah> which is also the snek bit
<tpb> Title: ecp5: Adding Verilog sim models by daveshah1 · Pull Request #186 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mithro> Dunno, it's not like I can complain - the ice40 rr_graph generator is *super slow* because of all the debugging prints and stuff
<daveshah> mithro: to be fair, even 10 minutes is nothing compared to downloading and installing Vivado or Diamond particularly if you have the internet connection of a mere mortal
<daveshah> not that we can't be better
pie_ has quit [Ping timeout: 260 seconds]
<daveshah> I might even get to solving those problems this weekend, now I have more motivation to do so
<mithro> daveshah: Even if you have Google's connectivity - downloading Vivado takes more then 10+ minutes
<daveshah> mithro: from memory when I was downloading it on uni's ridicuously fat pipe over the summer holidays I was definitely being limited to 1-2MB/s by Xilinx's side anyway
<mithro> IIRC digshadow managed to download and get blinky working on an ice40 device (having never used icestorm before) while waiting for Vivado to download...
<digshadow> ha yeah
<daveshah> I'm not surprised. On a slow day you could probably get an end to end flow working from scratch in that time period
* TD-Linux is slightly miffed that the ice40 doesn't have any 5v tolerant ios
<cr1901_modern> tinyfpga: Just in case; I don't mean distributed RAM in this case
<mithro> TD-Linux: What uses 5V's these days? :-P
<daveshah> my guess is it's something not from these days
<mithro> daveshah: Really interesting to see your work to add the ECP5 to Yosys
<daveshah> mithro: There is one annoyance that still needs work
luismarques has quit [Quit: luismarques]
<daveshah> The ECP5 has a FF style that is very unusual, and not following the usual silicon style. Basically synchronous set/reset has priority over clock enable - so clock enable isn't really a clock enable but just a data enable. Yosys can't extract these as it stands, so that will be a small custom pass
<mithro> daveshah: Interesting, I was looking at that recently myself
<daveshah> mithro: After discussion with Clifford we agreed just to use TRELLIS_FF for now and leave the Lattice primitives for another time
<mithro> daveshah: That actually sounds exactly how I would suggest you do it
<daveshah> Lattice have a lot of FF primitives that are quite annoying to deal with, like FFs with a mux in front because one of their ancient architectures looked like that
<daveshah> For RAM I may do the same, or support both. The Lattice primitives take a C-style hex number in a string rather than a Verilog numeric parameter for initialisation
<daveshah> You'll see the conversion function I had to write in the DPR16X4C sim model (I wanted a Lattice-compatible DPRAM as an option, because some people manually instantiate RAM)
<daveshah> somehow doing ASCII string processing in Verilog feels off
pie_ has joined #yosys
<TD-Linux> mithro, nothing, I'm trying to interface to 1992 hardware :^)
X-Scale has quit [Ping timeout: 240 seconds]
[X-Scale] has joined #yosys
xdeller has joined #yosys
<mithro> daveshah: WTF :-P
<daveshah> mithro: that's Lattice for you
<daveshah> Layers upon layers of legacy that no one understands any more
<daveshah> Oh wait that's almost any company
<qu1j0t3> ^
<daveshah> I'm not sure how much the core of Diamond has really changed since AT&T bought their NeoCAD license in '95 tbh
<daveshah> That then was sold with the ORCA FPGAs to Lucent, then Agere who were finally sold to Lattice
<daveshah> Many of the primitives seem to originate from the ORCA days
<daveshah> Why am I now spending Friday night reading PDF manuals of FPGA flows from before I was born? What is wrong with me :P
<mithro> daveshah: sounds about right
<daveshah> mithro: it's where the weird FF primitives came from. Letters were expensive back them
<daveshah> *then
<daveshah> :P
<mithro> daveshah: You say that - but one of the reason why unix commands are like 2 letters (like ls, cp, mv) is because typing on early terminals actually had very slow mechanical interlocks to prevent you pressing keys at the same time and causing shorts
<daveshah> mithro: hehe
<daveshah> I suspect the real reason is they were avoiding parameters for some reason, so they needed loads of different primitives
<daveshah> And then they built on that with every new architecure over the last 25 years
<daveshah> Tbh, I'm both impressed as to how advanced things were back then and depressed as to how little has changed, compared to the silicon itseld
<daveshah> Wow
<tpb> Title: FPGA synthesis goes online - Electronic Products (at www.electronicproducts.com)
<daveshah> Cloud synthesis in 2000
<daveshah> Costing 15-60$ per run
<sorear> now the question is what is that per hour at the speed of the tools in 2000 :p
<daveshah> The biggest ORCA 3 part was about 6000 LUTs, which Yosys/arachne can do in maybe a minute or two max
<daveshah> arachne's algorithms probably aren't much better than 2000 era, but might trade speed for QoR
<daveshah> I can't imagine it would be more than an hour
<mithro> daveshah: You might underestimate how much faster computers have gotten since the 2000s :-P
<daveshah> mithro: I'm going to assume it would be running on reasonably high end machines back then
<daveshah> It's hard to have a reference point because none of my uses of computers back then where really performance related
<daveshah> My Pentium III laptop certainly felt fast enough back then
<mithro> daveshah: 2000 was like ~Pentium 2 generation
<mithro> 400Mhz P2 -- 64mb sdram running at 100 mhz
<mithro> My 8088 felt pretty fast for a long time too -- definitely compared to my human abilities ;-)
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined #yosys
<sorear> [yall have seen dan luu's input latency post?]
<qu1j0t3> yes.... we have.....
<cr1901_modern> Err, mithro, how old are you again :P?
<mithro> Good question - Born 1983
<cr1901_modern> I mean, I have an 8088 (a few) but I certainly didn't buy it when it was new.
<cr1901_modern> Ahh
<cr1901_modern> I thought you were closer to my age (1990)
<cr1901_modern> Also, tbf, I didn't learn how to program/_really_ play w/ computers until I was 18-20
<mithro> 8088 was my first computer and it was second hand from what at the time was our monopoly telco
<sorear> qu1j0t3: i'd be surprised if you hadn't, but still remiss not to ask
<qu1j0t3> :)
<qu1j0t3> we're still a bit confused by what he was measuring and unsure if anyone has reproduced the results.
<qu1j0t3> anyone who's used transcontinental ssh knows that 200ms latencies are all but unusable
<sorear> do you mean intercontinental
<qu1j0t3> yes, inter-
<qu1j0t3> sorry
* mithro laughs at your 200ms -- Australia FTW!
<qu1j0t3> who has time to duplicate his test rig? i suspect he has more free time than i do, so my rebuttal will probably never be written :D
<awygle> maybe it's actually 400 ms latencies that are all but unusable
<awygle> and half comes from network and half from *other*
<qu1j0t3> no, 200ms is awful
<mithro> actually - latency isn't a huge problem - jitter is much worse
<qu1j0t3> latency is a problem.
<qu1j0t3> for me, anyway.
<TD-Linux> dan luu's post takes key travel into account
<qu1j0t3> i know.
<qu1j0t3> which seems pretty bizarre
<mithro> Humans will adapt to a fixed length latency pretty easily
<qu1j0t3> aren't we all typing on silly chiclet things nowadays? I mean, i'm not right now, i prefer proper keyboards
<qu1j0t3> mithro: I don't want to adapt to 200ms. Really. And I don't think you would either.
emeb has joined #yosys
<qu1j0t3> and i also don't believe we have, so luu's stuff smells funny.
<TD-Linux> no, I'm typing on a real keyboard. I imagine many are, the "mechanical" keyboards have even become popular with gamers
<awygle> i'm typing on a rubber dome keyboard :(
<mithro> qu1j0t3: Until they improve the speed of light, Australia -> US or Europe latency is always going to suck :-(
<awygle> i actually _like_ chiclets but i don't even have one
<qu1j0t3> i mean eventually arguments over Luu's piece may drive me to do my own measurements.
<qu1j0t3> mithro: I'm aware from first hand experience :D
<awygle> at least at work
<mithro> qu1j0t3: Your a fellow Australian expat?
<qu1j0t3> awygle: I have a 2012 MBP here with chiclets, i get used to it. I guess the Retina screen takes my mind off the keyboard.
<qu1j0t3> mithro: Yes, actually :)
<mithro> qu1j0t3: Ha, didn't know that
<awygle> qu1j0t3: i have, like, _really_ bad RSI issues so the low travel and light touch of chiclets help me enormously
<TD-Linux> also a lot of the views of old computer latency seem to have rose tinted glasses. For the early 90's machines I have, I get to watch it recompute palette all the time
<qu1j0t3> mithro: (I assume you checked my hostmask, which is no longer indicative of my actual location)
<qu1j0t3> awygle: *nod*
<awygle> (this is also why i tweeted that thing about hating using shift)
<TD-Linux> and the apple II can't accept keyboard input while accessing the disk, like scrolling through a document
<awygle> i certainly don't miss the computer going all "you just won solitaire" anytime i tried to do anything taxing
<qu1j0t3> TD-Linux: haha, i am pretty sure the BBC Micro doesn't have that problem
<qu1j0t3> TD-Linux: i don't recall any latency issues with machines i used in the 80s and 90s
<qu1j0t3> TD-Linux: or indeed the ones i use today *shrug*
AlexDaniel has quit [Read error: Connection reset by peer]
AlexDaniel has joined #yosys
<TD-Linux> qu1j0t3, yeah, well it has a real disk controller. the apple II has woz magic
<qu1j0t3> heheh
<TD-Linux> also the apple II has no interrupts at all.
<qu1j0t3> the II was a bit dated by the time the Beeb came out.
<sorear> they don't need to improve the speed of light, just run gas/vacuum waveguides in a trench through the mantle
<qu1j0t3> tell Musk, it might keep him out of trouble
<awygle> na musk is a 10xer and that's only 3x
<qu1j0t3> lol
<qu1j0t3> i think at 5x they should get a truman show dome
<qu1j0t3> for the safety of the rest of us
emeb has quit [Ping timeout: 256 seconds]
seldridge has quit [Ping timeout: 240 seconds]
emeb has joined #yosys
digshadow has quit [Ping timeout: 240 seconds]
digshadow has joined #yosys
seldridge has joined #yosys
dxld has quit [Quit: Bye]
dxld has joined #yosys
seldridge has quit [Ping timeout: 240 seconds]
promach_ has joined #yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys