*** tpb has joined #photonsdi | 00:00 | |
*** RexOrCine is now known as RexOrCine|away | 00:06 | |
Bertl_oO | felix_: have you written a test procedure how to check that the FPGA is properly working (soldered) yet? | 03:04 |
---|---|---|
Bertl_oO | if not, would be great if you could do so, to avoid sending the assembled boards forth and back till they 'work' :) | 03:05 |
*** se6astian|away is now known as se6astian | 07:01 | |
*** se6astian is now known as se6astian|away | 08:56 | |
*** se6astian|away is now known as se6astian | 10:52 | |
*** se6astian is now known as se6astian|away | 12:15 | |
*** se6astian|away is now known as se6astian | 12:26 | |
felix_ | haven't done that yet, but it is a good idea. i'll put that on my todo list | 14:28 |
felix_ | oh and i still don't know when exactly i'll have time to go to vienna; so far i can only say that it will likely be between calender week 43 and 47... | 14:31 |
felix_ | the part of the design that is still a bit unclear to me is btw. the part where the camera talks to the fpga via jtag | 14:36 |
Bertl_oO | this should be similar to the way the USB 3.0 plugin is handled, but for an initial test I would suggest to connect the JTAG directly (eliminating other problems) | 15:25 |
felix_ | in standalone mode, the modules needs two power supplies (5v and 3.3v); that's a bit annoying, but needed one of the ti stepdown modules less. or route the jtag to some other connector on the camera? | 15:30 |
*** se6astian is now known as se6astian|away | 15:41 | |
Bertl_oO | I guess we all have a desktop power supply which can provide 5V and 3.3V | 16:00 |
felix_ | yep. hmm, maybe i should have also designed a small baseboard for bringup with a 5v->3.3v stepdown and a ft2232h that connects to both jtag and serial port. but that's something that can be improvised with two pcie x1 connectors and a few wires | 16:04 |
*** RexOrCine|away is now known as RexOrCine | 16:11 | |
RexOrCine | Is it possible to get a rough ball-park percentage of the module's software completion please? | 16:51 |
Bertl_oO | my guess would be roughly 0% ;) | 16:57 |
felix_ | the gateware? that's rather hard to say. i did most of the work to understand how things work, maybe about 60% of how to implement them, but only maybe 25% of the final implementation, that is also mostly untested | 16:58 |
*** RexOrCine is now known as RexOrCine|away | 16:58 | |
Bertl_oO | really 25% already? | 16:59 |
felix_ | iirc the scrambler, the crc, small part of the frame generation (need to rewrite that to use it on the axiom beta though!) and some other stuff i don't really remember are sort-of implemented | 17:01 |
felix_ | need to be properly tested and cleaned up though | 17:01 |
Bertl_oO | nice | 17:01 |
felix_ | currently it's a unreleaseable mess that contains nonfree parts and was maybe last tested two weeks before the last change | 17:03 |
felix_ | my plan is to first work on the board support for the current prototype | 17:03 |
felix_ | that's osmething that can be released as soon as it's finished | 17:04 |
felix_ | then cleaning up and testing the scrambler and crc; if that works already release that part | 17:04 |
felix_ | then the rest ;) | 17:04 |
felix_ | need to set up my improvised hardware in the loop test thing again to test things; needed the test station for another (commercial) project, so i took it apart | 17:07 |
Kjetil | I guess we need to at least do some SDI jitter testing at some point | 17:08 |
felix_ | talking about hardware-based test setups: https://github.com/felixheld/qspimux (probably not useful for the axiom, but very useful for some other projects i have ;) | 17:09 |
tpb | Title: GitHub - felixheld/qspimux: QSPI flash multiplexer - connect a SPI NOR flash to either an embedded system or a programmer for remote firmware tests (at github.com) | 17:09 |
felix_ | first get it working amd then do the jitter test. shouldn't be too bad though, since we use the good sdi interface chips ;) | 17:09 |
Kjetil | I'm not that worried about the high frequency jitter. Low frequency is a different story | 17:10 |
felix_ | ah | 17:10 |
felix_ | might need some parameter tweaking on the silabs chip | 17:11 |
felix_ | but since that chip is used for 12g sdi applications, i don't see a too big problem that can't be solved | 17:12 |
*** se6astian|away is now known as se6astian | 17:30 | |
Kjetil | felix_: You were using kicad for the layout? | 18:22 |
felix_ | yep | 18:42 |
felix_ | some nightly build version | 18:42 |
Kjetil | Happy with it ? | 18:42 |
felix_ | sort-of | 18:42 |
felix_ | i mean the commercial software packages cost a lot of money and also have their sometimes severe problems | 18:43 |
felix_ | the layout part of kicad is rather good; the schematics part and especially the library part still have a lot of room for improvement | 18:44 |
Kjetil | Last time I looked into it defining new components were a hassle | 18:44 |
felix_ | oh and a bit of a problem in the axiom photonsdi hardware was that i starte the design with a rather old version, so i mostly use the old footprints for r/c/l; the newer one is a bit better, but changing this would have resulted in a lot of small changes on the board | 18:46 |
felix_ | footprints or schematic symbols? | 18:46 |
felix_ | the how those two work together is one of my main issues with kicad, but well... | 18:47 |
Kjetil | If I remember correctly there was some peculiarities with linking schematics symbols to footprints | 18:47 |
Kjetil | so yeah | 18:47 |
felix_ | you can add the information to the symbol which footprint should be used with it | 18:47 |
felix_ | i like that not every library has its own version of a footprint like in eagle, but the linking of symbol and footprint is much smoother in eagle | 18:48 |
felix_ | also looked a bit into altium, but i know the issues with altium mainly from a colleague who had rather serious issues with that tool | 18:49 |
Kjetil | I have a really old version of altium in a VM. But it is a bit unstable | 18:50 |
felix_ | have also tried some other tools, but those 3 are the ones i know enough about to rant about ;P | 18:50 |
Kjetil | So I'm looking for an alternative that is a bit more up to date | 18:50 |
felix_ | yeah, altium still crashes from time to time, but when you're not careful, you also might end up with getting non-wroking pcbs... (hidden layers or polygons end up being blank in the generated production data; and some othre stuff i don't remember) | 18:51 |
felix_ | kicad has a nice mode where it still shows the other layers in a dark gray, and only shows the current layer brighlt colored | 18:53 |
felix_ | but yeah, some time ago i also had a layer problem with kicad; somehow it didn't generate the solder mask for the bottom layer. that was maybe 3 years ago though and my pcb manufacturer caught that problem before the pcb went into production | 18:54 |
Kjetil | "To do: ... Integrate PCB calculator code into PCBnew/eeschema allowing for direct control of track impedance. Impedance for the lines could be defined as a net property/attribute." - well.. Yes! | 18:58 |
felix_ | yep, thats not implemented yet. and the net classes had a nasty well not exactly bug, but unexpected behaviour, that the net class geometry you defined for differential signals was ignored. that should be fixed in current nightly builds though | 19:04 |
felix_ | the lenght matching tools also have some not very well documented keybindings to change parameters; iirc two of the parameters that were in there a few years ago also seemed to be dropped | 19:05 |
felix_ | but at least it has rather useable length matching tools | 19:05 |
felix_ | oh and anoth ernasty bug in altium was when you have a multiscreen setup, it might happen that you place things in the schematics when clicking inside another window on another screen when the altium schematics windows had the input focus before that | 19:09 |
felix_ | *another nasty | 19:09 |
Kjetil | wth | 19:38 |
*** se6astian is now known as se6astian|away | 20:46 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!