pie_ has joined ##openfpga
<cyrozap> Thanks! It only took me ~1.5 years :P
<pie_> ű\o/
<pointfree> Well, come to think of it, it's been a few years since I started RE'ing the PSoC5LP -- cluelessly, until I could load values into registers with openocd. Maybe my next RE'ing target will go faster hahas
promach_ has joined ##openfpga
promach_ has quit [Remote host closed the connection]
<pointfree> carl0s, cyrozap: The bottom row of DSI's only use the most significant VS nybles. The top row use only the least significant VS nybles. This sounds like Tx and Rx. Inside a UDB pair, only the UDB inputs need Port Interface (Pi) configuration.
Zarutian has joined ##openfpga
<pointfree> This all has me thinking that the structure may lend itself to putting together a cluster.
<cyrozap> pointfree: It sounds more like they just split the upper/lower connections by nybles.
<pointfree> As for DSI PI configuration, we have DSI[0..15]_DSIOUTT[0..5] and DSI[0..15]_DSIINP[0..5] (DSI HC to DSI HC?) and DSI[0..15]_DSIOUTP[0..3] (DSI VS to DSI VS)
<pointfree> cyrozap: The middle two rows of VS use both nybles.
<cyrozap> And by cluster, do you mean a cluster of PSoCs? Or just that the UDB array is expandable?
<pointfree> cyrozap: By cluster I mean a cluster of PSoC's.
<cyrozap> pointfree: Right, because they have rows above and below them.
<cyrozap> One nyble corresponds to the connections to the upper row, and the other to the lower row.
<cyrozap> Unless I misunderstand how the VS works?
<pointfree> cyrozap: Yeah that's pretty much how it works, but going into the routing fabric does not require port interface configuration: going from the HC into the input terms requires configuring PI tiles, outputting from a PLD into the HC tile does not.
<pointfree> Not sure if there is enough port pin i/o to support this.
rah has quit [Ping timeout: 240 seconds]
rah has joined ##openfpga
<cyrozap> pointfree: Just to make sure I understand how routing works, can you please confirm if the following statements are correct?
<pointfree> Sure thing.
<cyrozap> 1. The HC is the horizontal connection between the UDBs and the HV, and the HC config bits control which UDB pins are connected to the HC.
<cyrozap> Err, s/which UDB pins are connected to the HC/which UDB pins are connected to which HC "wires" and the direction of that connection/
<cyrozap> 2. The HV is the connection between the HC and the VS, and the HV config bits control which HC "wires" are connected to which VS "wires".
DingoSaar_ has joined ##openfpga
<cyrozap> 3. VS "wires" either connect to the HV in the row above or the row below, but not both.
<cyrozap> pointfree: And that's it.
<cyrozap> Also, I think this image from the patent describes what you were talking about with the nybles: https://cdn.rawgit.com/wiki/azonenberg/openfpga/images/US08026739-20110927-D00016.png
DingoSaar has quit [Remote host closed the connection]
pie_ has quit [Ping timeout: 268 seconds]
<cyrozap> Anyways, if those three statements are correct, and we know what each bit means in the registers that control the HCs and HVs, I can start adding code to convert entire bitstreams to Verilog (at least up until the DSI connections).
<pointfree> 1) Yes. The switches in the HC and the HV's, when set, connect a their horizontal wire to their vertical wire. 2) Yes, the switches work like they do in HC, albeit the HC pattern starts out with the in-series switches, and the HV pattern starts with the in-parallel switches. 3) Yes, I think so, although I haven't tested it.
<pointfree> cyrozap: The p3archdump.txt gives all the facts we need to know about DSI connections and UDB connections.
m_w has quit [Quit: leaving]
<cyrozap> pointfree: When you say "in-series" and "in-parallel" switches, what do you mean by that?
indy has quit [Ping timeout: 260 seconds]
<cyrozap> Looking at the patent diagrams again, I think I'm finally beginning to understand...
<pointfree> cyrozap: I was talking about two switches next to each other on the same horizontal wire and different different vertical wires (in-series) and two switches on different horizontals and verticals (in-parallel): http://odroid.0xffffffff.in/~deploy/psoc-switching/switching-bits-and-regs.html
indy has joined ##openfpga
digshadow has quit [Quit: Leaving.]
* Zarutian marks the spot in his logs of this channel.
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
<cyrozap> pointfree: I think I understand, so the "in-series" switches are the ones that connect to the nS lines, and the "in-parallel" switches are the ones that connect to the nU and nL lines (as seen here: https://cdn.rawgit.com/wiki/azonenberg/openfpga/images/US08026739-20110927-D00016.png).
<pointfree> cyrozap: Yes.
<cyrozap> Oh, and the HS is what controls which horizontal wires connect to each other horizontally (and their direction), and the VS does the same thing vertically.
<pointfree> Yes.
<cyrozap> Ok, good, so now I understand your diagrams :)
<pointfree> Yay!
manizzle has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
manizzle has quit [Remote host closed the connection]
promach_ has joined ##openfpga
promach_ has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<cyrozap> pointfree: Any chance you could generate (please don't do it manually...) some register docs for the routing stuff? Right now I know you have that visual map, and while that's really nice for visualizing everything, it's really hard to write the bitream RE code based on that. Ideally, it should be kind of similar to the Cypress docs, where you list the register name and address and explain what each of
<cyrozap> its bits do. e.g., "B0_P0_ROUTE_HC0: 0x40010100\n[7]: Something\n[6:5]\nSomething else\n\t0x0: Off\n\t0x1: Up\n\t0x2: Down\n\t0x3: Bidirectional\n..."
<cyrozap> pointfree: I'd hate to generate a ton of work for you, and I'm not sure exactly how you have all your docs recorded (other than the ones you've posted), so please tell me if this is a ridiculous request.
<cyrozap> Or, if you have formulas for determining what bits in various registers (HC, HV_L, HS, etc.) do, I can generate docs from that.
Hootch has joined ##openfpga
<cyrozap> As it stands, I'd have to hunt for each register and bit in that diagram in order to write the parsing code, since the code of course is just going to see the raw bits and needs to know what to do with them.
<cyrozap> Or, if you don't have an actual formula, but just a description of the pattern(s), I can do the rest myself.
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
mifune has joined ##openfpga
m_t has joined ##openfpga
amclain has quit [Quit: Leaving]
DingoSAL has joined ##openfpga
DingoSAL has quit [Remote host closed the connection]
DingoSaar_ has quit [Ping timeout: 240 seconds]
DingoSaar has joined ##openfpga
DingoSaar has quit [Remote host closed the connection]
DingoSaar has joined ##openfpga
<pointfree> cyrozap: I used something like this https://hub.darcs.net/pointfree/psoc-diagrams-to-tables/browse/switching.4th to convert the diagram into a list of coordinates, bits, and register offsets like this: https://hub.darcs.net/pointfree/psoc-diagrams-to-tables/raw-file/switching.md I have to pack for my flight now, but I can do this for the whole thing fairly
<pointfree> easily while I'm in the air. I can do it for all tiles and UDB quandrants.
digshadow has joined ##openfpga
Bike has quit [Quit: slepe]
m_t has quit [Quit: Leaving]
pie_ has joined ##openfpga
laintoo_ has joined ##openfpga
laintoo has quit [Ping timeout: 240 seconds]
laintoo_ is now known as laintoo
pie_ has quit [Ping timeout: 252 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
X-Scale has joined ##openfpga
pie_ has quit [Ping timeout: 252 seconds]
mifune has quit [Ping timeout: 252 seconds]
pie_ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
m_t has joined ##openfpga
DingoSaar has quit [Remote host closed the connection]
Bike has joined ##openfpga
DingoSaar has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
digshadow has quit [Quit: Leaving.]
mifune has joined ##openfpga
mifune has joined ##openfpga
amclain has joined ##openfpga
m_w has joined ##openfpga
seu has quit [Quit: No Ping reply in 180 seconds.]
seu has joined ##openfpga
m_w has quit [Quit: leaving]
digshadow has joined ##openfpga
pie_ has joined ##openfpga
Hootch has quit [Read error: Connection reset by peer]
<mtp> that's so good
Hootch has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
DingoSaar has quit [Ping timeout: 240 seconds]
DingoSaar has joined ##openfpga
Hootch has quit [Quit: Leaving]
Hootch has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 258 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
Hootch has quit [Quit: Leaving]
m_t has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
mifune has quit [Ping timeout: 252 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 240 seconds]