Lofty changed the topic of #prjmistral to: Project Mistral: Yosys (and hopefully nextpnr) on Cyclone FPGAs - https://github.com/ZirconiumX/mistral - logs: https://freenode.irclog.whitequark.org/prjmistral
frubbl has joined #prjmistral
frubbl has quit [Ping timeout: 240 seconds]
frubbl has joined #prjmistral
hansfbaier has joined #prjmistral
frubbl has quit [Ping timeout: 246 seconds]
frubbl has joined #prjmistral
frubbl has quit [Ping timeout: 265 seconds]
frubbl has joined #prjmistral
_whitelogger has joined #prjmistral
hansfbaier has quit [Quit: WeeChat 2.8]
_whitelogger has joined #prjmistral
_whitelogger has joined #prjmistral
frubbl has quit [Ping timeout: 265 seconds]
frubbl has joined #prjmistral
frubbl has quit [Ping timeout: 256 seconds]
frubbl has joined #prjmistral
<Sarayan> How do I trigger a post-fit timing analysis already?
frubbl has quit [Ping timeout: 265 seconds]
peeps[zen] has joined #prjmistral
peepsalot has quit [Ping timeout: 272 seconds]
_whitelogger has joined #prjmistral
<Lofty> Sarayan: quartus_sta
frubbl has quit [Ping timeout: 256 seconds]
<Sarayan> thanks
<Sarayan> I'm doing the "make dmp files" dance, requires no efforts :-)
frubbl has joined #prjmistral
<Lofty> So, I'm looking through mux_to_source.py and I think I've found...not quite a bug, but something weird
<Lofty> The bit locations are single-element lists of lists
<Lofty> e.g.
<Lofty> 'bits': [[[29, 84]], [[29, 76]], [[29, 68]], [[29, 60]], [[29, 52]], [[29, 1]], [[29, 9]], [[29, 17]], [[29, 25]], [[29, 33]]]
<Sarayan> hmmm
<Sarayan> well, first level is per-instance
<Sarayan> second level is per-bit
<Sarayan> thrid level if it exists is for 2D coordinates
<Sarayan> so there you have ten instances (labcell I guess) of a one-bit mux (probably a boolean) on cram
<Sarayan> (cram being 2d)
<Lofty> Anyway, I hacked at mux_to_source.py to get a CSV dump of bit locations
<Lofty> There's a surprising amount of unused space here
<Lofty> Unless all of these are routing muxes
<Sarayan> no
<Sarayan> inner block rectangles and routing network bits are fully disjoint
<Sarayan> note that there is no cost associated with not using a bit
<Sarayan> the chip charges horizontal lines with the contents of one column, then triggers a specific column write signal
<Lofty> No cost for the FPGA, but some cost for the user of the chip :P
<Sarayan> things that have a bit just copy from the horizontal line on the strobe
<Sarayan> so there's no cram-sized memory anywhere
<Sarayan> I suspect rougly half the surface is actually used
<Sarayan> the pram is more dense, because there it's all shift registers, so bits are real
frubbl has quit [Ping timeout: 256 seconds]
<Sarayan> cute
<Sarayan> 1/10th of the LAB, but cute :-)
<Lofty> Sarayan: I couldn't fit the entire thing on my screen :P
<Sarayan> Lofty: told you, the scale of the damn thing :-) I can't fit the cram on my screen
<Sarayan> and it's 4K
<Sarayan> but 7605x7024 is way more than that
<Sarayan> The smallest is 3856x3412
<Sarayan> (gx25f)
<Sarayan> interesting, there are a ton of model.ddb files that are temperature but not speed rate dependant
<Sarayan> unless tt/ss/ff are rates
<daveshah> Those could be rates or corners
<daveshah> t=typical s=slow f=fast
<Sarayan> oh, interesting
<Sarayan> you're probably right
<Sarayan> I have 'ii' too :-)
<Sarayan> but it's rarer
<Sarayan> Makes me wonder if the speed grade is a routing thing only
<daveshah> ii=industrial?
<daveshah> That would be surprising, but possible
<Sarayan> these models being common for all 7 dies and not dependant on the speed grade
<Sarayan> nah, there's the temperature too
<daveshah> As speed grades are somewhat arbitrary, could the code just be adding a fixed percentage for the slower grades?
<Sarayan> but it's not a model, it's a jspice thing with model in the name, go figure
<Sarayan> could be, could be
<Sarayan> well, gonna start by trying to understand the files, they're not simple :-)
<daveshah> Mmm
<daveshah> Spice models will be fun to implement in a sufficiently fast way
<daveshah> Although I guess you only need spice for sign-off and you can use faster abstractions during the place and route algos themselves
<Sarayan> seems to be what they do
<daveshah> Nice
<Sarayan> I suspect the dmf files to be sim results
<daveshah> Interesting
<Sarayan> daveshah: when a method is called "get_real_speedgrade_and_set_scaling_factors", I kinda think you're probably right :-)
<daveshah> lmao
<daveshah> If its like Lattice when you actually build a ring oscillator all the speed grades will be the same anyway
bwidawsk has quit [Read error: Connection reset by peer]
bwidawks has joined #prjmistral
bwidawks is now known as bwidawsk
peeps[zen] is now known as peepsalot
hansfbaier has joined #prjmistral
frubbl has joined #prjmistral
frubbl has quit [Ping timeout: 260 seconds]