| *** tpb has joined #yosys | 00:00 | |
| *** ZirconiumX has quit IRC | 00:25 | |
| *** rohitksingh has joined #yosys | 00:49 | |
| *** citypw has joined #yosys | 01:47 | |
| *** citypw has quit IRC | 02:52 | |
| *** citypw has joined #yosys | 03:49 | |
| *** MoeIcenowy has quit IRC | 05:28 | |
| *** MoeIcenowy has joined #yosys | 05:28 | |
| *** Jybz has joined #yosys | 05:56 | |
| *** Jybz has quit IRC | 06:19 | |
| *** m4ssi has joined #yosys | 06:30 | |
| Xiretza | daveshah: confirmed, thank you! | 07:32 |
|---|---|---|
| *** strongsaxophone has joined #yosys | 07:58 | |
| *** marex-cloud has joined #yosys | 08:30 | |
| *** dys has joined #yosys | 08:40 | |
| *** develonepi3 has quit IRC | 08:57 | |
| *** kraiskil has joined #yosys | 08:58 | |
| mwk | daveshah: btw, xilinx sometimes packs even a LUT5 and LUT6 together if the bits align just right | 09:00 |
| mwk | and such a thing can drive a MUXF tree | 09:00 |
| daveshah | Yup, it was just an issue with the MUX output contention | 09:01 |
| mwk | I've seen such a thing in ISE output, they use the primary FF in always-enabled latch mode to route out of that mess | 09:01 |
| daveshah | Ah, I haven't implemented that yet but Vivado does that too | 09:01 |
| daveshah | The time I saw that I think it was actually to legalise a carry output | 09:01 |
| mwk | yes | 09:01 |
| mwk | that as well | 09:01 |
| mwk | with carry there's no way around that | 09:02 |
| mwk | well, there is, but not without lengthtening the carry chain or other contortions | 09:02 |
| *** kraiskil has quit IRC | 09:03 | |
| daveshah | Indeed - I do the former in nextpnr-xilinx but using the latch mode might be a better option | 09:03 |
| mwk | I use the latch mode in nextpnr-leuctra | 09:03 |
| mwk | (we need to sit down at some point and merge all this mess into a single unified target... preferably when I've had a proper night of sleep) | 09:04 |
| daveshah | Yes | 09:04 |
| daveshah | The problem is the lack of a deduplicated db for UltraScale atm | 09:04 |
| mwk | I can arrange that | 09:04 |
| mwk | I mean, I don't have one yet, but I can produce one in a week or two | 09:05 |
| daveshah | Right, there is also the question of timing, for xc7 I pull timing out of Xray and I want to do similar with xcup | 09:06 |
| daveshah | (from RapidWright in that case) | 09:06 |
| mwk | I'll be looking into timing extraction soon as well | 09:06 |
| mwk | no guarantees about that one though | 09:06 |
| daveshah | The primitive sets used are slightly different but that should be unifiable | 09:06 |
| daveshah | We can always just keep the xc7/xcup packing separate to start with | 09:06 |
| daveshah | from the leuctra packing | 09:06 |
| daveshah | just harmonise the database | 09:06 |
| mwk | actually I really thing we should merge them | 09:07 |
| mwk | well, the slice packing at least | 09:07 |
| mwk | I/O is a vastly different beast | 09:07 |
| mwk | xc6s slice is much closer to xc7 slice than xc7 is to ultrascale | 09:07 |
| mwk | basically just one fewer mux than xc7 (the secondary FF is perma-connected to LUT's O5 output) | 09:08 |
| daveshah | Yes, for xc7 at least | 09:08 |
| daveshah | For xcup I'd also need to do some work on the rapidwright side to split the larger primitives you've used | 09:08 |
| mwk | you mean, split up LEUCTRA_LC into LUTs/MUXs/CARRY4s? | 09:09 |
| daveshah | Yes, those are the primitives nextpnr-xilinx uses | 09:09 |
| mwk | it's kind of the opposite of what I'm doing in the post-processing step, ise really wants a SLICE* as a whole | 09:10 |
| daveshah | Right | 09:10 |
| mwk | (and my bitstream database also deals with whole slices as a unit, there's just too many common bits) | 09:10 |
| daveshah | The fasm backend will probably need some changes for the different db and slice structure but that shouldn't be so bad | 09:12 |
| daveshah | It all sounds fairly doable particularly if we keep BRAM and IO separate | 09:12 |
| mwk | BRAM packing will not really be a thing with -leuctra backend | 09:13 |
| daveshah | No, it's not so much packing as things like rewriting write enables | 09:14 |
| mwk | it should just go through the generic path for random primitives that just need to be passed through with minor changes | 09:14 |
| mwk | oh, xc7 needs that? | 09:14 |
| daveshah | Yes quite a bit of that | 09:14 |
| mwk | xc6s dumps most of this stuff on the synthesis tool | 09:14 |
| daveshah | Also connecting to both lower and upper signals for the 36 size primitives | 09:14 |
| daveshah | It's code that can just copy across from nextpnr-xilinx though | 09:14 |
| mwk | it actually tells you in the HDL library document exactly which signals you're supposed to tie how | 09:14 |
| mwk | also uhh | 09:15 |
| mwk | you know that xc7 support is in scope for nextpnr-leuctra as well, right? :p | 09:15 |
| daveshah | Yes, I do, that's why we are planning to merge to two | 09:15 |
| daveshah | *the two | 09:15 |
| mwk | good | 09:15 |
| daveshah | I've got most of these annoying things debugged now | 09:16 |
| mwk | (current status is that leuctra bitgen supports only xc3se and xc6s though; other stuff may need to wait a bit for the big rewrite) | 09:16 |
| *** kraiskil has joined #yosys | 09:16 | |
| daveshah | Yes, we can just use the fasm backend for prjxray bitgen for now anyway | 09:17 |
| daveshah | That was another very annoying thing but should port across OK | 09:17 |
| daveshah | Mostly just slice structure changes | 09:17 |
| *** X-Scale` has joined #yosys | 09:20 | |
| *** X-Scale has quit IRC | 09:20 | |
| *** X-Scale` is now known as X-Scale | 09:20 | |
| *** rohitksingh has quit IRC | 09:23 | |
| mwk | alright, in any case | 09:24 |
| mwk | I'll be busy with unrelated stuff this week | 09:24 |
| mwk | then I'll have some time to figure out the new db format (there are a couple issues with my current one that I really need to solve first; first and foremost the issue of alias pips) | 09:25 |
| mwk | right now I represent all inter-tile connections as bidirectional pips on the edges, which is not a great idea | 09:26 |
| daveshah | So I think I might continue with the short term plan to upstream the current nextpnr-xilinx for xc7 and xcup, even though this will be replaced by the leuctra db in the long term | 09:27 |
| mwk | for one, it can result in unsound routing when there are wires that can be driven from multiple directions... xc6s doesn't have those, but every single other xilinx family does | 09:27 |
| daveshah | Yes, the slice 'X' wires if nothing else | 09:28 |
| mwk | uh? | 09:28 |
| daveshah | iirc anyway | 09:28 |
| daveshah | Oh no I'm thinking of something else | 09:28 |
| mwk | no, I mean the long lines | 09:28 |
| mwk | which you can drive from top or bototm | 09:28 |
| mwk | (or, on some families, from the middle) | 09:28 |
| daveshah | One option would just be to have getPipsUphill etc iterate over all "neighbourhood" wires | 09:29 |
| mwk | yep | 09:29 |
| daveshah | That's basically what nextpnr-xilinx does | 09:29 |
| mwk | but it also requires having a unique WireId for a given node | 09:29 |
| mwk | unique canonical one | 09:29 |
| daveshah | Indeed, because nextpnr-xilinx doesn't deduplicate intertile nodes (only tile wires, pips and sites) this if fairly easy | 09:31 |
| mwk | right | 09:31 |
| mwk | so we need to figure how to approach it for deduplication | 09:32 |
| daveshah | I had to do some special casings of globals to get it to work well, but in the nexus arch that I'm working on I'm playing about with the concept of neighbourhoods | 09:34 |
| daveshah | Instead of just considering connections to adjacent neighbours I consider neighbours to be all other tiles that a tile has connection | 09:34 |
| daveshah | Then store the mappings for each set of possible "neighbourhoods" for a tile type separately | 09:35 |
| mwk | you mean, directly and indirectly? | 09:35 |
| daveshah | This works fairly well for something simple like CrossLink NX but might need more special casing for Xilinx with all the different long connections | 09:35 |
| mwk | yes | 09:35 |
| daveshah | Any nodal connection | 09:35 |
| daveshah | Lattice don't really have a concept of tile wires, only nodes, so I kind of do the splitting up myself | 09:37 |
| *** fsasm has joined #yosys | 09:56 | |
| *** az0re has quit IRC | 11:18 | |
| *** ZirconiumX has joined #yosys | 11:25 | |
| *** develonepi3 has joined #yosys | 11:37 | |
| strongsaxophone | is it possible to draw module level schematic with yosys? (not gate level like the example in the yosys documentation) | 12:02 |
| daveshah | Yes, this will happen if you don't use flatten in your flow (something like proc; hierarchy; show top) | 12:07 |
| daveshah | It won't be very pretty though | 12:07 |
| strongsaxophone | Okay, Thank you. | 12:12 |
| *** attie has quit IRC | 12:17 | |
| *** attie has joined #yosys | 12:17 | |
| strongsaxophone | daveshah: I got amazed with the result. Its fantastic. | 12:18 |
| ZirconiumX | ABC9 seems to be having major issues with my synthesis script and I don't understand why | 12:33 |
| ZirconiumX | ...Oh, I see why. Nevermind | 12:37 |
| *** m4ssi has quit IRC | 13:12 | |
| *** emeb has joined #yosys | 14:27 | |
| *** strongsaxophone has quit IRC | 14:50 | |
| *** citypw has quit IRC | 14:51 | |
| *** MoeIcenowy has quit IRC | 15:03 | |
| *** MoeIcenowy has joined #yosys | 15:04 | |
| *** citypw has joined #yosys | 15:08 | |
| *** C-M has joined #yosys | 15:20 | |
| *** citypw has quit IRC | 15:21 | |
| *** az0re has joined #yosys | 15:35 | |
| *** ZipCPU has quit IRC | 15:37 | |
| *** Forty-Bot has quit IRC | 15:42 | |
| *** ZipCPU has joined #yosys | 16:00 | |
| *** pepijndevos[m] has joined #yosys | 17:01 | |
| *** fsasm has quit IRC | 17:13 | |
| *** kraiskil has quit IRC | 17:16 | |
| *** rohitksingh has joined #yosys | 17:18 | |
| *** dys has quit IRC | 17:39 | |
| *** klotz has joined #yosys | 18:00 | |
| *** klotz has quit IRC | 18:10 | |
| *** pointfree has quit IRC | 18:47 | |
| *** pointfree has joined #yosys | 18:48 | |
| *** m_w has joined #yosys | 19:24 | |
| *** pointfree has quit IRC | 19:41 | |
| *** m_w has quit IRC | 19:56 | |
| *** Jybz has joined #yosys | 20:15 | |
| *** Jybz has quit IRC | 20:28 | |
| *** dys has joined #yosys | 20:39 | |
| *** rohitksingh has quit IRC | 20:42 | |
| *** strongsaxophone has joined #yosys | 20:46 | |
| *** strongsaxophone has quit IRC | 20:56 | |
| *** rohitksingh has joined #yosys | 21:04 | |
| *** rohitksingh has quit IRC | 21:20 | |
| *** rohitksingh has joined #yosys | 21:28 | |
| *** rohitksingh has quit IRC | 21:38 | |
| *** rohitksingh has joined #yosys | 21:43 | |
| *** kraiskil has joined #yosys | 22:01 | |
| *** rohitksingh has quit IRC | 22:19 | |
| *** pointfree has joined #yosys | 23:03 | |
| *** dys has quit IRC | 23:15 | |
| *** kraiskil has quit IRC | 23:50 | |
| *** develonepi3 has quit IRC | 23:55 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!