00:21 <_whitenotifier-3> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/J3ZG2

00:21 <_whitenotifier-3> [YoWASP/nextpnr] whitequark 9aad2bf - Update dependencies.

00:50 <_whitenotifier-3> [nmigen-boards] hansfbaier synchronize pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3L4k

00:58 <_whitenotifier-3> [nmigen-boards] hansfbaier commented on pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3ZWd

00:58 <_whitenotifier-3> [nmigen-boards] hansfbaier edited a comment on pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3ZWd

01:00 <_whitenotifier-3> [nmigen-boards] whitequark commented on pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3ZlL

01:08 <_whitenotifier-3> [nmigen-boards] hansfbaier commented on pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3Z84

01:08 <_whitenotifier-3> [nmigen-boards] hansfbaier edited a comment on pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3Z84

11:19 <_whitenotifier-3> [nmigen-boards] hansfbaier commented on pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3cBG

12:02 <_whitenotifier-3> [nmigen-boards] whitequark commented on pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3cVS

12:35 <_whitenotifier-3> [nmigen-boards] hansfbaier commented on pull request #152: add board support for QMTech XC7A35T core board and daughterboard - https://git.io/J3cXo

13:44 <FL4SHK> what is an acceptable amount of assertions that you have the right kind of AST node for my project?

13:57 <FL4SHK> actually

13:57 <FL4SHK> I think ti's better not to ask a loaded question like that

19:46 <lkcl> has anyone any ideas on how to pull a reset signal on *just one* module?

19:46 <lkcl> preferably without creating an entire domain to do so

19:55 <tpw_rules> you can wrap it in a ResetInserter

20:02 <FL4SHK> decided to continue with what I was doing for assertions

20:02 <FL4SHK> I do some asserts to make sure you've got the right kind of AST Node

20:02 <FL4SHK> but it's not completely perfect

20:02 <FL4SHK> some of it allows invalid VHDL

20:05 <FL4SHK> is that a problem if the VHDL implementation catches it?

20:21 <lkcl> tpw_rules: fantastic, thank you

20:23 <lkcl> are there any examples anywhere of how to use ResetInserter?

20:23 <lkcl> ah it's a decorator?

20:23 <lkcl> intriguing

20:24 <lkcl> accepts a *dict* of reset signals...

20:27 <lkcl> this uses it: https://vivonomicon.com/2020/06/13/lets-write-a-minimal-risc-v-cpu-in-nmigen/

20:44 <lkcl> tpw_rules: thank you, works great.

20:57 <vup> FL4SHK: that probably depends on the quality of error messages you want to provide, I can imagine errors coming from the VHDL implementation being harder to understand than the ones you generate yourself...

21:12 <FL4SHK> vup: the project I'm working on has you writing VHDL code from within Python

21:12 <FL4SHK> well, you're generating a VHDL AST

21:12 <FL4SHK> then my tool will translate it into real VHDL

21:13 <FL4SHK> so I don't know

21:13 <FL4SHK> implementing VHDL-side errors themselves seems hard

21:14 <vup> what do you mean by VHDL-side errors?

21:14 <FL4SHK> errors that the VHDL implementation could catch for me

21:15 <FL4SHK> I'd basically be making a partial VHDL implementation regarding errors

21:15 <vup> yeah, I mean that kind of seems unavoidable with your project

21:15 <vup> its a matter of where you want to draw the line I guess

21:16 <FL4SHK> I'm not going to be doing VHDL type checking

21:17 <FL4SHK> I could make it a long term goal

21:17 <FL4SHK> I do some error checking

21:18 <vup> if the structure of the python code and the vhdl code will be very similar, it could be the case that you don't even need any error checking on the python side, but to me it sounds like you want to write more of a meta programming layer for VHDL, so for example just finding the correct piece of python code to look at, when you get a error message from the VHDL implementation could start to get difficult.

21:25 <FL4SHK> vup: so I planned on letting you see the Python line numbers within the VHDL

21:26 <FL4SHK> I have that set up already

21:27 <vup> sure, but with one layer of python functions between that, that doesn't work anymore probably? Or you would need something like a complete stacktrace

21:27 <FL4SHK> I am using the complete stacktrace to figure it out

21:27 <FL4SHK> it's an argument to the VHDL AST nodes

21:30 <vup> ok maybe what I said was imprecise, what I mean is, there is not always a correct entry of the stacktrace to use.

21:30 <FL4SHK> why would that be the case?

21:30 <FL4SHK> I take the exact source code position to use within the stacktrace

21:31 <vup> say you are writing a function that takes some arguments and then generates some AST nodes from that

21:31 <vup> do you want to get the point in the function where the AST node was generated, or the point where the function was called?

21:31 <FL4SHK> I provide the point where the AST node was generated

21:32 <vup> I would say, it depends, for some errors you want to get the point in the function, for some you want the place where the function was called (for example if the error only occurs for a specific set of arguments)

21:33 <FL4SHK> I don't know how I'd track that

21:33 <FL4SHK> I thought tracking the location of AST nodes would just work (TM)

21:34 <vup> I mean the python stacktrace give you the whole stacktrace, does it not? So in principle it should be possible to track, but of course printing the whole stacktrace for every AST node would get very unreadable aswell

21:37 <FL4SHK> I think it's good to be able to see the line that an AST node was generated on

21:37 <FL4SHK> even if it's not the perfect answer

21:37 <FL4SHK> I see your point

21:37 <FL4SHK> here's the thing

21:38 <FL4SHK> I don't print out a whole stack trace

21:38 <vup> yes, I understood that, I am saying always printing out the whole stack trace would not be much better

21:44 <FL4SHK> I don't always print the whole stack trace

21:44 <FL4SHK> I don't print it out at all