Current Server Time: 20:56 (Central Europe)

#apertus IRC Channel Logs

2019/07/02

Timezone: UTC


01:57
aombk
left the channel
02:06
aombk
joined the channel
06:25
BAndiT1983|away
changed nick to: BAndiT1983
06:40
BAndiT1983
changed nick to: BAndiT1983|away
06:49
illwieckz
left the channel
06:53
illwieckz
joined the channel
08:04
Bertl_oO
changed nick to: Bertl_zZ
08:29
sebix
joined the channel
09:00
se6astian|away
changed nick to: se6astian
12:38
se6astian
dear community: I need your feedback regarding screw color on the AXIOM Beta compact enclosure
12:39
se6astian
please look at https://cloud.gerade.org/index.php/apps/gallery/s/EqJsZdy8SH8c9f9#20190701_121406_HDR.jpg
12:39
se6astian
do you think the aluminium parts match better with the slightly blueish screws eg. on the left
12:40
se6astian
or the slightly more brownish/greyish one in the middle?
13:10
sraj
joined the channel
13:34
RexOrCine|away
changed nick to: RexOrCine
13:46
sraj
left the channel
13:53
illwieckz
left the channel
14:05
Nira|away
changed nick to: Nira
14:05
illwieckz
joined the channel
14:47
Bertl_zZ
changed nick to: Bertl
14:47
Bertl
morning folks!
14:50
Nira
changed nick to: Nira|away
14:55
se6astian
left the channel
14:55
se6astian
joined the channel
14:55
se6astian
left the channel
14:55
se6astian
joined the channel
14:56
Nira|away
changed nick to: Nira
14:56
se6astian
left the channel
14:56
Nira
left the channel
14:56
RexOrCine
left the channel
14:56
philippej
left the channel
14:56
BAndiT1983|away
left the channel
15:05
apurvanandan[m]
Hi Bertl
15:06
Nira|away
joined the channel
15:06
RexOrCine|away
joined the channel
15:06
philippej|away
joined the channel
15:06
philippej|away
changed nick to: philippej
15:06
BAndiT1983|away
joined the channel
15:06
se6astian|away
joined the channel
15:06
BAndiT1983|away
changed nick to: BAndiT1983
15:06
se6astian|away
changed nick to: se6astian
15:07
RexOrCine|away
changed nick to: RexOrCine
15:07
apurvanandan[m]
Is there some way we can use the DDR x4 8:1 of MachXO2 to make 10:1 gearing?
15:08
Bertl
10*4 = 40 = 5*8
15:08
Bertl
so collecting 5 8bit values will give you 4 10bit values
15:11
apurvanandan[m]
Ahh okay, so a SIPO will do?
15:12
Bertl
well, you won't be able to 'shift' the bits at that speed
15:12
Bertl
(otherwise you wouldn't need a deserializing element :)
15:13
illwieckz
left the channel
15:13
Bertl
but you can 'select' the appropiate parts from a two byte history
15:14
Bertl
00000000|11111111|22222222|33333333|44444444
15:14
Bertl
AAAAAAAA AABBBBBB BBBBCCCC CCCCCCDD DDDDDDDD
15:17
aSobhy
Bertl: when we meet today ?
15:18
aSobhy
we will*
15:19
illwieckz
joined the channel
15:19
Nira|away
changed nick to: Nira
15:24
illwieckz
left the channel
15:24
illwieckz
joined the channel
15:25
Bertl
aSobhy: the usual time, 19:00 CEST unless you have a problem with that, then we can adjust it
15:27
aSobhy
I'm fine with that :)
15:29
apurvanandan[m]
Bertl: I didn't get that how to do that addressing by making a LUT Ram?
15:31
Bertl
as you can see from the example above, you always need two bytes from the input to form a 10bit word
15:31
Bertl
so you simply keep each byte for two cycles
15:32
Bertl
and combine those (the last two bytes) into a 10bit word
15:32
Bertl
there will be 4 clock cycles which generate a 10bit word
15:32
Bertl
and one clock cycle where nothing is generated only a byte is acquired
15:33
Bertl
you need an 8bit register for that and a mux which can select the correct bits for the 10bit word
16:00
apurvanandan[m]
Fairly clear, will ask if I get stuck
16:14
Bertl
great!
16:15
se6astian
changed nick to: se6astian|away
16:32
dev__
joined the channel
16:44
RexOrCine
Is someone using the GSoC Beta?
16:45
illwieckz
left the channel
16:47
aSobhy
RexOrCine: nope :)
16:47
RexOrCine
Have you just been using it?
16:48
RexOrCine
(a few minutes ago)
16:48
aSobhy
I didn't used it for wile
16:48
aSobhy
while (2 weeks )
16:50
RexOrCine
Thanks. The reason I ask is because the fan makes a noise occasionally, so ideally it should be replaced. I wonder if now might be an opportune time for me to do that. Bertl?
16:50
RexOrCine
(it's one of the early fans and the camera has been running for a very long time (24/7 for years)
16:51
RexOrCine
Two years possibly longer.
16:52
Bertl
RexOrCine: aSobhy is mostly using the Partial Beta
16:53
RexOrCine
Yes, that's the one with the issue.
16:53
RexOrCine
There it goes again. I'm not really bothered but Dan likes absolute silence here.
16:53
Bertl
I really doubt that, as I did assemble it a few weeks ago, so the fan cannot be that old there :)
16:54
RexOrCine
Aye I suspected it had been done.
16:54
RexOrCine
Is it ok to disconnect it and replace it? We have a suitable fan here.
16:54
Bertl
but feel free to install a new fan
16:54
RexOrCine
104
16:55
Bertl
just make sure it is actually turning :)
16:59
dev__
left the channel
16:59
RexOrCine
Phwar. It's even worse.
17:00
Bertl
well, I suggest to buy a 'silent' fan then
17:01
dev__
joined the channel
17:02
Bertl
Noctua for example has quite nice ones, but only 40mm so you need an adapter, which shouldn't be a big problem for the Partial
17:11
illwieckz
joined the channel
17:19
RexOrCine
Reconnected. Replacement fan was worse. Fixed with vegetable oil. Lashings of vegetable oil.
17:23
RexOrCine
Maybe we should watch how long that lasts and think about Noctua if it fails again.
17:24
RexOrCine
To be fair it's pretty silent anyways, with lashings of oil.
17:24
Dev
joined the channel
17:24
Dev
changed nick to: Guest50548
17:26
Guest50548
left the channel
17:27
dev__
left the channel
17:50
RexOrCine
Oh, we don't need them now, but as it happens there are four fans in your outbox here.
17:52
RexOrCine
changed nick to: RexOrCine|away
17:52
Bertl
most likely the oil will eat the bearing ...
17:53
Bertl
so make sure to check in the following days that the fan is still running :)
18:06
apurvanandan[m]
Meeting?
18:06
aSobhy
+1
18:07
Bertl
yup
18:08
Bertl
so first some feedback regarding the first evaluation
18:09
Bertl
while the quality of the code was okay, it wasn't great and the documenation in general was lacking a lot
18:10
Bertl
we let that slide for the first evaluation but we won't on the second, so please make sure to improve on that
18:10
apurvanandan[m]
Ok, definitely!
18:11
se6astian|away
changed nick to: se6astian
18:11
aSobhy
yes you are right :/
18:11
Bertl
also looking at your proposals, you are somewhat behind, but that is expected
18:12
Bertl
the main task now is to prioritize the important aspects
18:13
Bertl
I haven't seen any successful FPGA to FPGA communication yet and everything around synchronization and alignment is still 'very' vague
18:14
Bertl
so let's focus on that for now
18:15
Bertl
regarding code quality and documentation, I suggest to check eachothers code and try to understand it ... if that fails, let the other know so that it can be improved
18:15
Bertl
make sure that everything checked in can also be built by a third person
18:16
Bertl
(not just a day before - or even worse a day after the evaluation :)
18:18
Bertl
so on topic: data transfer, serialization and deserialization
18:18
Bertl
as you both figured out by now, with two different FPGAs invovled, you seldom have the same structures or elements/units to work with ...
18:19
Spirit532
left the channel
18:19
Spirit532
joined the channel
18:19
Bertl
any comments on how to address that? anything you figured out yet?
18:20
apurvanandan[m]
Let me tell what I have figured out
18:22
Bertl
go ahead
18:22
apurvanandan[m]
https://ibb.co/k0QWcnF
18:23
apurvanandan[m]
This is the architecture used for DDR x4 8:1 gearing
18:24
apurvanandan[m]
Here DLLDELC is controlled delay element
18:25
apurvanandan[m]
It is controlled by DSQSDLLC by the DQSDEL signal
18:26
apurvanandan[m]
Using it we shift the edge to edge clock by 90 degree for centered clock
18:26
apurvanandan[m]
ECLKSYNCA is inserted to minimize the skews at the edges of fpga
18:26
apurvanandan[m]
As the DDR circuitry is on bottom of the fpga
18:28
BAndiT1983
changed nick to: BAndiT1983|away
18:28
apurvanandan[m]
CLKDIVC generates the clock which we gonna use for sampling deserailized data
18:28
apurvanandan[m]
DELAYE is the fixed delay element on the data bus
18:28
apurvanandan[m]
DELAYE can be repalced by DELAYD for incorporating dynamic delays
18:29
Bertl
aSobhy: everything clear now?
18:29
apurvanandan[m]
ANd yes IDDR4XB is the final DDR x4 gearing primitive which does what its name says
18:31
aSobhy
he has a clk received at his module so we will have some difference in common
18:31
Bertl
what I meant was: did you understand the design and the challenges it solves?
18:32
apurvanandan[m]
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
18:33
aSobhy
not all of them !
18:34
apurvanandan[m]
IDDRX4B takes input ALIGNWD. On pulsing ALIGNWD, it shifts by a bit ie 90 degree. It does work of bitslip.
18:34
Bertl
good, because I would be very surprised if everything was clear from that
18:35
apurvanandan[m]
Yes aSobhy ask doubts
18:37
aSobhy
how can you find the fixed delay?
18:40
apurvanandan[m]
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)
18:41
Bertl
the timing constraints and the 'wiring' gives the desired delays
18:41
apurvanandan[m]
I meant In user defined mode we need to find
18:41
Bertl
let's say you tell the tools that the data is synchronous to the clock, then it can calculate the required delays
18:42
Bertl
assuming that you have a 'fixed' offset (data to clock) you can either adjust the constraints or set it manually in a delay
18:44
Bertl
aSobhy: note that you can also use a common clock as we discussed before
18:44
Nira
changed nick to: Nira|away
18:45
Bertl
note that you have to get the timing constraints right for such a setup and as mentioned before, at a certain speed, you won't be able to get it right for all cases
18:46
Bertl
i.e. you will need to have some kind of dynamic adjustment to compensate for temperature, clock variation, silicon, etc
18:47
Bertl
what seems to have caused some confusion in the last weeks is that there are no '10:1 deserializers' in the MachXO2
18:48
BAndiT1983|away
changed nick to: BAndiT1983
18:48
Bertl
but it is quite common that you do not have the perfect word length for your design
18:48
sebix
left the channel
18:48
Bertl
there are several approaches to this:
18:49
Bertl
- find a common denominator between the two FPGAs
18:49
Bertl
(this will usually be a 4:1 or maybe 8:1 setup)
18:50
Bertl
- find the smallest multiple of both capabilities
18:50
Bertl
and the desired word length
18:51
Bertl
(e.g. you want 6 bit, use 3x4 bit and a gearwork)
18:52
Bertl
- use a code which matches the available capabilities
18:52
se6astian
changed nick to: se6astian|away
18:53
Bertl
obviously the last one will usually result in inefficient bandwidth usage
18:54
Bertl
also a word on PRNG and their use for testing
18:54
Bertl
(as this seems to have caused some confusion and unnecessary work as well)
18:55
apurvanandan[m]
Bertl can you elaborate a little on third one
18:55
aSobhy
sorry I didn't catch last one. what is meant by word ?
18:55
aSobhy
code**
18:55
Bertl
let's say you have mechanisms for 4:1 gearing
18:56
Bertl
and you want to transfer data with 8 bits
18:56
Bertl
the obvious way to transfer them is in two packets (code = identity)
18:56
Bertl
s/packets/words/
18:57
Bertl
let's say you want to improve on that by using a more advanced coding scheme
18:57
Bertl
8b10b is not an option here without gearwork to remap the bits
18:58
Bertl
but you could use an 8b12b code instead
18:58
Bertl
and transfer 3 words instead of 2
18:58
apurvanandan[m]
Ahh,you mean to change encoding scheme
18:59
se6astian|away
changed nick to: se6astian
18:59
se6astian
left the channel
18:59
se6astian|away
joined the channel
19:00
Bertl
if done properly, you can benefit from the longer codewords (better CRC, possibly ECC, lower frequencies, etc)
19:00
se6astian|away
changed nick to: se6astian
19:00
se6astian
left the channel
19:00
RexOrCine|away
left the channel
19:00
Nira|away
left the channel
19:00
philippej
left the channel
19:00
BAndiT1983
left the channel
19:01
apurvanandan[m]
ahh yes
19:01
apurvanandan[m]
I have one more doubt, bit slip needs to be different for each lanes in the architecture shown right?
19:01
se6astian|away
joined the channel
19:01
se6astian|away
changed nick to: se6astian
19:01
BAndiT1983|away
joined the channel
19:01
BAndiT1983|away
changed nick to: BAndiT1983
19:01
philippej|away
joined the channel
19:01
Nira|away
joined the channel
19:01
RexOrCine|away
joined the channel
19:01
philippej|away
changed nick to: philippej
19:02
aSobhy
but the 2 extra bits needs to be generating to make the work balanced also ?
19:02
aSobhy
word**
19:02
apurvanandan[m]
ie the ALIGNWD
19:02
Bertl
DC balance is a nice feature, but not too relevant in your case as all the connections between FPGAs are DC coupled
19:03
Bertl
so even if your code is way off regarding DC balance, it will work just fine
19:03
Bertl
and yes, any word alignment needs to be done individually
19:04
Bertl
but you can make some assumptions if you know the sender and the transmission line
19:04
Bertl
i.e. if the sender is synchronous and the transmission line doesn't differ more than a bit is long, you can assume that you will get the data with at most 1 bit difference between the lanes
19:05
Bertl
back to PRNG
19:06
Bertl
for every LFSR of N bits, there is at least one 'optimal' polynomial which has 2^N-1 states till it loops
19:07
Bertl
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
19:07
apurvanandan[m]
If we aren't doing click recovery, connections are DC coupled , then why need 8b10b
19:07
Bertl
depending on the LFSR type, this will be either 0 or 2^(N-1)
19:08
Bertl
never said we need 8b10b, but you need some coding to verify what you are receiving
19:09
Bertl
if you use 'identity' as coding, all values you get are 'valid' regardless of any synchronization or data corruption issues
19:10
Bertl
(i.e. you will never know :)
19:11
apurvanandan[m]
Oh, okay ie just for control codes
19:11
Bertl
also encodings like TMDS (an 8b10b encoding) allow you to use the available bandwidth more efficient (i.e. transfer more data more reliably)
19:11
Bertl
*efficiently
19:11
Kjetil
use 7b11b ( ;P)
19:12
apurvanandan[m]
XD
19:13
Bertl
Kjetil: I'd prefer something with 13 or 17 bits :)
19:13
apurvanandan[m]
Will again see less overhead encoding
19:14
Kjetil
Bertl: 17b13b - Guaranteed 24% dataloss with every symbol
19:14
Bertl
apurvanandan[m], aSobhy: so as this seems to be an issue here, let's focus on encodings, CRC and ECC for this week
19:15
aSobhy
we should team again apurvanandan[m] :D
19:15
Bertl
do that and please investigate the options, find suitable codings for our purpose within the hardware capabilities
19:15
Bertl
make a list and document the pros and cons
19:16
Bertl
also make a rough plan how to design the gearworks around them
19:16
Bertl
let's try to have something till end of the week/week end
19:17
apurvanandan[m]
Ok great
19:18
aSobhy
OK
19:18
aSobhy
I have one question
19:19
Bertl
sure, go ahead
19:20
aSobhy
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,
19:20
aSobhy
and it has an input I set it to the income data (LVDS_in)
19:21
aSobhy
and the output will be the recovered clock
19:21
aSobhy
am I right or I should reference it with a clock from the MachXO2 ?
19:21
Bertl
well, that is something you can do if you have a PLL suitable for clock recovery and the proper coding
19:22
Bertl
I'm not aware that the MachXO2 PLL can do clock recovery, so most likely this will just result in a PLL which doesn't lock
19:25
aSobhy
Ok, what can you advice me to do ?
19:25
Bertl
personally I wouldn't spend much time on clock recovery with the MachXO2
19:26
Bertl
you can have a smart logic which detects the inevitable drift caused by having different clocks
19:26
Bertl
and compensates for it by dynamically adjusting the clock phase
19:27
Bertl
or you can simply go for a common clock and derive your clocks from that (via PLL)
19:29
aSobhy
OK I'll go with common clock
19:30
apurvanandan[m]
Bertl: Please discuss about PRNG now
19:30
Bertl
well, I kind of did already :)
19:31
apurvanandan[m]
Ok ^^'
19:31
Bertl
but to summarize: you need N bits of test data, get an LFSR with N bits size, find an 'optimal' polynomial and it will generate 2^N-1 values for you
19:31
Bertl
you can use the 'degenerate' code (the 'forbidden state') for synchronization
19:31
Bertl
as it won't be generated by the LFSR
19:32
Bertl
you can simply XOR the output with a pattern you'd like to use for synchronization
19:32
Bertl
note that 'xor-ing' the output is different from 'seeding' the LFSR
19:33
Bertl
but both will result in a pseudo random sequence
19:36
apurvanandan[m]
Ok great
19:40
Bertl
good, then have fun with encodings :)
19:40
apurvanandan[m]
Next week same time?
19:40
aSobhy
are we done today !
19:40
Bertl
and let me know if you encounter unexpected issues
19:41
Bertl
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
19:41
apurvanandan[m]
Definitely!
19:42
aSobhy
sure :)
19:42
apurvanandan[m]
Can we use oscilloscope for measuring fixed delays?
19:42
apurvanandan[m]
In my current setup
19:43
Bertl
if you pull that off for 1Gbit data rates, sure, why not :)
19:45
apurvanandan[m]
Ok, one more thing the upper limit clock speed for DDR gearing is 378 Mhz in MachXO2
19:46
apurvanandan[m]
We will definitely need more. But that is a later issue I guess
19:46
aSobhy
but that mean 378*2
19:47
apurvanandan[m]
I need atleast 800 if I used 8b/10b
19:48
apurvanandan[m]
Lets search for other encoding scheme for DC coupled systems
19:48
Bertl
that's why you want to sample with two phase related clocks
19:48
Bertl
(as done in the x4 and 7:1 examples)
19:50
apurvanandan[m]
You mean two clock lanes?
19:50
Bertl
no, you generate two clocks (with the PLL) with a fixed clock relation of 90deg
19:51
Bertl
then you can sample at 4 times the clock rate
19:52
Bertl
once again, check the Lattice high speed interfaces with MachXO2 for details (linked on the task description)
19:52
BAndiT1983
changed nick to: BAndiT1983|away
19:52
apurvanandan[m]
Actually I have read that completely
19:52
Bertl
you can also achieve a similar effect with an delay element
19:53
apurvanandan[m]
My doubt is at the end the ddr primitive needs to be clocked at 400 MHz edge clock right?
19:54
Bertl
why?
19:54
Bertl
what bandwidth do you plan to run?
19:55
apurvanandan[m]
Each lanes at 400 MHz DDR
19:55
Bertl
so 800Mbit, yes?
19:56
apurvanandan[m]
=800 Mbps
19:56
apurvanandan[m]
Yes
19:56
Bertl
with x4, this means 200MHz clock
19:56
apurvanandan[m]
Ok I think I missed something.
19:57
apurvanandan[m]
The clock is edge aligned with each bit from OSERDES right?
19:58
Bertl
that really depends on how you generate it
19:58
Bertl
for example, if you have a 1:10 serializer
19:59
Bertl
then it is good practice to generate the clock from a pattern like 0000011111
19:59
Bertl
(via the same serializer setup you use for data)
19:59
apurvanandan[m]
Ohh, I used 1010101010 actually
19:59
Bertl
well, that's unnecessarily high
20:00
apurvanandan[m]
It is clear now Thanks :)
20:00
Bertl
i.e. it will create a high frequency clock which has all the problems you don't need
20:01
Bertl
you typically transfer the clock at moderate frequency and use the PLL to regenerate the high speed clocks
20:01
apurvanandan[m]
Ok I got it
20:13
Spirit532
left the channel
20:14
Spirit532
joined the channel
20:55
BAndiT1983|away
changed nick to: BAndiT1983
21:49
BAndiT1983
changed nick to: BAndiT1983|away
22:59
Y_G
joined the channel
23:04
se6astian
off to bed
23:04
se6astian
good night
23:04
se6astian
changed nick to: se6astian|away