Clock Edge notation

[Zara]

On Mon, 13 Nov 2006 23:35:02 GMT, james <george@washington.edu> wrote:

On Sun, 12 Nov 2006 06:19:50 -0800, "ec" <wavesoft@netvision.net.il
wrote:

+++Hi All
+++
+++Is VHDL just for qualified emgimeers ?
+++
+++I am a old elect. techition with alot of experince and knowledge.
+++
+++I want to get into VHDL based designing.
+++
+++What are my theoretical chances ?
+++Thanks
+++ec
+++
***********

Based on your typing skills, you are going to spend a huge amount of
time debugging the syntax errors that should abound in your code.

Other than that a cave man can learn VHDL.

if rising_edge(SUN) then
if visible(MAMOUTH) then
hunt(MAMMOUTH);
eat_as_much_as_you_can();
else
hungry<='1';
end if;
end if;

Maybe I should trie to harvest berries to avoid this hungry signal
being asserted! As soon as copper=(others=>'1') I will start on it.

 

[Charles Steinkuehler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ruben.gue@gmail.com wrote:

where inhibitory_weights_array is defined in the package
type_definitions as:

TYPE inhibitory_weights_array IS array(0 to 23) of std_logic_vector(15
downto 0);

You generally can't do multi-dimensional arrays this way due to how
std_logic_vector is defined. I usually have to use a real
muti-dimensional array type specification:

TYPE inhibitory_weights_array IS array(0 to 23, 15 downto 0) of std_logic;

....or make a subtype:

subtype weights is std_logic_vector(15 downto 0);
TYPE inhibitory_weights_array IS array(0 to 23) of weights;

- --
Charles Steinkuehler
cstein@newtek.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)

iD8DBQFFWpaaenk4xp+mH40RAhw3AKCVFrVHhwwdh+kVLSXCc9l17w5j2QCfSNTA
GmfZcRYs9itT7Q9+A/BHlDg=
=7W/o
-----END PGP SIGNATURE-----

 

[black_duck]

Charles Steinkuehler wrote:

You generally can't do multi-dimensional arrays this way due to how
std_logic_vector is defined. I usually have to use a real
muti-dimensional array type specification:

TYPE inhibitory_weights_array IS array(0 to 23, 15 downto 0) of std_logic;

...or make a subtype:

subtype weights is std_logic_vector(15 downto 0);
TYPE inhibitory_weights_array IS array(0 to 23) of weights;

Charles Steinkuehler
cstein@newtek.com

It looks interesting, I never thought doing it this way, I am going to
try it right now, and I let you know what happens, if it works, it will
solve my problem indeed.

Thanks Charles, I'll keep you updated.

Ruben

 

[backhus]

Hi,
actually VHDL don't need delta delays at all.
BUT, simulators do.
Since VHDL Simulators ar in general event driven simulators, and they
run on sequential machines (e.g. your PC) it's hard to write an
algorithm that simulates simultaneous signal changes.

So the simulator evaluates one signal, and the chane becomes valid at
the next delta cycle which is an event for the simulator to evaluate the
next signal etc.

Delta cycles (Or Delta delays) consumes no time in simulation but time
for simulation.

Try to simulate a combinatorical feedback loop e.g. in Modelsim like
A<= not A;

Your simulation time will stay at 0 ns but your simulator runs forever,
or at least until he exeeds some memory limit and gives an error message
(Version dependent).

A concurrent statement in VHDL is just the short form of a process.


A <= B and C;

is the same as

Process (B,C)
begin
A <= B and C;
end process;

But...while

A <= B and C;
B <= C or D;

and

Process (B,C,D)
begin
A <= B and C;
B <= C or D;
end process;

give the same results in synthesis and simulation,
the simulator may internally handle them differently.
This may cause a different number of delta cycles, but as said before
there's no real delay involved.

Have a nice simulation
Eilert

bhavanireddy@gmail.com schrieb:

Hi,

I am new to VHDL and really don't understand the need for delata delays
in concurrent statements. I, infact understand the need for delta
delays in "process" statements. Are delta delays applicable only in
"process" statements?

 

[Jonathan Bromley]

On Wed, 15 Nov 2006 14:15:52 +0100, backhus
<nix@nirgends.xyz> wrote:

Hi,
actually VHDL don't need delta delays at all.
BUT, simulators do.

Since VHDL's reason for existence is no more nor less than
to define the behaviour of a simulator, I think maybe you need
to re-phrase that just a little more carefully...
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

Not _exaclty_ correct on that last example. With the separate
concurrent assignment statements, an event on D does not cause a
transaction on A (A'transaction = true), whereas in the combined
process, it does. Not a big difference, but in behavioral modelling
(e.g. testbenches), it can make a difference in the way some code
reacting to A behaves.

They are identical WRT synthesis, and simulation of synthesizable code
(i.e. with no references to A'transaction).

Andy


backhus wrote:

But...while

A <= B and C;
B <= C or D;

and

Process (B,C,D)
begin
A <= B and C;
B <= C or D;
end process;

give the same results in synthesis and simulation,
the simulator may internally handle them differently.
This may cause a different number of delta cycles, but as said before
there's no real delay involved.

Have a nice simulation
Eilert

bhavanireddy@gmail.com schrieb:
Hi,

I am new to VHDL and really don't understand the need for delata delays
in concurrent statements. I, infact understand the need for delta
delays in "process" statements. Are delta delays applicable only in
"process" statements?

 

[Ray Andraka]

black_duck wrote:

On 13 Nov, 15:55, "Derek Simmons" <dereks...@gmail.com> wrote:

Keep in mind you are porting an algorithm that was original writen in a
programming language to a hardware description language, instead of
thinking of 'passing' you should be thinking of 'connecting' or
'sharing'. Instead of doing what you are trying to do why not store the
values in a chunk of memory and connect the address and data bus to
your component.



Hello Derek,

Thanks for your answer. Actually, connecting a memory to the input of
the entity is a higher level program, this is just a sub-module of
another VHDL program, so following your advice, I am going to test the
VHDL program with the memory connected to the component "weight_adder"
and see what happens. However, I usually test all sub-modules before
testing the top module so I can get rid of possible bugs in any of the
sub-modules, which is what I wanted to do here. I still think there is
something wrong with the ISE dealing with this kind of multidimensional
arrays, because even when I change the port to individual
std_logic_vector(15 downto 0) inputs, and use an internal signal as
multidimensional array the simulation cannot be carried out for the
same reason.

Kind regards,

Ruben

The multidimensional array works fine within the architecture, I use it
frequently, although most of my work is on synplify. I'm pretty sure
that XST has not had any problems synthesizing these multidim arrays as
long as the type declaration and signal is local. Most of the tools
however do not support using it as a port on your entity. You can pack
the array into a large std_logic_vector for the port connections and
then unpack it inside the architecture.

entity tree_adder is
port (
A : in std_logic_vector(24*16-1 downto 0);
S : out std_logic_vector(15 downto 0)
);
end tree_adder;

architecture Behavioral of tree_adder is

TYPE inhibitory_weights_array IS array(0 to 23) of std_logic_vector(15
downto 0);
signal A_array: inhibitory_weights_array;

begin
process(A)
begin
for i in 0 to 23 loop
A_array(i) <= A((24-i)*16-1 downto (23-i)*16);
end loop;

 

[Andy Peters]

james wrote:

Other than that a cave man can learn VHDL.

There's a car-insurance commercial in here, somewhere.

-a

 

[black_duck]

Ray Andraka wrote:

The multidimensional array works fine within the architecture, I use it
frequently, although most of my work is on synplify. I'm pretty sure
that XST has not had any problems synthesizing these multidim arrays as
long as the type declaration and signal is local. Most of the tools
however do not support using it as a port on your entity. You can pack
the array into a large std_logic_vector for the port connections and
then unpack it inside the architecture.

entity tree_adder is
port (
A : in std_logic_vector(24*16-1 downto 0);
S : out std_logic_vector(15 downto 0)
);
end tree_adder;

architecture Behavioral of tree_adder is

TYPE inhibitory_weights_array IS array(0 to 23) of std_logic_vector(15
downto 0);
signal A_array: inhibitory_weights_array;

begin
process(A)
begin
for i in 0 to 23 loop
A_array(i) <= A((24-i)*16-1 downto (23-i)*16);
end loop;

Wow!, both schemes (Charles' and Ray's) work perfect! thank you very
much for your help, now everything looks much easier.

Thanks again Ray, Charles and Derek, I owe you one!

Ruben

 

[kclo4]

Davy a écrit :

Hi, rickman,

Thanks!

Can you tell me what's Nonpipelined bus mean?

Best regards,
Davy

rickman wrote:
Davy wrote:
Hi all,

I always heard Nonpipelined bus. Is any bus Nonpipelined? Or is there
Pipelined bus or other types of bus. Thanks in advance!
Sure, a bus can be pipelined. In many FPGAs busses are actually a
collection of point to point connections with multiplexers. The
multiplexers can be pipelined in sections which will allow faster clock
speeds.

A pipelined bus is a bus that join two point A and B but you add a

register (or more) on the way so it will take some clock cycle to
arrive(as much as register you add) So a nonpipelined is one without any
register
Pipelining a bus permit to break the critical path of the bus but it
adds latency. The delay will still be the same but the max frequency
will be increase.

ex :

port(
din : in std_logic(15 downto 0);
dout : out std_logic(15 downto 0)
);

....

signal bus : std_logic_vector(15 downto 0);
signal bus_reg : std_logic_vector(15 downto 0);
------------------------------------------------------------------------
--Nonpipelined bus
-- critical path= 12ns
-- latency =0 clock cycle
bus <= din;
dout <= bus;
------------------------------------------------------------------------
--Pipelined bus (1 register)
-- critical path = 6ns
-- latency =1 clock cycle

process(clk)
begin
if rising_edge(clk) then
bus <= din;
end;
dout <= bus;
------------------------------------------------------------------------
--Pipelined bus (2 registers)
-- critical path = 4ns
-- latency =2 clock cycle

process(clk)
begin
if rising_edge(clk) then
bus <= din;
dout <= bus;
end;
------------------------------------------------------------------------
--Pipelined bus (3 registers)
-- critical path = 3ns
-- latency =2 clock cycle

process(clk)
begin
if rising_edge(clk) then
bus <= din;
bus_reg <= bus;
dout <= reg ;
end;
------------------------------------------------------------------------



alexis

 

[Ajeetha]

Try:

vsim -c top_tb
vsim> add log -r /
vsim> run -all;exit

This would create a WLF file for you, after that you can convert to a
VCD (ASCII) format if your TEXT - but why do you need a text file?

Regards
Ajeetha, CVC
www.noveldv.com
Guilherme Corręa wrote:

Hello,

Could you possibly tell me if there is a way to save the resulting
information from a ModelSim simulation?
I would like to save these waveforms as a text file.

Thanks.
Guilherme Corręa.

 

[nfirtaps]

Thomas thanks for your reply.

I am a little unclear that clk2 could have the problem here since it
only starts the clk1 process. The clk1 process then stops itself after
writing 1024 bytes. Could you please explain a little more what you
mean? It seems to me as clk2 can start the clk1 process anytime an no
synchronizing problems would occur, because the clk1 process stops
itself.

Thanks,
Lloyd

 

[Hans]

I am not sure if the OEM version is restricted in this way but I would
suggest you simply try it out. Run your simulations and save the wlf files.
Then reload them all (wlf files that is) and see if you can open up multiple
waveform windows. I would also suggest you checkout the window panes option
which can be quite useful if you have to display lots of signals.

Hans
www.ht-lab.com



"OL" <noname@free.fr> wrote in message news:ekeb9r$dvd$1@ccpntc8.in2p3.fr...

I'm beginning to use the Altera Edition of Modelsim (6.1d). Is there a way
to have, in a simulation, several waveform windows ? If not, is it
possible with the full Modelsim edition ?

 

[Hans]

Another option is to use the list window, you can export this window to a
tabular list (amonst others). You will need to do some post processing on
this file since it records the signal values for each delta,

Hans
www.ht-lab.com

"Ajeetha" <ajeetha@gmail.com> wrote in message
news:1164634697.018285.159640@f16g2000cwb.googlegroups.com...
Try:

vsim -c top_tb
vsim> add log -r /
vsim> run -all;exit

This would create a WLF file for you, after that you can convert to a
VCD (ASCII) format if your TEXT - but why do you need a text file?

Regards
Ajeetha, CVC
www.noveldv.com
Guilherme Corręa wrote:

Hello,

Could you possibly tell me if there is a way to save the resulting
information from a ModelSim simulation?
I would like to save these waveforms as a text file.

Thanks.
Guilherme Corręa.

 

[KJ]

nfirtaps wrote:

Hello, I am using my FPGA to write 1024 bytes to another device. I am
noticing "sometimes" it writes 1025 bytes. I am wondering it this
could be a timing glitch.
Appears to be.

A few comments:
1. I don't see what is generating the signal 'clk2' but I'm assuming
that it is asynchronous to clk1.
2. The process that generates 'senddata' will infer a latch since it
does not assign senddata anything if 'trigger' and 'stop' are both '0'.
I understand that logically this is probably what you want to do, but
transparent latches are always a problem in an FPGA environment; make
it a clocked process. Since the output senddata is needed in the clk1
domain you should use clk1 as the clock for this process.
3. As it is, 'senddata' is a function of both clock domains since it is
a function of 'trigger' which comes out of the clk2 domain (since it
depends on counter2) and is also a function of 'stop' (which comes out
of the clk1 domain). The usage of senddata in the clk1 process will
require that it meet a setup time relative to clk1 which, depending on
how the synthesizer actually implements the logic it may not. This is
probably at the root of why you occasionally get extra writes, senddata
is probably failing timing.

The fix for #3 is mostly the same as with #2, make sure that senddata
comes from a single clock domain (i.e. clk1). The next thing to clean
up is 'trigger' so that you can use it properly. Change trigger to be
a new signal trigger_clk2 by putting the logic for what you currently
have for trigger inside a clocked process that is clocked by clk2.
Now, you'll need to move trigger_clk2 over into the clk1 domain so
inside the clocked process that generates senddata, add a line that is
trigger <= trigger_clk2. The reason for the two step approach is that
all 10 bits of counter2 are synched to clk2 so it is basically hopeless
to look for counter2 >= 1024 within the clk1 domain, this must be done
within the clk2 domain. The result of that comparison is the new
signal trigger_clk2 which is functionally what you want, but not
synchronized to clk1 as it will need to be...hence the second step.

You might also be able to get away without the second step of trigger
<= trigger_clk2 since it appears that the logic you have for senddata
is the only thing that depends on the trigger signal. If that's the
case, then the resynchronization to the clk1 domain will happen with
senddata now being generated in the clk1 domain.

KJ

 

[nfirtaps]

KJ,
I really appreciate your reply. I have done all the things you have
instructed but have not had any better luck. It maybe another issue I
am not aware of. Is the design you propose robust to glitches in the
counters, I have seen many people implment grey code counters? I am
mostly concerned with counter1, that it may take an extra clock cycle
to set data_en to go low. After all by it not going low at the check
(counter1 < 1024) another rising edge of the clock latches one extra
byte of data.

One point I did not make was that clk1 is an input clock, it comes in
through the FPGA and goes into a DLL. The device that reads this data
will sample data_out and data_en at the rising edges of this clock. I
have the FPGA just generating handshaking signals in sync with this
input clock. The DLL does no phase shifting or clock multiplication.
Is there some sort of issue buried by this method?

Thanks,
Lloyd

 

[KJ]

nfirtaps wrote:

KJ,
I really appreciate your reply. I have done all the things you have
instructed but have not had any better luck. It maybe another issue I
am not aware of. Is the design you propose robust to glitches in the
counters,
If you implemented as I suggested then 'yes' it should be robust.

Where you run into problems is where signals get generated in one clock
domain and then 'used' in another clock domain. Generating counter2
off of clk2 and then checking to see if counter2 is equal to some
number while inside an 'if rising_edge(clk1)' statement is an example
of such a problem case.

I have seen many people implment grey code counters?
Gray code counters won't be of any help here. On the surface it seems

you have some relatively straightforward function to implement. If
it's 'flaky' then this is a timing problem which needs to be solved.
Trying to use gray code will not uncover what the timing issue really
is and may end up masking it for a bit of time....which makes things
worse, since then you'll be in a situation where things might appear to
be working even though you have no idea what fixed it.

I am
mostly concerned with counter1, that it may take an extra clock cycle
to set data_en to go low. After all by it not going low at the check
(counter1 < 1024) another rising edge of the clock latches one extra
byte of data.

One point I did not make was that clk1 is an input clock, it comes in
through the FPGA and goes into a DLL. The device that reads this data
will sample data_out and data_en at the rising edges of this clock. I
have the FPGA just generating handshaking signals in sync with this
input clock. The DLL does no phase shifting or clock multiplication.
Is there some sort of issue buried by this method?
Maybe. Can you...

1. Post your updated code including whatever is generating clk1 and
clk2?
2. Have you checked with a simulator that the design is doing what you
want it to do?
3. Post the code for your simulation testbench if you have one.

KJ

 

[Paul Floyd]

On 3 Nov 2006 05:32:51 -0800, yaveh (Yet Another Vhdl Engineer Hoping)
<fcamarero@altek-technology.de> wrote:

Hi,

I consider good design practise to write case statements with a
default 'others' choice to be able to catch design errors and
properly mark them with an assert statement.

This works fine with VHDL sequentials and concurrent assert statements.

However, I can´t get VHDL-AMS simultaneous assert statement to work.
My tool complain with "unknown concurrent/simultaneous statement "
when I write, e.g.:

architecture [...] of [...] is
shared variable a : [...]
[...]
begin
[...]
case a use
when a1=> v'dot == -G - v**2*Air_Res; ;-- e.g.
when b2=> [...]
when others =
assert false report "case defaulted!" severity failure;
end case;
end;

If you use VHDL-AMS, don´t you find it necessary?
I just can´t find thsi construct in the Quick Reference of several
VHDL-AMS Simulator...

I haven't checked in the LRM, but I don't think that this is allowed.

A somewhat ugly solution, which doesn't quite do what you want (but
might be good enough for simulation), might be to define a function that
contains an assert.

For instance

function my_assert(s: string) return [type of a1, b2 ...] is
begin
assert false report s severity failure;
return 0.0; -- or whatever is compatible with a1 ...
end;


case a use
when a1=> v'dot == -G - v**2*Air_Res; ;-- e.g.
when b2=> [...]
when others =>
dummy == my_assert("case defaulted!");
end case;

A bientot
Paul
(Not speaking for Mentor Graphics)
--
Paul Floyd http://paulf.free.fr (for what it's worth)
Surgery: ennobled Gerald.

 

[nfirtaps]

In this code clk1 = usb_ifclk, and clk2 = ddc_clk. Also, rptr =
counter1, and wptr = counter2. Trigger will now be startchunk. The
trigger is started by startchunk_clk2, and stopped by stopchunk_clk1.


Thanks again !!!

*********************************** vhdl file
*****************************
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.numeric_std.all;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
library UNISIM;
use UNISIM.VComponents.all;

entity usb_backend is
Port (
-- Inputs/Outputs for FX2
usb_ifclk : in STD_LOGIC;
usb_slwr : out STD_LOGIC;
usb_fd : out STD_LOGIC_VECTOR(15 downto 0);
usb_ep6ff : in STD_LOGIC;
usb_ep6ef : in STD_LOGIC;

-- Inputs from Down Converter Logic
ddc_clk : in std_logic;
ddc_data : in std_logic_vector(15 downto 0);

reset : in std_logic
);
end usb_backend;

architecture Behavioral of usb_backend is

constant NBITS : integer := 14;
constant READCHUNKSIZE : integer := 511;

subtype POINTER is integer range 0 to (2**NBITS)-1;
subtype BYTECOUNT is integer range 0 to (2**NBITS)-1;

type MEMORY is array(0 to 16383) of std_logic_vector(15 downto 0);

signal rptr : POINTER;
signal wptr : POINTER;
signal rbytec : BYTECOUNT;
signal wbytec : BYTECOUNT;
signal circ : MEMORY;

signal data_out : std_logic_vector(15 downto 0);
signal readchunk : std_logic;
signal startchunk : std_logic;
signal startchunk_clk2 : std_logic;
signal stopchunk_clk1 : std_logic;

begin
usb_fd <= data_out after 1ns;

reader : process(usb_ifclk,reset) begin
if (reset = '1') then
rptr <= 0;
rbytec <= 0;
stopchunk_clk1 <= '0';
-- usb_slwr <= '0';
elsif(usb_ifclk'event and usb_ifclk = '1') then
if (readchunk = '1') then
stopchunk_clk1 <= '0';
if(rbytec = READCHUNKSIZE-1) then
stopchunk_clk1 <= '1'; -- takes one extra clock cycle to stop
end if;
if(rbytec < READCHUNKSIZE) then
data_out <= circ(rptr);
rptr <= (rptr + 1) mod 16384;
rbytec <= (rbytec + 1) mod 16384;
usb_slwr <= '1';
else
usb_slwr <= '0';
rbytec <= 0;
stopchunk_clk1 <= '1';
end if;
else
stopchunk_clk1 <= '0';
end if;
end if;
end process;

startchunk <= startchunk_clk2;

process(usb_ifclk,startchunk,stopchunk_clk1,reset)
begin
if (reset = '1') then
readchunk <= '0';
elsif(usb_ifclk'event and usb_ifclk = '1') then
if (stopchunk_clk1 = '1') then
readchunk <= '0';
elsif (startchunk = '1' and usb_ep6ef = '1') then
readchunk <= '1';
end if;
end if;
end process;

writer : process(ddc_clk,reset) begin
if(reset = '1') then
wptr <= 0;
wbytec <= 0;
elsif(ddc_clk'event and ddc_clk = '1') then
circ(wptr) <= ddc_data;
wptr <= (wptr + 1) mod 16384;
wbytec <= (wbytec + 1) mod 16384;

if (wbytec >= READCHUNKSIZE) then
wbytec <= 0;
startchunk_clk2 <= '1';
else
startchunk_clk2 <= '0';
end if;
end if;
end process;
end Behavioral;


********************** Testbench file run for ~ 3 msec
**********************
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.numeric_std.all;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
library UNISIM;
use UNISIM.VComponents.all;

entity usb_backend is
Port (
-- Inputs/Outputs for FX2
usb_ifclk : in STD_LOGIC;
usb_slwr : out STD_LOGIC;
usb_fd : out STD_LOGIC_VECTOR(15 downto 0);
usb_ep6ff : in STD_LOGIC;
usb_ep6ef : in STD_LOGIC;

-- Inputs from Down Converter Logic
ddc_clk : in std_logic;
ddc_data : in std_logic_vector(15 downto 0);

reset : in std_logic
);
end usb_backend;

architecture Behavioral of usb_backend is

constant NBITS : integer := 14;
constant READCHUNKSIZE : integer := 511;

subtype POINTER is integer range 0 to (2**NBITS)-1;
subtype BYTECOUNT is integer range 0 to (2**NBITS)-1;

type MEMORY is array(0 to 16383) of std_logic_vector(15 downto 0);

signal rptr : POINTER;
signal wptr : POINTER;
signal rbytec : BYTECOUNT;
signal wbytec : BYTECOUNT;
signal circ : MEMORY;

signal data_out : std_logic_vector(15 downto 0);
signal readchunk : std_logic;
signal startchunk : std_logic;
signal startchunk_clk2 : std_logic;
signal stopchunk_clk1 : std_logic;

begin
usb_fd <= data_out after 1ns;

reader : process(usb_ifclk,reset) begin
if (reset = '1') then
rptr <= 0;
rbytec <= 0;
stopchunk_clk1 <= '0';
-- usb_slwr <= '0';
elsif(usb_ifclk'event and usb_ifclk = '1') then
if (readchunk = '1') then
stopchunk_clk1 <= '0';
if(rbytec = READCHUNKSIZE-1) then
stopchunk_clk1 <= '1'; -- takes one extra clock cycle to stop
end if;
if(rbytec < READCHUNKSIZE) then
data_out <= circ(rptr);
rptr <= (rptr + 1) mod 16384;
rbytec <= (rbytec + 1) mod 16384;
usb_slwr <= '1';
else
usb_slwr <= '0';
rbytec <= 0;
stopchunk_clk1 <= '1';
end if;
else
stopchunk_clk1 <= '0';
end if;
end if;
end process;

startchunk <= startchunk_clk2;

process(usb_ifclk,startchunk,stopchunk_clk1,reset)
begin
if (reset = '1') then
readchunk <= '0';
elsif(usb_ifclk'event and usb_ifclk = '1') then
if (stopchunk_clk1 = '1') then
readchunk <= '0';
elsif (startchunk = '1' and usb_ep6ef = '1') then
readchunk <= '1';
end if;
end if;
end process;

writer : process(ddc_clk,reset) begin
if(reset = '1') then
wptr <= 0;
wbytec <= 0;
elsif(ddc_clk'event and ddc_clk = '1') then
circ(wptr) <= ddc_data;
wptr <= (wptr + 1) mod 16384;
wbytec <= (wbytec + 1) mod 16384;

if (wbytec >= READCHUNKSIZE) then
wbytec <= 0;
startchunk_clk2 <= '1';
else
startchunk_clk2 <= '0';
end if;
end if;
end process;
end Behavioral;

 

[OL]

Hans wrote:

I am not sure if the OEM version is restricted in this way but I would
suggest you simply try it out. Run your simulations and save the wlf files.
Then reload them all (wlf files that is) and see if you can open up multiple
waveform windows.
Yes, I tried this, but it does not seem to work. I can't open multiple

windows.

I would also suggest you checkout the window panes option

which can be quite useful if you have to display lots of signals.

Ok, I will try this.

Thanks for your reply.

OL