pie__ has joined ##openfpga
lexano has quit [Ping timeout: 254 seconds]
DocScrutinizer05 has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
pie_ has quit [Remote host closed the connection]
lexano has joined ##openfpga
prpplague has joined ##openfpga
_whitelogger has joined ##openfpga
promach__ has joined ##openfpga
<azonenberg> qu1j0t3: so, as of now
<azonenberg> gen 5 is not supported at all
<azonenberg> the two larger gen 4 devices (46620/46621) are almost finished
<azonenberg> the smaller (46140) needs a bit more work
<azonenberg> my focus for this next few weeks is static timing analysis
promach__ has quit [Quit: Leaving]
<pie__> whitequark, how do i go about understanding your furnace stuff
<azonenberg> pie__: no, rqou is helping me with the greenpak stuff
<azonenberg> sorry i meant
<azonenberg> gaah
<azonenberg> rqou is helping me with the coolrunner stuff
<azonenberg> :p
<azonenberg> greenpak is me on PAR, whitequark on USB/programming, and clifford helping a bit with synthesis
<pie__> oh
lexano_ has joined ##openfpga
lexano has quit [Ping timeout: 255 seconds]
<qu1j0t3> azonenberg: thanks for the update!
<azonenberg> grr my app now runs a lot faster and gives wrong answers
<azonenberg> lol
<whitequark> pie__: hm?
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHawT
<openfpga-github> openfpga/master 5f47939 Andrew Zonenberg: Various optimizations to LUT delay characterization
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
Finnpixel has quit [Ping timeout: 260 seconds]
<digshadow> azonenberg: cool
<azonenberg> ok so, i'm gonna add code to measure delays for the inverters
<azonenberg> Then start working on falling delays
m_w has quit [Quit: leaving]
<azonenberg> Lord_Nightmare:
<azonenberg> (21:55:12) azonenberg: You do not lose access to io pins
<azonenberg> (21:55:15) azonenberg: and its not external rom
<azonenberg> (21:55:28) azonenberg: the NVM is OTP
<azonenberg> (21:55:24) azonenberg: it's built like the coolrunner, NVM loaded into sram which controls the actula device behavior
<azonenberg> the devkit does this in parallel
<azonenberg> and it still needs HV Vpp
<azonenberg> so not in circuit programmable (yet)
<azonenberg> although rumor has it the next-generation may be?
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 245 seconds]
digshadow has quit [*.net *.split]
laintoo has quit [*.net *.split]
pointfree has quit [*.net *.split]
digshadow has joined ##openfpga
laintoo_ has joined ##openfpga
pointfree has joined ##openfpga
m_t has joined ##openfpga
<pie__> whitequark, i mean do i just start drilling down in source files?
<rqou> azonenberg: why does xbpar not have a "WriteDOT" debug tool?
<pie__> im not really a ruby guy
<azonenberg> rqou: good question
<azonenberg> i added one to splash for visualizing the dependency graph
<azonenberg> and yosys can i think export a graphviz render of the post-synth netlist
<azonenberg> but i dont have one in xbpar/gp4par that i know of
<pie__> whitequark, which foundry does furnace instrumentation.md refer to?: "Instrumentation data is produced by Foundry as streams of events dumped"
<openfpga-github> [openfpga] rqou opened issue #91: Add a debug helper to dump xbpar graphs https://git.io/vHaQT
<rqou> azonenberg: why are node names interned/stored as an integer but edge port names are not interned?
<azonenberg> explain?
<azonenberg> also about to go to sleep, so i'll probably respond in the morning
<rqou> your PARGraph has an AllocateLabel method that you essentially use to convert all strings into a number
<azonenberg> Oh
<rqou> and then all comparison operations can just be done on that number
<azonenberg> well its not exactly that
<azonenberg> labels and node types are not 1:1
<azonenberg> for example a GP_4LUT site is legal to place a GP_2LUT instance in
<azonenberg> so it's tagged with both
<azonenberg> a GP_IBUF, GP_OBUF, or GP_IOBUF can all be placed in a GP_IOBUF site
<rqou> but edge ports are just std::string rather than being mapped to an integer
<azonenberg> Yes, because that's always 1:1
<rqou> hmm ok
<azonenberg> the placer, in fact, doesn't really care about port names right now
<azonenberg> it cares about nodes only
<rqou> um... oh
<azonenberg> then once it has a placement the router will rip up and swap things as needed to make connections work
<rqou> that might be a little problem for the code i wrote
<azonenberg> oh?
<rqou> oh the router does check?
<rqou> then it's probably fine
<azonenberg> the router checks and moves stuff around
<azonenberg> initial placements are routinely unroutable due to e.g. lack of paths to hard IP
<azonenberg> well ok let me fix terms
<azonenberg> The initial placer is dumb
<azonenberg> the optimizing placer knows about what's routable
<rqou> yeah but i don't care too much about that at this point
<azonenberg> then the actual router is currently dumb since any placed greenpak netlist only has one legal routing
<azonenberg> But the optimizer will correct situations where a path doesnt exist
<azonenberg> it does so stupidly and randomly right now but more advanced strategies couldcertainly be added
<rqou> hmm so the tentative code i've written does things like just adding two edges into each FF's D/T pin
<rqou> one comes from the io pad and the other comes from the xor
<azonenberg> Yeah that would work
<rqou> but afaik if you somehow managed to use both of them, your design was wrong to start
<rqou> and the PAR engine cannot make it more wrong
<azonenberg> And yeah that would be a multiple driver error
<azonenberg> So the post-par drc will have to detect and complain about it if it's not caught sooner
<rqou> hmm afaik pre-par DRC/techmapping can already notice this
<azonenberg> hence the "if not caught sooner"
<azonenberg> i dont actually know how gp4par handles multiple drivers
<azonenberg> in the end, SetInput() is called on an input port
<azonenberg> and that will override any previous SetInput calls
<azonenberg> so it may just nondeterministically ignore one of the drivers :p
<azonenberg> But i would hope i implemented a check somewhere along the flow
<azonenberg> Just dont remember doing so
<azonenberg> aaaanyway sleeps
<rqou> g'night
qu1j0t3 has quit [Ping timeout: 246 seconds]
<rqou> hmm I will definitely be punting on this problem initially, but somehow I will need to teach the PAR engine about P-term dedup-ing/sharing
<whitequark> pie__: oh, instrumentation for compiler transformations
<whitequark> there's a visualizer called foundry-xray
<pie__> uh can you link that? thats pretty impossible to google
<pie__> im just getting a bunch of xray machine stuff
<pie__> whitequark, you familiar with the 3rdparty links under "swf documentation" at the time btw?: https://www.free-decompiler.com/flash/links/
<whitequark> sorry furnace-xray https://github.com/evilmartians/furnace-xray
<pie__> oh
<whitequark> I never used anything except the AVM2 spec and TraceMonkey source code
<pie__> ah, ok ill check that out too
<pie__> yeah i have several git repos cloned for later reference haha
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
<pie__> whitequark, hm. neat.
qu1j0t3 has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 258 seconds]
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
qu1j0t3 has joined ##openfpga
clifford has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
pie__ has quit [Changing host]
pie__ has joined ##openfpga
prpplague has left ##openfpga ["Leaving"]
m_w has joined ##openfpga
kristian1aul has quit [Quit: leaving]
massi has joined ##openfpga
amclain has joined ##openfpga
azonenberg_work has joined ##openfpga
digshadow has left ##openfpga [##openfpga]
massi has quit [Remote host closed the connection]
clifford has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
Zarutian has joined ##openfpga
mifune has joined ##openfpga
eduardo_ has quit [Read error: Connection reset by peer]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
mifune has quit [Ping timeout: 240 seconds]
ZipCPU|Laptop has quit [Ping timeout: 268 seconds]
mifune has joined ##openfpga
mifune has joined ##openfpga
digshadow has joined ##openfpga
<rqou> azonenberg: there is nothing gp4-specific about yosys .json netlist loading??
<rqou> why is it called Greenpak4Netlist?
<azonenberg> Good question, i think it is pretty generic
<azonenberg> If you want to rename it and move it into xbpar i'd be all for that
<azonenberg> it probably belongs there anyway
<rqou> hmm thinking about how to achieve that
<rqou> there is a little bit of random stuff about IBUFs
<azonenberg> i used iopadmap in yosys for my synthesis
<azonenberg> if you want, file a ticket and i'll get to it in a bit
<azonenberg> i have training right after work but am free after that to code on whatever
<rqou> hmm wait i'm still trying to understand exactly how it works
<azonenberg> basically xbpar maps a greenpak4netlist into a greenpak4device
<azonenberg> the actual par is all done on a pargraph
<azonenberg> and each pargraphnode points to either a netlistnode or a bitstreamentity
<azonenberg> depending on if it's in the device or netlist graph
<rqou> so specifically what i'm trying to understand is how the "bits" array in the yosys .json is actually represented in the code
<rqou> for the nets
<rqou> is netnames a required section of the .json file?
<azonenberg> I believe so
m_w has quit [Quit: leaving]
<rqou> hmm so regardless if it's required or not, when you use a net number it automatically starts existing at that point?
<azonenberg> Yeah
pie__ has quit [Quit: Leaving]
pie_ has joined ##openfpga
rvense_ is now known as rvense
<rqou> azonenberg: i just had a thought relevant to your "IDA for hardware" idea
<rqou> you can probably fingerprint synth/map/PAR tools the same way you can fingerprint compilers
<azonenberg> Quite possibly
<rqou> e.g. you can probably detect icestorm vs proprietary
<azonenberg> you can definitely fingerprint cell libraries
<rqou> you might even be able to detect e.g. <proprietary frontend> vs xst due to the different ways they optimize certain logic
<azonenberg> Perhaps
<rqou> not sure what the practical implications of being able to do this are though?
<azonenberg> None, probably
<azonenberg> i doubt it would be worth doing
<azonenberg> if anything i'd do the opposite
<azonenberg> you could do better netlist-to-HDL if you knew/could guess the toolchain
digshadow has quit [Ping timeout: 246 seconds]
digshadow has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
eric_j has quit [Read error: Connection reset by peer]
m_t has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
mifune has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
ZipCPU|Laptop_ has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
[X-Scale] is now known as X-Scale