cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern has joined #yosys
X-Scale has joined #yosys
dxld has quit [Ping timeout: 240 seconds]
dxld has joined #yosys
_whitelogger has joined #yosys
_whitelogger has joined #yosys
rohitksingh has quit [Ping timeout: 245 seconds]
nrossi has joined #yosys
dys has joined #yosys
turq is now known as turqq
turqq is now known as turq
rohitksingh has joined #yosys
FabM has joined #yosys
show1 has quit [Ping timeout: 240 seconds]
show1 has joined #yosys
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 265 seconds]
kraiskil has joined #yosys
<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
proteusguy has quit [Ping timeout: 240 seconds]
dys has quit [Ping timeout: 240 seconds]
proteusguy has joined #yosys
rohitksingh has quit [Ping timeout: 250 seconds]
citypw has joined #yosys
kraiskil has quit [Ping timeout: 240 seconds]
<pepijndevos>
What happens to initial values on an FPGA that does not support them? Will they get silently ignored? Will it cause an error?
<daveshah>
In ASIC synthesis where they are never supported, they are generally left unprocessed and therefore give a warning
<daveshah>
I think the same is true for ECP5 when there is a conflict between init value and async SR value
<daveshah>
It is only a warning rather than error because that's what the vendor tools do too
<pepijndevos>
is there a __techmap_warn though hehe
<daveshah>
Just leave the init value unprocessed
<daveshah>
You'll then get a warning at the end
<daveshah>
from check
<daveshah>
The $warning system task might work in techmap too but I haven't tried it
<pepijndevos>
How do you (not) proccess a init value? Is that what wire _TECHMAP_REMOVEINIT_Q_ = 1; does?
<daveshah>
I have not used the techmap init stuff, but that sounds like it
emeb has joined #yosys
FabM has quit [Quit: Leaving]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 240 seconds]
citypw has quit [Ping timeout: 240 seconds]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 265 seconds]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 240 seconds]
m_w has joined #yosys
m_w has quit [Quit: Leaving]
proteusguy has quit [Ping timeout: 240 seconds]
proteusguy has joined #yosys
fsasm has joined #yosys
dnotq has joined #yosys
kraiskil has joined #yosys
bobzoidting has joined #yosys
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #yosys
fsasm has quit [Ping timeout: 240 seconds]
fsasm has joined #yosys
rohitksingh has quit [Ping timeout: 265 seconds]
nrossi has quit [Quit: Connection closed for inactivity]
dys has joined #yosys
fsasm has quit [Ping timeout: 252 seconds]
<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?
<daveshah>
Yes
<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.
<daveshah>
nextpnr will use general routing until it reaches global routing resources
<daveshah>
It is less strict than Diamond about this
<dnotq>
Ok. So does the EPC5 have a primitive similar to the Xilinx BUFG that can route a logic signal to the clock fabric?
<daveshah>
It is DCCA. But nextpnr will insert one into any clock signal anyway, so no need for one in the design
<daveshah>
[Technically speaking DCCA is closest to something like BUFGCE in Xilinx, as it also provides an enable input for clock gating]
<whitequark>
actually, a related question: does ECP5 have a genuine equivalent of BUFGCE?
<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.
<daveshah>
whitequark: yes, DCCA should be glitchless too
<daveshah>
dnotq: no, I think Diamond needs some more hackery too
<whitequark>
the docs aren't super clear but doesn't it only enable a clock if you toggle the selection signal a few times?
<daveshah>
Are you sure you aren't looking at the clock selection primitive (DCS)
<daveshah>
dnotq: I think setting the environment variable WARNING_ON_PCLKPLC1 = 1 will disable the error in Diamond
<daveshah>
But I haven't tried it in this case
bobzoidting has quit [Ping timeout: 240 seconds]
<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.
<daveshah>
You can use a "FREQUENCY NET" constraint in the lpf; or a `--clock` command line argument which controls all clocks
<daveshah>
Clocks on PLL outputs are automatically derived for ECP5
<daveshah>
The HAD badge project looks to use the other approach; though; which is a Python script that sets up the constraints
<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?
<daveshah>
nextpnr doesn't care about that
<dnotq>
.py? The constraints are in a python file?
<daveshah>
They can be
<daveshah>
It's the current arch-independent way of timing constraints in nextpnr, if you don't want to use the LPF route
<dnotq>
hmm. Ok. Clearly I'm coming from a Xilinx / ISE environment, so all of this is new to me.
<whitequark>
daveshah: ohh right, that was indeed DCSC
<dnotq>
Is there an advantage of using the .py over the LPF? Is LFP Lattice specific?
<daveshah>
Yes
<whitequark>
the docs for DCCA don't say that it's glitchless
<daveshah>
The sim model looks like a glitchless buffer
<whitequark>
ah alright, good to know
<daveshah>
Oh the docs do say it is glitchless (the sysCLOCK doc anyway)
<daveshah>
lots of fairly low level internal detail on the clock routing too
<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?
<daveshah>
The simplicity was the reason for the iCE40 being the starting point for open FPGA tooling
<daveshah>
The ECP5 is as much coincidence than anything else (architecturally they are totally different as they were designed by different companies)
<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?
<daveshah>
I've been playing about with adding Xilinx support but it's not really end user ready
<daveshah>
The biggest issues being slow routing and a lack of any meaningful timing data
<tpb>
Title: GitHub - daveshah1/nextpnr-xilinx: Experimental flows using nextpnr for Xilinx devices (at github.com)
<daveshah>
If you want to play with it and see what goes horribly wrong then that is definitely helpful
<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)
<dnotq>
Ok, I'll see what I can do. :) I'm interested in helping.
<daveshah>
Awesome!
<dnotq>
I'm not familiar with symbiflow.
<daveshah>
mithro did a talk about it at HaD. I think there might be a video of it
<dnotq>
Cool, I'll do some searching.
<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. :)