gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Problem with logic elements on transient simulation


From: Felix Salfelder
Subject: Re: [Gnucap-devel] Problem with logic elements on transient simulation
Date: Mon, 5 Nov 2012 20:22:35 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hi Rupert.

On Mon, Nov 05, 2012 at 09:58:14AM +0000, Rupert Swarbrick wrote:
> Hunting through the code, I think I've worked out what's going
> on. Switching on tracing (and commenting out bit-rotted lines so it
> would compile, grrr).

theres less trouble (and less output) when tracing selectively:
$ make
$ touch d_logic.cc
$ make CPPFLAGS=-DDO_TRACE\ -DTRACE_UNTESTED

> Questions
> =========
> 
> (1) Is this a bug? (I presume so, but thought I should check!)

at first glance it looks like one.

> (2) Has anyone written down an explanation of how d_logic should work
>     somewhere? I'd happily search for a fix, but it feels like I'm
>     stumbling around in the dark a little bit.

this is approximately what i must have done, when i ran into the
assertion. i just checked: in gnucap-uf it's commented out.
also i must have done something that changes the output. i get

*Time       v(q)       v(vclk)    v(vdd)    
 0.         2.5        0.         5.        
 1.u        2.5        0.         5.        
 2.u        2.5        0.         5.        
 3.u        2.5        0.         5.        
 4.u        2.5        0.         5.        
 5.u        2.5        0.         5.        
 50.u       2.5        0.         5.        
 50.u       2.5        5.         5.        
 50.002u    5.         5.         5.        
 50.002u    0.         5.         5.        
 50.004u    0.         5.         5.        
 50.004u    0.         5.         5.        
 50.3u      0.         5.         5.        
 50.301u    0.         0.         5.        
 50.301u    0.         0.         5.        
 50.301u    5.         0.         5.        
 50.301u    5.         0.         5.        
 50.301u    5.         0.         5.        
 50.302u    1.0577     0.         5.        
 50.303u    5.         0.         5.        
 50.304u    0.         0.         5.        
 60.243u    0.         0.         5.        
 100.u      0.         0.         5. 

(i leave it to you, whether this is better or worse)

> (3) Is this going to be irrelevant if/when upcoming VHDL/Verilog work
>     gets merged?

i can only speak for my attempt to implement an iverilog target: no, i tried to
do something compatible with the existing devices. but the development has
stalled after i abandoned the vvp-hack to implement a clean(er) 
C++-only-variant.

> Not quite on the same topic:
> 
> (4) Is there an "official" development repository? I am using
>     git://github.com/savvy2020/gnucap.git, but this is just imports of
>     various snapshots. And the most recent non-git-related change is
>     from 2009(!)

good quesstion. there is another inofficial at
git://tool.em.cs.uni-frankfurt.de/git/gnucap. that's where the
"gnucap-uf" branch (fork?) is.

regards
felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]