Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   On HDL Synthesis (http://www.velocityreviews.com/forums/t517374-on-hdl-synthesis.html)

devices 06-25-2007 12:07 AM

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.



Mike Treseler 06-25-2007 01:20 AM

Re: On HDL Synthesis
 
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

Peter 06-25-2007 12:18 PM

Re: On HDL Synthesis
 
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 06-25-2007 02:45 PM

Re: On HDL Synthesis
 

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 06-25-2007 03:02 PM

Re: On HDL Synthesis
 

"Peter" <peter.hermansson@sts.saab.se> wrote in message
news:1182773923.721494.240320@q69g2000hsb.googlegr 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) ..."




Macias Wojtas 06-25-2007 05:13 PM

Re: On HDL Synthesis
 

"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.googlegr 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



devices 06-26-2007 10:47 AM

Re: On HDL Synthesis
 

"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.googlegr 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.



Macias Wojtas 06-27-2007 02:41 PM

Re: On HDL Synthesis
 
> 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 06-28-2007 10:04 AM

Re: On HDL Synthesis
 
> 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



Andy Peters 07-03-2007 01:14 AM

Re: On HDL Synthesis
 
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



All times are GMT. The time now is 12:15 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.