Current Server Time: 04:42 (Central Europe)

#apertus IRC Channel Logs

2019/08/05

Timezone: UTC


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