<Marex>
rqou: was nice hanging around the FPGA table :_)
Dolu has quit [Ping timeout: 248 seconds]
promach has quit [Ping timeout: 250 seconds]
rk[ghost] has joined ##openfpga
promach has joined ##openfpga
<balrog>
how are things going?
<pointfree>
So the routes that work and don't work seem to vary between brand-new psoc5lp boards just peeled out of the packaging... and I was pulling my hair out trying to come up with some theory or mathematical formula to describe how switches can connect.
<pointfree>
I guess Cypress decided that they don't need all routes to work for a 'successful yield' because their routing fabric is so flexible and permutable.
wpwrak has quit [Read error: Connection timed out]
wpwrak has joined ##openfpga
<monochroma>
lol gross
<sorear>
so p&r has to be repeated per device?
<monochroma>
is there fabric characterization data per chip?
soylentyellow has quit [Ping timeout: 265 seconds]
<pointfree>
monochroma: Cypress flash is similar. The flash is characterized per chip in the factory to compensate for its crappyness. The characterization data can be read from a memory region on the chip. I'm hoping there's something similar for the routing fabric.
<pointfree>
lately I've just been opening all routes in the direction I need to go with 0xFF and then unsetting unnecessary bits until I unset a bit that made it stop working.
<lain>
D:
<whitequark>
that sounds horrifying
<lain>
yeah that has some godawful implications for manufacturing things based on those chips, I would think
<pointfree>
Cypress PSoC's are very popular for automotive applications.
<awygle>
Honestly that doesn't sound any worse than any other "this thing kinda works, let's ship it"
<lain>
maybe I misunderstand -- doesn't that effectively mean a rebuild operation for every unit you use in production?
<lain>
IOW it's not just "here's the gold master image, just burn it into all of them"
<awygle>
I was assuming it just meant a more complicated programming algorithm than just "shift bits into registers"
<pointfree>
I've noticed stuck-at-1 and stuck-at-0 faults. I'll need to start reading up on fault analysis.
<pointfree>
Maybe if I pay for automotive-approved psoc's the quality will improve?
<awygle>
pointfree: do you have a decap of a psoc? Would be interested if there was a complicated circuit near the jtag or whatever
<awygle>
(not that I could actually read it usefully)
<pointfree>
for factory tests?
<awygle>
Either that or to take test data into account when programming
<pointfree>
awygle: Cypress stores the logic fabric configuration into the ends of each block of flash (they disable the ECC feature for this). The ends of all these blocks are mapped into 0x48000000.
<pointfree>
The logic fabric configuration is then loaded into the logic fabric switches (memory mapped) on boot with a loop written in C.
<pointfree>
...so I'm not sure where they could take this into account.
<lain>
>they disable the ECC feature for this
<lain>
CYPRESS YOU ARE DOING ME A CONCERN
<monochroma>
do they have a CRC somehwere?
<sorear>
by writing different bits into the flash of each chip based on that chip's fabric topology?
<awygle>
Yeah I mean surely the psoc tools generate working bitstreams *somehow*, and as lain says they can't be recompiling for every chip surely
<awygle>
(I am overusing the word surely)
<sorear>
why can't they be? isn't it pretty small?
<awygle>
It would mean you can't do any kind of mass production programming, basically
<awygle>
Which, as someone working at a company whose entire business model is doing mass production programming for automotive businesses, would be... Inconvenient.
<pointfree>
Cypress wrote about how they short interface lines and routes together so that your configured routes can take short-cuts. Of course I made use of this for more concise bitstreams. Maybe I need to fully specify all routes. Maybe Cypress does not guarantee that all of these short-cuts work.
<pointfree>
Still, I was having problems with Horizontal Segmentation switches which are required regardless (for traversing multiple routing tiles horizontally). Also, HS switches must each be aligned horizontally for a connection.
<balrog>
pointfree: this doesn't quite make sense because a bit file should work on any PSoC
<balrog>
unless the bit files they generate contain a level of redunancy
<pointfree>
balrog: I think Cypress overspecifies routes because then they're more likely to work.
<cyrozap>
pointfree: This all sounds really implausible. First of all, it's 100% possible to use the same flash image on multiple PSoCs without doing a rebuild, so the routing fabrics can't be _that_ unique. Second, if the P&R tool was over-specifying the routes, wouldn't that be visible in the tool output? Occam's razor says it's more likely we're missing some information about the on-chip route configuration
<cyrozap>
process than it is that Cypress doesn't know how to build reliable CPLDs--something they've been doing for nearly two decades.
<cyrozap>
lain: That ECC is on the flash memory rows, and disabling it frees up the ECC data space for use as an extra data memory. This way you can have 256k code+data plus and extra 32k data, instead of just 256k ECC-protected code+data.
<cyrozap>
lain: So it's really no more scary than programming an STM32--OpenOCD can verify the data after flashing.
<lain>
mmm.. is it safe to assume the flash will not degrade over time?
<awygle>
Generally, pretty safe
<awygle>
If your flash is good. Varies by many factors.
Dolu has joined ##openfpga
<rqou>
hey awygle, what exactly are you working on right now for openfpga?
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 268 seconds]
m_t has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 250 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 250 seconds]
pie_ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
m_w has quit [Quit: leaving]
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
m_t has quit [Quit: Leaving]
azonenberg_work has quit [Ping timeout: 248 seconds]
pie__ has quit [Ping timeout: 240 seconds]
<mithro>
awygle: Thanks for the pull request!
<awygle>
mithro: just added the signed-off-by
<mithro>
awygle: Looking now
<mithro>
awygle: DCO — All commits have a DCO sign-off from the author \o/
<mithro>
awygle: Please excuse how terrible both the make files and the python code is :-P
<awygle>
mithro: but of course :P
<awygle>
mithro: do you have a use for a .net to yosys json converter?
<awygle>
(the vpr .net, not like... C#)
<mithro>
hrm?
<awygle>
i am planning (possibly only in the short term) to use vpr to pack inputs to the parallel placer project. thus i need a way to get .net files into yosys json, which we've basically agreed on as the interchange format for openfpga tools
<awygle>
but if that's useful to more than just me, it could live somewhere other than github.com/awygle/a-silly-name
<mithro>
awygle: Converting the .net from vpr output into json seems like a useful thing
<mithro>
awygle: I mean it would be probably better to make vpr output json directly -- but I'm happy to start with a conversion script
<mithro>
awygle: btw, say my nick if you want my attention :-P
<pointfree>
DSIINP connects the portpin nyble *directly* to the routing fabric. Which pins are used by the routing fabric? That's decided by the drive modes you select for those pins.
<pointfree>
For the output to the blue led I chose strong pull-up, strong pull-down (we're driving an led)
<pointfree>
For the input I unforunately also chose strong pull-up, strong pull-down... routed directly into the routing fabric (!)
<pointfree>
...and input/output buffers disabled for all the others (also used for Hi-Z analog)
<cyrozap>
pointfree: Would that explain the problems you've been having?
enriq has quit [Ping timeout: 264 seconds]
pie__ has quit [Remote host closed the connection]