On HDL Synthesis

[devices]

I was trying to detect a start (or stop) condition (i2c).
A first approach consisted in "always @ (negedge isda)"
and setting a flag accordingly. The simulation woked.
When i wanted to check whether the module were
synthesizable the troubles began. No error, actually.
But the warnings were serious. The Timing Analysis
started to blame it on Ripple Clocks, Gated Clocks
and mostly on Clock skews. I fixed things by deploying
the common "always @ (posedge clk)" and detecting
the edges. I would like to know what happens behind
the scenes when a synthesis tool comes across a case
like the first "always" i listed.

 

[Mike Treseler]

devices wrote:

I was trying to detect a start (or stop) condition (i2c).
A first approach consisted in "always @ (negedge isda)"

That's verilog.
You probably want a synchronous always block.
Try comp.lang.verilog
See also pg 6-55
http://www.altera.com/literature/hb/qts/qts_qii51007.pdf

 

[Peter]

On 25 Juni, 02:07, "devices" <me@home> wrote:

I was trying to detect a start (or stop) condition (i2c).
A first approach consisted in "always @ (negedge isda)"
and setting a flag accordingly. The simulation woked.
When i wanted to check whether the module were
synthesizable the troubles began. No error, actually.
But the warnings were serious. The Timing Analysis
started to blame it on Ripple Clocks, Gated Clocks
and mostly on Clock skews. I fixed things by deploying
the common "always @ (posedge clk)" and detecting
the edges. I would like to know what happens behind
the scenes when a synthesis tool comes across a case
like the first "always" i listed.

Use a common clock and sample SDA and SCL (with synchronising
registers) as data, into a start/stop detector, instead of using SDA
as a clock.

/Peter

 

[devices]

Thanks for the link. I collected lots of info about coding style.
The one you show was not in my list.

That's verilog.
Try comp.lang.verilog

My issue was independent of the language that's why i
simply referred to it as HDL. I guess that that kind of
clock skew issue might arise whathever language you
use. I saw examples where the rising or falling edge of
SDA or a registered version of it drove a VDHL process.
I was just wondering what was inferred in such a case.

You probably want a synchronous always block.
Using "posedge clk" i've already made it synchronous.

 

[devices]

"Peter" <peter.hermansson@sts.saab.se> wrote in message
news:1182773923.721494.240320@q69g2000hsb.googlegroups.com...

On 25 Juni, 02:07, "devices" <me@home> wrote:
I was trying to detect a start (or stop) condition (i2c).
A first approach consisted in "always @ (negedge isda)"
and setting a flag accordingly. The simulation woked.
When i wanted to check whether the module were
synthesizable the troubles began. No error, actually.
But the warnings were serious. The Timing Analysis
started to blame it on Ripple Clocks, Gated Clocks
and mostly on Clock skews. I fixed things by deploying
the common "always @ (posedge clk)" and detecting
the edges. I would like to know what happens behind
the scenes when a synthesis tool comes across a case
like the first "always" i listed.

Use a common clock and sample SDA and SCL (with synchronising
registers) as data, into a start/stop detector, instead of using SDA
as a clock.

That's what i did when i used the "posedge clk".
It behaves more or less like: "process(clk)" plus
"if (clk='1' and clk'event) ..." or "if rising_edge(clk) ..."

 

[Macias Wojtas]

"devices" <me@home> wrote in message
news:467fd623$0$10620$4fafbaef@reader2.news.tin.it...

"Peter" <peter.hermansson@sts.saab.se> wrote in message
news:1182773923.721494.240320@q69g2000hsb.googlegroups.com...
On 25 Juni, 02:07, "devices" <me@home> wrote:
I was trying to detect a start (or stop) condition (i2c).
A first approach consisted in "always @ (negedge isda)"
and setting a flag accordingly. The simulation woked.
When i wanted to check whether the module were
synthesizable the troubles began. No error, actually.
But the warnings were serious. The Timing Analysis
started to blame it on Ripple Clocks, Gated Clocks
and mostly on Clock skews. I fixed things by deploying
the common "always @ (posedge clk)" and detecting
the edges. I would like to know what happens behind
the scenes when a synthesis tool comes across a case
like the first "always" i listed.

Use a common clock and sample SDA and SCL (with synchronising
registers) as data, into a start/stop detector, instead of using SDA
as a clock.

That's what i did when i used the "posedge clk".
It behaves more or less like: "process(clk)" plus
"if (clk='1' and clk'event) ..." or "if rising_edge(clk) ..."

Yes, but 'posedge clk' in Verilog and "process(clk)" plus "if (clk='1' and
clk'event) ..." or "if rising_edge(clk) ..." in VHDL should be apply only to
clock signals. It is not the way u can detect the change of signal level. As
Peter said u should sample this signal.

--
Maciek Wojtynski

 

[devices]

"Macias Wojtas" <wojtyns@poczta.onet.pl> wrote in message
news:f5ot8n$as$1@news.onet.pl...

"devices" <me@home> wrote in message
news:467fd623$0$10620$4fafbaef@reader2.news.tin.it...

"Peter" <peter.hermansson@sts.saab.se> wrote in message
news:1182773923.721494.240320@q69g2000hsb.googlegroups.com...
On 25 Juni, 02:07, "devices" <me@home> wrote:
I was trying to detect a start (or stop) condition (i2c).
A first approach consisted in "always @ (negedge isda)"
and setting a flag accordingly. The simulation woked.
When i wanted to check whether the module were
synthesizable the troubles began. No error, actually.
But the warnings were serious. The Timing Analysis
started to blame it on Ripple Clocks, Gated Clocks
and mostly on Clock skews. I fixed things by deploying
the common "always @ (posedge clk)" and detecting
the edges. I would like to know what happens behind
the scenes when a synthesis tool comes across a case
like the first "always" i listed.

Use a common clock and sample SDA and SCL (with synchronising
registers) as data, into a start/stop detector, instead of using SDA
as a clock.

That's what i did when i used the "posedge clk".
It behaves more or less like: "process(clk)" plus
"if (clk='1' and clk'event) ..." or "if rising_edge(clk) ..."

Yes, but 'posedge clk' in Verilog and "process(clk)" plus "if (clk='1' and
clk'event) ..." or "if rising_edge(clk) ..." in VHDL should be apply only
to
clock signals. It is not the way u can detect the change of signal level.
As
Peter said u should sample this signal.

--
Maciek Wojtynski

When did i say that CLK is the same as ISDA?

I stated two cases:

1) always @ (negedge isda)
which gave warnings

2) always @ (posedge clk)
which, as i said, fixed the issue.

in the second case i did the detection by
comparing the new and old sample.

 

[Macias Wojtas]

When did i say that CLK is the same as ISDA?

I stated two cases:

1) always @ (negedge isda)
which gave warnings

2) always @ (posedge clk)
which, as i said, fixed the issue.

in the second case i did the detection by
comparing the new and old sample.

U didn't said that isda was a the same as clk. I said that u can apply
'always @ (negedge xxx)' only to clock signal. Usually in FPGAs there is
only one dedicated clock line that's why when u try to use more then one
clock synthesis gives u warnings.

When in the same project u use always @ (posedge signal1) and always @
(posedge signal2) this require 2 clock lines - maybe this is your problem.



Best regards

Maciek Wojtynski

 

[devices]

U didn't said that isda was a the same as clk. I said that u can apply
'always @ (negedge xxx)' only to clock signal. Usually in FPGAs there is
only one dedicated clock line that's why when u try to use more then one
clock synthesis gives u warnings.

When in the same project u use always @ (posedge signal1) and always @
(posedge signal2) this require 2 clock lines - maybe this is your problem.



Best regards

Maciek Wojtynski

With both clk and isda as clocking signals, the timing
analyzer computed the shortest and longest path, the
shortest and longest delay and, as a warning, concluded
that the circuit may not operate.

Here's an explanation (though it has nothing to do with
the edge detection)

http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/03639c3b868fb8d6/6e1f8e28a059f3d3

 

[Andy Peters]

On Jun 27, 7:41 am, "Macias Wojtas" <wojt...@poczta.onet.pl> wrote:

U didn't said that isda was a the same as clk. I said that u can apply
'always @ (negedge xxx)' only to clock signal. Usually in FPGAs there is
only one dedicated clock line that's why when u try to use more then one
clock synthesis gives u warnings.

What's this "u" thing??

Your information about "only one dedicated clock line" in FPGAs is
waaaaay out of date.

-a

 

[Andy Peters]

On Jun 28, 3:04 am, "devices" <me@home> wrote:

U didn't said that isda was a the same as clk. I said that u can apply
'always @ (negedge xxx)' only to clock signal. Usually in FPGAs there is
only one dedicated clock line that's why when u try to use more then one
clock synthesis gives u warnings.

When in the same project u use always @ (posedge signal1) and always @
(posedge signal2) this require 2 clock lines - maybe this is your problem.

Best regards

Maciek Wojtynski

With both clk and isda as clocking signals, the timing
analyzer computed the shortest and longest path, the
shortest and longest delay and, as a warning, concluded
that the circuit may not operate.

Why two clocks?

-a

 

[devices]

"Andy Peters" <google@latke.net> wrote in message
news:1183425326.019803.58080@d30g2000prg.googlegroups.com...

With both clk and isda as clocking signals, the timing
analyzer computed the shortest and longest path, the
shortest and longest delay and, as a warning, concluded
that the circuit may not operate.

Why two clocks?

-a

ISDA is used locally to drive a flip flop clock. I
needed to detect its edges. Well, a flip flop clock
input would do that. The falling and rising edges of
SDA, in i2c, trigger the start and end conditions while
SCL holds high. So once the always block is triggered,
to detected the condition is just a matter of checking
SCL. I didn't invent anything. I had an application note
where the edges of SDA and mostly SCL were used
like that. I don't remember the AppNote case, but in
my case ISDA is internally generated (that's why
I-SDA) by my humble i2c master. I'm using the
Quartus II timing analyzer and i guess the ISDA's way
of driving the flip flop is what Altera calls a Registered
Clock and the analyzer might complain with warnings.

I'm not really interested in the ISDA thing now (as
i said i ended up in using a synchronous edge detector),
but i find that with Quartus' timing analyzer this kind of
issues arises frequently, even with clock dividers. Altera
explains why:

http://www.altera.com/literature/wp/wp_timingAnalysis.pdf

The key concept of the document is that the analyzer
does its best to check every possible issue in timing.
I guess that some of the warnings might be ignored or
you could instruct the analyzer on what you are doing
by setting up the analysis with detailed contraints. I'll
have to find out a way (or a way out to set a threshold
above or under which i can shrug my shoulder.

--

 

[devices]

"devices" <me@home> wrote in message
news:468a5de0$0$36441$4fafbaef@reader5.news.tin.it...

I'm not really interested in the ISDA thing now (as
i said i ended up in using a synchronous edge detector),
but i find that with Quartus' timing analyzer this kind of
issues arises frequently, even with clock dividers. Altera
explains why:

http://www.altera.com/literature/wp/wp_timingAnalysis.pdf

The key concept of the document is that the analyzer
does its best to check every possible issue in timing.
I guess that some of the warnings might be ignored or
you could instruct the analyzer on what you are doing
by setting up the analysis with detailed contraints. I'll
have to find out a way (or a way out to set a threshold
above or under which i can shrug my shoulder.

I've finally managed to make the Analyzer smile.
As i said, either you ignore the warnings or you declare
all the clocks and their operating points in the setup.

I decided to provide the details to Analizer's setup.

1) system clk
2) pll clk (i don't need it right now. Just a test)
3) baud rate generator (baud*16)

That's ok.

In this case if i had ignored the warnings it would have
been the same, but i wanted to gain some knowledge.

NOTES

1) I had already specified the details for the system clk.

2) The pll clk doesn't drive anything at the moment (no
warning anyway).

3) The baud rate generator used to give me warnings.
Working like a clock divider it was detected as a Ripple
Clock. The Analizer detected it as a clock but had no info
about it, so according to its own calculation it reported some
hold time violation. Now that i provided its parameters i get
no more warnings.