Clock Edge notation

[HT-Lab]

"Jim Lewis" <jim@synthworks.com> wrote in message
news:m8CdnWbmA5PECrbVnZ2dnUVZ_jednZ2d@posted.easystreetonline...

KJ wrote:
"Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message
news:g0fsiu$80g6@cnn.xsj.xilinx.com...
...


The good news is that the functions maximum and minimum are
language defined in the Accellera VHDL-2006 / IEEE VHDL-2008 (yet
to be balloted) for all numeric (and scalar) types.

I would recommend submitting a bug report to the tool vendor
if they have not implemented them yet. Warning, if you don't
do this, then they think you are not interested in the new
standard.

I can't agree more with Jim, look at the supported language constructs and
you will soon agree with me that we need this standard ASAP!

Come on guys speak to your favourite EDA vendor/distributor and log an
Enhancement Request (ER) to have this standard supported. I have already
done this for Modelsim but it seems I am one of the few :-(

Hans
www.ht-lab.com

Best,
Jim

 

[Uwe Bonnes]

Mike Treseler <mike_treseler@comcast.net> wrote:

rickman wrote:

One of these days I am going to try moving over to open source
software. There has to be something out there that is better than
this.

There are open-source projects, but nothing ready
for serious work. The best value on a commercial
simulator is the oem modelsim that comes with
a quartus license.

Mike,

did you try Iverilog lately?

--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Uwe Bonnes]

Mike Treseler <mtreseler@gmail.com> wrote:

Uwe Bonnes wrote:

Mike,
did you try Iverilog lately?

I have tried it. Mr. Williams has done an amazing job.
But I am mainly a vhdl guy, and for or my work,
a mixed-mode simulator is a huge advantage.

Probably not a way you want to go, but on the iverilog list was a discussion
recently about VHDL-Verilog converters.
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Uwe Bonnes]

Mike Treseler <mtreseler@gmail.com> wrote:

Uwe Bonnes wrote:

Mike,
did you try Iverilog lately?

I have tried it. Mr. Williams has done an amazing job.
But I am mainly a vhdl guy, and for or my work,
a mixed-mode simulator is a huge advantage.

Probably not a way you want to go, but on the iverilog list was a discussion
recently about VHDL-Verilog converters.
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[HT-Lab]

"Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message
news:g106qt$cl410@cnn.xsj.xilinx.com...

Is it possible to pass generics into a package file? A lot of the
constants in my package file are dependent upon an INPUT_WIDTH generic in
my main file.
-Kevin

Not until VHDL2006/8 becomes available, see example below copied from one of
Jim Lewis' presentations:

package MuxPkg is
generic( type array_type) ;
function Mux4 (
Sel : std_logic_vector(1 downto 0);
A : array_type ;
B : array_type ;
C : array_type ;
D : array_type
) return array_type ;
end MuxPkg ;
package body MuxPkg is
.. . .
end MuxPkg ;

library ieee ;
package MuxPkg_slv is new work.MuxPkg
Generic map (array_type => ieee.std_logic_1164.std_logic_vector) ;

library ieee ;
package MuxPkg_unsigned is new work.MuxPkg
Generic map (array_type => ieee.numeric_std.unsigned
) ;

http://www.synthworks.com/papers/index.htm

Hans
www.ht-lab.com

 

[KJ]

"jens" <roden@rochester.rr.com> wrote in message
news:0d73662d-b39b-43a9-a19f-e5c38227c35d@2g2000hsn.googlegroups.com...

then it will work. As you no doubt know, those are two big 'ifs' that
you need to get the answer to before using it. If not, then you'll
need to provide some external signal (even an otherwise unused signal
pulled up or down to a valid logic level will do the trick) to provide
the 'external reset' to the FPGA.

That would be quite a trick! An unused pull-up/down will either
hold the FPGA in perma-reset or not provide a reliable power-on
reset. The only way to generate a reliable power-on reset for an FPGA
that doesn't have its own is to use a carefully designed analog reset
or use an IC that's designed to do that.

The trick is that the external reset pin is not really providing a reset,
the logic level that it's providing is always a 'not reset'...but the code
in the FPGA doesn't know that. To provide an internal logic reset at power
up without an external (carefully designed reset) IC you need a device and
tool set that supports assignment of initial values.

signal Reset_Shift_Reg: std_ulogic_vector(3 downto 0) := (others => '1');
....
Fpga_Reset <= Reset_Shift_Reg(3);

where Reset_Shift_Reg will shift in a constant of '0' into the low end.
This will give you a couple clock cycle wide Fpga_Reset signal. But if your
synthesis tools are too smart in their optomization they could optomize the
whole shift register thing away replacing it with '0' and essentially
prevent you from getting any reset.

If that situation arises, then usually you can work around this by adding
attributes to tell it not to optomize the shift register logic. If that
still doesn't work then you could change your code so that the input from
the shift register is not a constant of '0' but instead comes from a pin
(that you pull down on the board, nothing fancy needed). In that situation
the synthesis tool would not be able to optomize anything the shift register
would remain intact. Since the pin is pulled to the 'not reset' logic level
it will get shifted through bringing the FPGA out of reset.

I used this trick once before years ago when the stars aligned just so
meeting all of the criteria that I mentioned. Now-a-daze the tools might
not be so unforgiving so you might not need this idea, but it does work and
works reliably as well.

Yes, I have successfully designed a non-carefully designed analog
reset.

You should've thought of it as a carefully designed 'not reset' instead

Kevin Jennings

 

[KJ]

"jens" <roden@rochester.rr.com> wrote in message
news:0d73662d-b39b-43a9-a19f-e5c38227c35d@2g2000hsn.googlegroups.com...

then it will work. As you no doubt know, those are two big 'ifs' that
you need to get the answer to before using it. If not, then you'll
need to provide some external signal (even an otherwise unused signal
pulled up or down to a valid logic level will do the trick) to provide
the 'external reset' to the FPGA.

That would be quite a trick! An unused pull-up/down will either
hold the FPGA in perma-reset or not provide a reliable power-on
reset. The only way to generate a reliable power-on reset for an FPGA
that doesn't have its own is to use a carefully designed analog reset
or use an IC that's designed to do that.

The trick is that the external reset pin is not really providing a reset,
the logic level that it's providing is always a 'not reset'...but the code
in the FPGA doesn't know that. To provide an internal logic reset at power
up without an external (carefully designed reset) IC you need a device and
tool set that supports assignment of initial values.

signal Reset_Shift_Reg: std_ulogic_vector(3 downto 0) := (others => '1');
....
Fpga_Reset <= Reset_Shift_Reg(3);

where Reset_Shift_Reg will shift in a constant of '0' into the low end.
This will give you a couple clock cycle wide Fpga_Reset signal. But if your
synthesis tools are too smart in their optomization they could optomize the
whole shift register thing away replacing it with '0' and essentially
prevent you from getting any reset.

If that situation arises, then usually you can work around this by adding
attributes to tell it not to optomize the shift register logic. If that
still doesn't work then you could change your code so that the input from
the shift register is not a constant of '0' but instead comes from a pin
(that you pull down on the board, nothing fancy needed). In that situation
the synthesis tool would not be able to optomize anything the shift register
would remain intact. Since the pin is pulled to the 'not reset' logic level
it will get shifted through bringing the FPGA out of reset.

I used this trick once before years ago when the stars aligned just so
meeting all of the criteria that I mentioned. Now-a-daze the tools might
not be so unforgiving so you might not need this idea, but it does work and
works reliably as well.

Yes, I have successfully designed a non-carefully designed analog
reset.

You should've thought of it as a carefully designed 'not reset' instead

Kevin Jennings

 

[KJ]

"rickman" <gnuarm@gmail.com> wrote in message
news:b1a28872-157b-4bcd-9eba-500508459339@k37g2000hsf.googlegroups.com...

On May 23, 12:56 am, "KJ" <kkjenni...@sbcglobal.net> wrote:

where Reset_Shift_Reg will shift in a constant of '0' into the low end.
This will give you a couple clock cycle wide Fpga_Reset signal. But if
your
synthesis tools are too smart in their optomization they could optomize
the
whole shift register thing away replacing it with '0' and essentially
prevent you from getting any reset.

If the synthesis software "optimizes" the shift register away, it is
not optimizing, it is malfunctioning. When tools optimize, they
replace circuitry with equivalent circuitry which uses less
resources. Obviously no shift register is not equivalent to a shift
register in this case. The tools won't optimize this away.

A shift register that has an input of '0' can be optomized away and simply

replaced with '0' if that shift register has no non-'0' initial values
specified. A tool that doesn't support initial values will do exactly that.
I agree that the tools "shouldn't" do that, but you would be wrong in
assuming that they "won't" do that. Some not to be named tools used to do
just that, one should verify before assuming that the particular tool that
you're using doesn't do that.

This...
q <= d when rising_edge(clock)
d <= '0';

is equivalent to this...
q <= '0';

If you have...
signal q: std_ulogic;

but not if you have...
signal q: std_ulogic := '1';

The method I was tossed out was a way to generate a synchronous reset
without any input pins but it requires support from both the device and the
tools...without both it won't work. It's also useful in generating multiple
resets that are each synchronous to some internal set of clocks (i.e.
reset_clk1, reset_clk2, etc.)

The problem is that the global async reset provided in an FPGA is not
at all useful as a global async reset. Or more accurately, it is not
a very good release from reset. It has to be released from reset
synchronously to prevent part of a state machine from starting without
the rest of it.

That's why I don't bother with async resets at all unless it presents some
actual advantage in terms of logic/routing usage in the particular device
I'm targetting (generally it does not)....the reset signal still needs to be
generated synchronously....and then those dang dual clock fifos...sigh...oh
well.

Kevin Jennings

 

[HT-Lab]

<dejfson@gmail.com> wrote in message
news:fa17637b-3631-4238-9b79-2061f475e3cb@m73g2000hsh.googlegroups.com...

Dear Experts,
i'd like to introduce to my design one register containing a firmware
revision. Very probably the firmware revision would be a data when the
VHDL code was checked out from the CVS repository where I store the
project.

The problem I encounter is how to translate the CVS last-commit data
of the project currently checked out, and translate it into VHDL code
to be a part of the project.

Example:

yesterday i committed at the end of day the whole project, thus when I
check it out today and burn, one of the registers I export should
contain yesterday's date as a firmware revision

i check out the project corresponding to a date 2 weeks ago, the
firmware register should contain a number corresponding to date at
which the version of the project I have checked out was committed.

This would allow very easily match the firmware and CVS source
together.....

any ideas how to do it?

thanks
david

Can't you use the $Id$/$Revision$ string in your source file and translate
that to a date/version constant with a bit of Tcl?

This might help you a bit :
http://www.ht-lab.com/freeutils/date2hdl/date2hdl.html

Hans
www.ht-lab.com

 

[HT-Lab]

<dejfson@gmail.com> wrote in message
news:fa17637b-3631-4238-9b79-2061f475e3cb@m73g2000hsh.googlegroups.com...

Dear Experts,
i'd like to introduce to my design one register containing a firmware
revision. Very probably the firmware revision would be a data when the
VHDL code was checked out from the CVS repository where I store the
project.

The problem I encounter is how to translate the CVS last-commit data
of the project currently checked out, and translate it into VHDL code
to be a part of the project.

Example:

yesterday i committed at the end of day the whole project, thus when I
check it out today and burn, one of the registers I export should
contain yesterday's date as a firmware revision

i check out the project corresponding to a date 2 weeks ago, the
firmware register should contain a number corresponding to date at
which the version of the project I have checked out was committed.

This would allow very easily match the firmware and CVS source
together.....

any ideas how to do it?

thanks
david

Can't you use the $Id$/$Revision$ string in your source file and translate
that to a date/version constant with a bit of Tcl?

This might help you a bit :
http://www.ht-lab.com/freeutils/date2hdl/date2hdl.html

Hans
www.ht-lab.com

 

[Symon]

"Florian" <FloXXX@yahoo.com> wrote in message news:g1erc2$5gp$1@aioe.org...

Hi

I have combinational logic that evaluates some logic expressions and to do
so it needs to compare some values that are stored in registers. The
simulation works as intended but when I take a closer look at the single
bits of a 32-bit wide register I can see that I have some bits that are
1 when the clock raises to high and goes than immediatelly back to ZERO.
Looks like a glitch in some way, as the bit doesnt remain the state until
the next rising clock. As I said, the simulation works but I cant figure
out what causes these peaks. Can somebody perhaps guide me how to trace
such a problem or can I ignore this?

Many thanks!
Flo

http://en.wikipedia.org/wiki/Hazard_%28logic%29
http://en.wikipedia.org/wiki/Synchronous_system
http://en.wikipedia.org/wiki/Static_timing_analysis

 

[Symon]

"Florian" <FloXXX@yahoo.com> wrote in message news:g1erc2$5gp$1@aioe.org...

Hi

I have combinational logic that evaluates some logic expressions and to do
so it needs to compare some values that are stored in registers. The
simulation works as intended but when I take a closer look at the single
bits of a 32-bit wide register I can see that I have some bits that are
1 when the clock raises to high and goes than immediatelly back to ZERO.
Looks like a glitch in some way, as the bit doesnt remain the state until
the next rising clock. As I said, the simulation works but I cant figure
out what causes these peaks. Can somebody perhaps guide me how to trace
such a problem or can I ignore this?

Many thanks!
Flo

http://en.wikipedia.org/wiki/Hazard_%28logic%29
http://en.wikipedia.org/wiki/Synchronous_system
http://en.wikipedia.org/wiki/Static_timing_analysis

 

[KJ]

"rickman" <gnuarm@gmail.com> wrote in message
news:b0860289-99bb-4a45-a0cd-87e84935e868@p25g2000hsf.googlegroups.com...

On May 28, 10:25 am, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> wrote:
rickman schrieb:


I had taken another look at Ben's code and found something I don't
understand. I see the same thing in your code. Maybe I have
forgotten something, but I thought a process had to either have a
sensitivity list, contain a loop or it would only be run once. Both
your code and Ben's have no sensitivity list and no loop. What am I
missing here?

A loop is not required. A process must contain either a sensitivity list or
a wait statement. All processes automatically 'restart' when they exit, the
only wait to have something run once is with an unconditional 'wait;' at
some point.

KJ

 

[Symon]

"Philip Herzog" <phu@arcor.de> wrote in message
news:483E67A1.3050204@arcor.de...

Hi!

I'm trying to get Xilinx ISE 9.2 to synthesize a shift register for a
Spartan 3E. I'm down to copying this code:


And yes, Shift register extraction and logical shifter extraction in the
HDL options are checked.

Please, help me before I go mad...

- Philip
--
Machen Sie sich erst einmal unbeliebt, dann werden
Sie auch ernst genommen. (Konrad Adenauer)

Hi Philip,

Does this work? :-

tmp <= tmp(6 downto 0) & SI;

HTH., Syms.

 

[Symon]

Philip,
Webcase?
Syms.

 

[Symon]

"jens" <roden@rochester.rr.com> wrote in message
news:1e501aec-c334-46b3-89a5-2d3a772f2d81@27g2000hsf.googlegroups.com...

It looks like that part only supports a 16-bit shift register in a LUT.

No,
UG331
Fig.7.2.
Syms.

 

[KJ]

"Shannon" <sgomes@sbcglobal.net> wrote in message
news:1e2083c0-63f4-4cf8-b41d-25e7c1f60212@x1g2000prh.googlegroups.com...

Little mistake there. For clarity those should have been ascii
values:

FUNCTION char_to_slv (c : CHARACTER) RETURN STD_LOGIC_VECTOR IS
variable Return_Value : STD_LOGIC_VECTOR(7 downto 0);
BEGIN
case c is
when '0' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(48,8));
when '1' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(49,8));
when '2' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(50,8));
when '3' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(51,8));
when '4' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(52,8));
when '5' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(53,8));
when '6' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(54,8));
when '7' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(55,8));
when '8' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(56,8));
when '9' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(57,8));
when '-' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(45,8));
when others => Return_Value := (OTHERS => '1');
end case;
return(Return_Value);
END char_to_slv;

And it's working in hardware! yeah! Now...to figure out how to write
a TCL script or something to push my revision number into a constant
in my package. The fun never ends!

Well if all you wanted was the ASCII value of the charcters in the string
(as it appears from your code that you do) then it's even simpler

for i in 1 to 16 loop
Some_Slv <= std_logic_vector(to_unsigned(character'pos(Some_String(i)),
8));
end loop;

KJ

 

[KJ]

"Shannon" <sgomes@sbcglobal.net> wrote in message
news:1e2083c0-63f4-4cf8-b41d-25e7c1f60212@x1g2000prh.googlegroups.com...

Little mistake there. For clarity those should have been ascii
values:

FUNCTION char_to_slv (c : CHARACTER) RETURN STD_LOGIC_VECTOR IS
variable Return_Value : STD_LOGIC_VECTOR(7 downto 0);
BEGIN
case c is
when '0' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(48,8));
when '1' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(49,8));
when '2' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(50,8));
when '3' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(51,8));
when '4' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(52,8));
when '5' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(53,8));
when '6' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(54,8));
when '7' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(55,8));
when '8' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(56,8));
when '9' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(57,8));
when '-' => Return_Value := STD_LOGIC_VECTOR(TO_UNSIGNED(45,8));
when others => Return_Value := (OTHERS => '1');
end case;
return(Return_Value);
END char_to_slv;

And it's working in hardware! yeah! Now...to figure out how to write
a TCL script or something to push my revision number into a constant
in my package. The fun never ends!

Shannon

Well if all you wanted was the ASCII value of the charcters in the string
(as it appears from your code that you do) then it's even simpler

for i in 1 to 16 loop
Some_Slv_String(i) <=
std_logic_vector(to_unsigned(character'pos(Some_String(i)),
8));
end loop;

KJ

 

[Symon]

"Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message
news:g1pmbj$m1f2@cnn.xsj.xilinx.com...

Mike Treseler wrote:
Kevin Neilson wrote:

I put this code in ISE 10.1 and got the same message. However, the
message is erroneous or ambiguous and the synthesizer is actually using
an SRL.

I expect that the *mapper* step
decided to utilize a LUT shifter
to cover the 8 D-type flops
inferred by synthesis.

-- Mike Treseler

I'm not sure what you mean by "mapper": I think of "map.exe" (in the
Xilinx flow) as "the mapper". Some people refer to a stage within the
synthesizer as the mapper. -Kevin

Hi Kev,
What? Look at your results and tell us the answer!
Thanks, Syms.

 

[Symon]

"Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message
news:g1pmbj$m1f2@cnn.xsj.xilinx.com...

Mike Treseler wrote:
Kevin Neilson wrote:

I put this code in ISE 10.1 and got the same message. However, the
message is erroneous or ambiguous and the synthesizer is actually using
an SRL.

I expect that the *mapper* step
decided to utilize a LUT shifter
to cover the 8 D-type flops
inferred by synthesis.

-- Mike Treseler

I'm not sure what you mean by "mapper": I think of "map.exe" (in the
Xilinx flow) as "the mapper". Some people refer to a stage within the
synthesizer as the mapper. -Kevin

Hi Kev,
What? Look at your results and tell us the answer!
Thanks, Syms.