Timer ...

[Niall]

Howdy all.

I'm essentially trying to make a clock. Here's the code I have, I'll
explain my problems later on (I'm very new to VHDL, so if there are
any design issues with this or whatever, let me know, please):



LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY clock IS
PORT( en : IN STD_LOGIC;
per_time : IN TIME;
clk : OUT STD_LOGIC );

END ENTITY clock;

ARCHITECTURE clock_arch OF clock IS
BEGIN
clocking : PROCESS ( en, per_time ) IS
VARIABLE temp : STD_LOGIC := '1';

BEGIN
IF en = '1' THEN
FOR i IN 0 TO 100 LOOP

clk <= temp AFTER per_time;
temp := NOT temp;

END LOOP;
END IF;
END PROCESS clocking;

END ARCHITECTURE;



And here's some testing code:



LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY clock_tb IS
END ENTITY;

ARCHITECTURE clock_tb_arch OF clock_tb IS
SIGNAL en : STD_LOGIC;
SIGNAL per_time : TIME;
SIGNAL clk : STD_LOGIC;

BEGIN
thing : ENTITY WORK.clock( clock_arch )
PORT MAP ( en, per_time, clk );

stimulous : PROCESS IS
BEGIN
per_time <= 1 NS;
en <= '0';

WAIT FOR 10 NS;

en <= '1';
WAIT FOR 100 NS;

WAIT;

END PROCESS stimulous;

END ARCHITECTURE;



What I'd like this to do is when the enable port is '1' I'd like the
clk port to change state 100 times (This is just for learning, I'll
modify it to suit my needs when they arise, so it serves no use at the
moment). However, I don't get the expected wave signal. Once the
enable port goes high the clk port follows it after 1 ns and doesn't
vary as I hoped it would. This is an image of the outputted waves -
http://twomers.googlepages.com/VHDL_CLOCK_WAVE.JPG

Does anyone know why this is happening, and if so could they suggest a
remedy?

Thanks

 

[Jonathan Bromley]

I'm essentially trying to make a clock.

"Clock" as in "clock signal to run some other design",
as opposed to "thing that tells me whether it's lunchtime"
(I presume)?

Here's the code I have, I'll
explain my problems later on (I'm very new to VHDL, so if there are
any design issues with this or whatever, let me know, please):

Firstly, all credit to you for two things:
(1) an intelligent attempt to package your clock oscillator
as a module over which you can exercise useful control,
(2) a sensible sanity-check test harness for your new module.

But there is something you REALLY need to know.....

***
the execution of a signal assignment, even one with an
AFTER delay, consumes no time
***

Rather, the AFTER delay postpones the signal-update until
the appropriate time after your assignment executes.

So in your clock generator process

clocking : PROCESS ( en, per_time ) IS
VARIABLE temp : STD_LOGIC := '1';
BEGIN
IF en = '1' THEN
FOR i IN 0 TO 100 LOOP
clk <= temp AFTER per_time;
temp := NOT temp;
END LOOP;
END IF;
END PROCESS clocking;

the 101 iterations of your loop will all take place at
the same time instant, with each one overwriting (and
deleting) the planned future signal update created by
the previous one. Consequently, you just see the effect
of a SINGLE signal assignment using the value of "temp"
as it was at the beginning of the last pass through the
loop.

Generally, the following advice is useful - not mandatory,
just useful guidelines:

- When writing a simulation-only stimulus generation process
like this, don't give it a sensitivity list. It's easier
to control its operation with explicit WAIT statements.
- Stimulus generation is often best performed by using
WAIT FOR delay statements to achieve the timing,
WAIT UNTIL statements to detect changes on external
control signals, and zero-delay signal assignments
to update your output signals.

Here's a rewrite of your clock generator process that
follows my own advice and, I think, achieves more-or-less
what you want:

clocking: process
begin
-- Initialise the clock output at time 0.
clk <= '0';
-- Infinite loop here, so we can restart after we're done.
loop
-- Don't (re)start until enable goes true. Note that
-- "wait until" is edge-sensitive, so requires a change
-- on "en" to trigger it.
wait until en = '1';
-- Generate the required 100 toggles on clk
-- (makes 50 pulses, back to zero when done)
for i in 1 to 100 loop
-- Sanity check that period is not silly
assert (per_time > 0 ns)
report "Zero clock period!" severity ERROR;
-- delay
wait for per_time;
-- toggle clock
clk <= not clk;
end loop; -- end of for loop
end loop; -- end of infinite loop
end process clocking;

And here's some testing code:

which, I think, is just fine - although you might like to
extend it to test whether you can successfully re-trigger
the clock generator.

Finally, two post-scripts:
(1) spare my pedantic groans by spelling "stimulus" correctly -
sorry, I know I'm not allowed to say that, but it HURT in
an otherwise impeccably well-written post!!!
(2) double-check: this is testbench, simulation-only code, yes?
You will not successfully synthesise to hardware anything
that has time delays in it.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Dave Pollum]

Howdy all.

I'm essentially trying to make a clock. Here's the code I have, I'll
explain my problems later on (I'm very new to VHDL, so if there are
any design issues with this or whatever, let me know, please):

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY clock IS
PORT( en : IN STD_LOGIC;
per_time : IN TIME;
clk : OUT STD_LOGIC );

END ENTITY clock;

ARCHITECTURE clock_arch OF clock IS
BEGIN
clocking : PROCESS ( en, per_time ) IS
VARIABLE temp : STD_LOGIC := '1';

BEGIN
IF en = '1' THEN
FOR i IN 0 TO 100 LOOP

clk <= temp AFTER per_time;
temp := NOT temp;

END LOOP;
END IF;
END PROCESS clocking;

END ARCHITECTURE;

And here's some testing code:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY clock_tb IS
END ENTITY;

ARCHITECTURE clock_tb_arch OF clock_tb IS
SIGNAL en : STD_LOGIC;
SIGNAL per_time : TIME;
SIGNAL clk : STD_LOGIC;

BEGIN
thing : ENTITY WORK.clock( clock_arch )
PORT MAP ( en, per_time, clk );

stimulous : PROCESS IS
BEGIN
per_time <= 1 NS;
en <= '0';

WAIT FOR 10 NS;

en <= '1';
WAIT FOR 100 NS;

WAIT;

END PROCESS stimulous;

END ARCHITECTURE;

What I'd like this to do is when the enable port is '1' I'd like the
clk port to change state 100 times (This is just for learning, I'll
modify it to suit my needs when they arise, so it serves no use at the
moment). However, I don't get the expected wave signal. Once the
enable port goes high the clk port follows it after 1 ns and doesn't
vary as I hoped it would. This is an image of the outputted waves -http://twomers.googlepages.com/VHDL_CLOCK_WAVE.JPG

Does anyone know why this is happening, and if so could they suggest a
remedy?

Thanks

Niall;

In "clock_arch", you've written the code as if it is software.
Remember VHDL is a Hardware Description Language. So while "clk <=
temp AFTER per_time;" is valid for a test bench, it isn't valid for
synthesis (creating hardware). The "after some_time" implies a
hardware
one-shot (i.e. 74LS123) which does not exist in CPLDs or FPGAs. I
like to think of a CPLD or FPGA as a board that contains lots of logic
gates (AND, OR, XOR, etc) and Flip Flops. VHDL describes how those
gates and flip-flops are "wired". That mental picture helps me avoid
many newbie mistakes.

If you are trying to generate a specific frequency, then start with
connecting a clock oscillator to your CPLD/FPGA. A 50Mhz oscillator
is used on many deveopment/starter boards. Your VHDL logic can then
divide 50Mhz down to whatever frequency you need. To simulate this,
your test bench must create a 50Mhz signal.

I recommend 2 books:
1) "Essential VHDL RTL Synthesis Done Right" by Sundar Rajan. This
book gently gets you into VHDL, introducing new keywords as it goes.
It also shows logic diagrams for the VHDL examples.
2) "RTL Hardware Design Using VHDL" by Pong P.Chu. This book assumes
you know some digital design. It goes into more detail than Rajan's
book, and it covers far more topics than Rajan's book. It also shows
logic diagrams for the VHDL examples.

Many people recommend "The Designer's Guide to VHDL" by Peter J.
Ashenden. This was my first book, and I found it to be overwhelming.
It starts with describing the entire VHDL language, and then moves
into VHDL code. It's a good reference book, though.

There is lots of VHDL info on the web. The VHDL FAQ lists a bunch of
useful sites.

HTH
-Dave Pollum

 

[Niall]

I actually got "The Designer's Guide to VHDL" from work ... yesterday
or the day before. It seems good - I've read a fair amount of
programming books, granted not Hardware ones, so I hope, at least,
that I'm of the right frame of mind to keep up with the concepts it
introduces. I'm not afraid to work to grasp what's being talked
about.
It's my first time doing hardware programming really - I'm used to C/C+
+ and other such languages. At the moment I'm literally just trying to
get the basics of the language down before I actually start to do
anything on an FPGA etc. I'll think more "Hard Ware" if I can in
future

Thanks for the book recommendations! I'll keep an eye out for
them ...





My internet connection crashed before I could post this (in response
to the first response):

Thanks, Jonathan Bromley, for your reply, and I am indeed sorry for my
spelling. Indeed, I corrected it in the initial test code that I
posted, not the above code, but noticded that I had to change
something, went back to the editor, changed it, tested it, didn't give
errors so I copied it to the browser. I changed "stilmulous" to "stim"
but that was overwritten by the newer code which I, shamefully admit,
I forgot to correct. And yes, it is indeed a clock signal to run
another design ... which may tell me when lunch time comes! I don't
know for sure yet.

Does the sensitivity list disable the WAIT command?
That would be referring to the first code I posted? I did not know
that, but I had some thoughts of the sort after testing my code - I
thought I just had the semantics of the script wrong. I shall remember
that. Thank you.

I wrote your code out again, I learn best that way - anyone can C&P,
but I'm getting an error (which I was getting all along. I overcame it
before with the temp variable bit, see code#1. I didn't know why I
needed it but from it's position I assumed you couldn't test the value
of an OUT port, which seemed ludicrous):

ERROR: port "clk" cannot be read

Which points to this line:

clk <= NOT clk;

Any ideas on why that is there?

I also changed a line of your code: WAIT FOR ABS per_time; and
asserted per_time=0 ns. What are the benefits of assert over if?

And yes, this is merely test-bench-simulation-only code.

 

[Jonathan Bromley]

Thanks, Jonathan Bromley, for your reply, and I am indeed sorry for my
spelling.

Ah phooey - I'm just a grumpy old pedant! And you should see
SOME of the spelling we get here....

Does the sensitivity list disable the WAIT command?

A process can have EITHER a sensitivity list OR one or more
wait statements. They're mutually exclusive. A sensitivity
list is in fact exactly equivalent to putting the statement
wait on <sensitivity-list>;
as the very last statement in the process - in other words,
the process executes once at time 0, then waits for any
change on any signal in the sensitivity list before looping
back to the top of the process again. In 100% of cases,
synthesisable (hardware) processes HAVE a sensitivity list
because the rules of the synthesisable subset of VHDL demand it.
In 99% of cases, simulation processes don't - but it can
occasionally be useful even for testbenches.

I wrote your code out again, I learn best that way - anyone can C&P,
but I'm getting an error (which I was getting all along. I overcame it
before with the temp variable bit, see code#1. I didn't know why I
needed it but from it's position I assumed you couldn't test the value
of an OUT port, which seemed ludicrous):

ERROR: port "clk" cannot be read

Oops, my bad. Moral: test before posting, even if you think
you know what you're doing
Yes, it is indeed illegal to read an output port. It is, to
say the least, an irritatingly bureaucratic feature. Your variable
trick is one possible solution. Another is to declare a signal
inside the architecture, manipulate that signal, and then -
in a separate, stand-alone process - copy your internal signal
out on to the port. You can do that with a concurrent assignment
statement in the architecture body:

clk <= internal_clk;

which is exactly shorthand for the mini-process

process (internal_clk)
begin
clk <= internal_clk;
end process;

I also changed a line of your code: WAIT FOR ABS per_time; and
asserted per_time=0 ns.

urrm, assert per_time /= 0 ns, surely?

What are the benefits of assert over if?

Assert throws an error when its boolean expression is false.
But it also prints a bunch of useful information that makes it
very clear to you (a) that you got an error; (b) whereabouts
in the simulation hierarchy the error occurred - very useful if
you have multiple instances of a module; (c) the simulation time
at which the error occurred. You *could*, with some effort, get
all of that from an if statement - but assert gives it to you
for nothing. Also, synthesis tools completely ignore asserts,
which makes them very useful for including simulation-only
error checks in a synthesisable design.

And yes, this is merely test-bench-simulation-only code.

Excellent.

Good luck
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On Sat, 12 May 2007 16:37:21 +0100, Jonathan Bromley

.... a post with two small fibs in it. Sorry....


~~~~~~~~~~~~~ Fib #1:

In 100% of cases,
synthesisable (hardware) processes HAVE a sensitivity list
because the rules of the synthesisable subset of VHDL demand it.

Yeah, well, sort-of. There *is* a synthesis style, supported
by some tools, in which you write a process with no sensitivity
list and then explicitly wait for an active clock edge.
I don't like it, for a variety of reasons.


~~~~~~~~~~~~~~ Fib #2:

synthesis tools completely ignore asserts

Again, sort-of. An assert that tests only constant values
*may* be checked by synthesis. This can be useful when you
write very configurable designs (using generics or package
constants) and you want synthesis to check that the user
of your configurable design hasn't screwed-up the
configuration by applying some impossible set of parameters.

It's obviously not my day for writing things like "100%" and
"completely ignore" :-(
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Niall]

Hi again. Sorry to be a nuisance but I have two other questions
somewhat related to the above problem.

I want to use my the clock in other applications so I decided I'd try
putting the output of the entity into one of the terminals of an and
gate that I made with inputs i0 and i1 and output q. The and gate
works just fine - I tested it well and the logic graphs show that it
works as it should. However it doesn't work as I would have expected
when I 'tie' the clk output port to either of the input ports of the
and gate. Here is the code I'm using -


LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY and_clock_tb IS
END ENTITY and_clock_tb;

ARCHITECTURE and_clock_tb_arch OF and_clock_tb IS
SIGNAL i0, i1, q, en, clk : STD_LOGIC;
SIGNAL per_time : TIME;
BEGIN
and_gate_0 : ENTITY WORK.and_gate( and_gate_arch )
PORT MAP( i0, i1, q );
clock_0 : ENTITY WORK.clock( clock_arch )
PORT MAP( en, per_time, clk );

stim_tb : PROCESS IS
BEGIN
en <= '1';
per_time <= 2 NS;

i0 <= clk; -- Q(i) here
i1 <= clk; -- and here
WAIT FOR 100 NS;
-- so I can see it work

en <= '0'; -- Q(ii)

WAIT;
END PROCESS stim_tb;
END ARCHITECTURE and_clock_tb_arch;


The clock works just fine, thanks to the replies I got earlier today,
but when I "i0 <= clk;" it doesn't work as I expected. Here's my graph
- http://twomers.googlepages.com/and_clock_troubles.JPG The input
ports seem to be undefined, that's what X signifies, right? I would
have expected them to rise and fall with my clock. Am I wrong in
thinking that? It seems similar to a problem I was getting earlier ...
WAIT problems again? I know I could simply AND the clock with itself,
but that's not the purpose of the exercise - I want to get entities to
interact with each other. I also tried my temp trick from earlier, but
to no avail.

My second question is this - If I compile the above code without the
line "en <= '0';" near the end it goes on compiling forever, or at
least for a very long time. This is because of how I have my clock
structured, I believe, as it keeps on ticking when it's enabled, so
the only way to stop it is to disable it. It makes sense, but for my
testbenchs do ye reckon I'll always have to do something like that if
I use the clock to stop the process? Is there a more elegant way to
accomplish cessation?

 

[Jonathan Bromley]

Hi again. Sorry to be a nuisance but I have two other questions
somewhat related to the above problem.

No nuisance. I'm having trouble sleeping

I want to use my the clock in other applications so I decided I'd try
putting the output of the entity into one of the terminals of an and
gate that I made with inputs i0 and i1 and output q.

Fair enough.

[snip code]

The clock works just fine, thanks to the replies I got earlier today,
but when I "i0 <= clk;" it doesn't work as I expected. Here's my graph
- http://twomers.googlepages.com/and_clock_troubles.JPG The input
ports seem to be undefined, that's what X signifies, right? I would
have expected them to rise and fall with my clock. Am I wrong in
thinking that?

Yes, you are. Your assignments

i0 <= clk;
i1 <= clk;

are in the testbench process, right? And they execute at time 0,
before you got around to doing any delays? So each of those lines
takes a copy of the value of clk at time 0 - that'll be X, or maybe
U, depending on various details - and drops that copy on to i0 and i1.
Procedural code in a process executes just the once, at the moment
it executes - if you see what I mean. A single statement has no
lasting effect (there are exceptions to this, but it's a Good Lie).

Now, I imagine that you really wanted to CONNECT clk to both i0
and i1 so that they continuously follow its value. That is a
somewhat different problem.

Easiest fix:
~~~~~~~~~~~~
Take those two assignments and put them OUTSIDE the process
(but still in the same architecture). They then become
"concurrent signal assignments" which automatically re-evaluate
themselves and re-assign a new value to their target whenever
their right-hand-side expression (clk) changes its value.

Neater fix:
~~~~~~~~~~~
Get rid of signals i0,i1 completely and connect the clock directly
to both inputs in the port map:

architecture....
signal clk: std_logic;
...
begin
clockgen: entity work.clock( clock_arch )
PORT MAP( en, per_time, clk );
and_gate_0 : ENTITY WORK.and_gate( and_gate_arch )
PORT MAP( clk, clk, q );

This is, I hope, the fundamental answer to your question about
how to get entities working together: Use signals to
hook them up. There is absolutely no need for the signal
names to match the port names. Indeed, if you're being
picky you can specify both port and signal names in the
port map:

and_gate_0: ENTITY WORK.and_gate( and_gate_arch )
PORT MAP( i0 => clk, i1 => clk, q => q );

The syntax of named port maps is (portname => signalname, ...)

My second question is this - If I compile the above code without the
line "en <= '0';" near the end it goes on compiling forever,

I guess you mean *simulating* forever

or at
least for a very long time. This is because of how I have my clock
structured, I believe, as it keeps on ticking when it's enabled, so
the only way to stop it is to disable it. It makes sense, but for my
testbenchs do ye reckon I'll always have to do something like that if
I use the clock to stop the process? Is there a more elegant way to
accomplish cessation?

This is a problem that troubles ALL testbench writers.

The simulator will run on until it has no more work to do, i.e.
it has no future signal changes scheduled. If you have a
continuous clock generator, obviously it always has a signal
change planned for the near future so it will never stop.
A stoppable clock generator like yours is one entirely
workable solution. Another is to nuke the simulation at
some time of your own choosing:

sim_stopper: process
begin
wait for 20 us;
assert FALSE
report "This is the programmed end of sim"
severity FAILURE;
end process;

Finally you can use the simulator's command-line
interface to run simulation for a limited time, instead
of running to completion.

In any reasonably complicated testbench, deciding when to
stop automatically is an important and non-trivial problem.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Niall]

That's great! It works fine now. I should have thought of that. What I
was trying to do, now that I think of it, was move wires around during
the simulation which isn't very intelligent Well, I guess you'd be
very intelligent to come up with a method of doing it, physically
speaking. Switches could simulate such behaviour, I guess, but then
you have to connect the output port of the switch/mux to the input of
the gate which defeats the whole purpose ... Anyway.

One last question.

I like to organise my projects so I have a GHDL (I'm using ghdl and
gtkwave), folder and inside that there are lots of different little
project folders - and_gate, clock, mux, etc. When I simulate each VHDL
file by itself they work fine but if I try to use one entity, say
clock, in another entity, say and_gate as I did above, I get this
error - "ghdl: cannot load entity "clock"". Which is fair enough -
different folders etc, so I copied and pasted my clock code to the
and_gate's folder compiled/simulated the lot and it worked fine like
that.

It's not a nice solution.

There's gotta be a better way to use "things in things" than copying
and pasting the first "thing" into the second "thing's" folder,
compiling and simulating "thing" one, repeat and stir as you see fit
for the second "thing". Can I point my file to say "../clock/
clock.vhdl", maybe not the vhdl file. Libraries? Can I add entities to
libraries as I make projects and do something like

LIBRARY Niall;
USE Niall.ALL;

in some code I want to test?

Thanks again for your replies. They've been extremely ... excellent.

 

[Jonathan Bromley]

Can I add entities to
libraries as I make projects and do something like

LIBRARY Niall;
USE Niall.ALL;

in some code I want to test?

Yes, most definitely.

The key to this is discovering how your tool maps VHDL
library names (like Niall, above) onto real physical
libraries - which, for almost all tools, are in fact
directories. I'm ashamed to say that I have no idea
how to do that with ghdl. Once you've achieved that,
you can run your VHDL tool in absolutely any location,
tell it about the library mappings you want, and then
compile any source file (regardless of its location)
into any library. Then you can pull stuff together
by writing library/use clauses as you suggest, and
of course specifying the right library in each
entity instantiation:

some_instance: entity some_library.some_entity ...

Note that the library that you are currently compiling
into, on any given compilation run, always has the
alias name WORK - it's usually a good idea *not* to
have a real library called WORK, to avoid confusion.
So, when you say

some_instance: entity WORK.some_entity ...

you are in fact saying "seek the already-compiled
entity some_entity in the same library into which
I'm compiling this code right now". Again, the
precise way to specify the working library (i.e.
the library where compilation results will be
saved) is tool-specific and I don't know how to
do it in ghdl.

You are climbing the learning curve alarmingly
quickly - you'd better slow down, or we'll have
no chance of selling you a training course
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[KJ]

There's gotta be a better way to use "things in things" than copying
and pasting the first "thing" into the second "thing's" folder,
compiling and simulating "thing" one, repeat and stir as you see fit
for the second "thing". Can I point my file to say "../clock/
clock.vhdl", maybe not the vhdl file. Libraries? Can I add entities to
libraries as I make projects and do something like

In addition to Jonathon's suggestion, you might consider starting to use a
source control system like Subversion. That way you can organize all of
your independent little 'things' into their own separate projects and the
bigger 'things' that call out the smaller things are yet another separate
project that references each of the little things. Then you simply get the
bigger thing and it will pull also pull out the smaller things
automatically. If you have a basic understanding of source control systems
and linking projects this will probably make some sense, if not then you may
be scratching your head wondering what I'm talking about.

The basic idea though is that the source control system can (should) be
organized to handle functional blocks that perform some useful function.
When you want to create a new thing that happens to build on these
previously built and tested blocks you don't copy them in, you simply
reference the functional blocks you want to use in the source control
system. When you then tell the source control system to 'get' this new
thing it will also automatically get the lower level blocks.

KJ

 

[Niall]

Well, that makes sense and I assumed that it should be possible. I've
been scouring the GHDL manual (http://ghdl.free.fr/ghdl/index.html),
for info on creating my own library. The closest thing I came up with
was this - http://ghdl.free.fr/ghdl/Starting-with-a-design.html which
makes a work directory so that you can keep all the info you want in
work. I think I may be able to manipulate this to make little
libraries. I think it's for large projects so one doesn't fill their
drive ... seems unnecessary ... but I really feel there should be a
neater method.

Are there any other tools (free I'm poor), which ye are familiar
with which do what I want. Either ones which work with the files
themselves or ones which do the whole process that GHDL does - I'm
apathetic one way or another about GHDL. It does what it should. Could
I use Subversion with the files that GHDL created to create the
libraries? Do libraries have a special file extension?

I know what you mean, KJ, don't worry

 

[KJ]

Are there any other tools (free I'm poor), which ye are familiar
with which do what I want.

Not sure just what all you want, but Subversion is free (link below)
http://subversion.tigris.org/

Either ones which work with the files
themselves or ones which do the whole process that GHDL does - I'm
apathetic one way or another about GHDL. It does what it should. Could
I use Subversion with the files that GHDL created to create the
libraries?

Subversion is used to organize your source files, it doesn't care what
you're organizing or what tool you're using or anything. It has nothing to
do with any language, it is simply a version control repository, you can put
anything you want into it.

From your question earlier, iiseemed like that what you were thinking about
was how to organize whatever stuff you create so that you don't do dumb
'copy files from here to there' types of things as you build up your library
of things. That's good that you're thinking that way, and a source control
tool is what you're looking for. That allows you to properly link your
little projects into bigger ones. GHDL (or any other tool you choose) then
interacts with the files that you get when you check those source files out.

Do libraries have a special file extension?

Don't know, in Modelsim each library gets its own folder and you have to
create it via a Modelsim command (i.e. it is more than simply creating a
folder using the operating system).. Personally I don't create my own
libraries, things I create almost without exception get compiled into the
'work' library. Compiling into a library other than 'work' is useful if
you're using two entities that have the same name but do different things
and you need to use them both. That situation doesn't come up very often,
but for some it might. My guess from what I've seen is that what you're
doing probably won't benefit from compiling into a unique VHDL library, just
put it into 'work'.

KJ

 

[Martin Thompson]

Yeah, well, sort-of. There *is* a synthesis style, supported
by some tools, in which you write a process with no sensitivity
list and then explicitly wait for an active clock edge.
I don't like it, for a variety of reasons.

Hi Jonathan,

I imagine you are taling about processes like:

process
begin
wait until rising_edge(clk);
--- do stuff
end process;

Can you elucidate on the reasons for disliking it? I've commented
before on the fact that it save a level of indent over the "if
rising_edge(clk)" form, which is a benefit in my view. I haven't seen
anydownsides, except maybe for tool support, which is a non-issue to
me, as my tools support it (as long as I don't bury the wait inside a
Mike Treseler-style "tick" procedure!)

Thanks in advance!

Martin

 

[Brian Drummond]

Compiling into a library other than 'work' is useful if
you're using two entities that have the same name but do different things
and you need to use them both.

Not if you're using certain versions of ISE it isn't...
(6.1 and 7.1 both; _might_ have been fixed in 8/9)

It ignores the explicit library names in your source, and embedded
configurations, and those libraries you had to build by hand, and
simply uses the first entity it can find with that name throughout the
design!

That situation doesn't come up very often,
but for some it might.

One example is combining two previously separate projects into one shiny
new large FPGA.

- Brian

 

[Jonathan Bromley]

Hi Jonathan,

I imagine you are taling about processes like:

process
begin
wait until rising_edge(clk);
--- do stuff
end process;

Can you elucidate on the reasons for disliking it? I've commented
before on the fact that it save a level of indent over the "if
rising_edge(clk)" form, which is a benefit in my view. I haven't seen
anydownsides, except maybe for tool support, which is a non-issue to
me, as my tools support it

Martin,

it's probably just prejudice - I did a bit of work with the late-90s
behavioural synthesis tools and rapidly gained a hearty distaste
for implicit state machines, for at least two main reasons:
the extreme ugliness of implementing asynch reset, and the
equally extreme messiness of implementing any kind of global
action such as a pipe-stall. And inline clock-waits are, for
me, tarnished by association with implicit state machines.

That dislike is kinda hypocritical, I guess, for someone who
claims - as I do - to be fond of a communicating-sequential-
processes style of organising designs.

C'mon, I'm old enough now for you all to indulge me when I
express unjustifiable but fervently-held opinions
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Can you elucidate on the reasons for disliking it? I've commented
before on the fact that it save a level of indent over the "if
rising_edge(clk)" form, which is a benefit in my view. I haven't seen
anydownsides, except maybe for tool support, which is a non-issue to
me, as my tools support it (as long as I don't bury the wait inside a
Mike Treseler-style "tick" procedure!)

I would note that I use these "tick" waits only for simulation.

For synthesis, I stick with the template.
This is a matter of style, not substance.
I prefer to handle updates to enumeration
variables as I would counts or shifts.
I only use one "if rising_edge(clk)" per entity,
so saving an indent level is not an issue.

-- Mike Treseler

 

[Martin Thompson]

I would note that I use these "tick" waits only for simulation.

Yes, I just thought I would try and aggravate my synthesis tool

For synthesis, I stick with the template.
This is a matter of style, not substance.
I prefer to handle updates to enumeration
variables as I would counts or shifts.
I only use one "if rising_edge(clk)" per entity,
so saving an indent level is not an issue.

As my eyes get worse, I have to use bigger fonts - I'm planning ahead
for when I have to use 30 pt Courier

Cheers,
Martin

 

[Martin Thompson]

C'mon, I'm old enough now for you all to indulge me when I
express unjustifiable but fervently-held opinions

Fair enough

Cheers,
Martin