Sunday, 2018-06-17

*** tpb has joined #yosys00:00
*** digshadow has joined #yosys00:56
*** promach_ has joined #yosys01:47
*** noname_Matt has joined #yosys02:11
*** dxld has quit IRC02:45
*** dxld has joined #yosys02:45
*** ZipCPU has joined #yosys03:34
*** pie_ has quit IRC03:42
*** cr1901_modern1 has joined #yosys03:45
*** cr1901_modern has quit IRC03:48
*** leviathan has joined #yosys04:44
*** noname_Matt has quit IRC04:59
*** promach_ has quit IRC05:01
*** cr1901_modern1 has quit IRC05:07
*** cr1901_modern has joined #yosys05:07
*** xerpi has joined #yosys05:22
*** xerpi has joined #yosys05:24
*** Ank has joined #yosys06:03
AnkHi all, one questions regarding synthesis with Yosys. Does yosys windows version follow all the synthesis command based constraints? like clock, pin out loading, etc?06:04
AnkIt seems to ignore them.. may be this is with windows version? should we switch to linux ?06:05
ZipCPUAnk: Is there a yosys windows version?06:13
ZipCPUIf so .... I can't imagine why it would be any different06:13
ZipCPUDo you have all the dependencies set up properly?06:13
AnkYeah. Windows version is there -
tpbTitle: Yosys Open SYnthesis Suite :: Download (at
AnkThe webpage also says - At the moment Yosys is mostly tested on Linux.06:14
ZipCPUThis is most certainly true.06:14
ZipCPUI know most of the developers spend all their time on Linux.06:15
AnkIt is working fine.. it gives out synthesized netlist.. but somehow it is not following the constraints06:15
ZipCPUWhich constraints is yosys not following?06:15
AnkLike a higher clock rate synthesis..06:15
ZipCPUSuch as ... ?06:15
Ankor output pin loading06:15
ZipCPUyosys doesn't handle output pins ... that's handled by the placement tool.  Yosys itself only does synthesis06:16
AnkYeah, correct. But, will it set sufficient buffering for the pin loads or not?06:16
Ankthere are commands where you can set the output pin loads...06:17
Ankduring synthesis06:17
ZipCPUYes/no.  It may or may not connect the pins to IO cells.  If you connect the pins to an SB_IO block (iCE40), that usually handles any needs you might have.06:17
ZipCPUWhat yosys doesn't handle (well) are inout ports.06:17
ZipCPUI've got to imagine that such ports are on the "to-do" list, although they've been on the same to-do list for quite some time by now.06:18
AnkNow, I think that my concerns are more related to ABC06:19
ZipCPUIf you instantiate an SB_IO primitive you get access to that capability without much hassle.06:19
tpbTitle: Yosys Open SYnthesis Suite :: Command Reference :: abc (at
Ankthere is -constr file.. in which one can set driving cell and load06:19
ZipCPUMost people have no need to work with abc apart from the default yosys settings.  What is it you are trying to do?06:19
Ankthen, there is -D flag with which one can set delay target.. which is linked to clock rate06:20
ZipCPUWhat hardware are you working with?06:20
Ankit is for ASIC06:20
Ankno fpga hardware06:20
ZipCPUAhh ... okay.  And what functionality are you hoping to get from the synthesis tool that it isn't providing?06:21
AnkThe delault synthesized output is good for lets say 40Mhz clock.. but it is slow for 125MHz.06:21
AnkI want to speed up the delays in the synthesized netlist so it can clock it at higher frequencies.06:22
ZipCPUAre you sure that's the synthesizer's fault and not the fault of your layout?06:22
ZipCPUIf you are sure, then ... yeah, abc might be the place to look.06:22
AnkYes, not reached the layout phase yet.. just doing simulations at gate level netlist06:23
ZipCPUI didn't think the gate level netlist had any timing properties associated with it ... ??06:23
*** noname_Matt has joined #yosys06:24
AnkThe timing comes from the gates inserted in the paths right? Instead of using inv1x strength, if it would use inv4x strengths, the delays will be less. Just saying..06:25
daveshahAnk: are you sure your design is able to reach 125MHz?06:25
AnkThese are real fooundry provided gates,, so one can so spice simulations of the synthesized netlist06:25
Ankone can *do06:26
daveshahYeah, but your logic could still be too slow for abc to find any way to synthesise it above 40MHz. Is it proven with anything else?06:26
AnkNo, it is a very small core of may be 1000 gates06:26
daveshahIf it is, this could be an issue passing stuff to abc as you initially thought. I would definitely try and test on Linux which is what most people test on.06:26
Ankit can definitely do above 200MHz that I know06:27
AnkI must check it then on a linux platform06:27
daveshahSo I'd say either Yosys is calling abc incorrectly for some reason, or it is a bug in abc06:27
AnkIf anyone has faced similar problems on windows platform, then please let me know06:29
noname_Mattis there anywhere that goes into detail about how a pnr like arachne works? (other than reading the code itself, of course)06:29
noname_MattI'm interested to know06:29
ZipCPUnoname_Matt: You might have better luck asking the question.  I might be able to help with the placer portion of that.  daveshah would also know.06:31
noname_MattI don't have a specific question, I just want to know more about how place and route is done.06:33
noname_MattSince I know basically zilch.06:33
ZipCPULet me try to describe the placer for you ... it'd be good a good exercise for me06:33
ZipCPUThe placer works by picking FPGA array elements, and assigning them to logic elements within your design.  It does this in multiple passes.  The first pass tends to be just a random mapping.06:34
ZipCPUThen, the placer examines the mapping, and randomly changes some of the assignments--using over all wire length as a metric it tries to minimize.06:35
ZipCPUBy using a form of simulated annealing, it can juggle fewer and fewer changes until (hopefully) everything ends up better than it was before with a "decent" design.06:35
ZipCPUFeel free to check out to see how the placement is actually done06:37
tpbTitle: arachne-pnr/ at master · cseed/arachne-pnr · GitHub (at
ZipCPU(and whether my description is worth its salt or not .. ;)06:37
ZipCPUHow'd I do?06:38
noname_Mattwhat do you mean by "annealing"?06:38
tpbTitle: Simulated annealing - Wikipedia (at
noname_Mattah. this might require more sleep06:39
ZipCPUIt's an old AI trick for trying to find a result in a space of possibilities that are much to big to properly search.  Annealing works by modifying an existing placement to see if you can't make a better one.06:39
ZipCPUThe size of the modifications are adjusted over time, starting with big adjustments, working towards little ones.06:39
noname_MattI have probably goeen really good at doing the exact same thing in minecraft in 3D :)06:40
ZipCPUImagine the logic elements to be places where a kernel of popcorn might end up in a pan after popping.  Initially, everything is moving.  Slowly, as the kernels pop, things slow down.06:41
noname_MattI sometimes play a modded version with nuclear reactors and such, and it's always a struggle to fit all my pipes and wires and such into the rooms I build, which are never big enough06:41
*** Ank has quit IRC06:42
ZipCPUI'm trying to avoid playing with nuclear reactors myself ... I just wouldn't trust my lack of experience to be able to keep the thing from having some sort of exothermic event06:42
noname_MattI would have thought you could work out the best placement purely from the logical net itself06:42
ZipCPUHow so?  Please go on.06:43
noname_Mattsomething like get it to lay flat and pull the pieces together06:43
ZipCPUIf you have a good idea, ... I might even try it! ;)06:43
noname_Mattone sec, while I find a picture06:43
noname_Mattreminds me of a fractal like this^06:45
noname_Mattdrawing one, anyway06:45
ZipCPUI'm looking at the picture now06:45
noname_Mattfrom the logic, net you might be able to figure out what stuff has to be closer to other stuff, since the components of a single multiplexer should be close together, with short wires inbetween06:47
ZipCPUTrue, but what if multiple things want the result of that multiplexer?06:47
ZipCPUThen you have one output that needs to feed many inputs.06:47
noname_Mattthere might be some long wires in the design, like clocks, which touch stuff in distant places, but those are single connections outweighed by lots of ones that want to be small local ones06:48
noname_Mattthe main issue I see with this is this sort of information might be obscured by logic sysnthesis06:48
ZipCPUClocks tend to have their own networks, so ... not usually a big deal yet.06:48
ZipCPUAs for obscured, yeah ... it is somewhat, but it shouldn't be too hard to unobscure and recapture.06:49
noname_Mattwell, the clock is a general example, any signal that crosses from one end to the other would be like that06:49
ZipCPUHow about a data bus?  That's a good example IMHO.06:49
noname_Mattthose would be a pain06:49
ZipCPUEvery slave connected to the bus will need a connection.06:49
noname_Mattthat's something *you* would know has to be long and connect to lots of far away stuff, but it has a lot of wires06:50
noname_Mattso it would tend to pull stuff together that might not be optimal06:50
noname_MattI suppose in a way I might be walking in a circle towards annealing06:51
ZipCPUTry this ... you can work from a FF with a clock edge to another FF with the next clock edge06:51
ZipCPU(Flip-flop) You can measure the logic between FF's, and so measure how "long" something will take to process.06:52
ZipCPUYour goal would be to make sure that the longest FF chain is kept to a minimum (one-clock period) distance.06:52
ZipCPUAlong the way, you can move FF's on this chain.06:52
noname_Mattwhen you transition from "large" to "small" changes, how do you define large and small?06:53
ZipCPULogic elements that are drawn together should make it easier for other logic elements in the chain to be farther apart.06:53
noname_Mattis it something like moving fewer wire paths less distance, or moving larger blocks of congealed circuitry less?06:55
tpbTitle: arachne-pnr/ at master · cseed/arachne-pnr · GitHub (at
ZipCPUnoname_Matt: It's based upon a score that you are trying to minimize.  There's a "diameter" parameter which is used to pick an alternate configuration to a particular placement.  As the "temperature" lowers, the diameter gets smaller.06:56
ZipCPUHence, you look for better LUT placements closer and closer to the last one as time goes on.06:56
noname_Mattbut you're always moving LUTs one at a time?06:57
ZipCPUIn arachnepnr, yes.06:57
ZipCPUIt seems there would be a time and place for tearing up sections larger than a single LUT to replace, but ... that would need to be a future upgrade.06:58
noname_Matthrm. What I was imaging above was a system where you gradually congeal LUTs into larger and larger groups, and move them as a whole. You basically work up from the bottom saying "It is optimal that these two LUTs be close together, for reason X" then work towards "It is optimal that these two groups of LUTs be close together, for reason X" (which in the design might be two multiplexers with a lot of common connections)06:59
noname_Mattyou might still allow breaking up groups, but it would be less and less attractive to split it in half and move the two halfs apart07:00
noname_Mattyour reasoning might be based on wire length, for example07:01
ZipCPUThat sounds like a possible approach, but how do you know you have the groupings right?07:01
noname_MattI'm not too sure. You could argue that LUTs that have a lot of connections that are common should be close, since they're probably related. I wonder if starting the annealing by laying things out based on their connections might lead to an "optimal" solution faster07:03
ZipCPUThat is a fascinating thought.  I might need to try it.  :D07:04
*** emeb_mac has quit IRC07:04
noname_MattIt might be good low hanging fruit for testing this group and logical connection based approach07:04
noname_Mattseeing if it has any merit07:05
noname_MattAll I can say is it works pretty good in minecraft (I've gotten out of some pretty tight scrapes) but in that case I have knowledge of the overarching design07:06
ZipCPUYes it might.  I'm definitely going to think about it.07:06
ZipCPUWhat happens if the design elements don't really lay out in a even grid fashion?07:06
noname_MattI can even "resynthsize" things a little ,(to something "logically equivalent") if I find some connections to be very inconvenient07:07
noname_Mattwell, you will probably always have connections that will span the design07:07
noname_Mattcrossing over stuff07:07
noname_Mattso it won't lay flat07:08
noname_Mattyou probably want to just get as flat as possible, and you might not have to do it in a super smart way, since you're optimising afterwards07:08
noname_Mattyou probably want to just get as flat as possible, and you might not have to do it in a super smart way, since you're optimizing afterwards07:08
noname_MattMy instincts, having never done anything like this, would be to actually place and rout and synthesize at the same time, laying out large logical blocks (and trusting the human to have them separated by function in an intelligent manor) and then trying to pencil in their contents as I move towards something that could actually be put on the FPGS07:10
noname_Mattthis is probably stupid though07:11
noname_Mattthe reason I think it's dumb is that it's entirely possible that what makes conceptual sense makes no sense at all from a layout perspective. in a schematic, you can have busses and wires as long as you want07:12
noname_Mattand can group functinoality however you want07:12
*** indy has joined #yosys07:12
ZipCPU"My instincts, having never done anything like this" before ... neither have I.  I might want to try it anyway though.07:12
noname_Mattdarn. I need to break the habit discord has taught me of uparrow-ing to fix errors after the fact07:13
ZipCPUNo, but I like your thought of grouping small things into larger things.07:13
ZipCPUThen moving larger things around.07:13
noname_Mattdon't forget rotating07:13
ZipCPUAnd squishing07:13
noname_Mattyou may need to deform a group to make it fit nicer, or rotate it, or reflect it07:14
ZipCPUThere are a lot of things that might end up happening to that larger piece of design along the way as attempts are made to place it.07:14
noname_MattI would take a dumb approach to that07:14
ZipCPUWhat would that approach be?07:14
noname_Mattif a bunch of signals are on the wrong side, flip it and remeasure the score. take the one that's lower. that sort of thing07:15
ZipCPUWhat happens if you have two puzzle pieced elements, but with the wrong connection shape?07:15
noname_Mattsupporting deformation would be a nice goal, but for that you probably need to think about the groups inside the groups07:15
noname_Mattto take one example I might be able to suggest a solution for, suppose you have two groups, with an interface inbetween07:16
* ZipCPU listens07:17
noname_Mattand theres something inconvenient, like two buses that cross over each other07:17
noname_Mattthe "smart" way I would do it, being human, would be to look at each group and look a the sub groups that generate the busses07:18
daveshahnoname_Matt: in an FPGA architecure, I don't believe the penalty for crossing over is too great. It is total wirelength that is most important07:18
noname_Mattcan I move one up and the other down? does this affect anything else in the toplevel group07:18
ZipCPUThe big problem you will have is when you hit the borders of the array--in addition to the deformation problems we just discussed.07:19
noname_Mattthis becomes a recursive thing, where every time you bump into something "inconvenient" (some contribution to a rise in unpleasantness, however you measure it), you check the next level down to see if adjust ments can be made07:20
* ZipCPU notes that daveshah has been maintaining arachnepnr, and might know more about its functionality than ZipCPU does07:20
noname_Mattthis could quickly husr preformance though07:20
noname_MattI suppose you'd need some sort of "to heck with it, I don't want to go any deeper" kind of thing07:21
noname_Mattand that limit would get stricter as the blocks get bigger07:21
daveshahSo, is quite an interesting idea for bigger fpgas where the simple simulated annealing approach that looks at each cell is too slow07:22
ZipCPUI'm going to have to think on this possibility.  I mean, there are many ideas here.  I'm not sure if they work, but I'm really tempted to think about and perhaps even try some of them.07:22
noname_Matt*I* certainly wouldn't want to spend time unraveling my own work07:22
ZipCPUBut you'll have to.07:22
daveshahYou would probably only want to do the block based stuff early on, then do fine grained placement at individual cell level later in the placement07:22
ZipCPUI've got designs that are close to 95-98% full.  You have to get every last LUT to fill, and you have to deform molecules if you have them.07:23
noname_Mattwell, I wouldn't want to spend too much, unless there was some indication I could massively reduce unpleasantness07:23
ZipCPUStill, this might be used to guide some initial placement decisions.07:23
noname_MattI don't have a heuristic for whether something *might* reduce unpleasantness, since IRL I usually just try it and see hot it goes07:25
ZipCPUSo .... you weren't trying to make a simulated annealing pun?07:26
daveshahnoname_Matt: the heuristic arachne-pnr uses is simply total wirelength07:26
daveshahBasically, for each wire it looks at the locations it connects to and calculates distance between them07:26
noname_Mattpun unintended07:27
daveshahBut a more serious tool would configure timing information in that metric too07:27
noname_Mattmakes sense07:27
daveshahWires that are part of a long timing path (many cells between DFF output and input) must be considered more important than those in a short timing path07:27
daveshahThe lack of this in arachne-pnr means its timing values are quire unpredictable and maybe 30% worse than a timing driven tool07:28
noname_Mattsadly, I think a lot of useful information is lost in synthesis regarding what paths are and are not timing-critical07:28
daveshahNo, definitely not07:28
noname_Mattyou may have long paths (ie debugging) for which it's not super important07:29
daveshahThese will still ruin your day if they don't meet timing though07:29
daveshahUnless they're just straight to IO without going through registers07:29
daveshahIn either case, a proper tool would let you add constraints to ignore these paths if you really want07:30
daveshahAnd manually constraint other things that are needed07:30
noname_Mattperhaps I have an overly simplistic understanding of synthesis07:30
*** ZipCPU has quit IRC07:31
noname_Mattstill, as I noted above, you might be able to get hints from the human regarding the initial block divisions, if you knew things about how the levels of the design are structured07:33
noname_Mattideally, receiving a tree where each level is logically equivalent07:33
noname_Mattbut the top is the design as the human sees it, and at the bottom are just LUTs07:33
awyglealso, arachne doesn't just use total wire length. it uses an approximation, because you can't get a real number without routing the design. it uses half perimeter wire length as that approximation.07:33
daveshahnoname_Matt: that is what you get if you would synthesise a design without flattening07:34
daveshahBut then that precludes a number of synthesis optimisations07:34
noname_Mattyou might be able to work with some intermediate: apply the operations and don't care that it might mess up your tagging07:35
daveshahYes, that's how you'd have to do it07:36
daveshahawygle: one possibility with that is to determine a function based on a large number of designs between distance and delay07:36
daveshahThis would probably give a better heuristic to determine delay than just distance based measures as are used at the moment, without excessive performance cost07:37
awygleyes, a straightforward "Manhattan distance to delay" approach is common07:37
awygleit's fast as it's just a table lookup07:38
awygleat least one of the papers I have on the openfpga wiki does that, and there's a discussion of how to add the time parameter and keep the cost function stable and whatnot07:38
daveshahI would also like to look at going back to placement if routing finds areas that are congested, have excessive fanout, etc, and can't route them within the timing budget07:40
noname_MattThat's the kind of scenario I imagine shifting whole blocks of LUTs over might be helpful07:41
awygleThat's tricky as routing is potentially expensive. I believe I read a paper where the full route was run every N iterations of the placer, and then that value was added to the wire cost with some kind of decay07:42
awygleBut I'd have to dig it up07:42
awygleBut yes in general by breaking the problem into phases we get worse results (but more tractable problems of course)07:42
awygleIdeally synthesis, packing, placement, and routing would all be the same process (or continually feed back into each other which is the same thing)07:43
daveshahYes, that would also be needed for doing stuff like cell duplication for high fan out but simple logic07:44
awygleYup. It's an interesting set of problems even before you bring in parallelism. Anyway :-P it's after midnight here. Goodnight!07:45
noname_MattIs that where you duplicate the logic generating a signal, if it's cheaper than routing a long wire to where the signals is needed?07:45
* noname_Matt checks clock: 3:42AM Hrm.07:46
daveshahYeah, that's the idea07:46
daveshahThe most basic example would be a source of constant '1' (single logic cell) on an architecure without constant generators07:46
noname_Mattseems there's a long list of features an arch may or may not have07:47
noname_Mattand then there's the arch of the actual cells and connections07:48
*** indy has quit IRC07:48
noname_MattI can see why trying to build a generalized *anything* is hard07:48
daveshahSo the idea would be to have generic place and route functions call into architecure specific functions07:48
daveshahSome stuff, like design legalisation, validity checking and most of packing, is architecure specific07:49
noname_Mattare there any multiarch PnRs?07:49
daveshahPacking actually tends to be vendor rather than architecure specific because most vendors have similar or identical logic cells used in many architectures07:49
daveshahThere is VPR, but it is primarily intended for virtual architectures and getting it to work on real FPGAs is quite hard07:50
noname_MattI think I head about that :)07:50
daveshahNeoCAD is a commercial PnR that underpins Lattice Diamond and Xilinx ISE07:50
*** indy has joined #yosys07:50
daveshahBut no idea how similar the code base is between the two now, they diverged in the late 90s07:51
noname_MattThat's a long time ago07:51
* noname_Matt was born around then07:51
daveshahWould love to mention a few more things now, unfortunately I can't.07:51
*** indy has quit IRC08:01
*** _whitelogger has quit IRC08:28
*** _whitelogger has joined #yosys08:30
*** eduardo_ has joined #yosys08:48
*** eduardo has quit IRC08:51
*** dys has joined #yosys08:59
*** jwhitmore has joined #yosys09:13
*** indy has joined #yosys09:14
*** eduardo_ has quit IRC10:14
*** xerpi has quit IRC10:20
*** dys has quit IRC10:31
*** eduardo_ has joined #yosys10:49
*** eduardo_ has quit IRC10:56
*** ZipCPU has joined #yosys11:05
*** eduardo_ has joined #yosys11:14
mjoldfieldHaving flattened the design, can you recover/infer good blocks by doing a minimum k-cut on the connectivity graph ?11:34
ZipCPUWhat do you mean by "good blocks"?  (I feel like I'm coming into the middle of a conversation here ... is this in reference to placing algorithms?)11:36
ZipCPUOk, and what do you mean by "good blocks"?  A placer places logic "blocks" into the design.  Blocks at that point are neither good nor bad, they are design blocks that need to be placed, right?  Or am I missing something?11:38
mjoldfieldIn the discussion above people were talking about routing small stuff then gluing those together. Then someone pointed out that if you flatten the design you lose the notion of the small blocks, so I wonder if minimum k-cut would recover components which are weakly connected to other blocks.11:38
* ZipCPU googles "k-cut"11:38
tpbTitle: Minimum k-cut - Wikipedia (at
ZipCPUOoohh ... fascinating11:39
mjoldfieldIt's a generalization of
tpbTitle: Minimum cut - Wikipedia (at
mjoldfieldI think there are a bunch of algorithms on graphs which do things more efficiently than you might guess, and they seem relevant for routing problems. However, I don't know much more about graph theory than 'there be interesting results here'.11:41
ZipCPUI suppose that's about as much as I know as well, but I like your link, and I'll do some reading on it.11:44
*** dys has joined #yosys11:59
*** gyroninja has quit IRC12:05
*** AlexDaniel has quit IRC12:32
*** promach_ has joined #yosys12:36
mjoldfieldI hope it's helpful. Let me know if you get anywhere.12:36
*** pie_ has joined #yosys12:47
*** pie__ has joined #yosys13:08
*** pie_ has quit IRC13:08
*** digshadow has quit IRC13:20
*** m_w has quit IRC13:57
*** m_w has joined #yosys13:58
*** pie__ has quit IRC14:00
*** gyroninja has joined #yosys14:10
*** digshadow has joined #yosys14:13
*** pie__ has joined #yosys14:27
*** leviathan has quit IRC14:36
*** leviathan has joined #yosys14:43
promach_do we need to manually specify all the source files in the sby file such as ? does SymbiYosys support wildcard (../rtl/*.v) file selection yet ?14:48
tpbTitle: zipcpu/zipcpu.sby at dev · ZipCPU/zipcpu · GitHub (at
ZipCPUWhy should SymbiYosys support wildcard selection?14:49
promach_read_verilog also needs to be repeated besides the files section14:51
ZipCPUThat ones not as much of a repeat, as you can add other command line arguments to read_verilog that might be specific to your proof.14:51
ZipCPUFor example, read_verilog -D ZIPCPU -formal fwb_counter.v14:52
ZipCPUOr read_verilog -D ZIPCPU -DPHASE_TWO -formal zipcpu.v14:52
promach_-D ??14:52
ZipCPUJust like with GCC, it specifies a synthesis directive.  Inside zipcpu, I have things like `ifdef ZIPCPU or `ifdef PHASE_TWO14:53
*** xerpi has joined #yosys15:09
promach_ZipCPU: why don't you have "opt_merge -share_all" in your sby file ?15:19
ZipCPUSometimes it helps, sometimes it doesn't.15:20
promach_what /15:31
ZipCPUSometimes it helps, sometimes it doesn't.15:31
promach_I do not understand why15:31
ZipCPUI started taking it out following an update of yosys where it didn't seem to support that functionality anymore.15:32
ZipCPUSince that time, I've discovered the problem was operator error, not tool changes.15:32
*** pie_ has joined #yosys15:33
*** pie__ has quit IRC15:33
*** pie_ has quit IRC16:06
*** pie_ has joined #yosys16:11
*** digshadow has quit IRC16:12
* noname_Matt reboots16:12
noname_Mattinsert coffee~~~~16:12
noname_Mattk-cut certainly seems interesting. might be a good fit for what I had in mind16:14
*** AlexDaniel has joined #yosys16:18
*** AlexDaniel has quit IRC16:52
*** AlexDaniel has joined #yosys16:52
*** promach_ has quit IRC17:21
*** digshadow has joined #yosys18:00
*** xerpi has quit IRC18:08
*** sklv has quit IRC18:17
*** sklv has joined #yosys18:18
*** ZipCPU|ztop has joined #yosys18:20
*** ZipCPU has quit IRC18:20
*** pie_ has quit IRC19:03
*** pie_ has joined #yosys19:22
*** leviathan has quit IRC19:39
*** digshadow has quit IRC19:40
*** digshadow has joined #yosys19:46
*** digshadow has quit IRC19:49
*** ZipCPU|ztop has quit IRC19:53
*** eduardo_ has quit IRC19:54
*** eduardo_ has joined #yosys19:58
*** xerpi has joined #yosys20:30
*** xerpi has joined #yosys20:31
*** emeb_mac has joined #yosys20:50
*** emeb_mac has quit IRC21:28
*** brandonz has joined #yosys21:52
*** xerpi has quit IRC22:05
*** eduardo__ has joined #yosys22:23
*** m_w has quit IRC22:23
*** eduardo_ has quit IRC22:26
noname_MattWhat's the largest contiguous ram you could specify in something like an ICE40HX8K? Or is it impractical for a large block of ram to coexist with other logic?22:27
noname_Matt(from a pnr standpoint)22:27
*** dys has quit IRC22:36
*** danieljabailey has quit IRC23:04
*** danieljabailey has joined #yosys23:04
*** jwhitmore has quit IRC23:24
*** digshadow has joined #yosys23:38

Generated by 2.13.1 by Marius Gedminas - find it at!