Clock Edge notation

[Andy]

On Jun 25, 1:53 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

Getting software folk and digital designers
talking to each other would be a big step in
the right direction.  Sometimes that works well,
but certain project management styles (as in Rick's
story) go a long way towards preventing it.

Re-skilling, as often as you get the chance, is
a pretty good antidote to belief that you know
it all.  Career circumstances don't usually make
that easy to do, sadly.

Most of the time when I mention that FPGA/ASIC engineers could learn a
trick or three from their SW brethren, I get bombarded with "FPGA/ASIC
design is not SW!" True enough, but the discipline of code design, and
to a lesser extent testing, is very much the same between the two. The
requirements for the code are much different (usually), but the method
in which complex requirements must be analyzed, broken down, designed
into code and verified are incredibly similar. SW has developed over
the years many techniques for dealing with the complexity of all
things coded, and we HW engineers can learn an awful lot from them
about at least that.

I have worked with some SW engineers that fairly quickly grasped the
HW nature of HDL code, and some that didn't ever get it. I have also
worked with some HW engineers that grasped the SW nature of their
design, and some that didn't. Those that do understand the
similarities and the differences between the two, and exploit the
similarities while observing the limitations of the differences, are
the ones I want on my team.

There are often organizational turf battles that get in the way of
honest exchange of ideas and solutions between SW and HW. It seems to
be the mavericks from both camps that tend to understand the common
ground and then exploit it, to the benefit of both.

Andy

 

[Mike Treseler]

Andy wrote:

I have worked with some SW engineers that fairly quickly grasped the
HW nature of HDL code, and some that didn't ever get it. I have also
worked with some HW engineers that grasped the SW nature of their
design, and some that didn't. Those that do understand the
similarities and the differences between the two, and exploit the
similarities while observing the limitations of the differences, are
the ones I want on my team.

I agree. Thanks for the posting.

I would only add that it is curious that the same
software engineers that insist on careful version
control and unit testing for their own code,
are often content to accept a binary fpga image file
directly into their firmware without insisting
on having any of the supporting sources or build processes.

-- Mike Treseler

 

[Mike Treseler]

Fredxx wrote:

At the same time blind reliance of simulators is just as bad.

As is blind reliance on anything.

There is the old saying garbage in = garbage out.

An rtl sim is a pretty good garbage filter.
It is only sufficient with a well-tested set of design rules.

In the past I have also come across instances where simulation has taken so
long, and created such large files, that reality has been quicker with a few
debugging flags in the code!

I have worked on projects where a few debugging
flags in the code would never have found
all of the logical errors.

A good testbench doesn't produce large files.
It reports pass or fail.

-- Mike Treseler

 

[Serkan]

On 26 Haziran, 19:58, Mike Treseler <mtrese...@gmail.com> wrote:

Serkan wrote:
 It takes two much time to simulate using that method.
 Is not there any way to do it without the testbench writing the
values?

Is your intent to test the ram design?
Finding the init data does not prove
that the ram works.

      -- Mike Treseler

No I do not want to test the ram. I have a design to test which has a
dpram. So I need a dpram model to help testing my design.
I created a ram(in my case dpram_32k) using the Xilinx Core
Generator.
I have a mif file that has the initial values to be entered to the ram
at the time 0 of test.(I do not want to do it on the testbench by
myself for timing purposes. This is important)
I just want to make a functinal simulation using Modelsim with the ram
initialized using the mif file that I have before the test starts.

I am missing something in the steps that I cant be able to initialize
the ram with the numbers in the milf file.

serkan

 

[Fredxx]

"Mike Treseler" <mtreseler@gmail.com> wrote in message
news:7akg5eF1tmmprU1@mid.individual.net...

Fredxx wrote:

At the same time blind reliance of simulators is just as bad.

As is blind reliance on anything.

There is the old saying garbage in = garbage out.

An rtl sim is a pretty good garbage filter.
It is only sufficient with a well-tested set of design rules.

Hmm - perhaps you're interfacing with an external IC. Are you going to tell
me you'd blindly write a testbench without confirming that your interface in
real hardware is correctly understood?

It's clear you've never got a PCI or PCIe interface working without
resorting to the likes of chipscope, where reality doesn't even match
signals as per standards.

In the past I have also come across instances where simulation has taken
so
long, and created such large files, that reality has been quicker with a
few
debugging flags in the code!

I have worked on projects where a few debugging
flags in the code would never have found
all of the logical errors.

Couldn't agree more.

A good testbench doesn't produce large files.

I was thinking of waveform files, where perhaps the simulation has to first
wade though a million states to start providing data.

It reports pass or fail.

You're just not living in the real world of FPGA design which ought to be a
mix of simulation and reality. Anything else, and you are either assuming
your test bench doesn't have any flaws, or just fumbling in the dark.

 

[Mike Treseler]

Fredxx wrote:

Hmm - perhaps you're interfacing with an external IC. Are you going to tell
me you'd blindly write a testbench without confirming that your interface in
real hardware is correctly understood?

Standard interfaces are well documented.
Certainly I have to verify a few things on the bench,
but starting with a sim improves my odds.

It's clear you've never got a PCI or PCIe interface working without
resorting to the likes of chipscope, where reality doesn't even match
signals as per standards.

We purchased a PCIe core that came with a testbench.
I just worked.

-- Mike Treseler

 

[Mike Treseler]

Mike Treseler wrote:

We purchased a PCIe core that came with a testbench.
I just worked.

It

 

[Fredxx]

"Mike Treseler" <mtreseler@gmail.com> wrote in message
news:4A477373.8040406@gmail.com...

Fredxx wrote:

Hmm - perhaps you're interfacing with an external IC. Are you going to
tell me you'd blindly write a testbench without confirming that your
interface in real hardware is correctly understood?

Standard interfaces are well documented.
Certainly I have to verify a few things on the bench,
but starting with a sim improves my odds.

It sounds we're really singing from the same hymn sheet, the difference is
I'm more honest to say that simulation is sometimes no substitution for
reality.

It's clear you've never got a PCI or PCIe interface working without
resorting to the likes of chipscope, where reality doesn't even match
signals as per standards.

We purchased a PCIe core that came with a testbench.
I just worked.

Perhaps I'm missing something here, but I would hope the purchased core and
test bench would work straight out of the box?

 

[rickman]

On Jun 27, 9:13 pm, "Fredxx" <fre...@spam.com> wrote:

"Mike Treseler" <mtrese...@gmail.com> wrote in message

news:7akg5eF1tmmprU1@mid.individual.net...

Fredxx wrote:

At the same time blind reliance of simulators is just as bad.

As is blind reliance on anything.

There is the old saying garbage in = garbage out.

An rtl sim is a pretty good garbage filter.
It is only sufficient with a well-tested set of design rules.

Hmm - perhaps you're interfacing with an external IC.  Are you going to tell
me you'd blindly write a testbench without confirming that your interface in
real hardware is correctly understood?

It's clear you've never got a PCI or PCIe interface working without
resorting to the likes of chipscope, where reality doesn't even match
signals as per standards.



In the past I have also come across instances where simulation has taken
so
long, and created such large files, that reality has been quicker with a
few
debugging flags in the code!

I have worked on projects where a few debugging
flags in the code would never have found
all of the logical errors.

Couldn't agree more.



A good testbench doesn't produce large files.

I was thinking of waveform files, where perhaps the simulation has to first
wade though a million states to start providing data.

It reports pass or fail.

You're just not living in the real world of FPGA design which ought to be a
mix of simulation and reality.  Anything else, and you are either assuming
your test bench doesn't have any flaws, or just fumbling in the dark.

Nobody is saying you never have to test a design in the chip. I think
Mike is just saying that time spent on a good test bench is work many
more hours in the lab with an O-scope. I know that my designs
typically are much harder to debug on the bench than in simulation. I
seldom get my test benches honed to the point of giving me a pass/fail
indication, but I know that I am going to be running them many more
times than once and construct them accordingly. In fact, I typically
design a test bench for each module and unit test before I integrate.
If the module changes during integration, I rework the unit test bench
to keep up with the changes. This can add greatly to module reuse as
well as helping to keep the bulk of debugging at a lower level where
it is easier to find and repair bugs.

The software community has a lot of good ideas that *do* apply to
writing HDL code. We just need to consider these ideas and use them
appropriately.

Rick

 

[Mad I.D.]

On Jul 25, 6:11 pm, KJ <kkjenni...@sbcglobal.net> wrote:
/cut

Thank you very much for this excellent explanation !
And thank you Brian Drummond.


Greeting from Croatia (right now )

 

[Brian Drummond]

On Sun, 26 Jul 2009 05:42:47 -0700 (PDT), "Mad I.D." <madid87@gmail.com> wrote:

On Jul 25, 6:11 pm, KJ <kkjenni...@sbcglobal.net> wrote:
/cut

Thank you very much for this excellent explanation !

Which only leaves one question un-answered... how did the XST manual get one of
these two examples wrong? (or alternatively, why is the error still there, after
no doubt several revisions of the document?)

All comments on Xilinx quality control apart; the error may have escaped
correction (possibly even detection) simply because latches are not commonly
used in FPGAs. Registers are far more commonly used; their more predictable
timing model makes them more generally useful, and it is normally better design
practice to use them.

As a result you are highly unlikely to come across bugs in the handling of
registers in the documentation or tools; however bugs are more likely in less
well trodden paths, such as latches.

It would be useful to open a Webcase on support.xilinx.com (if you are allowed;
e.g. if you are not a student) to report this error. Pursue it with the Xilinx
support team until they accept that it really is an error, and ask them for the
CR# (number of the change request) to correct this piece of documentation. This
may take a little time; some of their support team are excellent, but others do
not immediately see a problem unless it is very clearly expressed. This gives
you useful experience in dealing with Xilinx support, and eventually saves other
Xilinx users from confusion.

- Brian

 

[Mike Treseler]

Tim Hubberstey wrote:

If you want to see VHDL, you pay a MUCH higher price for a
source code license and sign non-disclosure agreements that require your
firstborn as collateral.

In my case the price was x for an encrypted netlist
and 3x for VHDL source. No collateral.

Guenter: Consider making a .pdf document and
a vcom -nodebug binary for potential customers
to try in their own testbench. That wouldn't
cost anything but time.

-- Mike Treseler

 

[Jan Decaluwe]

Mike Treseler wrote:

Jan Decaluwe wrote:

The bad one is the following. A coding style using
for loops and variables is forbidden by many "gurus".
In fact, in Verilog, the language used for the most
advanced ASIC designs, you shouldn't use them. If you
take the Verilog "gurus" seriously, that is. Unfortunately,
many people do, especially managing types. So if you
just need to stay out of trouble, here's your solution.

My advice applies only to VHDL and FPGAs.
I know very little about ASICs and Verilog.

The good one is the following. General synthesis tools
don't necessarily perform well on specialized
optimizations. For-loops are great as a description tool,
but they may result in an inefficient "starting point"
structure for synthesis.

Try it and see. I found no substantial difference
using Easics vs leo or synplicity on parallel
16 and 32 bit FCS checkers for an FPGA target.

Try and see is definitely the good advice.
My experience dates back several years, with Synopsys -
other synthesis tools / versions may behave differently,
especially if they would contain xor-specific optimizations,
as they perfectly could.

Also, for the record: a "stand-alone" experiment with
only the CRC functions is not sufficient to judge well.
The functions can and will be used in a context -
I remember that the difference became especially significant
within larger modules and for large bit
widths (e.g. 32) and large poly's (e.g. Ethernet).

However - if there's no significant difference, then
there is definitely no reason to use a specialized solution.

Regards, Jan

--
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium
mailto:jan@jandecaluwe.com
http://jandecaluwe.com

 

[Troels Smit]

Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de> wrote in message news:<bd7htd$pbo31$3@ID-8609.news.dfncis.de>...

Hi Troels!


I have to change state on the event change of a signal - so I wrote
the following posted below.

when wait4lr =
if lr'event then
next_state <= wait20sclk_and4_cordic;
end if;

This give a bad synchronous description of my "next_state" signal.


if lr'event then

is (nearly) the same like

if (rising_edge(lr) OR falling_edge(lr)) then


This "dual-edge-flipflop" is not synthesizable.
Furthermore It's not recommended to put rising_edge / falling_edge in a
branch of a case-statement.

Well, you are right that this way of writing dual edge triggered code
does not work ... but it is possible.
I found that the following code indeed will synthesize, you will find
dual edge, and case sentenze mixed terribly, but it synthesizes and I
don't see the difference between what I posted yesterday and the test
code below:


case test3 is
when '1' =>
if (clk'event) then
if (clk='1') then
test <= '0';
else
test <= '1';
end if;
end if;
when others =>
null;
end case;


if (reset='1') then
test3 <= '0';
elsif (reset'event and reset='0') then
test3 <= '1';
end if;

 

[dbtid]

On 24 Jun 2003 02:40:21 -0700, Troels Smit <troels_smit@hotmail.com> wrote:

Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de> wrote in message
news:<bd7htd$pbo31$3@ID-8609.news.dfncis.de>...
Hi Troels!


I have to change state on the event change of a signal - so I wrote
the following posted below.
when wait4lr =
if lr'event then
next_state <= wait20sclk_and4_cordic;
end if;
This give a bad synchronous description of my "next_state" signal.


if lr'event then

is (nearly) the same like

if (rising_edge(lr) OR falling_edge(lr)) then


This "dual-edge-flipflop" is not synthesizable.
Furthermore It's not recommended to put rising_edge / falling_edge in a
branch of a case-statement.


Well, you are right that this way of writing dual edge triggered code
does not work ... but it is possible.
I found that the following code indeed will synthesize, you will find
dual edge, and case sentenze mixed terribly, but it synthesizes and I
don't see the difference between what I posted yesterday and the test
code below:


case test3 is
when '1' =
if (clk'event) then
if (clk='1') then
test <= '0';
else
test <= '1';
end if;
end if;
when others =
null;
end case;

this is more like

test <= not clk;

[snip]

 

[John Moore]

1. What do I initilaise the crc to?

It depends what you're doing, but normally all '1's.

Thank you.

2. I'm assembling the received ethernet bit stream into bytes, so that
the
first bit received becomes the LS Bit of a byte.

That's how it works.

Is the input to
nextCRC32_D8 this byte or its bit reversal?

You shift 'em as like they come off the line.

That doesn't answer the question. There is no shifting, as the input is byte

wide. I've now found that the correct answer is to reverse the byte as
defined above.

Thank you for the help Mike. I've now got it working!

John Moore

 

[Jos]

Jan Decaluwe wrote:

Mike Treseler wrote:

Jan Decaluwe wrote:

The bad one is the following. A coding style using
for loops and variables is forbidden by many "gurus".
In fact, in Verilog, the language used for the most
advanced ASIC designs, you shouldn't use them. If you
take the Verilog "gurus" seriously, that is. Unfortunately,
many people do, especially managing types. So if you
just need to stay out of trouble, here's your solution.

My advice applies only to VHDL and FPGAs.
I know very little about ASICs and Verilog.

The good one is the following. General synthesis tools
don't necessarily perform well on specialized
optimizations. For-loops are great as a description tool,
but they may result in an inefficient "starting point"
structure for synthesis.

Try it and see. I found no substantial difference
using Easics vs leo or synplicity on parallel
16 and 32 bit FCS checkers for an FPGA target.

Try and see is definitely the good advice.
My experience dates back several years, with Synopsys -
other synthesis tools / versions may behave differently,
especially if they would contain xor-specific optimizations,
as they perfectly could.

Also, for the record: a "stand-alone" experiment with
only the CRC functions is not sufficient to judge well.
The functions can and will be used in a context -

Absolutely right. Synthesis tools tend to converge to an optimal
solution when synthesized "stand-alone". When buried in a bunch of other
logic the synthesizer doesn't find the optimal solution.

My favourite in that respect is the recursive xor or adder tree versus
the loop generated xor or adder.
Same phenomenon , same result.

Regards,

Jos

I remember that the difference became especially significant
within larger modules and for large bit
widths (e.g. 32) and large poly's (e.g. Ethernet).

However - if there's no significant difference, then
there is definitely no reason to use a specialized solution.

Regards, Jan

--
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium
mailto:jan@jandecaluwe.com
http://jandecaluwe.com

 

[John Moore]

Sorry to be a bore, but I'm still having trouble getting the generator
working in an ethernet transmitter.

It works fine in a receiver if I preload the crc with (others <= '1'), and
feed in the input bytes in bit reversed form, and look for an answer of
x"c704dd7b" at the end of the frame.

Presumably I should also preload with (others <= '1') for a transmitter as
well? This doesn't give the right answer (which I know from other
applications) after loading the last byte of the frame. Should I be doing
anything else?

Thanks for any further help
John Moore

 

[Mario Trams]

Troels Smit wrote:

When in a state, why is it not ok to listen for an event of another
signal ??

Let me reverse your question: Assume you have a regular synchronous
state machine and you instantaneously want to change the state when
an event on some signal occured.
How would you create some piece of hardware using D-FlipFlops and
some logic gates that do the job?

Regards,
Mario

 

[A. Smalls]

Hi Troels,
Is there any reason that you can not use a Flop with and an enable
in the idle state to "latch" the value of the signal and then just
compare that to the incoming signal in the wait4lr state and
transition if the values are not the same?



troels_smit@hotmail.com (Troels Smit) wrote in message news:<316d5fc0.0306230849.ec9959f@posting.google.com>...

Hi all,

I have to change state on the event change of a signal - so I wrote
the following posted below.

when wait4lr =
if lr'event then
next_state <= wait20sclk_and4_cordic;
end if;

This give a bad synchronous description of my "next_state" signal. How
does one work around the problem that you need to switch state on the
changing of a signal ?


/Troels






The Code (for reference):

state_logic : process (lr, current_state, counter20f, cordic_rfd,
cordic_rdy)
begin -- process state_logic
case current_state is
when idle =
next_state <= wait4lr;
when wait4lr =
if lr'event then --ERRROR
next_state <= wait20sclk_and4_cordic;
end if;
when wait20sclk_and4_cordic =
if (counter20f = '1' and cordic_rfd = '1') then
next_state <= handshake_cordic;
end if;
when handshake_cordic =
if cordic_rdy = '1' then
next_state <= read_output;
end if;
when read_output =
next_state <= wait4lr;
end case;
end process state_logic;



state_change : process (clk, reset)
begin -- process state_change
if reset = '1' then -- asynchronous reset (active
high)
current_state <= idle;
elsif clk'event and clk = '1' then -- rising clock
edge
current_state <= next_state;
end if;
end process state_change;