Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow
Brought to you by:
jandecaluwe
From: Angel E. <ang...@gm...> - 2012-10-10 10:47:25
|
Hi again Chris, see my replies below. On Wed, Oct 10, 2012 at 12:20 PM, Christopher Felton <chr...@gm...> wrote: > On 10/10/12 1:59 AM, Angel Ezquerra wrote: >> On Tue, Oct 9, 2012 at 8:07 PM, Christopher Felton >> <chr...@gm...> wrote: >>> On 10/4/2012 4:02 PM, Angel Ezquerra wrote: [...] >>>>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote: >>>>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton >> [...] >>>>> Why would a large VHDL be an issue? I don't think it >>>>> is. If you really need the hierarchy there are options, >>>>> just takes a little more work. >>>> >>>> Could you detail what you mean by it "just takes a little more work"? >>> >>> Just that, you will need to convert each piece separately >>> and merge them together. Most of this can be automated >>> (I believe). >>> >>> I had a rare case where I wanted to preserve hierarchy >>> this is how I did it: >>> >>> toVerilog(submodule, sigs, params) >>> # move to a new filename with params in the name >> >> Sorry, maybe I'm a bit thick but I don't know what you mean by "move >> to a new filename with params in the name" > > When converting a module it has a "default" filename. In > this case I wanted a filename that represented the parameters > used to generated the module. OK, I understand. >>> submodule.verilog_instance = 'SUB1' >>> toVerilog(module, sigs, params) >>> >>> Where "module" instantiates 'submodule". This will stub >>> out "submodule" in module. It is a little more work >>> but not bad. I had to add extra to the submodule >>> >>> def submodule(...): >>> if hasattr(submodule, "verilog_instance"): >>> out1.driven = 'wire' >>> out2.driven = 'wire' >>> # etc >> >> I don't know what "verilog_instance" does. I guess there is an >> equivalent "vhdl_instance"? I looked for it on google but I did not >> get any useful results. I also don't know why you need to set the >> "driven" attribute. > > The "*_instance" isn't currently documented in the > manual. It is something that has been discussed on > the mailing list. This is a discussion of methods > that might be possible. It is not intended to be > cookbook solution to a specific problem. I see. But can you give the the gist of what it is supposed to do? Or perhaps a link to the particular thread on the mailing list? >> I feel as if these questions are very basic and I should know them... >> Is there some documentation on these features that I missed? >> >>> If you had a design that is more complicated you could >>> automate the first part. You still would need to add >>> the output definition in the module (submodule) being >>> stubbed. The nice thing about the above example, every >>> thing will be wired up automatically. >>> >>> Note: I think Jan indicated the verilog_instance might >>> need some work, use with caution. I have used it >>> without issue. >> >> As I said I don't really know what these do so I don't think I could >> use them, even cautiously :-> It still seems a bit too complicated for >> my taste though. > > That is a haste judgement. If you don't know what > it is how can you objectively comment that it is too > complicated? I don't fully understand each of the steps that you proposed but I see the amount of steps per submodule. If you wanted to do this for a large design with a fair amount of submodules the amount of steps would be great, wouldn't it? >> Anyway, since this process seems easy to automate (I can't really >> tell, since I don't really understand it), the obvious question is why >> not make MyHDL itself automate it for us? That should put to rest the >> question of generating hierarchical VHDL or Verilog code which seems >> to crop up regularly on this list and on other online discussions >> about MyHDL! > > The obvious question is why someone interested in a > feature doesn't propose a MEP and a patch? That is a fair point. I am still "testing the waters" with MyHDL so to speak, so for now I am just raising the concerns that I come up with. I could try to write a MEP but first I'd like to see if there is some consensus that this could be a worthy idea (as I believe it is). Also, what would be the preferred way to indicate that a group of generators should be grouped into an entity and placed on their own file? For example, in the case that you described, imagine that you had had a magic wand that let you modify MyHDL in a way that you could have avoided all the manual work involved in solving your problem. How would you have liked to be able to tell MyHDL that you wanted to place "submodule" on its own file? Contributing a patch is another matter though. I am quite busy contributing to TortoiseHg at the moment and I don't know how complex the MyHDL code base is. I don't know that I'd have the time to dig deep enough into it to contribute such a patch. >> That could be interesting although given that Xilinx XST will >> sometimes give you a different result when you implement the same code >> twice I would not put that much faith on the comparison results... >> Sometimes I feel that the Xilinx uses the position of the stars and >> the phase of the moon to decide how to synthesize their FPGAs :-P > > No, you should get consistent results from synthesis, > you might get varying timing from PaR but functionally > it should not change. I have not noticed resource > changes from synthesis run to synthesis run. That was meant as a point in cheek comment about how finicky the Xilinx tools are. Sorry if that was not clear. Cheers, Angel |