Current Server Time: 04:28 (Central Europe)

#apertus IRC Channel Logs

2016/02/07

Timezone: UTC


00:00
Bertl
and to make sure, reflash the RFE
00:01
John_K
ok
00:03
John_K
INITN is still 0
00:04
John_K
do I have to 'reboot' the lattice after programming it?
00:05
Bertl
no, should be instantaneous
00:06
John_K
hrm
00:06
John_K
any thoughts?
00:07
Bertl
check with ./cmv_init.sh if it works
00:07
Bertl
if you get 0x0 then it doesn't
00:08
Bertl
note that you managed to get it working before, so we should be able to figure that out
00:08
John_K
still get 0's
00:08
John_K
right
00:09
Bertl
so, what did you do last time :)
00:09
Bertl
i.e. repeat the steps, and see when it starts working
00:10
John_K
well everything went south when we enabled cmv12k service and rebooted
00:11
Bertl
fair enough, try to disable it (this time without deleting it :)
00:11
John_K
yeah :{
00:11
Bertl
i.e. systemctl stop cmv12k
00:11
Bertl
systemctl disable cmv12k
00:11
John_K
yep
00:14
John_K
do any of these currents look out of place? https://gist.github.com/John-K/4149da3d11bed45d2b1f
00:15
Bertl
are your shunt resistor values correct?
00:15
Bertl
it looks a little hight
00:15
Bertl
*high
00:16
John_K
my changes may have been overwritten
00:17
John_K
one sec
00:17
John_K
they appear to be correct
00:17
Bertl
beta/sensor part is a little high
00:19
Bertl
hmm ... it might be the zynq firmware
00:20
John_K
the temperature or our problems?
00:20
Bertl
our problems
00:20
John_K
err s/temperature/current draw/
00:20
John_K
what are your thoughts?
00:21
Bertl
sec, checking
00:21
John_K
k
00:27
Bertl
yes, with the icsp.bit loaded, the RFE seems to work fine
00:27
Bertl
please check on your side
00:28
John_K
f671a9a98f7bbbc38636aab43954e979 icsp.bit ?
00:29
Bertl
yup
00:32
John_K
so I guess I need to break out the Logic Analyzer then
00:33
Bertl
sec
00:33
John_K
unless you can think of some other way to validate this
00:33
Bertl
I'm recreating your issue here :)
00:33
John_K
ok
00:33
John_K
systemd disable cmv12k
00:33
John_K
reboot
00:34
John_K
./power_init.sh
00:34
John_K
./power_on.sh
00:34
John_K
cat icsp.bit > /dev/xdevcfg
00:34
John_K
./icsp_sel.py B
00:34
John_K
./pic_gpio.py
00:34
John_K
that's where I'm at
00:40
slikdigit_
joined the channel
00:42
John_K
brb digging for a heatsink
00:42
Bertl
hmm, no, seems to work fine here
00:46
John_K
hrm
00:46
John_K
so you cleared the PIC FW and the CPLD config
00:46
John_K
and re-programmed both
00:46
Bertl
yup
00:47
Bertl
well, strictly speaking I didn't clear them, just overwrite them
00:47
John_K
well this is strange
00:47
John_K
especially since we got it working once
00:48
Bertl
yes, indeed
00:48
John_K
we did change some feature flags
00:48
John_K
what do those do?
00:48
Bertl
they configure the FPGA, but I tried with 0000 and 0620 here
00:48
Bertl
0620 is the "proper" value from the svf
00:48
Bertl
both work fine here
00:49
John_K
can you pastebin your pic_gpio output and pic_jtag_dump output?
00:50
Bertl
the dump doesn't help you, I'm using a XO2 2000 here
00:51
Bertl
http://pastebin.com/raw/iXZRRzLe
00:51
slikdigit_
left the channel
00:52
John_K
oh, right
00:53
Bertl
but I don't think the MachXO2 makes a difference
00:54
John_K
my gpio's are different straight off of boot
00:54
John_K
https://gist.github.com/John-K/b4df98812f03d8ee477f
00:55
Bertl
we probably should set some PIC initial defaults
00:56
John_K
ah
00:56
Bertl
after the boot, don't load the icsp.bit
00:57
John_K
and just use cmv_hdmi3.bit
00:57
John_K
?
00:57
Bertl
just load the cmv_hdmi3.bit and try a sel A/B
00:58
John_K
icsp_sel won't work without icsp.bit loaded right?
00:58
Bertl
it actually should with the proper cmv_hdmi3.bit
00:59
John_K
it locks up the system here
00:59
Bertl
(which provides the I2C bus)
00:59
John_K
8d56f01e1f1e72f45faa975797d1fb3b cmv_hdmi3.bit
00:59
Bertl
okay, so let's work around that for now with configuring the PIC with icsp.bit first
01:00
Bertl
i.e. create a script which loads the icsp.bit
01:00
John_K
curious
01:00
John_K
I'm getting a timeout even now that I've loaded icsp.bit
01:00
John_K
ah wait
01:00
John_K
my bad
01:00
Bertl
power?
01:00
John_K
yes
01:01
John_K
rebooting to try this fresh
01:02
John_K
it hangs in icsp_sel
01:02
John_K
with hdmi3
01:02
John_K
can you verify the hdmi3.bit you're using?
01:03
John_K
ok I have B selected
01:03
Bertl
doesn't help you either, my hardware is slightly different
01:04
Bertl
try to set 'sane' defaults for the PIC with icsp.bit in a script
01:04
John_K
ok so power init, power on, load icsp.bit, select B
01:04
John_K
using the i2c_set?
01:04
Bertl
add that to the kick.sh before the cmv_hdmi3.bit is loaded
01:04
Bertl
yes, the PIC has the following registers:
01:07
Bertl
http://pastebin.com/raw/nfhkvdGg
01:07
Bertl
basically the tris gives the direction, the latch the output value
01:08
Bertl
and adding pullups to all ports won't hurt (marked as ^ in the gpio output)
01:10
John_K
so tri and pullup to 0xFF and latch to 0
01:10
John_K
for each?
01:10
Bertl
for tris a '1' means input
01:10
Bertl
i.e. that should work with the pullups
01:11
Bertl
OTOH, that should be the default IIRC
01:12
John_K
it looks like
01:12
Bertl
please check what happens if you select the RFE
01:12
John_K
how does latch work on the PIC? should we set it to 0 and then have it set it back based on value of the pins?
01:12
John_K
what do you mean by that?
01:12
Bertl
with icsp.bit
01:12
Bertl
so that i2cdetect -r -y -a 2 shows the 10's and 30's
01:13
Bertl
and then if you load the cmv_hdmi3.bit
01:13
Bertl
and repeat the i2cdetect after that
01:13
Bertl
does it time out or show the 10's 30's and 70?
01:14
John_K
10's 30's 70
01:14
Bertl
so the bus is intact after loading the cmv_hdmi3 and i2c should be fine
01:14
John_K
oh wait, let me load cmv_hdmi3 that was my baseline check
01:15
John_K
still the same after loading cmv_hdmi3
01:15
Bertl
okay, so the icsp_* commands will hang after the cmv_hdmi3
01:15
John_K
right
01:15
Bertl
because you don't have the icsp serial interface
01:15
John_K
cmv_init still prints 0s
01:15
John_K
which makes total sense
01:16
Bertl
but the pic_jtag and gpio stuff will work fine
01:16
Bertl
(because you have the i2c bus in place)
01:16
John_K
pic_gpio works
01:17
Bertl
so you can (manually) play around with the pic ports and see what makes the cmv SPI interface work
01:17
Bertl
you just need to select the RFE before you load the cmv_hdmi.bit
01:17
Bertl
actually you can also manually switch that with
01:18
Bertl
i2cset -y 2 0x70 0x0 0x4
01:19
Bertl
if the pic doesn't show up on the bus, try with ./gpio.sh init
01:19
Bertl
*gpio.py
01:21
John_K
so none of those ports should be outputs right?
01:21
Bertl
they can be, but they do not need to
01:22
Bertl
the A port is basically all outputs except for A6 and A7 (which is unused)
01:22
Bertl
but they are not relevant for your setup
01:22
John_K
well currently they're set to inputs on both our boards
01:22
John_K
oh
01:23
Bertl
the B port is trickier, as INITN and DONE can be input as well as output on the lattice
01:23
Bertl
lower nibble on port C is the JTAG
01:23
Bertl
C6 is when you disable the JTAG port via the feature bits
01:24
Bertl
(i.e. there you can re-enable the jtag)
01:24
Bertl
and C7 is to restart the lattice
01:24
Bertl
(which can also be disabled via the feature bits)
01:24
John_K
so C7 should be an output
01:24
John_K
?
01:24
John_K
and is it reset low?
01:25
Bertl
yes, but it doesn't matter with the pullup and it doesn't matter with your feature row
01:25
Bertl
but you can try pulling it high
01:26
Bertl
I'm not entirely sure how the machxo2 handles the programn pin
01:26
John_K
btw, in I1+0^, I means input, what does the 1 mean?
01:27
John_K
I assume +0 means current value is low
01:27
John_K
and ^ means pullup enabled
01:27
Bertl
the first numeric value is the latch
01:27
Bertl
i.e. what an output would get
01:27
Bertl
the second numeric vaue is the port, i.e. the input
01:28
John_K
so even though I write a 0 to the latch for C, C0,C1,C3 latch is always 1
01:28
Bertl
shouldn't be
01:28
Bertl
the latch should reflect what you set
01:29
Bertl
the port will change depending on the actual input
01:29
John_K
https://gist.github.com/John-K/45b74c27cd0ddb3fbd67
01:30
Bertl
ah, sorry, I think I got the order wrong, sec
01:30
Bertl
yeah, first the port, then the latch
01:31
Bertl
so I0+1^ means:
01:31
Bertl
pin is an input, the latch says '1' (i.e. output would produce a '1')
01:31
Bertl
but the port reads '0' (i.e. that's the input value)
01:31
Bertl
and a pullup is active (^)
01:32
Bertl
the + means positive polarity but is not used on the pic
01:32
John_K
so in my dump, only B7,C0,C1,C3 are reading as HI
01:32
Bertl
(it is relevant on the I2C expanders, i.e. gpio.py)
01:32
John_K
ah
01:33
Bertl
yes, that's correct
01:34
Bertl
rb6/rb7 is the I2C bus, so they will give strange results
01:35
John_K
ok
01:35
Bertl
and C0-C3 is the JTAG interface
01:36
Bertl
what version is your power board?
01:36
John_K
this is very strange that I still get 00000000 back from cmv_init though
01:36
John_K
0.22
01:37
Bertl
okay, can you upload the gpio.py output again?
01:39
John_K
default on boot, or currently after me playing with it?
01:39
Bertl
gpio.py (you played with that?) not pic_gpio.py
01:39
John_K
oh gpio.py
01:39
John_K
one sec
01:40
John_K
https://gist.github.com/John-K/86686b5e707548a8e889
01:43
Bertl
hmm, did you try ./gpio.py init ?
01:43
John_K
just did that
01:44
John_K
refresh the page
01:44
Bertl
interesting
01:44
Bertl
[22a6] CSE_EN O0+0^ confuses me
01:45
John_K
what is that signal for?
01:45
Bertl
the enable line for the CSE (center solder on area, south east)
01:46
John_K
ok, is it weird that it would be disabled?
01:46
John_K
or should init set it high?
01:47
Bertl
it should be enabled
01:47
Bertl
the init should enable it
01:49
Bertl
it is unlikely to be relevant though
01:49
Bertl
just weird
01:52
John_K
everything about this current state is weird
01:53
Bertl
okay, try to load the .cfg and .ufm via the pic_jtag_load.py
01:53
John_K
I still think this is a problem with the lattice
01:54
John_K
is 1151 the right # of pages for a 640?
01:54
Bertl
yup
01:54
John_K
and 192 for user
01:54
Bertl
yup
01:54
John_K
hrm
01:55
John_K
INITN_E and DONE_E are both 0's
01:55
Bertl
what about cmv_init.sh?
01:55
John_K
after programming
01:55
John_K
still 0
01:55
Bertl
then yes, something is wrong with the lattice
01:55
John_K
shouldn't INITN_E and DONE_E go high once it's running?
01:56
Bertl
depends on the feature bits
01:56
Bertl
let me look up what would be correct there
01:56
John_K
ok
01:57
John_K
are you looking at the datasheet or some other doc for this?
01:57
Bertl
datasheet
02:04
Bertl
hmm ...
02:04
Bertl
the lattice will stay in initialization as long as INITN or PROGRAMN is low
02:05
John_K
check page 3 of file:///Users/jkelley/Downloads/MachXO2ProgrammingandConfigurationUsageGuide.pdf
02:05
John_K
oops
02:05
Bertl
a falling edge on PROGRAMN will trigger a REFRESH
02:05
John_K
http://latticesemi.com/view_document?document_id=39085
02:05
Bertl
when the configuration fails, INITN will be pulled low
02:06
John_K
right
02:06
Bertl
when the FPGA reaches the user mode, DONE will go high
02:06
John_K
we're probably looking at the same state machine diagram right now
02:06
Bertl
the feabits can override the pins though
02:06
John_K
ah
02:07
Bertl
bit 5 is PROGRAM Persistence Disable
02:07
Bertl
bit 6 is INIT Persistence Enable
02:07
Bertl
bit 7 is DONE Persistence Disable
02:07
Bertl
note the Enable vs. Disable
02:08
Bertl
so that is the '2' in 0620
02:08
John_K
that '2' is PROGRAM disable
02:09
Bertl
hmm, right, so we want a 6 there
02:09
John_K
where is the description for these bits?
02:10
Bertl
in TN1246
02:10
John_K
ahh table 4, page 10 of programming and configuration guide
02:11
Bertl
17-65
02:12
Bertl
Table 17-88. Program FEABITs (0xF8)
02:14
John_K
so if the DONE and INITN persistence is not enabled, they'll only go high for a short period?
02:14
John_K
trying to find a definition for this behaviour
02:14
Bertl
so we probably want 06C0
02:15
Bertl
which should enable INITN, DONE and PROGRAMN
02:16
Bertl
and disable SPI, I2C, SlaveSPI but not JTAG
02:16
Bertl
which gives proper '1' outputs here
02:17
Bertl
funny why the lattice tools use 0620 instead ...
02:18
John_K
so ./pic_jtag_feat.py 0000000000000000 06C0 then?
02:18
Bertl
yes, works here to get INITN and DONE up to '1'
02:19
John_K
yep
02:19
John_K
so if I set program to output it should reboot the CPLD right?
02:22
John_K
anyway, just completely powered off and back on, everything looks like we think it should AFAIK
02:23
John_K
but cmv_init doesn't work
02:23
John_K
I find I can't icsp_sel right after I upload the bitstream
02:23
John_K
I have to try a few times
02:23
John_K
or else pic_gpio.py will error out
02:23
Bertl
icsp_* commands won't work
02:24
Bertl
but you can manually steer the mux
02:24
Bertl
i2cset -y 2 0x70 0x0 0x4
02:24
John_K
that's for RFE?
02:24
Bertl
yup
02:25
Bertl
check in the icsp_sel.py code
02:25
John_K
ok
02:26
John_K
if I reboot, power init, power on, cat cmv_hdmi3.bit, i2cset -y 2 0x70 0x0 0x4, pic_gpio.py
02:26
John_K
pic_gpio errors out
02:27
Bertl
what error>
02:27
Bertl
?
02:27
John_K
error in readbyte
02:28
Bertl
i2cdetect -r -y -a 2
02:28
Bertl
10's and 30's there?
02:28
John_K
https://gist.github.com/anonymous/cc0d25c0c86e16bb49f2
02:28
John_K
nope, just a 70
02:29
Bertl
./gpio.py init
02:29
Bertl
then recheck?
02:30
John_K
same
02:30
Bertl
what was the output of the gpio.py init?
02:30
John_K
https://gist.github.com/John-K/01524af79e0a364e1efd
02:31
Bertl
damn, the init is not working as supposed
02:31
Bertl
your problem is that both pic reset lines are low
02:31
Bertl
[22a4] B_#RST O0+0^ [23a4] A_#RST O0+0^
02:32
Bertl
ah, I see, the init doesn't change the defaults
02:32
Bertl
this is actually done by power_on.sh
02:33
John_K
I don't see any code in gpio.py checking arguments either
02:33
Bertl
if len(sys.argv) > 1:
02:33
Bertl
if sys.argv[1] == "init":
02:33
Bertl
gpio_init(i2c, ver)
02:34
John_K
not in the version I have :(
02:34
John_K
(this is why we need git)
02:35
John_K
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/gpio.py doesn't have that either
02:35
Bertl
indeed, but the init code wouldn't help anyway
02:36
Bertl
uploaded the latest version
02:37
Bertl
the problem is your power_on.sh (for the pic not showing up)
02:37
Bertl
or well, not the power_on.sh per se, the fact that the reset lines default to low
02:38
John_K
gpio.py isn't updated in ICSP folder
02:38
John_K
sure, but power on should at least turn them on
02:39
Bertl
no, it shouldn't
02:39
John_K
no?
02:39
Bertl
you normally do not need the PICs active
02:39
Bertl
anyway, we can turn them on manually, so you can reach the PIC
02:44
Bertl
. ./i2c0.func; i2c0_bit_set 0x22 0x14 4
02:44
Bertl
i2c0_bit_set 0x23 0x14 4
02:44
Bertl
will turn the PICs on
02:47
John_K
trying
02:48
John_K
works
02:48
John_K
ok
02:49
John_K
so now the real question is why isn't RFE passing through SPI to the sensor, agreed?
02:49
Bertl
first, does it properly initialize? i.e. do you get the INITN/DONE ='1'?
02:49
John_K
yes
02:49
John_K
[B0] INITN_E I1+0^
02:50
John_K
[B2] DONE_E I1+1^
02:50
Bertl
okay, just to make sure, please run the following:
02:50
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/pic_jtag_refresh.py
02:52
John_K
[root@beta bringup]# ./pic_jtag_refresh,py
02:52
John_K
found MXO2-640HC [00000001001010111001000001000011]
02:52
John_K
status 00080100 [00000000000010000000000100000000] CFG=SRAM DONE SDMEN BSE=OK
02:52
Bertl
okay, that is a clear config okay, FPGA active
02:52
Bertl
cmv_init.sh still returns 0?
02:53
John_K
yes :(
02:53
Bertl
very strange
02:53
John_K
I feel like this worked before we messed with feature flags or something
02:53
Bertl
you can easily go back to the original state
02:54
Bertl
./pic_jtag_erase.py will wipe the lattice clean
02:54
Bertl
i.e. everything, config, user, done, feature row/bits
02:55
Bertl
bascially the same state as it was when soldered on
02:56
John_K
yeah tried setting and not setting feature flags and cmv_init returns 0 each time
02:57
Bertl
I would suspect a hardware problem somewhere
02:57
Bertl
there is no indication that the lattice isn't working as expected
02:58
Bertl
so my bet would be on one of the CMV SPI lines being flakey
02:58
John_K
I'll try the other sensor PCB
02:58
Bertl
you can test them with the tag_pin20.bit
02:58
Bertl
and a scope on the respective pin
02:58
John_K
I may have to do that
03:01
John_K
I'm still getting 0 with the other sensor PCB as well
03:01
John_K
how did this work that one time?
03:02
Bertl
I tell you, I have no clue at the moment
03:02
Bertl
I would suggest to add some code to the lattice to verify that it is actually working
03:03
Bertl
for example, you could connect the IO_SCL and IO_SDA
03:03
Bertl
and then toggle one with the PIC
03:03
Bertl
this way the other will change (as input) if the lattice is working correctly
03:05
John_K
yeah, I'll try soldering some tiny wires and look at it with a scope
03:09
Bertl
I've added the necessary code :)
03:09
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LATTICE/
03:10
Bertl
IO_SDA is forwarded to IO_SCL
03:11
Bertl
move the files to 640 dir
03:12
John_K
ok will give it a shot now before I take a break
03:12
Bertl
yeah, I'm off to bed soon anyway
03:18
Bertl
works here
03:19
Bertl
i2c2_set 0x38 0xDF
03:19
Bertl
i2c2_set 0x39 0x20
03:19
Bertl
i2c2_set 0x39 0x00
03:19
Bertl
toggles IO_SCL as well
03:20
John_K
yep it works
03:20
Bertl
hmm, hmm ...
03:20
Bertl
did you run ./fclk_init.sh ?
03:20
John_K
I was just figuring out those values myself
03:20
John_K
not before, no
03:20
Bertl
try that for cmv_init.sh
03:21
John_K
still 0
03:21
Bertl
so, to sum it up, FPGA is working fine
03:21
Bertl
zynq is working fine
03:22
John_K
so signs would point to something likely on the sensor side of the FPGA
03:22
John_K
either interface board or sensor
03:22
Bertl
sensor doesn't answer to SPI
03:22
Bertl
you switched out the SFE
03:22
John_K
right
03:22
Bertl
so unlikely that this one is the cause
03:23
John_K
it could be the dummy but I can't easily switch that out as my spare doesn't have the long header pins
03:23
Bertl
power levels are fine IIRC, so that should not be the problem either
03:23
Bertl
one thing you can easily try out right now is to disconnect the power completely
03:24
Bertl
wait a few seconds and reconnect, in case the sensor got "confused"
03:24
Bertl
make sure to run ./fclk_init.sh, ./power_init.sh and ./power_on.sh
03:24
Bertl
load the cmv_hdmi3.bit and then cmv_init.sh should work
03:25
John_K
ok
03:25
Bertl
the next steps would be to use the tag_pin20.bit and probe the SPI outputs
03:25
Bertl
if they work fine, testing the SPI input is the next step, which is a little trickier
03:26
John_K
still 0
03:26
John_K
how is testing SPI input tricky?
03:26
John_K
simply because I need to solder wires on?
03:27
Bertl
well, it is an input to the zynq, over a level converter
03:27
Bertl
there is a bitstream for testing that called check_spi.bit
03:27
Bertl
which produces a pattern on the outputs (EN, CLK, SDO) which incorporates the pattern seen on the input (SDI)
03:28
Bertl
so you can get away with a scope an a tiny cable :)
03:28
John_K
input being something generated in software?
03:29
John_K
I'm still confused as to how this worked once
03:30
Bertl
sdo <= sdi_clk xor sdi;
03:30
John_K
where are we generating sdi though?
03:30
Bertl
en <= sdi_clk;
03:30
Bertl
sck <= chk_clk and sdi_clk;
03:30
Bertl
sdi_clk and chk_clk are generated in the zynq
03:31
Bertl
so if you bridge sck with sdi, sdo will change :)
03:31
John_K
ah
03:31
John_K
that could work
03:32
Bertl
well, that's how I tested the SPI bus back then :)
03:32
Bertl
so yes, it works :)
03:32
Bertl
anyway, off to bed now ... have fun!
03:32
Bertl
changed nick to: Bertl_zZ
03:34
John_K
thanks
03:34
John_K
thanks for all the help today, have a good night
03:41
John_K
I got it to return 0x296 by moving a board slightly
03:41
John_K
looks like it might be an interface problem somewhere
05:25
danieel
left the channel
08:17
jucar
joined the channel
08:34
danieel
joined the channel
08:53
jucar
left the channel
10:40
Bertl_zZ
changed nick to: Bertl
10:40
Bertl
morning folks!
10:40
Bertl
John_K: yeah, I was suspecting the hardware at this point
10:41
Bertl
I would suggest double checking the pins at the SMD connectors for cold solder joints
10:42
Bertl
a good way is to get a needle and try to move each pin sideways under a microscope
11:59
ShinyCyril
hello :)
12:01
Bertl
hey :)
12:02
ShinyCyril
how are things?
12:03
Bertl
fine, thanks! on your side?
12:04
ShinyCyril
yeah good thanks - I've been playing around with FPGAs and image sensors for my master's project, hence my interest in the Axiom project!
12:07
Bertl
sounds good!
12:10
ShinyCyril
sadly my budget is non-existent - had to make do with a VGA resolution OV7670 instead of the nice CMOSIS sensors you guys have ;)
12:10
Bertl
indeed there is a price difference :)
12:12
ShinyCyril
what sort of approach did you guys take with your sensor module -> mainboard interface?
12:13
ShinyCyril
I guess it's the focus area of my project - I settled on a HDMI-like interface which fits a bunch of extra data (flash strobes etc.) into the blanking periods
12:13
ShinyCyril
I'm interested to see what approach other people have taken!
12:44
Bertl
well, we have an 80 channel LVDS + a bunch of control lines (I2C, SPI) as well as six regulated voltages as interface to the SFE
12:46
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_sensor_cmv12000_zif_v0.18_r1.2.pdf (page 2 basically)
12:58
ShinyCyril
ah ok going straight into the FMC
12:59
ShinyCyril
what happens when you plug a different sensor module in? Will you use partial reconfiguration on the FPGA or something?
13:13
Bertl
yes, the FPGA (zynq) will be reconfigured if necessary
13:19
ShinyCyril
I must read into reconfiguration at some point
13:19
ShinyCyril
the downside with my approach is that I must embed an FPGA into the sensor module
13:22
Bertl
it's a common approach, if you use an FPGA with GBTs, you can even produce high quality data streams for HDMI or DP directly
13:46
ShinyCyril
using Digilent's reference design I was actually able to get 1080p HDMI working on normal IO - I don't have enough experience to play around with the GBTs currently
13:46
ShinyCyril
however that was pushing the chip beyond its rated limits
13:55
Bertl
well, the zynq is doing 1080p60 over "normal" LVDS
13:55
Bertl
similar works for Spartan 6 and even Spartan 3 IIRC
13:56
Bertl
(although it requires careful placement there)
14:02
ShinyCyril
interesting that the Spartan 3 can manage such speeds
14:14
Bertl
not within spec, of course :)
14:31
jucar
joined the channel
14:49
jucar
left the channel
15:00
comradekingu
What do you think about http://0bin.net/paste/nKD3joccXzQRnwuI#CDans+bvoczxkM94Yx+JjY3xPOop7t0jFYnfye4IrKl
15:00
comradekingu
It is for the FSF to hand out as a flyer to video people
16:59
aombk
joined the channel
17:02
aombk2
left the channel
17:37
jucar
joined the channel
20:03
se6astian|away
changed nick to: se6astian
20:03
Bertl
evening se6astian!
20:07
se6astian
good evening
20:11
slikdigit_
joined the channel
21:10
ShinyCyril
left the channel
21:10
ShinyCyril
joined the channel
21:45
jucar
left the channel
21:50
slikdigit_
left the channel
22:01
GrahamM
joined the channel
22:24
se6astian
off to bed
22:24
se6astian
good night
22:43
GrahamM
left the channel
22:59
se6astian
changed nick to: se6astian|away