juri_ has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
juri_ has joined ##openfpga
azonenberg has quit [Ping timeout: 276 seconds]
azonenberg has joined ##openfpga
azonenberg_work has joined ##openfpga
OmniMancer has joined ##openfpga
jhol` is now known as jhol
felix_ has quit [Ping timeout: 240 seconds]
felix_ has joined ##openfpga
<OmniMancer>
daveshah: do timing reports give any idea of the hold time requirement?
<daveshah>
No, I've worked on this a bit but it's not upstream
<daveshah>
Some/most vendor tools do though l
<OmniMancer>
I mean in vendor tools
<OmniMancer>
thinking of trying to give a better idea of delays in the generic backend thing to see if that makes the attosoc happier
<OmniMancer>
I suspect having all the interconnect wires have the same delay no matter how far they go is probably not the best practice :/
<daveshah>
You're probably better off implementing global networks as a first step
<OmniMancer>
probably
<OmniMancer>
how hard is a simple C++ backend to start?
<daveshah>
Not very
<daveshah>
But global networks doesn't need that
<OmniMancer>
ah
<daveshah>
Not if you manually instantiate the global buffer
<daveshah>
Giving it interconnect delays etc will only improve setup time, not hold time
<daveshah>
You can eliminate setup time by running everything at a slow clock
<OmniMancer>
ah
<OmniMancer>
how slow is "slow"?
<daveshah>
<5MHz for picorv32
<OmniMancer>
I know my predivider works because my blinking output LED works from that
<daveshah>
probably less than 15MHz if it is known to be faster than a up5k
<OmniMancer>
I need to verify my second LED actually works
<daveshah>
Then it's probably not a setup time issue
<daveshah>
Another thing to check would be that resetn goes high
<OmniMancer>
indeed
<daveshah>
also try a few different seeds and see if the behaviour differs with any
<daveshah>
maybe also try and get pepijndevos's exact verilog
<OmniMancer>
perhaps I can wire that out to another LED
<daveshah>
given that is known working with generic synth as of a week or two ago
<OmniMancer>
does generic only support the simulated annealing placer?
<OmniMancer>
and is it likely that me not using half of the available slices is making the design more spread out than necessary?
<daveshah>
No it supports HeAP so long as you use GENERIC_IOB or have at least one manually constrained cell
<daveshah>
it should default to heap in this case too
<daveshah>
you will get a warning if it has to use SA because neither condition is met
<OmniMancer>
I have manual constraints on the IOBs so that they wind up where they need to be
<OmniMancer>
I should see if I can extract the pad locations from my IO test pnl because it is really annoying to have to search the td chip viewer for pad names
<daveshah>
Then it should be using HeAP
<OmniMancer>
it is using HeAP :)
<OmniMancer>
daveshah: could the issue be clock skew perhaps?
<daveshah>
Yes, hence the previous mention of hold time failures (clock skew --> hold time failure)
<OmniMancer>
Also I think it might be using the clock wires in some cases to route signals which is a bit strange but unsure if that will break anything
<daveshah>
Although I've got away with it on iCE40 and ECP5 and pepijndevos on Gowin, Anlogic might be more fussy
<daveshah>
You could try removing clock wires altogether in case there is something special with them
<OmniMancer>
It could very well be something silly
<OmniMancer>
the clock wires are necessary to get clocks into the tiles
<OmniMancer>
I can remove any pips from the clock wires to any other wires though
<daveshah>
Ack
<daveshah>
Sometimes there are power-saving config bits that need to be set to use clocks
<daveshah>
*clock wires
<daveshah>
it's possible that their bitgen doesn't set them with unusual clock routing
<OmniMancer>
as in, there is a wire in the tile called clk0 which as far as I can tell is the clock input for the two mslices in the tile
<OmniMancer>
that clock input can also be switched into the fabric
<OmniMancer>
It doesn't currently have any global clock wires that are connected to anything interesting, there are some pips from them to the clock inputs in the tiles and SR and CE though
<daveshah>
That sounds like it's alright then
<OmniMancer>
So when I said clock wires I meant the local Tile clock, not the global clock network
<daveshah>
Ah, I see
<OmniMancer>
I need to change my routing fuzzers to use tiles that are atleast 7 tiles away from the edge to avoid pesky special case arcs
<OmniMancer>
but since the tile clock wires can apparently drive the fabric as well I think the router has decided to use them as connections which I don't know if that works
<OmniMancer>
are the seeds randomised each run?
<daveshah>
No, they aren't
<OmniMancer>
am I expected to get the same routes each time then?
<OmniMancer>
(modulo me changing the pips that exist)
<daveshah>
Yes, barring something odd like hash randomisation on the Python side or something
<OmniMancer>
I don't think I am using any hash related things python side, it should just be list iterations
<whitequark>
python has both hash randomization and nondeterministic allocation order, so if you use default __hash__ you'll get varying results even with PYTHONHASHSEED
<daveshah>
I think everything should be deterministic then
<OmniMancer>
does the --check argument have any purpose for the generic backend?
<daveshah>
No
<OmniMancer>
what does it check anyway?
<daveshah>
some arch invariants, but afaik all or almost all are enforced by design in the generic backend anyway
<daveshah>
mostly just naming and location stuff
<OmniMancer>
ah okay
<OmniMancer>
does the trellis database have a different CIB tile for each place it occurs? like one for when they are with BRAM?
<daveshah>
They are all the same, with a few extra bits in some very exceptional ones (like the PLL select config which actually maps to one tie-zero or tie-one bit)
<OmniMancer>
ah
<OmniMancer>
I was wondering how to handle things like the clock and CE invert bits
<daveshah>
I gave them generic names
<daveshah>
actually that was just tie-1/tie-0 bits in the CIB
<daveshah>
the invert bits were in the MIB which is per-function anyway
<OmniMancer>
ah, what does MIB stand for?
<daveshah>
MACO interconnect block
<daveshah>
an entirely archaic name
<OmniMancer>
ah
<daveshah>
but these days it's the tile that includes the actual BRAM/DSP/etc config
<daveshah>
width settings etc
<OmniMancer>
ah
<OmniMancer>
I think for me that would be the emb_slice/emb_32k
<daveshah>
yeah
<OmniMancer>
but there would then be a bunch of fixed connections from some number of PIB wires to the actual BRAM signals
<OmniMancer>
since the routing has a generic, (a,b,c,d)0-7 e4-7 (f,fx,q)0-7 clk0-2 ce0-3 sr0-3
<daveshah>
I put those fixed connections in the MIB tiles
<OmniMancer>
do your MIBs only cover one routing switchbox?
<daveshah>
In general, yes
<daveshah>
DSPs have two MIBs per routing switchbox
<daveshah>
but note some of the fixed connections are actually from an adjacent routing switchbox
<daveshah>
even though EBR0 is split across MIB_EBR0 and MIB_EBR1 for consistency all the fixed connections end up in MIB_EBR0
<OmniMancer>
ah okay you do relativeness in those wires?
<daveshah>
yeah
<OmniMancer>
hmmmm, I wonder how I should do that
<OmniMancer>
perhaps I should work on getting stuff put in the repo for now and then I can just show people results and get advice or help
<daveshah>
yeah, sounds good
<daveshah>
perhaps you can persuade mmicko back too :)
<OmniMancer>
I think I also have the bitstream rotated 90degrees vs trellis
<OmniMancer>
or maybe not
<OmniMancer>
but the tiles are the other way on ecp5
<daveshah>
It's all quite arbitrary really
<OmniMancer>
ECP5 seems to have wide short tiles
<OmniMancer>
eagle has tall thinnish tiles
<OmniMancer>
I believe mmicko got waylayed by work busyness
omnitechnomancer has joined ##openfpga
<OmniMancer>
I figured out how to find this room from matrix :)
<miek>
i'm trying to debug this issue: https://github.com/azonenberg/openfpga/issues/127 - it looks like the "INIT" parameter used to be 0 or 1, but now ends up as "" for that example. i understand there's not really any spec for the json output, so i'm not sure if the bug is in yosys or xc2par - should that param ever be ""?
<daveshah>
The spec for the JSON output is "help write_json" - and it did change to output bit vectors more than often than it did before (instead of integers), although this was really stricter than the previous spec
<daveshah>
This reminds me a bit of the "zero width constant in Verilog" debate, but I can't remember how that one was resolved
<azonenberg>
miek: INIT "" should never happen IMO
<azonenberg>
It should be 0, 1, or the entire attribute should be unspecified
<azonenberg>
Does the DFF in question have an "initial" value?
<miek>
azonenberg: it doesn't
<azonenberg>
Then there should be no init attribute, imo that means a yosys bug
<azonenberg>
As a near term workaround, you can probably use some kind of generic yosys pass to strip empty INIT attributes
<azonenberg>
but yeah, there is no spec so there was no actual contract for the change to violate
<daveshah>
fwiw, the following Verilog also gives similar JSON
<miek>
it looks like xc2par requires it to exist - would it be reasonable to do something like default to 0 if it's empty?
<daveshah>
Not sure - this should probably be an option in `dffinit`
<azonenberg>
yeah
<azonenberg>
not all architectures support init on everything
<azonenberg>
in some cases, having an init attribute might limit you to only using some ffs
<azonenberg>
or in case of asic, it would cause an error
<azonenberg>
So imo the attribute should accurately reflect the intent of the RTL
<azonenberg>
then the toolchain should pick a reasonable default, typically 0, if the architecture requires initialization (like coolrunner) and no init value is provided
<daveshah>
This is about the INIT parameter being set by dffinit, not the general init attribute used by Yosys
<daveshah>
Many arches don't use dffinit at all, so the impact of any change would be fairly small
<daveshah>
imo the best way to do this is something like an optional `-default 0|1` argument to `dffinit`
<azonenberg>
agreed
<OmniMancer>
in an asic do you have to do stuff with reset lines to get init like behaviour
<daveshah>
Yes
<daveshah>
Yosys even has a mode for this `proc_arst -global_arst`
<OmniMancer>
cool
<OmniMancer>
I suppose an ASIC can have an FF which has both an async R and async S as well as D yes?
<daveshah>
Yes
<daveshah>
I think a few FPGAs do/did, but less common
inoaffep is now known as pinoaffe
<OmniMancer>
I suppose one thing making me hesitate upstreaming stuff is how hacky some aspects are :/
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
Guest32339 has quit [Ping timeout: 240 seconds]
ubuntu has joined ##openfpga
ubuntu is now known as Guest41869
freemint has quit [Ping timeout: 245 seconds]
emeb has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
dh73 has joined ##openfpga
Asu has joined ##openfpga
rohitksingh has joined ##openfpga
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined ##openfpga
<whitequark>
TIL Lattice has an iCE65 in dual row QFN
<whitequark>
wait, no, there is an iCE40LP1K in DRQFN too
<whitequark>
or... is it? or is their naming just bad
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined ##openfpga
<whitequark>
yeah it looks like there is an LP1K in DRQFN
<whitequark>
the QN84 one
rohitksingh has quit [Ping timeout: 245 seconds]
<davidc__>
"I'd like a package that confounds most PCB assemblers" said no dfm person ever
<ZirconiumX>
"I'd like our package names to be unpronounceable short acronyms as a shibboleth for non-EEs" - apparently all of them?
<daveshah>
I heard a very cursèd unconfirmed rumour that the new Lattice series might include an 84-pin DRQFN backward compatible with up5k footprints using the outer layer only
<TD-Linux>
is the thermal pad small enough for that to work?
<sorear>
so you can replace a single-ring QFN up5k in a design with the new chip, leaving the entire inner ring NC?
<davidc__>
daveshah: seems to me that PCB footprint backwards compat is the least of ones worries when doing an FPGA migration
<davidc__>
Some friends tried to do a design with a fairly tight pitch DRQFN and went through 3 assembly houses before giving up and choosing a more expensive package part
<davidc__>
(seems that the DRQFN variant was dirt cheap because nobody wanted the damn things because they had terrible yield)
mumptai has joined ##openfpga
<daveshah>
This is just a rumour I heard but I imagine the inner ring would be all IO so could short to ground without problem
m4ssi has quit [Remote host closed the connection]
<daveshah>
Yes, I think the mux is separate from the carry enable
<daveshah>
But nextpnr currently uses I3 as the best guide as to when to pack the carry or not because of what synthesis usually produces
<tnt>
yeah, I figured.
<azonenberg>
davidc__: I would rather do 0.35mm WLCSP than DRQFN honestly
<azonenberg>
Larger pitch BGA to DRQFN isn't even a question
Jybz has joined ##openfpga
dh73 has quit [Quit: Leaving.]
rohitksingh has quit [Ping timeout: 240 seconds]
dh73 has joined ##openfpga
rohitksingh has joined ##openfpga
Bob_Dole has joined ##openfpga
rohitksingh has quit [Ping timeout: 265 seconds]
freemint has quit [Ping timeout: 245 seconds]
horizon_ is now known as horizon
horizon has quit [Changing host]
horizon has joined ##openfpga
pie_ has quit [Ping timeout: 265 seconds]
<anticw>
davidc__: what's the issue assembly houses have with DRQFN? lack of experience or is there something about the pkg that makes optical alignment more problematic?
pie_ has joined ##openfpga
freemint has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
<davidc__>
anticw: very unforgiving of alignment (both component and solder paste), and sensitive to the exact amount of solder paste printed
<davidc__>
anticw: they had no-end to bridging problems at every fab (using the manufacturer recommended footprint/solderpaste layout, etc)
<davidc__>
anticw: contributing to the problem was that none of the fabs had dealt with tight pitch DRQFNs before with that high pin count, so they were just as much in the dark about how to solve the issues
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
<anticw>
davidc__: ah ok, i recall coming up with a part# (not fpga) for something a while ago and decided hand-[re]working wouldn't be easy and stuck to QFN48
<anticw>
davidc__: bridging issues are worse than bga because of the relatively large size of the pads and hence large amount of paste you end up with?
<davidc__>
anticw: and because of the limited clearance between package and PCB. any excess solder on one pad gets squeezed out and can bridge
<davidc__>
I seem to recall that when they tweaked the amount of solderpaste down a bit, they started getting opens
<pie_>
sounds like a bad time
<pie_>
why do they still use it
<anticw>
actualy i think it might have been an ICE40LP1K-QN84 and i decided i couldn't do that by hand and ordered ICE40UP5K-SG48I instead as i wanted cheap ice40 devices i could hand solder with an internal oscillator
<davidc__>
pie_: eh, I'm sure that with the right fab they are no problem. Also - fabs probably have more experience with those packages so know how to solder them
<pie_>
aha
<TD-Linux>
the big thermal pad is a nice advantage over bga. also probably qfn is cheaper
<TD-Linux>
dunno if thermals ever matter on an ice40 tho
<tnt>
TD-Linux: the thermal pad is the only GND pin on the up5k so it kind of matters for that :)
<tnt>
but yeah, for thermals ... ice40 doesn't really heat up unless you're driving lots of IO currents.
<tnt>
(or if you power its vcore with 3v3 ...)
dh73 has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
nrossi has quit [Quit: Connection closed for inactivity]
finsternis has quit [Remote host closed the connection]
<daveshah>
tnt: oh, I couldn't resist trying the 3v3 vcore now
<daveshah>
ring oscillator frequency increases 4.3x
<daveshah>
that should give it timing close to an ECP5 :)
<tnt>
daveshah: lol
<anticw>
TD-Linux: is the thermal pad needed given worse case on ice40 is still quite low power?
finsternis has joined ##openfpga
<TD-Linux>
I mean I usually use the tqfp packages so no :)
freemint has quit [Ping timeout: 245 seconds]
<anticw>
yeah, one think about qfn is i can hand solder to the pan from the other side when there is a hole
genii has quit [Quit: Time for beer and hockey.]
<omnitechnomancer>
daveshah: I had a thought about what could be wrong with more complex designs, I am not sure if I need to set anything for the F output to provide the LUT output, but I think this is not a problem since I added some inverters to the blinky case for driving the LED pad before and they work
<daveshah>
omnitechnomancer: you could probably determine that looking at the pnl file for something like an AND gate design built with the anlogic tools?!
<daveshah>
*?
<omnitechnomancer>
Yes, I don't remember any settings for the mslice for this, I have set the FF input mux to F, I will double-check tonight
freemint has joined ##openfpga
<omnitechnomancer>
The lslices have a mux that picks between the F LUT output and the LUT5 mux
Asu has quit [Quit: Konversation terminated!]
Bob_Dole has quit [Ping timeout: 250 seconds]
dh73 has joined ##openfpga
mumptai has quit [Remote host closed the connection]