Thread: [myhdl-list] A Reviewers Thoughts ...
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Christopher F. <chr...@gm...> - 2011-07-08 04:55:24
|
I have stumbled upon this presentation a couple times; http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf. The last slide is interesting, it is the brief summary of the author's concluding strengths and weaknesses of MyHDL. Strengths ----------- * The power of Python * Supporting Libraries * Flexibility * Fast accurate functional simulations Weaknesses ------------ * Flat Conversion * Limited Datatypes * Manual Process I am surprised to see the "Flat Conversion" protested frequently. I have not found this to be a weakness of any kind. Have others found this to be a weakness? Just curious, Chris |
|
From: Angel E. <ang...@gm...> - 2011-07-08 05:41:45
|
On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton <chr...@gm...> wrote: > I have stumbled upon this presentation a couple times; > > http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf. > > The last slide is interesting, it is the brief summary of the author's > concluding strengths and weaknesses of MyHDL. > > Strengths > ----------- > * The power of Python > * Supporting Libraries > * Flexibility > > * Fast accurate functional simulations > > Weaknesses > ------------ > * Flat Conversion > > * Limited Datatypes > > * Manual Process > > > I am surprised to see the "Flat Conversion" protested frequently. I > have not found this to be a weakness of any kind. Have others found > this to be a weakness? Well, I am definitely not a power user of MyHDL, but I recently attended a training course for Xilinx tools and one thing that we learned is that it is possible to tell the synthesizer to "keep the hierarchy" for a given (or all) module(s). Apparently this can lead to more predictable synthesis. Also this makes sure that the module interface signals are not lost during the synthesis/traslate/map process, which makes it easier to add probes (e.g. a ChipScope) that peek on those signals. Angel |
|
From: Christopher F. <chr...@gm...> - 2011-07-10 18:55:01
|
On 7/8/11 12:41 AM, Angel Ezquerra wrote: > On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton > <chr...@gm...> wrote: >> I have stumbled upon this presentation a couple times; >> >> http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf. >> >> The last slide is interesting, it is the brief summary of the author's >> concluding strengths and weaknesses of MyHDL. >> >> Strengths >> ----------- >> * The power of Python >> * Supporting Libraries >> * Flexibility >> >> * Fast accurate functional simulations >> >> Weaknesses >> ------------ >> * Flat Conversion >> >> * Limited Datatypes >> >> * Manual Process >> >> >> I am surprised to see the "Flat Conversion" protested frequently. I >> have not found this to be a weakness of any kind. Have others found >> this to be a weakness? > > Well, I am definitely not a power user of MyHDL, but I recently > attended a training course for Xilinx tools and one thing that we > learned is that it is possible to tell the synthesizer to "keep the > hierarchy" for a given (or all) module(s). Apparently this can lead to > more predictable synthesis. Also this makes sure that the module > interface signals are not lost during the synthesis/traslate/map > process, which makes it easier to add probes (e.g. a ChipScope) that > peek on those signals. > > Angel > Thanks for for the comments! I am curious because this "item" seems to appear from time to time. The following is my rebuttal to the case you mentioned. At least so far, the main argument is that minimal signal/variable/net obfuscation is desired for downstream debugging. In other-words the Designers want to identify "things" from the original design entry in the targeted implementation (in a FPGA the synthesized-P&R circuit). To me this is really a bigger question. What is the most efficient verification (debug) method. I think others would agree, in MyHDL with all the power of Python, building a robust verification environment is reasonable. This would minimize the requirement to do in system debugging. The need to identify a net in a post P&R circuit to attach debug probes shouldn't be required (chip-scope or signal-tap). Or at least, the in-circuit "probing", avoided because it is a more difficult method to debug. Not because of net obfusction but because less is available at run time: less visibility, limited number of probes, can be harder to inject error scenarios, etc. In some cases (in my opinion they are rare) you may want to do in system debugging / verification. In this scenario, it is usually because some interface is poorly defined and you need to see how it is acting. But in my mind, this is something that is designed in (DFM approach) and not an after-thought. Meaning that you don't realize you need to attach probes until it doesn't work and don't want to re-P&R. I guess, in my mind this isn't an issue of flat design versus a preserved hierarchy design. But rather the difference between the best verification/debug approach Regards, Chris |
|
From: Angel E. M. <ang...@gm...> - 2011-07-11 08:29:42
|
On Sun, Jul 10, 2011 at 8:54 PM, Christopher Felton <chr...@gm...> wrote: > On 7/8/11 12:41 AM, Angel Ezquerra wrote: >> On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton >> <chr...@gm...> wrote: >>> I have stumbled upon this presentation a couple times; >>> >>> http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf. >>> >>> The last slide is interesting, it is the brief summary of the author's >>> concluding strengths and weaknesses of MyHDL. >>> >>> Strengths >>> ----------- >>> * The power of Python >>> * Supporting Libraries >>> * Flexibility >>> >>> * Fast accurate functional simulations >>> >>> Weaknesses >>> ------------ >>> * Flat Conversion >>> >>> * Limited Datatypes >>> >>> * Manual Process >>> >>> >>> I am surprised to see the "Flat Conversion" protested frequently. I >>> have not found this to be a weakness of any kind. Have others found >>> this to be a weakness? >> >> Well, I am definitely not a power user of MyHDL, but I recently >> attended a training course for Xilinx tools and one thing that we >> learned is that it is possible to tell the synthesizer to "keep the >> hierarchy" for a given (or all) module(s). Apparently this can lead to >> more predictable synthesis. Also this makes sure that the module >> interface signals are not lost during the synthesis/traslate/map >> process, which makes it easier to add probes (e.g. a ChipScope) that >> peek on those signals. >> >> Angel >> > > Thanks for for the comments! I am curious because this "item" seems to > appear from time to time. The following is my rebuttal to the case you > mentioned. > > At least so far, the main argument is that minimal signal/variable/net > obfuscation is desired for downstream debugging. In other-words the > Designers want to identify "things" from the original design entry in > the targeted implementation (in a FPGA the synthesized-P&R circuit). To > me this is really a bigger question. What is the most efficient > verification (debug) method. > > I think others would agree, in MyHDL with all the power of Python, > building a robust verification environment is reasonable. This would > minimize the requirement to do in system debugging. The need to > identify a net in a post P&R circuit to attach debug probes shouldn't be > required (chip-scope or signal-tap). Or at least, the in-circuit > "probing", avoided because it is a more difficult method to debug. Not > because of net obfusction but because less is available at run time: > less visibility, limited number of probes, can be harder to inject error > scenarios, etc. > > In some cases (in my opinion they are rare) you may want to do in system > debugging / verification. In this scenario, it is usually because some > interface is poorly defined and you need to see how it is acting. But > in my mind, this is something that is designed in (DFM approach) and not > an after-thought. Meaning that you don't realize you need to attach > probes until it doesn't work and don't want to re-P&R. > > I guess, in my mind this isn't an issue of flat design versus a > preserved hierarchy design. But rather the difference between the best > verification/debug approach > > Regards, > Chris Chris, this is certainly a very good point, but even if rare, there are still occasions in which even with a very robust verification system you may still need to do "downstream debugging". For example, we work with systems whose inputs are non deterministic. It is quite hard to create a reasonable number of test vectors that cover all scenarios. So sometimes you must peek at the system as it is running in order to understand why it is not working as expected. Angel |
|
From: Christopher F. <chr...@gm...> - 2011-07-17 17:30:45
|
On 7/11/11 3:29 AM, Angel Ezquerra Moreu wrote: > On Sun, Jul 10, 2011 at 8:54 PM, Christopher Felton > <chr...@gm...> wrote: >> On 7/8/11 12:41 AM, Angel Ezquerra wrote: >>> On Fri, Jul 8, 2011 at 6:54 AM, Christopher Felton >>> <chr...@gm...> wrote: >>>> I have stumbled upon this presentation a couple times; >>>> >>>> http://seti.berkeley.edu/sites/default/files/gordon_casper_myhdl_presentation.pdf. >>>> >>>> The last slide is interesting, it is the brief summary of the author's >>>> concluding strengths and weaknesses of MyHDL. >>>> >>>> Strengths >>>> ----------- >>>> * The power of Python >>>> * Supporting Libraries >>>> * Flexibility >>>> >>>> * Fast accurate functional simulations >>>> >>>> Weaknesses >>>> ------------ >>>> * Flat Conversion >>>> >>>> * Limited Datatypes >>>> >>>> * Manual Process >>>> >>>> >>>> I am surprised to see the "Flat Conversion" protested frequently. I >>>> have not found this to be a weakness of any kind. Have others found >>>> this to be a weakness? >>> >>> Well, I am definitely not a power user of MyHDL, but I recently >>> attended a training course for Xilinx tools and one thing that we >>> learned is that it is possible to tell the synthesizer to "keep the >>> hierarchy" for a given (or all) module(s). Apparently this can lead to >>> more predictable synthesis. Also this makes sure that the module >>> interface signals are not lost during the synthesis/traslate/map >>> process, which makes it easier to add probes (e.g. a ChipScope) that >>> peek on those signals. >>> >>> Angel >>> >> >> Thanks for for the comments! I am curious because this "item" seems to >> appear from time to time. The following is my rebuttal to the case you >> mentioned. >> >> At least so far, the main argument is that minimal signal/variable/net >> obfuscation is desired for downstream debugging. In other-words the >> Designers want to identify "things" from the original design entry in >> the targeted implementation (in a FPGA the synthesized-P&R circuit). To >> me this is really a bigger question. What is the most efficient >> verification (debug) method. >> >> I think others would agree, in MyHDL with all the power of Python, >> building a robust verification environment is reasonable. This would >> minimize the requirement to do in system debugging. The need to >> identify a net in a post P&R circuit to attach debug probes shouldn't be >> required (chip-scope or signal-tap). Or at least, the in-circuit >> "probing", avoided because it is a more difficult method to debug. Not >> because of net obfusction but because less is available at run time: >> less visibility, limited number of probes, can be harder to inject error >> scenarios, etc. >> >> In some cases (in my opinion they are rare) you may want to do in system >> debugging / verification. In this scenario, it is usually because some >> interface is poorly defined and you need to see how it is acting. But >> in my mind, this is something that is designed in (DFM approach) and not >> an after-thought. Meaning that you don't realize you need to attach >> probes until it doesn't work and don't want to re-P&R. >> >> I guess, in my mind this isn't an issue of flat design versus a >> preserved hierarchy design. But rather the difference between the best >> verification/debug approach >> >> Regards, >> Chris > > Chris, > > this is certainly a very good point, but even if rare, there are still > occasions in which even with a very robust verification system you may > still need to do "downstream debugging". > > For example, we work with systems whose inputs are non deterministic. > It is quite hard to create a reasonable number of test vectors that > cover all scenarios. So sometimes you must peek at the system as it is > running in order to understand why it is not working as expected. > > Angel I think my point was missed, it wasn't the fact that downstream / in-system debugging is beneficial or not but rather that the need for *unexpected* downstream debugging can be adverted. And how this relates to the generated "flat" file. Again, I am not trying to argue if in-system debugging is useful or not but instead arguing that including in-system debugging in the design is a better approach. Which removes the need to add probes to the post-P&R. And such, minimizes the argument that the flat file conversion is a negative. Chris |
|
From: Angel E. <ang...@gm...> - 2011-07-25 08:28:09
|
On Fri, Jul 22, 2011 at 10:36 PM, Christopher Felton <chr...@gm...> wrote: > <snip> >> >> Again, I am not trying to argue if in-system debugging is useful or not >> but instead arguing that including in-system debugging in the design is >> a better approach. Which removes the need to add probes to the >> post-P&R. And such, minimizes the argument that the flat file >> conversion is a negative. >> >> >> Chris >> > > Thinking about this a little more, one possible downside, I can think > of, is how a flat hierarchy might effect floor-planning. Some FPGA and > IC designs might want (require) floor-planning*. But I am not really > sure of this either because the blocks are named blocks and the tools > might be able to handle this as well. > > Chris > > * Floor-planning is a "flow" to guide the P&R (place-and-route) tools by > defining physical constraints. Often this is done by indicating a > region for placement of a block, often a major block. Actually that is one of the things taht I meant to say on my first email on this thread, when I said that keeping the hierarchy "can lead to more predictable synthesis", but I should have said floor planning rather than synthesis. Angel |
|
From: Christopher F. <chr...@gm...> - 2011-07-25 11:21:20
|
On 7/25/11 3:28 AM, Angel Ezquerra wrote: > On Fri, Jul 22, 2011 at 10:36 PM, Christopher Felton > <chr...@gm...> wrote: >> <snip> >>> >>> Again, I am not trying to argue if in-system debugging is useful or not >>> but instead arguing that including in-system debugging in the design is >>> a better approach. Which removes the need to add probes to the >>> post-P&R. And such, minimizes the argument that the flat file >>> conversion is a negative. >>> >>> >>> Chris >>> >> >> Thinking about this a little more, one possible downside, I can think >> of, is how a flat hierarchy might effect floor-planning. Some FPGA and >> IC designs might want (require) floor-planning*. But I am not really >> sure of this either because the blocks are named blocks and the tools >> might be able to handle this as well. >> >> Chris >> >> * Floor-planning is a "flow" to guide the P&R (place-and-route) tools by >> defining physical constraints. Often this is done by indicating a >> region for placement of a block, often a major block. > > Actually that is one of the things taht I meant to say on my first > email on this thread, when I said that keeping the hierarchy "can lead > to more predictable synthesis", but I should have said floor planning > rather than synthesis. > > Angel > I should have said *manual* floor-planning. I my experience I don't think it effects auto P&R, much. Chris |
|
From: Christopher F. <chr...@gm...> - 2011-07-22 20:40:19
|
<snip> > > Again, I am not trying to argue if in-system debugging is useful or not > but instead arguing that including in-system debugging in the design is > a better approach. Which removes the need to add probes to the > post-P&R. And such, minimizes the argument that the flat file > conversion is a negative. > > > Chris > Thinking about this a little more, one possible downside, I can think of, is how a flat hierarchy might effect floor-planning. Some FPGA and IC designs might want (require) floor-planning*. But I am not really sure of this either because the blocks are named blocks and the tools might be able to handle this as well. Chris * Floor-planning is a "flow" to guide the P&R (place-and-route) tools by defining physical constraints. Often this is done by indicating a region for placement of a block, often a major block. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X