#apertus IRC Channel Logs

Hi everyone, will we have two meetings this week? On Monday and Tuesday?

apurvanandan[m]: Monday is the big meeting indeed, what meeting did you schedule for tuesday?

right, then indeed you have two meetings :)

gotta go

apurvanandan[m]: at least two meetings ;-)

se6astian|away: wget -r --no-parent https://files.niemo.de/axiom_pdfs/HARDWARE/AXIOM/

great! we have a decision to make!

they are basically pin compatible (the 2000 has more banks but on the same pins) https://www.latticesemi.com/view_document?document_id=43047

the question now is: do we want to have both (FT601 and FT602) with the 1200 or the 2000 or do we want one of each, and if so, which one :)

it would definitely make sense to use it and not have it sit there unused :)

we can decide on what to do with it ... it would be a good start to make a list of connections and protocol each routing fabric potentially has to handle

BANK13 SE_0 (RFW) and JX1 SE_0 (RFW)

which then can drive a PLL to generate higher phase related clock rates

so they can be different protocols on the two sides ?

but it would also be possible to use a bidirectional protocol on both RFE LVDS and just double the bandwidth

but I presume that switching direction has more problems than dedicating an LVDS connection to each direction

concerning to the packet protocol what kind of data I'll send ?

I can imagine ... basically we want to 'transport' data from various other protocols, ideally transparently, like I2C, SPI, JTAG, etc

what in my mind is: the ZYNQ will send the MachXO2 a command to do (for example read from a sensor of address ... with that I2C ) and the MachXO2 will handle that command and return the value again to the ZYNQ

both is true

Hmm,almost double, and what is the price estimate of USB module as whole?

but we can still decide to 'downgrade' the MachXO2 if we do not need the resources, the question is more for the current test/devel boards

naturally we can go for the 2000 for those, but then we cannot test with the 1200 at all

if we decide for the 1200 for both (FT601 and FT602) then we have a problem if it isn't good/large enough :)

leaves the question which one gets the 'larger' one :)

no, for many protocols this will be the way it goes

(specifically for input pins which are like 'interrupts' to the system)

SPI and JTAG also shift in as many bits as they shift out, so a generic 'request-response' approach might kill the latency there

off for now ... bbl

I think 2000 can go with ft601q and 1200 can go with ft602 as once we have a working module with 2000, we can try optimising the same for 1200 (stretch goal). I would choose the best bet when I don't know the limits.

When I run scripts like the zynq_info.sh in axiom_beta build,I get errors like these : "/sys/devices/soc0/amba/.adc/iio/in_temp0_offset': No such file or directory"

also what does 'bash -x zynq_info.sh' give as output (use a pastebin service or similar)

but even in qemu it should work

could be that the ADC is not emulated or (more likely) that the path is different

i don't know how Y_G runs the image, but if they use https://github.com/apertus-open-source-cinema/axiom-beta-firmware

(even in qemu)

and on real hardware it works aswell (just tested it), so not sure what the problem is...

hi Y_G, see the questions already asked here, if you use emulated firmware or not

it worked rather good, i could see my changes applied immediately, e.g. from web UI

I guess I should be using this "docker-make.sh qemu-shell"?

Yes you need to use qemu-shell

Y_G: yeah, as you can see, the sysfs entries are missing and that is why the script fails

Thanks ,I am running the "/usr/axiom/script/axiom-zynq-info.sh" which seems to give the correct output

great

BAndiT1983 : yup That would help

Hello BAndiT1983|away : playsliders now appear in UI of OC ,

I guess that's u have removed the code by commenting it

good night

Dev_, QtAV is not really used and was only added for first tests, don't know which problem with events you mean