Clock Edge notation

elektroda.net NewsGroups Forum Index - VHDL Language - Clock Edge notation

Goto page Previous 1, 2, 3 ... 102, 103, 104, 105 Next

David Bishop
Guest

Sat Apr 24, 2010 5:47 pm

Symon wrote:

Quote:

On 4/22/2010 3:26 AM, dlopez wrote:
Hi,
I'm trying to calculate the absolute value of a signed number (two's
complement).

Right now, I sign extend the input, and when msb=1, inverse all bits and
add 1. The sign extend is to take care of the most negative number.

So, if I read numeric_std correctly (see below), in VHDL, for (say) four
bit signed numbers, abs("1000"), aka abs(- Cool

, equals zero. What am I
missing?
Thanks, Symon.
p.s. This thought came from a post comp.arch.fpga

I noticed this when I did the fixed point package. If you use fixed
point then a bit gets added when you do an "abs".
Thus:
constant sf8 : sfixed (3 downto 0) := "1000";
variable sf8p : sfixed (4 downto 0);

....
sf8p := abs (sf8);

You will get "01000" as the result.

rickman
Guest

Sat Apr 24, 2010 7:22 pm

On Apr 23, 6:34 am, Symon <symon_bre...@hotmail.com> wrote:

Quote:

On 4/23/2010 10:56 AM, Andy Rushton wrote:> Symon wrote:

So, if I read numeric_std correctly (see below), in VHDL, for (say)
four bit signed numbers, abs("1000"), aka abs(- Cool

, equals zero. What
am I missing?

No, for a 4-bit signed, abs(- Cool

= -8!

Aha! OK, I see it now, many thanks.

I'm not sure I see the problem. If you need the result as a signed
number, you have to extend the result by one bit. This can be done
after the abs like this...

signed(resize(unsigned(abs(foo)), foo'length+1))

I guess that is a bit messy, but you can encapsulate this in a
function.

If you want the result as an unsigned number, you just re-type it...

unsigned(abs(foo)), foo'length)

The unsigned result fits in the same number of bits as the signed
value.

Rick

Andy Rushton
Guest

Mon Apr 26, 2010 12:00 pm

Rob Gaddi wrote:

Quote:

Or just copy/paste/tweak the numeric_std code to write your own abs
function that returns an unsigned of the same width as the signed input.

Not a good idea. Synthesis tools do not necessarily synthesise the body
of the package, in fact they almost certainly do not. Typically
operators have straight mappings to hardware. These mappings may be
pre-optimised. If you copy the body code, you may lose those
optimisations brought about by the straight mappings.

If you want an unsigned result from signed abs:

signal x : signed(3 downto 0);
signal z : unsigned(3 downto 0);

z <= unsigned(abs x);

Notice that the result is the same size as the input. However, z has the
range 0 to 15 and x has the range -8 to 7. The value -8 will get mapped
by abs onto -8, but the type conversion to unsigned will map it onto +8.
So everything pans out OK in the end.

Andy Peters
Guest

Thu Apr 29, 2010 2:21 am

On Apr 23, 3:01 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:

Quote:

Andy wrote:
Other than twice the declarations, unintentional latches, explicitly
coding clock enables, simulation penalties, etc., using separate
combinatorial and sequential blocks is just fine.

LoL. Note that there are further difficulties to understand this separated
code due to the fact that things which conceptually belong together are
spread apart over the file. This is just too messy.

Most designers here use single clocked processes / always blocks.
Those that don't are 'encouraged' to.

I'm fully on your side.

Same here. In the over one hundred posts in this thread, I still
haven't figured out exactly what benefits Patrick sees in the two-
process model.

Unless he likes the names of his machine's states to line up with the
signal assignments in the waveform view, as opposed to seeing the new
assignments in the _next_ state.

-a

Martin Thompson
Guest

Thu Apr 29, 2010 3:16 pm

Andy Peters <google_at_latke.net> writes:

Quote:

On Apr 23, 3:01 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
Andy wrote:
Other than twice the declarations, unintentional latches, explicitly
coding clock enables, simulation penalties, etc., using separate
combinatorial and sequential blocks is just fine.

LoL. Note that there are further difficulties to understand this separated
code due to the fact that things which conceptually belong together are
spread apart over the file. This is just too messy.

Most designers here use single clocked processes / always blocks.
Those that don't are 'encouraged' to.

I'm fully on your side.

Same here.

Me too.

Quote:

In the over one hundred posts in this thread, I still
haven't figured out exactly what benefits Patrick sees in the two-
process model.

I may be entirely wrong, but I *think* it's a Verilog thing - it's a
way to make it easy to check that the rules about sharing "variables"
don't go wrong, giving you races.

We VHDLers don't have to worry about it, so the discussion made little
sense within this newsgroup.

Cheers,
Martin

--
martin.j.thompson_at_trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

KJ
Guest

Sat Jul 31, 2010 4:44 am

On Jul 30, 12:20 pm, rickman <gnu...@gmail.com> wrote:

Quote:

On Jul 29, 6:43 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

On 29 Jul., 02:34, KJ <kkjenni...@sbcglobal.net> wrote:

Instead of this:
Some_slv_sig <= std_logic_vector(Some_unsigned);
Do this
Some_slv_sig <= std_ulogic_vector(Some_unsigned);

a package numeric_unresolved would be nice....

Kolja

There is no reason why unresolved can't be added to numeric_std is
there?

I don't think you could really *add* the unresolved types to
numeric_std because to do so you would have to create new types other
than 'unsigned' and 'signed' that are based on std_ulogic. Then of
course you would have to get all of the synthesis and simulation
vendors on board with the change before you could really use the new
types. In the mean time, the 'least common denominator' rule will
apply and everyone would continue to use the more supported current
data types that are based on the resolved std_logic type...which would
then kill all momentum for any of the vendors to support the change
and the proposal would likely die quietly.

If instead, numeric_std was simply changed from this...
type UNSIGNED is array (NATURAL range <>) of STD_LOGIC;
type SIGNED is array (NATURAL range <>) of STD_LOGIC;

to this...
type UNSIGNED is array (NATURAL range <>) of STD_ULOGIC;
type SIGNED is array (NATURAL range <>) of STD_ULOGIC;

Then the only ones the user community would have to beat on to get
this implemented would be the simulation vendors. Synthesis vendors
already flag multiple driver violations as a standard part of
synthesis since they (for the most part) do not implement multiple net
drivers.

Changes to standard packages should of course not be taken lightly,
but off the top of my head, I can't think of anyone that would be
negatively impacted by this. I'll toss this out to the newsgroupies
first to see if someone can come up with a use case where the change
in the definition of 'unsigned' and 'signed' would negatively impact
something. If not, then I'll submit it to the standards group for
consideration...numeric_std was so close, they were only two letters
short in the source code. Sooooo close.

Kevin Jennings

Andy
Guest

Sat Jul 31, 2010 8:50 pm

It would break existing code that used signed/unsigned like SLV, and
needed the tri-state, multi-driver logic. Also, elements of unsigned
would not be SL, with the same problem.

Am I just dreaming, or wasn't there an effort to change the
relationship between SLV and SULV such that they would become
interchangeable subtypes like SUL and SL are? E.G. subtype SLV is
resolved(SULV); or similar, with a new version of resolved() to match.
It seems like the gotcha was that an element of such an SLV would no
longer be SL, but SUL. But I thought they got around that.

Andy

KJ
Guest

Tue Aug 03, 2010 4:40 pm

On Jul 31, 1:50 pm, Andy <jonesa...@comcast.net> wrote:

Quote:

It would break existing code that used signed/unsigned like SLV, and
needed the tri-state, multi-driver logic. Also, elements of unsigned
would not be SL, with the same problem.

Actually, I intended my question more along the lines of if signed/
unsigned were changed to be collections of std_ulogic rather than
std_logic, how many would really notice/care? I understand that those
who use signed/unsigned with multiple drivers would be affected...but
how many of those cases are actually out there? So, do *you* use
multiple drivers on signed/unsigned signals? Is that actually
important to you?

KJ

Andy
Guest

Tue Aug 03, 2010 7:04 pm

On Aug 3, 8:40 am, KJ <kkjenni...@sbcglobal.net> wrote:

Quote:

On Jul 31, 1:50 pm, Andy <jonesa...@comcast.net> wrote:

It would break existing code that used signed/unsigned like SLV, and
needed the tri-state, multi-driver logic. Also, elements of unsigned
would not be SL, with the same problem.

Actually, I intended my question more along the lines of if signed/
unsigned were changed to be collections of std_ulogic rather than
std_logic, how many would really notice/care? I understand that those
who use signed/unsigned with multiple drivers would be affected...but
how many of those cases are actually out there? So, do *you* use
multiple drivers on signed/unsigned signals? Is that actually
important to you?

KJ

Mostly in places where I have an inout port (or procedure argument) of
a record type, and I need resolution functions to manage in and out
elements more often than I actually use a bidirectional element. My
test benches tend to have lots of procedures like read/write(bus,
address, data)

I have also used unsigned on tri-stated primary IOs of FPGAs (it is
easy enough to convert them back to SLV if I need to use the gate
level models).

Internally, I have used them with a tri-state bus description, knowing
full-well that the synthesis tool would convert them to muxes for me.
The added benefit is that the synthesis tool can assume that the tri-
state enables are mutually exclusive, which allows it to optimize the
muxes. Sometimes it is just easier to describe an interface with a
bus, than to create the mux and the plumbing for it. I don't usually
do truly bi-directional busses, but sometimes...

So, yes, I have used them in several areas.

IMHO, changes to the language or standard packages must be backwards
compatible (even though in rare cases in the past they have not been
so), so that they don't break anyone's code, regardless of how common
(or even "useful") a given usage is. The "prime directive" WRT changes
to the standards should be "do no harm". If we need a different
numeric_std-like package, so be it.

Andy

KJ
Guest

Thu Aug 05, 2010 2:32 am

On Aug 3, 12:04 pm, Andy <jonesa...@comcast.net> wrote:

Quote:

On Aug 3, 8:40 am, KJ <kkjenni...@sbcglobal.net> wrote:
IMHO, changes to the language or standard packages must be backwards
compatible (even though in rare cases in the past they have not been
so),

Backwards compatibility should not be a 'must have'...although I
certainly agree that it is something worth working for to get if you
can. Examples of changes that are definitely more onerous to 'used to
be working just fine' code were the changes to type 'FILE' and 'shared
variables'.

Quote:

so that they don't break anyone's code, regardless of how common
(or even "useful") a given usage is.

I think the cost/benefit should be weighed although just how well one
can weigh this with actual users is a bit of a question.

Quote:

The "prime directive" WRT changes
to the standards should be "do no harm".

'Do no harm' applies to doctors, not engineering standards. If
something needs to be improved and is 'worth it' to the users then it
should be improved. The definition of whether something is 'worth it'
or not is subjective.

Quote:

If we need a different
numeric_std-like package, so be it.

Maybe just use the fixed point package. The documentation says it

uses std_logic as the base, but the actual code says std_ulogic.

Thanks for your input on how you use/need multi-driver signed/unsigned

Kevin Jennings

Vince
Guest

Sat Aug 21, 2010 5:00 pm

niyander a écrit :

Quote:

Hi,

I have written some vhdl code which uses internal multiplier present
in spartan-3 device. Can someone check if this code is synthesizable,
i would appreciate if someone can help me in this.
I am getting desired results in simulation, but i am not sure if this
code is 100% synthesizable.

code:http://anceop.com/vhdl.txt

A synthesis tool will answer to your question...

Mike Treseler
Guest

Sat Aug 21, 2010 5:53 pm

On 8/21/2010 8:27 AM, niyander wrote:

Quote:

I have written some vhdl code which uses internal multiplier present
in spartan-3 device. Can someone check if this code is synthesizable,
i would appreciate if someone can help me in this.

I would suggest nothing but reset and clock in the sensitivity list.
Something like the template below.

-- Mike Treseler

main : process(reset, clock) is
begin -- process template
if reset = '1' then
-- init_regs;
elsif rising_edge(clock) then
-- update_regs;
end if;
-- update_ports;
end process main;
end architecture synth;

KJ
Guest

Sat Aug 21, 2010 8:57 pm

On Aug 21, 11:27 am, niyander <mightycatniyan...@gmail.com> wrote:

Quote:

Synthesis tools are downloadable from the supplier's web site,
consider downloading one. In both the short and long run you'll be
more productive. Using Quartus, the warnings reported below (*1)
represent conditions under which the logic that gets generated will
*not* match simulation results. (*2)

You should also consider getting rid of the first process and just use
concurrent signals assignments as you did when you commented out the
process portions of your second group. As a general rule you should
try to not use combinatorial (i.e. non-clocked processes) they lead to
design errors such as the ones being reported below as well as latches
if you miss an assignment to a signal under some condition in the
process.

Sometimes one really likes to use statements such as 'if' and 'case'
that are not available in concurrent assignment statements (such as in
your last process). In those cases, if making the process clocked is
not an option, then peruse the synthesis warnings for statements like
the ones listed below since they are actually potential design errors
waiting to trap you. Alternatively, consider implemeting your
'process' code as a function or a procedure instead. At least then
any compiler will flag usage of some signal (such as 'lead0') that is
not formally listed as an input parameter.

Kevin Jennings

(*1)
Warning (10492): VHDL Process Statement warning at Junk.vhd(509):
signal "lead0" is read inside the Process Statement but isn't in the
Process Statement's sensitivity list
Warning (10492): VHDL Process Statement warning at Junk.vhd(511):
signal "lead0" is read inside the Process Statement but isn't in the
Process Statement's sensitivity list
Warning: Design contains 1 input pin(s) that do not drive logic
Warning (15610): No output dependent on input pin "clk"

(*2) The synthesized result will behave as if 'lead0' was listed in
the sensitivity list. Since it is not, then your simulation will
differ if 'lead0' changes but none of the other signals does not
happen to simultaneously transition. In your case, 'lead0' will
change one simulation delta cycle after product_mantissa(47 or 46)
changes so it won't be simultaneous. Your process for computing
'final_mantissa' will wake up because of the change in
'product_mantissa' (with a soon to be out of date value for 'lead0')
but will not wake up again on the next simulation delta when 'lead0'
actually gets updated.

Pranav Pareek
Guest

Sun Aug 22, 2010 8:05 pm

On Aug 21, 10:57 pm, KJ <kkjenni...@sbcglobal.net> wrote:

Quote:

On Aug 21, 11:27 am, niyander <mightycatniyan...@gmail.com> wrote:

Hi,

I have written some vhdl code which uses internal multiplier present
in spartan-3 device. Can someone check if this code is synthesizable,
i would appreciate if someone can help me in this.
I am getting desired results in simulation, but i am not sure if this
code is 100% synthesizable.

code:http://anceop.com/vhdl.txt

Thanks

Synthesis tools are downloadable from the supplier's web site,
consider downloading one. In both the short and long run you'll be
more productive. Using Quartus, the warnings reported below (*1)
represent conditions under which the logic that gets generated will
*not* match simulation results. (*2)

You should also consider getting rid of the first process and just use
concurrent signals assignments as you did when you commented out the
process portions of your second group. As a general rule you should
try to not use combinatorial (i.e. non-clocked processes) they lead to
design errors such as the ones being reported below as well as latches
if you miss an assignment to a signal under some condition in the
process.

Sometimes one really likes to use statements such as 'if' and 'case'
that are not available in concurrent assignment statements (such as in
your last process). In those cases, if making the process clocked is
not an option, then peruse the synthesis warnings for statements like
the ones listed below since they are actually potential design errors
waiting to trap you. Alternatively, consider implemeting your
'process' code as a function or a procedure instead. At least then
any compiler will flag usage of some signal (such as 'lead0') that is
not formally listed as an input parameter.

Kevin Jennings

(*1)
Warning (10492): VHDL Process Statement warning at Junk.vhd(509):
signal "lead0" is read inside the Process Statement but isn't in the
Process Statement's sensitivity list
Warning (10492): VHDL Process Statement warning at Junk.vhd(511):
signal "lead0" is read inside the Process Statement but isn't in the
Process Statement's sensitivity list
Warning: Design contains 1 input pin(s) that do not drive logic
Warning (15610): No output dependent on input pin "clk"

(*2) The synthesized result will behave as if 'lead0' was listed in
the sensitivity list. Since it is not, then your simulation will
differ if 'lead0' changes but none of the other signals does not
happen to simultaneously transition. In your case, 'lead0' will
change one simulation delta cycle after product_mantissa(47 or 46)
changes so it won't be simultaneous. Your process for computing
'final_mantissa' will wake up because of the change in
'product_mantissa' (with a soon to be out of date value for 'lead0')
but will not wake up again on the next simulation delta when 'lead0'
actually gets updated.

Thank you ever one for your valuable comments.

Mike Treseler
Guest

Sat Dec 11, 2010 7:40 am

On Fri, Dec 10, 2010 at 4:42 PM, alessandro basili wrote:

Quote:

Dear Mr. Treseler,
few years ago I followed quite closely the comp.arch.fpga and
comp.lang.vhdl
groups and I was fascinated by your template project especially the
testbench style, that I adopted since then.
....
Talking about your template, how do you see multiple component
instantiation
and port mapping, as opposed to your procedural template?

My top entity is a collection of direct
instances of single process entities with port maps.
I use the Quartus rtl viewer to draw a block diagram
from my functional code.
I use a template to simplify the synthesis of variables.

Quote:

I believe that component instantiation offers a black-box view pretty
much
like a schematic entry and it's easy to me to follow, while I don't have
that picture through your procedural template. Am I missing something?

I agree at the top level.
I like to see the wired view, but I let quartus draw it for me.
I also click on on one of the top blocks on the rtl viewer
to verify the structural view of my procedural entity.

Quote:

Do you think a single process, as opposed to many of them, will
simplify the
datapath and allow for better maintainance of the code?

I instance single process entities at the top level.
I prefer to connect large boxes at the port map level to
connecting processes at the architecture level.

Quote:

What is the gain of having variables as opposed to signals?

I can write functional/procedural code for synthesis
using standard vhdl source code.

Quote:

I am very used
to signals since I always though that the way values are assigned to a
signal follow pretty much what happens on hardware, while for a variable
there is an abstraction that I am not accustomed to.

I am very used to writing, siming and tracing code descriptions with
immediate assignments,
and letting synthesis sort out the LUTs and flops using my template.

Quote:

I hope I haven't bother you too much with my questions.
Best regards,

Al

Not a bother in the least.

-- Mike Treseler

Goto page Previous 1, 2, 3 ... 102, 103, 104, 105 Next

elektroda.net NewsGroups Forum Index - VHDL Language - Clock Edge notation