| *** tpb has joined #yosys | 00:00 | |
| *** digshadow has joined #yosys | 00:56 | |
| *** promach_ has joined #yosys | 01:47 | |
| *** noname_Matt has joined #yosys | 02:11 | |
| *** dxld has quit IRC | 02:45 | |
| *** dxld has joined #yosys | 02:45 | |
| *** ZipCPU has joined #yosys | 03:34 | |
| *** pie_ has quit IRC | 03:42 | |
| *** cr1901_modern1 has joined #yosys | 03:45 | |
| *** cr1901_modern has quit IRC | 03:48 | |
| *** leviathan has joined #yosys | 04:44 | |
| *** noname_Matt has quit IRC | 04:59 | |
| *** promach_ has quit IRC | 05:01 | |
| *** cr1901_modern1 has quit IRC | 05:07 | |
| *** cr1901_modern has joined #yosys | 05:07 | |
| *** xerpi has joined #yosys | 05:22 | |
| *** xerpi has joined #yosys | 05:24 | |
| *** Ank has joined #yosys | 06:03 | |
| Ank | Hi 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 |
|---|---|---|
| Ank | It seems to ignore them.. may be this is with windows version? should we switch to linux ? | 06:05 |
| ZipCPU | Ank: Is there a yosys windows version? | 06:13 |
| ZipCPU | If so .... I can't imagine why it would be any different | 06:13 |
| ZipCPU | Do you have all the dependencies set up properly? | 06:13 |
| Ank | Yeah. Windows version is there - http://www.clifford.at/yosys/download.html | 06:14 |
| tpb | Title: Yosys Open SYnthesis Suite :: Download (at www.clifford.at) | 06:14 |
| Ank | The webpage also says - At the moment Yosys is mostly tested on Linux. | 06:14 |
| ZipCPU | This is most certainly true. | 06:14 |
| ZipCPU | I know most of the developers spend all their time on Linux. | 06:15 |
| Ank | It is working fine.. it gives out synthesized netlist.. but somehow it is not following the constraints | 06:15 |
| ZipCPU | Which constraints is yosys not following? | 06:15 |
| Ank | Like a higher clock rate synthesis.. | 06:15 |
| ZipCPU | Such as ... ? | 06:15 |
| Ank | or output pin loading | 06:15 |
| ZipCPU | yosys doesn't handle output pins ... that's handled by the placement tool. Yosys itself only does synthesis | 06:16 |
| Ank | Yeah, correct. But, will it set sufficient buffering for the pin loads or not? | 06:16 |
| Ank | there are commands where you can set the output pin loads... | 06:17 |
| Ank | during synthesis | 06:17 |
| ZipCPU | Yes/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 |
| ZipCPU | What yosys doesn't handle (well) are inout ports. | 06:17 |
| ZipCPU | I'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 |
| Ank | Now, I think that my concerns are more related to ABC | 06:19 |
| ZipCPU | If you instantiate an SB_IO primitive you get access to that capability without much hassle. | 06:19 |
| Ank | http://www.clifford.at/yosys/cmd_abc.html | 06:19 |
| tpb | Title: Yosys Open SYnthesis Suite :: Command Reference :: abc (at www.clifford.at) | 06:19 |
| Ank | there is -constr file.. in which one can set driving cell and load | 06:19 |
| ZipCPU | Most people have no need to work with abc apart from the default yosys settings. What is it you are trying to do? | 06:19 |
| Ank | then, there is -D flag with which one can set delay target.. which is linked to clock rate | 06:20 |
| ZipCPU | What hardware are you working with? | 06:20 |
| Ank | it is for ASIC | 06:20 |
| Ank | no fpga hardware | 06:20 |
| ZipCPU | Ahh ... okay. And what functionality are you hoping to get from the synthesis tool that it isn't providing? | 06:21 |
| Ank | The delault synthesized output is good for lets say 40Mhz clock.. but it is slow for 125MHz. | 06:21 |
| Ank | I want to speed up the delays in the synthesized netlist so it can clock it at higher frequencies. | 06:22 |
| ZipCPU | Are you sure that's the synthesizer's fault and not the fault of your layout? | 06:22 |
| ZipCPU | If you are sure, then ... yeah, abc might be the place to look. | 06:22 |
| Ank | Yes, not reached the layout phase yet.. just doing simulations at gate level netlist | 06:23 |
| ZipCPU | I didn't think the gate level netlist had any timing properties associated with it ... ?? | 06:23 |
| *** noname_Matt has joined #yosys | 06:24 | |
| Ank | The 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 |
| daveshah | Ank: are you sure your design is able to reach 125MHz? | 06:25 |
| Ank | These are real fooundry provided gates,, so one can so spice simulations of the synthesized netlist | 06:25 |
| Ank | one can *do | 06:26 |
| daveshah | Yeah, 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 |
| Ank | No, it is a very small core of may be 1000 gates | 06:26 |
| daveshah | If 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 |
| Ank | it can definitely do above 200MHz that I know | 06:27 |
| Ank | I must check it then on a linux platform | 06:27 |
| daveshah | So I'd say either Yosys is calling abc incorrectly for some reason, or it is a bug in abc | 06:27 |
| Ank | If anyone has faced similar problems on windows platform, then please let me know | 06:29 |
| noname_Matt | is there anywhere that goes into detail about how a pnr like arachne works? (other than reading the code itself, of course) | 06:29 |
| noname_Matt | I'm interested to know | 06:29 |
| ZipCPU | noname_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_Matt | I don't have a specific question, I just want to know more about how place and route is done. | 06:33 |
| noname_Matt | Since I know basically zilch. | 06:33 |
| ZipCPU | Let me try to describe the placer for you ... it'd be good a good exercise for me | 06:33 |
| noname_Matt | ok | 06:33 |
| ZipCPU | The 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 |
| ZipCPU | Then, 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 |
| ZipCPU | By 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 |
| ZipCPU | Feel free to check out https://github.com/cseed/arachne-pnr/blob/master/src/place.cc to see how the placement is actually done | 06:37 |
| tpb | Title: arachne-pnr/place.cc at master · cseed/arachne-pnr · GitHub (at github.com) | 06:37 |
| ZipCPU | (and whether my description is worth its salt or not .. ;) | 06:37 |
| noname_Matt | hrm. | 06:38 |
| ZipCPU | How'd I do? | 06:38 |
| noname_Matt | what do you mean by "annealing"? | 06:38 |
| ZipCPU | https://en.wikipedia.org/wiki/Simulated_annealing | 06:38 |
| tpb | Title: Simulated annealing - Wikipedia (at en.wikipedia.org) | 06:38 |
| noname_Matt | ah. this might require more sleep | 06:39 |
| ZipCPU | It'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 |
| ZipCPU | The size of the modifications are adjusted over time, starting with big adjustments, working towards little ones. | 06:39 |
| noname_Matt | I have probably goeen really good at doing the exact same thing in minecraft in 3D :) | 06:40 |
| ZipCPU | Imagine 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_Matt | I 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 enough | 06:41 |
| *** Ank has quit IRC | 06:42 | |
| ZipCPU | I'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 event | 06:42 |
| noname_Matt | I would have thought you could work out the best placement purely from the logical net itself | 06:42 |
| ZipCPU | How so? Please go on. | 06:43 |
| noname_Matt | something like get it to lay flat and pull the pieces together | 06:43 |
| ZipCPU | If you have a good idea, ... I might even try it! ;) | 06:43 |
| noname_Matt | one sec, while I find a picture | 06:43 |
| noname_Matt | http://community.wolfram.com//c/portal/getImageAttachment?filename=HilbertCurve.gif&userId=21530 | 06:45 |
| noname_Matt | reminds me of a fractal like this^ | 06:45 |
| noname_Matt | drawing one, anyway | 06:45 |
| ZipCPU | I'm looking at the picture now | 06:45 |
| noname_Matt | from 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 inbetween | 06:47 |
| ZipCPU | True, but what if multiple things want the result of that multiplexer? | 06:47 |
| ZipCPU | Then you have one output that needs to feed many inputs. | 06:47 |
| noname_Matt | there 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 ones | 06:48 |
| noname_Matt | the main issue I see with this is this sort of information might be obscured by logic sysnthesis | 06:48 |
| ZipCPU | Clocks tend to have their own networks, so ... not usually a big deal yet. | 06:48 |
| ZipCPU | As for obscured, yeah ... it is somewhat, but it shouldn't be too hard to unobscure and recapture. | 06:49 |
| noname_Matt | well, the clock is a general example, any signal that crosses from one end to the other would be like that | 06:49 |
| ZipCPU | How about a data bus? That's a good example IMHO. | 06:49 |
| noname_Matt | yeah | 06:49 |
| noname_Matt | those would be a pain | 06:49 |
| ZipCPU | Every slave connected to the bus will need a connection. | 06:49 |
| noname_Matt | that's something *you* would know has to be long and connect to lots of far away stuff, but it has a lot of wires | 06:50 |
| noname_Matt | so it would tend to pull stuff together that might not be optimal | 06:50 |
| noname_Matt | I suppose in a way I might be walking in a circle towards annealing | 06:51 |
| ZipCPU | Try this ... you can work from a FF with a clock edge to another FF with the next clock edge | 06:51 |
| noname_Matt | FF? | 06:51 |
| ZipCPU | (Flip-flop) You can measure the logic between FF's, and so measure how "long" something will take to process. | 06:52 |
| ZipCPU | Your goal would be to make sure that the longest FF chain is kept to a minimum (one-clock period) distance. | 06:52 |
| ZipCPU | Along the way, you can move FF's on this chain. | 06:52 |
| noname_Matt | when you transition from "large" to "small" changes, how do you define large and small? | 06:53 |
| ZipCPU | Logic elements that are drawn together should make it easier for other logic elements in the chain to be farther apart. | 06:53 |
| ZipCPU | Yes. | 06:53 |
| noname_Matt | is it something like moving fewer wire paths less distance, or moving larger blocks of congealed circuitry less? | 06:55 |
| ZipCPU | https://github.com/cseed/arachne-pnr/blob/master/src/place.cc#L2258-L2283 | 06:55 |
| tpb | Title: arachne-pnr/place.cc at master · cseed/arachne-pnr · GitHub (at github.com) | 06:55 |
| ZipCPU | noname_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 |
| ZipCPU | Hence, you look for better LUT placements closer and closer to the last one as time goes on. | 06:56 |
| noname_Matt | but you're always moving LUTs one at a time? | 06:57 |
| ZipCPU | In arachnepnr, yes. | 06:57 |
| ZipCPU | It 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_Matt | hrm. 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_Matt | you might still allow breaking up groups, but it would be less and less attractive to split it in half and move the two halfs apart | 07:00 |
| noname_Matt | your reasoning might be based on wire length, for example | 07:01 |
| ZipCPU | That sounds like a possible approach, but how do you know you have the groupings right? | 07:01 |
| noname_Matt | I'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 faster | 07:03 |
| ZipCPU | That is a fascinating thought. I might need to try it. :D | 07:04 |
| *** emeb_mac has quit IRC | 07:04 | |
| noname_Matt | It might be good low hanging fruit for testing this group and logical connection based approach | 07:04 |
| noname_Matt | seeing if it has any merit | 07:05 |
| noname_Matt | All 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 design | 07:06 |
| ZipCPU | Yes it might. I'm definitely going to think about it. | 07:06 |
| ZipCPU | What happens if the design elements don't really lay out in a even grid fashion? | 07:06 |
| noname_Matt | I can even "resynthsize" things a little ,(to something "logically equivalent") if I find some connections to be very inconvenient | 07:07 |
| noname_Matt | well, you will probably always have connections that will span the design | 07:07 |
| noname_Matt | crossing over stuff | 07:07 |
| noname_Matt | so it won't lay flat | 07:08 |
| noname_Matt | you 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 afterwards | 07:08 |
| noname_Matt | you 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 afterwards | 07:08 |
| noname_Matt | oops | 07:09 |
| noname_Matt | My 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 FPGS | 07:10 |
| noname_Matt | this is probably stupid though | 07:11 |
| noname_Matt | the 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 want | 07:12 |
| noname_Matt | and can group functinoality however you want | 07:12 |
| *** indy has joined #yosys | 07: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_Matt | darn. I need to break the habit discord has taught me of uparrow-ing to fix errors after the fact | 07:13 |
| ZipCPU | No, but I like your thought of grouping small things into larger things. | 07:13 |
| ZipCPU | Then moving larger things around. | 07:13 |
| noname_Matt | don't forget rotating | 07:13 |
| ZipCPU | And squishing | 07:13 |
| noname_Matt | you may need to deform a group to make it fit nicer, or rotate it, or reflect it | 07:14 |
| ZipCPU | There 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_Matt | I would take a dumb approach to that | 07:14 |
| ZipCPU | What would that approach be? | 07:14 |
| noname_Matt | if a bunch of signals are on the wrong side, flip it and remeasure the score. take the one that's lower. that sort of thing | 07:15 |
| ZipCPU | What happens if you have two puzzle pieced elements, but with the wrong connection shape? | 07:15 |
| noname_Matt | supporting deformation would be a nice goal, but for that you probably need to think about the groups inside the groups | 07:15 |
| noname_Matt | to take one example I might be able to suggest a solution for, suppose you have two groups, with an interface inbetween | 07:16 |
| * ZipCPU listens | 07:17 | |
| noname_Matt | and theres something inconvenient, like two buses that cross over each other | 07:17 |
| noname_Matt | the "smart" way I would do it, being human, would be to look at each group and look a the sub groups that generate the busses | 07:18 |
| daveshah | noname_Matt: in an FPGA architecure, I don't believe the penalty for crossing over is too great. It is total wirelength that is most important | 07:18 |
| noname_Matt | can I move one up and the other down? does this affect anything else in the toplevel group | 07:18 |
| ZipCPU | The 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_Matt | this 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 made | 07:20 |
| * ZipCPU notes that daveshah has been maintaining arachnepnr, and might know more about its functionality than ZipCPU does | 07:20 | |
| noname_Matt | this could quickly husr preformance though | 07:20 |
| noname_Matt | hurt* | 07:20 |
| noname_Matt | I suppose you'd need some sort of "to heck with it, I don't want to go any deeper" kind of thing | 07:21 |
| noname_Matt | and that limit would get stricter as the blocks get bigger | 07:21 |
| daveshah | So, is quite an interesting idea for bigger fpgas where the simple simulated annealing approach that looks at each cell is too slow | 07:22 |
| ZipCPU | I'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 work | 07:22 |
| ZipCPU | But you'll have to. | 07:22 |
| daveshah | You would probably only want to do the block based stuff early on, then do fine grained placement at individual cell level later in the placement | 07:22 |
| ZipCPU | I'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_Matt | well, I wouldn't want to spend too much, unless there was some indication I could massively reduce unpleasantness | 07:23 |
| ZipCPU | Still, this might be used to guide some initial placement decisions. | 07:23 |
| noname_Matt | I don't have a heuristic for whether something *might* reduce unpleasantness, since IRL I usually just try it and see hot it goes | 07:25 |
| noname_Matt | how* | 07:25 |
| ZipCPU | So .... you weren't trying to make a simulated annealing pun? | 07:26 |
| daveshah | noname_Matt: the heuristic arachne-pnr uses is simply total wirelength | 07:26 |
| ZipCPU | ;) | 07:26 |
| daveshah | Basically, for each wire it looks at the locations it connects to and calculates distance between them | 07:26 |
| noname_Matt | pun unintended | 07:27 |
| daveshah | But a more serious tool would configure timing information in that metric too | 07:27 |
| noname_Matt | makes sense | 07:27 |
| daveshah | Wires 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 path | 07:27 |
| daveshah | The lack of this in arachne-pnr means its timing values are quire unpredictable and maybe 30% worse than a timing driven tool | 07:28 |
| noname_Matt | sadly, I think a lot of useful information is lost in synthesis regarding what paths are and are not timing-critical | 07:28 |
| daveshah | No, definitely not | 07:28 |
| noname_Matt | you may have long paths (ie debugging) for which it's not super important | 07:29 |
| daveshah | These will still ruin your day if they don't meet timing though | 07:29 |
| daveshah | Unless they're just straight to IO without going through registers | 07:29 |
| daveshah | In either case, a proper tool would let you add constraints to ignore these paths if you really want | 07:30 |
| daveshah | And manually constraint other things that are needed | 07:30 |
| noname_Matt | perhaps I have an overly simplistic understanding of synthesis | 07:30 |
| *** ZipCPU has quit IRC | 07:31 | |
| noname_Matt | still, 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 structured | 07:33 |
| noname_Matt | ideally, receiving a tree where each level is logically equivalent | 07:33 |
| noname_Matt | but the top is the design as the human sees it, and at the bottom are just LUTs | 07:33 |
| awygle | also, 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 |
| daveshah | noname_Matt: that is what you get if you would synthesise a design without flattening | 07:34 |
| daveshah | But then that precludes a number of synthesis optimisations | 07:34 |
| noname_Matt | you might be able to work with some intermediate: apply the operations and don't care that it might mess up your tagging | 07:35 |
| daveshah | Yes, that's how you'd have to do it | 07:36 |
| daveshah | awygle: one possibility with that is to determine a function based on a large number of designs between distance and delay | 07:36 |
| daveshah | This would probably give a better heuristic to determine delay than just distance based measures as are used at the moment, without excessive performance cost | 07:37 |
| awygle | yes, a straightforward "Manhattan distance to delay" approach is common | 07:37 |
| awygle | it's fast as it's just a table lookup | 07:38 |
| awygle | at 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 whatnot | 07:38 |
| daveshah | Interesting | 07:39 |
| daveshah | I 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 budget | 07:40 |
| noname_Matt | That's the kind of scenario I imagine shifting whole blocks of LUTs over might be helpful | 07:41 |
| awygle | That'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 decay | 07:42 |
| awygle | But I'd have to dig it up | 07:42 |
| awygle | But yes in general by breaking the problem into phases we get worse results (but more tractable problems of course) | 07:42 |
| awygle | Ideally 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 |
| daveshah | Yes, that would also be needed for doing stuff like cell duplication for high fan out but simple logic | 07:44 |
| awygle | Yup. It's an interesting set of problems even before you bring in parallelism. Anyway :-P it's after midnight here. Goodnight! | 07:45 |
| noname_Matt | Is 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 | |
| daveshah | Yeah, that's the idea | 07:46 |
| daveshah | The most basic example would be a source of constant '1' (single logic cell) on an architecure without constant generators | 07:46 |
| noname_Matt | seems there's a long list of features an arch may or may not have | 07:47 |
| noname_Matt | and then there's the arch of the actual cells and connections | 07:48 |
| *** indy has quit IRC | 07:48 | |
| noname_Matt | I can see why trying to build a generalized *anything* is hard | 07:48 |
| daveshah | So the idea would be to have generic place and route functions call into architecure specific functions | 07:48 |
| daveshah | Some stuff, like design legalisation, validity checking and most of packing, is architecure specific | 07:49 |
| noname_Matt | are there any multiarch PnRs? | 07:49 |
| daveshah | Packing actually tends to be vendor rather than architecure specific because most vendors have similar or identical logic cells used in many architectures | 07:49 |
| daveshah | There is VPR, but it is primarily intended for virtual architectures and getting it to work on real FPGAs is quite hard | 07:50 |
| noname_Matt | I think I head about that :) | 07:50 |
| daveshah | NeoCAD is a commercial PnR that underpins Lattice Diamond and Xilinx ISE | 07:50 |
| *** indy has joined #yosys | 07:50 | |
| daveshah | But no idea how similar the code base is between the two now, they diverged in the late 90s | 07:51 |
| noname_Matt | That's a long time ago | 07:51 |
| * noname_Matt was born around then | 07:51 | |
| daveshah | Same... | 07:51 |
| daveshah | Would love to mention a few more things now, unfortunately I can't. | 07:51 |
| *** indy has quit IRC | 08:01 | |
| *** _whitelogger has quit IRC | 08:28 | |
| *** _whitelogger has joined #yosys | 08:30 | |
| *** eduardo_ has joined #yosys | 08:48 | |
| *** eduardo has quit IRC | 08:51 | |
| *** dys has joined #yosys | 08:59 | |
| *** jwhitmore has joined #yosys | 09:13 | |
| *** indy has joined #yosys | 09:14 | |
| *** eduardo_ has quit IRC | 10:14 | |
| *** xerpi has quit IRC | 10:20 | |
| *** dys has quit IRC | 10:31 | |
| *** eduardo_ has joined #yosys | 10:49 | |
| *** eduardo_ has quit IRC | 10:56 | |
| *** ZipCPU has joined #yosys | 11:05 | |
| *** eduardo_ has joined #yosys | 11:14 | |
| mjoldfield | Having flattened the design, can you recover/infer good blocks by doing a minimum k-cut on the connectivity graph ? | 11:34 |
| ZipCPU | What 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 |
| mjoldfield | Yes. | 11:37 |
| ZipCPU | Ok, 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 |
| mjoldfield | In 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 | |
| mjoldfield | https://en.wikipedia.org/wiki/Minimum_k-cut | 11:39 |
| tpb | Title: Minimum k-cut - Wikipedia (at en.wikipedia.org) | 11:39 |
| ZipCPU | Ooohh ... fascinating | 11:39 |
| mjoldfield | It's a generalization of https://en.wikipedia.org/wiki/Minimum_cut | 11:39 |
| tpb | Title: Minimum cut - Wikipedia (at en.wikipedia.org) | 11:39 |
| mjoldfield | I 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 |
| ZipCPU | I 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 #yosys | 11:59 | |
| *** gyroninja has quit IRC | 12:05 | |
| *** AlexDaniel has quit IRC | 12:32 | |
| *** promach_ has joined #yosys | 12:36 | |
| mjoldfield | I hope it's helpful. Let me know if you get anywhere. | 12:36 |
| *** pie_ has joined #yosys | 12:47 | |
| *** pie__ has joined #yosys | 13:08 | |
| *** pie_ has quit IRC | 13:08 | |
| *** digshadow has quit IRC | 13:20 | |
| *** m_w has quit IRC | 13:57 | |
| *** m_w has joined #yosys | 13:58 | |
| *** pie__ has quit IRC | 14:00 | |
| *** gyroninja has joined #yosys | 14:10 | |
| *** digshadow has joined #yosys | 14:13 | |
| *** pie__ has joined #yosys | 14:27 | |
| *** leviathan has quit IRC | 14:36 | |
| *** leviathan has joined #yosys | 14:43 | |
| promach_ | do we need to manually specify all the source files in the sby file such as https://github.com/ZipCPU/zipcpu/blob/dev/bench/formal/zipcpu.sby#L67-L81 ? does SymbiYosys support wildcard (../rtl/*.v) file selection yet ? | 14:48 |
| tpb | Title: zipcpu/zipcpu.sby at dev · ZipCPU/zipcpu · GitHub (at github.com) | 14:48 |
| ZipCPU | Why should SymbiYosys support wildcard selection? | 14:49 |
| promach_ | read_verilog also needs to be repeated besides the files section | 14:51 |
| ZipCPU | That 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 |
| ZipCPU | For example, read_verilog -D ZIPCPU -formal fwb_counter.v | 14:52 |
| ZipCPU | Or read_verilog -D ZIPCPU -DPHASE_TWO -formal zipcpu.v | 14:52 |
| promach_ | -D ?? | 14:52 |
| ZipCPU | Just like with GCC, it specifies a synthesis directive. Inside zipcpu, I have things like `ifdef ZIPCPU or `ifdef PHASE_TWO | 14:53 |
| *** xerpi has joined #yosys | 15:09 | |
| promach_ | ZipCPU: why don't you have "opt_merge -share_all" in your sby file ? | 15:19 |
| ZipCPU | Sometimes it helps, sometimes it doesn't. | 15:20 |
| promach_ | what / | 15:31 |
| promach_ | ? | 15:31 |
| ZipCPU | Sometimes it helps, sometimes it doesn't. | 15:31 |
| promach_ | I do not understand why | 15:31 |
| ZipCPU | I started taking it out following an update of yosys where it didn't seem to support that functionality anymore. | 15:32 |
| ZipCPU | Since that time, I've discovered the problem was operator error, not tool changes. | 15:32 |
| *** pie_ has joined #yosys | 15:33 | |
| *** pie__ has quit IRC | 15:33 | |
| *** pie_ has quit IRC | 16:06 | |
| *** pie_ has joined #yosys | 16:11 | |
| *** digshadow has quit IRC | 16:12 | |
| * noname_Matt reboots | 16:12 | |
| noname_Matt | insert coffee~~~~ | 16:12 |
| noname_Matt | k-cut certainly seems interesting. might be a good fit for what I had in mind | 16:14 |
| *** AlexDaniel has joined #yosys | 16:18 | |
| *** AlexDaniel has quit IRC | 16:52 | |
| *** AlexDaniel has joined #yosys | 16:52 | |
| *** promach_ has quit IRC | 17:21 | |
| *** digshadow has joined #yosys | 18:00 | |
| *** xerpi has quit IRC | 18:08 | |
| *** sklv has quit IRC | 18:17 | |
| *** sklv has joined #yosys | 18:18 | |
| *** ZipCPU|ztop has joined #yosys | 18:20 | |
| *** ZipCPU has quit IRC | 18:20 | |
| *** pie_ has quit IRC | 19:03 | |
| *** pie_ has joined #yosys | 19:22 | |
| *** leviathan has quit IRC | 19:39 | |
| *** digshadow has quit IRC | 19:40 | |
| *** digshadow has joined #yosys | 19:46 | |
| *** digshadow has quit IRC | 19:49 | |
| *** ZipCPU|ztop has quit IRC | 19:53 | |
| *** eduardo_ has quit IRC | 19:54 | |
| *** eduardo_ has joined #yosys | 19:58 | |
| *** xerpi has joined #yosys | 20:30 | |
| *** xerpi has joined #yosys | 20:31 | |
| *** emeb_mac has joined #yosys | 20:50 | |
| *** emeb_mac has quit IRC | 21:28 | |
| *** brandonz has joined #yosys | 21:52 | |
| *** xerpi has quit IRC | 22:05 | |
| *** eduardo__ has joined #yosys | 22:23 | |
| *** m_w has quit IRC | 22:23 | |
| *** eduardo_ has quit IRC | 22:26 | |
| noname_Matt | What'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 IRC | 22:36 | |
| *** danieljabailey has quit IRC | 23:04 | |
| *** danieljabailey has joined #yosys | 23:04 | |
| *** jwhitmore has quit IRC | 23:24 | |
| *** digshadow has joined #yosys | 23:38 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
