Current Server Time: 06:10 (Central Europe)

#apertus IRC Channel Logs

2019/04/08

Timezone: UTC


01:44
apurvanandan[m]
Hi Bertl
01:45
apurvanandan[m]
I have completed my first draft
01:45
apurvanandan[m]
Can you please review it?
01:50
apurvanandan[m]
I have mailed the proposal to *email address removed*
01:52
intrac
left the channel
01:59
Bertl
apurvanandan[m]: did you submit it as draft to GSoC as well?
02:00
apurvanandan[m]
no I didn't
02:00
apurvanandan[m]
Should I ?
02:01
Bertl
probably won't hurt to have it there for others to review
02:02
Bertl
you can easily update your draft there so no problem
02:02
apurvanandan[m]
yes !!
02:02
Bertl
going to the proposals now ...
02:02
Bertl
*through
02:04
apurvanandan[m]
If we share it through gsoc , can we update or change it after that?
02:06
intrac
joined the channel
02:07
Bertl
as far as I know, the draft proposals (as well as the final proposals I think) can be always updated to a newer version
02:08
Bertl
s/be always/always be/
02:08
apurvanandan[m]
okay
02:40
apurvanandan[m]
Bertl, I submitted the draft.
02:43
Bertl
great!
02:44
Bertl
checking now ...
02:47
shivamgoyal
joined the channel
03:06
Bertl
apurvanandan[m]: everything looks quite good, here a few points you might want to consider though (in timeline and proposal):
03:07
Bertl
our focus is on getting the raw data out, but that should actually be easier than the UVC part and you do not really need to worry about the 'other end' as _florent_ will also be working on this and as far as I know already has that part covered
03:08
Bertl
you want to plan some time for the Lattice programming interface though which can only be reached via the routing fabric (other Lattice MachXO2)
03:09
Bertl
this has already been 'done' in a proof of concept manner by myself but you probably want to improve on that for several reasons (and even if not, you need to get it working for testing)
03:10
Bertl
also I wouldn't focus too much on TMDS as encoding as it is quite convoluted and probably not really necessary for the transmission
03:11
Bertl
doesn't mean that you can't use TMDS there but a 'simpler' 8b/10b encoding scheme is probably just fine and might save you a lot resources, time and headache :)
03:12
Bertl
as we can't do any retransmissions some kind of data protection or even better data correction should be provisioned (CRC, ECC)
03:17
apurvanandan[m]
Thanks, I will take care of all the points. Please guide me where can I know about Lattice programming interface.
03:18
Bertl
that is a little tricky, but I can try to explain it to you
03:18
Bertl
there are two MachXO2 on the Main Board of the AXIOM Beta
03:19
Bertl
they are called RFE and RFW (Routing Fabric East and West)
03:20
Bertl
both are backed by a PIC microcontroller which has control over the JTAG interface of said routing fabric FPGAs
03:20
Bertl
in addition there are a few GPIOs shared between PIC and MachXO2
03:22
Bertl
once T731 is resolved, the routing fabrics should be able to transport protocols (like JTAG, I2C, SPI) between Zynq (FPGA and ARM cores) and other GPIOs (like the ones used on the PCIe x1 plugin slots)
03:23
Bertl
as this task is still open (unfortunately) a different solution is required (for now)
03:24
Bertl
the work-around I came up with (for testing) is to program a special 'pass through' code into the routing fabric to allow for certain PIC GPIOs to be directly connected to the plugin JTAG port of the plugin MachXO2
03:25
Bertl
this way the PIC originally used to program the routing fabric can now also be used to program the plugin FPGA
03:25
Bertl
(and even with the same tools, which are basically python scripts)
03:27
Bertl
hope this clarifies :)
03:29
apurvanandan[m]
Yeah, I got it. How will this special pass through code be uploaded on the RFE and RFW?
03:29
Bertl
with the same python scripts used for programming the plugin FPGA
03:29
Bertl
so the entire procedure is like this:
03:30
Bertl
1) switch PIC to 'direct mode'
03:30
Bertl
2) program RF (MachXO2 on MainBoard) with pass through code
03:30
Bertl
3) switch PIC to 'indirect mode'
03:30
Bertl
4) program plugin FPGA (MachXO2 on plugin)
03:31
Bertl
2) and 4) can use the same python scripts
03:33
apurvanandan[m]
Wow, this seems a great hack.
03:34
apurvanandan[m]
Is the pass through code already written?
03:34
Bertl
yes and also tested
03:36
apurvanandan[m]
Okay, Bertl will you be available for few hours?
03:36
apurvanandan[m]
I am updating my proposal with all that info.
03:37
Bertl
I'm off to bed soon, but I will check it 'in the morning' when I get up
03:38
apurvanandan[m]
Ok , no problem
03:43
Bertl
well, soon-ish ... about 30 min or so
03:44
apurvanandan[m]
Is my timeline division reasonable?
03:47
Bertl
you can probably do the preparations even before the 'community bonding period' so I would use that time for making yourself comfortable with the test setup and the community itself
03:48
Bertl
personally I would start with Zynq - MachXO2 transfer and leave the FT60x stuff for later but the other way round is fine as well
03:49
Bertl
otherwise it looks quite reasonable to me
04:21
Bertl
off to bed now ... have a good one everyone!
04:21
Bertl
changed nick to: Bertl_zZ
04:30
intrac
changed nick to: intrac_away
04:35
shivamgoyal
left the channel
04:42
shivamgoyal
joined the channel
05:21
lexano
left the channel
05:25
lexano
joined the channel
05:36
comradekingu
left the channel
05:50
shivamgoyal
left the channel
06:03
BAndiT1983|away
changed nick to: BAndiT1983
06:17
rohan_
joined the channel
06:20
rohan_
hey BAndiT1983. I have understood 3 of the 4 goals for T1121 but am still confused about the goal to move functionality of shell scripts. could you please tell what is expected for it? on moving the scripts, what kind of changes would I need to make?
06:21
BAndiT1983
hi rohan_, first thing would be to implement missing features from base scripts, like access to registers and mapped memory
06:22
BAndiT1983
afterwards replicate shell scripts in daemon, e.g. setting color matrix
06:22
BAndiT1983
this includes evaluating how to send data in proper way to daemon
06:25
rohan_
ok BAndiT1983. but where can I find data about the registers?
06:26
rohan_
<afterwards replicate shell scripts in daemon, e.g. setting color matrix> understood
06:26
BAndiT1983
in scripts or at our wiki, e.g. https://wiki.apertus.org/index.php/CMV12000_Register_Blocks
06:26
rohan_
<this includes evaluating how to send data in proper way to daemon> understood
06:26
rohan_
great! thanks
06:26
BAndiT1983
no problem
06:30
rohan_
also BAndit1983: do all scripts need to be moved?
06:31
BAndiT1983
probably not, as some scripts will stay for a while and others will be replaced by ones which are calling daemon
06:34
rohan_
ok
06:43
rohan_
left the channel
07:04
mrohit[m]
> this includes evaluating how to send data in proper way to daemon
07:04
mrohit[m]
BAndiT1983 , which data are we talking about here? Is it the data sent by the WebRemote?
07:16
BAndiT1983
nope, to daemon
07:16
BAndiT1983
off to work
07:16
BAndiT1983
eh, i mean from CLI or webremote yes
07:16
BAndiT1983
off now
07:16
BAndiT1983
changed nick to: BAndiT1983|away
07:18
dcz
joined the channel
07:24
mrohit[m]
ok, got it
07:36
Umar
joined the channel
07:37
Umar
hi
07:37
Umar
left the channel
07:37
Umar
joined the channel
07:38
Umar
Hi, can i have some details regarding eligbility
07:38
Umar
do i have to be professional on certain tasks or just a beginner level.
07:41
Umar
i have some certain level of experience on fpga via verilog and had made stuff like ram , processor and image processing via VGA port of FPGA and some other related stuff.
07:41
Umar
Will i be eligible to apply for this ...
07:46
Umar
i got it from idea list :)
07:52
se6astian|away
changed nick to: se6astian
08:09
se6astian
Umar: are you currently enlisted with a university?
08:19
Umar
yes
08:19
Umar
i am a 7th semester student
08:20
se6astian
are you at least 18 years old?
08:20
Umar
but from the project ideas and stuff i think i am not eligble for anykind of stuff there.. My skills levels seems to be too low.
08:20
Umar
i am 22 years old now
08:21
Umar
7th semester student of BS CS
08:21
se6astian
are you residing in a country that is not currently embargoed by the United States?
08:21
Umar
yup
08:21
Umar
i am from Pakistan
08:21
se6astian
are you eligible to work in the country you will reside in during the program?
08:22
Umar
yup i am
08:22
se6astian
have you been accepted as a Student in GSoC more than once already?
08:22
Umar
nope i never tried properly
08:22
Umar
because of confusions
08:22
se6astian
well then you are elegible to apply within GSoC
08:23
Umar
i am eligble to apply but my skill levels are of beginner level so
08:23
Umar
i got no hope ..
08:23
Umar
Thank you anyways for responding :)
08:23
se6astian
well GSoC is indeed an elite program and not for beginners :)
08:24
Umar
-_-
08:24
Umar
took me a while to understand that and am going to miss my last chance..
08:24
se6astian
but you mentioned you worked with FPGAs before
08:24
Umar
yes
08:24
se6astian
that doesnt sound like a beginner task
08:24
Umar
i did worked with fpgs before
08:24
Umar
fpga*
08:25
Umar
stuff like making a processor , processing an image from VGA port of fpga
08:25
Umar
and other small stuff
08:26
Umar
i was pretty much fancy to fpga stuff but since there wasnt any proper support or guideline i held back
08:26
Umar
now i saw that it isn't something that's forgotten or stuff like that .. I am a bit too late to
08:26
Umar
do anything about it ..
08:27
se6astian
well hard to judge but considering the deadline is tomorrow you are indeed very late :)
08:27
Umar
....
08:34
Umar
left the channel
08:37
sebix
joined the channel
09:39
nira
joined the channel
09:54
nira
hi, I have some questions about the goals of the AXIOM Remote task. I want to clarify what exactly I would have to do with the event handling implementation, because I’ve seen that the rotary knob or the button interactions already work and I would like to know what else are you planning to do
10:05
se6astian
hi nira
10:06
se6astian
there is no actual event handling implemented yet
10:06
se6astian
we simply poll the knob position and react accordingly
10:10
mrohit[m]
Hi se6astian ,It was once mentioned in the logs about implementation of sysfs being one of the tasks to be done to read temperature or voltage. But why do we need it when we can read the temperature from the CMV register 127. although it was BAndit1983 who mentioned it, but maybe you know the answer to this too
10:13
aSobhy
left the channel
10:13
nira
ok, thanks! And about the page setup could you explain me a little bit what do you have in mind?
10:15
se6astian
mrohit[m]: I noticed you mention "temperature and voltage" a lot in your proposal
10:15
se6astian
"Parameters which are dependent on temperature and voltage of the sensor"
10:15
se6astian
where is that coming from
10:15
se6astian
there are several temperature sensors in the AXIOM Beta hardware
10:15
se6astian
not just in the image sensor
10:16
se6astian
so reading those is a task for the daemon
10:16
se6astian
same with voltages provided by the power board
10:19
se6astian
nira: pages like page_wb.c or page_wb_help.c currently all reinvent the wheel by doing everything from scratch (init_*, draw_*, etc.)
10:20
se6astian
the goal of a new page setup would be to think how we can create a system that takes care of the basics already
10:20
se6astian
making it easier to create/maintain additional pages
10:20
mrohit[m]
yes, I misunderstood it a little . I was thinking only about the temperature of the sensor. I wasn't considering the other sensors on the hardware, now I see where the sysfs requirement is spawning from
10:21
se6astian
in the end the axiom remote will contain a lot of pages, so we should make it easier to handle many of them
10:22
se6astian
without requiring to write the same drawing function again and again since pages probably have a lot of comon structure/content
10:23
se6astian
mrohit[m]: did you take a look at the image sensor datasheet already?
10:23
mrohit[m]
yes, I did
10:24
mrohit[m]
that's where I found that CMV Register 127 will provide temperature of the image sensor
10:24
se6astian
good, make sure your proposal also contains actions to deal with all the other image sensor related registers
10:25
se6astian
subsampling, gain, offsets, PLR, etc.
10:27
mrohit[m]
these registers are also dealt within the scripts right?
10:28
se6astian
some
10:29
se6astian
nira: OOP for C would be an option to deal with the pages as classes and inheritance of base functions for example
10:29
se6astian
that would require some tests
10:29
mrohit[m]
okay, I will add plan to deal with those registers within a few hours
10:29
se6astian
off now to drive to the axiom office
10:29
se6astian
changed nick to: se6astian|away
10:31
mrohit[m]
let me know if you have any more comments or suggestions regarding my proposal
10:33
aSobhy
joined the channel
10:59
nira
left the channel
11:10
dcz
left the channel
11:11
futarisIRCcloud
left the channel
11:39
Ummi
joined the channel
11:40
Ummi
Hii how can i join apertus
11:41
Ummi
left the channel
11:44
se6astian|away
changed nick to: se6astian
12:22
shivamgoyal
joined the channel
12:33
Fares
joined the channel
12:35
supragya_
joined the channel
12:36
shivamgoyal
left the channel
12:58
supragya_
left the channel
13:33
se6astian
changed nick to: se6astian|away
13:35
se6astian|away
changed nick to: se6astian
13:39
dcz
joined the channel
13:43
Fares
left the channel
13:44
Fares
joined the channel
14:01
parimal
joined the channel
14:02
parimal
Hey, did anyone get time to go through my proposal?
14:09
se6astian
I did yes
14:10
se6astian
I didnt see anything that would justify a comment/change suggestion, but then I am not mentoring this task :)
14:19
Bertl_zZ
changed nick to: Bertl
14:19
Bertl
morning folks!
14:21
se6astian
good day
14:26
Fares
morning
14:28
parimal
Morning Bertl
14:28
parimal
thanks se6astian, I will wait for BAndiT1983 to review it :)
14:29
Fares
I have few questions about the beta pipeline which will help me in the proposal of implementing LJ92 core
14:30
Bertl
let's hear then
14:32
Fares
At first, I know that the pixels pattern stored in the memory are RGGB in a sequential manner, it would be better to compress the them in the same pattern rather than converting them first to [RG RG RG ...][GB GB GB ...] correct?
14:33
Bertl
really depends on how the data is fetched and what data is required for compression
14:34
Bertl
i.e. DDR memory access is quite expensive when you want to get a reasonable framerate
14:34
Bertl
random memory access is probably way too slow
14:36
Fares
so it is better to read the current pattern [RGGB RGGB ...] sequentially from the memory and design the LJ92 core accordingly?
14:37
Fares
the data to be compressed are the frames
14:37
intrac_away
changed nick to: intrac
14:38
saurabh_raj
joined the channel
14:45
saurabh_raj
Hi, can one of the mentors please review my proposal? Where do I send it?
14:45
se6astian
hi saurabh_raj
14:45
se6astian
we are happy to
14:46
saurabh_raj
should I send google docs link to you email?
14:46
se6astian
either you send it to the specific mentor as listed in the mentor contact list in the task
14:46
se6astian
or through the gsoc draft proposal
14:46
se6astian
or to the team address under www.apertus.org/contact
14:46
se6astian
yes google doc link
14:47
Bertl
Fares: you should do burst reads but you can do them at different places if that makes sense for the encoder
14:48
Bertl
saurabh_raj: because it is very close now, you are probably best off submitting it as draft proposal to GSoC
14:48
Bertl
this way mentors can check the draft without going through their mail and/or keeping track
14:52
saurabh_raj
Hey se6astian I have sent the link to google docs on the team email id. It would be great if you could go though them.
14:52
shivamgoyal
joined the channel
15:00
Fares
ok. the encoder actually support both. as far as the encoder is concern, the inputs are sequential pixels and the output is encoded pixels, so no need for reading from different places, the pattern problem is related to the format/container ie DNG or MLV.
15:01
Fares
the pipeline for usb3 is not yet implemented correct?
15:01
Bertl
correct, that is another task this year
15:02
se6astian
saurabh_raj: had a look at your proposal, it contains very little technical details about what you want to do
15:02
saurabh_raj
which one open cine or image calibration?
15:04
se6astian
the frame server
15:04
aSobhy
hello Bertl
15:04
saurabh_raj
oh.. should I add more technical details?
15:05
aSobhy
can you check my draft proposal :)
15:07
Bertl
let's see ...
15:08
aSobhy
I have Sent a new mail
15:08
Bertl
don't see it on the GSoC page
15:09
aSobhy
no its still a draft
15:09
aSobhy
I'll submit it after your check :)
15:10
Fares
cool, so if an encoder is placed between the memory readers and the usb3 module, taking the sequence from memory and provide encoded data to usb3, how many pixels should be encoded per cycle? the problem is that the encoding is a sequential operation, which mean we can't put two cores to handle the same frame and combine the results, either the parallelism to be implemented in the core itself, or splitting the frame into subframes can
15:10
Bertl
aSobhy: submit it as draft to GSoC, that's easier to check
15:11
aSobhy
Ok 1 min :)
15:11
se6astian
saurabh_raj: oh.. should I add more technical details? <- would probably be a good idea
15:12
Fares
which would be more complex, so I think the question is what is the maximum fps to be supported? at 100Mhz for example if only one pixel is encoded per cycle it would be maximum of 100 million pixels/second which is around 11fps.
15:12
Bertl
Fares: that depends on the cycle time no? best assume 4096x3072 sensel with 12bit at 30FPS
15:14
se6astian
Fares: from a filmmakers perspective full resolution at 24/25/30 FPS would be the minimum requirement for it to be useful
15:14
se6astian
the more the better of course :)
15:15
Fares
So 377487360 pixels/second. then 4 input pixels per cycle, great.
15:15
aSobhy
Done :)
15:16
Fares
more input pixels per cycle = more fabric consumptions. for usb 3.0 I think 4 pixels/cycle on 100Mhz clk will be sufficient for 4096x3072 at 30fps.
15:21
Fares
sure se6astian, I just wanted to know if faster I/O ports are planned so I take it into consideration by increasing input-pixels/cycle. but for usb3, 4pixels/cycle is sufficient to utilize its bandwidth.
15:22
se6astian
faster IO ports are not planned for the immediate future
15:23
vup2
also about 4096×3072@23fps and 12bit is about the maximum you can (theoretically) get over the usb3 module
15:23
vup2
(assuming no compression of course)
15:24
shivamgoyal1
joined the channel
15:24
Bertl
but we can have two USB 3.x plugin modules on the Beta
15:24
Bertl
so 60FPS might be doable as well
15:24
vup2
yes of course
15:25
shivamgoyal
left the channel
15:25
shivamgoyal1
changed nick to: shivamgoyal
15:25
apurvanandan[m]
Bertl, did my proposal lacked details and research ?
15:25
Bertl
did I say that?
15:26
apurvanandan[m]
No, the current chats are making me realize how much more can be done in the proposal. :(
15:27
Bertl
apurvanandan[m]: btw, aSobhy has just submitted a proposal for the bidirectional protocol, so you might want to chat about JTAG as one use case for programming the plugin module :)
15:29
apurvanandan[m]
Ok , we will in private message :)
15:29
aSobhy
yeah I saw the chat of yesterday :)
15:30
Bertl
feel free to do it here on the channel, that's what it is for
15:30
Bertl
also this way other community members can chime in and (sometimes) provide useful input
15:31
Fares
great, Bertl: about "integration with the existing AXIOM Beta framework", the core would be placed between memory reader and usb3.0 so I wan't planning in doing integration since the pipeline is not implemented yet, is there any note here?
15:31
vup2
if you two have nothing against it i think doing the discussion in the main channel would good as it gives others a way to follow the discussion and possibly contribute to it
15:31
apurvanandan[m]
Ok, I will surely when I see him here.
15:31
vup2
ah well Bertl beat me to it
15:32
vup2
Fares: you probably want some way to test it on the actual hardware, which could be difficult if the usb3 stuff is not in place yet
15:32
vup2
so for example some way to alternatively stream it to memory could be helpful
15:33
vup2
also possibly for the input, so that one can exactly control which image is fed to the core and then inspect the output
15:33
se6astian
aSobhy: I looked at your proposal, please consider adding technical details about how you plan to solve the task
15:35
Fares
yes I was planning on doing that in the period before 9th April to evaluate it eventually on actual FPGA.
15:35
Bertl
aSobhy: but it general it looks okay ... also consider reserving some time for bandwidth and error rate testing on the Zynq - MachXO2 connection
15:35
vup2
(integrating it with the whole gateware also puts a lot more constraints on the physical implementation of your core by the pnr tool, so it could be important for guiding optimization if you are not able to meet timing requirements)
15:35
Bertl
Fares: makes sense to me and as the USB solution would just connect to the memory reader itself that would be a good place
15:36
Bertl
Fares: when the core can work on the 'normal' sequential memory stream that would be preferable because in this case we can also have the HDMI output on the second plugin
15:37
Bertl
(fetching memory twice is probably not an option)
15:37
se6astian
aSobhy: for example in week 2 of your schedule it says "Implement the bidirectional packet protocol between the ZYNQ and MachXO2."
15:37
se6astian
isnt that the task for the entire project?
15:39
se6astian
I am just looking at the proposal from another student and his technical implementation proposal is 12 pages long
15:39
se6astian
I am not saying that it has to be that long or that longer than necessary is better
15:39
aSobhy
OK, I'll Give it more time :)
15:41
Bertl
the CV is a little short as well ... i.e. could use some more personal information (but it is sufficient)
15:41
se6astian
but no technical details and a 1 page schedule will definitely impress mentors less than 12 pages of technical details (the schedule is another 3.5 pages btw in this case)
15:43
Bertl
it is definitely beneficial when the mentors can see that you have spent some time and thought on the problem and already have an idea and plan how to tackle it
15:47
Fares
I was planning to feed it with a single sequential stream from memory for simplicity and efficiency reasons, so this point is fine with me
15:48
aSobhy
for the CV I eliminate all unnecessarily data and I'll add personal information sure :)
15:53
aSobhy
and shifting week 2 to week 3 would it would be better? and expand week 1
15:53
anuejn
Fares: do you mind sharing your proposal?
15:54
anuejn
i am interested :)
15:58
anuejn
ah nvm, got the mail xD
16:00
aSobhy
would it be better**
16:01
Fares
ok :) I tried to keep it as simple as possible so if you have any questions, please ask.
16:01
shivamgoyal
left the channel
16:07
vup2
Fares: btw do you now about nmigen
16:08
vup2
it might make sense to use nmigen instead of migen
16:10
se6astian
off for now
16:11
se6astian
changed nick to: se6astian|away
16:17
parimal
left the channel
16:22
Fares
I heard about nmigen when I was looking into Yosys. if nmigen is better or more organized than migen I will use it, I just didn't use it before.
16:23
Bertl
https://github.com/m-labs/nmigen/blob/master/doc/PROPOSAL.md
16:30
vup2
while nmigen certainly is not "production ready" it is quite useable from my experience
16:31
vup2
and while it provides a compatability layer for backwards compatability with migen the new "syntax" and other things provide substantial improvement over migen
16:37
sebix
left the channel
16:44
apurvanandan[m]
Hi aSobhy
16:44
Fares
I have read the document and several examples and it seem a better version of migen, I will prepare myself for using it for the core.
16:44
apurvanandan[m]
Could you brief me out how will you implement JTAG protocol
16:45
apurvanandan[m]
Why things I need to see so that our projects can be integrated easily :)
16:46
vup2
Fares: sounds good
16:48
BAndiT1983
joined the channel
16:48
BAndiT1983
Bertl: please check BNC, cannot conenct from my normal IRC client
16:49
BAndiT1983
it happened 2 days ago also
16:51
BAndiT1983
left the channel
16:52
vup2
if you ever want to switch your irc bouncer: quassel is running rock solid for me
16:57
vup2
(and has a nice mobile client)
17:04
saurabh_raj
left the channel
17:48
felix_
Bertl: on the two usb 3 plugings for more bandwidth: do the root ports of an xhci controller share bandwith or does each root port provide full 5gbit/s? sure, one ft60x doesn't use the full 5gbit/s, but more than the half
17:59
niemand
joined the channel
18:02
Bertl
BAndiT1983|away: will do
18:03
Bertl
felix_: really depends on the controller I'd say
18:06
Dev_
joined the channel
18:20
Dev_
Hello BAndiT1983|away , I have changed the challenge code and proposal as u suggested.
18:22
Dev_
Please also check timeline and "Breif tentaive work " section. It would be great if i get some technical feedback from you
18:23
Dev_
left the channel
18:23
apurvanandan[m]
Bertl, what improvements on Lattice programming interface are required ?
18:23
aSobhy
left the channel
18:24
Dev_
joined the channel
18:24
apurvanandan[m]
Should I keep it in stretch goals?
18:26
Bertl
nah, once you reach the 'bonus material' phase we might already have the Zynq - MachXO2 bridge working
18:26
Bertl
the improvements are probably just cosmetic ... i.e. to make it more useable for testing
18:26
apurvanandan[m]
:D
18:27
Bertl
we'll sort that out once you have (remote) access to the hardware
18:27
apurvanandan[m]
Ok :)
18:38
apurvanandan[m]
Bertl, what type of link training can we use
18:38
Bertl
between Zynq and MachXO2?
18:38
apurvanandan[m]
yes yes
18:39
Bertl
well, you control both ends, so basically anything you can come up with :)
18:39
Dev_
left the channel
18:40
apurvanandan[m]
Can the one used in task be used, like 0xBAF for training, as in 10b not all symbols are used ^^'
18:41
Bertl
probably but I guess that is a rather bad example
18:56
BAndiT1983_webcl
joined the channel
19:03
Dev_
joined the channel
19:05
Dev_
hey BAndiT1983_webcl , I did the changes which u have suggested for proposal and challenge (about variable names etc) , Can u please check my timeline and "breif tentative working " sections of proposal
19:06
Dev_
It would be great i could get some technical feedback before submiting the final proposal
19:08
BAndiT1983_webcl
hi Dev_, will try later when i have time
19:08
BAndiT1983_webcl
afk a bit
19:10
Dev__
joined the channel
19:11
Dev__
okay
19:13
Dev__
left the channel
19:13
rohan_
joined the channel
19:17
Dev_
left the channel
19:19
rohan_
hey BAndiT1983_webcl. wanted to ask something related to implementing handshake package
19:20
thiblahute
left the channel
19:20
thiblahute
joined the channel
19:24
rohan_
left the channel
19:44
rohan_
joined the channel
19:45
rohan_
BAndiT1983_webcl : can you spare 5 minutes right now. I just sent you a mail. wanted to clarify some things.
20:06
Fares
left the channel
20:09
BAndiT1983_webcl
back again
20:10
se6astian|away
left the channel
20:10
BAndiT1983|away
left the channel
20:10
philippej
left the channel
20:10
RexOrCine|away
left the channel
20:10
se6astian|away
joined the channel
20:10
se6astian|away
changed nick to: se6astian
20:10
BAndiT1983|away
joined the channel
20:10
BAndiT1983|away
changed nick to: BAndiT1983
20:10
RexOrCine|away
joined the channel
20:10
philippej|away
joined the channel
20:10
philippej|away
changed nick to: philippej
20:10
BAndiT1983_webcl
left the channel
20:13
rohan_
hey BAndiT1983: please check your mail if free. thanks
20:15
BAndiT1983
hi rohan_
20:15
BAndiT1983
i think there is a misunderstanding about the comm way
20:15
BAndiT1983
it's daemon <-> WSServer <-> WebRemote
20:15
BAndiT1983
WS stands for web socket
20:16
BAndiT1983
devserver is something that Francis has implemented and uses for quick tests without daemon, although it's not hard to start daemon, if build with ENABLE_MOCK=1 to prevent memory access on normal PC
20:17
BAndiT1983
i don't know the structure of web remote that well, as it was written from scratch again
20:18
BAndiT1983
currently the descriptions are retrieved from daemon through certain command: e.g. DaemonCLI general get available_methods
20:18
BAndiT1983
if i'm not mistaken
20:18
BAndiT1983
this should give back a list, which is based on description.json from daemon, but current values are filled in before sending it to the requester
20:19
BAndiT1983
CLI does not need handshake, as its solely purpose is, to provide web UI with available parameters and their ranges
20:23
rohan_
so for handshake, is the task to pass descriptions retrieved from daemon to the WebRemote through the WSServer?
20:24
BAndiT1983
it's already passing there
20:24
BAndiT1983
but adjustments in web remote need to be done, if not already there
20:25
BAndiT1983
WSServer works in almost same way as DaemonCLI
20:26
rohan_
okay okay, but for the new parameters, we would have to save them in description.json so that Daemon can read them also right?
20:28
rohan_
*new parameters that we will add in the task
20:28
BAndiT1983
daemon doesn't care for description.json much, as it's providing certain functionality, using the file primarily for web UI
20:28
BAndiT1983
daemon can provide more stuff that in the file, but maybe we don't want to expose everything
20:29
BAndiT1983
at least to the web UI
20:30
rohan_
so is handshake only about adjustments in web remote, if not already present?
20:30
rohan_
or is there more to it?
20:32
BAndiT1983
only web UI at the moment, if you find other usage areas, then you can propose how to apply it
20:32
parimal
joined the channel
20:33
parimal
Hey BAndiT1983, I sent my proposal yesterday, did you get time to have a look? You didn't confirm if you got the mail.
20:34
BAndiT1983
hi parimal, no, as i had not much time, trying to look through proposals and comment on them one by one
20:34
rohan_
which repository contains the web UI?
20:35
BAndiT1983
we don't have that many active repos, try to guess ;)
20:37
Y_G
joined the channel
20:39
Y_G
Hi BAndiT1983, I sent you a mail regarding the c++ task , please check whenever you have time
20:40
BAndiT1983
hi Y_G, will check when i have time
20:40
BAndiT1983
do you want a reply by mail or here?
20:41
BAndiT1983
ah, now i remember too k a glimpse while being at work, not bad, but you should work on formatting
20:42
aSobhy
joined the channel
20:42
BAndiT1983
also try to give methods proper names, e.g. DebayerUtil is not really telling much and could be considered as helper class, something like Process() or Execute() would be better
20:42
parimal
left the channel
20:43
BAndiT1983
and please move functionality out of constructor, maybe also the argument for image, as it's not a good practice
20:43
BAndiT1983
will check more tomorrow, if i have time, but my work occupies a lot currently
20:44
BAndiT1983
generally, calling method ...Util() is totally misleading when trying to understand code
20:47
rohan_
BAndiT1983 <we don't have that many active repos, try to guess ;)> is the the Adapter in control-daemon
20:47
Y_G
Sure , I'll work on the mentioned points ,Thanks for your time
20:47
parimal
joined the channel
20:48
BAndiT1983
Y_G: no problem
20:48
BAndiT1983
rohan_: which repos were updated lately?
20:49
BAndiT1983
such tasks are up to the student to show his/her ability to figure things out
20:49
BAndiT1983
and this thing is the easiest
20:49
Y_G
left the channel
20:50
parimal
left the channel
20:56
rohan_
sorry BAndiT1983. I think daemon.cpp is carrying this out as it is the one reading description.json and also printing the values
20:56
rohan_
am I right?
20:57
BAndiT1983
rohan_: what are we talking about at the moment? repo? daemon? meaning of life?
21:00
rohan_
both firmware and control-daemon repos were updated recently
21:01
rohan_
WebUI is part of Daemon
21:01
rohan_
*control daemon
21:01
rohan_
so should be in control-daemon repo
21:02
mrohit[m]
hey rohan_ , maybe this is what you are looking for :
21:02
mrohit[m]
https://github.com/apertus-open-source-cinema/web-remote
21:02
BAndiT1983
this is control daemon repo? really? then someone has changed it recently
21:02
shivamgoyal
joined the channel
21:04
rohan_
<this is control daemon repo? really? then someone has changed it recently>?
21:06
BAndiT1983
was a joke, as i was expecting the quicker answer from you
21:06
se6astian
changed nick to: se6astian|away
21:12
rohan_
BAndiT1983 :
21:13
rohan_
<rohan_> so is handshake only about adjustments in web remote, if not already present? [01:00] <rohan_> or is there more to it? [01:02] <BAndiT1983> only web UI at the moment, if you find other usage areas, then you can propose how to apply it
21:13
BAndiT1983
yes?
21:13
rohan_
it was exactly what I meant to say here when I said web remote
21:14
rohan_
that the changes need to be made to web UI
21:14
BAndiT1983
there was a push recently, so the first step would be to evaluate current state of it
21:15
BAndiT1983
extending it is not that difficult and also the daemon can be accessed through browser plugins for websocket communication, just suppply proper JSON packet
21:15
rohan_
but I couldn't understand what you meant by your message after that. I thought you tried to mean I that I was saying something wrong
21:16
BAndiT1983
i have just pointed to the fact, that only web UI requires it, as your email has mentioned CLI
21:19
rohan__
joined the channel
21:19
rohan__
sorry for that misunderstanding there
21:20
rohan_
left the channel
21:20
BAndiT1983
no problem
21:26
niemand
left the channel
21:31
rohan__
left the channel
21:31
BAndiT1983
off for today, good night
21:31
BAndiT1983
changed nick to: BAndiT1983|away
21:37
Dev_
joined the channel
21:40
shivamgoyal
left the channel
21:40
Dev_
left the channel
21:54
se6astian|away
changed nick to: se6astian
21:56
se6astian
changed nick to: se6astian|away
22:24
dcz
left the channel
23:34
apurvanandan[m]
Hi,
23:34
apurvanandan[m]
Bertl, I included all that you said
23:35
apurvanandan[m]
and also other additions are there
23:35
apurvanandan[m]
Please have a second review :)
23:42
comradekingu
joined the channel
23:51
aSobhy
Bertl, returning to the Challenge Task their always a restriction speed by Quartus of 250 MHZ even changing the places of the cells nearest to the I/O pins
23:52
aSobhy
their are 2 reports the FMax = 665 MHz and the Restricted Speed = 250
23:52
apurvanandan[m]
I think Bertl is off for sometime
23:53
aSobhy
and the post-implementation is restricted to 250 MHz
00:03
aSobhy
Can you guide me what should i do please ?!
00:04
apurvanandan[m]
Are you asking me?
00:04
aSobhy
Hi apurvanandan[m] :)
00:04
apurvanandan[m]
Hi :)
00:04
aSobhy
No Bertl :)
00:04
apurvanandan[m]
Ok
00:05
aSobhy
If you could help I'll be pleased :)
00:05
aSobhy
And i have seen your question to me but as you see
00:06
apurvanandan[m]
I think you should atleast reach 500MHz if the restriction is at 250MHz by using DDR (double data rate)
00:06
apurvanandan[m]
It very simple, you just need to send data at both clock edges
00:07
apurvanandan[m]
If not 600MHz then also, the more the better :)
00:07
aSobhy
I am switching between the Q.T and proposal
00:07
apurvanandan[m]
I can understand your situation very well :(
00:09
apurvanandan[m]
Or there is much simple way as far as I know, if you want to give a try it won't take much time. Take the IDDR and ODDR primitives connect them to the IOB as the pins are inout type you could use hardware loopback.
00:10
apurvanandan[m]
Just a simple serializer to ODDR to IDDR to deserializer. But its your call
00:10
aSobhy
But the problem will be the same since the path between the pins and the cells will be the same so doubling the read rate will end with reducing the freq to half
00:12
apurvanandan[m]
I didn't meant doubling clock rate, I said using DDR.
00:12
apurvanandan[m]
What is your FPGA?
00:13
apurvanandan[m]
There must be dedicated DDR on your board
00:13
apurvanandan[m]
Beyond this only Bertl can help.
00:17
aSobhy
I didn't try to use existing ddr but i tried to read on both edges before
00:17
apurvanandan[m]
Can you explain me in short after completion of your project , how will the plugin modules be programmed
00:19
apurvanandan[m]
There are plenty of dedicated blocks for things FPGA can't achieve
00:19
apurvanandan[m]
The PLL, MMCM, ISERDES, OSERDES
00:19
apurvanandan[m]
similarly, IDDR and ODDR
00:19
apurvanandan[m]
as per my knowloedge
00:21
apurvanandan[m]
It would be good if I could add how will the plugin modules programmed in my proposal :)
00:21
aSobhy
Sure, I want to finished the task to be free to think :D
00:21
apurvanandan[m]
Ok, no problem :D
00:22
apurvanandan[m]
Good luck! :D
00:22
aSobhy
but let me know what you think to get from me, in order to accelerate that process :)
00:27
apurvanandan[m]
Actually, that isn't that much issue. I just wanted to learn programming the plugin modules using the bidirectional packet protocol'
00:28
apurvanandan[m]
But you can focus on your proposal , no problem :)
00:45
Ashu
joined the channel
00:49
Bertl
sorry, lost the IRC connection ...
00:50
Bertl
(and didn't notice)
00:50
Bertl
apurvanandan[m]: will check the proposal shortly
00:50
Bertl
aSobhy: what is the part you are currently using?
00:51
Ashu
hey Bertl!!, please check mine too
00:51
aSobhy
i tried on both max10 and Cyclone
00:52
aSobhy
Cyclone IV
00:52
Bertl
well, the cyclone IV can certainly do more than 250MHz
00:53
Bertl
so you must be hitting some other limit there
00:54
aSobhy
it reports FMAX: 680 MHZ and restricted 250
00:55
Bertl
Restricted Fmax is 250 MHz with a Note that says 'limit due to minimum period restriction (max I/O toggle rate)' ?
00:55
aSobhy
yes
00:57
Bertl
which means you are hitting minimum pulse/period and hold limits or io toggle rate
00:58
Bertl
(which is a problem of your design)