| *** tpb has joined #yosys | 00:00 | |
| *** dys has quit IRC | 00:01 | |
| *** gorbak25 has quit IRC | 00:02 | |
| *** gorbak25 has joined #yosys | 00:05 | |
| *** cr1901_modern has quit IRC | 00:25 | |
| *** cr1901_modern has joined #yosys | 00:26 | |
| *** X-Scale has joined #yosys | 01:02 | |
| *** dxld has quit IRC | 01:07 | |
| *** dxld has joined #yosys | 01:15 | |
| *** _whitelogger has quit IRC | 01:27 | |
| *** _whitelogger has joined #yosys | 01:30 | |
| *** _whitelogger has quit IRC | 01:51 | |
| *** _whitelogger has joined #yosys | 01:53 | |
| *** rohitksingh has quit IRC | 03:39 | |
| *** nrossi has joined #yosys | 05:20 | |
| *** dys has joined #yosys | 05:42 | |
| *** turq is now known as turqq | 05:45 | |
| *** turqq is now known as turq | 05:49 | |
| *** rohitksingh has joined #yosys | 06:24 | |
| *** FabM has joined #yosys | 08:22 | |
| *** show1 has quit IRC | 08:43 | |
| *** show1 has joined #yosys | 09:10 | |
| *** kraiskil has joined #yosys | 09:14 | |
| *** kraiskil has quit IRC | 09:56 | |
| *** kraiskil has joined #yosys | 10:10 | |
| ZirconiumX | I'm pretty sure my LUT bit order is wrong, but I don't really know how to permute the bits in Verilog to get the right order | 10:38 |
|---|---|---|
| *** proteusguy has quit IRC | 11:52 | |
| *** dys has quit IRC | 12:00 | |
| *** proteusguy has joined #yosys | 12:06 | |
| *** rohitksingh has quit IRC | 12:16 | |
| *** citypw has joined #yosys | 14:51 | |
| *** kraiskil has quit IRC | 15:02 | |
| pepijndevos | What happens to initial values on an FPGA that does not support them? Will they get silently ignored? Will it cause an error? | 15:19 |
| daveshah | In ASIC synthesis where they are never supported, they are generally left unprocessed and therefore give a warning | 15:21 |
| daveshah | I think the same is true for ECP5 when there is a conflict between init value and async SR value | 15:22 |
| daveshah | It is only a warning rather than error because that's what the vendor tools do too | 15:22 |
| pepijndevos | is there a __techmap_warn though hehe | 15:22 |
| daveshah | Just leave the init value unprocessed | 15:23 |
| daveshah | You'll then get a warning at the end | 15:23 |
| daveshah | from check | 15:23 |
| daveshah | The $warning system task might work in techmap too but I haven't tried it | 15:24 |
| pepijndevos | How do you (not) proccess a init value? Is that what wire _TECHMAP_REMOVEINIT_Q_ = 1; does? | 15:25 |
| daveshah | I have not used the techmap init stuff, but that sounds like it | 15:25 |
| *** emeb has joined #yosys | 15:58 | |
| *** FabM has quit IRC | 16:22 | |
| *** kraiskil has joined #yosys | 16:33 | |
| *** kraiskil has quit IRC | 16:48 | |
| *** citypw has quit IRC | 16:49 | |
| *** kraiskil has joined #yosys | 16:53 | |
| *** kraiskil has quit IRC | 17:00 | |
| *** kraiskil has joined #yosys | 17:12 | |
| *** kraiskil has quit IRC | 17:17 | |
| *** m_w has joined #yosys | 17:34 | |
| *** m_w has quit IRC | 18:02 | |
| *** proteusguy has quit IRC | 18:08 | |
| *** proteusguy has joined #yosys | 18:21 | |
| *** fsasm has joined #yosys | 18:42 | |
| *** dnotq has joined #yosys | 19:27 | |
| *** kraiskil has joined #yosys | 19:28 | |
| *** bobzoidting has joined #yosys | 19:37 | |
| *** rohitksingh has joined #yosys | 19:47 | |
| *** rohitksingh has quit IRC | 20:27 | |
| *** rohitksingh has joined #yosys | 20:34 | |
| *** fsasm has quit IRC | 20:36 | |
| *** fsasm has joined #yosys | 20:47 | |
| *** rohitksingh has quit IRC | 20:52 | |
| *** nrossi has quit IRC | 20:55 | |
| *** dys has joined #yosys | 21:06 | |
| *** fsasm has quit IRC | 21:11 | |
| dnotq | I have some questions about nextnpr, but I don't see any channel specifically for it. It is ok to talk about nextnpr here? | 21:28 |
| daveshah | Yes | 21:28 |
| dnotq | Great! So I have the EPC5-based badge from the HackADay supercon, but it has a known layout problem with the external clock in that is was not routed to a valid global clock pin. | 21:30 |
| daveshah | nextpnr will use general routing until it reaches global routing resources | 21:30 |
| daveshah | It is less strict than Diamond about this | 21:30 |
| dnotq | Ok. So does the EPC5 have a primitive similar to the Xilinx BUFG that can route a logic signal to the clock fabric? | 21:31 |
| daveshah | It is DCCA. But nextpnr will insert one into any clock signal anyway, so no need for one in the design | 21:32 |
| daveshah | [Technically speaking DCCA is closest to something like BUFGCE in Xilinx, as it also provides an enable input for clock gating] | 21:33 |
| whitequark | actually, a related question: does ECP5 have a genuine equivalent of BUFGCE? | 21:34 |
| dnotq | Do you know if Diamond can be convinced to use the DCCA to accept the logic input as a clock? I'm only interested in Diamond right now because all of my existing HDL is VHDL, so until I convert to Verilog I'm stuck with the vendor tools. | 21:34 |
| daveshah | whitequark: yes, DCCA should be glitchless too | 21:35 |
| daveshah | dnotq: no, I think Diamond needs some more hackery too | 21:35 |
| whitequark | the docs aren't super clear but doesn't it only enable a clock if you toggle the selection signal a few times? | 21:35 |
| daveshah | There is some VHDL support with the open tools - see https://github.com/tgingold/ghdlsynth-beta | 21:35 |
| tpb | Title: GitHub - tgingold/ghdlsynth-beta: VHDL synthesis (based on ghdl) (at github.com) | 21:35 |
| daveshah | whitequark: I don't think so | 21:35 |
| daveshah | Are you sure you aren't looking at the clock selection primitive (DCS) | 21:36 |
| daveshah | dnotq: I think setting the environment variable WARNING_ON_PCLKPLC1 = 1 will disable the error in Diamond | 21:37 |
| daveshah | But I haven't tried it in this case | 21:38 |
| *** bobzoidting has quit IRC | 21:38 | |
| dnotq | How does nextnpr determine timing? In all the examples I have seen so far, there does not appear to be any information about a clock's period or frequency in the UCF (LPR? I can't remember the extension) file. | 21:38 |
| daveshah | You can use a "FREQUENCY NET" constraint in the lpf; or a `--clock` command line argument which controls all clocks | 21:39 |
| daveshah | Clocks on PLL outputs are automatically derived for ECP5 | 21:39 |
| daveshah | The HAD badge project looks to use the other approach; though; which is a Python script that sets up the constraints | 21:40 |
| daveshah | see https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/master/soc/clock-constrainsts.py | 21:40 |
| tpb | Title: hadbadge2019_fpgasoc/clock-constrainsts.py at master · Spritetm/hadbadge2019_fpgasoc · GitHub (at github.com) | 21:40 |
| dnotq | I tried some of those constraints and the tool always said it was using 200MHz for all clocks. Maybe because it never got past the error of trying to use the GPIO as an input to the PLL? | 21:40 |
| daveshah | nextpnr doesn't care about that | 21:41 |
| dnotq | .py? The constraints are in a python file? | 21:41 |
| daveshah | They can be | 21:41 |
| daveshah | It's the current arch-independent way of timing constraints in nextpnr, if you don't want to use the LPF route | 21:41 |
| dnotq | hmm. Ok. Clearly I'm coming from a Xilinx / ISE environment, so all of this is new to me. | 21:41 |
| whitequark | daveshah: ohh right, that was indeed DCSC | 21:42 |
| dnotq | Is there an advantage of using the .py over the LPF? Is LFP Lattice specific? | 21:42 |
| daveshah | Yes | 21:42 |
| whitequark | the docs for DCCA don't say that it's glitchless | 21:42 |
| daveshah | The sim model looks like a glitchless buffer | 21:42 |
| whitequark | ah alright, good to know | 21:43 |
| daveshah | Oh the docs do say it is glitchless (the sysCLOCK doc anyway) | 21:44 |
| daveshah | > Figure 13. Glitchless DCC Functional Waveform | 21:44 |
| whitequark | ohh I see, not the libraries guide | 21:45 |
| whitequark | thanks | 21:45 |
| daveshah | The sysCLOCK doc is a very nice | 21:46 |
| daveshah | *one | 21:46 |
| daveshah | lots of fairly low level internal detail on the clock routing too | 21:46 |
| dnotq | I'm wondering, is there something about the Lattice FPGAs that make them more appealing to be some of the first devices supported by yosys/nextnpr over other manufacturers? | 22:11 |
| daveshah | The simplicity was the reason for the iCE40 being the starting point for open FPGA tooling | 22:12 |
| daveshah | The ECP5 is as much coincidence than anything else (architecturally they are totally different as they were designed by different companies) | 22:13 |
| dnotq | What is the effort like to add other FPGAs? And what would someone need to know in order to contribute to such an effort? | 22:18 |
| daveshah | I've been playing about with adding Xilinx support but it's not really end user ready | 22:27 |
| daveshah | The biggest issues being slow routing and a lack of any meaningful timing data | 22:27 |
| daveshah | https://github.com/daveshah1/nextpnr-xilinx | 22:27 |
| tpb | Title: GitHub - daveshah1/nextpnr-xilinx: Experimental flows using nextpnr for Xilinx devices (at github.com) | 22:27 |
| daveshah | If you want to play with it and see what goes horribly wrong then that is definitely helpful | 22:27 |
| daveshah | It might also be worth asking on #symbiflow - that channel covers the Xilinx work including bitstream stuff and another place and route option (VPR) | 22:29 |
| dnotq | Ok, I'll see what I can do. :) I'm interested in helping. | 22:29 |
| daveshah | Awesome! | 22:29 |
| dnotq | I'm not familiar with symbiflow. | 22:30 |
| daveshah | mithro did a talk about it at HaD. I think there might be a video of it | 22:30 |
| dnotq | Cool, I'll do some searching. | 22:31 |
| dnotq | I really like the low-level stuff, and had I realized it earlier in life I think I would have been a chip designer. But FPGAs seem to satisfy that need for me. :) | 22:32 |
| daveshah | It's very good fun :) | 22:33 |
| mithro | https://www.youtube.com/watch?v=EHePto95qoE | 22:33 |
| dnotq | Ah, nice. From the man himself even! ;) | 22:34 |
| dnotq | Oh crap, that video is from this year! I was there... Not sure how I missed this talk!? | 22:37 |
| *** emeb has quit IRC | 23:49 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!