myhdl-list Mailing List for MyHDL (Page 94)
Brought to you by:
jandecaluwe
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
(10) |
Mar
(19) |
Apr
(14) |
May
(1) |
Jun
(4) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
(7) |
Nov
(17) |
Dec
(12) |
2005 |
Jan
(6) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(9) |
Jun
(5) |
Jul
(26) |
Aug
(34) |
Sep
(10) |
Oct
(38) |
Nov
(71) |
Dec
(74) |
2006 |
Jan
(20) |
Feb
(20) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
|
Jul
|
Aug
(4) |
Sep
(37) |
Oct
(43) |
Nov
(30) |
Dec
(33) |
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(30) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(13) |
Nov
|
Dec
(4) |
2008 |
Jan
(13) |
Feb
(46) |
Mar
(25) |
Apr
(7) |
May
(20) |
Jun
(73) |
Jul
(38) |
Aug
(47) |
Sep
(24) |
Oct
(18) |
Nov
(9) |
Dec
(36) |
2009 |
Jan
(31) |
Feb
(24) |
Mar
(73) |
Apr
(13) |
May
(47) |
Jun
(28) |
Jul
(36) |
Aug
(2) |
Sep
(5) |
Oct
(8) |
Nov
(16) |
Dec
(29) |
2010 |
Jan
(34) |
Feb
(18) |
Mar
(18) |
Apr
(5) |
May
|
Jun
(24) |
Jul
(53) |
Aug
(3) |
Sep
(18) |
Oct
(33) |
Nov
(19) |
Dec
(15) |
2011 |
Jan
(9) |
Feb
(4) |
Mar
(39) |
Apr
(213) |
May
(86) |
Jun
(46) |
Jul
(22) |
Aug
(11) |
Sep
(78) |
Oct
(59) |
Nov
(38) |
Dec
(24) |
2012 |
Jan
(9) |
Feb
(22) |
Mar
(89) |
Apr
(55) |
May
(222) |
Jun
(86) |
Jul
(57) |
Aug
(32) |
Sep
(49) |
Oct
(69) |
Nov
(12) |
Dec
(35) |
2013 |
Jan
(67) |
Feb
(39) |
Mar
(18) |
Apr
(42) |
May
(79) |
Jun
(1) |
Jul
(19) |
Aug
(18) |
Sep
(54) |
Oct
(79) |
Nov
(9) |
Dec
(26) |
2014 |
Jan
(30) |
Feb
(44) |
Mar
(26) |
Apr
(11) |
May
(39) |
Jun
(1) |
Jul
(89) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
(20) |
Dec
(27) |
2015 |
Jan
(107) |
Feb
(106) |
Mar
(130) |
Apr
(90) |
May
(147) |
Jun
(28) |
Jul
(53) |
Aug
(16) |
Sep
(23) |
Oct
(7) |
Nov
|
Dec
(16) |
2016 |
Jan
(86) |
Feb
(41) |
Mar
(38) |
Apr
(31) |
May
(37) |
Jun
(11) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
2017 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(1) |
Mar
(7) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(11) |
2022 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2023 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christopher F. <chr...@gm...> - 2012-05-10 02:06:42
|
On 5/5/12 10:20 AM, Norbo wrote: > Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton > <chr...@gm...>: <snip> >>>>>> >>>>>> I don't know if the _doinit flag is actually needed? I believe the >>>>>> conversion code can determine if the value should be written or not >>>>>> without modifying the Signal or intbv objects. As your modified intbv >>>>>> does, it can always create the initial value unless the Signal/intbv >>>>>> init value is None. >>>>> Yes this would be possible if the value (._val) of the intbv is set to >>>>> None. >>>>> But there are several things that raise, exceptions if the value is >>>>> set >>>>> to >>>>> None. (Boundcheck, __getitem__, etc..) >>>>> so i added the _doinit flag and set the (._val) to 0 (or to the min >>>>> value >>>>> if defined), and thereby avoided the error-prone changing of these >>>>> functions which wouldnt work with the None value. >>>> >>>> Why do you need "None"? It would be my understanding that the >>>> conversion process will always create the init values in the converted >>>> code. You don't need the _doinit flag and you don't need None. >>> >>> My thought on this was that it may be usefull to have explicit controll >>> on >>> whether the initial values are written ot not. For example if a big ram >>> is >>> described >>> and you don't need the initial values, the converted file would be >>> filled >>> up with a >>> huge number of basically useless values. -> Or in the words of "import >>> this" in python: >>> Explicit is better than implicit >>> >> >> To me this is *not* explicit, you don't have direct control over _doinit >> you have implicit control if the initial values are generated or not >> (which I have even forgotten what the control is). > The idea of the controll was if you write: > aList=[Signal(intbv(None)) for i in range(10) ] --> then the initial > values are not written no matter what. > aList=[Signal(intbv(i)) for i in range(10) ] --> the initial values > are written in verilog and vhdl when there is > no combinatorical assignment ("as a path of least resistance right > now") > > I think we are both in agreement, now, that the None can be used for the explicit control (which means more changes in the implementation). But I don't think I agree that there are cases when the values should *not* be written. I think they should always be written (when not None). I think we can work through the implementation changes. If None is used, that should mean the _doinit is not required. > > >> I hear the argument for the large inclusive of init values. And with >> FPGA embedded memories and ASIC available ROM/RAM growing these could be >> long init lists. But I am not totally convinced the inconvenience of >> long inits are bad because it breaks the earlier argument "MyHDL to >> Verilog/VHDL mismatch". > > I didn't get that. It has been brought up in the past that if MyHDL simulation has initial values and the Verilog/VHDL does not have initial values. Then you have a simulation mismatch at time 0 through time N (most cases, until the reset occurs). I think we have a good design plan to cover the initial values that includes the pre-init RAMS (nice addition). We should probably summarize in a separate post (new thread, not buried). I boils down to adding support for None and then creating initial values in Verilog/VHDL if the intbv initial value is not None. Regards, Chris |
From: Jan C. <jan...@mu...> - 2012-05-09 21:31:21
|
On 08/05/12 13:19, Christopher Felton wrote: > As you mentioned others are trying to give strong opinions on how to > fish without understanding much about fishing (or why we are fishing). Whether putting up a TV broadcast aerial, or just building a small house we have two principal choices: Understand all the engineering implications down to bedrock, or accept a ready made platform. If the platform is as high as a TV tower, it might be good to know something of it's behaviour in wind before climbing up to install an aerial, just in case some extra pills are needed! However, looking up at the waving top, and suggesting design modifications is likely to lessen the chance of anyone's aerial becoming installed. > By hinder progress, you simply mean your attention is diverted to a > lower-level non-related topic? No, worse than that! I get very interested in lower levels of the design in progress, the stuff that I can't control, and should happily entrust to synthesis tools. > In general the claim to fame by [1] is > that it takes the known, successful, design techniques and does the > translation to async itself. We might never need anything better!:) Since RTL balances delays between latches (to a first approximation), then replacing buffers with 'signal re-synchronisation' logic should just work. However, I dislike black boxes, so shall insist that I need to know the details, so that I can predict any odd cases where simple translation is not the best option. > MyHDL should be as useful as any other tool for [1]. Yes, I'm just starting to appreciate it's power. I struggle to read verilog in places where it is very terse, but also soon tired of using VHDL where so many things have to be written in triplicate. > Feedback is always welcome, it might be challenged but I believe you and > most have found that the group here is fair. Yes, it's been a largely pleasant experience, and I feel sufficiently supported. > It looks like you have been successful with MyHDL. ... The UART was the first sign of reasonable productivity. Translating the processor designs from verilog to MyHDL was an up-hill struggle - two unfamiliar languages, and no obvious means of testing anything less that a working whole. Thanks for the encouragement, Jan Coombs. -- [1] www.achronix.com |
From: Christopher F. <chr...@gm...> - 2012-05-08 12:19:38
|
On 5/6/2012 3:23 AM, Jan Coombs wrote: > On 06/05/12 06:35, Tom Dillon wrote: > >> "Experienced python developer", what is that? I am not sure what >> that has to do with anything. > True. An "Experienced python developer" is most likely someone who > has gained some control over a machine at a very high level of > abstraction. They may know little or nothing about the > progressively differing layers of software beneath, supporting > their code. Likely, the further layers of hardware concepts > expressed below are completely out of sight. > >> There is nothing unnatural about MyHDL. Again, trying to draw >> somebody into a meaningless discussion. > I think he's angling to get a fish, a big one. A person wanting to > learn to fish would need to be interested in understanding and > clearly distinguishing the names of the tools, behaviour of fish, > affects of tides, etc. Asking why angling is not an iPhone app > that can be run, sat on a bench in the park while watching bowls is > pointless. > >> MyHDL works fine. I fail to see a conflict at all. > I'm struggling, but much too inexperienced with Python to suggest > changing any of MyHDL. As you mentioned others are trying to give strong opinions on how to fish without understanding much about fishing (or why we are fishing). Thanks for being one of the sane members of the community. > > My hardware experience started with borrowing my mums breadboard > and dressmaking pins, and using surplus germanium diodes and > transistors. I still like to know the details of the fabric I'm > using. > > Today I still have questions, for example: Do clockless gate arrays > use standard SRAM blocks in an async wrapper, or are they async to > a much lower level than this. It may seem pointless to ask, but it > would help me to estimate the reliability of tools which translate > RTL designs to use a clockless fabric. [1] > > But this extremely low-level interest might hinder my progress in > using MyHDL in a similar way to having an insufficiently deep > understanding of electronics. I'll need to work to get the balance > right. > By hinder progress, you simply mean your attention is diverted to a lower-level non-related topic? In general the claim to fame by [1] is that it takes the known, successful, design techniques and does the translation to async itself. MyHDL should be as useful as any other tool for [1]. > It has been a hard struggle for me to get started with MyHDL, > hopefully we can work out why, and make it easier for others in the > future. > > Jan Coombs Feedback is always welcome, it might be challenged but I believe you and most have found that the group here is fair. And the group is much more tolerable to trolls than other groups. Don't be afraid to ping questions you have asked in the past if you still have questions. It looks like you have been successful with MyHDL. You have posted your UART code (comp.arch.fpga), mentioned your forth processor, and a couple other projects. Regards, Chris |
From: Christopher F. <chr...@gm...> - 2012-05-07 15:13:15
|
> >> This might be the path of least resistance right now. But I don't think >> there is a reason that the converted couldn't generate >> >> reg [7:0] out1 = 8'd0; >> reg [7:0] aListSig [0:10-1]; >> // initial blocks ... >> @always_comb begin > > nice: @always_comb begin a myhdl artefact ;) > >> aListSig[3] = in_data >> out1 = aListSig[3] >> end >> Yes, typo should not have included the '@'. Note: *always_comb* and *always_ff* are new key words in later version of Verilog and support by most Sysnthesis tools, even the free ones. Or it is fine to use always @(*) or explicitly include the sensitivity list as the VHDL conversion does. Regards, Chris |
From: Christopher F. <chr...@gm...> - 2012-05-07 13:53:47
|
On 5/3/2012 3:23 PM, G. Andrew Stone wrote: > Hi Jan, > > Let me try to say it in another way. Please forgive any inaccuracies; its > been a few years! :-) > > If my synthesizable hardware description was put in a simulation black box > (call it "hdl") with some simple API that could be used like: > > hdl.start() > for time in range(1,whatever): > output_signals = hdl.next(list_of_input_signals) > > then as a software engineer I'd completely understand how to write a > complex simulation and testbench around it. For example, if my "hdl" > object defined a PCI bus card I could pretty easily write Python code that > jams in a bunch of fake PCI requests and make sure the right stuff comes > out. I could easily make up code that runs a bunch of these black boxes > simultaneously and use unsynthesizable python to "glue" them together to > make a larger system -- thereby simulating a subset of some larger system. > I could even have each black box "running" at different clock speeds. Or I > could even hook the simulation black box up to the actual code that will > run on a CPU and talk to my FPGA. > > So I (as a software professional) don't need myHDL to help me do that. > What I need is it to help me with is what's inside that black box. But the > docs (but please remember my heavy use was several years ago) keep trying > to teach me how to do the testbench part. This confused me because I kept > thinking I was writing synthesizable code. > I don't understand where the confusion comes from? Both Python and MyHDL are tools -languages/tools- that help us build *things* as you suggest. Example, I have a verification framework that I use for building and verifying DSP modules. This has a mix of non-HDL blocks and HDL blocks. Here is a brief preview. from myhdl import Simulation import blocks from filters import MyFilter sine1 = blocks.sources.Sine(frequency=40e3, sample_rate=1e6) sine2 = blocks.sources.Sine(frequency=30e3, sample_rate=1e6) a1 = sine1 + sine2 flt = MyFilter(a1) plot1 = blocks.sinks.Plotter(sine1, sine2, a1, flt) v1 = blocks.sinks.VerifySequence(flt, exact=False, vfunc=vfunc) Simulation(blocks.GetAllGenerators()).run() This simple example verifies the expected output of the HDL filter. OO design was used heavily in this framework. MyHDL and Python are at the core, the technologies that enabled me to build such an environment. Without MyHDL's objects, functions, and *quality* I would have had to do a ton more work (which would have made it non-feasible). MyHDL enables me to have a competitive advantage! I have had to build, what feels like thousands of simulation models over the years, everything from C/C++/SystemC, HDLs, Matlab, etc. Some of these were non-HDL models, others mixed, and others pure HDL. But nothing has been more efficient to develop than Python/MyHDL! And now with the performance improvements I get to watch colleagues never meet a schedule and the one weak argument they had ... is irrelevant. Here is another example: @instance def tb_stimulus(): # Write Wishbone memory mapped device yield fx2Model.WriteAddress(0x0101, 1) yield fx2Model.WriteAddress(0x0103, 0xAA) yield fx2Model.ReadAddress(0x0103, rbuf) [fx2Model.Write(data, fx2Model.EP4 for dat in test_data1] # Wait for the data to transfer yield fx2Model.IsEmpty(fx2Model.EP4) ... raise StopSimulation In this example I have a model with "transactors". The transactors bridge my event driven model world to the HDL world. I guess from my point of view you can build frameworks with the interfaces you might want. And these interfaces might be different for each problem to solve. Regards, Chris |
From: Tom D. <td...@di...> - 2012-05-07 13:11:36
|
Now I get it, you need us all to know that you are an experienced python programmer (more experienced than the audience here) and also witty. On 05/06/2012 06:17 AM, Christopher Lozinski wrote: > On 5/6/12 12:35 AM, Tom Dillon wrote: >> MyHDL works fine. I fail to see a conflict at all. > There is a huge difference between representing signals are arguments to > a function, and as instance variables on an object. The later supports > inheritance, and quickly leads to rich libraries of Atomic and Compound > Hardware Module libraries. I am sincerely sorry you do not see the > difference. If there is any way I can help you understand the issues, > please let me know. Wait for the punchline. > . > . > . > . > . > . > . > . > . > > You just need more experience with Object-Oriented Modelling. > . > . > > |
From: Norbo <Nor...@gm...> - 2012-05-07 12:43:55
|
> I don't want to start a discussion about the merits of your point > of view, but again I point out that heavy MyHDL users, myself included, > see things entirely differently. > > I developed MyHDL because I wanted to do modeling and verification > in python, and stock python didn't give me the fine-grained threading > and event-driven paradigm needed. At that time, it was not clear if > it was desirable or even possible to do conversion as a path to > synthesis. > > If synthesizable code would be all it did, I wouldn't see the point. For me, synthesizable code is also a key aspect in Myhdl. Back in University and in two Jobs where i worked with VHDL the major job to do was to implement several Filters or Signalprocessing piplines where lookuptables occoured. Normally i used Matlab or Python (with pylab) to calculate these Filter coeffiecents or lookuptable values. The question then was how to get these values to the VHDL design. This is really a pain because in some stages of development these coeffiecents or lookuptable values change quite often, and every time they change i had to copy and paste them, change signal value ranges, array ranges, etc... --> with Myhdl i can use these values directly from the python code where i calculated them and let the signal value range, array range, etc.. be adjusted automatically. For me this is really extremly usfull and really simplifies the process. I think that fast signal processing piplines with lookuptables and filter design is a key area for hardware description languages and FPGAs. The other key area is maybe special bus interfaces, for them i didn't see a point of synthesisable Myhdl either. --> I couldn't think of any other case right now where a standard microcontroller or DSP wouldn't be enough. Back in University we also did some golden model checking for a cordic VHDL core design, by using SystemC with tlm and doing coSimulation. This is where the pain really starts. This is where Myhdl really starts to shine. If we would have used Myhdl back then, i think we really could have skipped half a year. greetings Norbo |
From: Jan D. <ja...@ja...> - 2012-05-07 09:27:07
|
On 05/03/2012 10:23 PM, G. Andrew Stone wrote: > Hi Jan, > > Let me try to say it in another way. Please forgive any > inaccuracies; its been a few years! :-) > > If my synthesizable hardware description was put in a simulation > black box (call it "hdl") with some simple API that could be used > like: > > hdl.start() for time in range(1,whatever): output_signals = > hdl.next(list_of_input_signals) > > then as a software engineer I'd completely understand how to write a > complex simulation and testbench around it. For example, if my "hdl" > object defined a PCI bus card I could pretty easily write Python code > that jams in a bunch of fake PCI requests and make sure the right > stuff comes out. I could easily make up code that runs a bunch of > these black boxes simultaneously and use unsynthesizable python to > "glue" them together to make a larger system -- thereby simulating a > subset of some larger system. I could even have each black box > "running" at different clock speeds. Or I could even hook the > simulation black box up to the actual code that will run on a CPU and > talk to my FPGA. > > So I (as a software professional) don't need myHDL to help me do > that. What I need is it to help me with is what's inside that black > box. But the docs (but please remember my heavy use was several > years ago) keep trying to teach me how to do the testbench part. > This confused me because I kept thinking I was writing synthesizable > code. I don't want to start a discussion about the merits of your point of view, but again I point out that heavy MyHDL users, myself included, see things entirely differently. I developed MyHDL because I wanted to do modeling and verification in python, and stock python didn't give me the fine-grained threading and event-driven paradigm needed. At that time, it was not clear if it was desirable or even possible to do conversion as a path to synthesis. If synthesizable code would be all it did, I wouldn't see the point. I always assumed that would be obvious to other MyHDL users but I recognize this is an assumption that may have been too implicit. Anyway, it explains why I'm not interested in discussions when MyHDL is limited to that aspect: it is not my world. And there are further reasons. The continuous identification of MyHDL "limitations" with conversion or even synthesis limitations is tiresome. And it is demotivating. I hardly hear any talk about the HDL limitations that MyHDL actually lifted in comparision to $$$ synthesis, e.g. by the way conversion works after elaboration, and how it does integers. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Christopher L. <loz...@fr...> - 2012-05-06 11:56:32
|
On 5/6/12 6:05 AM, Jan Decaluwe wrote: Those are all great steps in the right direction. > I have separated the chapters about modeling in the manual. > I have also added an introduction making it clear that > high-level modeling is very useful, but not intended for synthesis. > > http://www.myhdl.org/doc/dev/index.html > To write synthesizable models in MyHDL please make it, If you want to build an ASIC, or FPGA, use... python guys are not quite sure what synthesizable means. Specifically f you gave me a test, I would not be able to distinguish synthesizable logic from non-synthesizable logic. > > And I have further refined the What MyHDL is Not page. > > http://myhdl.org/doku.php/whatitisnot#myhdl_is_not_only_for_implementation > And here are my comments on that page. MyHDL is not a classic object-model of a digital circuit In MyHDL hardware modules are modeled by functions, not objects. Signals are arguments to that function, not instance variables of a class. There is no class called HardwareModule <http://wiki.myhdlclass.com:8080/AtomicHardwareModule>. If there were, it would look like this. http://wiki.myhdlclass.com:8080/OOHDL While Verlilog talks about Hardware module hierarchies, MyHDL has no parent instance variable, there is no children instance variables. Indeed there is no class to put them into. There is no rich library of hardware modules that subclass off of these classes. You cannot iterate over the tree of hardware modules to calculate something. By default, there is no such tree, unless you build it yourself. While MyHDL is written in python, I would call it a functional approach to modelling a digital design. It is designed for hardware engineers, not experienced python developers. It would be beyond awesome if you would add that to your wiki. In the meantime people can find a copy at: http://wiki.myhdlclass.com:8080/WhatMyHDLisNot Forgive me for being so direct. I sincerely hope the feedback is helpful. Thank you for listening, I am getting better at finding my voice. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
From: Christopher L. <loz...@fr...> - 2012-05-06 11:17:31
|
On 5/6/12 12:35 AM, Tom Dillon wrote: > MyHDL works fine. I fail to see a conflict at all. There is a huge difference between representing signals are arguments to a function, and as instance variables on an object. The later supports inheritance, and quickly leads to rich libraries of Atomic and Compound Hardware Module libraries. I am sincerely sorry you do not see the difference. If there is any way I can help you understand the issues, please let me know. Wait for the punchline. . . . . . . . . . You just need more experience with Object-Oriented Modelling. . . -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
From: Jan D. <ja...@ja...> - 2012-05-06 11:06:11
|
I have separated the chapters about modeling in the manual. I have also added an introduction making it clear that high-level modeling is very useful, but not intended for synthesis. http://www.myhdl.org/doc/dev/index.html And I have further refined the What MyHDL is Not page. http://myhdl.org/doku.php/whatitisnot#myhdl_is_not_only_for_implementation This should remove all confusions about the subject. If any pop up in the future I hope to be able to respond with a reference instead of endlessly repeating and rephrasing myself. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Jan C. <jan...@mu...> - 2012-05-06 08:23:54
|
On 06/05/12 06:35, Tom Dillon wrote: > "Experienced python developer", what is that? I am not sure what > that has to do with anything. True. An "Experienced python developer" is most likely someone who has gained some control over a machine at a very high level of abstraction. They may know little or nothing about the progressively differing layers of software beneath, supporting their code. Likely, the further layers of hardware concepts expressed below are completely out of sight. > There is nothing unnatural about MyHDL. Again, trying to draw > somebody into a meaningless discussion. I think he's angling to get a fish, a big one. A person wanting to learn to fish would need to be interested in understanding and clearly distinguishing the names of the tools, behaviour of fish, affects of tides, etc. Asking why angling is not an iPhone app that can be run, sat on a bench in the park while watching bowls is pointless. > MyHDL works fine. I fail to see a conflict at all. I'm struggling, but much too inexperienced with Python to suggest changing any of MyHDL. My hardware experience started with borrowing my mums breadboard and dressmaking pins, and using surplus germanium diodes and transistors. I still like to know the details of the fabric I'm using. Today I still have questions, for example: Do clockless gate arrays use standard SRAM blocks in an async wrapper, or are they async to a much lower level than this. It may seem pointless to ask, but it would help me to estimate the reliability of tools which translate RTL designs to use a clockless fabric. [1] But this extremely low-level interest might hinder my progress in using MyHDL in a similar way to having an insufficiently deep understanding of electronics. I'll need to work to get the balance right. It has been a hard struggle for me to get started with MyHDL, hopefully we can work out why, and make it easier for others in the future. Jan Coombs -- [1] www.achronix.com |
From: Tom D. <td...@di...> - 2012-05-06 05:35:55
|
On 05/05/2012 02:59 PM, Christopher Lozinski wrote: > In the page on Atomic and Compound Hardware modules, I model ports as > public instance variables. And internal signals as private instance > variables. It is how experienced python developers expect to see > things. It is natural for us to think of ports as instance variables. > Then you can get inheritance of ports for free as Hardware Modules are > subclassed. The port methods automatically remove Children and Parents > from the instance variable list. With this design, one would not have > to list all the ports repeatedly in the generator function for each > subclass. They just get inherited. Brings us a step closer towards > rich libraries of hardware modules that can be subclassed. Cool! "Experienced python developer", what is that? I am not sure what that has to do with anything. There is nothing unnatural about MyHDL. Again, trying to draw somebody into a meaningless discussion. > > But there is a problem, as that is not how MyHDL models ports. It is > not just an implementation problem. It is a conflict between how > experienced Python developers see the world, and the functional approach > favored by experienced hardware engineers. MyHDL works fine. I fail to see a conflict at all. |
From: Christopher L. <loz...@fr...> - 2012-05-05 20:00:13
|
Jan Decaluwe wrote: Coupling a sensitivity list to a module makes no sense. Understood. Here is the source of my confusion. The manual says: Hardware descriptions need to support the concepts of module instantiation and hierarchy. In MyHDL, an instance (of a hardware module) is recursively defined as being either a sequence of instances, or a generator. There are really two concepts here. One is a high level module which is recursively represented by a sequence of submodules. And the other is a leaf module which is represented by a generator. Ports can be associated with both high and low level modules The logic, generator and sensitivity lists are only associated with the leaf module. Or we could call them atomic and compound hardware modules. Did I get that correct? If so, thanks Jan for clearing that up for me. Accordingly I have updated split the Hardware Module class definition in two here: wiki.myhdlclass.com:8080/OOHDL But that still does not solve all my problems for these classes. Back to the Manual. The clock driver function ClkDriver() has a clock signal as its parameter. This is how a /port/ is modeled in MyHDL. In the page on Atomic and Compound Hardware modules, I model ports as public instance variables. And internal signals as private instance variables. It is how experienced python developers expect to see things. It is natural for us to think of ports as instance variables. Then you can get inheritance of ports for free as Hardware Modules are subclassed. The port methods automatically remove Children and Parents from the instance variable list. With this design, one would not have to list all the ports repeatedly in the generator function for each subclass. They just get inherited. Brings us a step closer towards rich libraries of hardware modules that can be subclassed. Cool! But there is a problem, as that is not how MyHDL models ports. It is not just an implementation problem. It is a conflict between how experienced Python developers see the world, and the functional approach favored by experienced hardware engineers. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
From: Uri N. <ur...@gm...> - 2012-05-05 19:42:24
|
At the time it took me a while to wrap my mind around the Queue example, since it introduces a different aspect of using MyHDL, which is more of a system architecture tool. IMO this merits a separate chapter, since one can drop the RTL/Synthesis requirements in favour of a different style of programming. I'd be happy to prepare some concrete examples for further discussion. On 2 May 2012 23:58, Christopher Felton <chr...@gm...> wrote: > On 5/2/2012 1:52 PM, Uri Nix wrote: > > IMHO it /is/ confusing, since the previous topics in the chapter are > > synthesis oriented. > > The manual under "Modeling techniques" currently progresses; structural, > RTL, High-level. Do you think a top-down versus bottom-up order would > be better? Someone *without* a HW design background may find; > High-level, RTL, structural order less confusing? Or, in your opinion, > do you think it needs to be a completely separate chapter? > > Regards, > Chris > > > > > I have had very good experience with MyHDL for system modelling, which > uses > > a different mindset than the FPGA direction. It is amazingly powerful, > > follows similar idioms as in SystemC with the ease of Python, and might > use > > some more mention. > > > > Cheers, > > Uri > > > > > > On 2 May 2012 18:55, Tom Dillon<td...@di...> wrote: > > > >> I think the manual is clear and it makes pretty good sense what can be > >> converted. > >> > >> One of the great things about MyHDL/Python is that as long as your code > at > >> the lowest level is RTL, then it will convert. > >> > >> You can use all the power of Python of top of that to make very high > level > >> structures. > >> > >> > >> > >> On 05/02/2012 10:30 AM, Jan Decaluwe wrote: > >> > >> On 04/27/2012 02:52 AM, Christopher Lozinski wrote: > >> > >> > >> The higher level approach is to model things as objects. There is a > >> queue example in the docs. This stuff blows my mind. How that can be > >> synthesized, what it means in terms of hardware functions, I really do > >> not yet understand. Sure the queue example is easily understandable to > >> a software engineer, but what does that look like when converted? > >> > >> I went back to the manual, to understand where so much confusion can > >> come from. > >> > >> But really, I don't see it. I think the manual is crystal clear. In the > >> chapter you refer to, it describes a number of modeling options that > >> MyHDL supports. When it talks about RTL, it explicitly makes the > connection > >> with synthesis. Then it moves on to high-level modeling - I think > >> it's obvious that there is no direct link with synthesis. > >> > >> To understand the link between conversion and synthesis, move to the > >> chapter about conversion. It explicitly states that the first goal > >> of conversion is synthesis, but also that the convertible subset > >> is more general than the synthesizable subset. And it describes > >> the convertible *subset*. > >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. > Discussions > >> will include endpoint security, mobile security and the latest in > malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> _______________________________________________ > >> myhdl-list mailing list > >> myh...@li... > >> https://lists.sourceforge.net/lists/listinfo/myhdl-list > >> > >> > > > > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > > > > > _______________________________________________ > > myhdl-list mailing list > > myh...@li... > > https://lists.sourceforge.net/lists/listinfo/myhdl-list > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Christopher L. <loz...@fr...> - 2012-05-05 16:29:05
|
Jan Decaluwe wrote: Coupling a sensitivity list to a module makes no sense. Understood. Here is the source of my confusion. The manual says: Hardware descriptions need to support the concepts of module instantiation and hierarchy. In MyHDL, an instance (of a hardware module) is recursively defined as being either a sequence of instances, or a generator. There are really two concepts here. One is a high level module which is recursively represented by a sequence of submodules. And the other is a leaf module which is represented by a generator. Ports can be associated with both high and low level modules The logic, generator and sensitivity lists are only associated with the leaf module. Or we could call them atomic and compound hardware modules. Did I get that correct? If so, thanks Jan for clearing that up for me. Accordingly I have updated split the Hardware Module class definition in two here: wiki.myhdlclass.com:8080/OOHDL But that still does not solve all my problems for these classes. Back to the Manual. The clock driver function ClkDriver() has a clock signal as its parameter. This is how a /port/ is modeled in MyHDL. In the page on Atomic and Compound Hardware modules, I model ports as public instance variables. And internal signals as private instance variables. It is how experienced python developers expect to see things. It is natural for us to think of ports as instance variables. Then you can get inheritance of ports for free as Hardware Modules are subclassed. The port methods automatically remove Children and Parents from the instance variable list. With this design, one would not have to list all the ports repeatedly in the generator function for each subclass. They just get inherited. Brings us a step closer towards rich libraries of hardware modules that can be subclassed. Cool! But there is a problem, as that is not how MyHDL models ports. It is not just an implementation problem. It is a conflict between how experienced Python developers see the world, and the functional approach favored by experienced hardware engineers. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
From: Norbo <Nor...@gm...> - 2012-05-05 15:35:53
|
Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton <chr...@gm...>: > On 5/5/12 4:00 AM, Norbo wrote: >> Am 05.05.2012, 06:49 Uhr, schrieb Christopher Felton >> <chr...@gm...>: >> >>> On 5/1/12 1:00 PM, Norbo wrote: >>>>> I was taking a look at your patch, your patch is not based on the >>>>> latest >>>>> 0.8-dev branch. There are enough changes that it doesn't auto import >>>>> to >>>>> the 0.8-dev branch. >>>>> >>>>> I don't know if the _doinit flag is actually needed? I believe the >>>>> conversion code can determine if the value should be written or not >>>>> without modifying the Signal or intbv objects. As your modified intbv >>>>> does, it can always create the initial value unless the Signal/intbv >>>>> init value is None. >>>> Yes this would be possible if the value (._val) of the intbv is set to >>>> None. >>>> But there are several things that raise, exceptions if the value is >>>> set >>>> to >>>> None. (Boundcheck, __getitem__, etc..) >>>> so i added the _doinit flag and set the (._val) to 0 (or to the min >>>> value >>>> if defined), and thereby avoided the error-prone changing of these >>>> functions which wouldnt work with the None value. >>> >>> Why do you need "None"? It would be my understanding that the >>> conversion process will always create the init values in the converted >>> code. You don't need the _doinit flag and you don't need None. >> >> My thought on this was that it may be usefull to have explicit controll >> on >> whether the initial values are written ot not. For example if a big ram >> is >> described >> and you don't need the initial values, the converted file would be >> filled >> up with a >> huge number of basically useless values. -> Or in the words of "import >> this" in python: >> Explicit is better than implicit >> > > To me this is *not* explicit, you don't have direct control over _doinit > you have implicit control if the initial values are generated or not > (which I have even forgotten what the control is). The idea of the controll was if you write: aList=[Signal(intbv(None)) for i in range(10) ] --> then the initial values are not written no matter what. aList=[Signal(intbv(i)) for i in range(10) ] --> the initial values are written in verilog and vhdl when there is no combinatorical assignment ("as a path of least resistance right now") > I hear the argument for the large inclusive of init values. And with > FPGA embedded memories and ASIC available ROM/RAM growing these could be > long init lists. But I am not totally convinced the inconvenience of > long inits are bad because it breaks the earlier argument "MyHDL to > Verilog/VHDL mismatch". I didn't get that. > This might be the path of least resistance right now. But I don't think > there is a reason that the converted couldn't generate > > reg [7:0] out1 = 8'd0; > reg [7:0] aListSig [0:10-1]; > // initial blocks ... > @always_comb begin nice: @always_comb begin a myhdl artefact ;) > aListSig[3] = in_data > out1 = aListSig[3] > end > > This is only an issue in Verilog and not VHDL. Maybe a behavioral > statement should be written instead of a continuous assignment. To me > it appears a lot of complexity would be added which could be avoided by > simply converting the Verilog similar to how the VHDL is converted. Damm, i overlooked that. The synthesis of the follwing is succesfully. .... reg [7:0] aListSig [0:10-1]; initial begin : INIT_aListSig aListSig[0]=0; aListSig[1]=1; aListSig[2]=2; aListSig[3]=3; aListSig[4]=4; aListSig[5]=5; aListSig[6]=6; aListSig[7]=7; aListSig[8]=8; aListSig[9]=9; end always @(in_data,aListSig[3]) begin // or always @* begin aListSig[3] = in_data; out1 = aListSig[3]; end summary: this means the "assign" in the verilog conversion needs to be replaced (by always @* begin ... end) and also if it gets declared as "wire" would need to be defined as "reg". another point is that i think it is a good thing to have all the variables by default not to be initialized with values in the converted code. Initialisation should only occour if you really want to describe (pre-init RAM) or ROM. because for example in VHDL all the std_logic signals are set at startup of a vhdl simulation to the value 'U' (stands for uninitialized) if there is no other initial value given. After the reset all values should have changed from this 'U' to something usefull. This allows you to see imidiatly if you have messed up or missed something in the reset code. If all values are set by default to something usefull you can easyl overlook some resets, you couldnt even check it with a testbench at startup if the reset is done properly, when the initial value has the same value as the reset value you have forgotten in the code. The point is, by default no initial value should be written in the converted code, only when you need it explicit to describe something. Maybe a default None value in the intbv? grettings Norbo |
From: Christopher F. <chr...@gm...> - 2012-05-05 10:41:27
|
On 5/5/12 4:00 AM, Norbo wrote: > Am 05.05.2012, 06:49 Uhr, schrieb Christopher Felton > <chr...@gm...>: > >> On 5/1/12 1:00 PM, Norbo wrote: >>>> I was taking a look at your patch, your patch is not based on the >>>> latest >>>> 0.8-dev branch. There are enough changes that it doesn't auto import to >>>> the 0.8-dev branch. >>>> >>>> I don't know if the _doinit flag is actually needed? I believe the >>>> conversion code can determine if the value should be written or not >>>> without modifying the Signal or intbv objects. As your modified intbv >>>> does, it can always create the initial value unless the Signal/intbv >>>> init value is None. >>> Yes this would be possible if the value (._val) of the intbv is set to >>> None. >>> But there are several things that raise, exceptions if the value is set >>> to >>> None. (Boundcheck, __getitem__, etc..) >>> so i added the _doinit flag and set the (._val) to 0 (or to the min >>> value >>> if defined), and thereby avoided the error-prone changing of these >>> functions which wouldnt work with the None value. >> >> Why do you need "None"? It would be my understanding that the >> conversion process will always create the init values in the converted >> code. You don't need the _doinit flag and you don't need None. > > My thought on this was that it may be usefull to have explicit controll on > whether the initial values are written ot not. For example if a big ram is > described > and you don't need the initial values, the converted file would be filled > up with a > huge number of basically useless values. -> Or in the words of "import > this" in python: > Explicit is better than implicit > To me this is *not* explicit, you don't have direct control over _doinit you have implicit control if the initial values are generated or not (which I have even forgotten what the control is). There are a set of rules that decide for you if initial values are to be generated or not. I would think explicit would be the use of None, you are directly indicating no init values. I hear the argument for the large inclusive of init values. And with FPGA embedded memories and ASIC available ROM/RAM growing these could be long init lists. But I am not totally convinced the inconvenience of long inits are bad because it breaks the earlier argument "MyHDL to Verilog/VHDL mismatch". I think the question; "Is the absence of initial values detrimental because it causes a co-simulation mismatch"? If it decided this is a bad thing then I think we need to live with the long init list or support the None initial values on the MyHDL side. > >>>> Lastly, the changes do break the unit-tests. As mentioned, the patch >>>> didn't auto import. I believe I got all the changes manually but >>>> possibly something was missed in the manual addition of the changes. I >>>> think removing the _doinit will fix the failures (but I didn't really >>>> look that closely). >>> The now appended patch file is based on the 0.8-dev branch, the core >>> test >>> passes but until now i wasnt able to >>> run the conversion tests. >>> >>> The initial values in this patch for the array signal are now written in >>> the following casess: for VHDL and Verilog: >>> >>> 1. reading it in a combinatorical process --- initial values are written >>> 2. reading it synchron (clocked) --- initial values are >>> written (could be used to describe inited ROM) >>> 3. reading it synchron (clocked) and writing it synchron --- initial >>> values are written (could be used to describe pre-inited RAM, or even >>> pre-inited dual ported RAM) >>> 4. reading it synchron (clocked) and writing it in a combinatorical >>> process --- initial values are not ! written (because it is >>> syntactically >>> not possible in verilog) >>> 5. reading and writing in a combinatorical process --- initial >>> values are not ! written (because it is syntactically not possible in >>> verilog) >>> >>> >>> would this be acceptable/desirable? >> >> Lost me. I don't understand why it matters how the Signal variable is >> used to determine if the initial value should be written. As mentioned, >> shouldn't the initial values always be written? > > For example for the case 5. "reading and writing in a combinatorical > process" > > assign aListSig[3] = in_data; > assign out1 = aListSig[3]; > > endmodule > This might be the path of least resistance right now. But I don't think there is a reason that the converted couldn't generate reg [7:0] out1 = 8'd0; reg [7:0] aListSig [0:10-1]; // initial blocks ... @always_comb begin aListSig[3] = in_data out1 = aListSig[3] end This is only an issue in Verilog and not VHDL. Maybe a behavioral statement should be written instead of a continuous assignment. To me it appears a lot of complexity would be added which could be avoided by simply converting the Verilog similar to how the VHDL is converted. Regards, Chris |
From: Norbo <Nor...@gm...> - 2012-05-05 09:00:59
|
Am 05.05.2012, 06:49 Uhr, schrieb Christopher Felton <chr...@gm...>: > On 5/1/12 1:00 PM, Norbo wrote: >>> I was taking a look at your patch, your patch is not based on the >>> latest >>> 0.8-dev branch. There are enough changes that it doesn't auto import to >>> the 0.8-dev branch. >>> >>> I don't know if the _doinit flag is actually needed? I believe the >>> conversion code can determine if the value should be written or not >>> without modifying the Signal or intbv objects. As your modified intbv >>> does, it can always create the initial value unless the Signal/intbv >>> init value is None. >> Yes this would be possible if the value (._val) of the intbv is set to >> None. >> But there are several things that raise, exceptions if the value is set >> to >> None. (Boundcheck, __getitem__, etc..) >> so i added the _doinit flag and set the (._val) to 0 (or to the min >> value >> if defined), and thereby avoided the error-prone changing of these >> functions which wouldnt work with the None value. > > Why do you need "None"? It would be my understanding that the > conversion process will always create the init values in the converted > code. You don't need the _doinit flag and you don't need None. My thought on this was that it may be usefull to have explicit controll on whether the initial values are written ot not. For example if a big ram is described and you don't need the initial values, the converted file would be filled up with a huge number of basically useless values. -> Or in the words of "import this" in python: Explicit is better than implicit >>> Lastly, the changes do break the unit-tests. As mentioned, the patch >>> didn't auto import. I believe I got all the changes manually but >>> possibly something was missed in the manual addition of the changes. I >>> think removing the _doinit will fix the failures (but I didn't really >>> look that closely). >> The now appended patch file is based on the 0.8-dev branch, the core >> test >> passes but until now i wasnt able to >> run the conversion tests. >> >> The initial values in this patch for the array signal are now written in >> the following casess: for VHDL and Verilog: >> >> 1. reading it in a combinatorical process --- initial values are written >> 2. reading it synchron (clocked) --- initial values are >> written (could be used to describe inited ROM) >> 3. reading it synchron (clocked) and writing it synchron --- initial >> values are written (could be used to describe pre-inited RAM, or even >> pre-inited dual ported RAM) >> 4. reading it synchron (clocked) and writing it in a combinatorical >> process --- initial values are not ! written (because it is >> syntactically >> not possible in verilog) >> 5. reading and writing in a combinatorical process --- initial >> values are not ! written (because it is syntactically not possible in >> verilog) >> >> >> would this be acceptable/desirable? > > Lost me. I don't understand why it matters how the Signal variable is > used to determine if the initial value should be written. As mentioned, > shouldn't the initial values always be written? For example for the case 5. "reading and writing in a combinatorical process" a example in for verilog could look like this: Myhdl code: ------------------------------------------------------ def TOP(out1,in_data): aListSig=[Signal(intbv(i)[8:]) for i in range(10)] @always_comb def comb_logic(): out1.next=aListSig[3] @always_comb def comb2_logic(): aListSig[3].next=in_data return comb2_logic ,comb_log Verilog code: --------------------------------------------------- module TOP ( out1, in_data ); output [7:0] out1; wire [7:0] out1; input [7:0] in_data; wire [7:0] aListSig [0:10-1]; //hypothetical inital block would be placed here //but if a initial block is placed here //the code is no longer valid because "aListSig" is defined as wire. //but it needs to be defined as wire because somewhere in the code someone //writes to the variable "aListSig" in combinatorically assignment. //therfore the initial signal cant be written in the case when a combinatoricall //assignment to the variable "aListSig" takes place somewhere in the code. //Anyway a initialvalue is not needed when a combinatorical assignment to the variable "aListSig" is made, //because the "aListSig" then gets its value imidiatley at the beginning of the simulation by this //assignment.(or after some delta cycles with zero delay). //In verilog the complete signal array is defined as wire, so if only the variable //with index 3 is (as below aListSig[3]) used combinatorically then the complete array //needs to be defined as "wire" and therfore no initialvalues are possible assign aListSig[3] = in_data; assign out1 = aListSig[3]; endmodule greetings Norbo |
From: Christopher F. <chr...@gm...> - 2012-05-05 04:49:26
|
On 5/1/12 1:00 PM, Norbo wrote: >> I was taking a look at your patch, your patch is not based on the latest >> 0.8-dev branch. There are enough changes that it doesn't auto import to >> the 0.8-dev branch. >> >> I don't know if the _doinit flag is actually needed? I believe the >> conversion code can determine if the value should be written or not >> without modifying the Signal or intbv objects. As your modified intbv >> does, it can always create the initial value unless the Signal/intbv >> init value is None. > Yes this would be possible if the value (._val) of the intbv is set to > None. > But there are several things that raise, exceptions if the value is set to > None. (Boundcheck, __getitem__, etc..) > so i added the _doinit flag and set the (._val) to 0 (or to the min value > if defined), and thereby avoided the error-prone changing of these > functions which wouldnt work with the None value. Why do you need "None"? It would be my understanding that the conversion process will always create the init values in the converted code. You don't need the _doinit flag and you don't need None. > > >> Lastly, the changes do break the unit-tests. As mentioned, the patch >> didn't auto import. I believe I got all the changes manually but >> possibly something was missed in the manual addition of the changes. I >> think removing the _doinit will fix the failures (but I didn't really >> look that closely). > The now appended patch file is based on the 0.8-dev branch, the core test > passes but until now i wasnt able to > run the conversion tests. > > The initial values in this patch for the array signal are now written in > the following casess: for VHDL and Verilog: > > 1. reading it in a combinatorical process --- initial values are written > 2. reading it synchron (clocked) --- initial values are > written (could be used to describe inited ROM) > 3. reading it synchron (clocked) and writing it synchron --- initial > values are written (could be used to describe pre-inited RAM, or even > pre-inited dual ported RAM) > 4. reading it synchron (clocked) and writing it in a combinatorical > process --- initial values are not ! written (because it is syntactically > not possible in verilog) > 5. reading and writing in a combinatorical process --- initial > values are not ! written (because it is syntactically not possible in > verilog) > > > would this be acceptable/desirable? Lost me. I don't understand why it matters how the Signal variable is used to determine if the initial value should be written. As mentioned, shouldn't the initial values always be written? Note: these are only simulation and or "special" synthesis mapping initial values. Reset values are still reset values. The only thing that needs to be determined is if the initial block needs to be added. That should simply be based on list of signals or not. Regards, Chris |
From: Christopher F. <chr...@gm...> - 2012-05-05 01:34:36
|
On 5/4/12 8:34 AM, Tom Dillon wrote: > It seems to me we are just being drawn into ridiculous conversations. > > I am more productive with MyHDL/Python and Verilog/VHDL that with only > straight Verilog/VHDL, so I use it. > > Particularly for test benches and re-usable IP modules. I would suggest > to anyone who wants to learn the benefits of MyHDL, that begin with test > benches. It is a great way to increase your test coverage and do it in > far less time than with an HDL test bench. > > After some experience is gained using MyHDL, your comments about what > can and can't be done with it might be more useful to the list. > > Right now debating whether or not you can use classes is absurd. > > +1 Tom has many good point here! |
From: garyr <ga...@fi...> - 2012-05-04 18:10:22
|
----- Original Message ----- From: "Tom Dillon" <td...@di...> To: <myh...@li...> Sent: Friday, May 04, 2012 7:40 AM Subject: Re: [myhdl-list] How to make MyHDL Object-Oriented > Hardly an attack. > > I fail to see the issue to be hard on. Amen to that. Crackpots shouldn't expect sympathy. |
From: Tom D. <td...@di...> - 2012-05-04 14:40:50
|
Hardly an attack. I fail to see the issue to be hard on. On 05/04/2012 09:27 AM, Christopher Lozinski wrote: > On 5/4/12 8:34 AM, Tom Dillon wrote: >> Right now debating whether or not you can use classes is absurd. > Thank you for being sensitive to my concerns. And yes this time I am > being sarcastic. > > I did not say you could not use classes. I said that there are specific > representational issues in MyHDL which conflict with my world view. > You completely failed to address the specific concern I have, instead > resorting to attacking my experience level. > > Be hard on issues, soft on people. You ignored the issue, and were > hard on me. I am not surprised by the response, but I am glad to have > figured out the specific technical problem I have with MyHDL. My > apologies if I had to bounce around to figure it out. > > Regards > Chris > > > > > |
From: Jan D. <ja...@ja...> - 2012-05-04 14:35:32
|
On 05/04/2012 02:18 PM, Christopher Lozinski wrote: > On 5/4/12 5:04 AM, Jan Decaluwe wrote: >> On 05/04/2012 01:45 AM, Christopher Lozinski wrote: >>> Thanks enormously to Andy Stone for pointing out that MyHDL, >>> while in Python is not object-oriented. There is no hardware >>> module class, just a generator, and decorator which are >>> functional approaches. >> How can you even say this, > > Actually the wiki says it. > > http://www.myhdl.org/doc/0.6/manual/intro.html In MyHDL, classic > functions are used to model hardware modules. In particular, the > parameter list is used to define the interface. Point taken. However, I am not sure how to change that for full generality in an introductory chapter, without being overly confusing to new users. However: it is true that I think that the approach based on functions is the best choice for a first step. It is correct that I wanted to make things as simple as possible for hardware designers, especially Verilog designers, with no exposure to object-orientation in their HDLs. It is also true that conversion was written with this choice in mind in the first place. > I would rather see objects being used to model hardware modules. In > particular the instance variables should be used to model the > interface. (and internal signals). You can do that today. > Here is another one. > http://www.myhdl.org/doc/current/manual/modeling.html > > In MyHDL, an instance is recursively defined as being either a > sequence of instances, or a generator. Hierarchy is modeled by > defining instances in a higher-level function, and returning them. > > That does sound to me like a functional approach. I would rather see > hardware modules defined "in a higher level object" a module with > parent and child nodes. I would expect a hierarchy of chip modules, > each of which points to its children and parents. > > Then let me quote others: Andrew Stone said this is what he > expected: > > In fact, what I thought myHDL was going to let me do is create > classes that define blocks of logic at the RTL level (synthesizable), > perhaps with inputs and output "Signals" as variables passed in the > constructor and then by instantiating those classes I'd be in effect > plunking down copies of that logic in the FPGA (or within larger > logic blocks by instantiating these within the constructor of another > class). 4 years ago I did not ever figure out how to do this... I > don't think anything wrapped in a class was synthesizable back then. > But maybe that has changed now; I haven't tried using classes since. > > And yes, Dillon wrote that he does this, but I think we will find the > details of how he does it are different than at least what I would > expect. In particular MyHDL does not pass variables into the object > constructor, it passes them into the generator. There are no parent > or child links. > > >> when the manual has a section about object-oriented modeling, which >> has a Queue class, which you have just been struggling with? > > If I recall correctly, the Queue class is not inside a @always, > @instance, or @always_comb, so it is not synthesizable. While MyHDL > is quite general, it is only the synthesizable stuff I am interested > in. Then you should clearly say so in your communication. Otherwise your statements are totally confusing to people, including myself, who are equally interested, or even more so, in other aspects of MyHDL. > Jan Decaluwe wrote: > >> Perhaps this stuff really is too hard for the "general python >> developer", though I > >> still don't understand why. > > Because it does not fit the way we see the world. Different people > have different world views. I am doing my best to explain my world > view. In particular one of my concepts is that every real world thing > should be represented by a class. So flip flops, adders, multipliers > should each be represented by a class. And then I mostly want the > documentation to be a listing of the classes, representing physical > objects, available to me to work with. And yes the existing MyHDL > documentation would also be useful. But that is a low-level view that I'm not interested in at all! I don't care about models for flip-flops, adders, multipliers etc - I have synthesis tools that infer them efficiently and by the dozen from the behavior of my code, without requiring my attention. (Of course, I know about them very well, to judge the quality of the synthesis result in the back end). But if you insist - you can do that today, and then work at the net list level in MyHDL connecting them. Just add some print method to each class that prints out the instance representation in some technology in Verilog and you are done - you have a netlist generator. No conversion needed, and no synthesis for that matter. > I now understand it is a hugely different view from the prevailing > view on this mailing list. And that is why we keep clashing. It is > why I am just not able to 'get' MyHDL. Because we are operating under > two different world views. And I don't buy that. More important than the software technique is the abstraction level at which you are working. Your object-oriented approach is just a low-level approach in disguise - not interested. You don't get MyHDL because you don't yet get the basics of HDL-based design. Unfortunately, I don't see an alternative of getting your hands dirty and building up experience yourself, painstakingly. Trying out Verilog, as you announced, may actually be a wise step. If you are happy with it, all the better. But if you are not, I trust the discussion will become much easier. Look at it this way. Synopsys has become very rich by selling great synthesis tools. But after all these years, I am still not aware of a reference work that I can recommend to really learn what synthesis can do. Don't expect some poor open-source guys to fill in that gap. > > -- Regards Christopher Lozinski > > Check out my iPhone apps TextFaster and EmailFaster > http://textfaster.com > > Expect a paradigm shift. http://MyHDL.org > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ myhdl-list mailing > list myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Christopher L. <loz...@fr...> - 2012-05-04 14:27:18
|
On 5/4/12 8:34 AM, Tom Dillon wrote: > Right now debating whether or not you can use classes is absurd. Thank you for being sensitive to my concerns. And yes this time I am being sarcastic. I did not say you could not use classes. I said that there are specific representational issues in MyHDL which conflict with my world view. You completely failed to address the specific concern I have, instead resorting to attacking my experience level. Be hard on issues, soft on people. You ignored the issue, and were hard on me. I am not surprised by the response, but I am glad to have figured out the specific technical problem I have with MyHDL. My apologies if I had to bounce around to figure it out. Regards Chris -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |