Current Server Time: 14:10 (Central Europe)

#apertus IRC Channel Logs

2015/04/03

Timezone: UTC


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