Clock Edge notation

[HT-Lab]

"PC" <pcvijay30@gmail.com> wrote in message
news:0ee4cb5c-32dc-40cc-bf84-8c14bd8ff049@25g2000hsx.googlegroups.com...

Hi all,

I have a very very basic problem with the cadence VHDL compiler
For example

signal test : std_logic_vector( 15 downto 0);
begin

test<="1111111111111111" ; works fine
test<=x"ffff"; gives an error expecting an expression of type
STD_LOGIC_VECTOR 87[8.3] 93[8.4] why ?

The code is fine, try compiling with the VHDL93 standard,

Hans
www.ht-lab.com

thanks in advance
PC

 

[Maarten]

Hi,
Alternatively you could consider to program a piece-wise-linear transfer
function; By limiting the numberof gain factors (i.e. degreeof freedom in
choice for steepness) to a set say {4*,2*, 1* , 1.125*, 1.25*, 1.5*} you
can replace multipliers by a number of shift-and-add functions, which
results in a compact and fast (since its most probably video, you should
appreciate that) solution.
I'd suggest youtry and play in Excel first to find a proper compromise
between accuracy and complexity, then step to an HDL implementation.

Cheers,
Maarten

"KJ" <kkjennings@sbcglobal.net> schreef in bericht
news:8c05a7c1-e730-4ee0-82e9-130dbb44e2b4@d77g2000hsb.googlegroups.com...

On Jun 30, 9:33 am, Martin Sauer <m...@displaign.de> wrote:
Hi,

I'm looking for a gamma correction vhdl code. Do anything know about
such cores?

thank you for your answer

bye

martin sauer

I'd suggest the following:
1. Go to Wikipedia for the fundamental equations for gamma correction
(unless you know them already).

2. Realize that to implement such a function you only need a lookup
table for whatever your input data width is (i.e. 8 bit video = 256
entry table).

3. Write a simple VHDL function to compute the above mentioned table.
In order to do this for gamma correction, you'll see that you need log
and powers and real number computations. While you can't syntheize
type real for 'signals' you can use type real to compute 'constants'
which is what you're trying to do here. For a related example that
demonstrates this see the link below or Google for "Sample code to
compute an sRGB->RGB conversion lookup table" in which case you should
run across the posting that I did that shows this.

http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/b2e4be6480069641?hl=en#

Kevin Jennings

 

[Maarten]

Hi,

You're right: implementing constants somewhere in a circuit is very unwise,
but then: that's not what I meant to propose ...
Since gamma correction is a tricky function from signal processing point of
view (non-linear, therefore generating spectral horror), and furthermore -
and this is the actual rationale- you surely would like to tune this
transfer function to see what performance improvement a tiny little gamma
change could bring.

To create that flexibility I suggested (I admit: not explicitely) to
implement a programmable structure, in which you only input the steepness of
the subsequent sections of a piecewise linear function in hardware. Excel
only helps to get a quick impression of the range of gain factors for each
section that would be fine.
This function is really easy to implement, and offers a lot of flexibility.
Note that the gain factors for each section can in a later stage also be
fixed in a lookup table.

The main difference between the solution you proposed and what I suggested,
is the amount of points that define the transfer funtion: a full look-up
table or a limited table with gain factors in between which linear
interpolation is done by hardware.

Your solution has one more advantage over mine: Suppose the initial poster
wants to process RGB signals, then one table can serve all three channels.

cheers,
Maarten



"KJ" <kkjennings@sbcglobal.net> schreef in bericht
news:76741322-2bdb-463d-9e2f-cdf4df6de0b1@m36g2000hse.googlegroups.com...
On Jun 30, 3:43 pm, "Maarten" <no_one@nowhere> wrote:

Hi,
Alternatively you could consider to program a piece-wise-linear transfer
function; By limiting the numberof gain factors (i.e. degreeof freedom in
choice for steepness) to a set say {4*,2*, 1* , 1.125*, 1.25*, 1.5*} you
can replace multipliers by a number of shift-and-add functions, which
results in a compact and fast (since its most probably video, you should

I think you're missing my point that all of the calculation stuff can
be done in a function that produces a constant. That constant is a
lookup table array. No multipliers, log/exp functions, etc. would be
synthesized.

Functionally, and from a synthesis perspective, it's absolutely no
different than if you were to use Excel to compute the lookup table
values and copy/paste them into your code. The difference is in the
maintainability of the design.

If you go the copy/paste route though your HDL design contains an
array of 'magic' numbers for the lookup table entries that (hopefully)
have some reference back to the Excel spreadsheet that generated
them...and hopefully nobody accidentally changes any of the values
when doing a search/replace operation.

If you go the route of having your HDL compute the lookup table
entries directly then the HDL has a fairly short, easy to read
function that (should) look very close to the true source equations
that define the mapping.

Functions to compute constants are not shackled with the same
constraints that apply to signals.

Kevin Jennings

 

[KJ]

<ALuPin@web.de> wrote in message
news:a6585932-8c49-47ce-b4b6-7ea99702661e@25g2000hsx.googlegroups.com...

Hi,

I have the following process without sensitivity list:

p_trigger: process
begin
for i in 0 to 10 loop

wait until ls_trigger='1';

if ls_falling_edge_enable='1' then
wait until ls_trigger='0';
end if;

end loop;
wait;
end process p_trigger;

Will the if branch be entered if "ls_falling_edge_enable" becomes
'1' ?
Thank you for your opinion.

Only if 'ls_falling_edge_enable' happens to be '1' at the time when
ls_trigger *changes* to a '1'. If it is not then the if condition is false
the loop goes back around and waits until ls_trigger changes to a '1' again.

KJ

 

[KJ]

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

Signed types (using numeric_std) can have widths bigger than 32, but the
to_signed() function only takes integers as an argument, so it seems to be
very difficult to assign values to large signed constants. For example,
in my code I have:

constant round_const: signed(c'range) := to_signed(2**x-1,c'length);

This doesn't work if x==32, because 2**32-1 is outside the range of an
integer (which must be <=(2**31-1)). I can't use a real as an argument,
and I can't convert a real to a signed without converting it to an integer
first, and then I have the same problem.

A workaround, for this case, seems to be:

constant round_const: signed(c'range):= (x-1 downto 0=>'1',others=>'0');

1. It's not that hard to write a function to compute a power when the
exponent is not a fraction. Something along the lines of the following is a
start

function pow(b, e: unsigned) return unsigned is
begin
if (to_integer(e) = 0) then
return(1);
elsif (to_integer(e) = 1) then
return(b);
else
return(b * pow(b, e-1);
end if'
end function pow;

1a. Perhaps override "**" to do this if you feel like it.

2. Then, using the synthesizable log2 function, give some more thought to
computing the proper number of bits for the return result and modify the
above mentioned starter function. That way 2**4 (when represented as
unsigned) will come out as 5 bits rather than 12.

2a. Hint for #2, a function to compute the ceil(log2(x)) would likely be a
handy function (perhaps ceil_log2(x)) which returns the smallest unsigned
that is greater than or equal to log2(x) (i.e. returns the conventional
'ceiling' math function).

3. Now you can say
constant round_const: signed(c'range) := pow("0010", "0100") - 1;
constant round_const: signed(c'range) := pow(x"2", x"4") - 1;

Remembering that hard coded constants (like 2 and 4 in this example; 2 and
32 in the OP example) can generally also be represented as generics and that
generics can be signed/unsigned of arbitrary width as well as integers one
is well on their way to working strictly with signed/unsigned directly
instead of doing the math in integers which is the source of the problem
here.

Kevin Jennings

 

[KJ]

"Clemens" <Clemens@hotmail.com> wrote in message
news:g50ebg$5v0$1@aioe.org...

Hi

Normally I always used the function conv_integer to convert a
std_logic_vector into an integer.

Poor choice (but not an uncommon one). Use numeric_std instead and the
to_integer() function.

use ieee.numeric_std.all;

However, now I have a signal
defined as follows:

signal test : unsigned(31 downto 0);

I wanna use a slice of test for a 4-bit table look-up and I tried
it like this

lookup(conv_integer(test(3 downto 0)));

which doesnt work

However, the following codeexample would be compiled:

lookup(conv_integer(std_logic_vector(test(3 downto 0))));

Anyone can tell me how to do that without this extra converting step to
std_logic_vector?

lookup(to_integer(test(3 downto 0)));

Kevin Jennings

 

[KJ]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:mid5741lq2qovj6ehttuqljm9r2l4u61f6@4ax.com...

On Mon, 7 Jul 2008 05:19:56 -0700 (PDT), KJ <kkjennings@sbcglobal.net
wrote:

On Jul 7, 5:37 am, Olaf <is...@inter.net> wrote:
Hi,

the following snippet won't pass the modelsim compiler, what's wrong
with it?
is this a syntactically problem?


Modelsim wouldn't have complained if it wasn't.

In this particular situation, there really isn't a good way to get
'count' and 'rld_value' to have the same range without copy/pasting
the equation for the range.

Possibly create a subtype declaration. I think you will have to put it
in a package so that it can be made visible to both places.
Untested here...

package mytypes is
constant MY_WIDTH : natural := 8;
subtype my_natural is natural range 2**MY_WIDTH-1 downto 0;
...
end package mytypes;

Then you lose the ability to instantiate different instances with different
values for the generic...until packages accept generics...which I suppose if
VHDL-200X gets the final approval will happen.

KJ

 

[KJ]

<ALuPin@web.de> wrote in message
news:e9e9b9ef-f6b1-4ece-b783-e90abddb8c45@c65g2000hsa.googlegroups.com...

Hi,

I have two modules A,B connected at their serial bidirectional port.

How can I insert the glitch while modules A or B are driving data on
the bidirectional line ?

If you want to insert anything other than an unknown value (i.e. change a
'1' to a '0' and not to 'X'), then you'll have to 'break' the connection
between A and B. C will have to be able to figure out which is driving the
signal(s) at any particular time and then insert your changes. If you try
to have C insert a glitch by say driving a '1' on to something that is being
driven by A or B to a '0' then all you'll get is 'X'...which probably isn't
terribly useful for inserting a fault.

Kevin Jennings

 

[HT-Lab]

<ALuPin@web.de> wrote in message
news:7e909f38-01c2-448c-b143-56ab441d722e@d1g2000hsg.googlegroups.com...

Hi Kevin,

thank you for your answer.



If you try
to have C insert a glitch by say driving a '1' on to something that is
being
driven by A or B to a '0' then all you'll get is 'X'...which probably
isn't
terribly useful for inserting a fault.

Yes, I know. But it seems to be very tricky to describe that kind of
"resolve" function for
three members accessing the bidirectional line.

Andre

Perhaps you can use the weak signal values ('L'/'H') for communication and
use '0'/'1' to force a glitch on the signal? Alternatively if you have
access to Modelsim you might be able to use the force/noforce/examine
command to insert a glitch,

Hans
www.ht-lab.com

 

[KJ]

"rickman" <gnuarm@gmail.com> wrote in message news:d5e80e02-a17f-4dbd-89c4-

BTW, I am using Synplify with Lattice parts and I have seen it
synthesis badly, then a trivial change to the code makes it work
correctly.

What's your definition of 'bad' synthesis?

Meanwhile it works just fine in simulation. My design is
running with a rather slow clock (12 MHz), so I don't expect it is
timing.

Do you have more than one clock in your design?
Any gated or otherwise derived clocks or is the whole design running off of
a single clock that is sourced by an external osc?

The malfunction is not easily explained by a timing error
either, but then maybe I am just not looking hard enough.

If the answer to either of the two above questions is 'yes', then it's quite
possible that you might not be looking hard enough.

If the answer is 'no' then have you properly input the external I/O pin
delays to account for setup and clock to output requirements?

I was
thinking more of an issue with an unintentional async loop. I have a
number of muxes and there may be an async loop from those.

If you have a loop, you'll see
- A warning during synthesis about either a loop detected or a latch being
inferred.
- Timing analysis after fitting will complain with a warning or error about
a loop.

KJ

 

[HT-Lab]

"rl" <rleenheer@amb-it.com> wrote in message
news:a3278b40-c214-463e-8ce2-b1c852f9a4d5@t54g2000hsg.googlegroups.com...

Consider the piece of code below, "ack" is not declared, yet it does
not give any compiler/synthesiser errors. Why is this, is "ack"
somehow reserved?

ENTITY test IS
PORT
(
output : OUT bit
);
END ENTITY;

ARCHITECTURE rtl OF test IS
BEGIN
output <= '1' WHEN (ack = '1') ELSE '0';
END rtl;

Yes, it is defined in the STD package;

package standard is
type boolean is (false,true);
type bit is ('0', '1');
type character is (
nul, soh, stx, etx, eot, enq, ack, bel,
bs, ht, lf, vt, ff, cr, so, si,
dle, dc1, dc2, dc3, dc4, nak, syn, etb,
can, em, sub, esc, fsp, gsp, rsp, usp, ......


Hans
www.ht-lab.com

 

[KJ]

"XSterna" <XSterna@gmail.com> wrote in message
news:67fd4987-aa2b-4458-8dc2-0a065787c924@z66g2000hsc.googlegroups.com...

On 17 juil, 22:14, Mike Treseler <mtrese...@gmail.com> wrote:

Maybe you don't have a generic map on the testbench entity.
See the testbench here:http://mysite.verizon.net/miketreseler/
for an example.

If you aren't using vsim -G then you might be better off
with a packaged constant for these values.

-- Mike Treseler

Thank you for your answer

You are right I don't have a generic map on my testbench entity. But I
don't understand why I need some since I have initialise the generics
in my component entity. If I need to create a generic map then I don't
see the interest of the generics initialisation ...
X

You don't need a generic map unless
- You want to override the defaults
- An input does not have a default specified.

In any case, if you change the default values for the generics (or other
inputs) in the entity those new values will be used (after you compile it).

In addition to the entity, do you have a component definition? If so, do
you have the same default values on the component that you have on the
entity? Typically I don't use components and don't recall which default
value takes precedence, but I seem to recall similar nastiness when the
default values differed between component and entity and that could be what
is going on for you.

I usually just directly instantiate the entity, but I use generics a lot and
default values are properly assigned if I don't override them in the map so
I doubt that it's a Modelsim problem...take a look for those component
definitions, I'll bet that's where the problem is.

KJ

 

[KJ]

"Tricky" <Trickyhead@gmail.com> wrote in message
news:effb5500-9f9e-4bd8-9bde-be9246237662@e53g2000hsa.googlegroups.com...

On 17 Jul, 17:27, Tricky <Trickyh...@gmail.com> wrote:
Unfortnalty, Ive just reaslised that the image and dimension types I
have declared are more likely to be than variables,

Thats meant to be "more likely to be constants than variables"

Something that is 'likely to be constant' still sounds like it's a variable
to me.

KJ

 

[HT-Lab]

"uj101" <uj101@yahoo.com> wrote in message
news:b6b658bf-9c15-4f95-b65a-d7104d3837ea@w1g2000prk.googlegroups.com...

I'm facing a delta delay issue (CLK arriving before the data) for the
mixed language (VHDL/Verilog) simulation in modeltech. Has anyone
faced the same and knows any simple workaround (instead of inserting
#1 or after).

Thx

uj101

Make sure that you do not have any combinatorial clock assignments in your
code. Modelsim 6.4 can now display delta's in the waveform window (although
it is a bit flaky

Hans
www.ht-lab.com

 

[HT-Lab]

"XSterna" <XSterna@gmail.com> wrote in message
news:d34e7f03-1eda-4b61-98c8-61ce738fa313@k36g2000pri.googlegroups.com...

Thank you everyone for your answers !

I find how to solve my problem !

Modelsim is creating a _opt file everytime I compile my entity. If I
don't delete the file from the 'work' library, the generics don't get
changed. If I do so, my changes are taking into accounts. It is quite
strange since I don't know what is this _opt and I don't feel this is
the common sense having to delete this but anyway, I have what I
wanted !

The _opt directory is created by the vopt optimiser (enabled by default
after I believe 6.2). If you run vsim -novopt this directory is not created.
However, vsim/vopt should detect a different generic argument and
re-optimise the relevant files so this looks like a bug. Log it with Mentor
if you are using Modelsim 6.4,

Hans
www.ht-lab.com

 

[HT-Lab]

"rickman" <gnuarm@gmail.com> wrote in message
news:d9ecb5e5-5712-4430-8156-375bbf0ec7fd@z66g2000hsc.googlegroups.com...

I may need to add a CPU to a design I am doing. I had rolled my own
core once with a 16 bit data path and it worked out fairly well. But
it was 600 LUT/FFs and I would like to use something smaller if
possible. The target is a Lattice XP3 with about 3100 LUT/FFs and
about 2000 are currently used. I believe that once I add the CPU
core, I can take out a lot of the logic since it runs so slowly. The
fastest parallel data rate is 8 kHz with some at 1 kHz and the rest at
100 Hz. I probably would have used a CPU to start with instead of the
FPGA, but there was a possible need to handle higher speed signals
which seems to have gone away.

I recall that someone had started a thread about serial
implementations of processors that were supported by a C compiler. I
don't think any ever turned up. But the OP had some other
requirements that may have excluded a few very small designs. Are
there any CPU cores, serial or parallel, that are significantly
smaller than 600 LUT/FFs?

I would suggest you check out one of the many free PIC cores available on
the web. The reason for suggesting PIC is that it is accompanied by a
processional IDE from Microchip. Developing a processor is easy and the web
is full of wonderful and clever implementation but at the end of the day if
you have to develop some software you need a good IDE.

I just tried a quick push-button synthesis of a 16C54,

***********************************************
Device Utilization for LFXP3C/PQFP208
***********************************************
Resource Used Avail Utilization
-----------------------------------------------
LUTs 374 3072 12.17%
Flipflops 83 3072 2.70%
Block RAMs 0 6 0.00%
IOs 67 136 49.26%
-----------------------------------------------

Hans
www.ht-lab.com

The Lattice part has LUT memory even dual
port, so that is not a constraint, the LUTs can be used for
registers.

Rick

 

[Victor Frankenstein]

VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO
VAF FAN CU LO

 

[Stef]

In comp.lang.vhdl,
utauta <NetbeansSound@gmail.com> wrote:

On Jul 23, 11:23 pm, Mike Treseler <mtrese...@gmail.com> wrote:
utauta wrote:
For example: If I have 6 different input combinations and need to go
through the same sequence of states except for a few small
modifications pertaining to input values.
What is the best way to implement this?

A counter?

Well I am using a counter to change from the current state to the
next, but what I meant was if I had a 50 state sequence (for example)
with 6 inputs each having to go through a slightly modified version of
the sequence, is it possible to create a function to simplify this? Or
will I have to type out 50 states 6 times?

So you have a state machine with 50 states and the sequence depends on
the input signals? Then add those input signals to your next-state
logic and you have a single state machine with the required behaviour.
If your machine should only use the input state that was present at
the start of the sequence, register that input state and use the
registered version in your next-state logic.


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

"I always avoid prophesying beforehand because it is much better
to prophesy after the event has already taken place. " - Winston
Churchill

 

[KJ]

"chestnut" <adam0818@gmail.com> wrote in message
news:2fa81d33-aef3-4ea9-9ce8-0ef765f19d07@a2g2000prm.googlegroups.com...

Ken,

Thank you. but what I intend is to make a VHDL source file used by
both simulation and synthesis.

That's always a good plan.

<snip>

if compiled by ModelSim, it gonna assume porta_wren <= '1'; if
compiled by Synthesis tools, it gonna assume porta_wren <= '0';

Such feature is easily supported by Aldec Active-HDL. I am wondering
if ModelSim has a similar support.

Doesn't sound like a good thing...making synthesis and simulation models
intentionally different that is. Your reasoning for why you would want to
do this is likely flawed.

In any case, rather than trying to go outside of the language and using tool
specific pragmas that are not part of any standard and which (as you've just
found out) can lead to incompatibilities, it would be much better to stick
with the design language and pass in some generic that percolates up to the
top level so that you can set it one way for sim and another way for
synthesis. Then instead of the pragmas you have

porta_wren <= '1' when (Sim=TRUE) else '0';

Much more maintainable and not tool specific....and don't bother with the
usual complaint about "It's soooo far down the hierarchy that I'd have to
edit half a dozen file to add the parameter to get it down to where I need
it". It's not that hard to modify code to accept the new parameter (use
copy/paste, it works wonders). Lastly, I'll reiterate that having a
simulation model that is different than the synthesis model is most likely a
bad plan.

KJ

 

[KJ]

"rickman" <gnuarm@gmail.com> wrote in message
news:62e47371-9d8d-43d1-a97b-4759ecc35fc6@56g2000hsm.googlegroups.com...
..

I know I can create a function for this such as select(sel,a,b), but I
like the form of the notation sel ? a : b, very clear and concise.

This is nearly as concise and what I use.

x<= sel(Condition, a, b);

You would have to overload 'sel' to handle all the data types that you deal
with (std_(u)logic(_vector), integer, real, time, etc). These could be
written once and then put into a common package that you use with wild
abandon. More specialized types that are application specific like records
would then need similar overrides (if needed).

I
guess I could always switch to Verilog... :^)

If that's the best reason you got, then you cna have it.

KJ