Clock Edge notation

[HT-Lab]

On 27/07/2011 13:36, hssig wrote:

Is there a possibility to use that tool under Windows (7) ? How do I
have to install it?

Cheers,
hssig

As suggested earlier why don't you simply use vmake from Modelsim?

Vmake can be used without a valid license (just extract after running
the installer). Use vcom (also no valid license required) to compile
your design followed by running vmake.

You can now use any make program under windows (I use nmake from Visual
C++) to process it.

Vmake can also handle Verilog files but unfortunately not SystemC.

Good luck,

Hans
www.ht-lab.com

 

[Paul Uiterlinden]

HT-Lab wrote:

On 27/07/2011 13:36, hssig wrote:
Is there a possibility to use that tool under Windows (7) ? How do I
have to install it?

Cheers,
hssig


As suggested earlier why don't you simply use vmake from Modelsim?

The major difference of course between vmake and a program like vmk is that
vmake creates a makefile from already compiled libraries and that vmk
creates a makefile directly from the VHDL sources.

So for the initial compilation vmk must be used. Or manual compilation, and
optional use of the vcom option "-just eapbc" and wildcards for the VHDL
files. But that does not always work, for example if packages uses other
packages from the same library.

For keeping libraries up to date vmake might be more convenient to use.

I use both vmake and vmk.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[hssig]

Hi Hans,

do you have a real example to share in which you use vmake from
Modelsim ?


Cheers, Hssig

 

[HT-Lab]

On 28/07/2011 13:32, hssig wrote:

Hi Hans,

do you have a real example to share in which you use vmake from
Modelsim ?


Cheers, Hssig

Hi Hssig,

If you have Modelsim installed then you can use one of their examples:

Navigate to ..\examples\tutorials\vhdl\basicSimulation, then execute

vlib work
vcom *.vhd
vmake > Makefile
nmake

modify one of the VHDL files and run nmake/make etc again. I would
recommend you have a quick look at the vmap command as well as you might
need it.

Good luck,

Hans.
www.ht-lab.com

 

[hssig]

Hi Hans,

I have tried to run the example. But when typing "vmake > Makefile" I
get the error message:
# The vmake utility must be run from a Unix shell or a Windows/DOS
prompt.

I am using Modelsim PE 10.0b


Cheers, Hssig

 

[Jonathan Bromley]

On Sat, 30 Jul 2011 04:07:57 -0700 (PDT), hssig <hssig@gmx.net> wrote:

I have tried to run the example. But when typing "vmake > Makefile" I
get the error message:
# The vmake utility must be run from a Unix shell or a Windows/DOS
prompt.

Well, it's hard to see how the error message could be
any clearer

Obviously you're running from within ModelSim's GUI, or Tcl
console. Fortunately Tcl comes to your rescue here:

exec vmake > Makefile

should do what you want. Of course, you *could* perhaps
RTFM and run vmake directly from the command prompt...

PS: exec is Tcl's command to run an external program. It does
a pretty good job of faking-up the environment to fool the
program into thinking it has been run from the DOS prompt.
--
Jonathan Bromley

 

[Anssi Saari]

Paul Uiterlinden <puiterl@notaimvalley.nl> writes:

I use both vmake and vmk.

Now that we're on the topic, what's a good make tool to use with vmake
on Windows? Gnu make included in Cygwin doesn't seem to like the
generated makefiles... I've been using make from unxutils, but it
seems to have a problem with time and imagines my files have a
modification time in the future and so on. It works, though.

 

[Enrik Berkhan]

Anssi Saari <as@sci.fi> wrote:

Now that we're on the topic, what's a good make tool to use with vmake
on Windows? Gnu make included in Cygwin doesn't seem to like the
generated makefiles...

Have you tried vmake's `-cygdrive' (IIRC) command line option?

Enrik

 

[Anssi Saari]

Enrik Berkhan <enrik.berkhan@inka.de> writes:

Anssi Saari <as@sci.fi> wrote:

Now that we're on the topic, what's a good make tool to use with vmake
on Windows? Gnu make included in Cygwin doesn't seem to like the
generated makefiles...

Have you tried vmake's `-cygdrive' (IIRC) command line option?

I take it that option is either new or non-existing? I'm using
Modelsim 6.5 and 6.6.

The specific error message from Gnu Make 3.81 in Cygwin is
Makefile:153: *** multiple target patterns. Stop.

On line 153 and onwards I have:

$(WORK__altera_tb) \
$(WORK__altera_tb__behavior) : altera_tb.vhd \
$(IEEE__std_logic_1164)
$(VCOM) -93 -O0 altera_tb.vhd

Anyways, looks like I stumbled on a working make:

GNU Make 3.82
Built for i386-pc-mingw32

I.e. the one included with mingw.

 

[Paul Uiterlinden]

Anssi Saari wrote:

Paul Uiterlinden <puiterl@notaimvalley.nl> writes:

I use both vmake and vmk.

Now that we're on the topic, what's a good make tool to use with vmake
on Windows?

Sorry, I don't know. I don't use Windows.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[Bart Fox]

On 12.08.11 10:28, wrote Anssi Saari:

The specific error message from Gnu Make 3.81 in Cygwin is
Makefile:153: *** multiple target patterns. Stop.

On line 153 and onwards I have:

$(WORK__altera_tb) \
$(WORK__altera_tb__behavior) : altera_tb.vhd \
$(IEEE__std_logic_1164)
$(VCOM) -93 -O0 altera_tb.vhd
There is a ":" in $(IEEE__std_logic_1164), right?

Anyways, looks like I stumbled on a working make:

GNU Make 3.82
Built for i386-pc-mingw32

I.e. the one included with mingw.
Make 3.80 should also work with DOS-colons in path names.

regards,
Bart

 

[Enrik Berkhan]

Anssi Saari <as@sci.fi> wrote:

Enrik Berkhan <enrik.berkhan@inka.de> writes:
Have you tried vmake's `-cygdrive' (IIRC) command line option?

I take it that option is either new or non-existing? I'm using
Modelsim 6.5 and 6.6.

I'm using an Altera Modelsim ASE OEM version, obviously based on 6.6d.
The header line in the generated Makefiles says 'vmake 2.2'.

$ vmake -h
Usage: vmake -help
vmake [-fullsrcpath] [-cygdrive] [-nolinewrap] [-f <filename>]
[-ignore <design_unit>] [-du <design_unit>] [<library>] [>
<makefile>

on Windows 7.

Without `-cygdrive', vmake genrates something like this:

....
LIB_IEEE = C:/altera/11.0/modelsim_ase/win32aloem/../ieee
....

This variable introduces the spurious colon in the rules when expanded,
leading to the error you described.

With `-cygdrive', the line reads:

....
LIB_IEEE = /cygdrive/c/altera/11.0/modelsim_ase/win32aloem/../ieee
....

and everything will work fine with make under Cygwin.

What vmake does not handle correctly though are path names containing
spaces.

Enrik

 

[Anssi Saari]

Enrik Berkhan <enrik.berkhan@inka.de> writes:

Anssi Saari <as@sci.fi> wrote:
Enrik Berkhan <enrik.berkhan@inka.de> writes:
Have you tried vmake's `-cygdrive' (IIRC) command line option?

I take it that option is either new or non-existing? I'm using
Modelsim 6.5 and 6.6.

I'm using an Altera Modelsim ASE OEM version, obviously based on 6.6d.
The header line in the generated Makefiles says 'vmake 2.2'.

OK. I only checked Modelsim 6.5, there was no -cygdrive there. But
yes, 6.6 has it. So, multiple solutions already. Thanks.

 

[Anssi Saari]

Paul Uiterlinden <puiterl@notaimvalley.nl> writes:

Sorry, I don't know. I don't use Windows.

Damn, it's a long time since I've been able to say that, even
professionally. At least documentation has in recent years been Wrod
always, even if real work was done in Linux.

You hiring?-)

 

[Paul Uiterlinden]

Anssi Saari wrote:

Paul Uiterlinden <puiterl@notaimvalley.nl> writes:

Sorry, I don't know. I don't use Windows.

Damn, it's a long time since I've been able to say that, even
professionally.

I pitty you.

At least documentation has in recent years been Wrod
always, even if real work was done in Linux.

You hiring?-)

Not personally.
You might check the WEB addres in my signature, although there are no direct
vacancies at the moment. And the location is the Netherlands. But I don't
see that as a problem.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[glen herrmannsfeldt]

In comp.lang.verilog Matt <maplante80@gmail.com> wrote:

I've been looking over the following post concerning parallel crc
computation and how to handle a multi-byte parallel bus where the data
can end in any 8b position:
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/587b14d0fc43dbc1

I haven't thought about the wide parallel CRC for a while, but...

All of the identities Allan calls out make perfect sense,
except when I try

#5.) If the CRC register is initialised to zero,
CRC(A & B) = CRC(CRC(A) & B))

My guess is that this is the case for the beginning of the
calculation, where some bytes are zeroed out.

With most CRC functions, CRC(0)==0, which my guess is what
he is using. Note the condition that it be initialized to zero.
That only matters at the beginning.

But for just this reason, most CRC's do not initialize to zero,
as it will give the same result for missing X'00' bytes
at the beginning.

As far as doing it for odd byte combinations, my first thought
is to compute it through the end, and then undo the last bytes.
The operation has an inverse, so you can cancel out the bytes at
the end that you don't want. You might be able to do that at
the beginning, too. Keep the complicated logic outside the
critical path.

-- glen

 

[Mark Curry]

In article <1953c27e-95f4-4be6-9c95-209a061f0184@vd8g2000pbc.googlegroups.com>,
Matt <maplante80@gmail.com> wrote:

I've been looking over the following post concerning parallel crc
computation and how to handle a multi-byte parallel bus where the data
can end in any 8b position:
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/587b14d0fc43dbc1

All of the identities Allan calls out make perfect sense, except when
I try
#5.) If the CRC register is initialised to zero,
CRC(A & B) = CRC(CRC(A) & B))

If I use some some test code, and the easics crc generator (http://
www.easics.com/webtools/crctool) :
snip

While not directly answering your question, I'll add my 2 cents.

I commented on this before, but I do it again - I really don't like tools such as
those on easics web site. CRCs in verilog or VHDL are dead-nuts simple. Using
those tools leads to more confusion and obtuse code than not.

A great reference for crcs is:
http://www.ross.net/crc/download/crc_v3.txt

For HW guys - don't read past chapter 8. After chapter 8, the doc is all about
optimizing the calcs in SW. For HW, it's really simple - just code up the
algorithm shown in chapter 8, and put a for loop in it for the number of bits
you need. Done.

Now you know that basics, there's two references that can help for the
special cases you've got:

J. Satran, D. Sheinwald, and I. Shimony, "Out of Order Incremental CRC Computation"
IEEE Transactions on Computers, Vol. 54, No. 9, September 2005.

and

M. Walma, "Pipelined Cycle Redundancy Check (CRC) Calculation". Intel Corporation
(My paper is lacking a clear reference, but it looks to be from some
IEEE doc published in 2007)

Both these papers have some great ideas to do creative things with CRCs, including
similar to what you're trying to do.

Regards,

Mark

 

[Matt]

Hi Glen,

Yes, the idea is to rotate the unwanted bits following the frame (set
to zero) to the front of the word. The CRC initialized with 0 won't
change as a result. If I understand Allen correctly, he then goes on
to state that you shift in the previous word's CRC (thinking serially,
even though it's a parallel operation), followed by the last few data
bytes of the frame. This is where I'm having the problem. I assume
the intent is to load the lfsr with the old crc data, and then shift
in the remaining data bytes, but it doesn't appear to work the way I'm
attempting to do it.

What's the inverse operation you mentioned?

Thanks,

-- Matt


On Feb 8, 5:24 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

In comp.lang.verilog Matt <maplant...@gmail.com> wrote:

I've been looking over the following post concerning parallel crc
computation and how to handle a multi-byte parallel bus where the data
can end in any 8b position:
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/587b1...

I haven't thought about the wide parallel CRC for a while, but...

All of the identities Allan calls out make perfect sense,
except when I try
#5.) If the CRC register is initialised to zero,
CRC(A & B) = CRC(CRC(A) & B))

My guess is that this is the case for the beginning of the
calculation, where some bytes are zeroed out.

With most CRC functions, CRC(0)==0, which my guess is what
he is using. Note the condition that it be initialized to zero.
That only matters at the beginning.

But for just this reason, most CRC's do not initialize to zero,
as it will give the same result for missing X'00' bytes
at the beginning.

As far as doing it for odd byte combinations, my first thought
is to compute it through the end, and then undo the last bytes.
The operation has an inverse, so you can cancel out the bytes at
the end that you don't want. You might be able to do that at
the beginning, too. Keep the complicated logic outside the
critical path.

-- glen

 

[KJ]

On Thursday, March 29, 2012 12:17:35 PM UTC-4, Matthew Jeschke wrote:

8 years ago I studied VHDL quite extensively in college.

Now I've been hired by a small company as their resident expert and
I'm finding I have to relearn everything all over again... I'm sure
my mistakes are novice but I'm not even sure where to go for help.

Attached below is what I've written and it has all sorts of issues
with it. It should be a simple 15 minute project but it's taken me
over a day and I'm getting frustrated lol Any feedback would be
greatly appreciated, I'm not sure where else to start. Are there any
good reference books you guys would recommend?

- The "if rising_edge(clock)" must be the outermost statement
- Don't use rising and falling edges (this is a digital design rule, not VHDL)

Other than that, you never stated exactly what problem you're having so I'm not going to try to figure it out for you.

Kevin Jennings

 

[Tricky]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.ALL;
use IEEE.std_logic_arith.ALL;

Std_logic_arith and numeric_std packages clash and will cause you problems if you try and use unsigned or signed types. std_logic_arith is non-standard VHDL and should not be used. Numeric_std is the real standard.

The story is origionally VHDL had no way to handle signed/unsigned arithmatic. Synpopsys wrote std_logic_unsigned/signed and std_logic_arith, which became a defacto standard across the industry. The VHDL working group then wrote numeric_std and released it as part of the IEEE VHDL standard in 1993. Unfortunatly it took a while for vendors to latch on to the real standard, as well as many many engineers and text book writers.