02:55 <sb0> rjo, ping

03:43 <cr1901_modern> sb0: Is it possible to generate an output migen Verilog file with parameters? Use case is to parameterize a clock frequency in an extenal project so the serial port gets the correct constant to count up to.

03:44 <sb0> no

03:44 <sb0> you have python to parameterize stuff, which is much more powerful than the verilog parameters

03:47 <cr1901_modern> Probably my best bet is to add a "manual verilog generation" mode for platforms which don't exist in Migen/LiteX

03:47 <sb0> ?

03:47 <cr1901_modern> "manual verilog generation" mode in my project*

03:47 <sb0> what do you mean?

03:50 <cr1901_modern> I have a few litescope designs that "should be portable to any dev board" regardless of whether it exists in LiteX or not. Not all of the platforms I use exist in LiteX. Since I can't really mix LiteX and migen.build platforms, _florent_ suggested I just generate verilog for each platform I'm interested in porting to, that only exists in Migen.

03:51 <cr1901_modern> However, if the platform DOES exist in Migen, I'd like to use it :P. Otherwise, just spit out a "generic Verilog file" that I can include in a non-migen project

03:51 <sb0> what do you need from the platform? what are the ios to your module?

03:51 <sb0> and how do you "port" it anyway?

03:53 <cr1901_modern> To port, I used a modified make.py similar to the one that existed in MiSoC before the API change. The IOs to my module are a serial port, clk (which can be of varying freq), and some GPIOs via add_extension

03:54 <cr1901_modern> sb0: This really isn't a "bug" or "something really important". It's just something I'm thinking about.

05:12 <rjo> sb0: pong

09:58 <cr1901_modern> Ahhh, so migen.build's Pins() class accept an int... did not know that. Well, making "fake" platforms to generate Verilog is easy then.

10:04 <sb0> how does this relate to pins being ints or not?

10:14 <cr1901_modern> sb0: I don't have to think up dummy names for pins :P (I guess it doesn't actually affect generating dummy platforms for Verilog generation)

10:15 <cr1901_modern> I imagine the vendor tools won't like the UCF with Pins instantiated with ints though

10:16 <_florent_> cr1901_modern: I'm not sure this is implemented in upstream migen (I added it to generate verilog code for cores)

10:16 <cr1901_modern> Oh...

10:18 <cr1901_modern> _florent_: I think you have the right idea. What I ended up doing for my litescope cores is instantiating a platform if one exists in LiteX, and also offering an option to generate platform/vendor independent Verilog code as well.

10:18 <cr1901_modern> (sans the clock frequency)

10:19 <cr1901_modern> I subclassed GenericPlatform, like you did in your litescope test files, added the expected I/O, and just make sure to only run get_verilog()- otherwise the build will die with NotImplemented

10:19 <cr1901_modern> This way, the procedure for building for targets and just generating Verilog code is the same

10:19 <cr1901_modern> sb0: Do you understand what I was trying to do now?

10:24 <cr1901_modern> _florent_: Migen doesn't implement this.

12:15 <sb0> cr1901_modern, I don't understand why you would like to make builds and verilog exports the same

12:16 <sb0> verilog exports don't really have "pins", and they don't have constraints etc.

12:16 <sb0> they don't need a database of potential IO resources to use

12:16 <sb0> if you want to have a similar "platform.request" API for verilog exports it's fine

12:16 <sb0> but

12:16 <sb0> 1. it should not be called "platform"

12:16 <cr1901_modern> For convenience/ease of creating build scripts. That's all

12:17 <sb0> 2. I don't think much or any of the infrastructure can be shared with the build system

12:17 <sb0> it's like using "make" for solving graph problems.

12:20 <cr1901_modern> sb0: I don't understand the graph problem analogy. It's not a huge problem if generating verilog code doesn't share the same infrastructure as building using migen.build.platform. I was just suggesting a convenience.

12:22 <cr1901_modern> If SCons wasn't so damn allergic to Python 3, I would just be using that.

12:23 <sb0> I'm saying it should _not_ use the same infrastructure

12:24 <cr1901_modern> You have your reasons/would know better than I. I'll figure something out.

12:32 <cr1901_modern> sb0: If you had a project that you wanted to use migen.build infrastructure, but also wanted the option to generate vendor-independent verilog (for unsupported boards and/or toolchains), how would you go about doing this?

16:14 <sb0> migen/misoc already output vendor-independent verilog whenever possible

16:14 <sb0> if it's using something vendor-dependent, that's because there's no other way of doing it

16:44 <sb0> whitequark, is the compiler handling negative delays correctly?

16:45 <whitequark> hm, it has no special logic to address those

16:46 <whitequark> it should, at least; if not then basic arithmetics would also be broken...