Current Server Time: 18:41 (Central Europe)

#apertus IRC Channel Logs

2019/04/08

Timezone: UTC


00:44
apurvanandan[m]
Hi Bertl
00:45
apurvanandan[m]
I have completed my first draft
00:45
apurvanandan[m]
Can you please review it?
00:50
apurvanandan[m]
I have mailed the proposal to *email address removed*
00:52
intrac
left the channel
00:59
Bertl
apurvanandan[m]: did you submit it as draft to GSoC as well?
01:00
apurvanandan[m]
no I didn't
01:00
apurvanandan[m]
Should I ?
01:01
Bertl
probably won't hurt to have it there for others to review
01:02
Bertl
you can easily update your draft there so no problem
01:02
apurvanandan[m]
yes !!
01:02
Bertl
going to the proposals now ...
01:02
Bertl
*through
01:04
apurvanandan[m]
If we share it through gsoc , can we update or change it after that?
01:06
intrac
joined the channel
01: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
01:08
Bertl
s/be always/always be/
01:08
apurvanandan[m]
okay
01:40
apurvanandan[m]
Bertl, I submitted the draft.
01:43
Bertl
great!
01:44
Bertl
checking now ...
01:47
shivamgoyal
joined the channel
02:06
Bertl
apurvanandan[m]: everything looks quite good, here a few points you might want to consider though (in timeline and proposal):
02: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
02: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)
02: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)
02: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
02: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 :)
02:12
Bertl
as we can't do any retransmissions some kind of data protection or even better data correction should be provisioned (CRC, ECC)
02:17
apurvanandan[m]
Thanks, I will take care of all the points. Please guide me where can I know about Lattice programming interface.
02:18
Bertl
that is a little tricky, but I can try to explain it to you
02:18
Bertl
there are two MachXO2 on the Main Board of the AXIOM Beta
02:19
Bertl
they are called RFE and RFW (Routing Fabric East and West)
02:20
Bertl
both are backed by a PIC microcontroller which has control over the JTAG interface of said routing fabric FPGAs
02:20
Bertl
in addition there are a few GPIOs shared between PIC and MachXO2
02: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)
02:23
Bertl
as this task is still open (unfortunately) a different solution is required (for now)
02: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
02:25
Bertl
this way the PIC originally used to program the routing fabric can now also be used to program the plugin FPGA
02:25
Bertl
(and even with the same tools, which are basically python scripts)
02:27
Bertl
hope this clarifies :)
02:29
apurvanandan[m]
Yeah, I got it. How will this special pass through code be uploaded on the RFE and RFW?
02:29
Bertl
with the same python scripts used for programming the plugin FPGA
02:29
Bertl
so the entire procedure is like this:
02:30
Bertl
1) switch PIC to 'direct mode'
02:30
Bertl
2) program RF (MachXO2 on MainBoard) with pass through code
02:30
Bertl
3) switch PIC to 'indirect mode'
02:30
Bertl
4) program plugin FPGA (MachXO2 on plugin)
02:31
Bertl
2) and 4) can use the same python scripts
02:33
apurvanandan[m]
Wow, this seems a great hack.
02:34
apurvanandan[m]
Is the pass through code already written?
02:34
Bertl
yes and also tested
02:36
apurvanandan[m]
Okay, Bertl will you be available for few hours?
02:36
apurvanandan[m]
I am updating my proposal with all that info.
02:37
Bertl
I'm off to bed soon, but I will check it 'in the morning' when I get up
02:38
apurvanandan[m]
Ok , no problem
02:43
Bertl
well, soon-ish ... about 30 min or so
02:44
apurvanandan[m]
Is my timeline division reasonable?
02: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
02: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
02:49
Bertl
otherwise it looks quite reasonable to me
03:21
Bertl
off to bed now ... have a good one everyone!
03:21
Bertl
changed nick to: Bertl_zZ
03:30
intrac
changed nick to: intrac_away
03:35
shivamgoyal
left the channel
03:42
shivamgoyal
joined the channel
04:21
lexano
left the channel
04:25
lexano
joined the channel
04:36
comradekingu
left the channel
04:50
shivamgoyal
left the channel
05:03
BAndiT1983|away
changed nick to: BAndiT1983
05:17
rohan_
joined the channel
05: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?
05:21
BAndiT1983
hi rohan_, first thing would be to implement missing features from base scripts, like access to registers and mapped memory
05:22
BAndiT1983
afterwards replicate shell scripts in daemon, e.g. setting color matrix
05:22
BAndiT1983
this includes evaluating how to send data in proper way to daemon
05:25
rohan_
ok BAndiT1983. but where can I find data about the registers?
05:26
rohan_
<afterwards replicate shell scripts in daemon, e.g. setting color matrix> understood
05:26
BAndiT1983
in scripts or at our wiki, e.g. https://wiki.apertus.org/index.php/CMV12000_Register_Blocks
05:26
rohan_
<this includes evaluating how to send data in proper way to daemon> understood
05:26
rohan_
great! thanks
05:26
BAndiT1983
no problem
05:30
rohan_
also BAndit1983: do all scripts need to be moved?
05:31
BAndiT1983
probably not, as some scripts will stay for a while and others will be replaced by ones which are calling daemon
05:34
rohan_
ok
05:43
rohan_
left the channel
06:04
mrohit[m]
> this includes evaluating how to send data in proper way to daemon
06:04
mrohit[m]
BAndiT1983 , which data are we talking about here? Is it the data sent by the WebRemote?
06:16
BAndiT1983
nope, to daemon
06:16
BAndiT1983
off to work
06:16
BAndiT1983
eh, i mean from CLI or webremote yes
06:16
BAndiT1983
off now
06:16
BAndiT1983
changed nick to: BAndiT1983|away
06:18
dcz
joined the channel
06:24
mrohit[m]
ok, got it
06:36
Umar
joined the channel
06:37
Umar
hi
06:37
Umar
left the channel
06:37
Umar
joined the channel
06:38
Umar
Hi, can i have some details regarding eligbility
06:38
Umar
do i have to be professional on certain tasks or just a beginner level.
06: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.
06:41
Umar
Will i be eligible to apply for this ...
06:46
Umar
i got it from idea list :)
06:52
se6astian|away
changed nick to: se6astian
07:09
se6astian
Umar: are you currently enlisted with a university?
07:19
Umar
yes
07:19
Umar
i am a 7th semester student
07:20
se6astian
are you at least 18 years old?
07: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.
07:20
Umar
i am 22 years old now
07:21
Umar
7th semester student of BS CS
07:21
se6astian
are you residing in a country that is not currently embargoed by the United States?
07:21
Umar
yup
07:21
Umar
i am from Pakistan
07:21
se6astian
are you eligible to work in the country you will reside in during the program?
07:22
Umar
yup i am
07:22
se6astian
have you been accepted as a Student in GSoC more than once already?
07:22
Umar
nope i never tried properly
07:22
Umar
because of confusions
07:22
se6astian
well then you are elegible to apply within GSoC
07:23
Umar
i am eligble to apply but my skill levels are of beginner level so
07:23
Umar
i got no hope ..
07:23
Umar
Thank you anyways for responding :)
07:23
se6astian
well GSoC is indeed an elite program and not for beginners :)
07:24
Umar
-_-
07:24
Umar
took me a while to understand that and am going to miss my last chance..
07:24
se6astian
but you mentioned you worked with FPGAs before
07:24
Umar
yes
07:24
se6astian
that doesnt sound like a beginner task
07:24
Umar
i did worked with fpgs before
07:24
Umar
fpga*
07:25
Umar
stuff like making a processor , processing an image from VGA port of fpga
07:25
Umar
and other small stuff
07:26
Umar
i was pretty much fancy to fpga stuff but since there wasnt any proper support or guideline i held back
07:26
Umar
now i saw that it isn't something that's forgotten or stuff like that .. I am a bit too late to
07:26
Umar
do anything about it ..
07:27
se6astian
well hard to judge but considering the deadline is tomorrow you are indeed very late :)
07:27
Umar
....
07:34
Umar
left the channel
07:37
sebix
joined the channel
08:39
nira
joined the channel
08: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
09:05
se6astian
hi nira
09:06
se6astian
there is no actual event handling implemented yet
09:06
se6astian
we simply poll the knob position and react accordingly
09: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
09:13
aSobhy
left the channel
09:13
nira
ok, thanks! And about the page setup could you explain me a little bit what do you have in mind?
09:15
se6astian
mrohit[m]: I noticed you mention "temperature and voltage" a lot in your proposal
09:15
se6astian
"Parameters which are dependent on temperature and voltage of the sensor"
09:15
se6astian
where is that coming from
09:15
se6astian
there are several temperature sensors in the AXIOM Beta hardware
09:15
se6astian
not just in the image sensor
09:16
se6astian
so reading those is a task for the daemon
09:16
se6astian
same with voltages provided by the power board
09: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.)
09: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
09:20
se6astian
making it easier to create/maintain additional pages
09: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
09: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
09:22
se6astian
without requiring to write the same drawing function again and again since pages probably have a lot of comon structure/content
09:23
se6astian
mrohit[m]: did you take a look at the image sensor datasheet already?
09:23
mrohit[m]
yes, I did
09:24
mrohit[m]
that's where I found that CMV Register 127 will provide temperature of the image sensor
09:24
se6astian
good, make sure your proposal also contains actions to deal with all the other image sensor related registers
09:25
se6astian
subsampling, gain, offsets, PLR, etc.
09:27
mrohit[m]
these registers are also dealt within the scripts right?
09:28
se6astian
some
09:29
se6astian
nira: OOP for C would be an option to deal with the pages as classes and inheritance of base functions for example
09:29
se6astian
that would require some tests
09:29
mrohit[m]
okay, I will add plan to deal with those registers within a few hours
09:29
se6astian
off now to drive to the axiom office
09:29
se6astian
changed nick to: se6astian|away
09:31
mrohit[m]
let me know if you have any more comments or suggestions regarding my proposal
09:33
aSobhy
joined the channel
09:59
nira
left the channel
10:10
dcz
left the channel
10:11
futarisIRCcloud
left the channel
10:39
Ummi
joined the channel
10:40
Ummi
Hii how can i join apertus
10:41
Ummi
left the channel
10:44
se6astian|away
changed nick to: se6astian
11:22
shivamgoyal
joined the channel
11:33
Fares
joined the channel
11:35
supragya_
joined the channel
11:36
shivamgoyal
left the channel
11:58
supragya_
left the channel
12:33
se6astian
changed nick to: se6astian|away
12:35
se6astian|away
changed nick to: se6astian
12:39
dcz
joined the channel
12:43
Fares
left the channel
12:44
Fares
joined the channel
13:01
parimal
joined the channel
13:02
parimal
Hey, did anyone get time to go through my proposal?
13:09
se6astian
I did yes
13:10
se6astian
I didnt see anything that would justify a comment/change suggestion, but then I am not mentoring this task :)
13:19
Bertl_zZ
changed nick to: Bertl
13:19
Bertl
morning folks!
13:21
se6astian
good day
13:26
Fares
morning
13:28
parimal
Morning Bertl
13:28
parimal
thanks se6astian, I will wait for BAndiT1983 to review it :)
13:29
Fares
I have few questions about the beta pipeline which will help me in the proposal of implementing LJ92 core
13:30
Bertl
let's hear then
13: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?
13:33
Bertl
really depends on how the data is fetched and what data is required for compression
13:34
Bertl
i.e. DDR memory access is quite expensive when you want to get a reasonable framerate
13:34
Bertl
random memory access is probably way too slow
13:36
Fares
so it is better to read the current pattern [RGGB RGGB ...] sequentially from the memory and design the LJ92 core accordingly?
13:37
Fares
the data to be compressed are the frames
13:37
intrac_away
changed nick to: intrac
13:38
saurabh_raj
joined the channel
13:45
saurabh_raj
Hi, can one of the mentors please review my proposal? Where do I send it?
13:45
se6astian
hi saurabh_raj
13:45
se6astian
we are happy to
13:46
saurabh_raj
should I send google docs link to you email?
13:46
se6astian
either you send it to the specific mentor as listed in the mentor contact list in the task
13:46
se6astian
or through the gsoc draft proposal
13:46
se6astian
or to the team address under www.apertus.org/contact
13:46
se6astian
yes google doc link
13:47
Bertl
Fares: you should do burst reads but you can do them at different places if that makes sense for the encoder
13:48
Bertl
saurabh_raj: because it is very close now, you are probably best off submitting it as draft proposal to GSoC
13:48
Bertl
this way mentors can check the draft without going through their mail and/or keeping track
13: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.
13:52
shivamgoyal
joined the channel
14: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.
14:01
Fares
the pipeline for usb3 is not yet implemented correct?
14:01
Bertl
correct, that is another task this year
14:02
se6astian
saurabh_raj: had a look at your proposal, it contains very little technical details about what you want to do
14:02
saurabh_raj
which one open cine or image calibration?
14:04
se6astian
the frame server
14:04
aSobhy
hello Bertl
14:04
saurabh_raj
oh.. should I add more technical details?
14:05
aSobhy
can you check my draft proposal :)
14:07
Bertl
let's see ...
14:08
aSobhy
I have Sent a new mail
14:08
Bertl
don't see it on the GSoC page
14:09
aSobhy
no its still a draft
14:09
aSobhy
I'll submit it after your check :)
14: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
14:10
Bertl
aSobhy: submit it as draft to GSoC, that's easier to check
14:11
aSobhy
Ok 1 min :)
14:11
se6astian
saurabh_raj: oh.. should I add more technical details? <- would probably be a good idea
14: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.
14:12
Bertl
Fares: that depends on the cycle time no? best assume 4096x3072 sensel with 12bit at 30FPS
14:14
se6astian
Fares: from a filmmakers perspective full resolution at 24/25/30 FPS would be the minimum requirement for it to be useful
14:14
se6astian
the more the better of course :)
14:15
Fares
So 377487360 pixels/second. then 4 input pixels per cycle, great.
14:15
aSobhy
Done :)
14: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.
14: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.
14:22
se6astian
faster IO ports are not planned for the immediate future
14:23
vup2
also about 4096×3072@23fps and 12bit is about the maximum you can (theoretically) get over the usb3 module
14:23
vup2
(assuming no compression of course)
14:24
shivamgoyal1
joined the channel
14:24
Bertl
but we can have two USB 3.x plugin modules on the Beta
14:24
Bertl
so 60FPS might be doable as well
14:24
vup2
yes of course
14:25
shivamgoyal
left the channel
14:25
shivamgoyal1
changed nick to: shivamgoyal
14:25
apurvanandan[m]
Bertl, did my proposal lacked details and research ?
14:25
Bertl
did I say that?
14:26
apurvanandan[m]
No, the current chats are making me realize how much more can be done in the proposal. :(
14: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 :)
14:29
apurvanandan[m]
Ok , we will in private message :)
14:29
aSobhy
yeah I saw the chat of yesterday :)
14:30
Bertl
feel free to do it here on the channel, that's what it is for
14:30
Bertl
also this way other community members can chime in and (sometimes) provide useful input
14: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?
14: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
14:31
apurvanandan[m]
Ok, I will surely when I see him here.
14:31
vup2
ah well Bertl beat me to it
14: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
14:32
vup2
so for example some way to alternatively stream it to memory could be helpful
14: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
14:33
se6astian
aSobhy: I looked at your proposal, please consider adding technical details about how you plan to solve the task
14:35
Fares
yes I was planning on doing that in the period before 9th April to evaluate it eventually on actual FPGA.
14: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
14: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)
14: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
14: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
14:37
Bertl
(fetching memory twice is probably not an option)
14:37
se6astian
aSobhy: for example in week 2 of your schedule it says "Implement the bidirectional packet protocol between the ZYNQ and MachXO2."
14:37
se6astian
isnt that the task for the entire project?
14:39
se6astian
I am just looking at the proposal from another student and his technical implementation proposal is 12 pages long
14:39
se6astian
I am not saying that it has to be that long or that longer than necessary is better
14:39
aSobhy
OK, I'll Give it more time :)
14:41
Bertl
the CV is a little short as well ... i.e. could use some more personal information (but it is sufficient)
14: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)
14: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
14: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
14:48
aSobhy
for the CV I eliminate all unnecessarily data and I'll add personal information sure :)
14:53
aSobhy
and shifting week 2 to week 3 would it would be better? and expand week 1
14:53
anuejn
Fares: do you mind sharing your proposal?
14:54
anuejn
i am interested :)
14:58
anuejn
ah nvm, got the mail xD
15:00
aSobhy
would it be better**
15:01
Fares
ok :) I tried to keep it as simple as possible so if you have any questions, please ask.
15:01
shivamgoyal
left the channel
15:07
vup2
Fares: btw do you now about nmigen
15:08
vup2
it might make sense to use nmigen instead of migen
15:10
se6astian
off for now
15:11
se6astian
changed nick to: se6astian|away
15:17
parimal
left the channel
15: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.
15:23
Bertl
https://github.com/m-labs/nmigen/blob/master/doc/PROPOSAL.md
15:30
vup2
while nmigen certainly is not "production ready" it is quite useable from my experience
15: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
15:37
sebix
left the channel
15:44
apurvanandan[m]
Hi aSobhy
15: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.
15:44
apurvanandan[m]
Could you brief me out how will you implement JTAG protocol
15:45
apurvanandan[m]
Why things I need to see so that our projects can be integrated easily :)
15:46
vup2
Fares: sounds good
15:48
BAndiT1983
joined the channel
15:48
BAndiT1983
Bertl: please check BNC, cannot conenct from my normal IRC client
15:49
BAndiT1983
it happened 2 days ago also
15:51
BAndiT1983
left the channel
15:52
vup2
if you ever want to switch your irc bouncer: quassel is running rock solid for me
15:57
vup2
(and has a nice mobile client)
16:04
saurabh_raj
left the channel
16: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
16:59
niemand
joined the channel
17:02
Bertl
BAndiT1983|away: will do
17:03
Bertl
felix_: really depends on the controller I'd say
17:06
Dev_
joined the channel
17:20
Dev_
Hello BAndiT1983|away , I have changed the challenge code and proposal as u suggested.
17:22
Dev_
Please also check timeline and "Breif tentaive work " section. It would be great if i get some technical feedback from you
17:23
Dev_
left the channel
17:23
apurvanandan[m]
Bertl, what improvements on Lattice programming interface are required ?
17:23
aSobhy
left the channel
17:24
Dev_
joined the channel
17:24
apurvanandan[m]
Should I keep it in stretch goals?
17:26
Bertl
nah, once you reach the 'bonus material' phase we might already have the Zynq - MachXO2 bridge working
17:26
Bertl
the improvements are probably just cosmetic ... i.e. to make it more useable for testing
17:26
apurvanandan[m]
:D
17:27
Bertl
we'll sort that out once you have (remote) access to the hardware
17:27
apurvanandan[m]
Ok :)
17:38
apurvanandan[m]
Bertl, what type of link training can we use
17:38
Bertl
between Zynq and MachXO2?
17:38
apurvanandan[m]
yes yes
17:39
Bertl
well, you control both ends, so basically anything you can come up with :)
17:39
Dev_
left the channel
17:40
apurvanandan[m]
Can the one used in task be used, like 0xBAF for training, as in 10b not all symbols are used ^^'
17:41
Bertl
probably but I guess that is a rather bad example
17:56
BAndiT1983_webcl
joined the channel
18:03
Dev_
joined the channel
18: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
18:06
Dev_
It would be great i could get some technical feedback before submiting the final proposal
18:08
BAndiT1983_webcl
hi Dev_, will try later when i have time
18:08
BAndiT1983_webcl
afk a bit
18:10
Dev__
joined the channel
18:11
Dev__
okay
18:13
Dev__
left the channel
18:13
rohan_
joined the channel
18:17
Dev_
left the channel
18:19
rohan_
hey BAndiT1983_webcl. wanted to ask something related to implementing handshake package
18:20
thiblahute
left the channel
18:20
thiblahute
joined the channel
18:24
rohan_
left the channel
18:44
rohan_
joined the channel
18:45
rohan_
BAndiT1983_webcl : can you spare 5 minutes right now. I just sent you a mail. wanted to clarify some things.
19:06
Fares
left the channel
19:09
BAndiT1983_webcl
back again
19:10
se6astian|away
left the channel
19:10
BAndiT1983|away
left the channel
19:10
philippej
left the channel
19:10
RexOrCine|away
left the channel
19:10
se6astian|away
joined the channel
19:10
se6astian|away
changed nick to: se6astian
19:10
BAndiT1983|away
joined the channel
19:10
BAndiT1983|away
changed nick to: BAndiT1983
19:10
RexOrCine|away
joined the channel
19:10
philippej|away
joined the channel
19:10
philippej|away
changed nick to: philippej
19:10
BAndiT1983_webcl
left the channel
19:13
rohan_
hey BAndiT1983: please check your mail if free. thanks
19:15
BAndiT1983
hi rohan_
19:15
BAndiT1983
i think there is a misunderstanding about the comm way
19:15
BAndiT1983
it's daemon <-> WSServer <-> WebRemote
19:15
BAndiT1983
WS stands for web socket
19: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
19:17
BAndiT1983
i don't know the structure of web remote that well, as it was written from scratch again
19:18
BAndiT1983
currently the descriptions are retrieved from daemon through certain command: e.g. DaemonCLI general get available_methods
19:18
BAndiT1983
if i'm not mistaken
19: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
19:19
BAndiT1983
CLI does not need handshake, as its solely purpose is, to provide web UI with available parameters and their ranges
19:23
rohan_
so for handshake, is the task to pass descriptions retrieved from daemon to the WebRemote through the WSServer?
19:24
BAndiT1983
it's already passing there
19:24
BAndiT1983
but adjustments in web remote need to be done, if not already there
19:25
BAndiT1983
WSServer works in almost same way as DaemonCLI
19: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?
19:28
rohan_
*new parameters that we will add in the task
19:28
BAndiT1983
daemon doesn't care for description.json much, as it's providing certain functionality, using the file primarily for web UI
19:28
BAndiT1983
daemon can provide more stuff that in the file, but maybe we don't want to expose everything
19:29
BAndiT1983
at least to the web UI
19:30
rohan_
so is handshake only about adjustments in web remote, if not already present?
19:30
rohan_
or is there more to it?
19:32
BAndiT1983
only web UI at the moment, if you find other usage areas, then you can propose how to apply it
19:32
parimal
joined the channel
19: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.
19:34
BAndiT1983
hi parimal, no, as i had not much time, trying to look through proposals and comment on them one by one
19:34
rohan_
which repository contains the web UI?
19:35
BAndiT1983
we don't have that many active repos, try to guess ;)
19:37
Y_G
joined the channel
19:39
Y_G
Hi BAndiT1983, I sent you a mail regarding the c++ task , please check whenever you have time
19:40
BAndiT1983
hi Y_G, will check when i have time
19:40
BAndiT1983
do you want a reply by mail or here?
19:41
BAndiT1983
ah, now i remember too k a glimpse while being at work, not bad, but you should work on formatting
19:42
aSobhy
joined the channel
19: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
19:42
parimal
left the channel
19:43
BAndiT1983
and please move functionality out of constructor, maybe also the argument for image, as it's not a good practice
19:43
BAndiT1983
will check more tomorrow, if i have time, but my work occupies a lot currently
19:44
BAndiT1983
generally, calling method ...Util() is totally misleading when trying to understand code
19:47
rohan_
BAndiT1983 <we don't have that many active repos, try to guess ;)> is the the Adapter in control-daemon
19:47
Y_G
Sure , I'll work on the mentioned points ,Thanks for your time
19:47
parimal
joined the channel
19:48
BAndiT1983
Y_G: no problem
19:48
BAndiT1983
rohan_: which repos were updated lately?
19:49
BAndiT1983
such tasks are up to the student to show his/her ability to figure things out
19:49
BAndiT1983
and this thing is the easiest
19:49
Y_G
left the channel
19:50
parimal
left the channel
19: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
19:56
rohan_
am I right?
19:57
BAndiT1983
rohan_: what are we talking about at the moment? repo? daemon? meaning of life?
20:00
rohan_
both firmware and control-daemon repos were updated recently
20:01
rohan_
WebUI is part of Daemon
20:01
rohan_
*control daemon
20:01
rohan_
so should be in control-daemon repo
20:02
mrohit[m]
hey rohan_ , maybe this is what you are looking for :
20:02
mrohit[m]
https://github.com/apertus-open-source-cinema/web-remote
20:02
BAndiT1983
this is control daemon repo? really? then someone has changed it recently
20:02
shivamgoyal
joined the channel
20:04
rohan_
<this is control daemon repo? really? then someone has changed it recently>?
20:06
BAndiT1983
was a joke, as i was expecting the quicker answer from you
20:06
se6astian
changed nick to: se6astian|away
20:12
rohan_
BAndiT1983 :
20: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
20:13
BAndiT1983
yes?
20:13
rohan_
it was exactly what I meant to say here when I said web remote
20:14
rohan_
that the changes need to be made to web UI
20:14
BAndiT1983
there was a push recently, so the first step would be to evaluate current state of it
20: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
20: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
20:16
BAndiT1983
i have just pointed to the fact, that only web UI requires it, as your email has mentioned CLI
20:19
rohan__
joined the channel
20:19
rohan__
sorry for that misunderstanding there
20:20
rohan_
left the channel
20:20
BAndiT1983
no problem
20:26
niemand
left the channel
20:31
rohan__
left the channel
20:31
BAndiT1983
off for today, good night
20:31
BAndiT1983
changed nick to: BAndiT1983|away
20:37
Dev_
joined the channel
20:40
shivamgoyal
left the channel
20:40
Dev_
left the channel
20:54
se6astian|away
changed nick to: se6astian
20:56
se6astian
changed nick to: se6astian|away
21:24
dcz
left the channel
22:34
apurvanandan[m]
Hi,
22:34
apurvanandan[m]
Bertl, I included all that you said
22:35
apurvanandan[m]
and also other additions are there
22:35
apurvanandan[m]
Please have a second review :)
22:42
comradekingu
joined the channel
22: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
22:52
aSobhy
their are 2 reports the FMax = 665 MHz and the Restricted Speed = 250
22:52
apurvanandan[m]
I think Bertl is off for sometime
22:53
aSobhy
and the post-implementation is restricted to 250 MHz
23:03
aSobhy
Can you guide me what should i do please ?!
23:04
apurvanandan[m]
Are you asking me?
23:04
aSobhy
Hi apurvanandan[m] :)
23:04
apurvanandan[m]
Hi :)
23:04
aSobhy
No Bertl :)
23:04
apurvanandan[m]
Ok
23:05
aSobhy
If you could help I'll be pleased :)
23:05
aSobhy
And i have seen your question to me but as you see
23:06
apurvanandan[m]
I think you should atleast reach 500MHz if the restriction is at 250MHz by using DDR (double data rate)
23:06
apurvanandan[m]
It very simple, you just need to send data at both clock edges
23:07
apurvanandan[m]
If not 600MHz then also, the more the better :)
23:07
aSobhy
I am switching between the Q.T and proposal
23:07
apurvanandan[m]
I can understand your situation very well :(
23: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.
23:10
apurvanandan[m]
Just a simple serializer to ODDR to IDDR to deserializer. But its your call
23: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
23:12
apurvanandan[m]
I didn't meant doubling clock rate, I said using DDR.
23:12
apurvanandan[m]
What is your FPGA?
23:13
apurvanandan[m]
There must be dedicated DDR on your board
23:13
apurvanandan[m]
Beyond this only Bertl can help.
23:17
aSobhy
I didn't try to use existing ddr but i tried to read on both edges before
23:17
apurvanandan[m]
Can you explain me in short after completion of your project , how will the plugin modules be programmed
23:19
apurvanandan[m]
There are plenty of dedicated blocks for things FPGA can't achieve
23:19
apurvanandan[m]
The PLL, MMCM, ISERDES, OSERDES
23:19
apurvanandan[m]
similarly, IDDR and ODDR
23:19
apurvanandan[m]
as per my knowloedge
23:21
apurvanandan[m]
It would be good if I could add how will the plugin modules programmed in my proposal :)
23:21
aSobhy
Sure, I want to finished the task to be free to think :D
23:21
apurvanandan[m]
Ok, no problem :D
23:22
apurvanandan[m]
Good luck! :D
23:22
aSobhy
but let me know what you think to get from me, in order to accelerate that process :)
23:27
apurvanandan[m]
Actually, that isn't that much issue. I just wanted to learn programming the plugin modules using the bidirectional packet protocol'
23:28
apurvanandan[m]
But you can focus on your proposal , no problem :)
23:45
Ashu
joined the channel
23:49
Bertl
sorry, lost the IRC connection ...
23:50
Bertl
(and didn't notice)
23:50
Bertl
apurvanandan[m]: will check the proposal shortly
23:50
Bertl
aSobhy: what is the part you are currently using?
23:51
Ashu
hey Bertl!!, please check mine too
23:51
aSobhy
i tried on both max10 and Cyclone
23:52
aSobhy
Cyclone IV
23:52
Bertl
well, the cyclone IV can certainly do more than 250MHz
23:53
Bertl
so you must be hitting some other limit there
23:54
aSobhy
it reports FMAX: 680 MHZ and restricted 250
23:55
Bertl
Restricted Fmax is 250 MHz with a Note that says 'limit due to minimum period restriction (max I/O toggle rate)' ?
23:55
aSobhy
yes
23:57
Bertl
which means you are hitting minimum pulse/period and hold limits or io toggle rate
23:58
Bertl
(which is a problem of your design)