#apertus IRC Channel Logs

dear community: I need your feedback regarding screw color on the AXIOM Beta compact enclosure

do you think the aluminium parts match better with the slightly blueish screws eg. on the left

10*4 = 40 = 5*8

Ahh okay, so a SIPO will do?

(otherwise you wouldn't need a deserializing element :)

but you can 'select' the appropiate parts from a two byte history

AAAAAAAA AABBBBBB BBBBCCCC CCCCCCDD DDDDDDDD

we will*

I'm fine with that :)

as you can see from the example above, you always need two bytes from the input to form a 10bit word

and combine those (the last two bytes) into a 10bit word

and one clock cycle where nothing is generated only a byte is acquired

Fairly clear, will ask if I get stuck

Is someone using the GSoC Beta?

RexOrCine: nope :)

(a few minutes ago)

while (2 weeks )

(it's one of the early fans and the camera has been running for a very long time (24/7 for years)

RexOrCine: aSobhy is mostly using the Partial Beta

There it goes again. I'm not really bothered but Dan likes absolute silence here.

Aye I suspected it had been done.

but feel free to install a new fan

just make sure it is actually turning :)

Phwar. It's even worse.

Maybe we should watch how long that lasts and think about Noctua if it fails again.

Oh, we don't need them now, but as it happens there are four fans in your outbox here.

most likely the oil will eat the bearing ...

Meeting?

yup

while the quality of the code was okay, it wasn't great and the documenation in general was lacking a lot

Ok, definitely!

yes you are right :/

the main task now is to prioritize the important aspects

so let's focus on that for now

make sure that everything checked in can also be built by a third person

so on topic: data transfer, serialization and deserialization

any comments on how to address that? anything you figured out yet?

go ahead

This is the architecture used for DDR x4 8:1 gearing

It is controlled by DSQSDLLC by the DQSDEL signal

ECLKSYNCA is inserted to minimize the skews at the edges of fpga

DELAYE is the fixed delay element on the data bus

aSobhy: everything clear now?

he has a clk received at his module so we will have some difference in common

DDRX4rx_sync is the vhdl code generated by the IPexpress of Lattice Diamond. It gives greater control over the gearwork like the rx_start signal , rstn input signal for 'proper' reset of the gearwork ie it setups the gearwork in good condition

IDDRX4B takes input ALIGNWD. On pulsing ALIGNWD, it shifts by a bit ie 90 degree. It does work of bitslip.

Yes aSobhy ask doubts

There are four modes: BYPASS, USER DEFINED, FIXED and DYNAMIC. In fixed mode the Lattice software computes the optimum delay ( don't know how) and sets that. In FIXED mode we need to find the delay ( don't know exactly how)

I meant In user defined mode we need to find

assuming that you have a 'fixed' offset (data to clock) you can either adjust the constraints or set it manually in a delay

i.e. you will need to have some kind of dynamic adjustment to compensate for temperature, clock variation, silicon, etc

- find a common denominator between the two FPGAs

- find the smallest multiple of both capabilities

(e.g. you want 6 bit, use 3x4 bit and a gearwork)

also a word on PRNG and their use for testing

Bertl can you elaborate a little on third one

code**

and you want to transfer data with 8 bits

s/packets/words/

8b10b is not an option here without gearwork to remap the bits

and transfer 3 words instead of 2

ahh yes

but the 2 extra bits needs to be generating to make the work balanced also ?

ie the ALIGNWD

so even if your code is way off regarding DC balance, it will work just fine

but you can make some assumptions if you know the sender and the transmission line

back to PRNG

this also means that the generated bits, and that means _all_ of them, can be used for testing as they will go trough all possible values except for one

depending on the LFSR type, this will be either 0 or 2^(N-1)

if you use 'identity' as coding, all values you get are 'valid' regardless of any synchronization or data corruption issues

Oh, okay ie just for control codes

*efficiently

XD

Will again see less overhead encoding

apurvanandan[m], aSobhy: so as this seems to be an issue here, let's focus on encodings, CRC and ECC for this week

do that and please investigate the options, find suitable codings for our purpose within the hardware capabilities

also make a rough plan how to design the gearworks around them

Ok great

I have one question

for the clock recovery as I didn't test it yet I generated pll that has a reference clock I set it 100MHZ for now,

and the output will be the recovered clock

well, that is something you can do if you have a PLL suitable for clock recovery and the proper coding

Ok, what can you advice me to do ?

you can have a smart logic which detects the inevitable drift caused by having different clocks

or you can simply go for a common clock and derive your clocks from that (via PLL)

Bertl: Please discuss about PRNG now

Ok ^^'

you can use the 'degenerate' code (the 'forbidden state') for synchronization

you can simply XOR the output with a pattern you'd like to use for synchronization

but both will result in a pseudo random sequence

good, then have fun with encodings :)

are we done today !

yes, we are done for today, and yes, next week, same time, but let's try to get something done till end of week as mentioned before

sure :)

In my current setup

Ok, one more thing the upper limit clock speed for DDR gearing is 378 Mhz in MachXO2

but that mean 378*2

Lets search for other encoding scheme for DC coupled systems

(as done in the x4 and 7:1 examples)

no, you generate two clocks (with the PLL) with a fixed clock relation of 90deg

once again, check the Lattice high speed interfaces with MachXO2 for details (linked on the task description)

Actually I have read that completely

My doubt is at the end the ddr primitive needs to be clocked at 400 MHz edge clock right?

what bandwidth do you plan to run?

so 800Mbit, yes?

Yes

Ok I think I missed something.

that really depends on how you generate it

then it is good practice to generate the clock from a pattern like 0000011111

Ohh, I used 1010101010 actually

It is clear now Thanks :)

you typically transfer the clock at moderate frequency and use the PLL to regenerate the high speed clocks

good night