#apertus IRC Channel Logs

I try to compile vhdl for ZedBoard Zynq Evaluation and Development Kit (xc7z020clg484-1) but it seems there is not enought port...

it is the "classic" zedboard ?

hummmm ok thanks

the place says that IO placement is infeasible. Number of unplaced terminals (1) is greater than number of available sites (0).

what code are you building?

do you use the build commands in top.vhd?

previously, i had create a Vivado project and try to build in it

don't do that :)

are you anti GUI ? :)

you can still invoke the GUI once it is built if you like to

ok i have a .bit file so it is good, the problem came from GUI :(

thank you :)

you're welcome!

no idea, I haven't tried

yes i agree

if you like to, I'm perfectly fine with using my favorite editor to write/edit code :)

the gui is usefull for looking at schematics and visual maps of the FPGA layout

i saw that you will use a microzed board for beta camera

so you think the zynq 7010 is ok ?

but the 7010 works as well, just less I/Os

because i have a 7010 microzed and i hope i will use it to learn

can i ask you another question ?

i saw in top.xdc file, you create pblock and you put some instance into it, then you place the pblock into the Zynq

yes, because the placer usually sucks :)

remove the pblocks and try to build it :)

so you need to know exactly how is the zynd built to know where to place differents blocks ?!

so to put the project onto my microzed, i need 1) to change pin affectation 2) to change pblock placement

i.e. the pblocks will mostly work as is

yes, that's why I said mostly :)

i imagine that you donnot place the pblock anywhere in the fpga?!

except for some timing critical paths

the block placement*

just changing irc client

back now

wb Francky!

because you saw me that the placer sucks, but it had placed the code into the 7010

when i look on the device in the gui it seems that it had placed the code anywhere but what are the conscequences ?

not at all

is the timing checked by the builder ?

report_timing -no_header -path_type summary -max_paths 1000 -slack_lesser_than 0 -setup

those are the problematic ones, if you do not get a hit there, you're fine

if there is problem, is the bitstream generated ?

ok so i need to check the build messages

but you can also run those two commands _after_ everything finished

ok

so i was happy to get a .bit file :)

so it doesn't always make sense to stop

i saw a lot of timing violation in the report file

do you have any support (i mean a book or a datasheet) to know where are the slice and to search how you can place them ?

OH maybe i can delete the "resize" pblock to get them into the gui... i will try

Hi Bertl

It seems to me that some boards are now available like power board, sensor board and io board right?

hi fadro

but we did not receive them yet for testing

the power board was added to the stack

So this mean that the complete stackup is with 5 boards?

correct

fadro_: originally we planned to use a single board design (i.e. one board with sensor) in addition to the MicroZed

*campaign

modularity and flexibility comes with a price, and in case of the Beta, it is mostly PCB real estate

Hi Bertl, yes I clearly undertand the modularity concept your speaking about and also understand (and approve) your idea of a unified interface to the sensor. The thing i'm not clear with is why is needed a 3 boards stackup (the power pcb, the sensor processing and the beta pcb) to achieve such functionalities?

(at least the sensors we use)

(we also want to do some output, etc :)

the other solution is to add an intermediate board (in my nomenclature the "interface" board)

Yes, I agree with your points above and clearly understand (and know) the needs to low down the nber of LVDS lanes. But my remaining question still why is a 3 stack pcb is needed? From what i understand, an interface board + IO board should be sufficient.

the interface board (the one doing the LVDS reduction)

and for space reasons (we don't want to get the board too crowded) we recently added the "power board"

this allows for a few new features we didn't even plan for in the beginning

OK clear, and what are the features embedded on the beta board?

it also contains the PIC32 microcontroller

and of course the electrcal interface to the MicroZed as well as the "interface" board

I imagine that the PIC32 manages the 10DOF sensor, gather the electrical information from the power pcb and provide an interface (trough a simple comm channel like uart, ..) to the fpga ?

so the PIC32 can actually power down the sensor and FPGA

and yes, the PIC32 also has a good conenction to the FPGA and thus the ARM cores to exchange data, like the DOF or Power measurements

plus how long would a power up recovery when the pic32 initiaties a wake up take roughly?

the power consumption can be way below a single LED

the maximum expected current for the PIC is 90mA, while a low speed processing is about 5mA and a sleep mode would go down to µA

And I imagine that the 3 HDMI connectors you are planning for the 1st release will be attached to the beta board?

we want folks to be able to easily adapt and recreate the Beta

and we kind of artificially limit ourselves to parts which can be easily bought and assembled

which connects via the two PCIe x1 connectors to the beta board

yes, for example

do you need any help for the pic developpement (hard and soft) ?

there are many areas we can use help, including the PIC side

i would be pleased to help you and to give you some of my time

And how the µzed FPGA feed the HDMI pl*ugin board? Through the PCIe lanes?

sorry i was disconnected

Bertl i need to qui irc, i propose you to speak about the help i can give for APERTUS tomorrow

there are real time IRC logs :)

oh real time ! i didn't know ;)

i saw, i thougt it wasn't real time !

see you tomorrow

fadro_: yes, the PCIe conenctors provide up to 12 LVDS pairs and a bunch of GPIO lanes to the plug-in board

But in the case of a plugin board with 3 HDMI, you need to address 3 HDMI drivers (and around 20 active signals per driver). Is there sufficient IO to drive 3 HDMI drivers?

and only a few GPIO signals for I2C, CEC and HP/HEAC

correct

And concerning the sensor throughput are all the LVDS lines connected to the IF board? And is the bandwidth between IF board and µzed sufficient to support the maximum CMV12k throughput? (which is around 300 fps if i remember well)

And thanks to all the interfaces the LVDS lanes will cross we really need to think about SI (also because the layout is 4 layers only, so microstrip lines only)

all the sensor lanes go to the interface board

perfect!

oups, error previously:

yes, in the v2 version of the sensor

yeah, found the relevant section in the change record

(note that this channel is open as well, just not logged/advertized)

Bertl, is there an accessible place where lastest beta design sources are stored?

and the mechanical designs are on github, se6astian has the details

ok , i have already been there but it was not clear how boards stack together. Now it is...

well, we try to keep it clean and well grounded, so it is all more like coplanar waveguide for the high speed connections and well shielded connectors

(i.e. everything is below 2GHz)

but input and detailed analysis is always welcome!

when do you plan to assemble your 1st complete prototype?

That's what is exciting...challenges...

it won't have the final boards, but it should work

perfect....In all case you have done a great job. I know that spending time on open projects when you already have a full time job is complicated.... But you just do it....

see U later

thanks! cya!

I'm off for the day, see you tomorrow with hopefully new ideas and more likely, additional questions :)

BAndiT1983 created T300: Add basic plug-in architecture. http://lab.apertus.org/T300

BAndiT1983 created T301: Add layout switching. http://lab.apertus.org/T301

BAndiT1983 created T303: Implement interface for OpenCL plug-ins. http://lab.apertus.org/T303

BAndiT1983 created T305: Add support for MOX file format. http://lab.apertus.org/T305

off for a nap ... bbl

me too