iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] prototypes for foo_register()

[Larry D. <ldo...@re...>]

Cary -

On Fri, Jul 11, 2014 at 10:42:03AM -0700, Cary R. wrote:
> I find #4 acceptable in it's present form, but it would be best to put a comment describing why the definition is there to avoid confusion in the future.

Using vpi/sys_time.c as an example, we'd end up with

/* Declare a prototype first, to avoid warnings with some strict C compiler
 * options.  This prototype conforms to the VPI plugin standard, and is
 * therefore consistent with the usage in Icarus' sys_table.c. */
void sys_time_register(void);
void sys_time_register(void)
{
	s_vpi_systf_data tf_data;
	.
	.

Or is that too verbose?

I'd like to hear from Steve W. on this topic.

  - Larry

Re: [Iverilog-devel] prototypes for foo_register()

[Cary R. <cy...@ya...>]

I find #4 acceptable in it's present form, but it would be best to put a comment describing why the definition is there to avoid confusion in the future.

Cary



On Friday, July 11, 2014 10:34 AM, Larry Doolittle <ldo...@re...> wrote:
 


Cary -

On Fri, Jul 11, 2014 at 10:16:22AM -0700, Cary R. wrote:
> If I understand this correctly #3 seems like too much work, #4 looks wrong since these are not static functions they are extern. I understand not wanting the warnings so that implies that #2 is the best choice. Can sys_priv.h be used to define these functions? I'm guessing most of the files already include it. Or maybe we need files for each table type (normal, math, v2009, etc.).

Sorry to have put a critical typo in #4.

4.  Just paper over the warning in each of the modules by
void foo_register(void);
void foo_register(void)
{
   blah blah blah
}
My original comments still apply, and this is no longer "wrong" as
your reply pointed out.

I managed to cut-and-paste from the one example (vhdl_register) that
is not part of the sys_table.c subsystem, and therefore the one
out of ~30 that has a static on it.  Just unlucky today, I guess.

I agree with your assessment on #3, but I really don't like #2 either.
#4 just adds one new line to each of 20 vpi source files.


  - Larry

> On Friday, July 11, 2014 9:33 AM, Larry Doolittle <ldo...@re...> wrote:
> Friends -
> 
> Looking in vpi at all the foo_register()  routines, which account for
> almost all of the remaining missing-prototypes warnings flagged.
> What to do?  I see four approaches, each has problems.
> 
> 1.  Leave them the way they are, and expect people like me who chase
> lint to filter out the warnings as spurious.  Where and how would we
> document that?
> 
> 2.  Move the block of 20 "extern void foo_register(void);" declarations
> in sys_table.c into a .h file, which is then #included into each of the
> C functions.  Introduces a spurious cross-dependency between each of the
> modules.
> 
> 3.  Create 20 new .h files, each declaring foo_register(void).  #include
> all 20 of these files in sys_table.c.  Creates quite a bit of fluff for
> not much benefit.
> 
> 4.  Just paper over the warning in each of the modules by
> static void foo_register(void);
> static void foo_register(void)
> {
>    blah blah blah
> }
> Minimal change, gets rid of the warnings.  Doesn't really check for 
> argument mismatches, but in this case there are no arguments to check.

Re: [Iverilog-devel] prototypes for foo_register()

[Larry D. <ldo...@re...>]

Cary -

On Fri, Jul 11, 2014 at 10:16:22AM -0700, Cary R. wrote:
> If I understand this correctly #3 seems like too much work, #4 looks wrong since these are not static functions they are extern. I understand not wanting the warnings so that implies that #2 is the best choice. Can sys_priv.h be used to define these functions? I'm guessing most of the files already include it. Or maybe we need files for each table type (normal, math, v2009, etc.).

Sorry to have put a critical typo in #4.

4.  Just paper over the warning in each of the modules by
void foo_register(void);
void foo_register(void)
{
   blah blah blah
}
My original comments still apply, and this is no longer "wrong" as
your reply pointed out.

I managed to cut-and-paste from the one example (vhdl_register) that
is not part of the sys_table.c subsystem, and therefore the one
out of ~30 that has a static on it.  Just unlucky today, I guess.

I agree with your assessment on #3, but I really don't like #2 either.
#4 just adds one new line to each of 20 vpi source files.

  - Larry

> On Friday, July 11, 2014 9:33 AM, Larry Doolittle <ldo...@re...> wrote:
> Friends -
> 
> Looking in vpi at all the foo_register()  routines, which account for
> almost all of the remaining missing-prototypes warnings flagged.
> What to do?  I see four approaches, each has problems.
> 
> 1.  Leave them the way they are, and expect people like me who chase
> lint to filter out the warnings as spurious.  Where and how would we
> document that?
> 
> 2.  Move the block of 20 "extern void foo_register(void);" declarations
> in sys_table.c into a .h file, which is then #included into each of the
> C functions.  Introduces a spurious cross-dependency between each of the
> modules.
> 
> 3.  Create 20 new .h files, each declaring foo_register(void).  #include
> all 20 of these files in sys_table.c.  Creates quite a bit of fluff for
> not much benefit.
> 
> 4.  Just paper over the warning in each of the modules by
> static void foo_register(void);
> static void foo_register(void)
> {
>    blah blah blah
> }
> Minimal change, gets rid of the warnings.  Doesn't really check for 
> argument mismatches, but in this case there are no arguments to check.

Re: [Iverilog-devel] prototypes for foo_register()

[Cary R. <cy...@ya...>]

Hi Larry,

If I understand this correctly #3 seems like too much work, #4 looks wrong since these are not static functions they are extern. I understand not wanting the warnings so that implies that #2 is the best choice. Can sys_priv.h be used to define these functions? I'm guessing most of the files already include it. Or maybe we need files for each table type (normal, math, v2009, etc.).

Cary



On Friday, July 11, 2014 9:33 AM, Larry Doolittle <ldo...@re...> wrote:
 


Friends -

Looking in vpi at all the foo_register()  routines, which account for
almost all of the remaining missing-prototypes warnings flagged.
What to do?  I see four approaches, each has problems.

1.  Leave them the way they are, and expect people like me who chase
lint to filter out the warnings as spurious.  Where and how would we
document that?

2.  Move the block of 20 "extern void foo_register(void);" declarations
in sys_table.c into a .h file, which is then #included into each of the
C functions.  Introduces a spurious cross-dependency between each of the
modules.

3.  Create 20 new .h files, each declaring foo_register(void).  #include
all 20 of these files in sys_table.c.  Creates quite a bit of fluff for
not much benefit.

4.  Just paper over the warning in each of the modules by
static void foo_register(void);
static void foo_register(void)
{
   blah blah blah
}
Minimal change, gets rid of the warnings.  Doesn't really check for 
argument mismatches, but in this case there are no arguments to check.

  - Larry

------------------------------------------------------------------------------
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

[Iverilog-devel] prototypes for foo_register()

[Larry D. <ldo...@re...>]

Friends -

Looking in vpi at all the foo_register()  routines, which account for
almost all of the remaining missing-prototypes warnings flagged.
What to do?  I see four approaches, each has problems.

1.  Leave them the way they are, and expect people like me who chase
lint to filter out the warnings as spurious.  Where and how would we
document that?

2.  Move the block of 20 "extern void foo_register(void);" declarations
in sys_table.c into a .h file, which is then #included into each of the
C functions.  Introduces a spurious cross-dependency between each of the
modules.

3.  Create 20 new .h files, each declaring foo_register(void).  #include
all 20 of these files in sys_table.c.  Creates quite a bit of fluff for
not much benefit.

4.  Just paper over the warning in each of the modules by
static void foo_register(void);
static void foo_register(void)
{
   blah blah blah
}
Minimal change, gets rid of the warnings.  Doesn't really check for 
argument mismatches, but in this case there are no arguments to check.

  - Larry

[Iverilog-devel] C99 and the Icarus C code

[Cary R. <cy...@ya...>]

A quick question at the end, but a little background first.

For some time Icarus has required the C99 flag when compiling C code to work around problems finding the nan(), etc. functions. We have tried not to add C99 specific code so that if someone did not have a C99 compliant compiler they only had to deal with getting the functions to load correctly. At this time it seems like avoiding C99 specific code is probably no longer needed. Any compiler that someone will be compiling Icarus with should support C99.


With this background does anyone have a reason we should not allow C99 specific constructs in the C code?

Steve and I do not see any reason why they should not be allowed, but thought we would ask if anyone else had a reason. We do not plan to actively updated the code except when fixing other issues. This has become an issue since there is a patch in the patch tracker that adds variable definitions inside the initialization part of some for statements, which is a C99 extension.

Cary

Re: [Iverilog-devel] patch tracker status?

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've been overwhelmed. Besides day job, there has been paid work
stealing away my time, so at the moment that is the way to get
my attention. (Am I a code whore? So it seems:-( ) That said, the
patch trackers have been addressed by others, such as Cary and Martin.

Inexplicably, people seem to have started using the trackers on
github. Fortunately, those have been covered by volunteers as well.

The above has been compounded by me being on vacation for almost
a week.

On 06/08/2014 05:41 PM, Cary R. wrote:
> Hi Larry,
> 
> Steve could be busy. I don't think we have used the patch tracker
> in a while, but it should still be functional and has not been
> obsoleted. I could apply the patches if they are straight forward.
> If you send them to the tracker I get notified along with Steve,
> though I defer the complicated patches to him.
> 
> Cary
> 
> 
> On Sunday, June 8, 2014 3:11 PM, Larry Doolittle 
> <ldo...@re...> wrote:
> 
> 
> Hi -
> 
> I sent Steve three patches, a little over a week ago:
> 
> 0001-Don-t-lie-to-the-c-about-some-pointer-alignment.patch 
> 0001-Pick-some-low-hanging-const-fruit.patch 
> 0001-Fix-some-weird-lint-found-by-clang.patch
> 
> Should I send them to a patch tracker instead? I don't see much
> recent activity on http://sourceforge.net/p/iverilog/patches/
> 
> I could send them to this list, if that's better.
> 
> - Larry


- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlOZ4TsACgkQrPt1Sc2b3inW/ACg6QUTYLOPkVmIcQ2KZ7Yx0Ofg
ab8An3Sj0YrN8z0G4PdI0ckAdOvmzDyi
=JLq5
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] patch tracker status?

[Cary R. <cy...@ya...>]

Hi Larry,

Steve could be busy. I don't think we have used the patch tracker in a while, but it should still be functional and has not been obsoleted. I could apply the patches if they are straight forward. If you send them to the tracker I get notified along with Steve, though I defer the complicated patches to him.


Cary



On Sunday, June 8, 2014 3:11 PM, Larry Doolittle <ldo...@re...> wrote:
 


Hi -

I sent Steve three patches, a little over a week ago:

0001-Don-t-lie-to-the-c-about-some-pointer-alignment.patch
0001-Pick-some-low-hanging-const-fruit.patch
0001-Fix-some-weird-lint-found-by-clang.patch

Should I send them to a patch tracker instead?
I don't see much recent activity on
http://sourceforge.net/p/iverilog/patches/

I could send them to this list, if that's better.

  - Larry

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

[Iverilog-devel] patch tracker status?

[Larry D. <ldo...@re...>]

Hi -

I sent Steve three patches, a little over a week ago:

0001-Don-t-lie-to-the-c-about-some-pointer-alignment.patch
0001-Pick-some-low-hanging-const-fruit.patch
0001-Fix-some-weird-lint-found-by-clang.patch

Should I send them to a patch tracker instead?
I don't see much recent activity on
http://sourceforge.net/p/iverilog/patches/

I could send them to this list, if that's better.

  - Larry

Re: [Iverilog-devel] Infinite loop on simulation

[Patrick S. <pat...@gm...>]

2014-04-08 22:39 GMT+01:00 Cary R. <cy...@ya...>:
> What is gate level to you and why do you want to do this at the gate level?
> Verilog primitive gates are not the same as the gates provided by a cell
> library. A cell library almost certainly has flip-flops and other more
> complicated gates. Verilog has a very limited number of primitive gates. At
> the gate level latches and flip-flops are usually modeled in Verilog using
> UDPs. Generation of a high quality UDP is not a trivial task and often
> involves making tradeoffs.

For me gate level was using only primitive gates that are built into
the language.

I am describing a CPU by writing each component with these primitives.

This exercise is mostly for self-educational purposes and I felt that
if I was using RTL, I wouldn't be close enough to the bare transistor
to understand what is happening underneath my Verilog code.

Essentially, I wanted to write the gate level code that the simulator
would generate from the RTL description.

> Two series D latches make a D flip-flop if the clock is inverted, though
> without some delay you can have a data/clock race condition between the
> first and second latch.

Indeed, I had completely forgotten my digital systems basics and now I
see why the D latch, which is not edge-triggered, implies that I would
get an infinitely fast oscillator.
I studied in France originally and I guess I also got confused in the
translation :)

With a D flip-flop, the system now behaves as expected. Of course, I
had to express my test cases differently by introducing a delay to
ensure that the input value is set before I enable writing on the
register.

The original code that I fixed is here:
https://github.com/patrick-samy/ace/blob/master/data/program-counter.v

> Verilog is fine for gate level modeling, though RTL is usually much fast to
> simulate and allows the design to be synthesized.

Now I understand why having the RTL abstraction is useful and how it
helps solving some issues.

Sorry for the response delay, I didn't have time to work much on this
in the past few weeks.

Thanks to everyone for your help.

Patrick

> On Tuesday, April 8, 2014 2:11 PM, Patrick Samy <pat...@gm...>
> wrote:
> 2014-04-08 19:37 GMT+02:00 Cary R. <cy...@ya...>:
>> This is a problem in your design/test setup. I could tell you the problem
>> and I will if you really want, but a better way is to learn some debugging
>> techniques.
>
> Definitely, it will be good to try and find out the issue by myself.
>
>> Adding the following line to the register module will show you the state
>> of
>> the bits driving the latch element:
>>
>> always @(qi, not_qi) $display($time,, in,, set,, qi,, not_qi);
>>
>> If you don't know, in the Icarus run time (vvp) ^C followed by finish<CR>
>> will stop the simulation. What pattern do you see? The key question here
>> is
>> why is "in" toggling? The answer to that is found by evaluating the
>> connection of the gates at the test level when the top level "in" == 0
>> (which is not the same as the register "in" signal).
>
> Indeed, I can see that the value is oscillating and I understand why.
>
>> If your gates had some delay the simulation would not lock up at a
>> specific
>> time step, but it will not stop either. You would need to end the test
>> block
>> with clock == 0 or add an explicit $finish.
>>
>> One significant point of clarification. Your register block is not a S/R
>> flip-flop or even a S/R latch. It is a S/R latch with some extra control
>> logic to make it act like a D latch. This latch is transparent when the
>> enable (set pin) is high. It is not edge sensitive like a D flip-flop. I
>> believe the problem you are experiencing is because you are using a latch
>> like a flip-flop, which as you have discovered doesn't work very well.
>
> I see the problem here.
>
> My goal was to do everything at the gate-level for the whole CPU
> design but it doesn't seem to be feasible since, in this case, you
> would need a way to wire the latch so that the value is stored only on
> the rising edge, which is essentially what the @(posedge clk)
> statement does.
>
> What if I add a second latch that keeps the previous value and when
> the latches outputs are different, a signal acts as a feedback loop
> and prevent first latch to be written again, until the next falling
> edge ?
>
> A good thing to ask, maybe: is Verilog the right tool for _gate-level
> only_ modeling ?
>
>> I hope that helps.
>
> Very much, thank you for your time.
> --
> Patrick Samy
>
>> On Tuesday, April 8, 2014 9:16 AM, Stephen Williams <st...@ic...>
>> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> Just quickly looking at this...
>>
>> It appears that you've created an infinitely fast oscillator.
>> I think you are trying to create an SR flip-flop with the last
>> two nand gates in your register module, but instead you are getting
>> meta-stability.
>>
>> Synchronous logic is not typically modeled in Verilog this way.
>> This looks like an educational exercise, so you might try getting
>> more realistic relative timings.
>>
>> What are you really trying to do?
>>
>> On 04/08/2014 03:50 AM, Patrick Samy wrote:
>>> Hello,
>>>
>>> When I perform a simulation of my design with iverilog 0.9.7, it
>>> seems to be stuck in an infinite loop.
>>>
>>> The original design is a program counter adder with the following
>>> prototype:
>>>
>>> module program_counter(input enable_count, input enable_overwrite,
>>> input[31:0] overwrite_value, output[31:0] out);
>>>
>>> I managed to simplify the verilog testbench code with a D flip flop
>>> as a 1-bit register and reproduce the issue:
>>>
>>> module register(input in, input set, output out);
>>>
>>> wire not_in; wire qi; wire not_qi; wire not_q;
>>>
>>> nand (qi, in, set);
>>>
>>> not  (not_in, in); nand (not_qi, not_in, set);
>>>
>>> nand (out, qi, not_q); nand (not_q, not_qi, out);
>>>
>>> endmodule
>>>
>>> module test;
>>>
>>> reg  clock; reg  in; wire out; wire not_out;
>>>
>>> // add 'x_out <- out + 1' xor (x_out, out, 1);
>>>
>>> // 2x1 mux with 'in' as value and control bit or  (muxed_out,
>>> x_out, in);
>>>
>>> register r(muxed_out, clock, out);
>>>
>>> initial begin $dumpfile("test.vcd"); $dumpvars(0, test);
>>>
>>> $display("\tclock,\tin,\tout") ; $monitor("\t%b,\t%x,\t%b", clock,
>>> in, out);
>>>
>>> // erase internal register #0 in = 1; #0 clock = 1;
>>>
>>> #1 in = 0; #1 clock = 0;
>>>
>>> #2 clock = 1; #3 clock = 0; #4 clock = 1; end
>>>
>>> endmodule
>>>
>>>
>>> The VCD output does not show any change of state after the #2
>>> tick: in== 0 clock == 1
>>>
>>> Therefore, the register is continuously feeded with the result of
>>> the adder and my guess is that icarus is waiting for the values to
>>> stabilize for this tick and gets stuck.
>>>
>>> Can you spot a potential issue with this design ?
>>>
>>> I also posted the issue on StackOverflow to make sure that code is
>>> correct:
>>>
>>>
>>> http://stackoverflow.com/questions/22900633/infinite-loop-when-simulating-a-program-counter-design-with-icarus-verilog
>>>
>>>  Thanks and apologies in advance if this is a stupid mistake on my
>>> side, I spent a week trying to figure it out by myself without
>>> success.
>>>
>>> Regards,
>>>
>>
>>
>> - --
>> Steve Williams                "The woods are lovely, dark and deep.
>> steve at icarus.com          But I have promises to keep,
>> http://www.icarus.com         and lines to code before I sleep,
>> http://www.picturel.com       And lines to code before I sleep."
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.19 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iEYEARECAAYFAlNEIL8ACgkQrPt1Sc2b3inQRQCdFS4YlwoLBY//HVYdzCLUgb00
>> gvsAoN0R3hxw9IHQFqtnVKaEIJvvmM+y
>> =p4NY
>> -----END PGP SIGNATURE-----
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>>
>
>
>
> --
> Patrick Samy
>
>



-- 
Patrick Samy

[Iverilog-devel] SIMBUS support for AXI4

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've pushed into the simbus git master support for the AXI4 bus.
Currently, there is only master support (in the libsimbus library)
for AXI4-Lite, but the server does handle all the AXI4 signals,
so you should be able to simulate your own AXI4 masters/slaves.

Here's more information about SIMBUS:

<http://http://iverilog.wikia.com/wiki/SIMBUS>

The AXI4 support is only in the git repository, not any snapshots.
I'll make a snapshot when the AXI4 stuff is for sure more stabilized.

- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNpT/MACgkQrPt1Sc2b3ilI/wCfe1oDn74aw1/QOWg9ttdqWXET
XlUAnjA/CIlL7XbDBrOifuGQcC3CjMAW
=oFDY
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] FYI: Latest Icarus Verilog 0.10.0 on EDA Playground

[Victor L. <vi...@vi...>]

Yes, NaCL is an interesting technology. I have not used it, but I
understand that it has not been widely adopted because
1. It only works on Chrome
2. The code has to be written/re-written to work in an NaCL environment to
close real or potential security holes

Funny you mention it, since a few weeks ago I spoke to the founder of an
NaCL company http://zerovm.org/ which was recently acquired by Rackspace.


On Sun, Apr 13, 2014 at 1:36 PM, Iztok Jeras <izt...@gm...> wrote:

> Hi,
>
> I was thinking, that it would be possible to run Icarus on the client
> computer using PNACL <http://en.wikipedia.org/wiki/Google_Native_Client>.
> For some users this could be faster then running on a server, and in any
> case less demanding on the server.
>
> Regards,
> Iztok Jeras
>
>
> On Sun, Apr 13, 2014 at 5:58 AM, Victor Lyuboslavsky <vi...@vi...
> > wrote:
>
>> I just updated Icarus Verilog 0.10.0 on EDA Playground to today's (4/12)
>> version. Example: http://www.edaplayground.com/x/26
>>
>>  EDA Playground also has ModelSim, so it can be a good place to test the
>> SystemVerilog/Verilog functionality of small examples. ModelSim claims to
>> support all of SystemVerilog except SV assertions/coverage, randomize()
>> method, and program blocks.
>>
>> Regards,
>> Victor
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>

Re: [Iverilog-devel] FYI: Latest Icarus Verilog 0.10.0 on EDA Playground

[Iztok J. <izt...@gm...>]

Hi,

I was thinking, that it would be possible to run Icarus on the client
computer using PNACL <http://en.wikipedia.org/wiki/Google_Native_Client>.
For some users this could be faster then running on a server, and in any
case less demanding on the server.

Regards,
Iztok Jeras


On Sun, Apr 13, 2014 at 5:58 AM, Victor Lyuboslavsky
<vi...@vi...>wrote:

> I just updated Icarus Verilog 0.10.0 on EDA Playground to today's (4/12)
> version. Example: http://www.edaplayground.com/x/26
>
>  EDA Playground also has ModelSim, so it can be a good place to test the
> SystemVerilog/Verilog functionality of small examples. ModelSim claims to
> support all of SystemVerilog except SV assertions/coverage, randomize()
> method, and program blocks.
>
> Regards,
> Victor
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>

Re: [Iverilog-devel] FYI: Latest Icarus Verilog 0.10.0 on EDA Playground

[Cary R. <cy...@ya...>]

Thanks for the update Victor.

On Saturday, April 12, 2014 9:11 PM, Victor Lyuboslavsky <vi...@vi...> wrote:
 
I just updated Icarus Verilog 0.10.0 on EDA Playground to today's (4/12) version. Example: http://www.edaplayground.com/x/26


EDA Playground also has ModelSim, so it can be a good place to test the 
SystemVerilog/Verilog functionality of small examples. ModelSim claims to support all of 
SystemVerilog except SV assertions/coverage, randomize() method, and 
program blocks.

Regards,
Victor


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

[Iverilog-devel] FYI: Latest Icarus Verilog 0.10.0 on EDA Playground

[Victor L. <vi...@vi...>]

I just updated Icarus Verilog 0.10.0 on EDA Playground to today's (4/12)
version. Example: http://www.edaplayground.com/x/26

EDA Playground also has ModelSim, so it can be a good place to test the
SystemVerilog/Verilog functionality of small examples. ModelSim claims to
support all of SystemVerilog except SV assertions/coverage, randomize()
method, and program blocks.

Regards,
Victor

Re: [Iverilog-devel] Infinite loop on simulation

[Cary R. <cy...@ya...>]

What is gate level to you and why do you want to do this at the gate level? Verilog primitive gates are not the same as the gates provided by a cell library. A cell library almost certainly has flip-flops and other more complicated gates. Verilog has a very limited number of primitive gates. At the gate level latches and flip-flops are usually modeled in Verilog using UDPs. Generation of a high quality UDP is not a trivial task and often involves making tradeoffs.

Two series D latches make a D flip-flop if the clock is inverted, though without some delay you can have a data/clock race condition between the first and second latch.

Verilog is fine for gate level modeling, though RTL is usually much fast to simulate and allows the design to be synthesized.

Cary

On Tuesday, April 8, 2014 2:11 PM, Patrick Samy <pat...@gm...> wrote:
 
2014-04-08 19:37 GMT+02:00 Cary R. <cy...@ya...>:
> This is a problem in your design/test setup. I could tell you the problem
> and I will if you really want, but a better way is to learn some debugging
> techniques.

Definitely, it will be good to try and find out the issue by myself.

> Adding the following line to the register module will show you the state of
> the bits driving the latch element:
>
> always @(qi, not_qi) $display($time,, in,, set,, qi,, not_qi);
>
> If you don't know, in the Icarus run time (vvp) ^C followed by finish<CR>
> will stop the simulation. What pattern do you see? The key question here is
> why is "in" toggling? The answer to that is found by evaluating the
> connection of the gates at the test level when the top level "in" == 0
> (which is not the same as the register "in" signal).

Indeed, I can see that the value is oscillating and I understand why.

> If your gates had some delay the simulation would not lock up at a specific
> time step, but it will not stop either. You would need to end the test block
> with clock == 0 or add an explicit $finish.
>
> One significant point of clarification. Your register block is not a S/R
> flip-flop or even a S/R latch. It is a S/R latch with some extra control
> logic to make it act like a D latch. This latch is transparent when the
> enable (set pin) is high. It is not edge sensitive like a D flip-flop. I
> believe the problem you are experiencing is because you are using a latch
> like a flip-flop, which as you have discovered doesn't work very well.

I see the problem here.

My goal was to do everything at the gate-level for the whole CPU
design but it doesn't seem to be feasible since, in this case, you
would need a way to wire the latch so that the value is stored only on
the rising edge, which is essentially what the @(posedge clk)
statement does.

What if I add a second latch that keeps the previous value and when
the latches outputs are different, a signal acts as a feedback loop
and prevent first latch to be written again, until the next falling
edge ?

A good thing to ask, maybe: is Verilog the right tool for _gate-level
only_ modeling ?

> I hope that helps.

Very much, thank you for your time.
-- 
Patrick Samy

> On Tuesday, April 8, 2014 9:16 AM, Stephen Williams <st...@ic...>
> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Just quickly looking at this...
>
> It appears that you've created an infinitely fast oscillator.
> I think you are trying to create an SR flip-flop with the last
> two nand gates in your register module, but instead you are getting
> meta-stability.
>
> Synchronous logic is not typically modeled in Verilog this way.
> This looks like an educational exercise, so you might try getting
> more realistic relative timings.
>
> What are you really trying to do?
>
> On 04/08/2014 03:50 AM, Patrick Samy wrote:
>> Hello,
>>
>> When I perform a simulation of my design with iverilog 0.9.7, it
>> seems to be stuck in an infinite loop.
>>
>> The original design is a program counter adder with the following
>> prototype:
>>
>> module program_counter(input enable_count, input enable_overwrite,
>> input[31:0] overwrite_value, output[31:0] out);
>>
>> I managed to simplify the verilog testbench code with a D flip flop
>> as a 1-bit register and reproduce the issue:
>>
>> module register(input in, input set, output out);
>>
>> wire not_in; wire qi; wire not_qi; wire not_q;
>>
>> nand (qi, in, set);
>>
>> not  (not_in, in); nand (not_qi, not_in, set);
>>
>> nand (out, qi, not_q); nand (not_q, not_qi, out);
>>
>> endmodule
>>
>> module test;
>>
>> reg  clock; reg  in; wire out; wire not_out;
>>
>> // add 'x_out <- out + 1' xor (x_out, out, 1);
>>
>> // 2x1 mux with 'in' as value and control bit or  (muxed_out,
>> x_out, in);
>>
>> register r(muxed_out, clock, out);
>>
>> initial begin $dumpfile("test.vcd"); $dumpvars(0, test);
>>
>> $display("\tclock,\tin,\tout") ; $monitor("\t%b,\t%x,\t%b", clock,
>> in, out);
>>
>> // erase internal register #0 in = 1; #0 clock = 1;
>>
>> #1 in = 0; #1 clock = 0;
>>
>> #2 clock = 1; #3 clock = 0; #4 clock = 1; end
>>
>> endmodule
>>
>>
>> The VCD output does not show any change of state after the #2
>> tick: in== 0 clock == 1
>>
>> Therefore, the register is continuously feeded with the result of
>> the adder and my guess is that icarus is waiting for the values to
>> stabilize for this tick and gets stuck.
>>
>> Can you spot a potential issue with this design ?
>>
>> I also posted the issue on StackOverflow to make sure that code is
>> correct:
>>
>> http://stackoverflow.com/questions/22900633/infinite-loop-when-simulating-a-program-counter-design-with-icarus-verilog
>>
>>  Thanks and apologies in advance if this is a stupid mistake on my
>> side, I spent a week trying to figure it out by myself without
>> success.
>>
>> Regards,
>>
>
>
> - --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com          But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlNEIL8ACgkQrPt1Sc2b3inQRQCdFS4YlwoLBY//HVYdzCLUgb00
> gvsAoN0R3hxw9IHQFqtnVKaEIJvvmM+y
> =p4NY
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

>



-- 
Patrick Samy

Re: [Iverilog-devel] Infinite loop on simulation

[Patrick S. <pat...@gm...>]

2014-04-08 19:37 GMT+02:00 Cary R. <cy...@ya...>:
> This is a problem in your design/test setup. I could tell you the problem
> and I will if you really want, but a better way is to learn some debugging
> techniques.

Definitely, it will be good to try and find out the issue by myself.

> Adding the following line to the register module will show you the state of
> the bits driving the latch element:
>
> always @(qi, not_qi) $display($time,, in,, set,, qi,, not_qi);
>
> If you don't know, in the Icarus run time (vvp) ^C followed by finish<CR>
> will stop the simulation. What pattern do you see? The key question here is
> why is "in" toggling? The answer to that is found by evaluating the
> connection of the gates at the test level when the top level "in" == 0
> (which is not the same as the register "in" signal).

Indeed, I can see that the value is oscillating and I understand why.

> If your gates had some delay the simulation would not lock up at a specific
> time step, but it will not stop either. You would need to end the test block
> with clock == 0 or add an explicit $finish.
>
> One significant point of clarification. Your register block is not a S/R
> flip-flop or even a S/R latch. It is a S/R latch with some extra control
> logic to make it act like a D latch. This latch is transparent when the
> enable (set pin) is high. It is not edge sensitive like a D flip-flop. I
> believe the problem you are experiencing is because you are using a latch
> like a flip-flop, which as you have discovered doesn't work very well.

I see the problem here.

My goal was to do everything at the gate-level for the whole CPU
design but it doesn't seem to be feasible since, in this case, you
would need a way to wire the latch so that the value is stored only on
the rising edge, which is essentially what the @(posedge clk)
statement does.

What if I add a second latch that keeps the previous value and when
the latches outputs are different, a signal acts as a feedback loop
and prevent first latch to be written again, until the next falling
edge ?

A good thing to ask, maybe: is Verilog the right tool for _gate-level
only_ modeling ?

> I hope that helps.

Very much, thank you for your time.
-- 
Patrick Samy

> On Tuesday, April 8, 2014 9:16 AM, Stephen Williams <st...@ic...>
> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Just quickly looking at this...
>
> It appears that you've created an infinitely fast oscillator.
> I think you are trying to create an SR flip-flop with the last
> two nand gates in your register module, but instead you are getting
> meta-stability.
>
> Synchronous logic is not typically modeled in Verilog this way.
> This looks like an educational exercise, so you might try getting
> more realistic relative timings.
>
> What are you really trying to do?
>
> On 04/08/2014 03:50 AM, Patrick Samy wrote:
>> Hello,
>>
>> When I perform a simulation of my design with iverilog 0.9.7, it
>> seems to be stuck in an infinite loop.
>>
>> The original design is a program counter adder with the following
>> prototype:
>>
>> module program_counter(input enable_count, input enable_overwrite,
>> input[31:0] overwrite_value, output[31:0] out);
>>
>> I managed to simplify the verilog testbench code with a D flip flop
>> as a 1-bit register and reproduce the issue:
>>
>> module register(input in, input set, output out);
>>
>> wire not_in; wire qi; wire not_qi; wire not_q;
>>
>> nand (qi, in, set);
>>
>> not  (not_in, in); nand (not_qi, not_in, set);
>>
>> nand (out, qi, not_q); nand (not_q, not_qi, out);
>>
>> endmodule
>>
>> module test;
>>
>> reg  clock; reg  in; wire out; wire not_out;
>>
>> // add 'x_out <- out + 1' xor (x_out, out, 1);
>>
>> // 2x1 mux with 'in' as value and control bit or  (muxed_out,
>> x_out, in);
>>
>> register r(muxed_out, clock, out);
>>
>> initial begin $dumpfile("test.vcd"); $dumpvars(0, test);
>>
>> $display("\tclock,\tin,\tout") ; $monitor("\t%b,\t%x,\t%b", clock,
>> in, out);
>>
>> // erase internal register #0 in = 1; #0 clock = 1;
>>
>> #1 in = 0; #1 clock = 0;
>>
>> #2 clock = 1; #3 clock = 0; #4 clock = 1; end
>>
>> endmodule
>>
>>
>> The VCD output does not show any change of state after the #2
>> tick: in== 0 clock == 1
>>
>> Therefore, the register is continuously feeded with the result of
>> the adder and my guess is that icarus is waiting for the values to
>> stabilize for this tick and gets stuck.
>>
>> Can you spot a potential issue with this design ?
>>
>> I also posted the issue on StackOverflow to make sure that code is
>> correct:
>>
>> http://stackoverflow.com/questions/22900633/infinite-loop-when-simulating-a-program-counter-design-with-icarus-verilog
>>
>>  Thanks and apologies in advance if this is a stupid mistake on my
>> side, I spent a week trying to figure it out by myself without
>> success.
>>
>> Regards,
>>
>
>
> - --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com          But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlNEIL8ACgkQrPt1Sc2b3inQRQCdFS4YlwoLBY//HVYdzCLUgb00
> gvsAoN0R3hxw9IHQFqtnVKaEIJvvmM+y
> =p4NY
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>



-- 
Patrick Samy

Re: [Iverilog-devel] Infinite loop on simulation

[Cary R. <cy...@ya...>]

One significant point of clarification. Your register block is not a S/R flip-flop or even a S/R latch. It is a S/R latch with some extra control logic to make it act like a D latch. This latch is transparent when the enable (set pin) is high. It is not edge sensitive like a D flip-flop. I believe the problem you are experiencing is because you are using a latch like a flip-flop, which as you have discovered doesn't work very well.

Cary

On Tuesday, April 8, 2014 12:54 PM, Stephen Williams <st...@ic...> wrote:
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The typical pattern in Verilog for a D-type FF is:

   reg Q;
   always @(posedge clk) Q <= D;

That is the basic atom of pretty much any state machine that you
model in Verilog, so once you get that in your head, things will
go a lot easier for you. Maybe kinda something like this?:

module counter(
   output reg [7:0] count,
   input clk,
   input reset,
   input load,
   input [7:0] load_value);

   always @(posedge clk) begin
      if (reset)
        count <= 0;
      else if (load)
        count <= load_value;
      else if (enable)
        count <= count + 1;
   end

endmodule

On 04/08/2014 12:32 PM, Patrick Samy wrote:
> 2014-04-08 17:15 GMT+01:00 Stephen Williams <st...@ic...>:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> 
>> Just quickly looking at this...
> 
> Thank you for taking the time to do this !
> 
>> It appears that you've created an infinitely fast oscillator.
> 
> Indeed, this simplified code performs an add "xout <- out + 1" and 
> does not store the carry, which therefore oscillates.
> 
> The original code does the same thing but with a 32-bit register
> based on the same D flip-flop and adding 4 to the (t - 1) value.
> 
>> I think you are trying to create an SR flip-flop with the last 
>> two nand gates in your register module, but instead you are
>> getting meta-stability.
> 
> Understood. I thought it could be the issue and you're right, I am 
> trying to create an SR flip-flop storing one bit with my register 
> module.
> 
>> Synchronous logic is not typically modeled in Verilog this way. 
>> This looks like an educational exercise, so you might try
>> getting more realistic relative timings.
>> 
>> What are you really trying to do?
> 
> I am designing a program counter component for my
> microarchitecture.
> 
> Ok, so do you mean that I should be using _always @(posedge
> clock)_ type of statements instead ?
> 
> In my original code, I was generating the clock with the following 
> code but I had the same issue:
> 
> always begin #5 clock = ~clock; end
> 
> Thanks again.
> 
> Regards,
> 


- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNEU78ACgkQrPt1Sc2b3ilkCQCeIR6DsrivcWmiWPJf1yEcqziK
0SsAni3WAzXXiANE6W+m6cMo/Zn3y0oE
=KNGW

-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Infinite loop on simulation

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The typical pattern in Verilog for a D-type FF is:

   reg Q;
   always @(posedge clk) Q <= D;

That is the basic atom of pretty much any state machine that you
model in Verilog, so once you get that in your head, things will
go a lot easier for you. Maybe kinda something like this?:

module counter(
   output reg [7:0] count,
   input clk,
   input reset,
   input load,
   input [7:0] load_value);

   always @(posedge clk) begin
      if (reset)
        count <= 0;
      else if (load)
        count <= load_value;
      else if (enable)
        count <= count + 1;
   end

endmodule

On 04/08/2014 12:32 PM, Patrick Samy wrote:
> 2014-04-08 17:15 GMT+01:00 Stephen Williams <st...@ic...>:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> 
>> Just quickly looking at this...
> 
> Thank you for taking the time to do this !
> 
>> It appears that you've created an infinitely fast oscillator.
> 
> Indeed, this simplified code performs an add "xout <- out + 1" and 
> does not store the carry, which therefore oscillates.
> 
> The original code does the same thing but with a 32-bit register
> based on the same D flip-flop and adding 4 to the (t - 1) value.
> 
>> I think you are trying to create an SR flip-flop with the last 
>> two nand gates in your register module, but instead you are
>> getting meta-stability.
> 
> Understood. I thought it could be the issue and you're right, I am 
> trying to create an SR flip-flop storing one bit with my register 
> module.
> 
>> Synchronous logic is not typically modeled in Verilog this way. 
>> This looks like an educational exercise, so you might try
>> getting more realistic relative timings.
>> 
>> What are you really trying to do?
> 
> I am designing a program counter component for my
> microarchitecture.
> 
> Ok, so do you mean that I should be using _always @(posedge
> clock)_ type of statements instead ?
> 
> In my original code, I was generating the clock with the following 
> code but I had the same issue:
> 
> always begin #5 clock = ~clock; end
> 
> Thanks again.
> 
> Regards,
> 


- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNEU78ACgkQrPt1Sc2b3ilkCQCeIR6DsrivcWmiWPJf1yEcqziK
0SsAni3WAzXXiANE6W+m6cMo/Zn3y0oE
=KNGW
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Infinite loop on simulation

[Patrick S. <pat...@gm...>]

2014-04-08 17:15 GMT+01:00 Stephen Williams <st...@ic...>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Just quickly looking at this...

Thank you for taking the time to do this !

> It appears that you've created an infinitely fast oscillator.

Indeed, this simplified code performs an add "xout <- out + 1" and
does not store the carry, which therefore oscillates.

The original code does the same thing but with a 32-bit register based
on the same D flip-flop and adding 4 to the (t - 1) value.

> I think you are trying to create an SR flip-flop with the last
> two nand gates in your register module, but instead you are getting
> meta-stability.

Understood. I thought it could be the issue and you're right, I am
trying to create an SR flip-flop storing one bit with my register
module.

> Synchronous logic is not typically modeled in Verilog this way.
> This looks like an educational exercise, so you might try getting
> more realistic relative timings.
>
> What are you really trying to do?

I am designing a program counter component for my microarchitecture.

Ok, so do you mean that I should be using _always @(posedge clock)_
type of statements instead ?

In my original code, I was generating the clock with the following
code but I had the same issue:

    always
    begin
        #5 clock = ~clock;
    end

Thanks again.

Regards,
-- 
Patrick Samy

> On 04/08/2014 03:50 AM, Patrick Samy wrote:
>> Hello,
>>
>> When I perform a simulation of my design with iverilog 0.9.7, it
>> seems to be stuck in an infinite loop.
>>
>> The original design is a program counter adder with the following
>> prototype:
>>
>> module program_counter(input enable_count, input enable_overwrite,
>> input[31:0] overwrite_value, output[31:0] out);
>>
>> I managed to simplify the verilog testbench code with a D flip flop
>> as a 1-bit register and reproduce the issue:
>>
>> module register(input in, input set, output out);
>>
>> wire not_in; wire qi; wire not_qi; wire not_q;
>>
>> nand (qi, in, set);
>>
>> not  (not_in, in); nand (not_qi, not_in, set);
>>
>> nand (out, qi, not_q); nand (not_q, not_qi, out);
>>
>> endmodule
>>
>> module test;
>>
>> reg  clock; reg  in; wire out; wire not_out;
>>
>> // add 'x_out <- out + 1' xor (x_out, out, 1);
>>
>> // 2x1 mux with 'in' as value and control bit or  (muxed_out,
>> x_out, in);
>>
>> register r(muxed_out, clock, out);
>>
>> initial begin $dumpfile("test.vcd"); $dumpvars(0, test);
>>
>> $display("\tclock,\tin,\tout") ; $monitor("\t%b,\t%x,\t%b", clock,
>> in, out);
>>
>> // erase internal register #0 in = 1; #0 clock = 1;
>>
>> #1 in = 0; #1 clock = 0;
>>
>> #2 clock = 1; #3 clock = 0; #4 clock = 1; end
>>
>> endmodule
>>
>>
>> The VCD output does not show any change of state after the #2
>> tick: in== 0 clock == 1
>>
>> Therefore, the register is continuously feeded with the result of
>> the adder and my guess is that icarus is waiting for the values to
>> stabilize for this tick and gets stuck.
>>
>> Can you spot a potential issue with this design ?
>>
>> I also posted the issue on StackOverflow to make sure that code is
>> correct:
>> http://stackoverflow.com/questions/22900633/infinite-loop-when-simulating-a-program-counter-design-with-icarus-verilog
>>
>>  Thanks and apologies in advance if this is a stupid mistake on my
>> side, I spent a week trying to figure it out by myself without
>> success.
>>
>> Regards,
>>
>
>
> - --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com           But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlNEIL8ACgkQrPt1Sc2b3inQRQCdFS4YlwoLBY//HVYdzCLUgb00
> gvsAoN0R3hxw9IHQFqtnVKaEIJvvmM+y
> =p4NY
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Iverilog-devel Digest, Vol 75, Issue 1

[<by...@nc...>]

I tried to send you a private message from my work address but it bounced.  You are writing LXT2, not FST.  You might want to check out your $ calls to set up the dumper, but it's impossible for FST to do that as it has a hard cutoff.  The LXT2 dumper strips off old suffixes so if you have "fst" in your filename, that is why it is disappearing and reappearing as "lxt".

-Tony


> On Wednesday, March 19, 2014 3:50 PM, Stephen Williams <st...@ic...> wrote:
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This may be a Cary and/or Tony question. In my day job, we are
> running long simulations using FST traces. It appears that the
> dumper is cutting files off at 1Gig, though. Is this a feature?
> What's weird, it seems to continue in a fresh file, but it is
> called system_001.lxt, instead of .fst. Is this correct? Is
> there a way to adjust this behavior?

Re: [Iverilog-devel] Infinite loop on simulation

[Cary R. <cy...@ya...>]

This is a problem in your design/test setup. I could tell you the problem and I will if you really want, but a better way is to learn some debugging techniques.

Adding the following line to the register module will show you the state of the bits driving the latch element:

always @(qi, not_qi) $display($time,, in,, set,, qi,, not_qi);

If you don't know, in the Icarus run time (vvp) ^C followed by finish<CR> will stop the simulation. What pattern do you see?The key question here is why is "in" toggling? The answer to that is found by evaluating the connection of the gates at the test level when the top level "in" == 0 (which is not the same as the register "in" signal).


If your gates had some delay the simulation would not lock up at a specific time step, but it will not stop either. You would need to end the test block with clock == 0 or add an explicit $finish.

I hope that helps.

Cary

On Tuesday, April 8, 2014 9:16 AM, Stephen Williams <st...@ic...> wrote:
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Just quickly looking at this...

It appears that you've created an infinitely fast oscillator.
I think you are trying to create an SR flip-flop with the last
two nand gates in your register module, but instead you are getting
meta-stability.

Synchronous logic is not typically modeled in Verilog this way.
This looks like an educational exercise, so you might try getting
more realistic relative timings.

What are you really trying to do?

On 04/08/2014 03:50 AM, Patrick Samy wrote:
> Hello,
> 
> When I perform a simulation of my design with iverilog 0.9.7, it
> seems to be stuck in an infinite loop.
> 
> The original design is a program counter adder with the following
> prototype:
> 
> module program_counter(input enable_count, input enable_overwrite, 
> input[31:0] overwrite_value, output[31:0] out);
> 
> I managed to simplify the verilog testbench code with a D flip flop
> as a 1-bit register and reproduce the issue:
> 
> module register(input in, input set, output out);
> 
> wire not_in; wire qi; wire not_qi; wire not_q;
> 
> nand (qi, in, set);
> 
> not  (not_in, in); nand (not_qi, not_in, set);
> 
> nand (out, qi, not_q); nand (not_q, not_qi, out);
> 
> endmodule
> 
> module test;
> 
> reg  clock; reg  in; wire out; wire not_out;
> 
> // add 'x_out <- out + 1' xor (x_out, out, 1);
> 
> // 2x1 mux with 'in' as value and control bit or  (muxed_out,
> x_out, in);
> 
> register r(muxed_out, clock, out);
> 
> initial begin $dumpfile("test.vcd"); $dumpvars(0, test);
> 
> $display("\tclock,\tin,\tout") ; $monitor("\t%b,\t%x,\t%b", clock,
> in, out);
> 
> // erase internal register #0 in = 1; #0 clock = 1;
> 
> #1 in = 0; #1 clock = 0;
> 
> #2 clock = 1; #3 clock = 0; #4 clock = 1; end
> 
> endmodule
> 
> 
> The VCD output does not show any change of state after the #2
> tick: in== 0 clock == 1
> 
> Therefore, the register is continuously feeded with the result of
> the adder and my guess is that icarus is waiting for the values to 
> stabilize for this tick and gets stuck.
> 
> Can you spot a potential issue with this design ?
> 
> I also posted the issue on StackOverflow to make sure that code is
> correct: 
> http://stackoverflow.com/questions/22900633/infinite-loop-when-simulating-a-program-counter-design-with-icarus-verilog
>
>  Thanks and apologies in advance if this is a stupid mistake on my 
> side, I spent a week trying to figure it out by myself without 
> success.
> 
> Regards,
> 


- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNEIL8ACgkQrPt1Sc2b3inQRQCdFS4YlwoLBY//HVYdzCLUgb00
gvsAoN0R3hxw9IHQFqtnVKaEIJvvmM+y
=p4NY
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Infinite loop on simulation

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Just quickly looking at this...

It appears that you've created an infinitely fast oscillator.
I think you are trying to create an SR flip-flop with the last
two nand gates in your register module, but instead you are getting
meta-stability.

Synchronous logic is not typically modeled in Verilog this way.
This looks like an educational exercise, so you might try getting
more realistic relative timings.

What are you really trying to do?

On 04/08/2014 03:50 AM, Patrick Samy wrote:
> Hello,
> 
> When I perform a simulation of my design with iverilog 0.9.7, it
> seems to be stuck in an infinite loop.
> 
> The original design is a program counter adder with the following
> prototype:
> 
> module program_counter(input enable_count, input enable_overwrite, 
> input[31:0] overwrite_value, output[31:0] out);
> 
> I managed to simplify the verilog testbench code with a D flip flop
> as a 1-bit register and reproduce the issue:
> 
> module register(input in, input set, output out);
> 
> wire not_in; wire qi; wire not_qi; wire not_q;
> 
> nand (qi, in, set);
> 
> not  (not_in, in); nand (not_qi, not_in, set);
> 
> nand (out, qi, not_q); nand (not_q, not_qi, out);
> 
> endmodule
> 
> module test;
> 
> reg  clock; reg  in; wire out; wire not_out;
> 
> // add 'x_out <- out + 1' xor (x_out, out, 1);
> 
> // 2x1 mux with 'in' as value and control bit or  (muxed_out,
> x_out, in);
> 
> register r(muxed_out, clock, out);
> 
> initial begin $dumpfile("test.vcd"); $dumpvars(0, test);
> 
> $display("\tclock,\tin,\tout") ; $monitor("\t%b,\t%x,\t%b", clock,
> in, out);
> 
> // erase internal register #0 in = 1; #0 clock = 1;
> 
> #1 in = 0; #1 clock = 0;
> 
> #2 clock = 1; #3 clock = 0; #4 clock = 1; end
> 
> endmodule
> 
> 
> The VCD output does not show any change of state after the #2
> tick: in== 0 clock == 1
> 
> Therefore, the register is continuously feeded with the result of
> the adder and my guess is that icarus is waiting for the values to 
> stabilize for this tick and gets stuck.
> 
> Can you spot a potential issue with this design ?
> 
> I also posted the issue on StackOverflow to make sure that code is
> correct: 
> http://stackoverflow.com/questions/22900633/infinite-loop-when-simulating-a-program-counter-design-with-icarus-verilog
>
>  Thanks and apologies in advance if this is a stupid mistake on my 
> side, I spent a week trying to figure it out by myself without 
> success.
> 
> Regards,
> 


- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNEIL8ACgkQrPt1Sc2b3inQRQCdFS4YlwoLBY//HVYdzCLUgb00
gvsAoN0R3hxw9IHQFqtnVKaEIJvvmM+y
=p4NY
-----END PGP SIGNATURE-----

[Iverilog-devel] Infinite loop on simulation

[Patrick S. <pat...@gm...>]

Hello,

When I perform a simulation of my design with iverilog 0.9.7, it seems
to be stuck in an infinite loop.

The original design is a program counter adder with the following prototype:

    module program_counter(input enable_count,
                                         input enable_overwrite,
                                         input[31:0] overwrite_value,
                                         output[31:0] out);

I managed to simplify the verilog testbench code with a D flip flop as
a 1-bit register and reproduce the issue:

    module register(input in, input set, output out);

        wire not_in;
        wire qi;
        wire not_qi;
        wire not_q;

        nand (qi, in, set);

        not  (not_in, in);
        nand (not_qi, not_in, set);

        nand (out, qi, not_q);
        nand (not_q, not_qi, out);

    endmodule

    module test;

        reg  clock;
        reg  in;
        wire out;
        wire not_out;

        // add 'x_out <- out + 1'
        xor (x_out, out, 1);

        // 2x1 mux with 'in' as value and control bit
        or  (muxed_out, x_out, in);

        register r(muxed_out, clock, out);

        initial
        begin
            $dumpfile("test.vcd");
            $dumpvars(0, test);

            $display("\tclock,\tin,\tout")
;
            $monitor("\t%b,\t%x,\t%b",
                    clock, in, out);

            // erase internal register
            #0 in = 1;
            #0 clock = 1;

            #1 in = 0;
            #1 clock = 0;

            #2 clock = 1;
            #3 clock = 0;
            #4 clock = 1;
        end

    endmodule


The VCD output does not show any change of state after the #2 tick:
    in== 0
    clock == 1

Therefore, the register is continuously feeded with the result of the
adder and my guess is that icarus is waiting for the values to
stabilize for this tick and gets stuck.

Can you spot a potential issue with this design ?

I also posted the issue on StackOverflow to make sure that code is correct:
http://stackoverflow.com/questions/22900633/infinite-loop-when-simulating-a-program-counter-design-with-icarus-verilog

Thanks and apologies in advance if this is a stupid mistake on my
side, I spent a week trying to figure it out by myself without
success.

Regards,
-- 
Patrick Samy

Re: [Iverilog-devel] Huge FST files

[Cary R. <cy...@ya...>]

I am fairly certain this is a Tony question though which version of Icarus are you using? I don't find "system" and "lxt" in anything that is FST related in the latest development or v0.9.

Cary




On Wednesday, March 19, 2014 3:50 PM, Stephen Williams <st...@ic...> wrote:
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This may be a Cary and/or Tony question. In my day job, we are
running long simulations using FST traces. It appears that the
dumper is cutting files off at 1Gig, though. Is this a feature?
What's weird, it seems to continue in a fresh file, but it is
called system_001.lxt, instead of .fst. Is this correct? Is
there a way to adjust this behavior?

- -- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMqHygACgkQrPt1Sc2b3ilgzQCgiY1HMsJfZ3FiHTn+utcgcnUM
RBMAnj4nX3VGukZBx501m28H58Z/HiIp
=OH1p
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel