| *** tpb has joined #yosys | 00:00 | |
| *** voxadam has quit IRC | 01:36 | |
| *** voxadam has joined #yosys | 01:40 | |
| *** PyroPeter has quit IRC | 02:13 | |
| *** PyroPeter has joined #yosys | 02:27 | |
| *** attie has joined #yosys | 03:11 | |
| *** attie has quit IRC | 03:16 | |
| *** jkiv has joined #yosys | 03:29 | |
| *** jkiv has quit IRC | 03:32 | |
| *** jkiv has joined #yosys | 03:33 | |
| *** jkiv has quit IRC | 03:37 | |
| *** citypw has joined #yosys | 04:38 | |
| *** _whitelogger has quit IRC | 04:45 | |
| *** _whitelogger has joined #yosys | 04:47 | |
| *** _whitelogger has quit IRC | 05:24 | |
| *** _whitelogger has joined #yosys | 05:26 | |
| *** _whitelogger has quit IRC | 05:42 | |
| *** _whitelogger has joined #yosys | 05:44 | |
| *** _whitelogger has quit IRC | 06:03 | |
| *** _whitelogger has joined #yosys | 06:05 | |
| *** emeb_mac has quit IRC | 06:16 | |
| *** craigo has quit IRC | 06:33 | |
| *** Jybz has joined #yosys | 06:46 | |
| *** _whitelogger has quit IRC | 07:03 | |
| *** _whitelogger has joined #yosys | 07:05 | |
| *** attie has joined #yosys | 11:13 | |
| *** attie has quit IRC | 11:17 | |
| *** fevv8[m] has quit IRC | 11:54 | |
| *** jryans has quit IRC | 11:54 | |
| *** pepijndevos[m] has quit IRC | 11:54 | |
| *** rjo has quit IRC | 11:54 | |
| *** nrossi has quit IRC | 11:54 | |
| *** fevv8[m] has joined #yosys | 12:06 | |
| *** attie has joined #yosys | 12:44 | |
| *** nrossi has joined #yosys | 12:58 | |
| *** jryans has joined #yosys | 12:58 | |
| *** pepijndevos[m] has joined #yosys | 12:58 | |
| pepijndevos | What's the difference between Shl Shr Sshl Sshr Shift Shiftx? | 12:59 |
|---|---|---|
| pepijndevos | From the name I'd guess sshl is signed/arithmetic, but Shl also has a signed parameter... | 13:02 |
| pepijndevos | Yea...manual+google suggests it's indeed arithmatic shift | 13:05 |
| *** Jybz has quit IRC | 13:33 | |
| *** Jybz has joined #yosys | 13:36 | |
| *** stzsch has quit IRC | 13:48 | |
| *** attie has quit IRC | 14:08 | |
| *** lutsabound has joined #yosys | 14:09 | |
| pepijndevos | Would love to chat with someone familiar with memory interference how to map HDL to memrd and memwr and mem and rtlil::Memory stuff | 14:11 |
| whitequark | sure | 14:12 |
| whitequark | i implemented that in nmigen | 14:12 |
| pepijndevos | yay | 14:12 |
| pepijndevos | so I'm looking at GHDL and how to map that to yosys constructs | 14:12 |
| whitequark | re shift/shiftx: i believe that's the same as shr, except it maps to the verilog indexed part-select construct | 14:12 |
| whitequark | i'm not sure if yosys ever emits shift (as opposed to shiftx) | 14:12 |
| pepijndevos | So if I make an 1024 array of 8 bit elements, it gets synthesized into a 8191 lenght flat vector | 14:13 |
| pepijndevos | then there is a memidx primitive that seems to translate and index to the flattened array | 14:14 |
| whitequark | hmm | 14:14 |
| whitequark | that seems troublesome | 14:14 |
| pepijndevos | and there is a dyn_extract and dyn_insert that is basically a non-constant array lookup | 14:14 |
| pepijndevos | So in yosys, is memory of a specified dimension? | 14:16 |
| whitequark | yep | 14:16 |
| pepijndevos | Hrm... I can maybe discuss with Tristan to delete the whole flattening and memidx step | 14:17 |
| pepijndevos | But okay, so either I need to "unflatten" that or skip that step in GHDL | 14:18 |
| pepijndevos | So say I have just an array of std_logic_vector, how would I map that to yosys memory things? | 14:19 |
| whitequark | let's see | 14:20 |
| *** attie has joined #yosys | 14:21 | |
| whitequark | pepijndevos: right, so, you could map either to $mem cells, or $memrd/$memwr/$meminit | 14:23 |
| whitequark | do you know which one is closer to your existing IR in that case? | 14:24 |
| whitequark | i.e. how does GHDL represent ports? | 14:24 |
| pepijndevos | As far as I understand, currently there is no "port" per se, but a dyn_extract and dyn_insert primitive that are basically arra[idx] and array[idx]=val | 14:26 |
| whitequark | ok | 14:27 |
| whitequark | those map directly to $memrd and $memwr | 14:27 |
| whitequark | basically you assign some index to each distinct `array` and use it as \MEMID parameter | 14:27 |
| pepijndevos | So do you need to convert arrays to RTLIL::Memory instances? | 14:28 |
| whitequark | nope | 14:29 |
| whitequark | i mean, you could | 14:29 |
| whitequark | soryr | 14:29 |
| whitequark | *sorry, you do | 14:29 |
| whitequark | I misremembered how this works | 14:29 |
| whitequark | each memory is converted to RTLIL::Memory, and then $memrd/$memwr ports are associated to it by name (via \MEMID) | 14:30 |
| whitequark | the geometry of the memory is duplicated, for RTLIL::Memory and then in each port | 14:30 |
| pepijndevos | Hm okay | 14:31 |
| pepijndevos | (I have NO idea what would map to meminit in VHDL) | 14:32 |
| whitequark | how do you initialize memories in VHDL? | 14:32 |
| pepijndevos | I googled it and I'm still not sure... you pretty much don't??? Or in some vendor specific way or something that only works in simulation. | 14:33 |
| whitequark | huh | 14:33 |
| ZirconiumX | That's odd. | 14:33 |
| pepijndevos | Like... there isn't anything like readmemb() either | 14:34 |
| pepijndevos | so people just reset arrays in reset and do manual file IO bs | 14:34 |
| ZirconiumX | And I almost had respect for VHDL :P | 14:35 |
| whitequark | reset arrays in reset? | 14:35 |
| pepijndevos | Yea, like you reset other values... if reset memory = initial value, doesn't map to bram in any useful way... | 14:36 |
| ZirconiumX | So it gets initialised by logic? | 14:37 |
| ZirconiumX | That's, uh, not great. | 14:37 |
| *** Xiretza has joined #yosys | 14:37 | |
| whitequark | I'm thinking it is mostly ASIC-geared then | 14:38 |
| ZirconiumX | I mean, it was originally written for ASICs, but I would have thought they'd expand it to handle this | 14:40 |
| daveshah | It definitely supports initialised registers | 14:41 |
| daveshah | With a := value after the signal declaration | 14:41 |
| *** umarcor has joined #yosys | 14:41 | |
| daveshah | I'm pretty sure this works for initialised BRAM too | 14:41 |
| pepijndevos | I guess you're right https://stackoverflow.com/questions/16607812/initializing-memory-in-netlist-vhdl | 14:53 |
| tpb | Title: synthesis - Initializing memory in netlist VHDL - Stack Overflow (at stackoverflow.com) | 14:53 |
| pepijndevos | Also, "Initializing RAM contents" here has a function for reading from disk in VHDL https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug901-vivado-synthesis.pdf | 14:55 |
| umarcor | @pepijndevos, I think the reason to use IO for simulation is that the same functions can be used to read different data files, instead of copying large sets of raw values in the codebase. however, I've seen packages used to define constants (memory initialization values) only. | 14:55 |
| *** attie has quit IRC | 14:57 | |
| umarcor | regarding initialization of BRAMs (as opposed to arrays of registers), I think that it is vendor-specific. IIRC, Xilinx (ISE or Vivado) will populate the BRAM with the values you define either as @daveshah commented, or with the reset values of the process from where the BRAM is inferred. I don't know which one is picked when both exist. | 14:58 |
| umarcor | when the BRAM is defined as an IP-core in Vivado, a bin or hex file can be provided. | 14:59 |
| umarcor | last, cli tools exist to overwritten the initialization values of BRAMs in bitstreams. these are provided in the SDK, since they are meant for software developers that don't have access to the sources of the hardware design. I'm afraid that none of this is open source. | 15:00 |
| whitequark | icestorm has such an open source tool | 15:00 |
| whitequark | called "icebram" | 15:00 |
| umarcor | exactly | 15:00 |
| *** dys has joined #yosys | 15:00 | |
| umarcor | but it targets lattice device only, for now, isn't it? | 15:01 |
| whitequark | icestorm targets ice40 specifically | 15:01 |
| umarcor | is the reverse engineering effort around xilinx's 7 series mature enough to adapt it? | 15:01 |
| mwk | hmm | 15:02 |
| mwk | how does icebram know which blockram to target? | 15:02 |
| whitequark | i know very little about xilinx, but i thought the BRAM frames were among the easiest to work with | 15:02 |
| whitequark | mwk: you fill it with a pattern first | 15:02 |
| mwk | ew | 15:02 |
| whitequark | you have to do it because the geometry may change quite a bit | 15:02 |
| whitequark | e.g. yosys can change aspect ratio and duplicate BRAMs | 15:03 |
| mwk | because of address lines being swizzled? | 15:03 |
| mwk | hmm | 15:03 |
| whitequark | and that too | 15:03 |
| mwk | tbh that sounds like something we should invent a metadata format for | 15:03 |
| whitequark | possibly, but i think the approach of filling it with a pattern works fine | 15:03 |
| mwk | feels hacky | 15:03 |
| whitequark | as long as you always have an unique mapping, is it? | 15:04 |
| mwk | unique mapping? | 15:04 |
| mwk | you just said that brams can get duplicated | 15:05 |
| whitequark | i mean, as long as the pattern is sufficiently random that you don't get collisions | 15:06 |
| * mwk was considering something some time ago | 15:06 | |
| mwk | a "relocation" mechanism | 15:06 |
| mwk | mark a BRAM / LUT / generic attribute as "to be resolved later" somehow in .v | 15:06 |
| mwk | let it pass through synth + pnr unchanged | 15:06 |
| mwk | and have it resolved at bitstream creation point | 15:07 |
| whitequark | vivado has almost this, no? | 15:07 |
| whitequark | where you can manipulate post-synthesis netlist | 15:07 |
| mwk | sort of, yes | 15:07 |
| whitequark | give your BRAM or LUT an attribute and grab it with tcl | 15:07 |
| mwk | hmm | 15:07 |
| mwk | right, that would work | 15:07 |
| mwk | anyhow, the "relocation" approach would work for things smaller than whole blockrams, ideally | 15:08 |
| mwk | like single LUTs | 15:08 |
| mwk | or, the case I was thinking of, PLL parameters | 15:08 |
| whitequark | yes, sb used it for PLL parameters | 15:09 |
| mwk | so you can tune your PLL without re-pnring and changing timing in the process | 15:09 |
| whitequark | when the bitstream would build for hours | 15:09 |
| mwk | sb? | 15:09 |
| whitequark | sebastien from m-labs | 15:09 |
| mwk | oh | 15:10 |
| pepijndevos | whitequark, talking to Tristan now, and the worry is that some uses of 2D array don't map to memories, and Yosys doesn't do 2D arrays apparently. So the only general approach seems to flatten everything and then have a whole pass to extract and unflatten memories -.- | 15:11 |
| pepijndevos | (https://gitter.im/ghdl1/Lobby) | 15:11 |
| tpb | Title: ghdl1/Lobby - Gitter (at gitter.im) | 15:11 |
| whitequark | what is a 2D array | 15:12 |
| mwk | int a[20][20]; | 15:13 |
| whitequark | personally, i think that the propensity of HDL toolchains to leave the most important properties of your design (like whether something gets mapped to BRAM) to "inference" is one of the absolute worst things about them | 15:13 |
| whitequark | but people seem to like that approach anyway, so i guess go for it | 15:13 |
| pepijndevos | Yea, so from what I gather in Verilog `reg [20] foo [8]` indicates an array of 20 elements of 8 bits, but VHDL doesn't really have a distinction like that. You just make arrays or arrays of arrays of arrays of bits | 15:14 |
| mwk | pepijndevos: 8 elements of 20 bits, and you write it as reg[19:0] foo [0:7] | 15:15 |
| mwk | and in systemverilog IIRC you can do reg[19:0] foo [0:7][0:9] | 15:15 |
| mwk | and as for xilinx and memory frames, uh | 15:20 |
| mwk | suppose you want to make a xilinxbram tool | 15:21 |
| pepijndevos | So how does yosys decide what to do with a reg [x:y] foo [a:b]? Does that always become a memory, or can you do non-memory things to it that cause it to just become logic? | 15:21 |
| mwk | first, you get to parse and re-emit the bitstream | 15:21 |
| mwk | which requires full geometry information about the chip already | 15:21 |
| mwk | this implies a big chip database | 15:21 |
| Xiretza | mwk: that's what https://github.com/SymbiFlow/prjxray is about | 15:22 |
| tpb | Title: GitHub - SymbiFlow/prjxray: Documenting the Xilinx 7-series bit-stream format. (at github.com) | 15:22 |
| mwk | second, you need a map of the bits in a blockram tile and information about the particular arrangement | 15:23 |
| emily | I think mwk might be a little familiar with Xilinx reverse-engineering efforts... | 15:23 |
| whitequark | lol | 15:23 |
| mwk | which depend on many things | 15:23 |
| mwk | mostly 18k vs 36k size and TDP vs SDP | 15:23 |
| mwk | I've looked at the blockram bits geometry, and... I suppose there is some logic to it, but it mostly looks like a big mess | 15:24 |
| mwk | anyhow, such a tool can definitely be done | 15:25 |
| mwk | atm I think I have enough data to do that for everything from xc2v up to xc7 | 15:26 |
| Xiretza | emily: hah, woops. I don't really follow the developments very closely and didn't associate the name :) | 15:26 |
| mwk | but that's quite a bit of effort, and given that both ISE and Vivado already include such a tool, I don't see it as high-priority | 15:26 |
| *** emeb has joined #yosys | 15:34 | |
| *** craigo has joined #yosys | 16:11 | |
| *** gkh has joined #yosys | 16:22 | |
| *** citypw has quit IRC | 17:40 | |
| *** Jybz has quit IRC | 18:57 | |
| *** Jybz has joined #yosys | 18:59 | |
| mwk | that may be a stupid question, but... what does "coarse-grain synthesis" refer to in yosys? (looking at splice and connwrappers command help) | 19:02 |
| whitequark | mwk: synthesis to multibit cells | 19:04 |
| whitequark | like there's $and which has n-bit inputs and outputs | 19:04 |
| whitequark | and $_AND_ which has strictly 1-bit | 19:05 |
| mwk | oh, just that | 19:07 |
| mwk | still don't understand what these two commands are useful for, though... | 19:07 |
| mwk | they don't seem to be called in the course of normal synthesis | 19:08 |
| mwk | "This command adds $slice and $concat cells to the design to make the splicing of multi-bit signals explicit. This for example is useful for coarse grain synthesis, where dedicated hardware is needed to splice signals." | 19:09 |
| mwk | ok, I definitely don't understand what dedicated hardware that would be | 19:09 |
| daveshah | Coarse grain reconfigurable arrays | 19:28 |
| daveshah | Which I guess might be based on buses internally and therefore have special resources for manipulating those buses | 19:28 |
| whitequark | huh, never heard of those. any links? | 19:28 |
| emily | I think it was meant as a hypothetical? | 19:29 |
| emily | apparently not | 19:29 |
| daveshah | I don't think there are any you can buy | 19:29 |
| daveshah | Lots of papers | 19:29 |
| mwk | some crazy research thing? | 19:30 |
| mwk | ah, figures | 19:30 |
| daveshah | I think some modern apps processors have structures a bit like them for image sensor pipelines etc | 19:30 |
| daveshah | But good luck finding any docs or info for them | 19:30 |
| whitequark | http://cccp.eecs.umich.edu/research/cgra.php lmao this logo | 19:31 |
| tpb | Title: CCCP: Coarse-Grained Reconfigurable Architecture (at cccp.eecs.umich.edu) | 19:31 |
| mwk | did they seriously.. | 19:32 |
| mwk | oh | 19:32 |
| mwk | they did | 19:32 |
| mwk | anyhow, this does answer my question | 19:33 |
| mwk | daveshah: thanks | 19:33 |
| daveshah | I'm not convinced how useful something like Yosys would be for commercial CGRAs | 19:34 |
| mwk | I still wonder how we ended up with these passes | 19:34 |
| daveshah | As far as I can tell from a quick search, hacking LLVM seems to be more popular as an approach | 19:34 |
| daveshah | I think Clifford did some work with TU Wien people on them | 19:34 |
| daveshah | http://www.clifford.at/intersynth/ | 19:35 |
| tpb | Title: InterSynth - Example-Driven Interconnect Synthesis (at www.clifford.at) | 19:35 |
| daveshah | Might be related | 19:35 |
| *** dys has quit IRC | 20:23 | |
| cr1901_modern | Dat hammer-and-sickle... | 20:32 |
| *** Jybz has quit IRC | 20:36 | |
| *** dys has joined #yosys | 20:43 | |
| *** emeb_mac has joined #yosys | 20:46 | |
| *** umarcor has quit IRC | 21:10 | |
| *** craigo has quit IRC | 22:34 | |
| *** craigo has joined #yosys | 23:23 | |
| *** gnufan_home has joined #yosys | 23:28 | |
| *** gnufan_home has quit IRC | 23:42 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!