Current Server Time: 15:48 (Central Europe)

#apertus IRC Channel Logs

2019/08/05

Timezone: UTC


00:04
apurvanandan[m]
Thats not the issue Bertl
00:06
Bertl_oO
well, it could be one of the FT60x errata
00:06
Bertl_oO
the first step should be to recreate the issue in a controlled way
00:07
Bertl_oO
you said you did extensive tests with a counter directly attached to the FTDI interface and there was no data loss, right?
00:08
Bertl_oO
did you also do those tests with a FIFO between counter and FTDI?
00:08
apurvanandan[m]
Yupp, I connected a counter clocked with FT601_clk with fifo_emp signal always zero
00:09
apurvanandan[m]
No it was counter clocked with FT601_clk so I didn't attach FIFO there
00:09
Bertl_oO
okay, so maybe try that then
00:10
Bertl_oO
i.e. use the internal oscillator of the MachXO2 to generate about 90MHz (something below the 100MHz of the FTDI)
00:10
apurvanandan[m]
I tried somewhat similar, I connected counter clocked with 75 MHz with write enable always 1 to the fifo and still data was lost
00:10
apurvanandan[m]
75 MHz of DDRX4
00:10
Bertl_oO
okay, try that without the DDR input clock
00:10
apurvanandan[m]
Okay I am going to try with internal oscillator
00:10
Bertl_oO
but 75MHz is fine as well
00:11
Bertl_oO
the oscillator can do 66.5 or 88.67
00:11
Bertl_oO
both are fine for this purpose
00:11
apurvanandan[m]
ok thanks
00:12
Bertl_oO
in case it turns out not to happen with this setup, we can get to 75MHz via PLL
00:15
apurvanandan[m]
okay
00:40
apurvanandan[m]
Bertl, it happens with simple counter at 66.5 MHz also
00:41
Bertl_oO
okay, let's ctry with clocking both sides of the FIFO with the 100MHz fom the FTDI
00:41
Bertl_oO
*try
00:42
apurvanandan[m]
:o good idea
01:01
apurvanandan[m]
Bertl It works perfectly fine ie no errors at 380MBps like it used to work
01:02
Bertl_oO
okay, that leaves a number of options
01:02
apurvanandan[m]
ie when clocked both sides with FT601 clocl
01:02
Bertl_oO
can you upload the counter data from the 66.5MHz test?
01:02
Bertl_oO
preferably with more than one block of missing data?
01:03
apurvanandan[m]
I can send few values before and after the miss
01:03
apurvanandan[m]
As they are rare
01:03
Bertl_oO
yeah, that should be fine
01:04
apurvanandan[m]
Okay sending 10 values
01:10
apurvanandan[m]
I probably know the issue now, lets see
01:11
illwieckz
left the channel
01:13
apurvanandan[m]
Yes Right, the fifo is get full
01:13
Bertl_oO
okay, how does that happen?
01:14
apurvanandan[m]
When I attached a condition of not full to counter, the data reception got correct
01:14
apurvanandan[m]
So the FT601 controller takes pauses long enough that fifo gets full
01:14
apurvanandan[m]
What can be the solution
01:15
apurvanandan[m]
Basically FT601 ensures that packet is received correctly at PC so it may retransmit
01:15
Bertl_oO
give me short description of that 'FT601 controller'
01:16
apurvanandan[m]
I converted the verilog code of ufrisk's pcileech from verilog to vhdl :/
01:16
Bertl_oO
without knowing what it does?
01:17
illwieckz
joined the channel
01:17
apurvanandan[m]
Basically, I removed read from PC states
01:18
apurvanandan[m]
No at that I completely understood what I wrote
01:18
apurvanandan[m]
But it has been quite some time so I am reading the code
01:18
Bertl_oO
so explain the ported code to me (or show me some well indented VHDL code :)
01:20
apurvanandan[m]
https://github.com/apurvanandan1997/usb-plug-mod/blob/master/MachXO2/ft601_controller/src/ft601.vhd
01:21
apurvanandan[m]
It goes from IDLE to intermediate states then to receive or transmit states
01:22
apurvanandan[m]
Creates small buffer of 3 32 bits words
01:22
apurvanandan[m]
req_data <= (not fifo_in_emp) and i_rd_en and ft601_txe and (not i_pre_valid(1)) when (i_tx_state = IDLE or i_tx_state = ACTIVE_TX) else '0';
01:22
apurvanandan[m]
This is the read enable of async fifo
01:23
Bertl_oO
I see, well, the retransmit is nice, but that is not a good approach for high bandwidth data transfer
01:23
apurvanandan[m]
I think I should increase fifo size?
01:23
Bertl_oO
but it seems to work for the 100MHz case, so the problem must be elsewhere
01:24
Bertl_oO
the main question now is, what is retransmitted and und what conditions
01:24
Bertl_oO
*under
01:25
Bertl_oO
btw, the code is not well formatted (as usual)
01:25
apurvanandan[m]
This is from the old times of first evaluation, please don't mind
01:25
Bertl_oO
still the code you are using right now, no?
01:26
apurvanandan[m]
Just little more formatted right now
01:26
Bertl_oO
then show me the well formatted code please :)
01:26
Bertl_oO
it makes reading HDL so much easier ...
01:27
Bertl_oO
what are the internal fifos?
01:28
apurvanandan[m]
Not much different but still :/ https://gist.github.com/apurvanandan1997/27a217c0cdc40d92343d748850d38837
01:28
apurvanandan[m]
Where internal fifos?
01:28
Bertl_oO
-- From Internal FIFOs
01:28
Bertl_oO
-- To Internal FIFOs
01:28
Bertl_oO
(line 46 and line 52)
01:29
Bertl_oO
(line 41 and 47 in the latest paste)
01:29
apurvanandan[m]
The async fifos
01:29
apurvanandan[m]
I think it maybe not be retransmit and they can be just buffers
01:29
Bertl_oO
what did you connect there?
01:30
apurvanandan[m]
My async fifos the ones we were talking about till now, and data out is unconnected
01:30
Bertl_oO
so the 'From' is connected to your fifo, yes?
01:31
Bertl_oO
and the 'To' is simply open as you do not receive anything from the PC side
01:31
apurvanandan[m]
Yup right
01:33
Bertl_oO
so the main question for me is why is there a fifo_in_emp and a data_wr_en?
01:34
apurvanandan[m]
Fifo_emp is the indicator that internal fifos are empty
01:34
Bertl_oO
means no data available in this case
01:34
Bertl_oO
but how is that different from data_wr_en = 0 ?
01:35
apurvanandan[m]
And data_wr_en just in case we want to disable data send , I connected to constant 1
01:36
Bertl_oO
I think that might be part of the problem
01:37
Bertl_oO
with 100MHz/100MHz on the FIFO sides, you never get a fifo_in_emp
01:37
Bertl_oO
so there is constant data flow without any interruption
01:38
Bertl_oO
with 66.5MHz/100MHz, fifo_in_emp will toggle every few words
01:38
apurvanandan[m]
Yupp
01:38
Bertl_oO
I presume the logic (haven't checked the code yet) makes a complex state transition when the fifo gets empty
01:38
Bertl_oO
which most likely turns off req_data
01:38
Bertl_oO
(that's something you can check)
01:39
Bertl_oO
which in turn will generate some backlog on the fifo
01:39
Bertl_oO
let's do the following:
01:39
apurvanandan[m]
req_data <= (not fifo_in_emp) and i_rd_en and ft601_txe and (not i_pre_valid(1)) when (i_tx_state = IDLE or i_tx_state = ACTIVE_TX) else '0';
01:39
apurvanandan[m]
Yupp
01:40
Bertl_oO
replace the highest bits of the counter with meta-data from the FIFO
01:40
Bertl_oO
like how full the FIFO is
01:41
apurvanandan[m]
Okk doing that
01:41
Bertl_oO
e.g. make the FIFO 256 words and replace the upper 8byte on the FIFO input with the FIFO count
01:42
Bertl_oO
if that is the case, and I'm pretty confident, we can work around that by letting the FIFO fill up to a certain value before the transfer is enabled
01:42
apurvanandan[m]
How can filling up prevent overflow?
01:43
Bertl_oO
because you do not get a huge number of FIFO empty signals
01:43
aSobhy
Bertl I'm afraid to ask the following question
01:43
Bertl_oO
which in turn cause the complex state changes
01:43
Bertl_oO
aSobhy: go ahead :)
01:45
apurvanandan[m]
Bertl I have a lecture , i wil be back later :)
01:45
Bertl_oO
okay, have fun!
01:46
aSobhy
In order to get the final counter out I checked the schematic of machXO2-1200 and found that it have EBR (Embedded Block RAM
01:46
aSobhy
so saving the final result in one of these blocks will be easily to get right
01:46
aSobhy
?
01:46
Bertl_oO
well, you can certainly store the counter into EBR
01:47
Bertl_oO
but how will you retrieve it 'easily' from there?
01:48
aSobhy
that's my question
01:49
Bertl_oO
you can't just solve a problem (getting the counter data out of the MachXO2) by moving the data to another part of the FPGA (without any plan how to get that data out)
01:50
Bertl_oO
this is like saying, hey, I have to move all the stuff from my living room to the new house ... but I don't know how ... let's move them into the kitchen maybe that helps...
01:51
aSobhy
by JTAG
01:51
Bertl_oO
okay, so what's the plan there? do you know how to transfer EBR via JTAG?
01:51
aSobhy
not yet !
01:52
Bertl_oO
but you are confident that this is simpler than moving a counter value by JTAG, yes?
01:52
aSobhy
I think yes
01:53
Bertl_oO
okay, so I'm not going to ask why, but I'm curious how you want to transfer the EBR
01:55
aSobhy
So I'm wrong :(
01:55
Bertl_oO
I didn't say that
01:55
Bertl_oO
but you still do not have a plan it seems
01:57
aSobhy
put me on the way
01:59
Bertl_oO
there is a JTAGF primitive in the MachXO2
02:00
Bertl_oO
this allows you to handle two special JTAG instruction (ER1 and ER2) inside the FPGA
02:00
Bertl_oO
which in turn allows you to access data from inside the MachXO2 via JTAG
02:03
aSobhy
ah okay I thought its hardened
02:04
Bertl_oO
well, jtag is always on unless you disable it (which is a bad idea anyway :)
02:04
Bertl_oO
so you can always use the ER1/ER2 instructions to conenct to one of the two registers
02:05
Bertl_oO
which need to be implemented in your FPGA code
02:05
Bertl_oO
(basically just requires a shift register of the length you need for your data)
02:09
Bertl_oO
sounds like a good way to transfer your data?
02:09
aSobhy
yes a good way :)
02:10
aSobhy
I was reading the library guide sorry for the delay
02:10
aSobhy
thanks Bertl :) :)
02:11
Bertl_oO
you're welcome!
04:10
apurvanandan[m]
Bertl, please tell how to prevent overflow?
04:11
Bertl_oO
does it overflow?
04:12
Bertl_oO
also why does it overlow? is it because of retransmission or because the FIFO slowly fills up?
04:12
apurvanandan[m]
Yes, as when I stopped counter on fifo_full condition , there wasn't any data loss at 66.5 MHz counter
04:12
Bertl_oO
so you know that you are losing data because the fifo is full
04:13
Bertl_oO
but we don't know yet why it gets full and if that happens slowly over time or abruptly at some point
04:14
Bertl_oO
unfortunately this very much affects how to address this issue
04:15
apurvanandan[m]
abruptly, i guess as we get 150 MB data then there loss of some values and then we again get MBs of data correctly
04:16
Bertl_oO
how can you tell?
04:17
Bertl_oO
what if the fifo lags behind a few words for every megabyte
04:17
Bertl_oO
and just after 150MB it is full and starts dropping data
04:17
apurvanandan[m]
hmm, I need to check that to be sure
04:18
Bertl_oO
are you using the FIFO_DC primitive?
04:18
apurvanandan[m]
Yupp
04:19
apurvanandan[m]
Basically it is group of FIFO_8kb
04:19
Bertl_oO
so there is no 'accessible' fill state there
04:19
Bertl_oO
but you can use the almost full and almost empty information
04:19
apurvanandan[m]
no accesible full state?
04:19
Bertl_oO
just set them to 30 and 70 percent of the total fifo size
04:20
Bertl_oO
fill state not full state :)
04:20
Bertl_oO
i.e. you do not know how much data is currently in the FIFO
04:21
Bertl_oO
but you can also do that with an external counter
04:21
Bertl_oO
you just need to modify your setup to run on the FTDI clock but with a reduced data pattern
04:22
apurvanandan[m]
Then what do I do with that :)
04:22
apurvanandan[m]
Currently, I am not using any full or almost signal and am using almost_empty only
04:22
Bertl_oO
i.e. have one out of four cycles supply data into the FIFO
04:22
apurvanandan[m]
We can't stop incoming data?
04:23
Bertl_oO
not easily
04:24
Bertl_oO
so, test setup: everything based on the 100MHz supplied by the FTDI
04:25
Bertl_oO
we know that 100MHz in and 100MHz out of the FIFO works (at least if you tested that correctly :)
04:26
Bertl_oO
we also know that less than 100% in causes problems, so let's trigger them with the 100MHz input by only sending 3 out of 4 words
04:27
Bertl_oO
i.e. put three words in the FIFO (at 100MHz FTDI clock), then skip one
04:28
Bertl_oO
add a counter at the fifo output which counts the words taken out of the FIFO
04:29
Bertl_oO
use that counter for the upper 16 bit of the FIFO data
04:30
Bertl_oO
(note: you need to feed the counter to the _input_ of the FIFO)
04:31
Bertl_oO
do some math on the received data to see if the fifo slowly gets full or suddenly stalls and fills up
04:32
Bertl_oO
you can also use the almost empty and almost full signals to do the same as your counter with a much more coarser precision
04:32
apurvanandan[m]
The setup works at 100MHz as the read enable becomes the write enable
04:33
apurvanandan[m]
So fifo becomes sort of synchronous
04:33
Bertl_oO
how's that?
04:34
apurvanandan[m]
With the counter setup
04:34
apurvanandan[m]
When the counter is again enabled when read enable is high
04:35
apurvanandan[m]
Basically I don't know a way without stopping the incoming data
04:36
Bertl_oO
I don't follow
04:36
Bertl_oO
you told me that running both sides of the FIFO with the same clock (100MHz from the FTDI) works and you do not lose any data
04:37
apurvanandan[m]
I mean , in both setups ie with 66.5 or with 100MHz I disable counter when the fifo gets full, that is why no data is lost
04:37
Bertl_oO
that isn't what you told me
04:38
Bertl_oO
so basically the throughput with the current controller is way lower than the available bandwidth
04:38
apurvanandan[m]
I am sorry for the miscommunication from my side
04:39
Bertl_oO
so back to square 1 on the FTDI side then
04:39
Bertl_oO
get rid of the controller, transmit data on every cycle of the 100MHz clock
04:40
Bertl_oO
check what you receive on the PC side and if there are any data losses
04:41
Bertl_oO
it is not an option for our purpose to 'wait' whenever there is some kind of congestion on the USB bus
04:41
Bertl_oO
we have 3.2Gbit to transfer and this has to go through
04:41
apurvanandan[m]
Okay, I got it
04:41
Bertl_oO
at USB 3 provides about 5GBit, this should be doable
04:42
Bertl_oO
(unless the folks at FTDI made some grave mistakes :)
04:43
Bertl_oO
off to bed now ...
04:43
Bertl_oO
changed nick to: Bertl_zZ
04:44
apurvanandan[m]
Ok cool, time to get to serious work :)
04:44
apurvanandan[m]
Good night!
06:48
se6ast1an
good day
07:26
illwieckz
left the channel
07:33
illwieckz
joined the channel
11:54
Spirit532
left the channel
11:54
Spirit532
joined the channel
12:15
Bertl_zZ
changed nick to: Bertl
12:15
Bertl
morning folks!
13:19
Umori
left the channel
13:24
Umori
joined the channel
14:24
Bertl
apurvanandan[m]: the remote beta (beta_e) just got an FT601 module conencted to the zbox ... please test as soon as possible :)
14:33
Nira|away
changed nick to: Nira
15:23
Y_G
joined the channel
15:43
danieel
Bertl: apurvanandan[m] - look at this: https://www.ftdichip.com/Support/Documents/AppNotes/AN_386%20FTDI%20FT600%20Maximize%20Performance.pdf
15:44
danieel
not trying to be pesimistic byt 3.2G target (400MB/s) is not figuring in the charts shown there :/
15:45
Bertl
yes, thanks, we have seen and discussed this quite some time ago
15:45
danieel
you think unidirectional transfer can go the desired speed?
15:46
Bertl
if you go through the document, the discuss the overhead of idle and header data
15:47
Bertl
if you switch to unidirectional, data only mode (no channels, etc) there should be no idle or overhead
15:47
Bertl
(again, unless the FTDI folks screwed up :)
15:47
danieel
so in that mode there are some handshake signals above the 32bit data?
15:48
danieel
lets see how it turns out :)
15:48
Bertl
yup
15:50
Fares
joined the channel
15:57
se6ast1an
meeting starting shortly
16:00
se6ast1an
meeting time!
16:00
se6ast1an
you might have noticed I use a different nick now and new IRC bouncer
16:00
se6ast1an
hopefully this will solve a lot of messages being set to me not going missing now
16:01
se6ast1an
if you sent me anything and I didnt react its probably been swallowed by the irc bouncer please send your messages again
16:01
se6ast1an
so meeting time, please pm me now as usual if you want to report!
16:03
se6ast1an
nira please kick of the meeting today with your report
16:03
se6ast1an
*off
16:03
Nira
great, thank you and hi everyone
16:03
Nira
this week I have done what was missing about the transmission from the PIC16 to the PIC32 via UART
16:04
Nira
I have also been understanding how to check the answer on minicom, solving how the pins are distributed and which ones are used for what I want to use
16:05
Nira
I am currently checking the good timing of the pulses to be detected as a bounce or not and joining the different parts of the code
16:05
Nira
this would be all about this week
16:07
se6ast1an
great, many thanks
16:07
se6ast1an
fares, your turn
16:07
Fares
Hi everyone
16:08
Fares
Last week I completed “the random” test and let it work on fpga for four days, it successfully encoded over 20k frame.
16:09
Fares
I also completed and pushed first report draft to be completed in the following weeks, and please guide me if I miss some important info while writing the report.
16:10
Fares
Lastly, I started working on integrating the core with the current beta gateware “SOC” and will continue working on it next week.
16:11
Fares
That would be all, thank you!
16:12
se6ast1an
many thanks
16:12
se6ast1an
please create an entry here:https://wiki.apertus.org/index.php/GSoC_Projects
16:12
se6ast1an
as suggested last week already
16:12
se6ast1an
but I see that nobody did it....
16:13
Fares
I tried but I didn’t find “add” or “create” button :)
16:13
Bertl
did you create an account and log in?
16:14
se6ast1an
and nobody on irc was able to help you?
16:14
se6ast1an
anyways, do it now!
16:14
se6ast1an
many thanks for the report
16:14
se6ast1an
Y_G, your tunr
16:14
se6ast1an
*turn
16:14
Fares
I have acc on the lab not the wiki
16:14
Fares
se6ast1an: I will
16:15
Y_G
Hi all,
16:15
Y_G
This week I completed working on Dummy WebUI to see if work done broke anything from WebUI perspective.
16:15
Y_G
The JSON format that would be sent from the WebUI has to be still decided and accordingly changes would be made in the MessageHandler. As of now keeping this on hold. Will update when WebUI is updated.
16:16
Y_G
Time was spent on reading about unit testing using catch2 framework.
16:16
Y_G
Have started writing basic unit tests for the work done . Will continue with this throughout the week.
16:16
Y_G
In parallel also working on documenting the work done .
16:17
Y_G
Sorry forgot about the entry,Will make an entry in the wiki today
16:17
Y_G
That would be all from my side.
16:18
se6ast1an
thanks!
16:19
se6ast1an
aSobhy: go ahead
16:19
aSobhy
Hi everyone :)
16:19
aSobhy
the last week I was working on generating the Bitstream files their were some errors that
16:19
aSobhy
I was facing and now Its free
16:19
aSobhy
added the jtag module to get the final result out
16:19
aSobhy
I almost 99% and a few hours I'll run on the beta_e
16:19
aSobhy
and thanks Bertl for the great help last week :)
16:20
se6ast1an
great, thanks!
16:20
Bertl
looking forward to the beta_e tests
16:21
se6ast1an
apurvanandan[m]: do you also want to report?
16:23
se6ast1an
right, quick update from my side
16:23
se6ast1an
I just installed a USB3 module in the partial remote beta
16:24
se6ast1an
I also measured rosette M6 center holes depths with other cameras and accessories today by visiting a local equipment rental place not far from our axiom office
16:24
se6ast1an
collected open todos for changes to the enclosure are listed here: https://wiki.apertus.org/index.php/AXIOM_Beta/Enclosures#AXIOM_Beta_Compact_Enclosure
16:24
se6ast1an
preparations for maker faire hannover have also started
16:25
se6ast1an
we will showcase the axiom project there august 17th and 18th
16:26
se6ast1an
right, anyone else who wants to update us here? felix_, BAndiT1983|away, Bertl ?
16:27
Bertl
well, I've been mostly busy with mentoring and reworking
16:28
se6ast1an
great, then I guess we can conclude this meeting early then
16:28
se6ast1an
feel free to discuss now with mentors
16:28
se6ast1an
and create an account on the wiki now
16:28
se6ast1an
you need a separate one
16:29
se6ast1an
a lab account will not help you on the wiki
16:29
se6ast1an
if something isnt working as it should be on the wiki now is a good time to discuss it here
16:29
se6ast1an
there are some anti spam measures on the wiki which could boycott the account creation process...
16:29
se6ast1an
let me know
16:31
Fares
Ok I am registering now
16:31
se6ast1an
great
16:37
Fares
I registered successfully and I will add the entry
16:37
se6ast1an
wonderful
16:38
se6ast1an
nira, Y_G, apurvanandan[m], aSobhy please do so as well
16:46
apurvanandan[m]
Hi everybody, sorry for the missing the meeting. This week I was able to both DDR x1 and DDr x4 work at 300 MHz with BER lower than 10^-9. This week I am working on bit alignment, channel bonding and improving FT601 controller. That was what I wanted to say.
16:48
se6ast1an
thanks
17:02
Bertl
off for now ... bbl
17:02
Bertl
changed nick to: Bertl_oO
17:12
Fares
left the channel
17:19
Fares
joined the channel
17:30
apurvanandan[m]
Bertl, can I install D3XX driver on beta_e
17:30
apurvanandan[m]
?
17:50
BAndiT1983|away
changed nick to: BAndiT1983
17:51
BAndiT1983
hi Y_G, sorry was not available for meeting as my day at work was longer than expected
17:52
BAndiT1983
which changes would be necessary for json format? usually it'S rather flexible and we could get away with just a general structure of it
17:54
Y_G
Hi BAndiT1983,yes general structure would work
17:54
Y_G
or We can also use three different structures for different types of request
17:55
BAndiT1983
why should we make things difficult than they should be?
17:56
BAndiT1983
at the moment i'm thinking also about the flatbuffers topic, we could get away with using a vector/array there and look for the size of it, if 2 thne it's general request and should be handled differently than 4 or 3096 etc.
17:57
BAndiT1983
same thing with json, we could send just 2 parameters or 4 for I2C or base64 string, the payload could be marked by a filed with the type or so
17:57
BAndiT1983
there are many ways to accomplish things, but it's importatn to keep it simple, otherwise the maintenance could be harder later
17:58
Y_G
Yes this seems better .
17:59
Y_G
So we can just add a field for packetType
17:59
BAndiT1983
i let you reflect on this for now, but will for sure start to implement a new server for axiom remote connection, there i also need JSON, but for general parameters, as it won't be possible to upload anything, obviously
17:59
BAndiT1983
yes, would you try to make considerations and we could discuss it in the next couple of days
17:59
BAndiT1983
?
17:59
BAndiT1983
just basic pro/contra
18:01
Y_G
Sure will check this .
18:01
Y_G
Also have started with writing basic unit tests. Will push the code in 2-3 days
18:02
BAndiT1983
very good, will also check them out
18:07
Y_G
Regarding the json structure of the packet ,there was one option for generating JSON schema by using --jsonschema with flatc
18:08
Y_G
https://pastebin.com/NYHG0Fd1
18:08
Y_G
^ This was the result ,but it seems a bit complex
18:12
BAndiT1983
nah, there is no reason to rely on flatbuffers structure for that
18:13
BAndiT1983
you can use flatbuffers structure as guidance, but if we need a bit more flexible structure to recognize special options, then you can adjust it to your liking
18:14
BAndiT1983
also this JSON packet structure is not suitable for slim usage, as it contains everything of flatbuffers and is probably used for their schema and not HTML transfer
18:15
Y_G
Ok , Thanks
18:17
BAndiT1983
Y_G, although flatbuffers supports such things as JSON deserialization, we still need to add payload recognition to be able to send proper packet to daemon
18:18
BAndiT1983
also this 2 step process is meant for preventing malicious usage by introducing basic sanity checks before sending to daemon
18:20
Y_G
Yes makes sense . A parameter for packetType will help with payload recognition
18:20
Y_G
what is the 2 step process ?
18:22
BAndiT1983
webui -(1)-> wsserver -(2)-> daemon
18:23
Y_G
oh ,ok
18:51
BAndiT1983
off for a moment
18:51
BAndiT1983
changed nick to: BAndiT1983|away
19:19
BAndiT1983|away
changed nick to: BAndiT1983
19:25
Fares
left the channel
19:43
Bertl_oO
apurvanandan[m]: you may, but I'm pretty sure it won't work there
19:52
apurvanandan[m]
Why would it not work?
19:52
Bertl_oO
because the beta_e is ARM architecture
20:03
apurvanandan[m]
no I meant on ZBox
20:04
Bertl_oO
then why do you say beta_e ?
20:05
apurvanandan[m]
sorry, can we install on zbox?
20:06
Bertl_oO
you may as well
20:09
apurvanandan[m]
and just to confirm, a usb cable goes from plugin module to the zbox right?
20:10
Bertl_oO
yup
20:11
apurvanandan[m]
okay
20:19
Nira
changed nick to: Nira|away
21:45
BAndiT1983
changed nick to: BAndiT1983|away
21:53
se6ast1an
good night
21:55
apurvanandan[m]
Good night
23:48
apurvanandan[m]
Bertl, the read and write ports of FIFOs belong to different clock domains, and must be accesed in their respective domains. But the full, empty, almost full/empty can be accesed from either reading and writing clock domains. Am I right?
23:49
Bertl_oO
most likely they belong to the respective domain as well
23:50
Bertl_oO
i.e. (almost) full to the write and (almost) empty to the read side
23:50
apurvanandan[m]
Full for write domain and empty for read domain
23:50
apurvanandan[m]
Okay
23:50
Bertl_oO
but for the test I suggested, you have the same clock on both ends
23:50
Bertl_oO
so it doesn't matter :)
23:50
apurvanandan[m]
That problem is resolved
23:51
Bertl_oO
yes, because we now know, that we do not know much about the actual BER of the FT601 connection
23:51
apurvanandan[m]
It was a stupidest mistake I made in data generation
23:52
Bertl_oO
do we have some new tests there? i.e. how does full bandwidth (32bit with 100MHz) perform?
23:52
apurvanandan[m]
There wasn't any issue with FT601 or fifo or software. The issue was is the counter I made :|
23:52
Bertl_oO
hmm? please elaborate
23:52
apurvanandan[m]
In pm
23:52
Bertl_oO
okayu