| *** tpb has joined #yosys | 00:00 | |
| *** emeb has quit IRC | 00:03 | |
| ross_s | Created this PR, based on how I currently understand the registers to affect the timing https://github.com/YosysHQ/nextpnr/pull/435 | 00:07 |
|---|---|---|
| tpb | Title: Alter MULT18X18D timing db based on register config by rschlaikjer · Pull Request #435 · YosysHQ/nextpnr · GitHub (at github.com) | 00:07 |
| *** Vinalon_ has quit IRC | 00:34 | |
| *** Vinalon has joined #yosys | 01:07 | |
| *** adjtm_ has quit IRC | 01:16 | |
| *** adjtm has joined #yosys | 01:16 | |
| *** adjtm has quit IRC | 01:18 | |
| *** adjtm has joined #yosys | 01:20 | |
| *** Vinalon has quit IRC | 01:51 | |
| *** craigo has joined #yosys | 03:19 | |
| *** Degi has quit IRC | 03:55 | |
| *** Degi has joined #yosys | 03:58 | |
| *** lambda has quit IRC | 04:23 | |
| *** lambda has joined #yosys | 04:30 | |
| *** mwalle has quit IRC | 04:41 | |
| *** pie_[bnc] has quit IRC | 06:08 | |
| *** pie_[bnc] has joined #yosys | 06:17 | |
| *** emeb_mac has quit IRC | 06:30 | |
| *** az0re has joined #yosys | 06:37 | |
| *** citypw has quit IRC | 07:31 | |
| *** dys has joined #yosys | 07:35 | |
| *** jakobwenzel has joined #yosys | 07:40 | |
| *** Asu has joined #yosys | 08:21 | |
| *** adjtm has quit IRC | 08:33 | |
| *** craigo has quit IRC | 09:01 | |
| *** m4ssi has joined #yosys | 10:09 | |
| *** adjtm has joined #yosys | 10:11 | |
| *** adjtm has quit IRC | 10:51 | |
| *** adjtm has joined #yosys | 10:52 | |
| *** anuejn_ has joined #yosys | 11:19 | |
| *** yosys-questions has quit IRC | 11:38 | |
| *** keith-man has quit IRC | 11:54 | |
| *** Nazara has quit IRC | 13:14 | |
| *** Nazara has joined #yosys | 13:15 | |
| *** N2TOH has quit IRC | 14:11 | |
| *** N2TOH has joined #yosys | 14:14 | |
| *** N2TOH_ has joined #yosys | 14:18 | |
| *** N2TOH has quit IRC | 14:22 | |
| *** emeb has joined #yosys | 14:31 | |
| *** N2TOH_ has quit IRC | 14:41 | |
| *** N2TOH has joined #yosys | 14:41 | |
| *** N2TOH_ has joined #yosys | 14:44 | |
| *** N2TOH has quit IRC | 14:46 | |
| *** jfcaron_ has joined #yosys | 14:54 | |
| *** craigo has joined #yosys | 15:10 | |
| ross_s | daveshah: thanks for the feedback on the PR. I've updated the getPortTimingClass section, but when verifying the change to getPortClockingInfo I never actually seem to hit my cell->type == id_MULT18X18D check, even though I have one directly instantiated. Is there some other mechanism that causes this check to be skipped? | 15:10 |
| ross_s | (this check = getPortClockingInfo call) | 15:12 |
| daveshah | ross_s: you need to set clockInfoCount | 15:13 |
| ross_s | aha | 15:13 |
| ross_s | should it be one if any clocks are detected, or to the number of distinct clocks? It looks like the mult can have up to 4 | 15:14 |
| daveshah | The number of clock edges affecting a pin | 15:14 |
| daveshah | While it is true this could be up to 4 for a DSP | 15:14 |
| daveshah | for now the common case of a single clock is enough imo | 15:14 |
| ross_s | ok, sounds good | 15:15 |
| daveshah | (Technically up to 8 in fact if you used the DSPs in DDR mode but even Diamond doesn't officially support this...) | 15:15 |
| ross_s | interesting | 15:15 |
| ross_s | also, do you happen to know of any good resources on the ecp5 dsp internals? I've been trying to grok some of the diamond generated code and it seems to involve both the parallel in/out and shift register in/out, but TN1267 doesn't elaborate much on how the shift setup works | 15:17 |
| daveshah | No, there aren't any | 15:19 |
| daveshah | Looking at the sim models is the only option | 15:20 |
| daveshah | but I've never actually looked into the shift register stuff | 15:20 |
| ross_s | Baffling that there is no documentation. How do Diamond users get by? Just plugging in autogenerated black boxes? | 15:20 |
| tnt | Yeah, I think you're supposed to use the clarity designer ... | 15:21 |
| tnt | Compared to the detailled docs of the ice40 (on the lower end) or the 7-series (on the upper end), the ecp5 dsp docs are definitely lacking. | 15:21 |
| daveshah | I think the assumption, sadly incorrect, is anyone doing complex DSP stuff has access to a Lattife FAE | 15:23 |
| daveshah | *Lattice | 15:23 |
| ross_s | I guess sim models it is then. Though, do you have to have a non-free license to generate those? I was testing out diamond yesterday and it wouldn't deign to open the simulation wizard | 15:24 |
| daveshah | You can just look at the Verilog all the DSP related stuff isn't encrypted | 15:24 |
| daveshah | in the cae_library folder of the install | 15:25 |
| *** jfcaron_ is now known as jfcaron | 15:25 | |
| ross_s | good to know. hopefully I can use those for verliator as well | 15:26 |
| daveshah | No, they use a load of sim stuff that probably breaks in Verilog | 15:27 |
| daveshah | should work in icarus though | 15:27 |
| daveshah | s/Verilog/Verilator | 15:27 |
| tnt | daveshah: did you ever try the ice40 models in iverilog ? I couldn't get them to run. | 15:29 |
| daveshah | No, I've tried the ECP5 RAM and IO models in the past and they've worked though | 15:30 |
| daveshah | don't know about the DSPs | 15:30 |
| daveshah | I think part of the Yosys testing involved running the SB_MAC16 model in iverilog and that worked fine | 15:31 |
| *** dys has quit IRC | 15:57 | |
| *** yosys-questions has joined #yosys | 15:59 | |
| *** jakobwenzel has quit IRC | 16:08 | |
| ross_s | hmm it looks like the timing db might be a bit sparse for the mult18x18 | 16:08 |
| ross_s | it only has a timing for CLK0 -> P | 16:08 |
| ross_s | whereas the dp16kd has timings for both clocks to each output pin | 16:09 |
| ross_s | so currently when I call getDelayFromTimingDatabase for CLK0 and P35, it fails | 16:09 |
| ross_s | since it can only handle the call CLK0, P | 16:09 |
| ross_s | is the better approach here to expand the timing db, or try and do some ID rewriting before calling getDelay? | 16:10 |
| daveshah | You would need to do some rewriting | 16:30 |
| daveshah | This was done to stop the database from getting too massive | 16:30 |
| daveshah | particularly once all timings are considered | 16:30 |
| *** jfcaron_ has joined #yosys | 16:41 | |
| *** jfcaron has quit IRC | 16:45 | |
| ross_s | alright, can work with that. | 16:53 |
| emeb | getting an interesting error from nextpnr-ice40: ERROR: JSON module blackbox attribute value is not a number | 16:53 |
| daveshah | Sounds perhaps like old next nextpnr and new yosys, or vice versa? | 16:55 |
| emeb | Yosys 0.9+1706 (git sha1 036c46de, clang 8.0.0 -fPIC -Os) + nextpnr-ice40 -- Next Generation Place and Route (git sha1 8f28132) | 16:55 |
| daveshah | Try updating nextpnr | 16:57 |
| emeb | Will do. Thanks. | 16:57 |
| emeb | Hmm... that didn't fix it. | 17:05 |
| emeb | Will try updating Yosys | 17:05 |
| emeb | Updating yosys and nextpnr did not fix this | 17:27 |
| emeb | Yosys 0.9+2406 (git sha1 a66200ed, clang 8.0.0 -fPIC -Os) + nextpnr-ice40 -- Next Generation Place and Route (git sha1 5c6b2cba) | 17:28 |
| emeb | OK - this appears to be a design that has never really worked in the yosys / nextpnr flow for up5k. It's got a bunch of hairy DSP stuff in it (multiplier inferences and huge adder trees) | 17:30 |
| daveshah | It still shouldn't be failing this way... | 17:31 |
| emeb | here's the nextpnr cmd: nextpnr-ice40 --up5k --json rxadc_14.json --pcf ../src/rxadc_14.pcf --asc rxadc_14.asc | 17:32 |
| daveshah | Looks fine | 17:34 |
| daveshah | what does `grep blackbox rxadc_14.json` give? | 17:34 |
| emeb | a whole lot of lines of this form -> "blackbox": "00000000000000000000000000000001", | 17:39 |
| daveshah | That sounds fine | 17:41 |
| emeb | I can send a testcase as zipfile if that would be of any interest | 17:47 |
| daveshah | Yes please, thanks | 17:48 |
| emeb | https://www.dropbox.com/s/4sd5898r3bpvza3/emeb_testcase_04-29-20.zip?dl=0 | 17:48 |
| tpb | Title: Dropbox - emeb_testcase_04-29-20.zip - Simplify your life (at www.dropbox.com) | 17:48 |
| daveshah | Seems to build fine here | 17:52 |
| emeb | Very interesting | 17:52 |
| daveshah | Are you sure you installed latest nextpnr-ice40? | 17:53 |
| emeb | I'll try rebuilding from a fresh git clone | 17:53 |
| emeb | previously just did a make clean / git pull / | 17:53 |
| ross_s | daveshah: I think I'm about done here, but have one question about how exactly the registers work - currently, I separately mark A/B/P as registered or not based on the register clock setting. 1) Is that definitely the parameter that sets whether they are registered? and 2) Is it correct to have a mixed comb & register timing, or should _any_ registered input mark _all_ IOs as registered? | 17:55 |
| daveshah | 1) yes as far as I know | 17:56 |
| daveshah | 2) mixed is fine, but any register means it is counted as registered in the port class | 17:57 |
| *** Nazara has quit IRC | 18:00 | |
| *** Nazara has joined #yosys | 18:02 | |
| emeb | daveshah: OK - did a clean build of nextpnr and it works here now. Thanks and sorry for the low SNR | 18:03 |
| ross_s | so, should the timing db then be regs=input if (a_clk != none || b_clk != none) as opposed to (a_clk != none && b_clk != none)? | 18:03 |
| ross_s | or, in the event that only one of a/b is registered, say that both of them are not | 18:04 |
| daveshah | Yes, if you want to be strictly correct then you would need to mix and match between regs=input and no regs | 18:04 |
| ross_s | hmm ok | 18:04 |
| daveshah | If you only want to support both or none being registered and warn on the unsupported mixed possibility, I don't mind that either | 18:06 |
| *** klotz has joined #yosys | 18:41 | |
| ross_s | Alright; this ended up involving a lot more false starts than I expected but I _think_ this is now correct https://github.com/YosysHQ/nextpnr/pull/435/files | 18:53 |
| tpb | Title: Alter MULT18X18D timing db based on register config by rschlaikjer · Pull Request #435 · YosysHQ/nextpnr · GitHub (at github.com) | 18:53 |
| ross_s | In the case where A/B have different clock modes it issues a warning and treats both as not registered | 18:54 |
| daveshah | Thanks, I'll have a proper look tomorrow | 18:58 |
| *** klotz has quit IRC | 18:58 | |
| daveshah | I was in a similar situation with the ALU54B, seems that the bitstream data isn't complete for the cascade configuration | 18:59 |
| ross_s | I guess these are less commonly used features for FOSS designs | 19:02 |
| ross_s | which makes sense given that you don't get to know how they work outside clarity designer | 19:02 |
| daveshah | Yeah, I got a bit bored half way through the original DSP fuzzing work last year | 19:06 |
| daveshah | it was hard to work out what was even supposed to work together | 19:06 |
| *** yosys-questions has quit IRC | 20:03 | |
| *** yosys-questions has joined #yosys | 20:16 | |
| *** m4ssi has quit IRC | 20:34 | |
| *** N2TOH_ has quit IRC | 20:37 | |
| *** N2TOH has joined #yosys | 20:38 | |
| *** N2TOH has quit IRC | 21:26 | |
| *** N2TOH has joined #yosys | 21:28 | |
| *** yosys-questions has quit IRC | 21:34 | |
| *** N2TOH has quit IRC | 21:35 | |
| *** N2TOH has joined #yosys | 21:50 | |
| *** N2TOH has quit IRC | 21:55 | |
| *** jfcaron_ has quit IRC | 21:57 | |
| *** Cerpin has quit IRC | 22:00 | |
| *** Cerpin has joined #yosys | 22:09 | |
| *** N2TOH has joined #yosys | 22:32 | |
| *** Thorn has quit IRC | 22:38 | |
| *** N2TOH has quit IRC | 22:44 | |
| *** N2TOH has joined #yosys | 22:46 | |
| *** N2TOH has quit IRC | 22:51 | |
| *** N2TOH has joined #yosys | 23:01 | |
| *** X-Scale` has joined #yosys | 23:03 | |
| *** N2TOH has quit IRC | 23:06 | |
| *** X-Scale has quit IRC | 23:06 | |
| *** X-Scale` is now known as X-Scale | 23:06 | |
| *** Asu has quit IRC | 23:06 | |
| *** N2TOH has joined #yosys | 23:09 | |
| *** N2TOH has quit IRC | 23:16 | |
| *** N2TOH has joined #yosys | 23:20 | |
| *** emeb has quit IRC | 23:56 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!