carl0s has quit [Remote host closed the connection]
_whitelogger has joined ##openfpga
mickdermack has joined ##openfpga
davidw has joined ##openfpga
davidw is now known as Guest54885
davidthings has quit [Read error: Connection reset by peer]
Bike has quit [Quit: Lost terminal]
Guest54885 has quit [Read error: Connection reset by peer]
Guest54885 has joined ##openfpga
Guest54885 has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
davidthings has quit [Read error: Connection reset by peer]
Jybz has joined ##openfpga
OmniMancer has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
emeb_mac has quit [Quit: Leaving.]
freemint has joined ##openfpga
rohitksingh has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
henriknj has quit [Remote host closed the connection]
swedishhat[m] has quit [Remote host closed the connection]
scream has quit [Remote host closed the connection]
jfng has quit [Remote host closed the connection]
nrossi has quit [Remote host closed the connection]
galv[m] has quit [Read error: Connection reset by peer]
synaption[m] has quit [Remote host closed the connection]
xobs has quit [Read error: Connection reset by peer]
thehurley3[m] has quit [Remote host closed the connection]
pepijndevos[m] has quit [Write error: Connection reset by peer]
pepijndevos[m] has joined ##openfpga
<tnt>
Does the ECP5 not have async reset in its FF ?
<mwk>
it does have async resets
<daveshah>
What you can't have is an async set/reset to something different to the init value
<OmniMancer>
I suppose anlogic already having some yosys support will help with knowing what knobs there are on the slices
<tnt>
daveshah: yeah, that's fine. I'm just seeing weird things.
<OmniMancer>
the lslices are definitely 4 LUT4s rather than just LUT5s but that isn't exactly unexpected I guess
<OmniMancer>
daveshah: are the RNCN tile names in trellis the way the lattice tools refer to the tiles?
<daveshah>
Yeah they are
<OmniMancer>
would it in general be best to match the vendor tools naming of things?
<mwk>
usually yes
<mwk>
unless it's something brain-dead
<tnt>
https://pastebin.com/N32PjHcb Pretty classic snippet I use almost everytime I have a PLL (to make sure logic is reset properly only when pll provides a clock). With that version, design fails (reliably) in weird unexplanable ways. If I remove the async reset on pll_lock, works just fine / reliably.
<mwk>
*cough* spartan 6 tile naming *cough*
<OmniMancer>
mwk: I think anlogic names the tiles with xNyN but the y is upside down
<mwk>
which way is up?
* mwk
doesn't really consider any of the directions the Right Proper Way™
<OmniMancer>
As in y0 is the end of the frame not the beginning
<mwk>
although it would be really nice if vendor could decide on a single one in their tools
<mwk>
ah heh
<mwk>
is it up or down on the chip though?
<OmniMancer>
and y71 (in the eagle_s20 which is what I care about immediately) is first
<OmniMancer>
In what sense?
<OmniMancer>
mwk: as yet I do not have one of the chips and I am unsure it matters that much
<mwk>
yeah, well, chips can be rotated of course
<mwk>
but a lot of things on the chip tend to be named by geographical directions (for some reason)
<mwk>
so it helps to know which way is south when you see a "south X1" wire
scream has joined ##openfpga
thehurley3[m] has joined ##openfpga
galv[m] has joined ##openfpga
nrossi has joined ##openfpga
jfng has joined ##openfpga
henriknj has joined ##openfpga
xobs has joined ##openfpga
synaption[m] has joined ##openfpga
swedishhat[m] has joined ##openfpga
<OmniMancer>
mwk: ah yes, I will have to check cause I suspect such might be true here too for now I sort of just want to work out how large the tiles are
<OmniMancer>
row is usually the vertical co-ord right?
<mwk>
yes
<mwk>
although opinions differ on whether row 1 is bottom or top
<mwk>
or maybe row 0, who knows
<mwk>
on xilinx, it can even depend on what kind of rows you're counting at the moment (sigh)
<whitequark>
can't row 1 just be a switch
<mwk>
... whitequark
<whitequark>
sorry
<OmniMancer>
so all of the project trellis co-ordinates are the opposite way round to the conventional mathematics ordering then
<mwk>
(that btw does happen on Virtex 4+ row numbering in bitstream, wherein you specify rows as index + top/bottom)
<whitequark>
lmao
<mwk>
(so row top 0 is the row immediately above config center, rot bottom 0 is the row immediately below)
<OmniMancer>
so it has helpful integer co-ordinates
<OmniMancer>
but ones compliment co-ordinates
<OmniMancer>
both + and - 0
<daveshah>
In ECP5 row 0 is top, fight it :)
<daveshah>
iCE40 is more crazy because it rotates 90 degrees between the two vendor tools
<mwk>
whitequark: in nouveau we had a policy on avoiding jokes about demented things the hw could be doing, since they tended to come true way too often :(
<whitequark>
mwk: ouch
<whitequark>
can i OH that
<mwk>
sure
<mwk>
(another fun fact: the "config center" is just the place where the configuration circuitry is, it doesn't really have to be in the center of the FPGA, so there are FPGAs with several more bottom rows than top rows, or the other way around)
<mwk>
(also, for series 7, it may or may not be on the same y coordinate as the "clock center", which is the place where the global clock buffers/multiplexers are)
<tnt>
Can anyone decode this supposed combinatorial loop: https://pastebin.com/JarC9pyt I jus don't see where that error message shows me a loop.
<daveshah>
Combinational loop printing is yet another thing in nextpnr that needs fixing
<tnt>
Oh wait ... I think I was reading this wrong. each 'remaining' is an independent path, it's not the steps through a single path.
<daveshah>
Yeah, they are all nodes that weren't fully reached because of a loop in the graph
<OmniMancer>
mwk: can there be FPGAs where the config centre is just on the top or bottom?
<daveshah>
Well, the iCE40 doesn't really have one
<daveshah>
But if it did it would be at the bottom
<mwk>
OmniMancer: the config center is spread across row top 0 and row bottom 0, so you have to have at least one top and at least one bottom row (on series 7)
<mwk>
*except* the smallest spartan 7, where the whole device has only a single row, row bottom 0
<mwk>
and these have the functionality normally present in tow top 0 (system monitor and bitstream encryption) missing
<mwk>
and of course there are fpga families that don't put their config functionality in the center, instead stuffing it in the corner
<mwk>
or spreading it around corners/edges/...
<mwk>
eg. viertex 2, spartan 3*, spartan 6
<OmniMancer>
Indeed, I think Anlogic has various misc tiles for such settings scattered around the edges
<mwk>
yep
<mwk>
the pre-virtex 4 xilinx FPGAs had it concentrated in the whole corners
<mwk>
er
<mwk>
*four corners
freemint has quit [Ping timeout: 252 seconds]
X-Scale` has joined ##openfpga
davidthings has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale has joined ##openfpga
X-Scale` has quit [Ping timeout: 265 seconds]
freemint has joined ##openfpga
<OmniMancer>
daveshah: are the individual bit names from the bit database manually populated?
<daveshah>
OmniMancer: what do you mean?
emeb has joined ##openfpga
<OmniMancer>
daveshah: Ah I think what I meant is the mux arc names and config enum names
<OmniMancer>
but the word type bits do not seem to be named
<daveshah>
They come from the fuzzer Python
<daveshah>
The arc names are automatic, the enum options are usually manually specified in those scripts
<daveshah>
Word bits aren't named because they are just an ordered list of bits in the config word
<OmniMancer>
Indeed I see better now looking at it a while
<OmniMancer>
The Anlogic tools do have names for each LUT init bit, I am wondering if that should be recorded somewhere
<daveshah>
The Lattice tools do, you see it in the bstool dump, but I didn't bother
<OmniMancer>
I see
<daveshah>
They were very Lattice internal names and only increased legal risk, providing no real help to parsing or generating bitstreams
<OmniMancer>
I have done a somewhat hacky importing of a bunch of libtrellis stuff except for the routing graph, bels and deduplicating db, but have not attempted to do anything more than build it, tomorrow I will see if I can use the python module to look at bit differences
<OmniMancer>
I see, the names I see for Anlogic seem to be pretty much just a string that gives the index of the slice, lut and bit number so likely not too important
OmniMancer has quit [Quit: Leaving.]
genii has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
david__ has joined ##openfpga
davidthings has quit [Read error: Connection reset by peer]
david__ has quit [Remote host closed the connection]
ironsteel has joined ##openfpga
mumptai has joined ##openfpga
Thorn has quit [Ping timeout: 268 seconds]
freemint has quit [Ping timeout: 276 seconds]
<kc8apf>
7-series coordinates keep getting worse the deeper you go
<ZirconiumX>
Well, so far Quartus has four levels of nested coordinates
<ZirconiumX>
e.g. X32Y12S0I16
<kc8apf>
after the top/bottom (which is where the global clock buffers are) and the rows (growing outward from the global clock buffers), columns are a count of tiles from one side of the row.
<kc8apf>
of course rows can have different lengths
<kc8apf>
and then there's the whole tile type thing where the same (top/bottom, row, column) scheme is applied to completely different topologies
ironsteel has quit [Remote host closed the connection]
<kc8apf>
mostly so BRAMs can be loaded
<ZirconiumX>
Oh wonderful.
ironsteel has joined ##openfpga
ironsteel has quit [Remote host closed the connection]
Jybz has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
lain has quit [Remote host closed the connection]
lain has joined ##openfpga
q3k has quit [Ping timeout: 240 seconds]
implr has quit [Ping timeout: 240 seconds]
q3k has joined ##openfpga
implr has joined ##openfpga
implr_ has joined ##openfpga
implr_ has quit [Client Quit]
AndrevS has joined ##openfpga
Thorn has joined ##openfpga
<pepijndevos>
Has anyone tried to fit an Arduino core on an ice40?
<pepijndevos>
Or rather: what's the smallest FPGA you can fit an Arduino core in?
<daveshah>
The limited user flash might be a problem
<pepijndevos>
I'll probably end up just implementing the protocol in VHDL.
<daveshah>
I'm sure bare metal code on a small softcore would be fine
<goran-mahovlic>
I also have an Arduino system running on SaxonSoc, the software side of which is based on your f32c/arduino system. The ULX3S is probably overkill for that.
<goran-mahovlic>
And this is really nice to know -- I think @Dolu1990 managed to fit the SaxonSoc Linux system onto an 8k ice40, so 24k should not be a problem.