Clock Edge notation

[Thomas Kurth]

Hi Allan,

thanks for your answer... No It has become clearer to me.

Greetz,

Thomas

--

No matter if you are going on-piste or off-piste, just hit the slope and
stay healthy!

For mail reply replace "nospam" with "kurth".

 

[Keith R. Williams]

In article <5ed45146.0307140248.61093aa1@posting.google.com>, prv3299
@yahoo.com says...

Hello! I got the following code which obviously creates latches. (It
is not clocked)

CASE ad(10 DOWNTO 4) IS
WHEN b"011_0000" =
CASE ad(3 DOWNTO 1) IS
WHEN "000" => dout <= msacom_reg;
WHEN OTHERS =
END CASE;
WHEN b"011_0001" => dout <= ccm_txd;
WHEN b"011_0010" => IF (rx_page = '0') THEN dout <= ccm_rxd1;
ELSE dout <= ccm_rxd0;
END IF;
WHEN OTHERS =
END CASE;

Dout is also generated by other processes.

If Dout is also generated by other processes, you *must* guarantee that
they don't drive a '1' or '0' into each other. The magic smoke will
be released.

I could clock the process
but then the latency would not be good. Can I add "dout <= (others =
'Z')" to the "WHEN OTHERS" part?

Ok. That gives you a high impedance when none of the other cases is
valid.

BTW, it works good with the latch but
since I always heard a latch is bad I'm not really sure what to do
besides adding a clock (which timing wise, would not be good).

If you don't want the synthesizer to infer latches you must have all
signals defined in all states. Since your Dout is defined in all states
except "others", adding dout to the "when others" clauses (both of
them) should get rid of your unwanted latches.

Remember, latches get inferred when there is a state for which a
variable/signal is undefined. It "remembers" the value it had in the
last state, thus it is latched.

--
Keith

 

[Ken Smith]

In article <5ed45146.0307140248.61093aa1@posting.google.com>,
Paulo Valentim <prv3299@yahoo.com> wrote:
[....]

since I always heard a latch is bad I'm not really sure what to do

Latches are not "bad". If you want a latch they are very good. If you
don't want a latch, the generation of a latch can indicate that there is
an error in your code. If there is no error and you don't want a latch,
the latch can use up hardware needlessly.

Some software doesn't do latches when you'd expect it would. The Cypress
program called "Warp" will sometimes refuse to fit a latch into their
parts.


--
--
kensmith@rahul.net forging knowledge

 

[Tim Hubberstey]

Ken Smith wrote:

In article <5ed45146.0307140248.61093aa1@posting.google.com>,
Paulo Valentim <prv3299@yahoo.com> wrote:
[....]
since I always heard a latch is bad I'm not really sure what to do

Latches are not "bad". If you want a latch they are very good. If you
don't want a latch, the generation of a latch can indicate that there is
an error in your code. If there is no error and you don't want a latch,
the latch can use up hardware needlessly.

Latches *are* bad unless the target technology supports them as a
primitive. Latches that are inferred by code when no latch primitive
exists end up created out of gates. These often have race conditions
that can result in latch failure unless you analyze the timing very
carefully. You often need to add redundant terms to cover the race
conditions which the tools will then strip out unless you can convince
them not to.

Some software doesn't do latches when you'd expect it would. The Cypress
program called "Warp" will sometimes refuse to fit a latch into their
parts.

Probably for the reason I mentioned. They know that their parts don't
have latches and are protecting you from yourself. This isn't a policy I
agree with but I can understand it.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Jay]

Hi all.

I was actually thinking about digital PLLs recently when I was doing
investigation on analog PLLs.

Can someone describe the basic parts and operation of a DPLL?
Essentially these are the components I figured would be needed and this
is how the operation might work, I'd appreciate comments....

1. Phase / Frequency Detector

Standard two-DFF version, UP/DOWN outputs are used to control a
Numerically Controlled Oscillator block.

Input one to the PFD is the signal to be locked onto and input two is
the current output(or an ouput controlled by the DPLL), thus UP/DOWN
tries to drive the error down. UP/DOWN may have to be sychronized,
comments?

A lock signal could be the NAND(UP,DOWN) signals. Thus the output is
true when UP and DOWN are both zero.

Though I wonder, since this is a digital system, will 100% lock ever be
achieved, thus will the lock signal ever light?.

2. NCO

This block is essentially a mod-N counter which, at the end of it's
count, re-loads a count value from a register (perhaps double-buffered).
The register("error counter") is setup to increment or decrement it's
current value depending on the UP/DOWN signal from the Phase/Frequency
detector block.

The mod-N counter is set to count down from the current value, thus, a
smaller value in the counter means a higher frequency. This operation
(should?) emulate a VCO.

If the counter is configured to count down, I would guess that the
"error counter" would have to numerically increment the value it stores
when DOWN is true and numerically decrement with UP is true. I reason
this because there is an inverse relationship between the value stored
in the register and the output frequency (since we're controlling
"time" in terms of clock cycles).

3. Gain

The "error" register could be setup to increment by more than decimal 1,
perhaps by a power of 2 or something. Maybe even a "coarse" and fine
UP/DOWN could be used to get a faster lock.

My guess is that the setup I described emulates a P/I controller since
we could control how much the "error register" changes for an UP/DOWN
"event", thus this control the "P". And since the "error register" has
memory and stores a value even when the system is locked, we have "I".

I'd appreciate any comments on my scheme, what kinds of input clocks I
might need, if there are pitfalls and so on. I haven't actually built
this, but it's just an idea I've been toying with.

Thanks everyone.

-- Jay.

In article <AcIQa.2165$eP6.325075@news20.bellglobal.com>,
look_at_bottom_of@email.com says...

Thanks for all of the responses, it's a great place to get going from.
Having further looked into this analog design it seems as though the analog
phase lock loop IC was being implemented in a circuit that essential is a
frequency lock loop more than anything else. The input signal goes through
this phase lock loop chip and then through a very heavy analog filter which
converts the differential output of the IC to a single ended DC voltage that
then is used to steer a VCO, the VCO output then gets divided down and the
resulting waveform is used to drive the main circuitry (off of which the
reference or input signal is derived).

This being the case if you try to create a digital version of this, your
output waveform is essentially a rock solid wave and since it is driving the
circuit that your reference or input signal is derived from nothing moves,
i.e when you turn it on it is locked almost instantly. If you ideally want
your system frequency to wander slightly (say +/- 200 Hz around a frequency
of say 25000 Hz) according to certain conditions such as temperature,
current, etc. how is that analog type lag created in the digital domain.
Would it just be a delay from input to output or something similar. In
essence what I'm looking for is to create an oscillator that maintains it's
peak amplitude, as temperatures increase (due to circuit current) the tuned
circuits' peak value changes, and the circuit frequency naturally wants to
move to the peak.

Does this make sense? It's an interesting problem, and I don't think that
the answer is very easy. I'm approaching it from a few angles at present.

Once again thanks for the responses.

Jason


"Ray Andraka" <ray@andraka.com> wrote in message
news:3F134720.D19A8BCA@andraka.com...
Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

My all-digital PLL was similar and worked very well. My reference clock
and
system clock were pretty stable so I didn't do a lot of analysis. I
just

 

[Jan De Ceuster]

Dout is also generated by other processes. I could clock the process
but then the latency would not be good. Can I add "dout <= (others =
'Z')" to the "WHEN OTHERS" part? BTW, it works good with the latch but
since I always heard a latch is bad I'm not really sure what to do
besides adding a clock(which timing wise, would not be good). Thanks
a lot.

If you are sure that you never (should) reach the "others" state than
you can also use a don't care statement instead of a high impedance.

I disagree. A 'Z' is a synthesizable value in many logic families.
I've never seen a real '-'. Perhaps it'll work in simulation, but it
won't match the logic. The simulator doesn't know the logic can never
reach this state.

This will tell the synthesis tool that it can do anything with the
"others" state.

If you allow the synthesizer to do "anything" with the others state
then use the "null" others, though you'll get a latch. IMO, incorrect
to use an unrealizable logic state.

You should always be aware of the fact that writing HDL is NOT like
writing software. The WYSIWYG factor in hardware design is much lower
than in software design. It isn't the tools that do the design, it is
you and only you. Tools just help you but they are utterly completely
stupid.

As you should know: std_logic contains much more signal states than
possible in real life. These are usefull for implementing a correct
behaviour. So plainly taking std_logic values as 'real' values is
stupid. You need to understand what they mean in real life. '-' means
"I don't care if the value is logic '1' or logic '0'" Using this in
certain cases (and of course knowing what you're doing) will release
some constrains on the synthesis tool.

Let me take an example similar to the previous one:
architecture rtl of test1 is
begin
process (state, din)
begin
case state is
when "00" =>
dout <= din;
when "01" =>
dout <= '1';
when "10" =>
dout <= '0';
when others =>
end case;
end process;
end rtl;

This is a simple example with a latch on dout. After synthesis you'll
get something like this:
module test1 ( din, dout, state );
input [1:0] state;
input din;
output dout;
wire n_31, n_30, n11, n12, n13;
ND2 U10 ( .A(state[1]), .B(state[0]), .Z(n_31) );
ND2 U11 ( .A(n11), .B(n12), .Z(n_30) );
IV U12 ( .A(state[0]), .Z(n11) );
IV U13 ( .A(state[1]), .Z(n13) );
ND2 U14 ( .A(din), .B(n13), .Z(n12) );
LD1 dout_reg ( .D(n_30), .G(n_31), .Q(dout) );
endmodule

You see some logic to control the latch and the latch itself (LD1)
You have 3 NANDS, 2 invertors and 1 latch.

Now you don't want a latch and use tri-state instead:
architecture rtl of test2 is
begin
process (state, din)
begin
case state is
when "00" =>
dout <= din;
when "01" =>
dout <= '1';
when "10" =>
dout <= '0';
when others =>
dout <= 'Z';
end case;
end process;
end rtl;

The synthesis now does this:
module test2 ( din, dout, state );
input [1:0] state;
input din;
output dout;
wire n15, n16, n17;
tri dout_wire;
assign dout = dout_wire;
ND2 U10 ( .A(state[1]), .B(state[0]), .Z(n17) );
AO6 U11 ( .A(din), .B(n15), .C(state[0]), .Z(n16) );
IV U12 ( .A(state[1]), .Z(n15) );
BTS5 dout_tri ( .A(n16), .E(n17), .Z(dout_wire) );
endmodule

The logic is a bit more simple and still safe (but a tristate buffer
which is huge and slow). Here are 1 NAND, 1 ANDOR, 1 invertor and the
tristate buffer. This is already simpeler.

Now you *know* that state (should) never have value "11" (or else the
system fails anyway). In this case you can use the '-' thingy :

architecture rtl of test2 is
begin
process (state, din)
begin
case state is
when "00" =>
dout <= din;
when "01" =>
dout <= '1';
when "10" =>
dout <= '0';
when others =>
dout <= '-';
end case;
end process;
end rtl;

No latch, no buffers, supperfast and supper simple:
module test ( din, dout, state );
input [1:0] state;
input din;
output dout;
wire n8, n9;
AO7 U7 ( .A(state[1]), .B(n8), .C(n9), .Z(dout) );
IV U8 ( .A(din), .Z(n8) );
IV U9 ( .A(state[0]), .Z(n9) );
endmodule

Just a AND/OR gate and 2 invertors... 'bout 1.5 a 2 times smaller than
the tri-state version...

Works perfectly in the valid states. The output is also a valid
signal, you just don't care what that value might be (in this case it
will be 'not din'). These kinds of things are very good for adress
decoders where you expect to always receive a valid address (or your
system is screwed anyway), for n-bit statemachines with less than 2^n
possible states and so on. Yes I know you can use type enumerations
but I hate using those things in RTL cause it is not flexible enough
(I tend to optimze my state encoding WITHOUT worrying about what the
synthesis tool will do with it). Another way I like to use this is in
shift registers with load/shift-out operation.

Now in simulation a '-' will propagate into active logic if something
does go wrong and then you can easily backtrack it. So no: I don't
expect to use '-' as a 'real' value because you shouldn't...

BTW, I don't realy see the difference between using a latch and a
tri-state buffer. Both (at least in my example) have a level sensitive
enable. So if the input data changes, so does the output (when en is
active).

Anymore questions? Does everybody understand this?

Kind regards,
Jan

 

[Charles M. Elias]

"Brad Smallridge" <bsmallridge@dslextreme.com> wrote in message news:<vh901e9sds8c26@corp.supernews.com>...

Dear folks,

I am a Cypress user and have had the trouble of laying out a board using 134
of what I thought were 136 available I/O lines going into the device. Eight
of these lines were global control or global clocks. I had thought that I
could use all of them but the Warp 6.2 only lets me use 128 I/Os. What
gives? Is there a special declaration I should be using for the global pins?
Do I only get 128 I/Os even though there are 136 I/O pins?

Thanks,

Brad

P.S Details of my discussion with Cypress below:

Created at: 06/20/03 03:45 PM

Part Number: Delta 39K
Product: Programmable Logic > Programmable Logic Devices
Subject: Error with Max IO
Description: I am running Warp6.2 for a 39k100 and get error EMP043
Resource Limit Maximum Number of IO Cells Exceeded (max=128, needed 134)
although I believe this chip should have enough IO.

Brad

Attachments:

Interactions

Cypress Response 07/15/03 08:03 AM | Web
Hi Brad,

I hope we have fully addressed your inquiry. I am closing this case for now,
if you require further assistance on this issue please re-open this case
(using the radio button for Status, Open, and clicking Submit) and we will
be glad to assist you. For all other inquiries please open a new case.


Thank you for using Cypress products,

Cypress Applications Support


Cypress Response | 07/10/03 02:51 PM | Web
Hi Brad,

The global clock and control signal pins are declared as inputs (for OE)
Warp will route these signals as in the 11c signal in your design.


Cypress Applications Support


Customer Comment Brad Smallridge | 07/10/03 11:33 AM | Web
Are there some sort of other pin type assignemnts similar to in, out, or
inout that should be used with the global clock and global control pins?

Cypress Response | 07/07/03 09:33 AM | Web
Hi Brad,

Sorry for all the confusion.

In reference to your response:

The data sheets state that I have 136 IOs available. Is there some sort of
internal architecture that limits me to 128 IOs? What pins may I or may I
not use?

Page 2 of the datasheet states that of the 208 packages. " Device Package
Offering and I/O Count Including Dedicated Clock and Control Inputs", is
136.

Pages 50 thru 56 of the datasheet explain the pins and their functions for
the CY39100V208-200NTC package. If you count the number of pins that can
function as I/O's there are 128. Depending how you configure the I/O's this
number decreases.

Please see application note: Delta39K and Quantum38K I/O Standards and
Configurations

I/O Standards and Configurations


Thank you for your patience


Cypress Applications Support




Customer Comment Brad Smallridge | 07/03/03 12:48 PM | Web
This reply seems non-responsive. The data sheets state that I have 136 IOs
available. Is there some sort of internal architecture that limits me to 128
IOs? What pins may I or may I not use? I think I need a better answer since
I have already committed to, and spent money on, a hardware design.


Cypress Response | 07/02/03 01:51 PM | Web
Hi Brad,

The pin attributes in your design are fine. Whether or not the design can be
fitted to the device depends on the rest of your design which you have
commented out. There are too many floating signals to determine if this
design as coded can be compiled to fit the device.

From what I have been able to determine, you will probably not have enough
I/O's to support your design.


Thank you for your patience


Cypress Applications Support


Customer Comment Brad Smallridge | 07/02/03 09:24 AM | Web
I am not using VCCIO for signals. Perhaps you can look at my VHD pin list
and tell me what pins I can not use?

Cypress Response | 06/30/03 09:09 AM | Web
Hi Brad,

I did try to contact you, I left a msg on your voice-mail.

I hope we have fully addressed your inquiry. I am closing this case for now,
if you require further assistance on this issue please re-open this case
(using the radio button for Status, Open, and clicking Submit) and we will
be glad to assist you. For all other inquiries please open a new case.


Thank you for using Cypress products,

Cypress Applications Support


Cypress Response | 06/27/03 03:20 PM | Web
Hi Brad,

Thank you for using the Cypress On-Line ConnectionCenterT. In reference to:


Error EMP043 Resource Limit Maximum Number of IO Cells Exceeded (max=128,
needed 134) although I believe this chip should have enough IO.

Ans: The available number of I/O's for this device is 128, the additional 8
I/O's (VCCIO) are for power to the I/O banks and not for signals.


Note:

If you limit your design to the use of 128 I/O's it will compile



Thank you for your patience

Cypress Applications Support


Customer Comment Brad Smallridge | 06/27/03 12:03 AM | Web
1) CY39100V208B-200NTC
2) no other errors

VHD file is attached
test08.vhd


Cypress Response | 06/23/03 10:27 AM | Web
Hi Brad,

We are presently looking into your case and will respond as soon as
possible. I want to clarify your issue, "Error with Max IO":

1) What is the entire part description of the device that you are targeting?

2) Are their any other errors being generated by the compiler?


Please include your design files that we may further investigate this issue.


Thank you for your patience

Cypress Applications Support

Brad,

Using the Cypress data, sheet I count 128 IO pins, 4 global clock pins
and 4 global control pins. This does add up to 136 "IO" pins.
However, the global clock pins can be used only for clock signals and,
according to the data sheet, "There are four dedicated inputs
(GCTI[3:0]) that are used as Global Control Signals available to every
IO cell. These global control signals may be used as output enables,
register resets, and register clock enables as shown in figure 8." So
the global control signals are dedicated inputs and the global clocks
can be used only for clocks. This should explain why you are not able
to use 136 pins for general purpose IO.

Best regards,

Charles

 

[Ken Smith]

In article <3F138450.A6B47DAB@no.spam>, Tim Hubberstey <sendme@no.spam> wrote:

Ken Smith wrote:

In article <5ed45146.0307140248.61093aa1@posting.google.com>,
Paulo Valentim <prv3299@yahoo.com> wrote:
[....]
since I always heard a latch is bad I'm not really sure what to do

Latches are not "bad". If you want a latch they are very good. If you
don't want a latch, the generation of a latch can indicate that there is
an error in your code. If there is no error and you don't want a latch,
the latch can use up hardware needlessly.

Latches *are* bad unless the target technology supports them as a
primitive. Latches that are inferred by code when no latch primitive
exists end up created out of gates.

Yes they are created out of gates. This does not mean they are bad.

These often have race conditions
that can result in latch failure unless you analyze the timing very
carefully.

"Latches that are the result of a mistake often have race conitions" I
would agree with. If a latch is what is intended, then it is fair to
assume that the designer has considered the issue of race conditions and,
for example, made sure that the signal that causes the set never overlaps
with the one that causes the reset.

You often need to add redundant terms to cover the race
conditions which the tools will then strip out unless you can convince
them not to.

If you are having to add redundant terms then there is a risk. Not all
latch situations need redundant terms and as such are free of this risk.

Some software doesn't do latches when you'd expect it would. The Cypress
program called "Warp" will sometimes refuse to fit a latch into their
parts.

Probably for the reason I mentioned. They know that their parts don't
have latches and are protecting you from yourself. This isn't a policy I
agree with but I can understand it.

No, it simply is a bug. The CPLD in question has a latch mode in its
macro cell. If they would use it all would be well. The fitter just
simply doesn't try to use the latch mode in some cases where it should.



--
--
kensmith@rahul.net forging knowledge

 

[Tim Hubberstey]

Ken Smith wrote:

In article <3F138450.A6B47DAB@no.spam>, Tim Hubberstey <sendme@no.spam> wrote:
Ken Smith wrote:

In article <5ed45146.0307140248.61093aa1@posting.google.com>,
Paulo Valentim <prv3299@yahoo.com> wrote:
[....]
since I always heard a latch is bad I'm not really sure what to do

Latches are not "bad". If you want a latch they are very good. If you
don't want a latch, the generation of a latch can indicate that there is
an error in your code. If there is no error and you don't want a latch,
the latch can use up hardware needlessly.

Latches *are* bad unless the target technology supports them as a
primitive. Latches that are inferred by code when no latch primitive
exists end up created out of gates.

Yes they are created out of gates. This does not mean they are bad.

These often have race conditions
that can result in latch failure unless you analyze the timing very
carefully.

"Latches that are the result of a mistake often have race conitions" I
would agree with. If a latch is what is intended, then it is fair to
assume that the designer has considered the issue of race conditions and,
for example, made sure that the signal that causes the set never overlaps
with the one that causes the reset.

I think we're talking about two different situations here. I am
referring to D-type transparent latches defined by:

Q <= D when G='1' else Q;

and you seem to be referring to RS flip-flops.

You often need to add redundant terms to cover the race
conditions which the tools will then strip out unless you can convince
them not to.

A D-latch defined this way will often have a race condition on the
falling edge of the gate signal that can cause it to fail to latch under
some conditions and with some technologies. In order to cover this
situation, you need rewrite it and include a redundant term:

Q <= ( G and D) or
(not G and Q) or
( D and Q); -- redundant term

Convincing the synthesizer and/or P&R tools to not strip redundant terms
like this can be quite complex and you can never be sure it won't stop
working after the next rev of the tools. It is also untestable since it
*is* a redundant term. This is why I recommend against inferring
D-latches where the primitive isn't in the library.

Also, latches, either D or RS, tend not to fit into a full-scan
methodology for ASICs which will cause you no end of headaches.

For these reasons, many companies doing ASICs have a blanket policy of
"no latches, ever".
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[spyros]

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

Pedro Claro wrote:

I am sorry Keith, but I can't understand it yet.
Is it or is not possible to have two processes giving values to
a signal at different instants of time?

hi,
i had the same question some time ago.the solution is at:
http://courses.ece.uiuc.edu/ece311/ at the faq.html, where it says:

1. Can more than one process update a signal?

No. This tends to cause race conditions. (Which process should have
updated the signal?)

i read at the other answers that you can do it if you design a
bus-signal.I don't know what is that, so i cannot make a comment.

hope i helped.

- -- spyros

- --

öïéôçôÞò óôï Ä.Ð.È

student @ DUTH

public key: dalab.ee.duth.gr/~spyros/my_pub.asc


-----BEGIN PGP SIGNATURE-----
iQEVAwUBPxjR8z2QMCA0LA8jAQI8qwf/TBTEixWQzcN7AeFuYitgxEwvwz3AGwOk
UW/WdFk/NnJI/GBAfvKmnzk+Ud5UkowGpJvrt6XX5Yk7rtdfXwcwr4XlPho1mhbi
CgPtKq8ZWixIyX/mlhrn7Re/v6+4LnQZvFsMOQp5RPrmAIk0YwmsuRUNi8H+TQDs
u4LGMqP0Xb6FGoY/+6/BAh04YydTtqY5lZ6g1Z2H+gvdSIQqEjQxR5JYj2+LNnxN
2GIvJKoi4CeKEpCF3AQncLQ5Q2lwhB4oq3jiNxy0WcrCLtehZ0BPhwIDYjCiOVoE
1Sb1cpKJQypPvTPbF4XcNHZn/pKNRfxiB6eLvYKCVhtOrD68JRoyYg==yUqm
-----END PGP SIGNATURE-----

 

[Mario Trams]

Matt Gessner wrote:

Hi, all,

I have a question about whether the following is a) synchronous (I believe
it is) and b) advisable:

signal counter: std_logic_vector (4 downto 0);
signal clk: std_logic;
signal cclk: std_logic;

processa: process (clk) is
begin
if rising_edge (clk) then
counter <= counter + 1;
end if;
end process;

cclk <= counter (4);

processb: process (cclk) is
begin
if rising_edge (cclk) then
null; -- do something interesting
end if;
end process;

Part of me screams "No, don't do it!" because I'm making a clock
out of something that's not //really// a clock. Is this is a problem?

Essentially, I'm scaling clk down by 8. In general, is this the
way to do this? Is there something more advisable?

Hi Matt,

when you speak for VHDL, this is definitively not a problem an
is working perfectly.

When you speak for synthesis (FPGAs, CPLDs, etc.), this might be a
problem.
First of all, you should "inform" your synthesis tool that cclk
is a clock so that it uses appropriate routing ressources for that
signal (clock distribution network).
But the more complicated issue is that there is a small phase-shift
between the D-FlipFlops clocked by clk and the ones clocked by cclk.
In fact, cclk comes a little later than clk. In the case when
ordinary signals are exchanged between the two clocking domain your
design might not work. This is especially true for the signals
generated inside the clk domain.

I'm usually go the following way:

processa: process (clk)
begin
if rising_edge (clk) then
counter <= counter + 1;
cclk_dly1 <= cclk;
end if;
end process;

cclk <= counter (4);

processb: process (clk)
begin
if rising_edge (clk) then
if cclk='1' and cclk_dly1='0' then
null; -- do something interesting
end if;
end if;
end process;

That is, everything is clocked by one and the same clock now.
cclk and cclk_dly1 are used as enable for the second part. I.e.
the "interesting stuff" is done only one cycle after cclk turned
high.

NOTE: The stuff above is not a 1:1 replacement for your code due
to the 1-cycle delay!

I hope this helps,
Mario

 

[Mario Trams]

Bob wrote:

Hi,

I am passing in a signal to a component. The signal is not used
but I want to keep it there to have uniformity with other very similar
components. Synthesis gives me a warning, which I would like to
remove.

Do you know of any way that I can remove the warning while still
keeping the input port ?

Hi Bob,

just attach a dummy signal to these ports.
I usually have two signals "high" and "low" that always keep a
'1' or a '0' for such purposes.

Btw., I don't know your design in detail, but leaving inputs
open might cause errors in the later stages of synthesis.

Regards,
Mario

 

[Bob]

Hi Mario,

Thanks for replying.

I am passing a signal "aft" which is a "000" into a component.
Now I don't use it in the component, but I pwant to keep it in
the port map. Synthesis tells me the signal is not used, but I
would like to avoid getting this synthesis warning while still
keeping the signal in the port map....If I set it to something in the
component, it'll give another warning...any ideas. ?


stenasc@yahoo.com (Bob) wrote in message news:<20540d3a.0307211358.7ff6699d@posting.google.com>...

Hi,

I am passing in a signal to a component. The signal is not used
but I want to keep it there to have uniformity with other very similar
components. Synthesis gives me a warning, which I would like to
remove.

Do you know of any way that I can remove the warning while still
keeping the input port ?

Thanks

Bob

 

[Mario Trams]

Hi Bob,

I am passing a signal "aft" which is a "000" into a component.
Now I don't use it in the component, but I pwant to keep it in
the port map. Synthesis tells me the signal is not used, but I
would like to avoid getting this synthesis warning while still
keeping the signal in the port map....If I set it to something in the
component, it'll give another warning...any ideas. ?

Ahhh, that's the issue - sorry.

But this warning is something you have to deal with. It is
a "friendly" remainder of your synthesis tool just to let you
know that these ports are not used, actually.

The only way to get rid of these warnings would be some
option of the synthesis tool like "-dont_warn_for_unused_ports".
But I doubt that there is such an option (check your user's manual).
Perhaps there is some option to skip all warnigns, but that's
perhaps not what you want.

What about piping stdout through some standard tools like grep
and remove these warnings in that way?

Regards,
Mario

 

[Charles M. Elias]

mgessner@yahoo.com (Matt Gessner) wrote in message news:<909a6ea3.0307211437.1f27387@posting.google.com>...

Hi, all,

I have a question about whether the following is a) synchronous (I believe
it is) and b) advisable:

signal counter: std_logic_vector (4 downto 0);
signal clk: std_logic;
signal cclk: std_logic;

processa: process (clk) is
begin
if rising_edge (clk) then
counter <= counter + 1;
end if;
end process;

cclk <= counter (4);

processb: process (cclk) is
begin
if rising_edge (cclk) then
null; -- do something interesting
end if;
end process;

Part of me screams "No, don't do it!" because I'm making a clock
out of something that's not //really// a clock. Is this is a problem?

Essentially, I'm scaling clk down by 8. In general, is this the
way to do this? Is there something more advisable?

I look forward to your insights.

Thanks -- Matt
Matt,

I don't think your logic is wrong, but here is another (generic)
approach. This is derived from From FAQ complang.vhdl part 1. I
added some features that can be omitted if not needed. It produces a
symmetric output waveform if "Modulus" is even, otherwise it stays low
for one input clock period
longer than it stays high. Below is the entity/architecture for the
clock component. If you don't need the enable or reset, just omit
them from the component declaration.

--------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.all;
--------------------------------------------------------------------------------
entity clock_divider is
generic(modulus: in positive range 2 to integer'high);
port( clk_in : in std_logic;
enable : in std_logic := '1';
reset : in std_logic := '0';
clk_out : out std_logic );
end clock_divider;

architecture behavior of clock_divider is
begin
process (clk_in, reset, enable )

variable count: natural range 0 to modulus - 1;

begin
if reset = '1' then
count := 0;
clk_out <= '0';
elsif rising_edge( clk_in ) then
if enable = '1' then
if count = modulus - 1 then
count := 0;
else
count := count + 1;
end if; --count = modulus - 1
else
count := count;
end if; --enable = '1'
if count >= modulus/2 then
clk_out <= '0';
else
clk_out <= '1';
end if; --count >= modulus/2
end if; --rising_edge( clk_in )
end process;
end behavior;

 

[Jerold Green]

This is not synchronous. You are using a ripple carry as a clock. This is
a bad idea because this clock is slightly delayed. If the inputs to
processb are clocked by clk, they may be in transition when cclk changes.

To make this synchronous, make a carry output
carry <= '1' when counter = "1111";


Then in processb, use carry as an enable:
processb: process (clk) is
begin
if rising_edge (clk) then
if (carry = '1') then
null; -- do something interesting
end if;
end if;
end process;

This is fully synchronous.

"Matt Gessner" <mgessner@yahoo.com> wrote in message
news:909a6ea3.0307211437.1f27387@posting.google.com...

Hi, all,

I have a question about whether the following is a) synchronous (I believe
it is) and b) advisable:

signal counter: std_logic_vector (4 downto 0);
signal clk: std_logic;
signal cclk: std_logic;

processa: process (clk) is
begin
if rising_edge (clk) then
counter <= counter + 1;
end if;
end process;

cclk <= counter (4);

processb: process (cclk) is
begin
if rising_edge (cclk) then
null; -- do something interesting
end if;
end process;

Part of me screams "No, don't do it!" because I'm making a clock
out of something that's not //really// a clock. Is this is a problem?

Essentially, I'm scaling clk down by 8. In general, is this the
way to do this? Is there something more advisable?

I look forward to your insights.

Thanks -- Matt

 

[Weng Tianxiang]

The problem is resolved with help from Altera field engineer Mark
Vanderzalm.

I set the right option for project in ModelSim, but two individual
files have their own option windows that take precedence over project
option window setting, causing trouble:

Right project option window setting:
"Use 1993 Language Syntex" = 1
"Using explicit Declaration Only" = 0

Wrong file option window setting(never thought there are individual
file compiler option setting):
"Use 1993 Language Syntex" = 0
"Using explicit Declaration Only" = 1

That causes ModelSim compiler to fail to recognize X"xxx" bit string
for wrong setting files.

Thank you.

Weng

wtx@umem.com (Weng Tianxiang) wrote in message news:<511e4538.0307221510.5f71d7ee@posting.google.com>...

Hi,
Thank you for your help.

I checked that two compilation options are same:
Use 1993 Language Syntax and all Report Warnings On.

I had attached the error information:
ERROR: C:/PCI-CORE/pci-core/B5460_Window_66MHz_debug_5B86.vhd(425):
Type error in bit string literal. Type std_logic_vector is not an
array of bit.
Essentially ModelSim cannot recognize std_logic_vector.
The files are same and in same compiler order.
If my files lack a ieee's liberary, it should have failed for any
compilations.

Weng

"Stan Zaborowski" <stan@zaborowski.org> wrote in message news:<vho7561qukdn13@corp.supernews.com>...
Are you sure that you are compiling with the same options? In particular,
are you compiling one set with VHDL 86 and one with VHDL 03?

In VHDL 93 the following would be legal,

signal hex_string : std_logic_vector(7 downto 0);
begin
hex_string <= X"AF";

In VHDL 86, it is not legal because X"AF" is a bit string.

If this is not your problem, please show us the statements that don't
compile.


"Weng Tianxiang" <wtx@umem.com> wrote in message
news:511e4538.0307210844.59a558ed@posting.google.com...
I have a problem while creating a new project from ModelSim:
1. Same set of files is compiled on two different directory;
2. In Old directory that works for over 3 years compilation is
successful without any errors;
3. I created a new project using the same set of files, but it fails.

4. The problem is if my files lack some liberay definitions, it would
fail at all compilations. But in one directory it works, another new
fails.

Thank you.

Weng

The following is the description of compilation results.

The old project is compiled well without any errors:

# Compile of M_T_State.vho was successful.
# Compile of ReadFIFO.vhd was successful.
# Compile of WriteFIFO.vhd was successful.
# Compile of B5460_Window_66MHz_debug_5B86.vhd was successful.
# Compile of TestSDRAM_B5460_5B8.vhd was successful.
# 5 compiles, 0 failed with 0 error(s).

When new project is created, it has errors with the same files:

# Compile of M_T_State.vho was successful.
# Compile of ReadFIFO.vhd was successful.
# Compile of WriteFIFO.vhd was successful.
# Compile of B5460_Window_66MHz_debug_5B86.vhd failed with 3 errors.
# Compile of TestSDRAM_B5460_5B8.vhd failed with 2 errors.
# 5 compiles, 2 failed with 5 error(s).

ERROR: C:/PCI-CORE/pci-core/B5460_Window_66MHz_debug_5B86.vhd(425):
Type
error in bit string literal. Type std_logic_vector is not an array of
bit.
ERROR: C:/PCI-CORE/pci-core/B5460_Window_66MHz_debug_5B86.vhd(426):
Type
error in bit string literal. Type std_logic_vector is not an array of
bit.
ERROR: C:/PCI-CORE/pci-core/B5460_Window_66MHz_debug_5B86.vhd(427):
Type
error in bit string literal. Type std_logic_vector is not an array of
bit.
ERROR: C:/PCI-CORE/pci-core/B5460_Window_66MHz_debug_5B86.vhd(428):
Type
error in bit string literal. Type std_logic_vector is not an array of
bit.
ERROR: C:/PCI-CORE/pci-core/B5460_Window_66MHz_debug_5B86.vhd(429):
Type
error in bit string literal. Type std_logic_vector is not an array of
bit.
ERROR: C:/PCI-CORE/pci-core/B5460_Window_66MHz_debug_5B86.vhd(430):
Type
error in bit string literal. Type std_logic_vector is not an array of
bit.
ERROR: C:/PCI-CORE/pci-core/B5460_Window_66MHz_debug_5B86.vhd(431):
Type
error in bit string literal. Type std_logic_vector is not an array of
bit.

 

[John Moore]

vlint, no, but I'm sure you know that emacs can 'beautify' vhdl code.

John Moore

 

[Mike Treseler]

Weng Tianxiang wrote:

The problem is resolved with help from Altera field engineer Mark
Vanderzalm.

I set the right option for project in ModelSim, but two individual
files have their own option windows that take precedence over project
option window setting, causing trouble:

Right project option window setting:
"Use 1993 Language Syntex" = 1
"Using explicit Declaration Only" = 0

Wrong file option window setting(never thought there are individual
file compiler option setting):

It makes no sense to me either.
This is the main reason I use modelsim only for simulation,
not compilation. Once a file is compiled as -87 it is
branded for life. Consider emacs vhdlmode or vcom scripts for
compilation.


-- Mike Treseler

 

[Allan Herriman]

On Fri, 25 Jul 2003 13:37:52 +0200, "Willem Oosthuizen"
<willy@asic.co.za> wrote:

Hi,

I there a place where handy VHDL functions/procedures can be posted
/retrieved on the web? The more code I write, the more handy functions I
develop.
It would be nice to be able to share these. I am not talking about VHDL RTL
source code, but more of packages. Functions like Random, Integer_fit_Bits
etc.

"Random" is in the package ieee.math_real that is probably already
available in your simulator.

It has this prototype:
procedure UNIFORM (variable Seed1,Seed2:inout integer; variable
Xut real);


Integer_fit_Bits presumably is the same as the various log2 functions
that have been posted in this newsgroup many times.


What other handy functions do you have?

Bye,
Allan.