<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
  <title>Ruby-VPI project</title>
  <link>http://snk.rubyforge.org/web/</link>
  <description>&lt;p&gt;News feed for &lt;a href=&quot;http://ruby-vpi.rubyforge.org&quot;&gt;the Ruby-&lt;span class=&quot;caps&quot;&gt;VPI&lt;/span&gt; project&lt;/a&gt;&lt;/p&gt;</description>
  <language>en-us</language>
  <lastBuildDate>Sat, 09 May 2009 10:00:25 -0700</lastBuildDate>
  <generator>Rassmalog 12.0.1</generator>
    <item>
      <title>Ruby-VPI 21.1.0</title>
      <link>http://snk.rubyforge.org/web/2008-08-02-ruby-vpi-21-1-0.html</link>
      <guid>http://snk.rubyforge.org/web/2008-08-02-ruby-vpi-21-1-0.html</guid>
      <pubDate>Sat, 02 Aug 2008 13:10:22 -0700</pubDate>
      <description>&lt;p&gt;This release adds new compilation hooks, improves support for Mentor Modelsim, simplifies the internal task scheduler, and shortens the critical path of the C extension.&lt;/p&gt;
&lt;h1&gt;Features&lt;/h1&gt;
&lt;ul&gt;
	&lt;li&gt;Added &lt;code class=&quot;code&quot;&gt;&lt;span style=&quot;color:#036;font-weight:bold&quot;&gt;CFLAGS_EXTRA&lt;/span&gt;&lt;/code&gt; and &lt;code class=&quot;code&quot;&gt;&lt;span style=&quot;color:#036;font-weight:bold&quot;&gt;LDFLAGS_EXTRA&lt;/span&gt;&lt;/code&gt; environment variables, which allow you  to &lt;em&gt;append&lt;/em&gt; to the default &lt;code class=&quot;code&quot;&gt;&lt;span style=&quot;color:#036;font-weight:bold&quot;&gt;CFLAGS&lt;/span&gt;&lt;/code&gt; and &lt;code class=&quot;code&quot;&gt;&lt;span style=&quot;color:#036;font-weight:bold&quot;&gt;LDFLAGS&lt;/span&gt;&lt;/code&gt; with which your Ruby installation was built.&lt;/li&gt;
&lt;/ul&gt;
Note that the &lt;code class=&quot;code&quot;&gt;&lt;span style=&quot;color:#036;font-weight:bold&quot;&gt;CFLAGS&lt;/span&gt;&lt;/code&gt; and &lt;code class=&quot;code&quot;&gt;&lt;span style=&quot;color:#036;font-weight:bold&quot;&gt;LDFLAGS&lt;/span&gt;&lt;/code&gt; environment variables still behave the same way: they completely override the defaults.
&lt;h1&gt;Improvements&lt;/h1&gt;
&lt;ul&gt;
	&lt;li&gt;Attempted to fix &lt;a href=&quot;http://rubyforge.org/pipermail/ruby-vpi-discuss/2007-October/000083.html&quot;&gt;spurious failures with Modelsim 6.2g&lt;/a&gt; by advancing to the &lt;em&gt;same&lt;/em&gt; time step&lt;sup class=&quot;footnote&quot;&gt;&lt;a href=&quot;http://snk.rubyforge.org/web/2008-08-02-ruby-vpi-21-1-0.html/#fn1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt; before applying cache write operations.&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
	&lt;li&gt;Replaced thread-based tasks with continuations (callcc) in internal scheduler.&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
	&lt;li&gt;Avoid some function calls on the C extension&amp;#8217;s critical path by storing/reusing return values.&lt;/li&gt;
&lt;/ul&gt;
&lt;p class=&quot;footnote&quot; id=&quot;fn1&quot;&gt;&lt;sup&gt;1&lt;/sup&gt; How can advancing the simulator by &lt;em&gt;zero&lt;/em&gt; time steps solve anything?&lt;/p&gt;
&lt;p&gt;A time step is really composed of multiple time &lt;em&gt;slots&lt;/em&gt;, so advancing by zero time steps could, in fact, take us to &lt;em&gt;any&lt;/em&gt; future time slot withnin the current time step.&lt;/p&gt;
&lt;p&gt;There are more details that I don&amp;#8217;t care to explain here, but in general, this technique seems to cure Modelsim 6.2g by advancing it into a time slot where write operations can be applied correctly.&lt;/p&gt;</description>

        <category>project</category>
        <category>ruby-vpi</category>

        <comments>mailto:&#115;&#110;&#107;&#64;&#103;&#110;&#97;&#46;&#111;&#114;&#103;?subject=Ruby-VPI%2021.1.0&amp;body=http%3A%2F%2Fsnk.rubyforge.org%2Fweb%2F2008-08-02-ruby-vpi-21-1-0.html</comments>
    </item>
</channel>
</rss>
