jevinskie has joined ##openfpga
Bike has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
azonenberg_work has quit [Ping timeout: 250 seconds]
Maya-sama has joined ##openfpga
GenTooMan has joined ##openfpga
Miyu has quit [Ping timeout: 268 seconds]
Miyu has joined ##openfpga
Maya-sama has quit [Ping timeout: 250 seconds]
jevinskie has joined ##openfpga
pie___ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
dj_pi has joined ##openfpga
dj_pi has quit [Ping timeout: 250 seconds]
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 268 seconds]
dj_pi has joined ##openfpga
rohitksingh_work has joined ##openfpga
pie__ has joined ##openfpga
pie___ has quit [Ping timeout: 250 seconds]
GenTooMan has quit [Quit: Leaving]
Bike has quit [Quit: sleep]
<fseidel> I have acquired a Pynq-Z2 (Zynq 7020) board
<fseidel> are there open tools that will let me generate and upload bitstreams for this board?
<fseidel> I don't care about the SoC bits, I really only want the PL for now
<whitequark> i don't think so
<fseidel> darn
<fseidel> oh well, it was worth a shot
* fseidel needs to allocate more space for his VM so he can fit the 20GB minimal install :/
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 244 seconds]
Miyu has quit [Ping timeout: 268 seconds]
dj_pi has quit [Ping timeout: 268 seconds]
<swetland> as far as uploading bitstreams, I expect my tools that work with zynq and artix are probably useable or adaptable
<swetland> as far as generating them, I believe you're stuck with vivado for the time being, but there's work underway on xilinx 7-series foss goodness
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
<kc8apf> Someone recently sent a pull request to prjxray to start on zynq.
<kc8apf> Re: connectors; smd SFP connectors can be bought without cages for $0.50. Mating connectors seem to be harder to find.
pie___ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
m4ssi has joined ##openfpga
Flea86 has joined ##openfpga
Bob_Dole has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
Richard_Simmons has quit [Ping timeout: 250 seconds]
scrts has quit [Ping timeout: 244 seconds]
mumptai_ has quit [Quit: Verlassend]
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
Bike has joined ##openfpga
scrts has quit [Ping timeout: 250 seconds]
pie___ has quit [Remote host closed the connection]
pie___ has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
scrts has joined ##openfpga
wpwrak has quit [Ping timeout: 272 seconds]
wpwrak has joined ##openfpga
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined ##openfpga
Bike is now known as Bicyclidine
<gruetzkopf> kc8apf: SFP mating connectors are (iirc 1mm) circuit boards
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<tnt> empty sfp 'cases' though ... not sure where to find that.
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh has joined ##openfpga
Miyu has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
<whitequark> sfp cages
<whitequark> theyre called cages
<whitequark> oh, nevermind, you mean the ones that plug into cages
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
catplant has quit [Ping timeout: 240 seconds]
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 250 seconds]
catplant has joined ##openfpga
azonenberg_work has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
catdemon has joined ##openfpga
catplant has quit [Ping timeout: 246 seconds]
catdemon has quit [Quit: WeeChat 2.2]
catplant has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
catplant has quit [Read error: Connection reset by peer]
scrts has joined ##openfpga
Stary- has joined ##openfpga
<kc8apf> is greenpak's config memory really just a single giant register?
<kc8apf> i'm trying to wrap my head around all the different ways config memories are laid out
Stary- has quit [Client Quit]
<kc8apf> Xilinx tends to do hierarchical routing to a 2D memory with height in multiples of the family's word size
<azonenberg_work> kc8apf: the reality of greenpak config, at least for the slg46620
<azonenberg_work> is that it's a stock 1kbit tsmc 180nn efuse macro
<azonenberg_work> that is loaded at boot time into a bunch of dffs scattered around the die
<kc8apf> ice40 is a 2D memory
<azonenberg_work> presumably a byte or 16-bit word at a time
<kc8apf> ah, ok
<kc8apf> so it basically is a single big "register"
<daveshah> ECP5 main config is a dense 2D array of frames and bits (each frame padded to 8 bits and followed by a CRC16 in the bitstream)
<daveshah> Block RAM init is command based. Each BRAM is assigned a 10 bit ID in the main bitstream, then written to individually by commands following the main bitstream
<whitequark> 19:53 < azonenberg_work> is that it's a stock 1kbit tsmc 180nn efuse macro
<whitequark> wait what?
<whitequark> did you decap it?
<kc8apf> daveshah: what constitutes a frame?
<azonenberg_work> whitequark: yes, but didnt want to make a lot of fuss or tweet the die shots or anything
<azonenberg_work> since we had a good working relationship with them
<azonenberg_work> it was just out of curiosity
<daveshah> kc8apf: a device dependent number of bits
<daveshah> Little more than that really
<daveshah> Frames form a large 2D space. Tiles are rectangles on that space
<whitequark> kk
<whitequark> azonenberg_work: what if i independenently decapped and published?
<azonenberg_work> whitequark: i dont have any references to compare the IP to, but the fact that the greenpaks all have power-of-two config space suggests they didnt go full custom like xilinx
<daveshah> Each tile has start and end frame and start and end bit within those frames
<azonenberg_work> they just used a stock ip
<azonenberg_work> whitequark: what would the point be? the bitstream is public already
<whitequark> azonenberg_work: silicon pron
<daveshah> So each frame contains parts of several tiles
<azonenberg_work> lol fair enough
<azonenberg_work> yeah i guess you can go for it, i mostly just didnt want my name on it
<whitequark> ok
<azonenberg_work> to avoid burning bridges
<azonenberg_work> if it was xilinx, there's no relationship to speak of
<azonenberg_work> so do whatever you want :p
<kc8apf> My theory so far is that all programmable logic config memories can be represented as hierarchical addressing that resolves to 2D memories with sizes defined in bits
<kc8apf> daveshah: sounds a lot like xilinx
<daveshah> There is no concept of a word in ecp5, unlike Xilinx
<azonenberg_work> kc8apf, daveshah: i think you mean xilinx FPGA specifically
<azonenberg_work> the CPLDs have a very different config mem arch
<kc8apf> fair. i haven't looked at xc2c yet
<azonenberg_work> xc2c32a for example is explicitly 2D where config "words" are 260 bits long
<azonenberg_work> and directly correspond to a sram word line that crosses the whole die
<azonenberg_work> i can point to it in a sem photo :p
<whitequark> azonenberg_work: oh hmmm i should decap some old CPLDs i guess
<kc8apf> that's similar to xc2064
<whitequark> maybe try out new optics and/or cameras
<whitequark> next time i have money to spend on that
<kc8apf> I'm not hearing anything that disproves my theory. Time to put my thoughts on an ELF-like format for programmable logic into code.
<whitequark> wtf
<whitequark> that sounds cursed
<azonenberg_work> kc8apf: how do you plan to handle metadata
<azonenberg_work> or things that aren't directly config bits
<kc8apf> azonenberg_work: not entirely sure
<azonenberg_work> Things like the bitstream CRC
<whitequark> kc8apf: how would programmable logic relocations even work
<jn__> DWARF? :P
<azonenberg_work> or "SPI bus clock rate"
<kc8apf> whitequark: oh, not planning on that part
<azonenberg_work> whitequark: i think he just means a universal container format
<whitequark> then how is it ELF-like?
<daveshah> jn__: we have symbols in icebox asc files already
<daveshah> Net name against icebox wire id
<kc8apf> mostly just want a common format for representing config memory space that is independent of the programming format
<whitequark> .jed?
<azonenberg_work> whitequark: jed is absurdly verbose
<kc8apf> ugh
<azonenberg_work> imagine trying to do a big xilinx chip with it
<whitequark> azonenberg_work: just put it in gzip
<azonenberg_work> there is a definite need for a universal binary format imo
<azonenberg_work> decompressing gzip is a pain on low end embedded hardware
<whitequark> that is a good point
<azonenberg_work> (think stm32 class)
<whitequark> i agree with you now
<whitequark> something like binary jed would be nice
<azonenberg_work> also, the main point of text based formats is human readability
<whitequark> could even be 1:1 equivalent to jed for fpgas that already use jed
<azonenberg_work> if your file is all ascii ones and zeroes
<azonenberg_work> it still isnt really human readable
<azonenberg_work> thus the point of ascii is lost
<whitequark> azonenberg_work: disputable
<whitequark> when i was reing xc9572xl programming
<whitequark> there were obvious visual parallels between jed and bit :P
<azonenberg_work> i mean yes you can add comments, and the newlines help give a bit of structures
<whitequark> and jed and actual dffs
<whitequark> but i agree that is not worth keeping jed as format, of course
<azonenberg_work> but the nice thing is that we dont need to make our format easily re-able
<azonenberg_work> we're documenting the bitstreams as we go :p
<whitequark> i mean
<whitequark> just make a bjed2jed and jed2bjed tools
<whitequark> again so you can support existing PLDs that use jed, mostly
<azonenberg_work> kc8apf: also factor to consider: if you want to program a xilinx device from spi flash etc
<azonenberg_work> you have to create the actual .bit register headers in there too
<azonenberg_work> and then the bitstream in their order
<azonenberg_work> Is your goal to replace .bit for jtag programming? to replace .ncd?
<kc8apf> yeah, there's a definite need for metadata to allow conversion to actual programming files
catplant has joined ##openfpga
<daveshah> Config frequency, that sort of thing, too
<kc8apf> azonenberg_work: goal is to provide a format independent of programming concerns and then provide tools to convert to/from the various programming formats
<kc8apf> higher-level tools won't need to deal with the programming format details then
<kc8apf> I need to read up on JED
<kc8apf> All I know about it is that everyone hates it
<kc8apf> why has this page never popped up in my searches before: http://www.pldtool.com/pld-file-formats
<kc8apf> oh god. JED was designed to allow you to do transfers over a serial port that is also being used as a terminal
<azonenberg_work> lol
<azonenberg_work> jed is meant to be used on dumb programmers made of 74xx parts and maybe a tiny 8 bit micro
<whitequark> kc8apf: you know gcode?
<whitequark> jed is basically gcode for pld programmers
<azonenberg_work> Yep
<azonenberg_work> That sounds exactly right
<kc8apf> wishful goal is to allow "linking" of multiple objects together to complete a design. It'd require all objects to be non-overlapping which makes sense for partial reconfig designs
<azonenberg_work> and what, a symbol table showing what nets are at the border of which objects?
<kc8apf> so many industries built on stupidly cursed formats
<kc8apf> azonenberg_work: something like that
<azonenberg_work> and then you do a trivial P&R on the boundaries to connect them?
<azonenberg_work> sounds plausib
<azonenberg_work> e
<azonenberg_work> inb4 refcounted partial reconfig shared libraries
<whitequark> kc8apf: JED is defined by JESD3C
<whitequark> lmk if you need the pdf
<whitequark> i don't really think it's cursed, more just verbose
<whitequark> a bit similar to intel hex
<azonenberg_work> verbose and imo insufficiently expressive for out-of-bitstream metadata
<azonenberg_work> like xilinx config state machine commands
<kc8apf> whitequark: found a copy
<azonenberg_work> i mean i guess you could invent a fictitious address range for them
<whitequark> azonenberg_work: it has U for User data
<whitequark> no need to invent anything
<kc8apf> the note about being designed for serial ports shared with terminals is straight from the Purpose & Scope section
<whitequark> kc8apf: yeah, i know
<whitequark> it's really old
<whitequark> but aren't you basically designing for a similar space?
<kc8apf> '94 isn't _that_ old
<whitequark> an stm32 that loads a .bjed is more or less similar to a serial programmer
<whitequark> in the sense that it, well, programs serially
<kc8apf> I don't care about the programmer part. I'm content to have converters from .bjed to .whatever
<kc8apf> i want the abstraction from the .whatever
<kc8apf> xc7 bitstreams are horrible to work with because of the whole programming state machine
<whitequark> anyway, regarding jed, you are only interested in 3 commands. QF*, L* and C*
<whitequark> in practice jed is used as a kind of TLV framing for a bitstream
<kc8apf> higher-level tools really only care about the address of a config mem region and the contents
<whitequark> so it is exactly what you want, right?
<kc8apf> sounds likely
<whitequark> i'm willing to contribute a converter to/from jed to your tools btw
<whitequark> i will need jed anyway in glasgow
<whitequark> for cplds
<kc8apf> I have to actually have tools first :(
<whitequark> the actual jed code is probably tens of LOC
<kc8apf> i'm ignoring my day job today and doing this instead
<whitequark> heh
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 268 seconds]
Bob_Dole has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
catplant has quit [Quit: WeeChat 2.2]
catplant has joined ##openfpga
cr1901_modern has quit [Ping timeout: 250 seconds]
Finde has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<catplant> dang
cr1901_modern has joined ##openfpga
<whitequark> azonenberg_work: what is "power miser" in context of CPLD?
<whitequark> not a typo
<azonenberg_work> probably saying super low power
<azonenberg_work> but i'd need to see more context to be sure
<tnt> mithro: picture "Fomu front and back" says "tomu" on the silk screen :)
<whitequark> azonenberg_work: no other context, it's in JESD3C
<whitequark> talking about fuses
<azonenberg_work> whitequark: huh, that seems more like a manufacturing trade name
<azonenberg_work> than something you'd see in a standard
GenTooMan has joined ##openfpga
<whitequark> i t hink it is a trade name they use as an example
<whitequark> but i wonder what it would do
pie__ has joined ##openfpga
<pie__> hey guys, I have a USB 2 (4 pin) device that I dont know the pinout of (fitbit versa), would it be ok to try all pinout permutations or will that fry something
Maya-sama has joined ##openfpga
<pie__> probably need a glasgow :P
<qu1j0t3> pie__: since there is 5v and gnd on there i do not recommend this.
Miyu has quit [Ping timeout: 250 seconds]
Miyu has joined ##openfpga
<pie__> reverse polarity protection probably doesnt exist, since the charger adapter is not reversible...
<pie__> #yolo
<pie__> ^ 2 people 1 keyboard
Maya-sama has quit [Ping timeout: 240 seconds]
<pie__> nevermind we got it
<pie__> and it didnt explode (yet)
Maya-sama has joined ##openfpga