| *** tpb has joined #yosys | 00:00 | |
| *** kuldeep has joined #yosys | 00:11 | |
| *** kuldeep has quit IRC | 00:34 | |
| mwk | what's a reasonable way to cause an elaboration-time error for invalid parameter values? (I'm writing more simulation models for xilinx/cells_sim.v and would like to add some armor plating) | 00:34 |
|---|---|---|
| *** kuldeep has joined #yosys | 00:37 | |
| *** citypw has joined #yosys | 03:32 | |
| ZipCPU | An initial block with a $stop command in it | 03:34 |
| *** citypw has quit IRC | 05:04 | |
| *** Jybz has joined #yosys | 05:23 | |
| *** Jybz has quit IRC | 05:29 | |
| *** nrossi has joined #yosys | 06:40 | |
| *** citypw has joined #yosys | 06:45 | |
| *** emeb_mac has quit IRC | 07:04 | |
| *** dys has joined #yosys | 07:40 | |
| pepijndevos | I think I have lived with a confusion of what GENERIC_IOB considers an input or an output. | 07:58 |
| *** kraiskil has joined #yosys | 07:59 | |
| pepijndevos | daveshah, soooo GENERIC_IOB O is the output of the input buffer, and I is the input to the output buffer. But is INPUT_USED supposed to indicate that the Input buffer is used, or that the input pin of the output buffer is used? | 08:24 |
| pepijndevos | Seems the latter | 08:27 |
| daveshah | INPUT_USED was supposed to mean it is used as an input | 08:35 |
| daveshah | ie the O pin is used | 08:35 |
| daveshah | Maybe I messed this up | 08:35 |
| pepijndevos | Yea, it seems the other way around. I was creating input pins for my blinky LEDs hehe | 08:41 |
| *** citypw has quit IRC | 08:41 | |
| pepijndevos | parameter \OUTPUT_USED 1 | 08:41 |
| pepijndevos | parameter \INPUT_USED 0 | 08:41 |
| pepijndevos | connect \O \clk | 08:41 |
| daveshah | Right could you fix that in the packer and PR it? | 08:42 |
| pepijndevos | Sure... but... part of me feels it kinda makes sense the way it is. | 08:43 |
| pepijndevos | And... I'm confused how this actually happens | 08:45 |
| pepijndevos | This seems to make perfect sense https://github.com/YosysHQ/nextpnr/blob/6a335411da6eb54f0960eb514c5384e4ae60c3a7/generic/cells.cc#L109 | 08:46 |
| tpb | Title: nextpnr/cells.cc at 6a335411da6eb54f0960eb514c5384e4ae60c3a7 · YosysHQ/nextpnr · GitHub (at github.com) | 08:46 |
| pepijndevos | Wait... maybe it's my own fault | 08:48 |
| pepijndevos | Yea... remember you told me to do constraints you have to initialise the IOB yourself? | 08:48 |
| pepijndevos | Well... | 08:49 |
| pepijndevos | I uploaded my blinky, and... it doesn't blink, but it outputs *something* and accepts my bitstream, so that's a pretty good start of the day I'd say. | 08:53 |
| *** kraiskil has quit IRC | 08:55 | |
| daveshah | Very good! | 09:08 |
| daveshah | Usually my first tests are output at constant 0 or 1 | 09:09 |
| daveshah | Then input to output direct | 09:09 |
| daveshah | Then a NOT gate | 09:09 |
| daveshah | Then it might be worth trying blinky | 09:09 |
| pepijndevos | Yea, doing that now. | 09:12 |
| pepijndevos | It likes constants less than blinky it seems | 09:17 |
| daveshah | Good start, at least that means outputs work | 09:18 |
| pepijndevos | No I mean... if I do constants, nothing happens. If I do blinky, it at least lit some random LEDs | 09:21 |
| pepijndevos | Well, nothing: all LEDs are off | 09:21 |
| pepijndevos | It's doing something really fishy, routing them to a DFF | 09:22 |
| pepijndevos | I need to somehow tell Nextpnr about my VCC and VSS nets. | 09:24 |
| daveshah | If you don't tell it about them then it will use a LUT | 09:29 |
| daveshah | However, I think the LUT init value it uses might be wrong for Gowin | 09:29 |
| daveshah | ie just a single 1 for Vcc assuming unused LUT inputs are 0 rather than all 1s | 09:29 |
| pepijndevos | Ah, it might actually be an issue with my unpacker, which might not find a LUT with all 1's which are all 0s in the bitstream. | 09:30 |
| pepijndevos | But how would I express a constant net? | 09:31 |
| pepijndevos | I think I already create VCC and VSS nets for the pips, but they are just normal nets, and nothing outputs to them. | 09:32 |
| daveshah | You would need to create a bel with Vcc and Gnd pins that map to those wires | 09:33 |
| daveshah | And then get the packer to use that bel rather than creating constant driving LUTs | 09:33 |
| daveshah | For now I'd try and get the constant driving LUTs to work | 09:33 |
| daveshah | Less efficient, but in the spirit of generic - some FPGAs don't have omnipresent Vcc and Gnd (e.g. ICE40) | 09:34 |
| pepijndevos | But a bell that doesn't have a location on the fpga | 09:35 |
| pepijndevos | (I actually expand init values by repeating them so 01 would become 0101010101 and 1 becomse 11111111 so that should not be a problem) | 09:36 |
| daveshah | You give it an arbitrary one | 09:36 |
| daveshah | It's not a real bel | 09:36 |
| sorear | am I the only person bothered by using "vcc and gnd" as notation for logic 1 and 0? for all we actually know the ice40 fabric could be active-low internally | 09:36 |
| daveshah | It's just a way of accessing the gloval Vcc and Gnd wires | 09:37 |
| pepijndevos | Ohi I see | 09:37 |
| daveshah | Well, several fpga companies also use this notation... | 09:37 |
| daveshah | (and given the schematics in patents I'm pretty sure it isn't... | 09:37 |
| pepijndevos | Gowin even mixes VSS and GND | 09:38 |
| whitequark | yamaha has a chip with only vss and gnd | 09:38 |
| whitequark | no other power pins :) | 09:39 |
| pepijndevos | Wait, that's actually odd... their global names are VSS and VCC, mixing BJT and CMOS naming. | 09:39 |
| daveshah | Xilinx tends to use Vcc and Gnd | 09:40 |
| daveshah | Because their FPGAs are bjt based :p | 09:40 |
| pepijndevos | Their primitives are VCC and GND, but the wire name is not. | 09:40 |
| pepijndevos | I want a TTL FPGA hehe | 09:41 |
| pepijndevos | Ah, spotted the bug | 09:44 |
| pepijndevos | Okay! Output works!! | 09:47 |
| pepijndevos | PR incoming | 09:47 |
| pepijndevos | daveshah, https://github.com/YosysHQ/nextpnr/pull/352 | 09:50 |
| tpb | Title: leftover Q from before slice api change by pepijndevos · Pull Request #352 · YosysHQ/nextpnr · GitHub (at github.com) | 09:50 |
| daveshah | Ah, that makes sense. Thanks! | 09:50 |
| sorear | whitequark: negative supply? | 09:52 |
| whitequark | a typo | 09:52 |
| whitequark | should've been VCC | 09:53 |
| pepijndevos | Ah, seems like my LUT INIT bits get messed up somewhere. | 09:58 |
| pepijndevos | Nextpnr gives me parameter \INIT 2'01, but after unpacking it decodes to parameter \INIT 16'1010101010101010 | 10:00 |
| pepijndevos | I had the bit order backwards lol | 10:10 |
| *** kraiskil has joined #yosys | 10:11 | |
| pepijndevos | BLINKYYYYYY | 10:15 |
| daveshah | \o/ | 10:15 |
| ZirconiumX | Congrats, pepijndevos! | 10:19 |
| ZirconiumX | Of course, this makes you an abyss domain expert now | 10:19 |
| pepijndevos | I think there are worse abysses to be a domain expert in. | 10:20 |
| sorear | what's the project scope? | 10:21 |
| pepijndevos | "do as much stuff as possible within your internship period" I think | 10:22 |
| sorear | I mean, what did you just succeed at doing | 10:27 |
| sorear | what can you do with open tools today | 10:27 |
| ZirconiumX | Blinking an LED on a Gowin GW1N-1 | 10:27 |
| sorear | end to end or with vendor tool deps? | 10:27 |
| pepijndevos | *GW1NR-9 | 10:27 |
| ZirconiumX | End to end | 10:27 |
| pepijndevos | Oh, so I used the Nextpnr generic target for PnR and my own bitstream packer. Only vendor dep is the programmer. | 10:28 |
| ZirconiumX | Which honestly doesn't count in my book, because it's almost certainly JTAG of some kind | 10:29 |
| *** citypw has joined #yosys | 10:29 | |
| pepijndevos | Yea, it's exactly that, so probably easy to write custom, but IMO not high-priority. | 10:30 |
| pepijndevos | Enumerates as 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC | 10:30 |
| ZirconiumX | You could just use openocd | 10:31 |
| pepijndevos | ...how? | 10:31 |
| whitequark | openocd has a generic ftdi target iirc | 10:37 |
| whitequark | you have to configure how it drives the thing, mostly the gpios | 10:37 |
| pepijndevos | Has this been done before for ice40 or ecp5 or some other fpga? | 10:39 |
| daveshah | Yes, I use it for ECP5 | 10:40 |
| daveshah | Ecppack can create an SVF file | 10:40 |
| pepijndevos | Sweet. Any code/usage I can look at? | 10:44 |
| daveshah | This was my first svf generator which might be easier to understand | 10:47 |
| daveshah | https://github.com/SymbiFlow/prjtrellis/blob/master/tools/bit_to_svf.py | 10:47 |
| tpb | Title: prjtrellis/bit_to_svf.py at master · SymbiFlow/prjtrellis · GitHub (at github.com) | 10:47 |
| daveshah | For the ECP5 it was easy as you just send the bitstream as the payload to an SVF command after a few initial setup commands | 10:47 |
| daveshah | Not sure how Gowin works | 10:47 |
| daveshah | If the vendor tools can create an SVF file then you could work from that | 10:48 |
| ZirconiumX | I could probably look at how quartus does it for the CV | 10:48 |
| daveshah | I'm sure Quartus can create an SVF, I think I've even done it before | 10:48 |
| ZirconiumX | Yep | 10:48 |
| daveshah | No idea what that SVF looks like though | 10:48 |
| pepijndevos | So this SVF file tells openocd all it needs to program the things? | 10:48 |
| ZirconiumX | Basically, yeah; it's a command dump | 10:48 |
| pepijndevos | Hmmm, lemme see if the Gowin IDE has anything like that or I need to somehow capture it. | 10:49 |
| daveshah | A logic analyser on the JTAG would be the way forward otherwise | 10:50 |
| daveshah | Looks like sigrok even has a JTAG decoder | 10:50 |
| daveshah | Haven't tried it though | 10:50 |
| ZirconiumX | Not necessarily. It's going over USB, so you could Wireshark it | 10:50 |
| whitequark | that'd probably be more annoying tbh | 10:51 |
| pepijndevos | Yea, but I have wireshark, I misplaced my logic analyser :((( | 10:51 |
| ZirconiumX | It does annoy me that Wireshark don't let you build message streams over USB because USB packets are supposed to be independent | 10:52 |
| * pepijndevos needs a glasgow | 10:53 | |
| ZirconiumX | We all do | 10:54 |
| whitequark | :D | 10:54 |
| pepijndevos | Actually... JTAG is kind of a giant gap in my knowledge. It's like this magic thing that "other people" use to debug their chips or something. I also seem to be under the impression it's super hard to use, requires expensive hardware, and gives you super powers. | 10:59 |
| * pepijndevos programms FPGAs using JTAG FTDI chips without thinking about it | 10:59 | |
| whitequark | it doesn't require expensive hardware at all | 11:00 |
| whitequark | you need, what, five GPIOs? | 11:00 |
| whitequark | now, *very fast* JTAG does | 11:00 |
| ZirconiumX | Y'know, I'm suddenly very glad Altera changed their SKU naming scheme. I'm sure it wouldn't be confusing to have ecppack and ep5cpack. | 11:01 |
| pepijndevos | I don't see any SVF option in Gowin IDE or programmer. | 11:04 |
| daveshah | It might be called deployment or similar | 11:06 |
| daveshah | Such an option would be used for bulk testing/programming with industrial programmers, for example | 11:07 |
| pepijndevos | It's not helpful that the GUI tool doesn't work on my machine at all. | 11:09 |
| pepijndevos | All the options: https://paste.ubuntu.com/p/8J9tSYSt58/ | 11:10 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 11:10 |
| *** FabM has joined #yosys | 11:11 | |
| daveshah | I wonder what the JTAG 1149 options do compared to the normal program options | 11:25 |
| *** citypw has quit IRC | 12:11 | |
| *** rohitksingh has quit IRC | 12:49 | |
| *** rohitksingh has joined #yosys | 12:52 | |
| *** dys has quit IRC | 12:59 | |
| *** rohitksingh has quit IRC | 13:46 | |
| *** dys has joined #yosys | 13:49 | |
| *** dys has quit IRC | 14:41 | |
| *** dys has joined #yosys | 15:42 | |
| *** adjtm has quit IRC | 15:54 | |
| *** freemint has joined #yosys | 16:00 | |
| *** freemint has quit IRC | 16:01 | |
| *** emeb has joined #yosys | 16:04 | |
| *** FSM_Dude has joined #yosys | 16:05 | |
| FSM_Dude | ZirconiumX Hey! It's me again, the guy with the problem on the Mac :) | 16:06 |
| FSM_Dude | I figured out my problem! It was totally my fault, so there is nothing wrong in Yosys ;) | 16:06 |
| FSM_Dude | Thanks for helping me tho! | 16:06 |
| daveshah | What was the problem? | 16:07 |
| FSM_Dude | I thought I had removed all my old code, and that I basically was back to no changes to Yosys, but that wasn't the case | 16:10 |
| FSM_Dude | in my code I did something which cause the thread_bad_access | 16:10 |
| FSM_Dude | So the fault is completely my own mistake :) | 16:10 |
| ZirconiumX | Right, okay | 16:15 |
| mwk | FSM_Dude: it's not | 16:16 |
| mwk | whenever you get yosys to crash on your code, it's a bug in yosys | 16:16 |
| mwk | even if the code is total nonsense | 16:16 |
| mwk | and you should report such events | 16:16 |
| ZirconiumX | mwk: my understanding is this is a modified version of Yosys, so the bug was in the modifications | 16:17 |
| mwk | oh | 16:18 |
| mwk | okay, fair enough then | 16:18 |
| ZirconiumX | And that the version of Yosys FSM_Dude still contained some changes, which caused a crash | 16:18 |
| FSM_Dude | Ye, I'm trying to use Yosys for research for my thesis | 16:18 |
| FSM_Dude | I'm implementing state encodings which are hardened against 1 bit error or 2 bit errors in the state signal | 16:19 |
| mwk | hmm | 16:19 |
| mwk | would be nice if we had reasonable state machine support in the first place | 16:20 |
| mwk | ah well | 16:20 |
| FSM_Dude | Why is the state machine support not reasonable? | 16:21 |
| mwk | https://github.com/YosysHQ/yosys/issues/188 | 16:22 |
| tpb | Title: Feature request: FSM init fixes · Issue #188 · YosysHQ/yosys · GitHub (at github.com) | 16:22 |
| mwk | it's not about the init value, btw, that part is actually easy to fix | 16:23 |
| FSM_Dude | Hmm okay | 16:23 |
| FSM_Dude | I just face one 'big' problem at the moment | 16:23 |
| FSM_Dude | I'm trying to add states to the state machine, but that seems to be tricky in Yosys | 16:24 |
| *** FabM has quit IRC | 16:28 | |
| mwk | well, you'd have to parse all the params into something sane, possibly enlarge the state encoding size, add whatever transitions you want, and reencode | 16:29 |
| *** FSM_Dude has quit IRC | 16:40 | |
| *** FSM_Dude has joined #yosys | 16:42 | |
| FSM_Dude | mwk So what I do now is: add an encoding type to the fsm_recode.cc; like Yosys already has "one-hot" or "binary", I added the functionality of "my_encoding". So now, you can run: fsm_recode -encoding my_encoding. | 16:43 |
| FSM_Dude | what my_encoding does, is encode the state signals from the fsm_data in a certain way, and add additional states to the fsm_data's state table. Also I add the necessary transitions.From there on, I continue the synthesis process, but somehow I end up with no logic and cells in the end | 16:43 |
| mwk | that's worrying | 16:45 |
| mwk | it sounds like it should work, fsm_map doesn't really do anything smart | 16:45 |
| FSM_Dude | I tried it my new encoding type on a small FSM | 16:49 |
| FSM_Dude | and after running fsm_recode -encoding my_encoding, I ran fsm_info and I printed the fsm to a png | 16:50 |
| FSM_Dude | which was the exact result I hoped for | 16:50 |
| FSM_Dude | but then continuing the synthesis process, something else seem to fail | 16:50 |
| FSM_Dude | on the other hand, I'm quite new to this all, so it might be my incompetence | 16:51 |
| mwk | could you show me fsm_info before and after? | 16:52 |
| *** FSM_Dude has quit IRC | 16:58 | |
| *** qu1j0t3 is now known as OK_b00m3r | 17:26 | |
| *** dys has quit IRC | 18:27 | |
| ZirconiumX | daveshah: So, I copied synth_intel and modified it a bit to be called synth_intel_alm, but Yosys does not seem to be picking it up, so I've evidently missed a step. | 18:38 |
| daveshah | Are you actually building the file? | 18:38 |
| mwk | makefile? | 18:38 |
| daveshah | haha snap | 18:38 |
| ZirconiumX | OBJS += techlibs/intel/synth_intel.o techlibs/intel/synth_intel_alm.o | 18:42 |
| ZirconiumX | [ 82%] Building techlibs/intel/synth_intel_alm.o | 18:42 |
| ZirconiumX | Yes :P | 18:42 |
| daveshah | Is https://github.com/YosysHQ/yosys/blob/master/techlibs/intel/synth_intel.cc#L29 sensibly changed? | 18:43 |
| tpb | Title: yosys/synth_intel.cc at master · YosysHQ/yosys · GitHub (at github.com) | 18:43 |
| ZirconiumX | Yes, it is | 18:43 |
| daveshah | and an object instance created like https://github.com/YosysHQ/yosys/blob/master/techlibs/intel/synth_intel.cc#L251 ? | 18:43 |
| tpb | Title: yosys/synth_intel.cc at master · YosysHQ/yosys · GitHub (at github.com) | 18:43 |
| ZirconiumX | The answer is that once again, I'm an idiot | 18:43 |
| ZirconiumX | I was running `yosys -p "help synth_intel_alm"`, and forgot a `sudo make install` first | 18:44 |
| ZirconiumX | -- Running command `help synth_intel_alm' -- | 18:44 |
| ZirconiumX | synth_intel_alm [options] | 18:44 |
| ZirconiumX | This command runs synthesis for ALM-based Intel FPGAs. | 18:44 |
| ZirconiumX | Yay | 18:44 |
| daveshah | We've all been there | 18:44 |
| ZirconiumX | The next question is: can I actually compile anything with it? | 18:45 |
| ZirconiumX | Answer: yes, but it then crashes kind of oddly. | 18:48 |
| ZirconiumX | I'm probably being an idiot again | 18:48 |
| ZirconiumX | Yep. | 18:48 |
| daveshah | Oh BTW,the Yosys makefile strips binaries before installing them | 18:49 |
| daveshah | so for dev it's usually best not to use installed yosys | 18:49 |
| ZirconiumX | Yep, those commands get printed from the Makefile | 18:49 |
| daveshah | at least if you want decent debug info | 18:49 |
| *** Jybz has joined #yosys | 18:51 | |
| *** Jybz has quit IRC | 18:54 | |
| cr1901_modern | Modern gcc does something similar, except the Makefile command to install stripped binaries to --prefix is "install-strip" instead of "install". So they got it _half_ right. | 18:59 |
| ZirconiumX | Right, the test run seems to work. Now to adapt my script pass for this. | 19:06 |
| *** Jybz has joined #yosys | 19:11 | |
| *** bobzoidting has joined #yosys | 19:15 | |
| *** adjtm has joined #yosys | 19:50 | |
| *** Jybz has quit IRC | 20:02 | |
| *** dys has joined #yosys | 20:11 | |
| ZirconiumX | How much more efficient is cmp2lut compared to letting ABC figure it out? Has anybody tried to quantify that? | 20:20 |
| daveshah | the problem isn't abc per se, but yosys using carries | 20:25 |
| daveshah | that then limit abc's optimisation | 20:25 |
| whitequark | cmp2lut should not exist | 20:25 |
| whitequark | instead lut mapping should be able to use whiteboxes | 20:25 |
| daveshah | but this is more about optimisation than mapping | 20:26 |
| daveshah | whitebox aware fine grain optimisation would eliminate it | 20:26 |
| ZipCPU | daveshah: Have you ever used any of the DELAYF elements/ | 20:26 |
| ZipCPU | ? | 20:26 |
| whitequark | would it? | 20:27 |
| daveshah | or more, combined optimisation and mapping | 20:27 |
| daveshah | not so much cmp2lut, but the example I think of is (7-x) on a 8-input mux select input | 20:27 |
| daveshah | If you don't have hard blocks in the way, you can optimise and map the mux to LUTs with the data inputs reversed | 20:28 |
| daveshah | perhaps I'm not explaining this well | 20:28 |
| ZipCPU | Looks like I jumped in in the middle of a conversation | 20:28 |
| daveshah | but the core problem isn't just local mapping of the hard blocks to logic | 20:28 |
| daveshah | there's also the bigger decision where hard blocks prevent optimisation opportunities elsewhere | 20:29 |
| daveshah | it's certainly an interesting thing to think about and something that could well be done better than abc does it | 20:29 |
| daveshah | ZipCPU: yes, I have | 20:29 |
| daveshah | at least in litedram | 20:29 |
| daveshah | see https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/ecp5ddrphy.py#L369 | 20:29 |
| tpb | Title: litedram/ecp5ddrphy.py at master · enjoy-digital/litedram · GitHub (at github.com) | 20:29 |
| daveshah | this uses one of the built in delay modes | 20:30 |
| ZipCPU | Is there any particular trick to it? I'm trying to adjust one and ... it doesn't seem to be adjusting. Do need to hold the MOVE pin high for any particular length of time for example? | 20:30 |
| * ZipCPU opens the link | 20:30 | |
| daveshah | I don't know, tbh | 20:30 |
| daveshah | I've only ever used fixed delays | 20:30 |
| daveshah | I believe it is edge triggered on move | 20:30 |
| daveshah | I presume you have LOADN high? | 20:31 |
| ZipCPU | Yes. | 20:31 |
| daveshah | worth noting the step size is pretty small - something like 60ps | 20:31 |
| ZipCPU | Here's the code I'm using: https://github.com/ZipCPU/zipversa/blob/master/rtl/ecpnetdly.v | 20:31 |
| tpb | Title: zipversa/ecpnetdly.v at master · ZipCPU/zipversa · GitHub (at github.com) | 20:31 |
| ZipCPU | It doesn't ever seem to be setting the CFLAG high when I raise the delay | 20:32 |
| daveshah | It is possible there is a trellis bug here | 20:33 |
| ZipCPU | Any suggestions? | 20:33 |
| daveshah | Hang on, I'll have a look | 20:36 |
| ZipCPU | Thanks! | 20:36 |
| daveshah | Yes, I can see a missing database bit | 20:39 |
| ZipCPU | Also, should the parameter values show up in the json file? DEL_MODE and DEL_VALUE? | 20:40 |
| janrinze | daveshah: in nextpnr the posedge to posedge of the global clk is 9.9 ns yet nextpnr tells me the max frequency is 70.61 Mhz. how does that work? does it add the I/O async times? | 20:41 |
| *** emeb_mac has joined #yosys | 20:44 | |
| daveshah | ZipCPU: no, not if they are not assigned values | 20:44 |
| daveshah | janrinze: hmm, might be a bug - can you post the path report? | 20:44 |
| ZipCPU | Ok | 20:44 |
| ZipCPU | The path report? You mean the log from running nextpnr-ecp5? | 20:44 |
| daveshah | That was for janrinze :) | 20:45 |
| janrinze | will do | 20:45 |
| ZipCPU | Oh, sorry, that was to janrinze ;) | 20:45 |
| janrinze | :D | 20:45 |
| daveshah | I've found what I think is the delay issue. I just need to patch trellis and nextpnr now... | 20:45 |
| ZipCPU | Thanks! | 20:51 |
| *** rohitksingh has joined #yosys | 20:53 | |
| *** emeb_mac has quit IRC | 20:55 | |
| janrinze | https://github.com/YosysHQ/nextpnr/issues/354 | 20:57 |
| tpb | Title: how to read the path report. · Issue #354 · YosysHQ/nextpnr · GitHub (at github.com) | 20:57 |
| daveshah | ZipCPU: can you try again with latest nextpnr and trellis (if it still fails, then I'll look further on hardware tomorrow) | 20:59 |
| ZipCPU | Absolutely! Thanks! | 20:59 |
| janrinze | daveshah: where do i send the json? | 21:05 |
| janrinze | daveshah: and the cpu runs at.. 96MHz without errors :D | 21:05 |
| daveshah | Either attach it to the issue, zipped, or email it to me at [email protected] | 21:05 |
| daveshah | That's probably more to do with the margin at room temperature with a decent die than anything else... | 21:06 |
| *** stzsch has quit IRC | 21:06 | |
| janrinze | daveshah: 35% faster is within 'normal' range? I have not been able to 'overclock' designs before with the HX8K but if ECP5 is more lenient then that's nice to know. | 21:08 |
| daveshah | It certainly seems doable | 21:08 |
| daveshah | Maybe iCE40 devices have less margin | 21:08 |
| daveshah | What speed grade is your ECP5 BTW? I have a suspicion that if Lattice have too many good -8 devices then they'll just sell them as -6 as artificial market segmentation | 21:09 |
| janrinze | daveshah: it's a -8 | 21:09 |
| daveshah | That would get you at least 35% if that happened | 21:09 |
| daveshah | Oh, nevermind that idea then | 21:09 |
| janrinze | do they have a -10? ;D | 21:10 |
| daveshah | Well, they have the 5G parts | 21:10 |
| janrinze | it's a 5G | 21:10 |
| daveshah | Ah, they are like a -9 already because of the overvoltage | 21:10 |
| daveshah | but that is taken account of already in the numbers | 21:11 |
| janrinze | I use the lattice ecp5 board. (the one without the PCIe connector) | 21:11 |
| janrinze | uploaded the json file. | 21:21 |
| janrinze | i'm going to test 110 MHz too :-) | 21:22 |
| janrinze | ok. that's too much for the monitor. | 21:24 |
| *** nrossi has quit IRC | 21:32 | |
| daveshah | janrinze: Have pushed a fix to nextpnr master | 21:36 |
| daveshah | unfortunately the path was wrong, the 68MHz was correct... | 21:36 |
| janrinze | it will take a while to build. I will keep am eye out on the margins allowable for this ecp5. 68MHz vs 96MHz is nice to keep in mind. Of course just for fiddling, not for stable. | 21:47 |
| *** kraiskil has quit IRC | 21:49 | |
| ZipCPU | daveshah: nextpnr is now crashing on an assertion_failure, in nextpnr.h:340 | 21:50 |
| daveshah | ZipCPU: can you get a backtrace with gdb/coredumpctl/etc? | 21:53 |
| daveshah | It is possible this is from another recent change | 21:54 |
| ZipCPU | It says, "terminate called after throwing an instance of nextpnr_ecp5::assertion_failure what(): Assertion failure: is_string (/home/dan/work/rnd/opencores/tools/nextpnr/common/nextpnr.h:340) | 21:54 |
| daveshah | ZipCPU: can you run `gdb --args nextpnr-ecp5 --json .....`, `run` and then print the stack trace pointing to where the assertion failure is? | 21:56 |
| ZipCPU | Working on it | 21:56 |
| daveshah | s/print/send | 21:56 |
| daveshah | Cheer | 21:56 |
| daveshah | *Cheers | 21:56 |
| ZipCPU | (Was trying to do it with ddd ...) | 21:56 |
| ZipCPU | daveshah: Here's the trace: https://imgur.com/tT9r4aG | 21:59 |
| tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 21:59 |
| ZipCPU | I still have ddd up, in case you want to query anything | 21:59 |
| *** rohitksingh has quit IRC | 22:01 | |
| daveshah | No, on it now | 22:01 |
| daveshah | ZipCPU: try updating again (just nextpnr this time, trellis hasn't changed) | 22:04 |
| ZipCPU | Got it | 22:04 |
| *** rohitksingh has joined #yosys | 22:18 | |
| *** d__ has joined #yosys | 22:22 | |
| *** bobzoidting has quit IRC | 22:29 | |
| *** X-Scale has quit IRC | 22:42 | |
| ZipCPU | daveshah: That's closer. Now I'm getting an incompatible IO voltage warning the project was never getting before. | 22:44 |
| daveshah | What is the message? | 22:44 |
| ZipCPU | ERROR: Error processing 'gpio_clk_scli': incompatible IO voltages 2V5 and 3V3 on bank 2.0 warnings, 1 error | 22:45 |
| ZipCPU | gpio_clk_scli isn't a name used (by me) anywhere in my design | 22:45 |
| daveshah | Is it present in your LPF file? | 22:47 |
| daveshah | If it isn't, it really shouldn't have even got that far | 22:47 |
| ZipCPU | It's not present anywhere in my RTL directory: JSON, design, etc. | 22:47 |
| ZipCPU | Ok, gpio_clk_scl is present in the design | 22:47 |
| ZipCPU | Specifically, I have a wire named io_gpio_clk_scl. I'll need to chase that down I guess | 22:48 |
| ZipCPU | Give me a bit with that | 22:48 |
| daveshah | I'm still confused where the extra "i" is coming from | 22:48 |
| ZipCPU | Yes. You and me both | 22:49 |
| daveshah | Can you post the JSON and LPF? | 22:49 |
| ZipCPU | Sure ... how do you want them posted? | 22:49 |
| daveshah | Zip them and upload them to somewhere? | 22:49 |
| daveshah | google drive or similar | 22:49 |
| daveshah | Oh, I see | 22:50 |
| daveshah | You have an IO buffer called gpio_clk_scli | 22:51 |
| daveshah | https://github.com/ZipCPU/zipversa/blob/83d7ad0a6d83fb457d217723c1bf341b21722b52/rtl/toplevel.v#L205 | 22:51 |
| tpb | Title: zipversa/toplevel.v at 83d7ad0a6d83fb457d217723c1bf341b21722b52 · ZipCPU/zipversa · GitHub (at github.com) | 22:51 |
| daveshah | But it's in a mess because the BB isn't connected to a proper top level pin | 22:51 |
| daveshah | this should be .B(io_gpio_clk_scl) io_gpio_clk_scl | 22:51 |
| daveshah | * .B(io_gpio_clk_scl) | 22:51 |
| daveshah | https://github.com/ZipCPU/zipversa/blob/83d7ad0a6d83fb457d217723c1bf341b21722b52/rtl/toplevel.v#L206 | 22:51 |
| tpb | Title: zipversa/toplevel.v at 83d7ad0a6d83fb457d217723c1bf341b21722b52 · ZipCPU/zipversa · GitHub (at github.com) | 22:51 |
| daveshah | and the instance below | 22:52 |
| daveshah | B is the name of the top level pad port, not O | 22:52 |
| daveshah | (O is the output from the input buffer) | 22:52 |
| ZipCPU | Ahhh ... okay | 22:52 |
| ZipCPU | So ... just swap .O with .B? | 22:52 |
| daveshah | Yep | 22:52 |
| ZipCPU | No, that's not quite it | 22:52 |
| ZipCPU | ... but I think I see what's going on | 22:52 |
| daveshah | Anyway, BB should have B connected to a top level pin | 22:53 |
| ZipCPU | Got it | 22:54 |
| daveshah | Due to some historical issues it is hard to enforce this as a check | 22:54 |
| ZipCPU | Lol | 22:54 |
| ZipCPU | Someday, we'll convert those to histerical issues | 22:54 |
| ZipCPU | daveshah: Now, there's: terminate called after throwing an instance of 'std::runtime_error'\n what(): no enum named 'IOLOGICD.LOADNMUX' | 23:12 |
| daveshah | Are you sure that Trellis and its database submodule updated? | 23:13 |
| ZipCPU | Well, there was a push to "Bump database" since I lats built, so let me try again | 23:19 |
| ZipCPU | Okay, looks like I'm getting the error from libtrellis' ecppack ... rebuilding that one again now | 23:34 |
| ZipCPU | Okay, I rebuilt it completely and ... it's still dying in ecppack with the aforementioned error | 23:37 |
| *** emeb has quit IRC | 23:38 | |
| daveshah | Is ecppack make installed, and the correct ecppack being used? | 23:39 |
| ZipCPU | Yes. It is installed via make | 23:39 |
| ZipCPU | ... and I'm using the correct/installed ecppack | 23:40 |
| daveshah | Can you grep for LOADNMUX in /usr/local/share/trellis/database? | 23:40 |
| ZipCPU | Okay ... | 23:40 |
| daveshah | Or /usr/share depending on where it is installed? | 23:40 |
| ZipCPU | The string isn't present | 23:42 |
| ZipCPU | That means I need to rebuild the database, then, right? | 23:42 |
| daveshah | No, this isn't built | 23:42 |
| daveshah | It's just cloned and copied | 23:43 |
| daveshah | It is more likely that the database submodule in prjtrellis isn't up to date | 23:43 |
| daveshah | Or that make install didn't work for some reason | 23:43 |
| ZipCPU | I think I have a submodules problem | 23:43 |
| ZipCPU | "git pull" in prjtrellis/database just made a whole lot of changes | 23:44 |
| daveshah | That sounds promising. make install libtrellis again and ecppack should succeed | 23:44 |
| ZipCPU | Yep! | 23:45 |
| ZipCPU | Now ecppack completes without error. Let me rebuild the design from scratch and make sure all the pieces work | 23:45 |
| ZipCPU | Yaaayyyyy!!!! I'm not getting bad network CRCs anymore! Thanks, daveshah! | 23:56 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!