Clock Edge notation

[Thomas Reinemann]

nospam schrieb:

Dear all,

Could any one telll me how to change 64 INSTANTIATION (MEMxx) below
into
a for loop?

Yick

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;

entity viterbi is
generic (VITERBI_N, VITERBI_L, VITERBI_NUM_STATES:
integer);
port ( clk : in std_logic;
reset : in std_logic;
receive_symbol0 : in std_logic_vector;

receive_symbol1 : in std_logic_vector

inputting : in std_logic;
input_ready : out std_logic;
symbol : out std_logic
);
end viterbi;

architecture behaviour of viterbi is

constant PATH_METRICE_NUM_BITS : integer := 10;
constant VITERBI_Q : integer := receive_symbol0'length;

component butterfly_ACS is
generic (PATH_METRICE_NUM_BITS, Q, ENCODER_N:integer);
port (
clk : in std_logic;
PM0_IN : in signed((PATH_METRICE_NUM_BITS-1) downto 0);
PM1_IN : in signed((PATH_METRICE_NUM_BITS-1) downto 0);
SYM0 : in signed((Q-1) downto 0);
SYM1 : in signed((Q-1) downto 0);
CMD : in std_logic_vector(1 downto 0);
PM0_OUT: out signed((PATH_METRICE_NUM_BITS-1) downto 0);
TBR0 : out std_logic;
PM1_OUT: out signed((PATH_METRICE_NUM_BITS-1) downto 0);
TBR0 : out std_logic;
PM1_OUT: out signed((PATH_METRICE_NUM_BITS-1) downto 0);
TBR1 : out std_logic;
XXX_ZERO_TO_ZERO_XXX_INPUT_0: in std_logic_vector((ENCODER_N-1)
downto 0);
XXX_ZERO_TO_ONE_XXX_INPUT_1 : in std_logic_vector((ENCODER_N-1)
downto 0);
XXX_ONE_TO_ZERO_XXX_INPUT_0 : in std_logic_vector((ENCODER_N-1)
downto 0);
XXX_ONE_TO_ONE_XXX_INPUT_1 : in std_logic_vector((ENCODER_N-1)
downto 0)
);
end component;

component memory_unit is
generic (NUM_BITS: integer := PATH_METRICE_NUM_BITS);
port (
clk : in std_logic;
out_sel : in std_logic;
reset : in std_logic;
input : in std_logic_vector((NUM_BITS-1) downto 0);
output : out std_logic_vector((NUM_BITS-1) downto 0)
);
end component;

component stack is
generic (STACK_SIZE: integer);
port (
clk : in std_logic;
push_pop : in std_logic;
input : in std_logic;
output : out std_logic
);
end component;

type state_t is (
S_READY
);

type PM_TYPE is array (0 to (VITERBI_NUM_STATES-1))
of std_logic_vector((PATH_METRICE_NUM_BITS-1) downto 0);
signal PM_IN, PM_OUT: PM_TYPE;

signal cur_state: state_t;
signal mem_clk: std_logic;
signal mem_sel: std_logic;

begin
process(reset, CLK)
begin
if (RESET='1') then -- asynchronous reset
elsif (CLK'event and CLK='1') then
end if;
end process;

memo: for i in 0 to PM_IN'length - 1 generate

memory_unit port map (mem_clk, mem_sel, reset, PM_IN(i), PM_OUT(i));
end generate memo;

end behaviour;

 

[jtw]

CRC is for error DETECTION, not correction.

Jason
"sk_effect" <sunilkshukla@gmail.com> wrote in message
news:74cc822a1f71ea40eb41530b2ccf3341@localhost.talkaboutprogramming.com...

Please refer this paper for CRC-16 single bit error correction
implementation in hardware. Its a highly optimized and time efficient
method.

http://www.itee.uq.edu.au/~sunil/publications.htm

Cheers,
Sunil

 

[Mike Treseler]

jtw wrote:

CRC is for error DETECTION, not correction.

That's the most common application,
but not the only one.

Jason wrote:
Please refer this paper for CRC-16 single bit error correction
implementation in hardware. Its a highly optimized and time efficient
method.

Is it worth $35 to read?

-- Mike Treseler

 

[Kim Enkovaara]

Analog Guy wrote:

The design is working, right?

Yes, the design is working, but I am still worried about eliminating this
hold problem.

Easiest way to debug the problem is to get all the signals around the cells
that give the warning. And then you should just manually from the wave try
to understand why the warning happened.

One possible reason could be timing resolution. Are you using accurate enough
timing for the models (can be set in modelsim.ini or vith "-t 1ps" style
command line switch).

Also some glitches can have affect in the simulation models. Usually the
vendor gives some notes if pulse rejection must be used (in modelsim
+pulse* switches).

Why are you using a timing simulation in the first place?


As far as I was aware, that is the only way to verify the "physical" device
in the simulator, and to achieve a good
degree of confidence before going to the lab. By using the SDF delays, you
get a worst-case representation of the
timing. I realize the sims take orders of magnitude longer to run, but you
get a dynamic representation of your device
performance. Are you suggesting to use only the static timing analysis?

Usually STA is enough. SDF simulations of the design are made to make sure
that the STA setups in big chips are correct, and to test the asynchronous
interfaces a little. If there are only few clock domains it's easier just to
review the STA setup.

Also synthesis errors can be debugged with post simulations,
but RTL->gate formal verification is easier tool for that (and exhaustive).
Also in the ASIC world post simulations are usually needed to check
that all the test logic is connected correctly (can be done mostly also
with formal checks).

--Kim

 

[fred]

In article <1117908574.903296.284390@o13g2000cwo.googlegroups.com

, Pasacco <pasacco@gmail.com> writes
Dear

I implemented 12-state controller and the operations are basically

ld 32bit data -> ld another 32bit data -> compare -> store into memory

The operation above is repeated 1024 times.....

Then I synthesized in FPGA tool.

Problem is that the area is too big (more than 10% of Vertex2pro),
though 'area' optimiation option was used.

When I do the same thing with 128 times of ld/ld/cmp/store, the area
was 3%.

Open the design in a physical editor (or look at the synth report) to see
where the resources are being used and you will likely see where
inefficiencies exist. Such an occurrence usually results from a difference in
your understanding of how you think the design will implement and how the
synthesis tool actually implements it. If you wish your design to share
resources you must code in such a way that the synthesis tool has no
choice but to operate (and share) in the way you intend it.

You also make no mention of the size of your device.
--
fred

 

[m]

On 4 Jun 2005 11:09:34 -0700, "Pasacco" <pasacco@gmail.com> wrote:

Dear

I implemented 12-state controller and the operations are basically

ld 32bit data -> ld another 32bit data -> compare -> store into memory

The operation above is repeated 1024 times.....

Then I synthesized in FPGA tool.

Problem is that the area is too big (more than 10% of Vertex2pro),
though 'area' optimiation option was used.

When I do the same thing with 128 times of ld/ld/cmp/store, the area
was 3%.

I am wondering why this happens....

and I hope the area of FSM will be constant, regarless of the number of
ld/st...

If someone has this experience or idea, let me know....Thankyou

It seems you're somehow merging the your counter into your
state-machine states. Without seeing your code, it would be difficult
to point to what the problem is but what you can do is to instantiate
a 10 bit counter and in a certain state of your FSM compare the
counter value to your max count to decide whether to continue to load
or terminate. This should decouple your FSM from the counter.

 

[Thomas Reinemann]

Weng Tianxiang wrote:

Thomas,
I have the same question as Neo does.

Can you explain the meaning of the following statement:
constant VITERBI_Q : integer := receive_symbol0'length;
The original post has an additional generic "VITERBI_Q". Since you can

obtain this information from the signal "receive_symbol0", it isn't
really needed on this place. The entity gets simpler and more flexible
by this.

The essential of the question is it wants a variable unit name that can
be changed in a 'generate' loop.

Is there any formal semantics or reference to the problem resolution.

Your method doesn't give any relationships with the memory_unit name.

I have a book named "HDL Chip Design" and it doesn't have the semantics
about variable unit name in 'generate' loop.

Generate statements are evaluated during elaboration. During this stage
only constant values are assumed.
Usually I prefer this range specification. Since the range is linked
obviously to the signal PM_IN. I could use VITERBI_NUM_STATES-1, but
without knowledge of PM_TYPE you couldn't relate it to PM_IN. In fact I
didn't regard PM_IN's type as I wrote the answer. May be it will not
work in this case, since PM_TYPE is an array.

Bye Tom

 

[John_H]

john.deepu@gmail.com wrote:

I wanted to sort 48 8bit unsigned numbers

And do you want the 384 bit result for a new set of numbers every 10 ns?
Can you wait 1 ms for the result?
Is it fine to keep the inputs and outputs in a BlockRAM or are you
presenting them parallel?

 

[Stephane]

Tom Verbeure wrote:

Assuming you're using a unix line environment:

find . -name "*.vhd" -exec ./Metrix.sh {} \;

--------------------------- Metrix.sh ---------------------
#! /usr/bin/sh
echo "Filename $1"
echo "Lines in file:"
wc -l $1
echo "Lines with comment:"
grep "\-\-" $1 | wc -l
echo "Empty lines:"
egrep "^[ \t]*$" $1 | wc -l

are you guys grading your students? ;-)

first make sure they don't ask for traffic light controllers on this
newsgroup!

 

[M@rte]

"pho" <philippe.hostiou@orange.fr> wrote in message
news:1118154866.773513.187220@g44g2000cwa.googlegroups.com...

Hi,
I'm looking for an IP vhdl to make a CODEC video on a Xilinx platforme
(Virtex II Pro)
I found a JPEG2000 IP from BARCO Silex, but I would like to know
if someone have already use an IP as MPEG-2 or MPEG-4 part 2
running on a FPGA (using the PowerPC for instance) ?
I beleive it is very challenging to find it !
My aim is to make a small video encoder with a lantency around 1-2
frame(s)
with a bit rate less than 15-20 Mbits/s.
Thank you a lot of for your help
Regards
Philippe

Codec Video no yet, but Im working in Codec Audio AC3 (alpha test). Without
PowerPC, only mB.

Regards
Marte

 

[Ralf Hildebrandt]

Neil wrote:

-- process a --
a: process(clk,reset)
begin
if reset='1' then
LoadA<='0';
wr<='0';
....
end process;

-- process b --
b: process(clk,reset)
begin
....
elsif clk'event and clk='1' then
if RxData=x"01" then
wr<='1';
....
end process;

-- ************************************************ --

the error is:"Xst:528 - Multi-source in Unit <...> on signal <wr>".
but I don't find any multi-source for it

For me it was very easy to find it: You write to wr from both processes.

Every process generates a signal driver.

Furtunately you use an unresolved data type for wr and therefore you got
this error.

What do you think this can be in hardware? Two flipflops driving the
same wire? There is only one exception where this makes sense: Tri-state
drivers.


Hint: It does not matter, that wr gets a value assigned in the
reset-clause in the 1st process and in the edge-sensitive clause in the
2nd process. For a HDL you have written two drivers and in real world it
would be a fixed '0' at the 1st wire and a flipflop (without
asynchronous set/reset) for the 2nd wire. Both wires are connected,
which is impossible.

Ralf

 

[Stephane]

Andrew wrote:

Yeah, I'm hoping that is not what my PHB wants such a script for. And
no, I am not the PHB.

Does anyone know of any tools that have this as a feature? A simulator
or something? Unfortunately we're a Windows shop so to run a script
like Stephane's I would need to install cygwin on the PHB's computer.

Not mine, Tom's one.

Maybe your boss needs the "bullbuster", or something like that, a
semantic speech analyser, created by Andersen, and that scored high some
presidnt!

 

[Ralf Hildebrandt]

Neil wrote:

I'm a beginner in VHDL, and I can't understand your explanation well...

Even each process will generate a signal driver for the signal
separately, there is also assert function / assert signal to determin
the value of the signal at that time. So why does it mean is there two
wire in real world? It always has only one proper value at a time...

And if "wr <= '0';" is placed in the reset-clause in the process b, how
many wires are there? one or two?
And how to know how many wires will be gotten for a signal in the real
world? Thank you!

Let me explain with a flipflop as an example.
In VHDL a FF is coded like:
---
process(reset, clock)
begin
if (reset = '0') then
ff<='0';
elsif rising_edge(clock) then
ff<=data_in;
end if;
end process;
---
In real world this can be represented as a D-flipflop with asynchornous
low-active reset:
_____
data_in __| |__ ff
clock __|D-FF |__ NOT(ff)
|_____|
o
|
reset




If you write
---
A : process(reset, clock)
begin
if (reset = '0') then
ff<='0';
elsif rising_edge(clock) then
-- ff<=data_in;
end if;
end process A;
---
this will be a wire

'0' __________ ff





If you write
---
B : process(reset, clock)
begin
if (reset = '0') then
-- ff<='0';
elsif rising_edge(clock) then
ff<=data_in;
end if;
end process B;
---
this will be a D-flipflop without reset:
_____
data_in __| |__ ff
clock __|D-FF |__ NOT(ff)
|_____|





If you write both processes A and B this will result in

'0' ___________
|
_____ |
data_in __| |__|__ ff
clock __|D-FF |__ NOT(ff)
|_____|

And now guess, what will happen if you do this.



This is the reason, why you are not allowed to write to one signal from
more than process in VHDL.
(O.k. if you are going to model a tri-state bus you have to do exactly
this, but then you usually know what you are doing and a resolved data
type will let you do this.)


Ralf

 

[Ralf Hildebrandt]

ajahn wrote:

Ralf, I don't think, process a will be a wire. It will rather be a FF
with output looped back to its input and an async reset. If you
simulate it, the behavior would be to have 'U' assigned to it upon
simulator initialization and '0' during and all the time after reset.

Good point - I think you are right.

The conclusion (multiple drivers) stays valid.

Ralf

 

[Tim McCoy]

On Mon, 23 May 2005 06:12:03 -0700, jo.spreutels wrote:

Hi,

For a project we have to make an 8bitcounter which exists of two 4
bit-counters.
The 8bit counters drives two 7seg displays on a spartan 2 board.
I use also 3 buttons on the board as enable,updown and reset.
In simulation the counters are working perfect but in hardware the
thing doesn't do much.
Is it possible to have a look at the code?

thanks for having a look at it!

If its simulating correctly at a post-synthesis level, then you're
probably not enabling the segment LED displays properly. Theres a module
on my website that I generated recently for this purpose - it might help,
considering I used it for a single unit 8-bit counter, outputting the hex
count to two units of a four segment display on a Spartan-3 board!

http://home.swiftdsl.com.au/~tmccoy/index.php?option=content&task=view&id=107&Itemid=32

You need to (somewhat slowly) drive the control signals out to the display
anodes, then assert the control signals as required.

I'd also suggest assigning the pins of the 8-bit count output bus to
simple LEDs first, so make sure its working.

Are you holding the "buttons", which are instant action (only on whilst
PUSHED) - you'd be better assigning these inputs to slide switches. Also

The code was difficult to read with the variables in (german?), but have
you also divided down the (50MHz) system clock into human readable
increments of about 1Hz?

This link is my 8-bit counter that might help you along.

http://home.swiftdsl.com.au/~tmccoy/index.php?option=content&task=view&id=101&Itemid=32

Cheers

Tim

--
"Linux... because rebooting is for adding new hardware!"

http://home.swiftdsl.com.au/~tmccoy
MSN: timsy_01@hotmail.com
ICQ: 160341067

 

[Mike Treseler]

janbeck@gmail.com wrote:

I am trying to use the fixed point package fixed_pkg and am having
trouble with synthesis

Simulation is OK?

shared variable m1: sfixed (32 downto -32) := to_sfixed (50, 32, -32);

This is likely your problem.
Shared variables are not commonly supported for synthesis.
Alternatives include
1.regular variables, which can be shared
across procedures in a single process or
2.signals which can be driven across processes.

-- Mike Treseler

 

[Mike Treseler]

janbeck@gmail.com wrote:

Thank you for your reply.

You are welcome.

I need to move this into hardware, so simulation is not sufficient.

Simulation is sufficient with the right design rules.
And it is necessary in any case, to find logical errors in all
but the most trivial of digital designs.

I have actually had everything declared as signals and assigned the
signals in a state machine before. I felt the signals might be the
problem, so I went to the variables, but no luck.

Any other ideas?

It may be a logical problem.

-- Mike Treseler

 

[Martin Thompson]

"vicky" <vikas.talwar@gmail.com> writes:

Hi All,

i'm new to VHDL, my aim is to overload airthmatic and shift operators
for STD_LOGIC_VECTORs/STD_LOGICs.

They are already there in numeric_std, just use the unsigned or signed
data types, depending on the type of data you are using.

SLVs have no numerical representation (although we sometimes pretend
that they do!)

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

 

[Amit Dua]

uninitialized objects get 'left value of their type.

in this case, the real signals get most -ive value
i.e. -1e+308. When this is multiplied, it overflows.

btw, NCVHDL has an option "-initzero" to initialize
all "integer" and "time" type objects (signals,variables,
generics) in the design to 0 (instead of 'left).
so if this is what you desire, you don't have to
explicitly set for objects of these types.

Thanks.
-Amit.


Brandon wrote:

I'm trying to scale some reals in a test bench, however I'm getting an
out of range error:

SNIP

signal srefloat_unscale : real;
signal simfloat_unscale : real;
signal srefloat_test : real;
signal simfloat_test : real;

begin
...
...
...
scaleresult_proc: process(srefloat_unscale, simfloat_unscale)
begin
srefloat_test <= srefloat_unscale*2.0**7;
simfloat_test <= simfloat_unscale*2.0**7;
-- srefloat_test <= srefloat_unscale;
-- simfloat_test <= simfloat_unscale;
end process scaleresult_proc;
/SNIP

In ModelSim:

VSIM> run
# ** Fatal: (vsim-3421) Value -1.#INF is out of range 1e+308 to
-1e+308.

What gives? Is the scale factor I'm multiplying by somehow causing an
overflow in the floating point? srefloat_unscale and simfloat_unscale
are both reals between -1 and +1 (normalized fixed point), so the
result should be anywhere from -128 to +128 after scaling.

Thanks,
-Brandon

 

[Egbert Molenkamp]

Did you also initialize the input in the entity declaration?
e.g.
entity dbbl is
port (x : in real :=0.0 ; y : out real);
end dbbl;

Egbert Molenkamp

"Brandon" <killerhertz@gmail.com> wrote in message
news:1118770362.119722.218220@g44g2000cwa.googlegroups.com...

I tried the above advice, but it did not seem to help.

I think the problem is because the signals are connected to output
ports of the entity that converts my fixed point binary to real:
SNIP

architecture behavioral_ar of my_tb is
...
signal srefloat_unscale : real := 0.0;
signal simfloat_unscale : real := 0.0;
signal srefloat_test : real := 0.0;
signal simfloat_test : real := 0.0;
...

begin
sreConvert_ins : entity work.fxdbin2fpdec_g(behavioral_ar)
generic map (dwidth => DWIDTH_C)
port map (fxdbin => sre, fpdec => srefloat_unscale);

simConvert_ins : entity work.fxdbin2fpdec_g(behavioral_ar)
generic map (dwidth => DWIDTH_C)
port map (fxdbin => sim, fpdec => simfloat_unscale);
...
scaleresult_proc: process(srefloat_unscale, simfloat_unscale)
begin
srefloat_test <= srefloat_unscale*2.0**7;
simfloat_test <= simfloat_unscale*2.0**7;
end process scaleresult_proc;

end behavioral_ar;
/SNIP

Is there anyway around this? I'm also using ModelSim, so ncvhdl
compiler properties are not an option.