need a cheap student edition FPGA

[NigelE]

Davy wrote:

Hi all,

I was told that transaction layer communication is the very important
thing in SystemVerilog testbench construction.

And in VMM and AVM, they use queue (VMM) or virtual interface (AVM) to
mimic the Mail-box idea. Mail-box is defined in standard SystemVerilog
standard.

Why they don't use Mail-box directly? Or is there any disadvantage to
use Mail-box?

Best regards,
Davy

Hi Davy

I can't speak for the VMM, but the AVM does use SystemVerilog mailboxes
at the heart of its tlm communication.

The reason this is not obvious to the user is because the AVM channels
(eg tlm_fifo) provide additional functionality over a pure mailbox,
with multiple communication interfaces (put, get, peek, blocking,
non-blocking ...) and analysis ports to send any transaction
written/read to/from the channel to any registered analysis components
(scoreboards, coverage collectors ...)

If you've downloaded the AVM (www.mentor.com/go/cookbook), have a look
at
utilities/systemverilog/avm/tlm/tlm_fifos.svh
for the detailed code and you'll see the mailbox construct.

Also, the AVM's use of virtual interfaces is not related to tlm
communication.
The virtual interface is the mechanism used to link the class based
verification environment to the module based dut.
Generally this is connecting a pin-level transactor (with a virtual
interface) to an actual interface on the dut.

Hope this helps

regards

- Nigel

 

[Davy]

Hi NigelE,

Thanks a lot! I mis-understand virtual interface.

Is there any web seminar or online video talk about AVM? That I want to
understand AVM more clearly.

Best regards,
Davy

NigelE wrote:

Davy wrote:
Hi all,

I was told that transaction layer communication is the very important
thing in SystemVerilog testbench construction.

And in VMM and AVM, they use queue (VMM) or virtual interface (AVM) to
mimic the Mail-box idea. Mail-box is defined in standard SystemVerilog
standard.

Why they don't use Mail-box directly? Or is there any disadvantage to
use Mail-box?

Best regards,
Davy

Hi Davy

I can't speak for the VMM, but the AVM does use SystemVerilog mailboxes
at the heart of its tlm communication.

The reason this is not obvious to the user is because the AVM channels
(eg tlm_fifo) provide additional functionality over a pure mailbox,
with multiple communication interfaces (put, get, peek, blocking,
non-blocking ...) and analysis ports to send any transaction
written/read to/from the channel to any registered analysis components
(scoreboards, coverage collectors ...)

If you've downloaded the AVM (www.mentor.com/go/cookbook), have a look
at
utilities/systemverilog/avm/tlm/tlm_fifos.svh
for the detailed code and you'll see the mailbox construct.

Also, the AVM's use of virtual interfaces is not related to tlm
communication.
The virtual interface is the mechanism used to link the class based
verification environment to the module based dut.
Generally this is connecting a pin-level transactor (with a virtual
interface) to an actual interface on the dut.

Hope this helps

regards

- Nigel

 

[NigelE]

Davy wrote:

Hi NigelE,

Thanks a lot! I mis-understand virtual interface.

Is there any web seminar or online video talk about AVM? That I want to
understand AVM more clearly.

Best regards,
Davy

Hi Davy

Try a look at

http://www.mentor.com/products/fv/events/

You'll find listed in the online events, our recent 'Hitchhikers Guide
to Verification' seminar that covers AVM and other SV verification
topics.

It's split into 5 sessions so you don't need to watch it all at once

Best regards

- Nigel

 

[Michael]

I know how to make modules instantiations. I don't understand how it
works and how good is that. How can it help me in comparison to an
"old" style?

ABC wrote:

Hi Micheal,
Example
module top();
wire a,b,c,d,e;
same_port inxta (.a(a),.b(b));
rename_concat inxtb ({a,b},c,d,e);
complex_ports inxtc ({a,b},c);
endmodule

module same_port (.a(i), .b(i));
inout i;
endmodule

module renamed_concat (.a({b,c}), f, .g(h[1]),.e(h[0]));
input b,c,f;
input [1:0] h;
endmodule

module complex_ports ({c,d}, .e(f));
input c,d,f;
endmodule

Best regards,
ABC

Michael wrote:
Hello all,

I've discovered a new way of ports declaration. Could somebody
exlain to me how it works and how can it be used for design?

module same_port (.a(i), .b(i));

module renamed_concat (.a({b,c}), f, .g(h[1]));

module complex_ports ({c,d}, .e(f));

Thanks a lot.

 

googler wrote:

Is there a way I can use the absolute time unit (as shown as part of
comment on right) in my code instead of having to use the time
difference relative to last statement?

As others have suggested, you could use intra-assignment delays with
nonblocking assignments, to schedule them all at the start for specific
absolute times. This does work if you schedule multiple values for the
same variables at different times. You could also use a fork..join
block instead of a begin..end block, so that each statement starts
executing at the same time instead of sequentially. This would give
much the same effect, and would work for things other than assignments.
Or you can use the mechanism of computing the relative delay from the
current time to the desired time, using $time.

All of these would work. They are also likely to have negative effects
on your simulator performance.

 

[ABC]

Hi Micheal,
I am confuse with your reply.

Best regards,
ABC

Michael wrote:

I know how to make modules instantiations. I don't understand how it
works and how good is that. How can it help me in comparison to an
"old" style?

ABC wrote:
Hi Micheal,
Example
module top();
wire a,b,c,d,e;
same_port inxta (.a(a),.b(b));
rename_concat inxtb ({a,b},c,d,e);
complex_ports inxtc ({a,b},c);
endmodule

module same_port (.a(i), .b(i));
inout i;
endmodule

module renamed_concat (.a({b,c}), f, .g(h[1]),.e(h[0]));
input b,c,f;
input [1:0] h;
endmodule

module complex_ports ({c,d}, .e(f));
input c,d,f;
endmodule

Best regards,
ABC

Michael wrote:
Hello all,

I've discovered a new way of ports declaration. Could somebody
exlain to me how it works and how can it be used for design?

module same_port (.a(i), .b(i));

module renamed_concat (.a({b,c}), f, .g(h[1]));

module complex_ports ({c,d}, .e(f));

Thanks a lot.

 

Michael wrote:

I know how to make modules instantiations. I don't understand how it
works and how good is that. How can it help me in comparison to an
"old" style?

Most of the time it doesn't help. It is rarely used. The most common
use is for a module that connects its two ports together, using two
external ports with different names.

It allows you to declare a port whose external name used in the
instantiation is different from the internal name used inside the
module. It allows connecting an external port to parts of several
internal nets, or multiple external ports to parts of the same internal
net, in case the most convenient internal groupings are different from
the natural external groupings. It allows connecting the same internal
net bit to multiple different external port bits. It allows the
connections to the ports from inside the module to have much the same
flexibility that connections to the ports from outside the module have.

If you have a use for this capability, then it is convenient that the
language allows it. Otherwise, you shouldn't waste time trying to find
a way to use it just because it exists.

 

[Davy]

NigelE wrote:

Davy wrote:
Hi NigelE,

Thanks a lot! I mis-understand virtual interface.

Is there any web seminar or online video talk about AVM? That I want to
understand AVM more clearly.

Best regards,
Davy


Hi Davy

Try a look at

http://www.mentor.com/products/fv/events/

You'll find listed in the online events, our recent 'Hitchhikers Guide
to Verification' seminar that covers AVM and other SV verification
topics.

It's split into 5 sessions so you don't need to watch it all at once

Best regards

- Nigel

Hi Nigel,

Thanks a lot for the help!

Best regards,
Davy

 

[Davy]

Davy wrote:

NigelE wrote:
Davy wrote:
Hi NigelE,

Thanks a lot! I mis-understand virtual interface.

Is there any web seminar or online video talk about AVM? That I want to
understand AVM more clearly.

Best regards,
Davy


Hi Davy

Try a look at

http://www.mentor.com/products/fv/events/

You'll find listed in the online events, our recent 'Hitchhikers Guide
to Verification' seminar that covers AVM and other SV verification
topics.

It's split into 5 sessions so you don't need to watch it all at once

Best regards

- Nigel

Hi Nigel,

Thanks a lot for the help!

Best regards,
Davy

The direct path to 'Hitchhikers Guide to Verification' seminar is
http://www.mentor.com/products/fv/events/hitchhiker_online_sem.cfm#
Just a memo for myself

Thanks!
Davy

 

[Davy]

Hi NigelE,

Is AVM IEEE 1800 compatible? Thanks!

Thanks!
Davy

NigelE wrote:

Davy wrote:
Hi NigelE,

Thanks a lot! I mis-understand virtual interface.

Is there any web seminar or online video talk about AVM? That I want to
understand AVM more clearly.

Best regards,
Davy


Hi Davy

Try a look at

http://www.mentor.com/products/fv/events/

You'll find listed in the online events, our recent 'Hitchhikers Guide
to Verification' seminar that covers AVM and other SV verification
topics.

It's split into 5 sessions so you don't need to watch it all at once

Best regards

- Nigel

 

[AdamRose]

Davy wrote:

Hi NigelE,

Is AVM IEEE 1800 compatible? Thanks!

Yes it is.

Adam.

Adam Rose
Verification Technologist
Mentor Graphics

 

[Davy]

Hi Jonathan,

I understand

Best regards,
Davy

Jonathan Bromley wrote:

On 12 Nov 2006 21:39:23 -0800, "Davy" <zhushenli@gmail.com> wrote:


I have find the "description" in groups.google.com

Don't believe everything you find on google

This question has been raised before. The general feeling seems to
be:
- SystemVerilog is a superset of Verilog. Indeed, there is even a
serious proposal to merge the 1364 and 1800 standards into a
single standard at some point in the future. So, if we're serious
about Verilog, we better be talking about SystemVerilog too!
- People who know about, and are interested in, SystemVerilog
are likely to be interested in Verilog too. So this is a good
place to seek them out.
--
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.

 

[PeteS]

Borge wrote:

Good idea!

Or perhaps even better, have a register with no reset value be counted
up towards a preset and let the local reset be active between preset
one and preset two. After reaching preset two there's no more counting.


If we can KNOW that the register is reset to either 0xFF or 0x00, and
not the preset values, this should generate a local reset pulse.

So, for example, a 4-bit register could count up from 0 (or F) to 2,
activate reset, count to 4 and then deactivate reset and stop counting.


I love your abbreviations, but how would you declare the 4-bit register
in practical, synthesizable Verilog?


Thanks,
Borge

Without trying to write verilog after a couple of glasses of wine, use
the 'initial' keyword for a block instead of 'always'; it gets executed
precisely once (immediately post configuration).

Cheers

PeteS

Slurp skrev:> As all the FPGA's FF's are reset to zero on powerup, why
not create a
counter that inhibits itself after reaching a suitable a preset value when
clocked with one of your system clocks?
Use the terminal count decode as your POR (adjusting polarity as
appropriate).


Slurp

 

[mjl296@hotmail.com]

continue will jump to the start of the next iteration of the enclosing
loop.

For your example, it stops the case statement being executed in any
clock cycle where reset is asserted.


Davy wrote:

Hi all,

There is a SystemVerilog/Verilog code.
What's "continue" in "if" block mean? If I delete "continue", will the
function same? Thanks!

//------------
forever begin
@(posedge clk);
if (reset) begin
... ...
do something;
continue;
end

case(state)
... ...
do something;
... ...
end
//--------------

Best regards,
Davy

 

[Ajeetha]

Clocking block is recommended usage in testbench to avoid race
conditions. WIthout it, all your read/write or asynchronous and you are
required to explicitly synchronize them.

HTH
Ajeetha, CVC
www.noveldv.com
Davy wrote:

Hi,

I found in some SystemVerilog examples, people like to add Clocking
Block to driver and monitor. While some other SV examples only use
modport (don't use Clocking Block).

So I am confused with it.
1. Is it recommendation to use Clocking Block?
2. Shall I only use it in testbench component like driver and monitor
(shall I use it in responder)?


Best regards,
Davy

 

[gabor]

There are two issues when changing clock domains with
multibit data. The first is data coherency and this would
be addressed using Gray code. There are other methods
when the destination clock is much slower than the source
clock. My favourite is to create a sampling signal in the
source clock domain just after the edge in the destination
clock. Use this as a clock enable in the source clock
domain to latch the data, which is then used directly
at the next destination clock edge.

The second issue is metastability, and at 100 Hz I would
say this is not likely to become an issue. In the Gray code
case only one bit at a time is changing and therefore unless
your metastability window spans the source clock period
the sampled data will be usable at the next edge of 100 Hz.
The important issue here is not so much the two-stage
synchronizer, but the single point of sampling. i.e. at the
sampling clock edge only one flip-flop in the 100 Hz clock
domain can sample each bit. This seems to be addressed
in your slowclk process below. Of course this delays
your interrupt by 10 milliseconds.

moogyd@yahoo.co.uk wrote:

Hi experts,

Sorry for the cross posting, but I wanted to ensure a complete
readership. It's more a design question than language specific.

When I pass a signal between clock domains (clkfrom to clkto), I use
two FF's in the clkto domain prior to using the signal in this domain.
If there is a timing violation (setup or hold) at the first FF, then
the O/P will become metastable. i.e. Unknown, and it will stay in this
state for a time determind by a probability distribution.
We therefore use a second FF before we use the signal. Hopefully, the
O/P of the fist FF will be stable by the next clock edge. This is not
guarenteed, and depends on the clock frequency, target technology etc.
All we can say is that there is a probabilty of X% that it will always
work.

Therefore, first question : Is my understanding correct?

If so, I have another question.

If I am passing a signal from a fast clock domain (16MHz) to a slow
clock domain (100Hz) at 0.18us, do I need to synchronize?

e.g. As a simple example, I have a timer on a system bus. The cycle
time register is in the fast domain.

Ignoring reset's, (and assuming I gray code the counter) my code looks
like

p_fast : process(fastclk)
if fastclk'event and fastclk='1' then
if write_cycle='1' then
r_cycle <= wr_data ;
end if;
end if ;
end process ;

p_slow : process(slowclk)
if slowclk'event and slowclk='1' then
r_cycle_eq_count <=cycle_eq_count ; // This is an interrupt which
will be sync'ed into fast clock domain
if r_cycle_eq_count='1' then
r_count <= (others => '0') ;
else
r_count <= r_count + 1 ;
endif ;
end if ;
end process ;

assign cycle_eq_count = '1' when r_cycle=r_count else '0' ;

Is there a problem with this code?
If r_cycle changes around slowclk, there may be metastabity in
r_cycle_count, but this should have settled within a 100Hz cycle?

Any further suggestions/insights welcomed.

Steven

 

[Mike Treseler]

moogyd@yahoo.co.uk wrote:

When I pass a signal between clock domains (clkfrom to clkto), I use
two FF's in the clkto domain prior to using the signal in this domain.
If there is a timing violation (setup or hold) at the first FF, then
the O/P will become metastable. i.e. Unknown, and it will stay in this
state for a time determind by a probability distribution.

The most likely result of a timing violation in FF1 is proper
synchronization either on that edge or the next. The primary
job of the flop is to eliminate races to the subsequent flops
in the design by retiming the edges. The most common symptom of a logic
race is an "impossible" state transition.

The second flop is there to reduce the odds
of synchronization failure from say once a year to maybe
once every hundred years. That's cheap insurance.
Without any synchronization, I would expect a race problem
in much less than a year -- more likely in less than a millisecond.

For a synchronizer example, search for "retime"
in the reference design here:
http://home.comcast.net/~mike_treseler/

If I am passing a signal from a fast clock domain (16MHz) to a slow
clock domain (100Hz) at 0.18us, do I need to synchronize?

Yes.

The easiest way is to run the "slow" counter at 16MHz
using clock enables. See the "clock enabled counters"
source for an example. Or you could handshake the
transaction with ready and ack signals, properly
synchronized, of course.

e.g. As a simple example, I have a timer on a system bus. The cycle
time register is in the fast domain.

Is there a problem with this code?

Yes.

If you travel down this road you will
eventually reinvent the uart or the fifo.

-- Mike Treseler

 

[Guenter]

hdl_book_seller wrote:

We have about 34 copies left of the most popular Verilog reference
book, Thomas & Moorby's classic "The Verilog Hardware Language" at only
$32 -- over 73% off the Amazon price of $119.

[...]

*** The Verilog Hardware Description Language, 4th Edition -- 73% off
Sale price: $32 (save $87 off Amazon's price)

Isn't it interesting that Amazon sells the 4th edition of the book for
$119, but the 5th edition for $91.63?

Wonder why they still offer the old version?

Cheers,

Guenter

 

[Andy]

The second flop is assumed to have more timing margin on its input than
other flop inputs driven through combinatorial logic. If adequate
timing margin can be guaranteed to produce a desired probability of
failure, it does not matter whether it is one flop with no preceding
logic, or one or more flops, each with preceding logic.

As an example, say an asynchronous input is registered only once, and
then used to drive a load signal on a counter. Generally speaking, the
timing margin from clock to setup, going through the load muxes to all
the bits of the counter will be less than the timing margin to a
single additional flop immediately downstream from the synchronizing
flop. But, depending on routing, placement, and logic involved, there
can actually be less margin on the single flop than on the multiple
flops with preceding mux logic. Unless the timing is additionally
constrained to give you that extra margin (in either case), there is no
guaranteed improvement in probability of failure from inserting a
second flop after the synchronizing flop (we call the second flop the
meta[stable]-rejecting flop).

The above only holds true for non-causal (i.e. clocked) inputs. It is
not true for causal (clock or asyncrhonous) inputs. Never drive causal
inputs from output of the first synchronizing flop.

You should also constrain the synchronizing input register (the first
one) so as not to be replicated due to high fanout (or any other
reason). Such replication is almost never a problem if you have a
single, second flop before fanning out into the rest of your logic
(although in rare cases, the second flop gets replicated enough times
to where it creates enough fanout on the first register to trigger
replication!). Such replication is more common when the synchronizing
flop drives your logic directly. Either way, the no-replicate
constraint is highly recommended. You also don't want the synchronizing
flop to be re-timed either.

Andy


Mike Treseler wrote:

moogyd@yahoo.co.uk wrote:

When I pass a signal between clock domains (clkfrom to clkto), I use
two FF's in the clkto domain prior to using the signal in this domain.
If there is a timing violation (setup or hold) at the first FF, then
the O/P will become metastable. i.e. Unknown, and it will stay in this
state for a time determind by a probability distribution.

The most likely result of a timing violation in FF1 is proper
synchronization either on that edge or the next. The primary
job of the flop is to eliminate races to the subsequent flops
in the design by retiming the edges. The most common symptom of a logic
race is an "impossible" state transition.

The second flop is there to reduce the odds
of synchronization failure from say once a year to maybe
once every hundred years. That's cheap insurance.
Without any synchronization, I would expect a race problem
in much less than a year -- more likely in less than a millisecond.

For a synchronizer example, search for "retime"
in the reference design here:
http://home.comcast.net/~mike_treseler/

If I am passing a signal from a fast clock domain (16MHz) to a slow
clock domain (100Hz) at 0.18us, do I need to synchronize?

Yes.

The easiest way is to run the "slow" counter at 16MHz
using clock enables. See the "clock enabled counters"
source for an example. Or you could handshake the
transaction with ready and ack signals, properly
synchronized, of course.

e.g. As a simple example, I have a timer on a system bus. The cycle
time register is in the fast domain.

Is there a problem with this code?

Yes.

If you travel down this road you will
eventually reinvent the uart or the fifo.

-- Mike Treseler

 

[Davy]

Hi mjl296,

Thanks a lot!
And I am confused if there are two layers of enclosing loop, shall I
just jump out of the inner loop? Thanks!

Best regards,
Davy

mjl296@hotmail.com wrote:

continue will jump to the start of the next iteration of the enclosing
loop.

For your example, it stops the case statement being executed in any
clock cycle where reset is asserted.


Davy wrote:

Hi all,

There is a SystemVerilog/Verilog code.
What's "continue" in "if" block mean? If I delete "continue", will the
function same? Thanks!

//------------
forever begin
@(posedge clk);
if (reset) begin
... ...
do something;
continue;
end

case(state)
... ...
do something;
... ...
end
//--------------

Best regards,
Davy