04:26 <unclestem[m]> Got told to use this to meet new

04:26 <unclestem[m]> Got told to use this to meet new

04:26 <unclestem[m]> People

04:26 <unclestem[m]> People

15:38 <d1b2> <TomKeddie> I'm looking at a protocol (arm trace) that needs ddr input support. We currently only support one pin type, it seems like I could add support for ddr input and ddr output at the same time (and possibly allow for differential input or output on future hardware). I've made a start, I'm looking for a nod that I'm heading in a direction compatible with the platform. I'm also looking for the preferred way to proceed wrt TSTriple (as far as I can tell

15:38 <d1b2> <TomKeddie> I'm looking at a protocol (arm trace) that needs ddr input support. We currently only support one pin type, it seems like I could add support for ddr input and ddr output at the same time (and possibly allow for differential input or output on future hardware). I've made a start, I'm looking for a nod that I'm heading in a direction compatible with the platform. I'm also looking for the preferred way to proceed wrt TSTriple (as far as I can tell

15:38 <d1b2> there is no object representation for io in nmigen other than TSTriple). The support for ddr etc is (of course) already present in the ice40 support, I'm asking about the preferred way to generate this from glasgow applets. https://github.com/TomKeddie/glasgow/commit/5afccbebc9f736d24ea0abe00d2d9807a0bd5d67#diff-e31a46634d1bb74cb28c44a28bc7460aae5973fa85d176d36a6906ddfc22f0bb

15:38 <d1b2> there is no object representation for io in nmigen other than TSTriple). The support for ddr etc is (of course) already present in the ice40 support, I'm asking about the preferred way to generate this from glasgow applets. https://github.com/TomKeddie/glasgow/commit/5afccbebc9f736d24ea0abe00d2d9807a0bd5d67#diff-e31a46634d1bb74cb28c44a28bc7460aae5973fa85d176d36a6906ddfc22f0bb

15:39 <whitequark[m]> there is no TSTriple in nmigen

15:39 <whitequark[m]> there is no TSTriple in nmigen

15:40 <whitequark[m]> as for DDR pins, this is missing a lot of machinery and is unlikely to be merged soon

15:40 <whitequark[m]> as for DDR pins, this is missing a lot of machinery and is unlikely to be merged soon

18:38 <d1b2> <TomKeddie> Since you haven't told me I'm wasting my time completely I'm going to press on trying to add the necessary machinery. Am I on the right path using a list of dictionaries in set_pads or would you prefer an object?

18:38 <d1b2> <TomKeddie> Since you haven't told me I'm wasting my time completely I'm going to press on trying to add the necessary machinery. Am I on the right path using a list of dictionaries in set_pads or would you prefer an object?

18:39 <whitequark[m]> I don't expect to have time to spend any time on code for Glasgow within the next month or more

18:39 <whitequark[m]> I don't expect to have time to spend any time on code for Glasgow within the next month or more

18:39 <whitequark[m]> * I don't expect to have any time to spend on code for Glasgow within the next month or more

18:39 <whitequark[m]> * I don't expect to have any time to spend on code for Glasgow within the next month or more

18:39 <whitequark[m]> adjust accordingly

18:39 <whitequark[m]> adjust accordingly

18:40 <whitequark[m]> I also expect to implement the necessary machinery myself in concert with improving it in nMigen

18:40 <whitequark[m]> I also expect to implement the necessary machinery myself in concert with improving it in nMigen

18:41 <whitequark[m]> there's a lot of things to discuss on the design stage; no code can be written meaningfully at the moment

18:41 <whitequark[m]> there's a lot of things to discuss on the design stage; no code can be written meaningfully at the moment

18:42 <d1b2> <TomKeddie> Ok, I'll drop it. It would be great to have arm trace on Glasgow, the trace capable probes are like $us2k.

18:42 <d1b2> <TomKeddie> Ok, I'll drop it. It would be great to have arm trace on Glasgow, the trace capable probes are like $us2k.

18:43 <whitequark[m]> sure, and I have plans for ARM trace

18:43 <whitequark[m]> sure, and I have plans for ARM trace

18:43 <whitequark[m]> it's just that technical debt needs to be addressed first, and it will be addressed first

18:43 <whitequark[m]> it's just that technical debt needs to be addressed first, and it will be addressed first

18:43 <jpa-> maybe you could fake DDR inputs with e.g. d-flipflops activated on other edge, connected to normal inputs; or just higher internal clock and checking for edges on the clock pin

18:43 <jpa-> maybe you could fake DDR inputs with e.g. d-flipflops activated on other edge, connected to normal inputs; or just higher internal clock and checking for edges on the clock pin

18:44 <whitequark[m]> none of that will be merged upstream

18:44 <whitequark[m]> none of that will be merged upstream

18:44 <whitequark[m]> and if you don't aim for that, just instantiate SB_IO

18:44 <whitequark[m]> and if you don't aim for that, just instantiate SB_IO

18:54 <d1b2> <TomKeddie> I have it working on icebreaker just fine, that's all I need for now.

18:54 <d1b2> <TomKeddie> I have it working on icebreaker just fine, that's all I need for now.