#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

good morning

hi

it seems to be very hard without the gui... :(

i use the gui for this time, i will see if i can do this in another way later

just connect the ps_fclk array there to a signal and you're done

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)

also note that you need to enable the internal level shifters

the PS has a lower voltage IIRC, the level shifters adapt it to the PL fabric

ok and as i see the LVL_SHFTR_EN is set in the ps side

(or via jtag)

i still have a problem with router...

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

xdc*

did you specify/load it in the build script?

yep it is good for all signals, exept one (two in fact because it is a lvds_in)

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

https://dl.dropboxusercontent.com/u/782577/sender_to_receiver/sender_to_receiver.xdc

oh no in fact the error message is not for the lvds input signals but for the NET serial_clk_word_in

yep it is the clock signal for the receiver side

in the xdc

yup, every input clock to the PL should be defined

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 ?

the normal pin is the _p (positive) pin right ?

IBUFDS_inst (IBUFDS.O) is locked to IOB_X0Y14

maybe some pins are able to catch clock and other are not ?!

but I haven't checked the xdc in this regard

pins with MRCC or SRCC function han take and handle clock input properly

JX*_LVDS_10/11/12/13 and BANK13_LVDS_0/1 are

also note: you can still use other pins when you tell the tools (your "patch" :), but the performance will be worse

i'm affraid to see that the placer says that some nets are not routed, but this is *just* a warning

it seems that input and output port need delays

the iserdes2 has a IOBDELAY but it semms that oserdes2 doesn't

whereas it was working on simulation

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

yes, it is also way faster and at least helps you to figure basic errors in the design

where do you route it except for the pins?

the SERDES are special I/O block, like the input and output buffers

the output of oserdes are connected (by different signals) to a OBUFDS

OBUFDS should be fine

no, there can't be a BUFG on the output of the oserdes

no it seems to be clearly a vhdl code problem, besause the erros are only on some signals, whereas others don't generate error

i put the errors at the end

sorry for the delay ...

the reason for this is hidden in the rather lengthy logs

Unroutable connection Types:

Type 1 : OLOGICE3.OFB->IOB33M.O

-----Representative Net: Net[51] sender_32bits_clk_inst/gen_sender_8bits[1].DATA.sender_8bits_I/ser_out[0]

-----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

so the oserdes output cannot be connected to the obufds input

i had connected OFB output pin of OSERDES2 to OBUDS

i had to use OQ output pin of OSERDESE2

yeah, well, nothing I could have spotted from the files you linked me :)

so i have corrected a lot of drc errors, but i have 2 types that i need some help

paste?

okay

does it mean that i need to put a BUFG on both clok ?

yes, basically

e.g. if you use a BUFR for dividing down the word clock

in fact i make the division "by my self" with a process (shouldn't be the better way)

i.e. the warning stays

so generating _all_ required clocks should be easy

yes, but it only has limited capabilities to divide

should be good :D

[Power 33-198] PS7 POWER property is not specified on the PS7 instance. Power reported will not be accurate.

seems to be into the ps7_stub instance but there is any "power" string in the ps7_stub file

it is only used to calculate power consumption

yes

perfect

thank you

bye