<pointfree>
balrog: I'm currently working through the above paper on incremental logic synthesis. I've also been implementing parallel logic synthesis from these papers: http://hub.darcs.net/pointfree/gelFORTH-references
<pointfree>
I have a formula for the HS (horizontal segment bits) but not for the horizontal segment bytes, strangely enough.
<pointfree>
I've been working on capturing more of the process of RE with utilities for inference... not just the inference but also managing the data for inference... with a semantic web triplestore and the like. (Not sure if it's a good idea yet)
<pointfree>
I'm also working on psoc-rebit (like debit) so I can have the computer do the work via Mill's Methods etc.
<pointfree>
The coordinates in the .route file evidently control both the byte and the bits of the corresponding registers (for routing registers) because they are a contiguous space.
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
diamondman has quit [*.net *.split]
cblam has quit [*.net *.split]
bibor has quit [*.net *.split]
eightdot has quit [*.net *.split]
jn__ has quit [*.net *.split]
dingbat has quit [*.net *.split]
nurelin has quit [*.net *.split]
plaes has quit [*.net *.split]
diamondm1n has joined ##openfpga
jn__ has joined ##openfpga
eightdot has joined ##openfpga
plaes has joined ##openfpga
nurelin has joined ##openfpga
bibor has joined ##openfpga
plaes has quit [Changing host]
plaes has joined ##openfpga
talsit has joined ##openfpga
cblam has joined ##openfpga
dingbat has joined ##openfpga
amclain has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<cyrozap>
Marex: "14:22 <marex-cloud> azonenberg: I disagree with github TOS"
<jrernst>
Marex: but I couldn't get E/e - ENA signal enable -- 0:disabled 1:enabled
<jrernst>
the problem is to construct the HDL to get two distinct sets
<jrernst>
in this particular case setA in which ENA ist set and setB in which ENA is not set
<jrernst>
in the netlist viewer it looks fine
<Marex>
jrernst: I think I got that by fiddling with the chip planner :)
<jrernst>
I saw the bits also but the position is in both sets. Although netviewer show FFs with and without ENA
<jrernst>
so i started to investigate C4
<jrernst>
problem here I'm not sure that the method does cover this because it needs the two distinct sets and I must no for sure what's in them.
<jrernst>
... and I must know for sure what's in them.
<jrernst>
how can I get the C4s right?
<Marex>
hmmmmmmm
<Marex>
I basically use the most stupid way, although I'm not sure it's applicable to your method
<Marex>
I just force two LEs into particular position and have them offset by +1 in X coordinate
<Marex>
that way, you get LE -.
<Marex>
|
<Marex>
|_LE
<Marex>
connection
<Marex>
oh hm, ascii art didn't survive well
<Marex>
if you offset the LEs in Y coordinate by two or so, quartus will spit C4
<jrernst>
hmmm
<jrernst>
but thats not practical for a program
<jrernst>
ah wait
<jrernst>
how about setting up the LEs as you said two y positions away
mifune has quit [Read error: Connection reset by peer]
<jrernst>
then making more examples of this
<jrernst>
letting the first LE at its position and altering the second LEs position
mifune has joined ##openfpga
<jrernst>
if its with the C4 range the C4 must show up in the rcf
<jrernst>
and by holding the first LE fixed the connection to C4 must hopefully the same bits through all tests, right?
digshadow has joined ##openfpga
<jrernst>
Marex: you figured out the C4 configuration (UP and DOWN, 12 wires each)
<jrernst>
did you ever check the names in the rcf file?
<jrernst>
for example: C4:X15Y9S0I12
<jrernst>
I mean there is X15 Y9 and S0 (means N0 and is always N0 as far as I know)
<jrernst>
but there is this I12 sub division number scheme
<jrernst>
is this numer I12 in any way correlated with the C4 tables
<jrernst>
is it possible to get from that number to the wire? And is it always the same wire and bit position in every LE?
<Marex>
jrernst: I believe the code already has some support for calculating the number of the wire in the RCF, yes
<jrernst>
where exactly?
<jrernst>
maybe c4_dump in libsof-bitstream.c ?
<Marex>
yes
<Marex>
although I'm not super convinced it's entirely correct
<jrernst>
ahhh... you wrote a real mind twister... I don't get it...
<jrernst>
the fog is fading a little bit...
<jrernst>
half way through...
* pie__
throws epiphanies at jrernst
<jrernst>
Marex: can't find where ffs is defined. do you know what it's for?
<pie__>
for fucks sake?
<Marex>
jrernst: find first set , see ffs(3)
<jrernst>
damn, I thought it means flipflops (it's ffs - find first bit set in a word). okay, then it's easy.
mifune has quit [Ping timeout: 258 seconds]
<Marex>
jrernst: I _think_ the C4 has some muxes, one where you select 0 or 1 bit out of two and one where you select exactly 1 bit out of six
<jrernst>
got it
<jrernst>
you have everything in yout c4_table struct.
<jrernst>
and your doc lists what you are describing 2 bits (enable) and 6 bits (select)
<jrernst>
so there is definately a fixed relationchip... this can be exploited automatically by a script
<jrernst>
let's get to the LE-Buffer
<jrernst>
the FFs must have a connection to a LE-Buffer. How? Is it fixed or can it move?
pie_ has quit [Ping timeout: 256 seconds]
digshadow has quit [Quit: Leaving.]
<Marex>
the buffer(s) are fixed imo
<jrernst>
ok, then the cfg bits are also fixed and can be automatically found. The I-number must be the same at every LE throughout the whole bitstream, right?
<jrernst>
I'll check the LE hypothesis first, it's easy... gone for a while...
<pointfree>
Perhaps I need to isolate on other things to find formulas.
<pointfree>
The problem right now is finding formulas to map the coordinates + directions (top_f, bot_f, top_b, bot_b) to bytes and bits.
<pointfree>
Mapping PIPs to value,register pairs is not difficult with Cypress PSoC 5LP config. I pretty much know what lines in the .route file correspond to what sites and I usually only see one bit per config byte in the bitstream anyway.
<pointfree>
It is true that the bitstream is just bits, but those bits are mapped onto a 2D space and tessellations.
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<pointfree>
Sites with the same structure as other sites can be correlated with each other. The same site but configured in different projects/bitstreams can be viewed as independent sites of the same structure.
<pointfree>
Isolating and correlating between other kinds of things can help.
<pointfree>
Miscellaneous sparsely documented configuration registers can be RE'd by making more projects.