#apertus IRC Channel Logs

well, it could be one of the FT60x errata

you said you did extensive tests with a counter directly attached to the FTDI interface and there was no data loss, right?

Yupp, I connected a counter clocked with FT601_clk with fifo_emp signal always zero

okay, so maybe try that then

I tried somewhat similar, I connected counter clocked with 75 MHz with write enable always 1 to the fifo and still data was lost

okay, try that without the DDR input clock

but 75MHz is fine as well

both are fine for this purpose

in case it turns out not to happen with this setup, we can get to 75MHz via PLL

Bertl, it happens with simple counter at 66.5 MHz also

*try

Bertl It works perfectly fine ie no errors at 380MBps like it used to work

ie when clocked both sides with FT601 clocl

preferably with more than one block of missing data?

As they are rare

Okay sending 10 values

okay, how does that happen?

So the FT601 controller takes pauses long enough that fifo gets full

Basically FT601 ensures that packet is received correctly at PC so it may retransmit

I converted the verilog code of ufrisk's pcileech from verilog to vhdl :/

No at that I completely understood what I wrote

so explain the ported code to me (or show me some well indented VHDL code :)

It goes from IDLE to intermediate states then to receive or transmit states

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';

I see, well, the retransmit is nice, but that is not a good approach for high bandwidth data transfer

but it seems to work for the 100MHz case, so the problem must be elsewhere

*under

This is from the old times of first evaluation, please don't mind

Just little more formatted right now

it makes reading HDL so much easier ...

Not much different but still :/ https://gist.github.com/apurvanandan1997/27a217c0cdc40d92343d748850d38837

-- From Internal FIFOs

(line 46 and line 52)

The async fifos

what did you connect there?

so the 'From' is connected to your fifo, yes?

Yup right

Fifo_emp is the indicator that internal fifos are empty

but how is that different from data_wr_en = 0 ?

I think that might be part of the problem

so there is constant data flow without any interruption

Yupp

which most likely turns off req_data

which in turn will generate some backlog on the fifo

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';

replace the highest bits of the counter with meta-data from the FIFO

Okk doing that

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

because you do not get a huge number of FIFO empty signals

which in turn cause the complex state changes

Bertl I have a lecture , i wil be back later :)

In order to get the final counter out I checked the schematic of machXO2-1200 and found that it have EBR (Embedded Block RAM

?

but how will you retrieve it 'easily' from there?

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)

by JTAG

not yet !

I think yes

So I'm wrong :(

but you still do not have a plan it seems

there is a JTAGF primitive in the MachXO2

which in turn allows you to access data from inside the MachXO2 via JTAG

well, jtag is always on unless you disable it (which is a bad idea anyway :)

which need to be implemented in your FPGA code

sounds like a good way to transfer your data?

I was reading the library guide sorry for the delay

you're welcome!

does it overflow?

Yes, as when I stopped counter on fifo_full condition , there wasn't any data loss at 66.5 MHz counter

but we don't know yet why it gets full and if that happens slowly over time or abruptly at some point

abruptly, i guess as we get 150 MB data then there loss of some values and then we again get MBs of data correctly

what if the fifo lags behind a few words for every megabyte

hmm, I need to check that to be sure

Yupp

so there is no 'accessible' fill state there

no accesible full state?

fill state not full state :)

but you can also do that with an external counter

Then what do I do with that :)

i.e. have one out of four cycles supply data into the FIFO

not easily

we know that 100MHz in and 100MHz out of the FIFO works (at least if you tested that correctly :)

i.e. put three words in the FIFO (at 100MHz FTDI clock), then skip one

use that counter for the upper 16 bit of the FIFO data

do some math on the received data to see if the fifo slowly gets full or suddenly stalls and fills up

The setup works at 100MHz as the read enable becomes the write enable

how's that?

When the counter is again enabled when read enable is high

I don't follow

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

so basically the throughput with the current controller is way lower than the available bandwidth

so back to square 1 on the FTDI side then

check what you receive on the PC side and if there are any data losses

we have 3.2Gbit to transfer and this has to go through

at USB 3 provides about 5GBit, this should be doable

off to bed now ...

Ok cool, time to get to serious work :)

good day

morning folks!

Bertl: apurvanandan[m] - look at this: https://www.ftdichip.com/Support/Documents/AppNotes/AN_386%20FTDI%20FT600%20Maximize%20Performance.pdf

yes, thanks, we have seen and discussed this quite some time ago

if you go through the document, the discuss the overhead of idle and header data

(again, unless the FTDI folks screwed up :)

lets see how it turns out :)

meeting time!

hopefully this will solve a lot of messages being set to me not going missing now

so meeting time, please pm me now as usual if you want to report!

*off

this week I have done what was missing about the transmission from the PIC16 to the PIC32 via UART

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

great, many thanks

Hi everyone

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.

That would be all, thank you!

please create an entry here:https://wiki.apertus.org/index.php/GSoC_Projects

but I see that nobody did it....

did you create an account and log in?

anyways, do it now!

Y_G, your tunr

I have acc on the lab not the wiki

Hi all,

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.

Have started writing basic unit tests for the work done . Will continue with this throughout the week.

Sorry forgot about the entry,Will make an entry in the wiki today

thanks!

Hi everyone :)

I was facing and now Its free

I almost 99% and a few hours I'll run on the beta_e

great, thanks!

apurvanandan[m]: do you also want to report?

I just installed a USB3 module in the partial remote beta

collected open todos for changes to the enclosure are listed here: https://wiki.apertus.org/index.php/AXIOM_Beta/Enclosures#AXIOM_Beta_Compact_Enclosure

we will showcase the axiom project there august 17th and 18th

well, I've been mostly busy with mentoring and reworking

feel free to discuss now with mentors

you need a separate one

if something isnt working as it should be on the wiki now is a good time to discuss it here

let me know

great

wonderful

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.

off for now ... bbl

Bertl, can I install D3XX driver on beta_e

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

or We can also use three different structures for different types of request

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.

there are many ways to accomplish things, but it's importatn to keep it simple, otherwise the maintenance could be harder later

So we can just add a field for packetType

yes, would you try to make considerations and we could discuss it in the next couple of days

just basic pro/contra

Also have started with writing basic unit tests. Will push the code in 2-3 days

Regarding the json structure of the packet ,there was one option for generating JSON schema by using --jsonschema with flatc

^ This was the result ,but it seems a bit complex

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

Ok , Thanks

also this 2 step process is meant for preventing malicious usage by introducing basic sanity checks before sending to daemon

what is the 2 step process ?

oh ,ok

Why would it not work?

no I meant on ZBox

sorry, can we install on zbox?

and just to confirm, a usb cable goes from plugin module to the zbox right?

okay

Good night

most likely they belong to the respective domain as well

Full for write domain and empty for read domain

but for the test I suggested, you have the same clock on both ends

That problem is resolved

It was a stupidest mistake I made in data generation

There wasn't any issue with FT601 or fifo or software. The issue was is the counter I made :|

In pm