Clock Edge notation

[rickman]

On 5/1/2014 12:55 PM, emirogluengin@gmail.com wrote:

15 Mayıs 2002 Çarşamba 23:07:03 UTC+3 tarihinde Christian yazdı:
Hello!
I know this newsgroup is specially ybout VHDL. But I am curently working
with Altera's derivation AHDL.
My question isn't quite language related but more general:

How would you create a decoder which generates BCD-coding from normal 8bit
binary coding?
I want to control several 7 segment displays and therefore have to use BCD
coding.

I'd be very happy to get any kind of help.
Regards
Chris.

I see this message has not been answered so let me try.

I remember seeing some fairly elegant ways to convert binary to decimal,
but none of them seem to have stuck in my mind. I bet a google search
would pull up a few.

In your case I think you could do some fairly simple shortcuts which
take advantage of the fact that you are only converting an 8 bit sample.
With larger numbers it is usually done iteratively, converting one
digit at a time, LSB first.

--

Rick

 

[GaborSzakacs]

rickman wrote:

On 5/1/2014 12:55 PM, emirogluengin@gmail.com wrote:
15 Mayıs 2002 Çarşamba 23:07:03 UTC+3 tarihinde Christian yazdı:
Hello!
I know this newsgroup is specially ybout VHDL. But I am curently working
with Altera's derivation AHDL.
My question isn't quite language related but more general:

How would you create a decoder which generates BCD-coding from normal
8bit
binary coding?
I want to control several 7 segment displays and therefore have to
use BCD
coding.

I'd be very happy to get any kind of help.
Regards
Chris.

I see this message has not been answered so let me try.

I remember seeing some fairly elegant ways to convert binary to decimal,
but none of them seem to have stuck in my mind. I bet a google search
would pull up a few.

In your case I think you could do some fairly simple shortcuts which
take advantage of the fact that you are only converting an 8 bit sample.
With larger numbers it is usually done iteratively, converting one
digit at a time, LSB first.

When I had to do this with an 8-bit micro, I made use of the DAA
(decimal adjust after addition) instruction. The basic loop was:

shift input left into carry
add accumulator + carry in to accumulator
decimal adjust accumulator

The combination of addition and DAA effectively created a BCD
adder.

Note that the accumulator must be zeroed out before the loop,
and you need a loop counter, but that was the basic idea.

In an FPGA, I'd probably use a lookup table if there were only 8 bits.
I assume that since this information is going to a display, that you
have lots of time (many clock cycles) available to get the job done?

--
Gabor

 

[suhas sajjan]

On Friday, 4 December 1998 09:00:00 UTC+1, Georges wrote:

Hello,

I'm looking for vhdl programs for decoding the GPS signal or the DCF-77
signal (an AM signal at 77.5kHz emitted in Frankfurt used for
synchronisation).
I want to do a synchronised clock on an IC, I need any information on
this subject.
Thank you for your attention.

Gaetan Brichet
Student at the University of Liege - Belgium
brichet@stud.montefiore.ulg.ac.be

Hi George,

Do you have any idea regarding this project.I am doing the same and i m in need of VHDL for decoding dcf77 time signal and display it on a nixie tube which is like a 8 segment dispaly?

Regards,
Suhas Sajjan

 

[Nikolaos Kavvadias]

Hi Suhan and all,

around 2012 I had implemented both a DCF77 and an MSF decoder in RTL-style VHDL. (for the UK and German signals)

The design had been put to work with success on a specific lab facility.

I think there is no such open-source core, so it possible that you might be interested.


Best regards
Nikolaos Kavvadias
http://www.nkavvadias.com


Τη Τετάρτη, 28 Μαΐου 2014 11:11:24 π.μ. UTC+3, ο χρήστης Stef έγραψε:

In comp.lang.vhdl,

suhas sajjan <suhas.sajjan@gmail.com> wrote:

On Friday, 4 December 1998 09:00:00 UTC+1, Georges wrote:

Hello,



I'm looking for vhdl programs for decoding the GPS signal or the DCF-77

signal (an AM signal at 77.5kHz emitted in Frankfurt used for

synchronisation).

I want to do a synchronised clock on an IC, I need any information on

this subject.

Thank you for your attention.



Gaetan Brichet

Student at the University of Liege - Belgium

brichet@stud.montefiore.ulg.ac.be



Hi George,



Do you have any idea regarding this project.I am doing the same and i m in need of VHDL for decoding dcf77 time signal and display it on a nixie tube which is like a 8 segment dispaly?



Regards,

Suhas Sajjan



I hope he has finished his study project after 15 1/2 years!



For information about DCF77, start reading here:

http://en.wikipedia.org/wiki/DCF77

Also have a look at the external links.







--

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



"I found out why my car was humming. It had forgotten the words."

Hi,

 

[rickman]

On 5/28/2014 3:37 AM, suhas sajjan wrote:

On Friday, 4 December 1998 09:00:00 UTC+1, Georges wrote:
Hello,

I'm looking for vhdl programs for decoding the GPS signal or the DCF-77
signal (an AM signal at 77.5kHz emitted in Frankfurt used for
synchronisation).
I want to do a synchronised clock on an IC, I need any information on
this subject.
Thank you for your attention.

Gaetan Brichet
Student at the University of Liege - Belgium
brichet@stud.montefiore.ulg.ac.be

Hi George,

Do you have any idea regarding this project.I am doing the same and i m in need of VHDL for decoding dcf77 time signal and display it on a nixie tube which is like a 8 segment dispaly?

I have not looked at DCF-77 in detail, but I believe it is very similar
to the time code transmitted by NIST in the US which I am familiar with.
I have designed a decoder/encoder for the IRIG-B signal which is again
very similar. I can't share any of the code, but I can offer you some
advice in how to proceed.

You might want to be aware of two things. One is that there are
commercial chips which do exactly this. I believe they are complete
receivers needing only passive devices to form the antenna. The one I
am thinking of decodes the US and German signals as well as the related
Japanese signal.

So why reinvent the wheel? Is this a project for a class rather than
development of a product?

btw, GPS will be a much harder task than the simple audio time codes.

--

Rick

 

[Stef]

In comp.lang.vhdl,
suhas sajjan <suhas.sajjan@gmail.com> wrote:

On Friday, 4 December 1998 09:00:00 UTC+1, Georges wrote:
Hello,

I'm looking for vhdl programs for decoding the GPS signal or the DCF-77
signal (an AM signal at 77.5kHz emitted in Frankfurt used for
synchronisation).
I want to do a synchronised clock on an IC, I need any information on
this subject.
Thank you for your attention.

Gaetan Brichet
Student at the University of Liege - Belgium
brichet@stud.montefiore.ulg.ac.be

Hi George,

Do you have any idea regarding this project.I am doing the same and i m in need of VHDL for decoding dcf77 time signal and display it on a nixie tube which is like a 8 segment dispaly?

Regards,
Suhas Sajjan

I hope he has finished his study project after 15 1/2 years!

For information about DCF77, start reading here:
http://en.wikipedia.org/wiki/DCF77
Also have a look at the external links.



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

"I found out why my car was humming. It had forgotten the words."

 

[Jim Lewis]

Hi,
If you know where you want to work and who you are interested in working for, look at what they currently use, if you can ask them if they plan on changing. Then learn that.

While it is nice to be general, I would put my first focus on a job you want.

Jim

 

[alb]

Hi Kevin,
KJ <kkjennings@sbcglobal.net> wrote:

On Tuesday, July 15, 2014 4:25:27 PM UTC-4, alb wrote:
this morning a member of the verification team found a bug in a
testbench which lead to think we were testing a particular feature of
the design while we were not (that's bad)!

No, actually that's good. If your verification team does not find
bugs, then most likely they are not trying or the design is very
mature and only subject to relatively minor changes.

Indeed, I was focused on the 'half empty' glass... ;-)

Even though some boss believes that code coverage is all you need (and
hopefully most of us know that that's not the case!), when I try to
argument the need of a functional coverage collection I start to wander:
wait a minute, what if our coverage model is not correct. What if we
believe we are done just because we are doing functional coverage
verification and we 'measure' that function A has been exercised. What
if we 'believe' we have done a test against function A, happily
recording the transaction which was supposedly defined to test it, while
in reality the transaction got sidetracked by a stupid bug which did not
cause the function A to be tested at all?

[]

The intended test was performed (albeit incorrectly), but the checker
did not catch that the correct response to the intended test did not
occur. Sounds to me that there were two errors, not one as you
reported. The checker should first be upgraded to detect and report
the incorrect (or lack of) response to the test as it was originally
written. Then the stimulus should be updated to perform the intended
test.

Yes, you are right. There was a combination of two errors, one in the
stimulus and one in the checker. None of them were spotted in time and
only 'luck' helped us out. We were actually lucky that the issue came
out at system level, but I'd like to understand why not earlier and what
can we do to improve this situation.

code
-- from the presentation, available to registered users.

while not ACov.IsCovered loop

(Reg1, Reg2) := Acov.RandCovPoint; -- randomize uncovered bins
DoAluOp(Trec, Reg1, Reg2); -- do transaction
Acov.Icover((Reg1, Reg2)); -- mark it covered

end loop;

/code
In the above snippet the real transaction is DoAluOp, which is supposed
to do something with registers Reg[12], but we mark the bin as covered
even though there's no real feedback from the transaction result.

Not sure about your point here. Are you saying
- It is not possible to check that Reg[12] responded properly?

In the above example we assume that injecting Reg1 and Reg2 we are
covering the intended case, *assuming* DoAluOp does what is supposed to
do.

> - Reg1 and Reg2 were used where Reg[12] should have been used?

negative. My regexp notation for Reg1 and Reg2 was a bad choice that
lead confusion. There's no Reg[12], only Reg1 and Reg2.

The answer to the first scenario is that will never be the case unless
Reg[12] controls nothing. There should be a verifiable response to
everything.

That's is what it *should*, but here it was not the case. Is it a matter
of code review? plan? report? model?

Getting that response might be rather involved but if it
is intended to do something then it can be verified in theory.

Assume we inject Reg1 and Reg2 in order to have a Reg3=0 (I'm
oversimplifying here). It is possible that Reg1 and Reg2 did not operate
at all on Reg3, but for some reason the value of Reg3 is still correct.
I realize the example is a bit too stupid to be representative but the
point is still valid.

The functional coverage should aim at generating the /condition/ *and*
/measuring/ that something *did* happen (like a transition in Reg3 from
one value to another).

[]

If you're thinking that having a bug in a testbench is somehow worse
than a bug in the design than you are a bit shortsighted. You should
view every line of code written equally. A given line of code is just
as likely to be wrong no matter where it is located.

It was not my intention to make you believe that I consider a testbench
bug worse than a design one. All bugs are born equal, they only become
severe if they have time to grow unnoticed.

We are measuring coverage, we generate a transaction, but where did it
ended? how can we be sure that we really tested what we believed? Isn't
this the very same situation my colleague met this morning?

The short answer is that in most situations is that you can't be sure.

What I'm saying is that if a state of your sistem is controllable and
observable there *must* be a way to A) define the inputs to control it
to a particular value and B) observe that value happen.

If we 'collect' only the fact that we have covered A) does not
necessarily mean that B) is covered as well.

Some niches of designs might be able to be provably correct but most
will not. That's not to say that you shouldn't be using good testing
and design techniques, but don't expect those techniques to be
implemented flawlessly.

My point here is not to point fingers on a wrong implementation, bugs
are most likely there and will be there even if the final product
behaves 'correctly'. My point is about trying to define a methodology
which allows to anticipate these issues early in the
development/verification cycle.

 

[HT-Lab]

On 15/07/2014 21:25, alb wrote:
Hi Al,
...

I recently followed a recorded webinar on OSVVM at Aldec, by J.Lewis,
and I found it very interesting, especially when he talked about
Intelligent Coverage but then something stroke me, let's see this
snippet of code [1]:

code
-- from the presentation, available to registered users.

while not ACov.IsCovered loop

(Reg1, Reg2) := Acov.RandCovPoint; -- randomize uncovered bins
DoAluOp(Trec, Reg1, Reg2); -- do transaction
Acov.Icover((Reg1, Reg2)); -- mark it covered

end loop;

/code

In the above snippet the real transaction is DoAluOp, which is supposed
to do something with registers Reg[12], but we mark the bin as covered
even though there's no real feedback from the transaction result.

We are measuring coverage, we generate a transaction, but where did it
ended? how can we be sure that we really tested what we believed? Isn't
this the very same situation my colleague met this morning?

Coverage (not code) is only measuring that we have applied all the
required and corner test cases, is not concerned with checking correct
behaviour. So you are right in the above code snipped there must be
another module that checks the ALU operations. In most cases Coverage
Based Verification and Assertion Based Verification goes hand in hand.

> On top of that, how can we collect coverage when using direct testing?

Simply use an assertion, PSL is IMHO the easiest as it support sequences
but you can also use OVL or write a simple FSM that confirms the sequence.

Regards,
Hans.
www.ht-lab.com

 

[HT-Lab]

Hi Al,

On 15/07/2014 21:47, alb wrote:

Hi everyone,

while trying to convince someone to have a look at the OSVVM package I
got told that vhdl-2008 cannot be as efficient as SystemVerilog or
SystemC in handling processor resources therefore a bench with UVM/OVM
is certainly far more efficient [1] than one with OSVVM.

It is true that (SystemVerilog/SystemC) can run faster than VHDL,
however, I suspect the difference will be too small to be concerned
about unless you are running a regression test for several days.
You also have to ask yourself the question, would you swap language and
verification environment just to get a few extra % of performance?
Wouldn't it be more cost effective to improve your code (Modelsim has a
nice code/memory profiler) or just get a faster PC.

Not knowing what are the performances of UVM/OVM I couldn't certainly
argue against it, but is it really the case?

I suspect that UVM(SV) will be quite fast (and faster in the future
unless another acronym is invented) for the simple reason that this is
where EDA vendors are spending their R&D budget on. However, the UVM/OVM
is IMHO hugely complex and a total overkill for the fast majority of us.
Unless you are working on a huge xxM gate ASIC design, have a large
verification team or have lots of re-usable/verification IP I would
forget about the UVM (or OVM/VVM).

I know about the Intelligent Coverage in OSVVM is o(log(N)) more
efficient than its companion Constrained Random in SV, but what about
memory allocation for instance? Or task switching?

SystemC is certainly very flexible being derived from C++, but is that
factor so important in simulation? What about the synchronization
messages between the two simulation cores (if that is how they are
called)?

Yes, I believe that you are right that dual language simulation is not
as efficient as a single language one as the simulator has to handle 2
simulation kernels. For SystemC and VHDL the overhead is probably not
that great as they are both based on the same scheduler model, however,
(System)Verilog is quite different (has a lot more scheduler stages).

Regards,
Hans.
www.ht-lab.com

 

[HT-Lab]

On 16/07/2014 09:39, HT-Lab wrote:

On 15/07/2014 21:25, alb wrote:
Hi Al,
..

I recently followed a recorded webinar on OSVVM at Aldec, by J.Lewis,
and I found it very interesting, especially when he talked about
Intelligent Coverage but then something stroke me, let's see this
snippet of code [1]:

code
-- from the presentation, available to registered users.

while not ACov.IsCovered loop

(Reg1, Reg2) := Acov.RandCovPoint; -- randomize uncovered bins
DoAluOp(Trec, Reg1, Reg2); -- do transaction
Acov.Icover((Reg1, Reg2)); -- mark it covered

end loop;

/code

In the above snippet the real transaction is DoAluOp, which is supposed
to do something with registers Reg[12], but we mark the bin as covered
even though there's no real feedback from the transaction result.

We are measuring coverage, we generate a transaction, but where did it
ended? how can we be sure that we really tested what we believed? Isn't
this the very same situation my colleague met this morning?


Coverage (not code) is only measuring that we have applied all the
required and corner test cases, is not concerned with checking correct
behaviour.

Sorry it should read "is not normally concerned with", obviously you can
use coverage to check behaviour.

Regards,
Hans.
www.ht-lab.com

 

[Jim Lewis]

Hi Al,
I think the need for functional coverage revolves around complexity. As complexity increases, the need for functional coverage increases. The need for it also increases as the design goes through revision cycles. As we go to new chips, they have bigger memory resources. We may decide to leverage this and increase FIFO size. We re-run the old directed testbench and it passes, however, did we validate that the testbench still hits the boundary conditions - some may, some may not.

Code coverage measures execution of lines of code. However, if the item we need to make sure happens is not in the code, then we need functional coverage (both of the examples from the presentation require functional coverage).

Code coverage works well for code that only runs once per clock cycle. OTOH, it is optimistic for combinational logic coded in a process with a sensitivity list. This process runs on delta cycles and may run multiple times during a given clock cycle - as a result, it may report you have covered something that you did not.

While code coverage works great for software, it seems some put too much confidence in it without understanding its limitations.

code
while not ACov.IsCovered loop
(Reg1, Reg2) := Acov.RandCovPoint; -- randomize uncovered bins
DoAluOp(Trec, Reg1, Reg2); -- do transaction
Acov.Icover((Reg1, Reg2)); -- mark it covered
end loop;
/code


In the above snippet the real transaction is DoAluOp, which is supposed
to do something with registers Reg[12], but we mark the bin as covered
even though there's no real feedback from the transaction result.

The example in the presentation is somewhat simplified. You have valid about concerns whether the input vectors are really applied or not. More formally you could (and perhaps should) have a input monitor that watches the interface and collects the functional coverage - hard to show that on one slide . It would definitely reduce the risk. It is in some ways extra work and the value it delivers will depend on the situation.

The value of a separate monitor will depend some on complexity. If I issue a DoAluOp transaction, can I validate it in such a way that I am confident that it always does what the transaction implies? For the ALU or even a UART transmitter - these are fairly simple and I should be able to validate the testbench model well enough.

The value of a separate monitor will also depend on the response checking methdology. For example, as KJ suggested, sometimes while doing result checking we also validate that the correct stimulus was applied. For example, with UART or Ethernet traffic, I send a transaction, I put the expected value into the scoreboard, and then when the RX side receives the transaction and checks it via the scoreboard. In this case, the monitor is not adding significant value since I am validating it on the receive side of the interface anyway.

OTOH, for the ALU logic, my testbench may simultaneously apply the inputs to the DUT and a behavioral math model. In this case, the response checker is not going to me anything about what inputs were applied. However, in this case, DoAluOp may almost be trivial to write.

If I were doing a safety critical design, I would require a separate monitor process or model all of the time, just to add to the confidence level of the testing.

I hope Jim does not get upset for having used a snippet from his
presentation :-/
Certainly permitted. Especially when it promotes good discussion.

Cheers,
Jim

 

[Andy]

Most of the simulation performance difference between vhdl and verilog/SV is due to the data types used by VHDL (SLV, etc.), how much memory they consume, etc.

But most good testbenches minimize the use of slv/unsigned/etc. and use variables, integers and booleans as much as possible. That narrows the performance gap between VHDL and Verilog/SV tremendously.

Thankfully, OSVVM supports integer coverage and randomization natively, so it should be more comparable to SV/UVM (especially if the DUT is in VHDL), and even faster if intelligent coverage is used.

Alas, I have no benchmarking to back any of this up. YMMV, Closed Course Professional Driver, do not try this at home, void where prohibited by law, etc.

Andy

 

[hssig]

You could use stimulus coverage and DUT response coverage. Both together form the overall coverage.

Cheers, hssig

 

On Monday, October 28, 2002 12:50:09 PM UTC+3:30, ameya wrote:

I need the code for the dual port ram. a single 8 bit will do . if i
have for a 16x8 then its very nice of u. the specs are :

If data is to be written from both sides thne priority has to be
assigned to one side. Simultaneous read & write from same location
results in corect data being writen into the memory but invalid data
presented at reading port. simultaneous reads from the same location
allowed.

-------------------------------------------------------
2 -- Design Name : ram_dp_ar_aw
3 -- File Name : ram_dp_ar_aw.vhd
4 -- Function : Asynchronous read write RAM
5 -- Coder : Deepak Kumar Tala (Verilog)
6 -- Translator : Alexander H Pham (VHDL)
7 -------------------------------------------------------
8 library ieee;
9 use ieee.std_logic_1164.all;
10 use ieee.std_logic_unsigned.all;
11
12 entity ram_dp_ar_aw is
13 generic (
14 DATA_WIDTH :integer := 8;
15 ADDR_WIDTH :integer := 8
16 );
17 port (
18 address_0 :in std_logic_vector (ADDR_WIDTH-1 downto 0); -- address_0 Input
19 data_0 :inout std_logic_vector (DATA_WIDTH-1 downto 0); -- data_0 bi-directional
20 cs_0 :in std_logic; -- Chip Select
21 we_0 :in std_logic; -- Write Enable/Read Enable
22 oe_0 :in std_logic; -- Output Enable
23 address_1 :in std_logic_vector (ADDR_WIDTH-1 downto 0); -- address_1 Input
24 data_1 :inout std_logic_vector (DATA_WIDTH-1 downto 0); -- data_1 bi-directional
25 cs_1 :in std_logic; -- Chip Select
26 we_1 :in std_logic; -- Write Enable/Read Enable
27 oe_1 :in std_logic -- Output Enable
28 );
29 end entity;
30 architecture rtl of ram_dp_ar_aw is
31 ----------------Internal variables----------------
32
33 constant RAM_DEPTH :integer := 2**ADDR_WIDTH;
34
35 signal data_0_out :std_logic_vector (DATA_WIDTH-1 downto 0);
36 signal data_1_out :std_logic_vector (DATA_WIDTH-1 downto 0);
37
38 type RAM is array (integer range <&gtof std_logic_vector (DATA_WIDTH-1 downto 0);
39 signal mem : RAM (0 to RAM_DEPTH-1);
40 begin
41
42 ----------------Code Starts Here------------------
43 -- Memory Write Block
44 -- Write Operation : When we_0 = 1, cs_0 = 1
45 MEM_WRITE:
46 process (address_0, cs_0, we_0, data_0, address_1, cs_1, we_1, data_1) begin
47 if (cs_0 = '1' and we_0 = '1') then
48 mem(conv_integer(address_0)) <= data_0;
49 elsif (cs_1 = '1' and we_1 = '1') then
50 mem(conv_integer(address_1)) <= data_1;
51 end if;
52 end process;
53
54 -- Tri-State Buffer control
55 data_0 <= data_0_out when (cs_0 = '1' and oe_0 = '1' and we_0 = '0') else (others=>'Z');
56
57 -- Memory Read Block
58 MEM_READ_0:
59 process (address_0, cs_0, we_0, oe_0, mem) begin
60 if (cs_0 = '1' and we_0 = '0' and oe_0 = '1') then
61 data_0_out <= mem(conv_integer(address_0));
62 else
63 data_0_out <= (others=>'0');
64 end if;
65 end process;
66
67 -- Second Port of RAM
68 -- Tri-State Buffer control
69 data_1 <= data_1_out when (cs_1 = '1' and oe_1 = '1' and we_1 = '0') else (others=>'Z');
70
71 -- Memory Read Block 1
72 MEM_READ_1:
73 process (address_1, cs_1, we_1, oe_1, mem) begin
74 if (cs_1 = '1' and we_1 = '0' and oe_1 = '1') then
75 data_1_out <= mem(conv_integer(address_1));
76 else
77 data_1_out <= (others=>'0');
78 end if;
79 end process;
80
81 end architecture;

 

[Nicolas Matringe]

Le 03/09/2014 16:50, mahdihatamigh61@gmail.com a écrit :

On Monday, October 28, 2002 12:50:09 PM UTC+3:30, ameya wrote:
I need the code for the dual port ram. a single 8 bit will do . if i
have for a 16x8 then its very nice of u. the specs are :
[...]
-------------------------------------------------------
2 -- Design Name : ram_dp_ar_aw
3 -- File Name : ram_dp_ar_aw.vhd
4 -- Function : Asynchronous read write RAM
5 -- Coder : Deepak Kumar Tala (Verilog)
6 -- Translator : Alexander H Pham (VHDL)
[...]

Well I sincerely hope the original poster didn't wait almost 12 years
for you to give an answer

Nicolas

 

[Andy]

There are three kinds of subprogram arguments: constant, variable and signal.

By default, function arguments are of kind constant, and always of mode in. Constant kind arguments must be of mode in, and can be associated with any expression of constant(s), variable(s) and/or signal(s).

Variable kind can only be associated with a variable actual, and signal kind can only be associated with a signal actual. Procedure out/inout ports default to variable kind.

If a procedure spans time (contains a wait statement) and needs to receive updates on an in/inout argument after it is called, or to update an inout/output before it returns, then a signal kind must be used.

Unlike argument types, modes or formal names, argument kinds are not used for compiler selection between multiple overloaded subprograms (signature matching).

Hope this helps,

Andy

 

On Friday, April 19, 2002 6:40:44 AM UTC-5, Renaud Pacalet wrote:

chak a écrit :

hi every body,
could any body suggest me how to convert unsigned to bit
vector...... and bitvector to unsigned with an exmaple.i will be
very thank full thanx in advance
chakri

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;
...
signal BV: BIT_VECTOR(15 downto 0);
signal UV: UNSIGNED(1 to 16);
...
BV <= TO_BITVECTOR(STD_ULOGIC_VECTOR(UV));
UV <= UNSIGNED(TO_STDULOGICVECTOR(BV));

As suggested by Egbert the FAQ is a good starting point if you want
to understand all this.

Regards.
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pacalet@enst.fr
###### Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ ######

Dear Renaud,

I also need to convert unsigned to bit vector...... and bit vector to unsigned. Unfortunately, I need to use
USE ieee.numeric_bit.all;

When I add
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;

my program gives me an error (vcom-1078) Identifier "unsigned" is not directly visible.

Do you know any other way to unsigned to bit vector...... and bit vector to unsigned using USE ieee.numeric_bit.all;

Thanks!

Have a nice evening,
Lesya

 

On Monday, April 15, 2002 5:33:16 PM UTC+12, chak wrote:

hi every body,
could any body suggest me how to convert unsigned to bit vector......
and bitvector to unsigned with an exmaple.i will be very thank full
thanx in advance
chakri

With a context clause consisting of

library ieee;
use ieee.numeric_bit.all;

The conversion between the unsigned type declared in numeric_bit and bit_vector can be accomplished explicit type conversion between closely related types:

entity foo is
end entity;

architecture fum of foo is
signal unsigned_vector: unsigned (7 downto 0):= "11001010";
signal bit_val: bit_vector (7 downto 0);
begin
bit_val <= bit_vector(unsigned_vector);
end architecture;

unsigned is defined as an array natural range of type bit in package numeric_bit while bit_vector is defined as an array natural range of type bit in package standard. This makes the two types closely related, both arrays with the same element type, dimensionality and index type.

This context clause and associated entity/architecture pair analyzes, elaborates and simulates.

Conversion to unsigned is also accomplished by explicit type conversion:

architecture fie of foo is
signal unsigned_vector: unsigned (7 downto 0):= "11001010";
signal bit_val: bit_vector (7 downto 0);
signal un_signed: unsigned (7 downto 0);
begin
bit_val <= bit_vector(unsigned_vector);
un_signed <= unsigned(bit_val);
end architecture;

And this also analyzes, elaborates and simulates, differing from the previous architecture by doing conversion between unsigned and bit_vector and bit_vector and unsigned.

So as you can see from the rest of the answers you can see there is confusion on which declared unsigned to which you're referring.

In those cases where you need to express a VHDL design specification with both unsigned type declarations visible you could partition by visibility. For instance you could specify use clauses as process declarative items in a process statement's process declarative part. You'd communicate between the two processes via signals declared from types visible in both declarative regions.

For example one process statement can have a use clause

use ieee.numeric_std.all;

and use ieee.numeric_std.unsigned. While another process statement can have

use ieee.numeric_bit.all;

and use ieee.numeric_bit.unsigned.

You'd communicate between the two processes using signals whose types are visible to both declarations (e.g. bit_vector, std_logic_vector). Any unsigned types would be variables declared as process declarative items.

You could also use selected names:

library ieee;
use ieee.numeric_bit.all;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity fuu is
end entity;

architecture fee of fuu is
signal unsigned_vector: ieee.numeric_bit.unsigned (7 downto 0)
:= "11001010";
signal bit_val: bit_vector (7 downto 0);
signal un_signed: ieee.numeric_bit.unsigned (7 downto 0);
signal unsigned_slv: ieee.numeric_std.unsigned (7 downto 0);
signal bit_unsigned: ieee.numeric_bit.unsigned (7 downto 0);
begin
bit_val <= bit_vector(unsigned_vector);
un_signed <= ieee.numeric_bit.unsigned(bit_val);
unsigned_slv <= ieee.numeric_std.unsigned(to_stdlogicvector(bit_val));
bit_unsigned <= ieee.numeric_bit.unsigned(
to_bitvector(std_logic_vector(unsigned_slv))
);
end architecture;

Selected names overcome the issue of ambiguity with two types named unsigned.

(And this example also analyzes, elaborates and simulates)

 

[Muhammad]

On Monday, January 7, 2002 11:08:40 PM UTC+1, pacific ocean wrote:

Looking for links to interleaver design for Turbo codes.

THX
Fredj

hi,
i need the code for interleaver can u give me plz..

thanks