digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
digshadow has quit [Quit: Leaving.]
<flaviusb> Is there a guide to 'techmapping' that people have found to be useful?
<flaviusb> I'm kindof playing around with a staging approach to eventual artwork generation (ala multistage programming, http://okmij.org/ftp/meta-programming/HPC.html or http://okmij.org/ftp/meta-programming/ for further material), which looks like a much more direct 'describe what you actually want to generate' approach, rather than 'write simulation focused code, magic happens, it (maybe) turns into a chip', which seems to be how most chip
<flaviusb> sign works.
<flaviusb> But I don't understand the 'magic happens' phase at all, so I could easily be completely wrong in my approach.
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
m_w has quit [Quit: leaving]
amclain has quit [Quit: Leaving]
_whitelogger has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<azonenberg> flaviusb: i've always used yosys for that
<azonenberg> my work has mostly been lower level than that
<azonenberg> i started with a techmapped netlist and turned it into a bitstream
<azonenberg> might be worth studying yosys source though?
<azonenberg> i found it pretty easy to follow once you got used to the general flow of things
_whitelogger has joined ##openfpga
<flaviusb> azonenberg: Thanks. I'll have a look at that.
<pointfree> flaviusb: My plan for gelFORTH is to unify placement, routing, and techmapping under incremental, interactive logic synthesis.
<pointfree> Expressions that map to the same prime/essential prime implicants evaluate to the same address/bits in the bitstream.
<pointfree> I'm thinking about finding the shortest route as the same problem as finding the shortest Boolean expression.
<flaviusb> pointfree: Cool. Yeah, gelFORTH was one of the projects I was looking at when I was trying to work out what kinds of directions people had fruitfully explored before.
<whitequark> flaviusb: you cannot write simulation focused code and expect it to easily turn into a chip
<whitequark> you have to write synthesis-focused code
<whitequark> and in case you don't like being allowed to write simulation code in the same language, other approaches exist (migen is one of them, for example)
<whitequark> in migen you can only (without resorting to instancing) express synchronous logic, etc
scrts has quit [Ping timeout: 256 seconds]
<flaviusb> whitequark: That was lazy of me. I think I mean more like... there are these languages which are simulation focused in their design and many assumptions, and you *can* (if you know the folklore) write input to tools that will eventually produce chips in them. But good luck if you don't know the folklore.
<flaviusb> I like what I have seen of Migen a *lot*.
scrts has joined ##openfpga
<flaviusb> My memory of my reasoning for what led me to not just use it for what I want to do is:
<flaviusb> 1) I have a mild case of NIH syndrome
<flaviusb> 3) I think I remember that Migen still used chunks of the 'magic based ecosystem', which I want to get away from entirely
<flaviusb> 2) I hate Python with the fire of a thousand suns, for a variety of reasons
<mIKEjONES> azonenberg: you're famous
<mIKEjONES> Ctrl+F openfpga
<whitequark> flaviusb: (2) I hate Python too
<whitequark> you could rewrite migen in something else rather easily, and there are fairly similar projects out there already anyway
<whitequark> like SystemC, as we've recently figured out
<whitequark> (3) it does, and you can't
<whitequark> well
<whitequark> you can't, if you want to deploy code to real FPGAs
<whitequark> you can, if you deploy code to iCE40
<whitequark> migen can output netlists directly, there's no inherent problem with that, it just gets you nowhere with xilinx/altera tools
<azonenberg> mIKEjONES: lol that was posted by magulo
<mIKEjONES> oh dammit I can't scroll too much with this client :(
<cr1901_modern> magic based ecosystem?
<flaviusb> VHDL/Verilog have this thing where they have a reasonably well defined semantics when used for simulation, but nothing of the sort when used to generate chips.
<azonenberg> flaviusb: There is a fairly well defined set of semantics for synthesis, but many additional things, like initial statements
<azonenberg> are not officially supported for synthesis but most real tools support
<azonenberg> (at least for fpga)
<cr1901_modern> Oh, Idk what Migen's semantics are. Probably "just use the semantics of whatever verilog it generates, work around toolchain bugs"
<cr1901_modern> And I didn't know migen supported output to yosys
<cr1901_modern> erm, netlist*
<cr1901_modern> whitequark: What did you mean by these statements? https://irclog.whitequark.org/~h~openfpga/2017-04-01#1491028957-1491028988; Use verilog as the simulation lang, Migen for synthesis?
<whitequark> no
<whitequark> migen has a precisely defined semantics
<whitequark> it's the same in both synthesis and simulation (well if not it's a bug)
<flaviusb> Eh. I would put VHDL and Verilog at about the level of Javascript, both in terms of language and ecosystem. Like, you can clearly write gigantic impressive stuff with it, but none of the constituent technologies really actually *work*.
<flaviusb> *Magic*
<cr1901_modern> Okay, it sound like "if you don't like being allowed to write simulation code in the same language" was a constraint that "a language shouldn't be used for both simulation and synthesis"
<cr1901_modern> Migen simulator is fine (if slow), but I do miss the VPI.
<flaviusb> In JS's case it is just that everything if fractally janky. In HDL stuff it seems to be (from the perspective of this filthy casual) that many steps are giant stacks of heuristics and an opaque target execution model, both of which you just have to learn and simulate manually in your head.
<flaviusb> s/if fractally/is fractally/
<cr1901_modern> Migen-to-netlist would be an interesting project, but Idk how to write a code generator
<whitequark> cr1901_modern: it exists
<whitequark> migen.fhdl.edif
<flaviusb> The problem is netlist-to-bitstream or netlist-to-artwork.
<whitequark> flaviusb: that's what the PAR does
<flaviusb> whitequark: Which part, sorry?
<whitequark> flaviusb: netlist-to-bitstream
<cr1901_modern> whitequark: TIL o.0;. I've been using Migen for two years and I've never seen this
<whitequark> netlist-to-artwork is actually easier, there is, I think, more than one fully FOSS toolchain for that
<cr1901_modern> netlist-to-artwork?
<flaviusb> GDSII or whatever you feed to a foundry to get back chips.
<whitequark> cr1901_modern: masks for lithography
<flaviusb> whitequark: So... it would be possible to liberate Migen from magic?
<cr1901_modern> Ahhh okay. Idk much about that. I am a little surprised it's easier than netlist-to-bitstream, since masks have to pass a bunch more analyses
<whitequark> flaviusb: you can literally do that right now
<flaviusb> whitequark: Wow. Okay. That is really cool.
<cr1901_modern> whitequark: Do you mean "use the edif generator"?
<whitequark> yes
<whitequark> and feed it into yosys
<cr1901_modern> flaviusb: We both learned something lol. I NEVER knew the edif generator existed lol.
<cr1901_modern> I should prob add an option to use that for the IceStorm backend
<whitequark> you could even tell yosys to transform it BACK to verilog
<whitequark> and then feed it into xilinx tools
<rqou> wait, there's no way there's FOSS tools for optical proximity correction, are there?
<rqou> (replying to netlist-to-artwork being easier)
<cr1901_modern> whitequark: That might be an interesting way to flush out bugs... find a design written in Migen where EDIF=>verilog=>Xilinx and verilog=>Xilinx don't match
digshadow has joined ##openfpga
m_t has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
<rqou> hrm, another interesting vhdl footgun/feature
<rqou> if you have an entity named "test"
<rqou> it will exist in the "root declarative region" the instant you hit the keyword "is"
<rqou> so basically "it exists while still inside the entity itself"
<rqou> but it won't exist in the library until the end of the entity
<rqou> so inside the entity "test" you can use "test.a" to refer to a constant "a" inside the entity
<rqou> but you can't use "work.test.a"
<rqou> hrm
<rqou> apparently expanded names aren't even allowed in the declarative part at all
<rqou> wut
<rqou> er, maybe it's a different issue after all
<rqou> maybe ghdl is just wrong
<rqou> VHDL language lawyers, is the following valid?
<rqou> entity test is
<rqou> constant a : bit := '0';
<rqou> constant b : bit := work.test.a;
<rqou> begin end;
<rqou> ghdl says no, i believe it should be yes
<rqou> also herp derp i really haven't been productive this entire week
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
<egg|egg> rqou: can't help you here, Ada has no entities :-p
<egg|egg> rqou: maybe I can tell you what happens with packages
<rqou> oh VHDL has packages too :P
X-Scale has quit [Read error: Connection reset by peer]
<rqou> wow i'm at a part of the program where i have no idea what to do next
<rqou> software engineering (as opposed to code monkey-ing) is hard :P
scrts has quit [Ping timeout: 246 seconds]
promach has joined ##openfpga
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
ZipCPU_ has joined ##openfpga
ZipCPU has quit [Ping timeout: 240 seconds]
ZipCPU_ is now known as ZipCPU
Hootch has joined ##openfpga
Zarutian has joined ##openfpga
Zarutian has quit [Read error: Connection reset by peer]
Zarutian has joined ##openfpga
m_t has quit [Remote host closed the connection]
m_t has joined ##openfpga
<qu1j0t3> +1
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
m_t has quit [Quit: Leaving]
m_t has joined ##openfpga
azonenberg_work has quit [Ping timeout: 256 seconds]
azonenberg_work has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
promach has quit [Ping timeout: 258 seconds]
m_w has joined ##openfpga
X-Scale has joined ##openfpga
X-Scale has quit [Read error: Connection reset by peer]
X-Scale has joined ##openfpga
felix_ has quit [Ping timeout: 246 seconds]
felix_ has joined ##openfpga
scrts has quit [Ping timeout: 256 seconds]
scrts has joined ##openfpga
mzpx has joined ##openfpga
mzpx has quit [Ping timeout: 264 seconds]
Hootch has quit [Quit: Leaving]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
m_t has quit [Quit: Leaving]
fpgacraft2 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft2 has joined ##openfpga
fpgacraft1 has joined ##openfpga
m_t has joined ##openfpga
digshadow1 has quit [Quit: Leaving.]
Zarutian has quit [Ping timeout: 240 seconds]
m_t has quit [Quit: Leaving]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
Zarutian has joined ##openfpga
clifford has quit [Ping timeout: 240 seconds]
<rqou> huh, I apparently got a huge barrage of spam recently
<rqou> time to retrain spamasaassin