00:11 <ysionneau> the firmware can just set EBA to the right address

00:12 <cr1901_modern> Oh, I don't think I've ever done that. HDMI2USB doesn't handle that?

00:12 <ysionneau> upon exception, the lm32 cpu jumps at the address contained in the EBA CSR + offset (offset depends on the exception nature)

00:12 <ysionneau> EBA = exception base address

00:13 <ysionneau> so if you just modify with wcsr instr the EBA CSR, you're OK

00:14 <cr1901_modern> Though I suppose it doesn't matter in a microcontroller application, there's nothing preventing your firmware that loads after the BIOS from editing EBA at will?

00:15 <ysionneau> https://github.com/m-labs/misoc/blob/master/misoc/software/libbase/crt0-lm32.S#L35 it's done over there.

00:16 <ysionneau> the 1st instructions of the firmware is to update EBA

00:16 <cr1901_modern> then there's no problem then. Your firmware that loads after the BIOS should be linking in the startup code anyway.

00:17 <ysionneau> sure, fw is linking with crt0-$(CPU) : for instance https://github.com/m-labs/mixxeo-soc/blob/master/software/Makefile#L23

00:17 <ysionneau> cr1901_modern: nothing will prevent any write to any CSR at all.

00:17 <cr1901_modern> Fair, was just wondering

00:17 <ysionneau> there is no "protected mode" or thing like that

00:18 <cr1901_modern> Well you wrote a MMU for it, didn't you?

00:18 <ysionneau> yes I was talking about the basic lm32 cpu without mmu

00:18 <cr1901_modern> Okay :)

00:21 <cr1901_modern> And I *assume* that user fw is always going to be linked such that it exclusively uses the main_ram section? From what I can tell, crt0, particularly the reset_handler, is going to be hardcoded, so the BIOS better load reset_handler at the proper address. >>

00:21 <cr1901_modern> (This of course doesn't apply if you're using libdyld, which isn't default)

00:21 <cr1901_modern> And I don't know if MiSoC BIOS even knows about it?

00:25 <ysionneau> the BIOS is responsible for loading the fw in RAM at the correct address

00:27 <cr1901_modern> I had started a SoC this month where it was actually necessary to *not* have a UART. So I looked into my options and concluded that just using FPGA block RAM as (partially) ROM will be sufficient for my purposes. So I didn't need to really think about making sure firmware was at the correct address :P.

00:27 <cr1901_modern> (*not* have a UART == I can't use MiSoC BIOS b/c it expects a UART)

00:28 <ysionneau> well I guess you can just hack MiSoC BIOS not to use any uart

00:30 <cr1901_modern> Might be an interesting pull request in the future. Main reason I haven't done it is b/c it could potentially break artiq stuff

00:30 <cr1901_modern> and I don't want to be responsible for breaking the builds :P

00:31 <shenki> ysionneau: thank you

00:32 <ysionneau> you're welcome!

00:32 <ysionneau> gn8

00:33 <cr1901_modern> Leave it ysionneau to dish out that important advice! :)

00:47 <mithro> ysionneau: Ahh, so it uses a dynamic jump vector location

01:15 <mithro> shenki: See above

01:23 <shenki> mithro: :)

02:21 <GitHub155> [artiq] jordens pushed 5 new commits to phaser2: https://git.io/vX9iS

02:21 <GitHub155> artiq/phaser2 b9ce2bb Robert Jordens: Merge branch 'phaser' into phaser2...

02:21 <GitHub155> artiq/phaser2 424a1f8 Robert Jordens: dsp: move test tools

02:21 <GitHub155> artiq/phaser2 ea0c304 Robert Jordens: phaser2: wip

09:47 <ysionneau> 01:47 < mithro> ysionneau: Ahh, so it uses a dynamic jump vector location < upon exception the address is fetched from EBA so yes it's dynamic

14:29 <larsc> do you know how multi-lane alignment in buffer bypass mode works with the GTX? How does it compensate the phase difference between the lanes?

14:33 <GitHub49> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/vXHSq

14:33 <GitHub49> artiq/drtio bb047aa Sebastien Bourdeauducq: drtio: simpler link layer

14:55 <sb0> larsc, in TX you mean?

14:57 <sb0> as I understand it, in TX it adjusts its internal clocks to match TXUSRCLK

14:57 <sb0> so there is no phase difference

14:58 <sb0> oh there's a RX multi-lane buffer bypass as well... haven't looked at that one

14:59 <sb0> mh, no idea how that can even work

15:01 <sb0> perhaps there is some sort of internal delay line on the data

15:05 <larsc> sb0: RX

15:05 <larsc> ok, thanks

15:16 <sb0> it's probably not det-lat

15:16 <sb0> well, of one serial UI

15:17 <sb0> hm

15:20 <GitHub68> [artiq] whitequark pushed 1 new commit to master: https://git.io/vXHb1

15:20 <GitHub68> artiq/master c7844d5 whitequark: runtime: use proper format for git commit....

15:22 <larsc> the thing is the buffer on the rx side is super expensive in terms of latency

15:22 <larsc> because it has all these features like char insertation/removal and what not

15:23 <larsc> and the comma alignment also seems to be quite expensive

15:24 <larsc> comma alignment in fabric would basically just be a mux right?

15:27 <sb0> I do comma alignment by resetting the xilinx garbage until it aligns itself

15:28 <larsc> but I wonder if you can still do the buffer bypass in that case

15:28 <sb0> in theory you could make its clock divider slip, but it looks like they messed up the silicon

15:28 <sb0> well if you have many lanes it gets tedious

15:29 <sb0> https://github.com/m-labs/artiq/blob/drtio/artiq/gateware/drtio/transceiver/gtx_7series_init.py#L120

15:30 <sb0> and yes, you can comma-align in fabric easily

15:31 <sb0> register the previous word, and then barrel-shift the concatenation of the previous and current

15:32 <sb0> they ought to fix their PMA issues instead of implementing hard blocks for this...

15:33 <sb0> in misoc dvi_sampler there's a soft comma aligner and soft lane aligner

15:33 <sb0> https://github.com/m-labs/misoc/blob/master/misoc/cores/dvi_sampler/charsync.py

15:33 <sb0> https://github.com/m-labs/misoc/blob/master/misoc/cores/dvi_sampler/chansync.py

15:36 <sb0> larsc, isn't clock correction (aka char insert/remove I suppose) a feature of the elastic buffer that gets bypassed?

15:38 <larsc> yes, but when it does not get bypassed you still get the penalty even if you only want to do phase alignment

15:38 <larsc> there is a special mode for just phase alignment, but th e documentation

15:39 <larsc> the latency specification doesn't mention it

15:39 <sb0> are you building a jesd204 receiver?

15:39 <larsc> I can neither confirm nor deny that

15:40 <larsc> well, the answer is no, I did built one a while ago, just looking at the latency right now

15:40 <larsc> cause the GTX latency is pretty bad

15:41 <bb-m-labs> build #195 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/195

16:09 <bb-m-labs> build #385 of artiq-win64-test is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/385 blamelist: whitequark <whitequark@whitequark.org>

16:09 <bb-m-labs> build #1095 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1095 blamelist: whitequark <whitequark@whitequark.org>

16:50 <larsc> is there a good way to dynamically generate the sensitiviy list based on configuration parameters?

17:21 <rjo> larsc: which sensitivity list? which config paramters?

17:21 <larsc> for a always statement

17:21 <larsc> based on module parameters

17:21 <larsc> in verilog

17:23 <rjo> larsc: is '*' not adequate?

17:24 <larsc> I want either * or posedge clk

17:26 <rjo> larsc: not that i know. in migen it's trivial though. ;)

17:26 <larsc> yeah

17:27 <larsc> well, I guess I just have to have two blocks with the second one registering the output of the first

20:36 <cr1901_modern1> Is "posedge clk" legal in the context of an if statement in Verilog (that's also inside an always @)?

20:55 <larsc> only in a sensitive list I belive

20:56 <larsc> sensitivity

21:37 <cr1901_modern> sb0: *Is it okay if this is not supported*, but... is it possible to make a wishbone memory (add_mem_region) and a wishbone peripheral to share the same 256MB region in MiSoC? Or does the address decoding for MiSoC not support this?

21:38 <cr1901_modern> Making the peripheral part of the CSR bus isn't possible b/c the core I want to attach isn't designed to operate at 32 or 50 MHz. So wait states will be necessary during reads.

21:38 <cr1901_modern> (And well, only wishbone provides these :P)

21:39 <cr1901_modern> If it's not supported, I'll just use another 256MB chunk for peripheral output buffers (read only from CPU's POV) and call it a day.