<digshadow>
But 50 is pretty generic. We might be able to cover using it
<litghost>
It's also worth noting that the MMCM fuzzer is not part of the root make, so at a minimum adding it to the root Makefile and check the fuzzer for stability issues is useful work
<litghost>
Once 1) and 2) is done, then it needs to be added to symbiflow-arch-defs
<nats`>
uhhmm is it me or when i source the env now I don't have (env) prefix int he terminal anymore
<nats`>
that was pretty usefull
mario_ has joined #symbiflow
<nats`>
litghost, I'm updating the 072 to be like 074 PR that and only after i'll split the pool function I would like to have functionnal block in case we need to rollback
<litghost>
sounds good
<litghost>
I only see the 074 once?
<nats`>
you have my commit
<nats`>
and then upper there is your commit saying merging PR
<litghost>
github creates a merge commit when pulling PR's
<litghost>
that's all
<nats`>
ah oky
kraiskil has joined #symbiflow
<mario_>
Hello lads, at 35c3 I've seen your talk and waving for help and just listened to the interview on the hackaday podcast. And (i think tim was it) said it on 35c3 and the interview said that people with an spartan-6 would be cool to help documenting the bitstream. I do have a cheap chinese fpga board from ebay with a spartan-6 xc6slx9 on it. Is it possible for me to help porting that or is it even worth it?
<mario_>
I only got into fpgas last semester, but it really got me and I think i want to learn more about them
<sorear>
there are I think 3 semi-active projects to study s6. hardware doesn't really help here, most of the process is feeding thousands upon thousands of verilog designs into ISE and correlating the input with the resulting bitstreams
<tpb>
Title: GitHub - koriakin/prjleuctra: Reverse engineering tools and chip database for ISE-era Xilinx FPGAs. (at github.com)
<mithro>
nats`: Oh, interesting - they seem to have an approach for generating the tiles which is somewhere I think SymbiFlow might be heading....
<nats`>
apparently the guy is inspired by prjxray
<nats`>
it quote it in readme
<nats`>
litghost, https://github.com/SymbiFlow/prjxray/pull/555 <= I made the same change to add argument to the 072 fuzzer, if you could do a run to compare output that would be cool :)
<nats`>
sure I saw that but I don't understand why S6 couldn't be supported by Yosys after reverse
<litghost>
It can, but someone has to do that work
<daveshah>
Support in Yosys is orthogonal to bitstream stuff
<daveshah>
I'm pretty sure s6 did work to some extent in Yosys once, although maybe there has been bitrot
<nats`>
uhhmm the PNR needs to be tuned to target ?
<litghost>
Yosys doesn't do PNR, it does synthesis
<nats`>
uhh sure it's logic in fact
<nats`>
synthesis and PnR needs that
<nats`>
oky I think I get the idea
<nats`>
if we start a work on Serie 6 and 3 I would certainly help but I don't like those serie they have so many flaws
<daveshah>
Synthesis just needs to know about the primitives
<nats`>
the serie 7 seems perfect in comparison :)
<daveshah>
And in general the vendors document them reasonably well
<nats`>
ok :)
<nats`>
so basically you're saying a lot of work need to be done on a part with no reverse and "only" writing the good interface in Yosys
<nats`>
?
<litghost>
Yes and no. Implementing the techlibs are the first step. Lowering the synthesized output then may require further mapping for the PnR tooling. For example DRAM primatives can be considered multiple placable units
<nats`>
oky I get the idea
<mithro>
nats`: bitstream documentation for the s6 is not currently the long pole for s6 support. Someone needs to do the work in Yosys first and then PnR....
<nats`>
I would like to help but I'm really too ignorant for that :)
Rahix has quit [Quit: Rahix]
<nats`>
litghost, I apparently have a problem sha1 is not the same !
<nats`>
I'm surprised i'll check why
tpb has quit [Read error: Connection reset by peer]