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]
<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>
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
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...