On HDL Synthesis

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.

devices

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/...s_qii51007.pdf

Mike Treseler

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

Peter

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" <> wrote in message
news: oups.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) ..."

devices

"devices" <me@home> wrote in message
news:467fd623$0$10620$ ...
>
> "Peter" <> wrote in message
> news: oups.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

Macias Wojtas

"Macias Wojtas" <> wrote in message
news:f5ot8n$as$...
>
> "devices" <me@home> wrote in message
> news:467fd623$0$10620$ ...
> >
> > "Peter" <> wrote in message
> > news: oups.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.

devices

> 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

Macias Wojtas

> 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....1f8e28a059f3d3

devices

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