Current Server Time: 20:32 (Central Europe)

#apertus IRC Channel Logs

2015/04/03

Timezone: UTC


00:27
fsteinel
left the channel
00:27
fsteinel_
joined the channel
00:37
fsteinel_
changed nick to: fsteinel
01:02
fsteinel
left the channel
01:02
fsteinel
joined the channel
01:47
Bertl_oO
off to bed now ... have a good one everyone!
01:47
Bertl_oO
changed nick to: Bertl_zZ
02:05
slikdigit
left the channel
02:35
dmjnova
joined the channel
03:33
Rebelj12a
joined the channel
04:32
slikdigit
joined the channel
04:32
slikdigit
left the channel
04:32
slikdigit
joined the channel
05:38
Rebelj12a
left the channel
06:58
se6astian|away
changed nick to: se6astian
06:58
se6astian
good morning
07:59
Francky
joined the channel
08:01
Francky
hi
08:05
Francky
does someone know how to connect the fclk of the ps side of the zynq to the pl side in vhdl without block design gui ?
08:08
Francky
it seems to be very hard without the gui... :(
08:09
se6astian
hmm, I am afraid only Bertl is really able to answer that :)
08:17
Bertl_zZ
changed nick to: Bertl
08:17
Bertl
morning folks!
08:18
Francky
i use the gui for this time, i will see if i can do this in another way later
08:18
Bertl
Francky: it's rather trivial, that's what the ps7_stub.vhd is for
08:19
Bertl
just connect the ps_fclk array there to a signal and you're done
08:19
Francky
perfect :)
08:21
g3gg0
joined the channel
08:22
Francky
the 4 ps_fclk are at 33MHz without configuration right ?
08:26
Bertl
I think they are kind of pre-configured by the bootloader and/or kernel, so don't assume that, check first what actual frequency you get or configure it on the PS side (linux)
08:26
Bertl
you can also use a few commands on the bootloader to configure them properly
08:27
Bertl
also note that you need to enable the internal level shifters
08:39
Francky
the ps_fclk voltage level is not the same as the pl ?
08:41
Bertl
the PS has a lower voltage IIRC, the level shifters adapt it to the PL fabric
08:41
Bertl
(they are inside the zynq)
08:42
Francky
ok and as i see the LVL_SHFTR_EN is set in the ps side
08:43
Bertl
yes, you can also do that on the bootload
08:43
Bertl
(or via jtag)
08:43
Francky
ok
08:53
Francky
i still have a problem with router...
08:54
Bertl
router?
08:54
Francky
i have made a kdc file to route lvds_in and lvds_out signals on the sata connectors of the breakoutboard to be able to make a bridge between in and out signal by stat cables
08:54
Francky
placer
08:54
Francky
xdc*
08:54
Bertl
okay
08:54
Bertl
did you specify/load it in the build script?
08:55
Francky
but, for 1 signal, the placer says "Poor placement for routing between an IO pin and BUFG"
08:55
Francky
yep it is good for all signals, exept one (two in fact because it is a lvds_in)
08:56
Bertl
can you upload the sources?
08:56
Francky
these lvds signals are clk_word_in (_p and _n), which are connected to a ibufds block to make a "normal" signal, then this signal is connected to a pll
08:58
Francky
https://dl.dropboxusercontent.com/u/782577/sender_to_receiver/sender_to_receiver.vhd
08:58
Francky
https://dl.dropboxusercontent.com/u/782577/sender_to_receiver/sender_to_receiver.xdc
08:58
Francky
if you need other sources tell me
08:59
Francky
oh no in fact the error message is not for the lvds input signals but for the NET serial_clk_word_in
08:59
Bertl
ah, that is a clock input for the design
08:59
Francky
yep it is the clock signal for the receiver side
08:59
Bertl
you probably want to create a clock for that as well
08:59
Francky
in the xdc
08:59
Francky
ok
09:00
Bertl
yup, every input clock to the PL should be defined
09:00
Bertl
otherwise the tools do not know that it is a clock and what timing to check for
09:02
Francky
but is it a lvds clk so do i need to specify that or just create 2 clock at the same frequency on the bath pins ?
09:04
Bertl
just on the normal pin, the inverted input is assumed to be identical
09:05
Francky
the normal pin is the _p (positive) pin right ?
09:08
Francky
i have got the same error, i think the IBUFDS block is not "aligned" in the zynq with the input pin ihave selected
09:08
Francky
IBUFDS_inst (IBUFDS.O) is locked to IOB_X0Y14
09:08
Francky
and serial_clk_word_in_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y0
09:09
Francky
maybe some pins are able to catch clock and other are not ?!
09:14
Bertl
yes, there are dedicated clock pins
09:15
Bertl
but I haven't checked the xdc in this regard
09:15
Francky
i will search
09:16
Bertl
pins with MRCC or SRCC function han take and handle clock input properly
09:17
Bertl
W16/V16 isn't one of them :)
09:20
Bertl
JX*_LVDS_10/11/12/13 and BANK13_LVDS_0/1 are
09:21
Bertl
note that only affects clock inputs
09:22
Bertl
also note: you can still use other pins when you tell the tools (your "patch" :), but the performance will be worse
09:23
Francky
yep this is why i comment the patch to find a "good" way :)
09:24
Francky
i'm affraid to see that the placer says that some nets are not routed, but this is *just* a warning
09:25
Bertl
check for timing violations
09:31
Francky
it seems that input and output port need delays
09:35
Bertl
note: you can't have ODELAY elements on the HR banks (i.e. all of the microzed pins)
09:37
Francky
the iserdes2 has a IOBDELAY but it semms that oserdes2 doesn't
09:39
Francky
but it seems that the unrouted nets are due to code error
09:40
Francky
whereas it was working on simulation
09:45
Bertl
yeah, reality is quite different from simulation :)
09:46
Bertl
you also need to differentiate between logic level simulation (where everything is right on time, etc) and actual circuit simulation, where you at least get the routing/gate delays
09:47
Francky
i made the ideal one :D
09:47
Bertl
yes, it is also way faster and at least helps you to figure basic errors in the design
09:47
Francky
the problem i have is the routing of the output signal of the oserdes2 IP
09:48
Bertl
where do you route it except for the pins?
09:48
Bertl
or to put it the other way round, you can't use the oserdes2 output in the fabric easily
09:49
Bertl
the SERDES are special I/O block, like the input and output buffers
09:49
Bertl
so they only have limited connectivity to nearby elements
09:51
Francky
the output of oserdes are connected (by different signals) to a OBUFDS
09:51
Francky
to be outputed to a lvds pair
09:52
Bertl
OBUFDS should be fine
09:52
Francky
i try to put a BUFG between the output of the oseres and the input of the OBUFDS but nothing better
09:53
Bertl
no, there can't be a BUFG on the output of the oserdes
09:54
Francky
could it be because the oserdes2 is not in the same entity than the OBUFDS ?
10:04
Francky
no it seems to be clearly a vhdl code problem, besause the erros are only on some signals, whereas others don't generate error
11:07
Francky
if you have 3 free seconds, could you take a look on the code please ? https://dl.dropboxusercontent.com/u/782577/sender_to_receiver/sender_32bits_clk.vhd
11:07
Francky
i put the errors at the end
11:11
intracube
left the channel
11:42
Bertl
sorry for the delay ...
11:42
Bertl
the errors just tell you that the placer didn't route everything
11:43
Bertl
the reason for this is hidden in the rather lengthy logs
11:59
Francky
i have something interesting :
11:59
Francky
Unroutable connection Types:
11:59
Francky
----------------------------
11:59
Francky
Type 1 : OLOGICE3.OFB->IOB33M.O
11:59
Francky
-----Num Open nets: 5
11:59
Francky
-----Representative Net: Net[51] sender_32bits_clk_inst/gen_sender_8bits[1].DATA.sender_8bits_I/ser_out[0]
11:59
Francky
-----OLOGIC_X0Y97.OFB -> IOB_X0Y14.O
11:59
Francky
-----Driver Term: sender_32bits_clk_inst/gen_sender_8bits[1].DATA.sender_8bits_I/OSERDES_1/OFB Load Term [225]: gen_lvds[1].OBUFDS_inst/I
11:59
Francky
Phase 3.1 Initial Routing Verification | Checksum: 123d58d20
11:59
Francky
so the oserdes output cannot be connected to the obufds input
12:02
Francky
but it is ok for 3/5 signals...
12:34
se6astian
changed nick to: se6astian|away
12:43
Francky
YES i found it :D
12:44
Francky
i had connected OFB output pin of OSERDES2 to OBUDS
12:45
Francky
but OFB is not the right pin
12:45
Francky
i had to use OQ output pin of OSERDESE2
12:45
Francky
it is written in the xilinx doc :D
12:48
Bertl
yeah, well, nothing I could have spotted from the files you linked me :)
12:48
Bertl
but you figured it out anyway
12:50
g3gg0
left the channel
12:53
Francky
i have not finish to compile my program ! i have DRC problems now :)
13:00
Francky
so i have corrected a lot of drc errors, but i have 2 types that i need some help
13:00
Francky
the first is the voltage property that i don't set
13:02
Bertl
paste?
13:02
Francky
this seems to be done in the xdc file, shoudn'r be too complicated
13:02
Bertl
okay
13:05
Francky
so the last error (in fact it is a warning) i have is about oserdes clk and clk_div which should be driven by the same buffer type
13:06
Francky
does it mean that i need to put a BUFG on both clok ?
13:06
Francky
clocks*
13:09
Bertl
yes, basically
13:10
Bertl
there are some other combinations, but they should be the same type
13:10
Bertl
e.g. if you use a BUFR for dividing down the word clock
13:10
Bertl
then you want to use a BUFR for the bitclock as well
13:12
Francky
in fact i make the division "by my self" with a process (shouldn't be the better way)
13:12
Francky
but with adding the BUFG, it doesn't seems to be better
13:12
Francky
i.e. the warning stays
13:14
Bertl
in this case, I would opt for a PLL, you have enough of them for sender and receiver
13:14
Bertl
so generating _all_ required clocks should be easy
13:14
Francky
after reading the BUFR documentation, it is large better than a process to divide a clock...
13:15
Bertl
yes, but it only has limited capabilities to divide
13:16
Francky
yep buf for my test, i need a 8 time divided clock for the word clock (for the moment i don't use coder)
13:24
Francky
should be good :D
13:25
Francky
do you have an idea for this :
13:25
Francky
[Power 33-198] PS7 POWER property is not specified on the PS7 instance. Power reported will not be accurate.
13:26
Bertl
yes, you can ignore it
13:26
Francky
seems to be into the ps7_stub instance but there is any "power" string in the ps7_stub file
13:26
Francky
ok
13:26
Bertl
it is only used to calculate power consumption
13:31
Francky
can i directly connect a signal from my design to emio_gpio_i signal of the ps7_stup and "easy" read the value of it on the linux running on the ps ?
13:31
Bertl
yes
13:32
Bertl
the gpio driver for linux works quite well
13:34
Francky
perfect
13:35
se6astian|away
changed nick to: se6astian
13:53
niemand
joined the channel
14:20
intracube
joined the channel
14:27
aombk2
joined the channel
14:31
aombk
left the channel
14:32
aombk2
changed nick to: aombk
14:40
Francky
i need to go
14:40
Francky
thank you
14:40
Francky
by
14:40
Francky
bye
14:40
Bertl
cya
14:40
Francky
left the channel
15:54
slikdigit
left the channel
16:02
niemand
left the channel
17:45
comradekingu
joined the channel
18:02
niemand
joined the channel
18:06
Bertl
off for a nap ... bbl
18:06
Bertl
changed nick to: Bertl_zZ
18:21
aombk2
joined the channel
18:24
aombk
left the channel
19:01
niemand
left the channel
19:05
g3gg0
joined the channel
20:05
niemand
joined the channel
20:07
slikdigit
joined the channel
20:07
slikdigit
left the channel
20:07
slikdigit
joined the channel
20:12
intracube
left the channel
20:12
intracube
joined the channel
20:46
intracube
changed nick to: intracube_afk
20:51
Bertl_zZ
changed nick to: Bertl
20:51
Bertl
back now ...
20:52
niemand
left the channel
22:51
intracube_afk
changed nick to: intracube
23:13
aombk2
changed nick to: aombk