<RaivisR>
hi folks, mithro invited me to join, I want to help with project xray, so I'm here
<mithro>
RaivisR: I'll be around in a couple of hours just heading out to lunch now.
<RaivisR>
my timezone is GMT+2, so I am having lunch right now, will be back at console in 4ish hours
<RaivisR>
will you still be online mithro?
<mithro>
I should be
<RaivisR>
talk to you then
<mithro>
If you mention my nick, then it will ping me
<RaivisR>
ok
<azonenberg_work>
o/ RaivisR - nice to see more folks here
<azonenberg_work>
It seems like almost all of the xray folks are living in this channel now
<azonenberg_work>
I've been following the project with interest for a while, although i havent been involved in any of the reversing work
<azonenberg_work>
my interest is more on the toolchain development side as well as higher level netlist RE algorithms (finding hierarchy and such in an extracted netlist)
<azonenberg_work>
At this point it looks like we've got work in some level of progress for coolrunner-2, 7 series, greenpak4, psoc5lp, and obviously ice40
<azonenberg_work>
thats not bad at all :)
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
awygle has quit [K-Lined]
awygle has joined ##openfpga
pie_ has joined ##openfpga
<RaivisR>
mithro, I got an hour before I have to go, if you have some time to kill on noob, I would appreciate that
<mithro>
RaivisR: I'm around now
<mithro>
RaivisR: So, my first question is what are you interested or excited to work on? There is no point me giving you tasks that your not interested in as you'll just end up playing computer games or something instead
<RaivisR>
mithro, as I understand you create a bunch of bitstreams with explicitly instantiated fpga elements at known locations and then check what changes in bitstream?
<RaivisR>
ugh, I want to become smarter and I want to fill that table to 100%
<RaivisR>
and I don't play computer games
<mithro>
RaivisR: There are plenty of areas and tile types which we still know very little about
<mithro>
RaivisR: So we would be more than happy to have people looking at them
<RaivisR>
and since I have 4 kids, I have very little time that I can spend on hobbies (and limited budget) so I can play some on a computer, way less with real hw
<RaivisR>
the core is fuzzers, right?
<mithro>
RaivisR: Yes, that is how we are documenting the bitstream relationships
<mithro>
RaivisR: So the first step would be to get project x-ray and trying to run some of the existing fuzzers
<RaivisR>
already did yesterday
<RaivisR>
which one is relatively simple tile that I should analyze end to end to understand what is going on?
<RaivisR>
the part that sets up hdmi rx and tx over i2c
<balrog>
neat :)
<RaivisR>
and the whole thing in general (and I know Joe from #tymkrs chat on AfterNET, I have never met him in person)
<mithro>
RaivisR: Oh - I'm the HDMI2USB.tv guy
<mithro>
RaivisR: Sorry, if you don't say my nick I might forget to response as I'm doing multiple things at once :-P
<RaivisR>
I was aware that mudball is small and round
<mithro>
RaivisR: The best approach is to start at the first fuzzer and just go through each one
<RaivisR>
mithro, as we all do. so which tile is probably the easiest for analysis of what is going on?
<mithro>
RaivisR: but digshadow might be able to give you more advice there -- I just run the fuzzers, not write them :-P
<RaivisR>
got it, as I understand writing them is the part where help is needed the most
<mithro>
RaivisR: Well, actually I would say that the place we need most help is getting the full toolchain producing bitstreams -- which are the moment is more blocked on getting the architectures and stuff into a format that Verilog to Routing understands and then generating bitstreams from it's output
<mithro>
RaivisR: Things like the DSP block are of course cool, but we can make do without them for quite a while
<RaivisR>
yeah, well, that would be way over the top of my head right now :)
<RaivisR>
but if there is any grunt work involved in that, I will gladly do that
<digshadow>
RaivisR: can you give me an idea of the sort of FPGA stuff you are familiar with today? Worked with Vivado? What is the most complex project you've done?
<RaivisR>
digshadow, I am somewhat familiar with Vivado, ISE and Quartus, most complex project - hdmi splitter+mirror (there is nothing complex about it though), complete design including hw and verilog (no softcores involved)
<RaivisR>
so it's "full stack" development in web developer lingo :)
<digshadow>
Ha gotcha. That doesn't sound too bad...sounds like you have basic workflows down. If you were told to look at a block for example, sounds like you would have enough background to read the manual for the block and understand how to instiantiate it
<digshadow>
thats whats required for a lot of the fuzzers...just enough to understand how to instantiate something and roughly how its used
<RaivisR>
digshadow, oh, that I can do woken up 2am in a morning
<digshadow>
I learned a lot about 7 series LUTs for example because I needed to for the CLB
<RaivisR>
i would rather struggle writing proper and correct verilog and understanding nuances of it, but datasheets I can do all day long
<digshadow>
What about mithro's project with the bitstream generation? would that be a better fit for now?
<azonenberg_work>
in particular i want to experiment with measuring timing myself (vs extracting from the tools)
<RaivisR>
I will check it out once I get back to the console
<RaivisR>
family is starting to pull me away from console..
<balrog>
azonenberg_work: what's the current state of greenpak?
<balrog>
any plans to add vtr support to that?
<azonenberg_work>
No, and it doesnt make sense
<azonenberg_work>
VPR is for 2D lut fabrics
<azonenberg_work>
not for crossbars
<balrog>
aaah
<azonenberg_work>
What's mostly needed is support for the last few hard IP blocks in gp3
<azonenberg_work>
gp4*
<azonenberg_work>
then starting to work on gp5
<balrog>
makes me wonder how messy it would be to integrate crossbar support to vpr
<azonenberg_work>
i just havent had time to touch it for the last ~6 months
<azonenberg_work>
its fundamentlaly different architecturally
<azonenberg_work>
i dont think theres any benefit
<balrog>
do other chips use that sort of architecture....? I'm thinking some CPLDs maybe?
<RaivisR>
will have to get some ice40 board from olimex to play with yosis as well
<azonenberg_work>
Yes, most CPLDs
<azonenberg_work>
libxbpar was intended to be a generic crossbar for CPLDs
<balrog>
icoBoard is nice
<azonenberg_work>
generic PAR*
<azonenberg_work>
just like vpr is a generic par for FPGAs
<balrog>
aha, I see
<azonenberg_work>
Then rqou had to go and write his PAR in rust and not use my toolchain
<azonenberg_work>
just b/c he didnt like doing C++ :P
<balrog>
is his PAR good? :)
<azonenberg_work>
That i dont know
<balrog>
(I'm not opposed to Rust)
<azonenberg_work>
havent actually used it
<balrog>
(it's a better language and compilers are widely available)
<azonenberg_work>
i'm more opposed to forking the porject and not taking advantage of the existing work
<azonenberg_work>
the whole point was to create a unified platform for multiple architectures to have PAR engines
<azonenberg_work>
that shared most of their code
<azonenberg_work>
now we have two arches and two toolchains
<mithro>
RaivisR: You can play with yosys without needing an ice40
<balrog>
hmm where is his par
<mithro>
But we are trying to get iCE40 support into vpr too
<RaivisR>
mithro, I am local olimex distributor, I helped Olimex get firs olinuxino off the ground, so I became one..
<RaivisR>
*first
<mithro>
RaivisR: cool
<RaivisR>
also became online friends with Tsvetan, owner of Olimex
<RaivisR>
local == Latvia
<azonenberg_work>
balrog: its in my repo i think?
<mithro>
RaivisR: I'm pretty sure I have some olimex hardware sitting in my suitcase right now :-P
<balrog>
azonenberg_work: xc2par?
<RaivisR>
mithro, they are quite popular around the world (not so much here)
<balrog>
would need to know what rqou's plans are
<RaivisR>
ok, ttyl, will check out that symbiflow-arch-defs repo later on
<azonenberg_work>
balrog: yes
<balrog>
because right now it seems there are three separate PAR implementations in that repo
<azonenberg_work>
three??
<azonenberg_work>
gp4par is an app that uses xbpar to target greenpak4
<balrog>
ahh, so two then
<azonenberg_work>
its not a separate implementation
<azonenberg_work>
it's just a greenpak techlib for xbpar
<balrog>
I see
m_w has quit [Quit: leaving]
azonenberg_work has quit [Ping timeout: 248 seconds]
digshadow has quit [Ping timeout: 260 seconds]
ym has quit [Ping timeout: 240 seconds]
ym has joined ##openfpga
digshadow has joined ##openfpga
clifford has joined ##openfpga
kc8apf has joined ##openfpga
sgstair_ has joined ##openfpga
sgstair has quit [Disconnected by services]
sgstair_ is now known as sgstair
sgstair_ has joined ##openfpga
sgstair has quit [Disconnected by services]
sgstair_ is now known as sgstair
sgstair_ has joined ##openfpga
sgstair has quit [Disconnected by services]
sgstair_ is now known as sgstair
mumptai has joined ##openfpga
sgstair has quit [Ping timeout: 268 seconds]
nrossi has quit [Quit: Connection closed for inactivity]
<rqou>
my class right now is discussing S<redacted>'s awful work/life balance without passing judgment
<rqou>
this is why SV is so toxic :P
<rqou>
azonenberg: i also didn't like xbpar because it didn't easily allow me to make pla-specific optimizations
<rqou>
also, i really dislike annealing/optimization-based formulations and prefer CSP/search-based formulations of the problem
<rqou>
although interestingly xc2par is not using a search algorithm but min-conflicts instead
<rqou>
the idea here being that almost all actual designs I've considered are very close to working just with greedy allocation
<rqou>
xbpar keeps running into limitations of "foobar constraint requires a hack to implement"
<balrog>
rqou: are you planning to make xc2par extensible to other architectures?
<balrog>
and what about hybrid annealing/optimizatioon and csp/search?
<rqou>
maybe
<rqou>
but likely only PLAs
<rqou>
unless i get some new insight on how to handle PAL pterm allocation without violating the ancient Xilinx patent
azonenberg_work has joined ##openfpga
<rqou>
i actually don't 100% understand the limitations of pterm allocators
<rqou>
i actually want to add xpla3 support but azonenberg doesn't care about it
<qu1j0t3>
do it anyway who cares about that guy
<rqou>
yeah xpla3 would be really straightforward
<rqou>
it's almost the same as a Coolrunner-II
<rqou>
xc9500 would be awful
<rqou>
we have basically no insight into how the interconnect works
<azonenberg_work>
I have no objection to xpla3
<azonenberg_work>
i just dont think its a priority
<rqou>
it also has a lot more limitations
<rqou>
somehow lots of people want xc9500 for RE
<rqou>
or something?
<rqou>
also max7000
<rqou>
cpld interconnects are a big pain
<rqou>
actually i just remembered
<rqou>
xpla3 has weird stuff like "foldback nand gates"
<rqou>
which i also have no idea how to utilize
sgstair has joined ##openfpga
<azonenberg_work>
rqou: i wont stop you if you want to RE xc9500 either
<azonenberg_work>
The more the merrier
<azonenberg_work>
I just want a working coolrunner toolchain first
<rqou>
which is why I keep asking other people to go do it
<rqou>
but apparently those people asking for it aren't actually doing the re
Tenacious-Techhu has joined ##openfpga
<Tenacious-Techhu>
Anyone know a good open Schematic to HDL converter, other than xschem?
<Tenacious-Techhu>
Also, I'm having some trouble with the IceStudio tools; how do I rotate or flip blocks, and why am I having some trouble connecting blocks to one another?
<Tenacious-Techhu>
And is there a way to integrate VHDL into the IceStorm toolchain, rather than Verilog?
<kc8apf>
I know there are a few VHDL to verilog converters
<azonenberg_work>
Tenacious-Techhu: rqou has a very early WIP yosys front end for VHDL but its far from usable
<balrog>
Tenacious-Techhu: there isn't great VHDL support yet. tgingold was working on a GHDL synthesis plugin
<azonenberg_work>
If you want to poke him to motivate, or join the effort, he's here ;)
<Tenacious-Techhu>
Thanks; I may do that. :)
<balrog>
rqou: is also working on it
<balrog>
lol azonenberg_work already said so
<Tenacious-Techhu>
I would argue that an LLVM based converter may be better than a GCC based one, but I don’t have the background details to back up that statement. ^_^;
<balrog>
Tenacious-Techhu: I don't see how that's relevant?
<Tenacious-Techhu>
The GHDL thing was based on GCC, I think.
<balrog>
(the reason no one wants to work on GHDL is because it's written in Ada)
<balrog>
nah, GHDL is original code, just in Ada that compiles with GNAT)
<Tenacious-Techhu>
Yeah, that might be the other problem with it.
<Tenacious-Techhu>
Any of you know a good Schematic to HDL converter?
<Tenacious-Techhu>
I know that HDLs have their merits, but I generally prefer working in Schematic.
<Tenacious-Techhu>
Some designs just don’t have the variability that makes coded designs worthwhile.
<azonenberg_work>
lol i actually have the opposite approach
<azonenberg_work>
i want to do PCB designs in an HDL
<Tenacious-Techhu>
azonenberg_work, I don’t think autorouters are good enough for that yet.
<azonenberg_work>
Tenacious-Techhu: you misunderstand
<azonenberg_work>
i want to replace schematic entry with HDL
<azonenberg_work>
Do a top level design, synthesize
<azonenberg_work>
then do manual layout
<azonenberg_work>
i.e. verilog -> netlist, import netlist into layout tool
<awygle>
Tenacious-Techhu: are you aware of icestudio
<awygle>
They seem to have some kind of schematic based gui
<balrog>
there's a reason nearly all major ASICs/SoCs are done using some sort of HDL
<Tenacious-Techhu>
awygle, see my second question. :)
<awygle>
Ah.
<Tenacious-Techhu>
azonenberg_work, I’m not even certain what an electrical schematic based HDL would look like. You also have to start caring about the impedance of your netlists a little soon for beginner schematic design.
<Tenacious-Techhu>
balrog, if it were up to me, I’d be able to interact with the floorplan directly to wire things together manually.
<balrog>
Tenacious-Techhu: I'd rather have something where you can specify constraints in the HDL
<balrog>
and the fitter, placer, and router would respect that
<azonenberg_work>
Tenacious-Techhu: yes, constraints are the way to go
<azonenberg_work>
I wasnt going to have an auotmated PAR
<azonenberg_work>
i wanted to go HDL -> kicad pcbnew
<balrog>
that's reproducible and portable
<balrog>
manual layout is not
<azonenberg_work>
and just have it spit out a set of component footprints and connections
<Tenacious-Techhu>
What’s not portable about a PCB layout?
<azonenberg_work>
he means manual layout vs auotomated
<azonenberg_work>
and while i would love a full automated PAR for PCBs
<azonenberg_work>
we're a long way from that
<balrog>
I'm referring to in FPGAs and such
<azonenberg_work>
oh
<azonenberg_work>
I was talking about cutting schematic entry out of the workflow entirely, even at the PCB level
<Tenacious-Techhu>
Yes, manual layout in an FPGA isn’t portable, unless you can come up with a LUT block that is universal across platforms.
<Tenacious-Techhu>
Personally, I’d rather treat the floorplan like a solderless breadboard, and wire between the blocks manually, within the interconnection restrictions.
<azonenberg_work>
Tenacious-Techhu: you want to manually PAR the FPGA?
<azonenberg_work>
good luck doing anything nontrivial that way
<Tenacious-Techhu>
Through a nice GUI, of course.
<azonenberg_work>
In general the way most folks do high-performance layout like that is to do the whole thing in HDL
<Tenacious-Techhu>
Yes, I’m aware.
<azonenberg_work>
then constrain locations of individual LUTs as needed
<azonenberg_work>
and let the router do its thing
<Tenacious-Techhu>
HDLs are certainly better from a parameterized perspective.
<azonenberg_work>
In general asic/fpga routers are fairly good
<azonenberg_work>
placement is the area where you can sometimes outperform the tool
<azonenberg_work>
i havent seen too many cases where you can outperform the router by much
<Tenacious-Techhu>
It’s hard really to know how good they are, with so many closed-source cases.
<azonenberg_work>
Yeah but you can look at the output
<azonenberg_work>
they show you the routing
<Tenacious-Techhu>
Yeah, but they don’t really show you much about how they could be routed, do they?
<Tenacious-Techhu>
I’d rather schematic something up, and have some interactive draggable mesh come up, with some hard constraints popping up in red; stuff like “No more than 4 connections this deep”, so you know where you’re hardware constrained.
m_w has joined ##openfpga
<balrog>
but how would that benefit yo?
<balrog>
you*
<Tenacious-Techhu>
It would benefit me because it makes more intuitive sense for me to interact with the thing more directly, rather than use an abstraction.
<Tenacious-Techhu>
The abstraction is nice for portability, but it sucks for ease of use.
<Tenacious-Techhu>
Not to mention that humans are better at solving packing problems than any algorithm is.
<Tenacious-Techhu>
And not by just a little, either.