Current Server Time: 17:01 (Central Europe)

#apertus IRC Channel Logs

2019/07/02

Timezone: UTC


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