Current Server Time: 13:41 (Central Europe)

#apertus IRC Channel Logs

2016/02/07

Timezone: UTC


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