<edbordin>
omnitechnomancer yeah, I wrote a couple of lines of bash instead. man these fuzzers really do take a while :P
<omnitechnomancer>
there is a LOT of routing
<omnitechnomancer>
are you running the trellis or tang ones?
<edbordin>
tang
<edbordin>
I mainly wanted to check the tools were working and then figured it couldn't hurt to just start running the lot
<omnitechnomancer>
basically everything except the routing ones should be fast
<omnitechnomancer>
the routing ones are trial and erroring every possible routing connection of specific types
<edbordin>
yeah I could see it was basically a case of combinatorial explosion hehe
<edbordin>
anyway I'll just leave it running for now. I'm a bit tired today so wouldn't have gotten much further anyway
<edbordin>
hmm, I'm having trouble finding a .db that has anything in it after fuzzing though
<edbordin>
omnitechnomancer after fuzzing mslice_lut_init are the results supposed to be in prjtang/database/eagle/tiledata/plb/bits.db ?
<omnitechnomancer>
yes, if you want html run tools/html_all.py and give it an output directory as an arg
<edbordin>
the .db file is empty :/
<omnitechnomancer>
those fuzzers will wind up adding stuff to pib and plb
<omnitechnomancer>
hmmm
<omnitechnomancer>
interesting
<edbordin>
well, it has the headings "# Routing Mux Bits\n\n# Non-Routing Configuration\n\n# Fixed Connections"
<omnitechnomancer>
hmmmm
<edbordin>
I stole create-empty-db.sh from prjtrellis so perhaps I haven't initialised it properly
<omnitechnomancer>
um
<omnitechnomancer>
there should be a create-empty-db.py in the tools dir to run
<edbordin>
ah I see it. "create_empty_bitdbs.py"
<omnitechnomancer>
but it just makes those files in those folders so the db code in the library doesnt complain
<edbordin>
hmm, well. I guess I'll try building the folders with your script and see if it starts working
<omnitechnomancer>
oh one question
<omnitechnomancer>
what did you run before all this?
<edbordin>
source environment.sh
<omnitechnomancer>
did you run annotate_tilegrid.py?
<omnitechnomancer>
at some point after extracting it
<edbordin>
and to build the C++ I just did "cmake . && make"
<edbordin>
no I did not run annotate_tilegrid. that would probably be the problem
<omnitechnomancer>
yes
<omnitechnomancer>
that is what staples the tile sizes into the tilegrid
<omnitechnomancer>
I really should list the steps in the README.md
<edbordin>
looks like create_empty_bitdbs.py expects a directory structure to already be there
<omnitechnomancer>
it will want the tilegrids I think
<edbordin>
oh right. *facepalm*
<edbordin>
I just had to order wrong
<edbordin>
the order*
<omnitechnomancer>
run get_tilegrid_all.py then annotate_tilegrid.py then the empty bitdbs one
Jybz has joined ##openfpga
<omnitechnomancer>
then the fuzzers should work
<edbordin>
roger that
<edbordin>
OK, yeah. the script from trellis didn't run annotate_tilegrid which is why it almost worked but didn't
<omnitechnomancer>
annotate_tilegrid is not a trellis thing
<omnitechnomancer>
trellis gets the benefit of the toolchain telling you how large the tiles are in the bitstream
<edbordin>
yep. in summary trying to copy trellis was not a good idea on my part
<omnitechnomancer>
for tang the ones I know I had to work out from repetitions in positions
<omnitechnomancer>
copying trellis is fine as long as you make necessary adjustments
<edbordin>
yeah, that's better. it's building the db now
Asu has joined ##openfpga
jjjaaaccckkk has quit [Remote host closed the connection]
Zorix has quit [Ping timeout: 260 seconds]
Zorix has joined ##openfpga
_franck_ has quit [Ping timeout: 246 seconds]
<ZirconiumX>
I've got to really admire Intel's commitment to open source
<ZirconiumX>
Putting debug symbols in the release builds of Quartus
<ZirconiumX>
omnitechnomancer: do Anlogic have internal muxes like ECP5 appears to? (So you can mux up to bigger LUTs)
<omnitechnomancer>
ZirconiumX: some stuff in the sim models implies they do, but I think only the ones that combine the two LUTs in a slice are ever used AFAIK
<ZirconiumX>
Ah, I see; so that means it still tops out at LUT5 then?
<omnitechnomancer>
They have a mux that lets you use one of the MI inputs (the one that usually can feed the FF directly) as another MUX input to combine both LUTs into a bigger one, so the mslices become LUT5s and the lslices LUT6s
<ZirconiumX>
Altera seem to have no way of muxing beyond what a single ALM provides
<omnitechnomancer>
There is an implication that there is a similar situation to the ECP5 going on with the other MI input muxing other stuff together but I am not sure if it never worked out or if they couldnt make the tools effectively use it so they dumped it from the tools
<omnitechnomancer>
the datasheet mentions being able to combine up to LUT7
<ZirconiumX>
Sounds like something fun to investigate
<omnitechnomancer>
but the tools map output only seems to use up to LUT6
<omnitechnomancer>
so perhaps there is more but it would need someone to do some bitstream fiddling to find out with an actual chip
<omnitechnomancer>
for now I will not bother to look into it since other stuff is higher priority for having anything useful occur
<ZirconiumX>
omnitechnomancer: did I mention that I wrote an ALM packing pass for Yosys to get a better idea of area?
<omnitechnomancer>
ZirconiumX: no you did not
<ZirconiumX>
Using PicoSoC as a benchmark, Quartus produces 2.4k ALMs in balanced mode and 1.9k ALMs optimising for size
<ZirconiumX>
Yosys gets 2.6k ALMs, but my packing is not the most efficient in the world
<omnitechnomancer>
Ah
<omnitechnomancer>
I actually do wonder how one handles a flow that makes too large a number of large LUTs such that they cant all be placed, do you just fail and tell the user to give synth different settings?
<ZirconiumX>
Pretty much; it's a placement constraints just like running out of multipliers
<ZirconiumX>
My ABC9 lut table has LUT6s listed with twice the area of the others
<ZirconiumX>
Which makes ABC dial down on LUT6 packing everything it can
<omnitechnomancer>
ah okay you can tell it how much area things take up
<omnitechnomancer>
I guess one problem I will have is that LUT5s and LUT4s kind of have equal area, but if you have more than a certain number of LUT5s they cant place anymore
<omnitechnomancer>
or start eating larger area
<omnitechnomancer>
because there are two ways to make a LUT5
<ZirconiumX>
The Cyclone V is actually pretty slow in terms of logic delay, and Quartus must pull off a bloody miracle to get it to run as fast as it does
<omnitechnomancer>
interesting
<ZirconiumX>
Like, if you want to build an adder, the delay from input to carry-out is like 1.2ns
<ZirconiumX>
Which is pretty huge
<omnitechnomancer>
because yea, LUT4 can be placed in the LUTs on any slice, LUT5 can take a whole mslice or half of an lslice, LUT6 takes a whole lslice
<ZirconiumX>
Honestly, try to pull up some delay numbers and prototype
<omnitechnomancer>
Also if you have two LUT4s with common inputs you can place them both in one half of one of the LUTs in a n lslice
<ZirconiumX>
That's what I did
<omnitechnomancer>
That will probably help figure out the best one, for speed
<ZirconiumX>
Yosys instructs ABC to optimise first by delay and then by area
<ZirconiumX>
(thus if you look at the ABC9 stats, delay will decrease first before area does)
<omnitechnomancer>
ah yep
<omnitechnomancer>
though I cant imagine the ECP5 multi slice muxed wide luts win that much in delay?
<omnitechnomancer>
I guess they might over building it out of more LUTs
Patater_ is now known as Patater
<ZirconiumX>
omnitechnomancer: An ECP5 LUT6 is 618ps; a CV LUT6 is 605ps, but an ECP5 LUT4 is 379ps to the CV's 462ps
<omnitechnomancer>
Ah yes I see, so chaining slices very slightly slower than a CV LUT6 but LUT4s are faster
<omnitechnomancer>
can you get any improvement by picking which intputs to use for the LUT4?
<ZirconiumX>
And you're more likely to encounter LUT4s than LUT6
<ZirconiumX>
It's a bit tricky to measure
<omnitechnomancer>
I know ECP5 has variable delay depending on which inputs are used, so when doing <4 width it matters which ones you pick as your inputs
<ZirconiumX>
An ALM has overprovisioned I/O - 8 combinational inputs, and a whole host of outputs
<ZirconiumX>
Indeed, that applies for the CV
<ZirconiumX>
But you end up with two LUT4s in an ALM
<omnitechnomancer>
because really its a tree of MUXes with 16 config cells
<omnitechnomancer>
providing the LUT values
<omnitechnomancer>
do those two LUT4s have equal or unequal delay?
<ZirconiumX>
Equal, judging by the numbers I have and my general knowledge of the ALM
<ZirconiumX>
Because they're delays relative to the combinational outputs
<omnitechnomancer>
yes
_franck_ has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Bike has joined ##openfpga
Bob_Dole has quit [Ping timeout: 260 seconds]
Bob_Dole has joined ##openfpga
<tnt>
In nmigen, can you define a platform that always include a given submodule and that has resource that are connection to that always included submodule rather than IO pins ?
<whitequark>
no, but this has been requested by ZirconiumX as well
<whitequark>
can you open an issue? I'll need to think of a design
<whitequark>
but it has to be supported eventually
<whitequark>
what do you need it for? hard CPU?
<tnt>
no, actually, a "soft cpu + usb core" that's just exposed as a fifo in/out to the user of that platforms.
<whitequark>
ok, so it can't be just an Instance, hmmm
<whitequark>
I'm actually not sure if nmigen's platform interface is entirely appropriate for this
<whitequark>
but let's not be overly strict here
<whitequark>
it doesn't seem too inappropriate either
<whitequark>
ok, yes, please open an issue and list your wishes/requirements in detail
<tnt>
well, this would probably end up being an existing design that already exists in verilog, so it wouldn't be far from an "Instance".
<whitequark>
"not far" and "is specifically" is quite different here wrt some possible implementations I had in mind
<tnt>
ok sure. Writing an issue now with as much details I can think of.
lutsabound has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 272 seconds]
freemint has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
<tnt>
In nmigen, I get DeprecationWarning: instead of `Signal(min=0, max=123)`, use `Signal(range(0, 123))`
<tnt>
Is it really range(0,123) or should it be range(0,124) ?
<tnt>
Oh wait, no the 'max=' was already exclusive in the previous notation (so more like maxvalue+1 and not maxvalue)
<whitequark>
yes
<whitequark>
which is why I deprecated it
<whitequark>
it was very confusing
ZirconiumY has joined ##openfpga
ZirconiumX has quit [Ping timeout: 252 seconds]
ZirconiumY is now known as ZirconiumX
Laksen has joined ##openfpga
Laksen has quit [Client Quit]
Bob_Dole has quit [Read error: Connection reset by peer]
Bob_Dole has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
Bob_Dole has joined ##openfpga
diadatp has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
<tnt>
How do I stop nmigen from creating the SB_IO ?
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
<tnt>
ok, got it : dir="-"
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
Asu has quit [Remote host closed the connection]
<omnitechnomancer>
whitequark I think something like what tnt wanted would be helpful for exposing the package bonded SDRAM in some of the Anlogic FPGAs in an easy to use fashion, though that can just be an Instance
edbordin has quit [Ping timeout: 260 seconds]
<tnt>
whitequark: Would you have any objection to supporting .il file in platform.add_file ? Obviously that would only work for yosys ... not sure if that's an issue to have something only supported on ECP5/ice40.