|
From: Alan M. G. <alm...@gm...> - 2016-04-07 22:15:24
|
On Thu, Mar 24, 2016 at 5:44 AM, Larry Doolittle <ldo...@re...> wrote: > Friends - > > On Wed, Mar 23, 2016 at 09:23:41PM +0000, Jonathan David wrote: > > I would expect that the module level features (ie RTL features like > these ) would be farther along than the class and package related > features. But I haven't installed icarus for a while, so can't really > comment on the present state. > > I looked up what the state of always_ff, always_latch, and always_comb > are in Icarus git master. > > They are present and accounted for as language-level-specific keywords > in lexor_keyword.gperf and parse.y. But parse.y never uses them in > in the grammar. > > Adding them to the grammar would be easy -- even I could do that. > But then Icarus would need new enum values for ivl_process_type_e, > and handle their semantics correctly. This has to be done without > breaking the old "always" semantics. > In particular, always_comb is not precisely the same as always@*; always_comb executes its contents at startup immediately, then blocks on sensitivity list. So instead of always@* begin foo; bar; end, it's more like always begin foo; bar; @*; end This hack is because constant wires and parameters might not trigger @*, leading to an RTL-vs-gate mismatch during simulation startup if you use always@*. As I understand it, always_ff and always_latch behave exactly the same as always, but an implementation is supposed to warn if it will not be inferred as a ff or latch. Whether actual tools actually warn, and whether those warnings will get glossed over in practice when you're synthesizing a 100k gate product with not the best coding style, is a separate question. Personally, I'd prefer a flag somewhere that indicates that an always_ff/always_latch not being inferrable to ff/latch should be thrown as an error rather than a warning. > > Good thing we have ivtest! > > - Larry > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |