clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
ZipCPU|Laptop has joined #yosys
gnufan1 has joined #yosys
gnufan has quit [Ping timeout: 256 seconds]
vinny has joined #yosys
AlexDaniel has quit [Ping timeout: 240 seconds]
phire has quit [Remote host closed the connection]
phire has joined #yosys
phire has quit [Remote host closed the connection]
phiren has joined #yosys
pie_ has quit [Ping timeout: 248 seconds]
sklv has quit [Ping timeout: 255 seconds]
sklv has joined #yosys
gnufan1 has quit [Ping timeout: 240 seconds]
gnufan has joined #yosys
ovf has quit [Disconnected by services]
sorear_ has joined #yosys
pointfree_ has joined #yosys
thoughtpolice_ has joined #yosys
ovf has joined #yosys
sorear has quit [Disconnected by services]
sorear_ is now known as sorear
shapr_ has joined #yosys
forrestv has quit [*.net *.split]
jayaura has quit [*.net *.split]
thoughtpolice has quit [*.net *.split]
andi- has quit [*.net *.split]
pointfree has quit [*.net *.split]
shapr has quit [*.net *.split]
thoughtpolice_ is now known as thoughtpolice
pointfree_ is now known as pointfree
forrestv has joined #yosys
Guest85812 has joined #yosys
andi- has joined #yosys
nrossi has joined #yosys
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined #yosys
gnufan has quit [Ping timeout: 256 seconds]
vinny has quit [Quit: Page closed]
gnufan has joined #yosys
gnufan has quit [Ping timeout: 256 seconds]
gnufan has joined #yosys
gnufan has quit [Ping timeout: 264 seconds]
gnufan has joined #yosys
dys has quit [Ping timeout: 248 seconds]
sklv has quit [Remote host closed the connection]
sklv has joined #yosys
gnufan has quit [Ping timeout: 248 seconds]
gnufan has joined #yosys
dys has joined #yosys
AlexDaniel has joined #yosys
eduardo_ has joined #yosys
eduardo__ has quit [Ping timeout: 252 seconds]
Guest85812 is now known as jayaura
sklv has quit [Ping timeout: 255 seconds]
sklv has joined #yosys
m_t has joined #yosys
gnufan1 has joined #yosys
gnufan has quit [Ping timeout: 268 seconds]
sklv has quit [Remote host closed the connection]
sklv has joined #yosys
sklv has quit [Remote host closed the connection]
sklv has joined #yosys
sklv has quit [Remote host closed the connection]
sklv has joined #yosys
sklv has quit [Remote host closed the connection]
sklv has joined #yosys
pie_ has joined #yosys
m_t has quit [Quit: Leaving]
ZipCPU|Laptop has quit [Ping timeout: 264 seconds]
maikmerten has joined #yosys
<maikmerten> hi there, as I progress in my Verilog CPU design, some questions arised. The first one would be if it is usually okay in FPGAs to generate clock signals via binary counters. For instance, the icoboard has a 100 MHz clock, my design goes only up to 56 MHz, so 50 MHz should be fine and 25 MHz could give a somewhat usuable VGA pixel clock. The fine-grained control of a PLL shouldn't be needed there, but perhaps one sho
<maikmerten> uld use on nonetheless if, e.g., the FPGA has its own clock network?
<maikmerten> The second question would be regarding `include statements. My CPU usually follows a "one file per module" file organization, so the cpu toplevel includes the necessary module files. However, it appears the paths there are workdir relative, not file relative, which I find somewhat undesirable.
<maikmerten> iverilog has an option to include the current file dir, but I wonder how yosys behaves and if there are best practices to follow
<jimn> maikmerten: I would use the PLL.
<maikmerten> jimn, okay, thanks for your opinion. The PLL certainly should be the safe option.
<jimn> maikmeerten: And the easiest too since the clock network is already built into the FPGA
Sourcerer has joined #yosys
<maikmerten> yeah. too bad that that there is no such thing as "PLL inference" (I like to avoid vendor-specific things, for instance via BRAM inference), but then again sooner or later you'll have to have a board/vendor-specific toplevel at one point
Sourcerer has quit [Ping timeout: 260 seconds]
<jimn> maikmerten: If you want to get the optimization you have to the vendor-specific things.
gnufan1 has quit [Ping timeout: 240 seconds]
<maikmerten> jimn, yup, that's certainly true
gnufan has joined #yosys
<thoughtpolice> maikmerten: On the iCE40, IIRC, you can get manual access to the low-skew clock network by driving PLLOUTGLOBAL from the configured PLL to a global buffer (SB_GB), which drives some dedicated clock network lines. PLLOUTGLOBAL is almost directly connected to a corresponding gbuf
<thoughtpolice> maikmerten: I wrote a bunch of this down with some links if you want to read about the iCE40, see the top-part which has a bunch of links, and ctrl+f "Global Buffers" too https://github.com/thoughtpolice/clash-playground/blob/master/src/Lattice.hs
<maikmerten> thoughtpolice, thanks!
<thoughtpolice> The iCE40 architecture links are probably the most relevant/important
ravenexp has quit [Ping timeout: 240 seconds]
ravenexp has joined #yosys
digshadow1 has quit [Quit: Leaving.]
digshadow has joined #yosys
<jimn> thoughtpolice: that's haskell?
<thoughtpolice> jimn: Yes. Technically the compiler/language is called "Clash" in this case (it has a few minor semantic differences, and its own standard library of things for circuits vs Haskell), but for all practical purposes it is Haskell and uses the same tools. The compiler actually does produce Verilog/VHDL from that code. If you've ever heard of Chisel or MyHDL, it's kind of like that, just for Haskell.
<jimn> Oh yes. How does the QOR compare to something written in Verilog/VHDL?
<sorear> hmm, somehow I got the idea that clash was a high-level-synthesis tool and not a DSL
<thoughtpolice> sorear: That's why I said "kind of" but I didn't want to touch that much on the tooling details
<thoughtpolice> You are right, and it is more like Verilog than Chisel in the sense it's not a DSL, but it's not really high-level synthesis, either.
<thoughtpolice> Clash is structural and not behavioral in any real way, but the abstraction powers are good enough to make it tolerable.
<jimn> thoughtpolice: How would you compare writing in Verilog/VHDL versus Haskell?
<thoughtpolice> You're always managing your own registers/flip flops to a very real extent, so you can pipeline and control things pretty carefully, and build things on top of that. Not being a DSL means you can use all the ordinary extensions and stuff like that, so it's much more convenient than most DSLs in a lot of ways.
<thoughtpolice> jimn: Well, I know Haskell, uhh, quite well. So it was a very obvious choice for me, at least. But I am using it for fairly big designs at work now -- one thing is that it's generally much more concise which I like. Verilog/VHDL somehow have you write tons of textual code, but the abstraction capabilities are fairly poor. Structural design gives you pretty low-level control, but concision and good abstraction tools really
<thoughtpolice> help smooth it out.
<jimn> thoughtpolice: How does the QOR compare between wring something in Haskell vs. Verilog/VHDL?
m_t has joined #yosys
<jimn> s/wring/writing/
<jimn> thoughtpolice: are the 'big designs' written exclusively in Haskell or a combination of Haskell and Verilog/VHDL?
<thoughtpolice> jimn: You mean in terms of performance, area, etc? Well, *I'm* at least far more effective at writing it than any alternative. :) In general there are some things that are still too hard to do that would make it difficult for other people... In terms of controlling area/time/latency trade offs, all of that is pretty doable with some work. A big problem is there aren't a lot of building blocks yet.
<jimn> thoughtpolice: 'big problem' == you're writing almost everything from scratch and are unable to reuse blocks that were previously written?
<thoughtpolice> jimn: Entirely in Haskell, with some VHDL to bind out to IP from the vendors. I'd say it's like 95%+ Haskell. There are parts written by hand and parts generated by other tools -- large design being few 100K LUTs, 70%+ device resource utilization on something like an Arria 10.
<jimn> thoughtpolice: Is the ultimate target an FPGA or an ASIC?
<thoughtpolice> jimn: Just publicly available stuff that you often don't want to rewrite... There are only so many users. Reuse is fine, just like -- oh I want a wishbone interface, gotta pony up and write that right fast. Various IP bindings, simple protocols (i2c masters, etc). There just isn't a lot of public code right now, and building it all takes time in any case.
<thoughtpolice> jimn: FPGAs
<jimn> thoughtpolice: If you can say, what is the purpose of what you are building?
<thoughtpolice> The overall return is fine it's just I already have a job and stuff, and writing all that again is a pain, etc.
<thoughtpolice> jimn: Currently, accelerator-style designs for machine learning workloads, stuff like that. I'll remain vague beyond that :)
<thoughtpolice> (Not that you couldn't find out, I just don't often get into that stuff, is all.)
<jimn> thoughtpolice: Understood. Don't want you to loose your work!
<jimn> thoughtpolice: I'm definitely going to have to give Clash a test spin on something.
<thoughtpolice> It's unfortunately a bit rougher than it should be... Haskell experience helps a lot. The hardest thing right now, really, is getting the most fundamental APIs designed right of course, but it's hard to have something that's tolerable/usable for both an experienced designer and semantically appealing for new users, at the same time.
<thoughtpolice> But you really want a shared base to build on. There are some various ideas floating around we have, but I think right now it's much more "experienced user" oriented than beginner oriented, in a sense.
<jimn> thoughtpolice: I think that's true for any HDL situation.
<jimn> thoughtpolice: I've used Haskell in the crypto space, so I just need to get my head around the hardware implications, but seeing the generated Verilog will expedite that process.
<jimn> thoughtpolice: From the code fragment you shared, it's alot more readable then most Verilog I've seen
<thoughtpolice> If you've ever done FRP it feels a lot like like that -- you program in a time-independent Applicative manner, in a sense. If you've ever written raw, structural Verilog you'll get a feel for it pretty quick, too, it just is far more concise.
<thoughtpolice> (e.g. an entire structural module instantiation in Verilog is "just" function application in Clash, so you can think of Clash as sort of like, a really good structural hardware language -- or of Verilog as a really bad functional hardware language, in a sense)
<jimn> thoughtpolice: I've got three tapeouts under my belt doing ASICs
nrossi has quit [Quit: Connection closed for inactivity]
<thoughtpolice> :) I think there's a lot to like about it, but there's certainly a lot missing still, so you might enjoy it! I'm still relatively new to digital design, but using Clash/Haskell helped a lot -- I probably would not have tolerated raw Verilog for very long.
<thoughtpolice> (Now it's more tolerable of course, with a bit more experience)
<jimn> thoughtpolice: Verilog is about as dangerous as C can be!
<jimn> thoughtpolice: And the various simulators/synthesizers don't help matters.
<thoughtpolice> Yeah, we have a SystemVerilog backend and it's constantly busted, part of it is having no available simulators. :( These days I normally use the 'prep' pass in Yosys to try and simplify all my Verilog from Clash, before giving it to another tool.
<sorear> verilog is like C back when lint(1) was a separate program from an entirely different company
<thoughtpolice> Since we've also hit various issues even in Icarus/Verilator before (although to be fair, I think those are all fixed up now.)
<jimn> thoughtpolice: Most of 'us' don't have the cash to be able to buy a license for VCS/Questa, so we have to use either Icarus/Verilator.
<jimn> thoughtpolice: I'd have to see how much the license is for the version of VCS I was using once upon a time. At the time it was US$250K/years
<jimn> s/years/year/
<jimn> s.have/hate/
<thoughtpolice> Dang, I heard something far lower than that recently (think 1/10th) but I don't understand their whole product line... If it was for ASIC verification (I assume with the manufacturer's gate libs?) then yeah that sounds more accurate, and in line with similar FPGA vs ASIC tooling prices
<jimn> This one also did mixed-signal simulation and had the high-performance option (multithreaded)
<jimn> Those two really drive the cost up
ZipCPU|Laptop has joined #yosys
ZipCPU|Laptop has quit [Quit: Warp drive ready at your command, Captain!]
tmiw has quit [Ping timeout: 265 seconds]
dys has quit [Ping timeout: 248 seconds]
gnufan1 has joined #yosys
gnufan has quit [Ping timeout: 240 seconds]
maikmerten has quit [Quit: Ex-Chat]
m_t has quit [Quit: Leaving]
siqueira_ has quit [Quit: Connection closed for inactivity]
indy has quit [Ping timeout: 248 seconds]
phiren is now known as phire
indy has joined #yosys