04:01 <Ocheg> Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech

04:02 <Ocheg> Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech

04:02 <Ocheg> Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech

14:27 <whitequark> tnt: so, about the ecp5 spi thing

14:27 <whitequark> can you explain when the fpga will assert cs?

14:28 <whitequark> i'm currently refactoring the spi code (which i forgot how gross it is...) to support this use case nicer

14:33 <tnt> My understanding is that a SDR/ShiftDR burst corresponds to one spi exchange of asserting CS / shifting / de-asserting CS.

14:35 <tnt> so DRPAUSE is the 'deasserted' CS state.

14:38 <whitequark> ie CS is only asserted in DR SHIFT?

14:38 <whitequark> that makes sense; iirc there is an internal TAP signal that correspons to that

14:39 <whitequark> tnt: do you have to go through pause DR or can I exit? I assume I can

14:39 <tnt> daveshah would know better, but that's my assumption. I really only ever used in the way that the python script does.

14:40 <tnt> (i.e. shift dr is asserted and everything else is not)

15:25 <cyberclown> Hi, I'm currently going through the glasgow revC1 design and I'm struggling to understand the reasoning behind the ATECC508A chip included. From what I understand it seems to be a cryptographic co-processor? Is this a fluke in the BOM or is there a valid reason to have such a thing on a debug tool?

15:26 <whitequark> cyberclown: there are vendors that sell OSHW design clones of specific esden production runs (for example), i.e. with silkscreen saying it was made by 1b2 whereas in fact it was some random chnese vendor

15:27 <whitequark> the original reasoning behind including ATECC508A would be for the vendor to be able to see if a returned device should be handled under warranty or not

15:27 <whitequark> in practice it is not clear whether the cost is worth the benefit, we went back and forth on this topic a bit

15:28 <whitequark> it is not intended to affect operation of the device in any way and in fact it is not possible for it to even if we tried

15:28 <cyberclown> ahh I see. Thanks for the info! So if I assemble my own board for personal use I can just leave it unpopulated?

15:28 <whitequark> pretty much

15:28 <tnt> Maybe it should be marked as DNP on the schematics.

15:28 <cyberclown> Great! Looks like an awesome project btw. Thanks for making it open source :)

15:28 <whitequark> worst case, the CLI will show a warning for that board which can be turned off. but probably not even that

15:29 <whitequark> since the utility for end user knowing whether the board is "genuine" or not in some way is quite low. if it works, it works

15:30 <whitequark> we'd better spend the resources on selftest rather than that

15:32 <cyberclown> Seems logical. Another question if I may: I've thought about adding position markers for the BGA in the copper layer (to make hand assembly a little easier). Can I just add these in the copper layer and leave the silkscreen etc. as is or should I somehow indicate that it's changed from the original version?

15:33 <tnt> ? isn't there position marker in the silk ?

15:34 <cyberclown> There is, but I'd rather not rely on the relative positioning of silkscreen and copper layer. Just a habbit

15:35 <whitequark> the assembly is quite dense so if your fab fucks up the silk alignment you're not going to get a working board i think

15:36 <whitequark> that said

15:36 <whitequark> if you are modifying the gerbers I would ask you to indicate that you did so, as a courtesy

15:38 <cyberclown> Well, I don't know if it's really necessary anyways. Like I said, it's just become a habbit and I'm used to position my BGAs with these markers.

15:38 <cyberclown> But sure, I'll add some indication if I end up changing anything!

15:54 <electronic_eel> cyberclown: while I'm with you that a marker in copper is more accurate than in silk, I'm not sure if that will work out with glasgow

15:54 <electronic_eel> you don't have much space around the fpga, so maybe a small mark in the top left and bottom right will be possible when you move some vias

15:55 <electronic_eel> but these marks will be so small that they are hardly visible

15:56 <electronic_eel> I suggest to add some copper/silk offset marks instead. you could use the fiducials we already have in several places on the board

15:57 <electronic_eel> just make a circle around the fiducials in the silk

15:57 <electronic_eel> when the fab has noticable offset between copper and silk, you'll spot that on the fiducials and can correct for it

15:59 <electronic_eel> oh wait, you don't have to change anything at all - we already have copper/silk offset markers: the testpoints

15:59 <electronic_eel> the testpoints have a solid copper circle with a small silk circle around

16:03 <cyberclown> electronic_eel you're right about that. I had some hopes that maybe bottom left would be possible if D3 is re-routable to the left instead of downwards. But so far I've not really come to do anythingm, I've just had this idea floating around my head and thought I'd use the chance to ask just in case I end up doing it.

16:03 <cyberclown> But yeah, using the existing testpoint to check the alignment sounds like a good idea, too. Thanks a lot for the suggestions!

16:04 <cyberclown> Sounds a lot less painfull, too ^^

18:44 <tomtastic> "debug ARC processors via JTAG" ?

18:44 <tomtastic> ARM?

18:47 <tomtastic> Or the 'Argonaut RISC Core'?

19:17 <gruetzkopf> argonaut risc core

19:18 <gruetzkopf> that descendant of a super-nintendo accellerator is surprisingly common

19:22 <tomtastic> ooh, cool