> I think what you're saying is to pass Verilog >parameters and macros through Migen, and then let the Verilog >synthesis (after Migen) evaluate them.
If I take a small example, what I was saying is: The .mig.v file: 'define MY_DEF0 1'b101 parameter MY_PARAM0 = 4'hA [- print(MY_DEF0) print(MY_PARAM0) -] becomes the .v file: 'define MY_DEF0 1'b101 parameter MY_PARAM0 = 4'hA 5 10 So Migen will know their values, but with that you can't have a top-down parameters propagation. (Or will have to generate multiple .v files according to parameters values). In fact I don't want to disappoint you but with the "embedded blocks" I was only wanting to code more efficiently while keeping a fine control on the result code. That why I suppose wire/reg/in/out interfaces are know by the user. Some uses case where I'd like to use this: - I have to code an FSM, but keep fine control of others parts of my code, let's use migen only for my FSM! - I have to do repetitive signal assignation,instantiations : let's use for python loops and migen. - According to my filters coefficients, when I generate my verilog, I want to plot the filters characteristics... - Get from a distant server some constants, a rom table, parse complex parameters files that will be too complicated to do in verilog. With this I can have all the information in my .mig.v file while in the traditionnal way I'll have a Python script doing the job, generating external files that I will have to re-include in my verilog files... So, it's maybe not really "Migen embedded" but more "Python + Migen embedded", It's maybe not the original idea behind Migen, but when I was testing MyHdl, I dropped very quickly because I was loosing completely control on my code and it was unreadable. Allowing a progressive adaptation can, I think, help introduce Migen to Verilog developers that will use it only for delimited use cases and switch to it progressively for their entire design... ;) But if you have ideas of a different uses with more integration in a global Migen design, I'll be happy to discuss about it and try to contribute. Florent 2012/7/19 Werner Almesberger <wer...@almesberger.net> > Florent Kermarrec wrote: > > When Migen blocks will be executed, Macro/Parameters will be known > > as Python Vars ;), but maybe I misunderstood your idea?? > > Hmm, maybe :-) I think what you're saying is to pass Verilog > parameters and macros through Migen, and then let the Verilog > synthesis (after Migen) evaluate them. This would work in > cases where Migen itself doesn't need to know these items. > > But what if also Migen needs to know their values ? > > > I don't really understand, if you mean that Migen code will be > distributed > > among blocks in mig.v files > > An example: let's say you want to make an arbiter. One way > to do it would be to have a central arbiter object and let > each user of it "connect" to the central object. In this > case, each user would modify the state of the central object > and the resulting Verilog Migen generates for each user > would be affected by at least the presence of other users. > > A different approach would be to create the central object > with the number of users and all other information known in > advance and then pass the items the users need to connect > to them individually. > > So depending on how this is done, Migen may have to have > some way to pass data around in a way that's not strictly > top-down. > > Disclaimer: I haven't had time to play with Migen yet, so > these scenarios are somewhat hypothetical. > > - Werner > _______________________________________________ > http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org > IRC: #milkymist@Freenode >
_______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
