<pepijndevos>
What is the intention of the generic target? Seems very tempting for a PoC to just hack a few dozen lines of Python rather than thousands of lines of C. But maybe it has major limitations in adition to the mentioned Windows linking issues?
<pepijndevos>
Of course eventually a nice C target is desirable, but at this point it's more of a proof of concept, with all the timing info and advanced knowledge still missing, so it'd be not far off from the simple.py example, and be mostly rewritten eventually anyway.
<daveshah>
The two limitations are performance (running the Python every time at startup might take 10-20s compared to 10ms to a bba linked into the elf)
<daveshah>
and the lack of custom validity checking/packing/etc
<daveshah>
the latter needed for useful clock enable, set/reset, advanced IO, etc
<mwk>
a lot of packing could be done as yosys passes though
<daveshah>
Yeah, it's mostly performance that's the issue
<daveshah>
The main part of packing that's a bit annoying to do in Yosys is clocking/IO stuff that requires some understanding of the physical layout
<daveshah>
stuff like what banks IO are in changing the IOLOGIC primitive used; merging/constraining DQS groups; etcc
<pepijndevos>
Yea, once I get to those kind of things it'll *definitely* be a C thing.
<pepijndevos>
But for now all I have is basically LUT, DFF([SR]E?), and basic, basic, IOB. So compared to the simple.py I only need to add more wires, and figure out the stuff about packing and constraint to some extend.
<pepijndevos>
But for now, even if set/reset/enable is not supported, fine with me.
<pepijndevos>
I guess the main thing is that in Gowin, a tiles has 4 slices of two DFF with a shared clock and set/reset, so I need to find out how to add that.
<pepijndevos>
But honestly, if the pnr for now assumes the whole tile shares clock and reset, that's probably good enough fow now.
<daveshah>
The generic arch comes with a toy packer that just combines FFs and LUTs into a LUTFF primitive, assuming a shared clock and no set/reset
<daveshah>
Just creating 8 of those per tile for the generic arch would be a very good start
<daveshah>
then you don't really have to do any packing or legality checking of your own at all
<daveshah>
There is also another script that is an example of a fasm backend for generic, if you wanted to use that as your bitstream IR
<pepijndevos>
... within which scope does it assume a shared clock?
<daveshah>
It allows one clock per tile
<daveshah>
Given this is really intended for a proof of concept, it's most likely you'll only have one clock per design anyway....
<pepijndevos>
Right
<pepijndevos>
I'm thinking if I can do this in a way that the bitstream packer doesn't depend on names in the generic target.
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 276 seconds]
kraiskil has joined #yosys
anuejn has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` is now known as X-Scale
blackbit has joined #yosys
cr1901_modern has quit [Quit: Leaving.]
<blackbit>
hi all. i read about this GW1N-1 FPGA recently. is there any leverage to support it in yosys and make something comparible to icestorm?
cr1901_modern has joined #yosys
<pepijndevos>
blackbit, I'm working on it :)
<blackbit>
nice
<blackbit>
you already have such a board?
<pepijndevos>
I have a Tang Nano with an GW1N-1
<blackbit>
i am ordering two of them right now, though the seeed website is unbelievably slow right now
<pepijndevos>
blackbit, current status of Gowin support is that the Yosys side is fairly decent. Nextpnr not so much. I'm working towards some PoC flow now that can just barely route LUTs and DFF without any special options or hard IP blocks (bram, pll, etc)
<pepijndevos>
I tweet progress updates some times.
<pepijndevos>
Meanwhile working on making a wireless display with one of these ASK breakout boards that talks with Virtualwire/Radiohead: https://github.com/pepijndevos/vhdlwire/
<tpb>
Title: GitHub - pepijndevos/vhdlwire: A VHDL implementation of VirtualWire/RadioHead (at github.com)
<tpb>
Title: Improvements for gowin support by pepijndevos · Pull Request #1449 · YosysHQ/yosys · GitHub (at github.com)
<blackbit>
thanks
kraiskil has quit [Ping timeout: 265 seconds]
citypw has joined #yosys
dys has joined #yosys
citypw has quit [Ping timeout: 265 seconds]
emeb_mac has joined #yosys
emeb_mac has quit [Quit: Leaving.]
kraiskil has joined #yosys
m4ssi has joined #yosys
craigo has joined #yosys
<pepijndevos>
How does one use bugpoint? With the default options it seems to delete the toplevel module and then say all simplifications are exhausted.
<pepijndevos>
What I'm currently doing is read_velilog on a design, and then bugpoint -script with something that does an equivalence check on synthesis
Thorn__ has joined #yosys
cr1901_modern has quit [Ping timeout: 252 seconds]
Thorn has quit [Ping timeout: 252 seconds]
Thorn__ is now known as Thorn
vidbina_ has joined #yosys
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` has joined #yosys
X-Scale` is now known as X-Scale
m4ssi has quit [Remote host closed the connection]
kraiskil has quit [Ping timeout: 246 seconds]
vidbina_ has quit [Ping timeout: 268 seconds]
<ZirconiumX>
pepijndevos: are you triggering something
<ZirconiumX>
If you are, then you should use `-grep`
cr1901_modern has joined #yosys
blackbit has left #yosys ["WeeChat 2.7-dev"]
Laksen has joined #yosys
emeb_mac has joined #yosys
Jybz has joined #yosys
rohitksingh has joined #yosys
emeb has joined #yosys
rohitksingh has quit [Ping timeout: 268 seconds]
Jybz has quit [Quit: Konversation terminated!]
Laksen has quit [Quit: Leaving]
rohitksingh has joined #yosys
<ZirconiumX>
So, I'm trying to implement the yosys test/arch/common tests, and proc_dff bails out with "ERROR: Multiple edge sensitive events found for this signal!"
<ZirconiumX>
I'm probably doing something wrong, but what?
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #yosys
rohitksingh has quit [Remote host closed the connection]