Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 154000

Article: 154000
Subject: Re: accumulator (again)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 10 Jul 2012 01:23:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
>> I suppose that is true, but really it shouldn't be a problem.
>> It is usual for many systems to clock as fast as you can,
>> consistent with the critical path delay. As metastability
>> is exponential, even a slightly shorter delay is usually enough
>> to make enough difference in the exponent.

>> That assumes that there is a FF to FF path that is faster than
>> the FF logic FF path. I believe that is usual for FPGAs, but
>> if you manage to get a critical path with only one LUT, then
>> I am not so sure. But that is pretty hard in most real systems.

(snip)
> You keep talking about the critical path delay as if the metastable
> input is driving the critical path.  There is only one critical path
> in a design normally.  All other paths are faster.  Are you assuming
> that all paths have the same amount of delay?

No, but it might be that many have about the same delay. Well, 
my favorite things to design are systolic arrays, where there is
the same logic (though with different routing, different delay)
between a large number of FFs. 

For any pipelined processor, the most efficient logic has about
the same delay between successive registers. 

> Regardless, all I am saying is that you don't need to use a path that
> has no logic to obtain *enough* slack to give enough settling time to
> the metastable input.  But in all cases you need to verify this.  

Yes. One would hope that no logic would have the shortest delay,
though in the case of FPGAs, you might not be able to count on that.

> As mentioned in another post, Peter Alfke's numbers show that you only
> need about 2 ns to get 100 million years MTBF.  Of course whether this
> is good enough depends on just how reliable your systems have to be
> and how many there are.  It is 100 million years for one unit, but for
> 10 million units it will only be 10 years MTBF for the group.

I have done designs with at most two LUTs between registers,
and might even be able to do one. 

-- glen

Article: 154001
Subject: Re: accumulator (again)
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 09 Jul 2012 20:47:47 -0500
Links: << >>  << T >>  << A >>
On Mon, 09 Jul 2012 17:20:26 -0700, rickman wrote:

> On Jul 9, 2:35 pm, Tim Wescott <t...@seemywebsite.com> wrote:
>> On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote:
>> > On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
>> > Murray) wrote:
>> >> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>,
>> >>  Tim Wescott <t...@seemywebsite.please> writes:
>>
>> >> >Paranoid logic designers will have a string of two or three
>> >> >registers to avoid metastability, but I've been told that's not
>> >> >necessary.  (I'm not much of a logic designer).
>>
>> >> Ahh, but are they paranoid enough?
>>
>> >> The key is settling time.
>>
>> >> In the old days of TTL chips, a pair of FFs (with no logic in
>> >> between) got you settling time of as much logic as the worst case
>> >> delay for the rest of the system.  In practice, that was enough.
>>
>> >> With FPGAs, routhing is important.  A pair of FFs close together is
>> >> probably good enough.  If you put them on opposite sides of a big
>> >> chip, the routing delays may match the long path of the logic delays
>> >> and eat up all of your slack time.
>>
>> >> Have any FPGA vendors published recent metastability info? (Many
>> >> thanks to Peter Alfke for all his good work in this area.)
>>
>> >> I'm not a silicon wizard.  Is it reasonable to simulate this stuff?
>> >> I'd like to know worst case rather than typicals.  It should be
>> >> possible to do something like verify simulations with lab typicals
>> >> and then use simulations to find the numbers for the nasty corners.
>>
>> > I'm not sure what you would want to simulate.  Metastability is
>> > probabilistic.  There is For a given length of settling time there is
>> > some probability of it happening.  Increasing the settling time
>> > reduces the probability but it will never be zero meaning there is no
>> > max length of time it takes for the output of a metastable ff to
>> > settle.
>>
>> The drivers of metastability are probabilistic, yes.  But given enough
>> information you could certainly simulate the positive feedback loop
>> that is a flip-flop.
>>
>> I suspect that unless the ball that is the flip-flop state is poised
>> right on the top of the mountain between the Valley of Zero and the
>> Valley of One, that the problem is mostly deterministic.  It's only
>> when the after-strobe balance is perfect and the gain is so low that
>> the FF voltage is affected more by noise than by actual circuit forces
>> that the problem would remain probabilistic _after_ the strobe
>> happened.
>>
>> "Enough information", in this case, would involve a whole lot of deep
>> knowledge of the inner workings of the FPGA, and the simulation would
>> be an analog circuits problem.  So I suspect that you couldn't do it
>> for any specific part unless you worked at the company in question.
>>
>> --
>> My liberal friends think I'm a conservative kook. My conservative
>> friends think I'm a liberal kook. Why am I not happy that they have
>> found common ground?
>>
>> Tim Wescott, Communications, Control, Circuits &
>> Softwarehttp://www.wescottdesign.com
> 
> That's what probability is all about, dealing with the lack of
> knowledge.  You don't know the exact voltage of the input when the clock
> edge changed and you don't know how fast either signal was changing...
> etc.  But you do know how often you expect all of these events to line
> up to produce metastability and you know the distribution of delay is a
> logarithmic taper.
> 
> I won't try to argue about how many angels can dance on the head of a
> pin, but I have no information to show me that the formula that Peter
> used is not accurate, even for extreme cases.

Well, first, I wasn't trying to contradict you -- I just picked the wrong 
place in the thread to answer Hal's question.

And second, before you can know the necessary inputs to your statistical 
calculations, you need to do some simulating to see how long it takes for 
the state to come down from various places on the mountaintop.

The difference between a circuit that has a narrow & sharp potential peak 
vs. one that has a wide, flat, broad one is significant.

(One that had a true stable spot at 1/2 voltage would be mucho worse, but 
that's not too likely in this day and age).

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 154002
Subject: Re: accumulator (again)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 10 Jul 2012 04:12:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:

(snip, someone wrote)
>> That's what probability is all about, dealing with the lack of
>> knowledge.  You don't know the exact voltage of the input when the clock
>> edge changed and you don't know how fast either signal was changing...
>> etc.  But you do know how often you expect all of these events to line
>> up to produce metastability and you know the distribution of delay is a
>> logarithmic taper.
 

(snip)
> Well, first, I wasn't trying to contradict you -- I just picked the wrong 
> place in the thread to answer Hal's question.

> And second, before you can know the necessary inputs to your statistical 
> calculations, you need to do some simulating to see how long it takes for 
> the state to come down from various places on the mountaintop.

> The difference between a circuit that has a narrow & sharp potential peak 
> vs. one that has a wide, flat, broad one is significant.

Story I heard some years ago, the sharper and narrower the peak,
the harder it is to get into the metastable state, but the 
longer it stays when it actually gets there.

-- glen

Article: 154003
Subject: Re: accumulator (again)
From: Tim Wescott <tim@seemywebsite.please>
Date: Tue, 10 Jul 2012 10:34:26 -0500
Links: << >>  << T >>  << A >>
On Tue, 10 Jul 2012 04:12:21 +0000, glen herrmannsfeldt wrote:

> Tim Wescott <tim@seemywebsite.com> wrote:
> 
> (snip, someone wrote)
>>> That's what probability is all about, dealing with the lack of
>>> knowledge.  You don't know the exact voltage of the input when the
>>> clock edge changed and you don't know how fast either signal was
>>> changing... etc.  But you do know how often you expect all of these
>>> events to line up to produce metastability and you know the
>>> distribution of delay is a logarithmic taper.
>  
>  
> (snip)
>> Well, first, I wasn't trying to contradict you -- I just picked the
>> wrong place in the thread to answer Hal's question.
> 
>> And second, before you can know the necessary inputs to your
>> statistical calculations, you need to do some simulating to see how
>> long it takes for the state to come down from various places on the
>> mountaintop.
> 
>> The difference between a circuit that has a narrow & sharp potential
>> peak vs. one that has a wide, flat, broad one is significant.
> 
> Story I heard some years ago, the sharper and narrower the peak,
> the harder it is to get into the metastable state, but the longer it
> stays when it actually gets there.

Wow.  That's counter-intuitive.  I would think that the sharper the peak 
the less likely that the device would be stuck without knowing which way 
to fall.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Article: 154004
Subject: Possibility to use MGTREFCLK1P/MGTREFCLK1N as clock for user logic in
From: wzab01@gmail.com
Date: Tue, 10 Jul 2012 11:13:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

Due to broken design of the FPGA board, I have the master clock available only at  MGTREFCLK1P/MGTREFCLK1N pins.
Is it possible to use those pins to produce clock for use logic in FPGA instead of GTP transceiver?

If I try to connect those pins to the differential input buffer, I get the following errors:

Mapping design into LUTs...
Running directed packing...
ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a
   single IOB component because the site type selected is not compatible. 

   Further explanation:
   The component type is determined by the types of logic and the properties and
   configuration of the logic it contains. In this case an IO component of type
   IOB was chosen because the IO contains symbols and/or properties consistent
   with input, output, or bi-directional usage and contains no other symbols or
   properties that require a more specific IO component type. Please double
   check that the types of logic elements and all of their relevant properties
   and configuration options are compatible with the physical site type of the
   constraint.

   Summary:
   Symbols involved:
   	PAD symbol "gtc_n5" (Pad Signal = gtc_n5)
   	SlaveBuffer symbol "ib1/SLAVEBUF.DIFFIN" (Output Signal =
   ib1/SLAVEBUF.DIFFIN)
   Component type involved: IOB
   Site Location involved: AK19
   Site Type involved: IPAD

ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a
   single IOB component because the site type selected is not compatible. 

   Further explanation:
   The component type is determined by the types of logic and the properties and
   configuration of the logic it contains. In this case an IO component of type
   IOB was chosen because the IO contains symbols and/or properties consistent
   with input, output, or bi-directional usage and contains no other symbols or
   properties that require a more specific IO component type. Please double
   check that the types of logic elements and all of their relevant properties
   and configuration options are compatible with the physical site type of the
   constraint.

   Summary:
   Symbols involved:
   	PAD symbol "gtc_p5" (Pad Signal = gtc_p5)
   	DIFFAMP symbol "ib1/IBUFDS" (Output Signal = io_clk)
   Component type involved: IOB
   Site Location involved: AJ19
   Site Type involved: IPAD

Is there any component (BUFIO2, or something similar) able to produce normal clock from those pins?
-- 
TIA & Regards,
WZab

Article: 154005
Subject: Re: accumulator (again)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 10 Jul 2012 19:16:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.please> wrote:

(snip, I wrote)
>> Story I heard some years ago, the sharper and narrower the peak,
>> the harder it is to get into the metastable state, but the longer it
>> stays when it actually gets there.

> Wow.  That's counter-intuitive.  I would think that the sharper the peak 
> the less likely that the device would be stuck without knowing which way 
> to fall.

First, remember that it is conditional on actually getting it
to the metastable state.

I don't know if it is convincing or not, but consider balancing
a knife on its edge on a table. You have a sharp and dull knife.
Once you get the sharp knife balanced, it will make a deeper
impression into the table and so stay up longer.

For the actual physics, there are some symmetries that require
some correlations in the probability of getting into, and getting
out of, a certain state. If you get it wrong, then energy 
conservation fails.

There is an old favorite, of putting a dark and light colored
object in a mirrored room. (Consider an ellipoidal mirror
with two spheres at the foci.) Now, consider the effect of
black body radiation with a black and a white sphere. 
The black sphere absorbs most radiation (mostly IR light)
but the white one doesn't absorb as much. Conservation of
energy requires that the black one emit more black body
radiation (that is where the name comes from). If not,
the black one would get warmer, and you could extract
energy from the temperature difference.

Note that this is why heat sinks are (usually) black.
(To get a connection to DSP.)

Warm objects have more electrons in higher (metastable) states.

-- glen

Article: 154006
Subject: XAUI on V5 FX200T
From: explore <chethanzmail@gmail.com>
Date: Tue, 10 Jul 2012 12:45:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am trying to implement a 10G MAC/XAUI design on a Virtex 5 FX200T
FPGA. I have tested the same design on a V5 LX100T FPGA successfully
and have now generated appropriate MAC/XAUI cores for the the FX200T
FPGA. The issue I am seeing now is that data is being sent out of the
MAC into the XAUI block, but the XAUI core does not seem to be sending
data over a CX4 cable connected to another identical board.

- Using XAUI v10.1, ISE 14.1
- Hitech Global  HTG-V5-PCIE-200-2 development board with a CX4
adapter
- Using GTX tiles 116 and 120
- Fowarding reference clock from GTX 124 (powered down) to GTX 116 and
120
- Able to confirm the following on chipscope: align_status = '1',
sync_status = "1111", mgt_tx_ready  = '1', mgt_rxlock = '1', and all
clocks in the design are active

I have used iBERT to check the transcievers and see no bit errors in
near-end PCS and PMA loopback modes. However, when the loopback mode
is set to none on one card and set to far-end PMA/PCS on another card,
there are continuous bit-errors. The link remains high throughout. I
am not sure if there are any settings in the transceiver that I need
to modify.

Appreciate any help.

Thanks!

Article: 154007
Subject: Re: accumulator (again)
From: Jon Elson <jmelson@wustl.edu>
Date: Tue, 10 Jul 2012 15:43:06 -0500
Links: << >>  << T >>  << A >>
rickman wrote:


> Regardless, all I am saying is that you don't need to use a path that
> has no logic to obtain *enough* slack to give enough settling time to
> the metastable input.

Well, one thing that I learned on this group is that metastability
is not the most likely problem, it is time skew.  If an unsynchronized
input is fed to a number of LUTs scattered around the chip, it can have
several ns of skew between them.  The clocks have tightly controlled
skew, so the unsynched input can be sensed differently at two locations.
I ran into this on a state machine and it caused the state logic to go
to undefined states.  This was finally explained, I think by one of the
guys at Xilinx, and that it can have a thousand times higher probability
than true metastability of a single FF.

Jon


Article: 154008
Subject: Re: Possibility to use MGTREFCLK1P/MGTREFCLK1N as clock for user logic in
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 10 Jul 2012 20:56:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <af2d18b0-beec-47ac-afd9-49c024034fdd@googlegroups.com>,
 <wzab01@gmail.com> wrote:
>Hi,
>
>Due to broken design of the FPGA board, I have the master clock available only at  MGTREFCLK1P/MGTREFCLK1N pins.
>Is it possible to use those pins to produce clock for use logic in FPGA instead of GTP transceiver?
>
>If I try to connect those pins to the differential input buffer, I get the following errors:
>
<snip error log>

>
>Is there any component (BUFIO2, or something similar) able to produce normal clock from those pins?

I think the clock must still go through the GTPA1_DUAL.  Then use the output pin "GTPCLKOUT[0|1]", connect
that to a BUFIO2, then connect the output of the BUFIO2 to a BUFG.

I know we've done similar with a virtex6 GTX, and we put the above hooks in place
for the Spartan6 versions of our boards.  I just don't know if we tested it.

It's a good place to start.  In any case I'm fairly sure you have to go through the 
GTP in some form - you can't just tap the clocks directly.

In any event, pour over the clocking section of the GTP user's guide.  It should give you what 
you need.

Regards,

Mark



Article: 154009
Subject: Re: accumulator (again)
From: rickman <gnuarm@gmail.com>
Date: Tue, 10 Jul 2012 16:22:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 9, 9:47=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Mon, 09 Jul 2012 17:20:26 -0700, rickman wrote:
> > On Jul 9, 2:35=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> >> On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote:
> >> > On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
> >> > Murray) wrote:
> >> >> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>,
> >> >> =A0Tim Wescott <t...@seemywebsite.please> writes:
>
> >> >> >Paranoid logic designers will have a string of two or three
> >> >> >registers to avoid metastability, but I've been told that's not
> >> >> >necessary. =A0(I'm not much of a logic designer).
>
> >> >> Ahh, but are they paranoid enough?
>
> >> >> The key is settling time.
>
> >> >> In the old days of TTL chips, a pair of FFs (with no logic in
> >> >> between) got you settling time of as much logic as the worst case
> >> >> delay for the rest of the system. =A0In practice, that was enough.
>
> >> >> With FPGAs, routhing is important. =A0A pair of FFs close together =
is
> >> >> probably good enough. =A0If you put them on opposite sides of a big
> >> >> chip, the routing delays may match the long path of the logic delay=
s
> >> >> and eat up all of your slack time.
>
> >> >> Have any FPGA vendors published recent metastability info? (Many
> >> >> thanks to Peter Alfke for all his good work in this area.)
>
> >> >> I'm not a silicon wizard. =A0Is it reasonable to simulate this stuf=
f?
> >> >> I'd like to know worst case rather than typicals. =A0It should be
> >> >> possible to do something like verify simulations with lab typicals
> >> >> and then use simulations to find the numbers for the nasty corners.
>
> >> > I'm not sure what you would want to simulate. =A0Metastability is
> >> > probabilistic. =A0There is For a given length of settling time there=
 is
> >> > some probability of it happening. =A0Increasing the settling time
> >> > reduces the probability but it will never be zero meaning there is n=
o
> >> > max length of time it takes for the output of a metastable ff to
> >> > settle.
>
> >> The drivers of metastability are probabilistic, yes. =A0But given enou=
gh
> >> information you could certainly simulate the positive feedback loop
> >> that is a flip-flop.
>
> >> I suspect that unless the ball that is the flip-flop state is poised
> >> right on the top of the mountain between the Valley of Zero and the
> >> Valley of One, that the problem is mostly deterministic. =A0It's only
> >> when the after-strobe balance is perfect and the gain is so low that
> >> the FF voltage is affected more by noise than by actual circuit forces
> >> that the problem would remain probabilistic _after_ the strobe
> >> happened.
>
> >> "Enough information", in this case, would involve a whole lot of deep
> >> knowledge of the inner workings of the FPGA, and the simulation would
> >> be an analog circuits problem. =A0So I suspect that you couldn't do it
> >> for any specific part unless you worked at the company in question.
>
> >> --
> >> My liberal friends think I'm a conservative kook. My conservative
> >> friends think I'm a liberal kook. Why am I not happy that they have
> >> found common ground?
>
> >> Tim Wescott, Communications, Control, Circuits &
> >> Softwarehttp://www.wescottdesign.com
>
> > That's what probability is all about, dealing with the lack of
> > knowledge. =A0You don't know the exact voltage of the input when the cl=
ock
> > edge changed and you don't know how fast either signal was changing...
> > etc. =A0But you do know how often you expect all of these events to lin=
e
> > up to produce metastability and you know the distribution of delay is a
> > logarithmic taper.
>
> > I won't try to argue about how many angels can dance on the head of a
> > pin, but I have no information to show me that the formula that Peter
> > used is not accurate, even for extreme cases.
>
> Well, first, I wasn't trying to contradict you -- I just picked the wrong
> place in the thread to answer Hal's question.
>
> And second, before you can know the necessary inputs to your statistical
> calculations, you need to do some simulating to see how long it takes for
> the state to come down from various places on the mountaintop.
>
> The difference between a circuit that has a narrow & sharp potential peak
> vs. one that has a wide, flat, broad one is significant.
>
> (One that had a true stable spot at 1/2 voltage would be mucho worse, but
> that's not too likely in this day and age).
>
> --
> My liberal friends think I'm a conservative kook.
> My conservative friends think I'm a liberal kook.
> Why am I not happy that they have found common ground?
>
> Tim Wescott, Communications, Control, Circuits & Softwarehttp://www.wesco=
ttdesign.com

Sorry if my tone sounded like I was offended at all, I'm not.  I was
just trying to make the point that you don't know the shape of the
"mountain" the ball is balanced on and I doubt a simulation could
model it very well.  But that is outside my expertise so if I am
wrong...

But I still fail to see how that shape would affect anything
significantly.  Unless it has flat spots or even indentations that
were local minima, what would the shape change?  It would most likely
only change the speed at which the ball falls off the "mountain" which
is part of what is measured when they characterize a device the way
Peter Alfke did.

Still, even if there is some abnormalities in the shape of the
"mountain", is that really important?  The goal is to get the
possibility so far out you just don't have to think about it.  If the
shape changes the probability by a factor of 10 either way it
shouldn't make a problem.  Just add another 200 ps to the slack and
get another order of magnitude in the MTBF.  Or was it 100 ps?

Rick

Article: 154010
Subject: Re: accumulator (again)
From: rickman <gnuarm@gmail.com>
Date: Tue, 10 Jul 2012 16:29:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 9, 9:23=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip, I wrote)
>
> >> I suppose that is true, but really it shouldn't be a problem.
> >> It is usual for many systems to clock as fast as you can,
> >> consistent with the critical path delay. As metastability
> >> is exponential, even a slightly shorter delay is usually enough
> >> to make enough difference in the exponent.
> >> That assumes that there is a FF to FF path that is faster than
> >> the FF logic FF path. I believe that is usual for FPGAs, but
> >> if you manage to get a critical path with only one LUT, then
> >> I am not so sure. But that is pretty hard in most real systems.
>
> (snip)
>
> > You keep talking about the critical path delay as if the metastable
> > input is driving the critical path. =A0There is only one critical path
> > in a design normally. =A0All other paths are faster. =A0Are you assumin=
g
> > that all paths have the same amount of delay?
>
> No, but it might be that many have about the same delay. Well,
> my favorite things to design are systolic arrays, where there is
> the same logic (though with different routing, different delay)
> between a large number of FFs.
>
> For any pipelined processor, the most efficient logic has about
> the same delay between successive registers.

We are still not talking about the same thing.  The *max* delay in
each stage will be roughly even, but within a stage there will be all
sorts of delays.  If you are balancing all paths to achieve even
delays you are working on a very intense design akin to the original
Cray computers with hand designed ECL chip logic.


> > Regardless, all I am saying is that you don't need to use a path that
> > has no logic to obtain *enough* slack to give enough settling time to
> > the metastable input. =A0But in all cases you need to verify this.
>
> Yes. One would hope that no logic would have the shortest delay,
> though in the case of FPGAs, you might not be able to count on that.

Yes, that is the point, you need to verify the required slack time no
mater what is in the path.


> > As mentioned in another post, Peter Alfke's numbers show that you only
> > need about 2 ns to get 100 million years MTBF. =A0Of course whether thi=
s
> > is good enough depends on just how reliable your systems have to be
> > and how many there are. =A0It is 100 million years for one unit, but fo=
r
> > 10 million units it will only be 10 years MTBF for the group.
>
> I have done designs with at most two LUTs between registers,
> and might even be able to do one.

That would be good, but I don't know if it is very practical.  To make
that useful you also have to optimize the placement to minimize
routing delays.  I haven't seen that done since some of Ray Andraka's
designs which are actually fairly small by today's standards.  I can't
conceive of trying that with many current designs.

Rick

Article: 154011
Subject: Completely puzzled: Strange shift register behaviour
From: o pere o <me@somewhere.net>
Date: Wed, 11 Jul 2012 13:23:51 +0200
Links: << >>  << T >>  << A >>
Hi,

I am not an FPGA expert although this is not my first design. The 
problem that I am having for two days now, is that I am observing 
different results when simulating a design in GHDL and in Modelsim 
ALTERA starter edition.

The design includes a shift register. The significant code is:

   read_sro : process(s_sample)
   begin
     if rising_edge(s_sample) then
       if ... --irrelevant here
       end if;
       if ...		
       end if;	
       if sr_burst_ena = '1' then  --First phase: store data in shift_reg
           new_data <= sr_sro_wave & new_data(c_burst_no-1 downto 1);
        elsif dec_shift_ena = '1' then --Second phase: rotate data

           new_data <= new_data(0) & new_data(c_burst_no-1 downto 1);

           --irrelevant, but included for completeness
           max_cnt <= max_cnt + 1;
           if usum > max then
              max <= usum;
              max_pos <= max_cnt;
           end if;
        end if;
     end if;
   end process read_sro;

the clock signal s_sample is obtained from the main 50 MHz clock with 
the following process:

sr_signals : process(clk)
begin
    if rising_edge(clk) then
      if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then
           s_sample <= not s_sample;
      end if;
    ...
    end if;
end process sr_signals;

I have uploaded some screenshots here:

1- ghdl+gtkwave result http://tinypic.com/r/wklimq/6
2- simulink http://tinypic.com/r/2le743t/6

It may be seen that the input signal (top signal in the GHDL result and 
third from the top in SIMULINK) is zero during the first 5 s_sample 
clocks, then is at one during 10 clocks and zero again for the rest of 
the (up to 20) clocks.

The GHDL simulation shows up ok, with the register correctly loaded with 
0000011111111110000 after the 20 clocks, however Altera's quartus gives 
00000111110000011111.

Exactly the same file is being fed to to Quartus II for synthesis!! But 
Alteras RTL (and gate level) simulations do not behave as intended.

Is there something with the coding style than can make Quartus infer an 
absolutely different behaviour? Any help is very much appreciated!!

Pere


Article: 154012
Subject: Re: Completely puzzled: Strange shift register behaviour
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 11 Jul 2012 05:02:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote:
> Hi,
>=20
> I am not an FPGA expert although this is not my first design. The=20
> problem that I am having for two days now, is that I am observing=20
> different results when simulating a design in GHDL and in Modelsim=20
> ALTERA starter edition.
>=20
> The design includes a shift register. The significant code is:
>=20
>    read_sro : process(s_sample)
>    begin
>      if rising_edge(s_sample) then
>        if ... --irrelevant here
>        end if;
>        if ...	=09
>        end if;=09
>        if sr_burst_ena =3D &#39;1&#39; then  --First phase: store data in=
 shift_reg
>            new_data &lt;=3D sr_sro_wave &amp; new_data(c_burst_no-1 downt=
o 1);
>         elsif dec_shift_ena =3D &#39;1&#39; then --Second phase: rotate d=
ata
>=20
>            new_data &lt;=3D new_data(0) &amp; new_data(c_burst_no-1 downt=
o 1);
>=20
>            --irrelevant, but included for completeness
>            max_cnt &lt;=3D max_cnt + 1;
>            if usum &gt; max then
>               max &lt;=3D usum;
>               max_pos &lt;=3D max_cnt;
>            end if;
>         end if;
>      end if;
>    end process read_sro;
>=20
> the clock signal s_sample is obtained from the main 50 MHz clock with=20
> the following process:
>=20
> sr_signals : process(clk)
> begin
>     if rising_edge(clk) then
>       if sr_clear =3D &#39;1&#39; or sr_burst_ena =3D &#39;1&#39; or dec_=
shift_ena =3D&#39;1&#39; then
>            s_sample &lt;=3D not s_sample;
>       end if;
>     ...
>     end if;
> end process sr_signals;
>=20
> I have uploaded some screenshots here:
>=20
> 1- ghdl+gtkwave result http://tinypic.com/r/wklimq/6
> 2- simulink http://tinypic.com/r/2le743t/6
>=20
> It may be seen that the input signal (top signal in the GHDL result and=
=20
> third from the top in SIMULINK) is zero during the first 5 s_sample=20
> clocks, then is at one during 10 clocks and zero again for the rest of=20
> the (up to 20) clocks.
>=20
> The GHDL simulation shows up ok, with the register correctly loaded with=
=20
> 0000011111111110000 after the 20 clocks, however Altera&#39;s quartus giv=
es=20
> 00000111110000011111.
>=20
> Exactly the same file is being fed to to Quartus II for synthesis!! But=
=20
> Alteras RTL (and gate level) simulations do not behave as intended.
>=20
> Is there something with the coding style than can make Quartus infer an=
=20
> absolutely different behaviour? Any help is very much appreciated!!
>=20
> Pere

By generating an internal clock signal you're not following synchronous des=
ign practice.  In an FPGA design that spells trouble.  What you need to do =
to make it synchronous is:

- Change the 'sr_signals' process that currently generates 's_sample'.  Wha=
t you'll want is for 's_sample' to be a one clock cycle pulse at the approp=
riate time.  Modify your if statement to accomplish this.
- Modify the 'read_src' process to use the free running clock and 's_sample=
' like this

read_sro : process(clk)=20
begin=20
    if rising_edge(clk) then
       if (s_sample =3D '1') then
          -- Put all of the code you have that was previously within
          -- the "if rising_edge(s_sample) then" statement here
       end if;
    end if;
end process read_src;

The reason that generated clocks are bad news in an FPGA is that you have e=
ssentially zero control over signal skew.  A signal generated in one clock =
domain can, depending on the routing, make it over into the other clock dom=
ain even before the generated clock gets there, or perhaps after.  In your =
case, you really have no way to say what skew there is between 'clk' and 's=
_sample'.  The signals 'sr_burst_ena' and 'dec_shift_ena' are used in both =
of your processes and yet each can only be valid in one clock domain (your =
posted code does not show those signal assignments so it is not clear in wh=
ich domain they have been generated, but I suspect it is in 'clk').

Kevin Jennings
    

Article: 154013
Subject: Re: Completely puzzled: Strange shift register behaviour
From: o pere o <me@somewhere.net>
Date: Wed, 11 Jul 2012 18:48:49 +0200
Links: << >>  << T >>  << A >>
On 07/11/2012 02:02 PM, KJ wrote:
> On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote:
>> Hi,
>>
>> I am not an FPGA expert although this is not my first design. The
>> problem that I am having for two days now, is that I am observing
>> different results when simulating a design in GHDL and in Modelsim
>> ALTERA starter edition.
>>
>> The design includes a shift register. The significant code is:
>>
>>     read_sro : process(s_sample)
>>     begin
>>       if rising_edge(s_sample) then
>>         if ... --irrelevant here
>>         end if;
>>         if ...		
>>         end if;	
>>         if sr_burst_ena =&#39;1&#39; then  --First phase: store data in shift_reg
>>             new_data&lt;= sr_sro_wave&amp; new_data(c_burst_no-1 downto 1);
>>          elsif dec_shift_ena =&#39;1&#39; then --Second phase: rotate data
>>
>>             new_data&lt;= new_data(0)&amp; new_data(c_burst_no-1 downto 1);
>>
>>             --irrelevant, but included for completeness
>>             max_cnt&lt;= max_cnt + 1;
>>             if usum&gt; max then
>>                max&lt;= usum;
>>                max_pos&lt;= max_cnt;
>>             end if;
>>          end if;
>>       end if;
>>     end process read_sro;
>>
>> the clock signal s_sample is obtained from the main 50 MHz clock with
>> the following process:
>>
>> sr_signals : process(clk)
>> begin
>>      if rising_edge(clk) then
>>        if sr_clear =&#39;1&#39; or sr_burst_ena =&#39;1&#39; or dec_shift_ena =&#39;1&#39; then
>>             s_sample&lt;= not s_sample;
>>        end if;
>>      ...
>>      end if;
>> end process sr_signals;
>>
>> I have uploaded some screenshots here:
>>
>> 1- ghdl+gtkwave result http://tinypic.com/r/wklimq/6
>> 2- simulink http://tinypic.com/r/2le743t/6
>>
>> It may be seen that the input signal (top signal in the GHDL result and
>> third from the top in SIMULINK) is zero during the first 5 s_sample
>> clocks, then is at one during 10 clocks and zero again for the rest of
>> the (up to 20) clocks.
>>
>> The GHDL simulation shows up ok, with the register correctly loaded with
>> 0000011111111110000 after the 20 clocks, however Altera&#39;s quartus gives
>> 00000111110000011111.
>>
>> Exactly the same file is being fed to to Quartus II for synthesis!! But
>> Alteras RTL (and gate level) simulations do not behave as intended.
>>
>> Is there something with the coding style than can make Quartus infer an
>> absolutely different behaviour? Any help is very much appreciated!!
>>
>> Pere
>
> By generating an internal clock signal you're not following synchronous design practice.  In an FPGA design that spells trouble.  What you need to do to make it synchronous is:
>
> - Change the 'sr_signals' process that currently generates 's_sample'.  What you'll want is for 's_sample' to be a one clock cycle pulse at the appropriate time.  Modify your if statement to accomplish this.
> - Modify the 'read_src' process to use the free running clock and 's_sample' like this
>
> read_sro : process(clk)
> begin
>      if rising_edge(clk) then
>         if (s_sample = '1') then
>            -- Put all of the code you have that was previously within
>            -- the "if rising_edge(s_sample) then" statement here
>         end if;
>      end if;
> end process read_src;
>
> The reason that generated clocks are bad news in an FPGA is that you have essentially zero control over signal skew.  A signal generated in one clock domain can, depending on the routing, make it over into the other clock domain even before the generated clock gets there, or perhaps after.  In your case, you really have no way to say what skew there is between 'clk' and 's_sample'.  The signals 'sr_burst_ena' and 'dec_shift_ena' are used in both of your processes and yet each can only be valid in one clock domain (your posted code does not show those signal assignments so it is not clear in which domain they have been generated, but I suspect it is in 'clk').
>
> Kevin Jennings
>
Kevin

Thanks for your input!

I know that this does not result in a synchronous design, and I was 
already thinking of rewriting it with clock enables, as you suggested.

However, this was done because, in this case, there is no signal 
generated in the "clk" domain that is read by "s_sample". Actually 
"s_sample" is only used to read some signals from the outside world and 
the shift register more or less tries to correlate what is read in the 
present cycle with the previous ones.

Is it correct to say that, in this case, "it doesn't matter"?

Now, completely agreeing with your observation, I am still puzzled by 
the fact that the even the RTL simulation (which I assume does not take 
any delays into account) is not working properly. If you have a look at 
the simulation results, this is absolutely not a shift register!

It seems that Altera's synthesis tool infers something quite 
different... but why??

Pere

Article: 154014
Subject: Re: Completely puzzled: Strange shift register behaviour
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 11 Jul 2012 18:53:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
o pere o <me@somewhere.net> wrote:

> I am not an FPGA expert although this is not my first design. The 
> problem that I am having for two days now, is that I am observing 
> different results when simulating a design in GHDL and in Modelsim 
> ALTERA starter edition.

(snip)

> the clock signal s_sample is obtained from the main 50 MHz 
> clock with the following process:

> sr_signals : process(clk)
> begin
>    if rising_edge(clk) then
>      if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then
>           s_sample <= not s_sample;
>      end if;
>    ...
>    end if;
> end process sr_signals;

You don't show where dec_shift_ena comes from.

(snip)

> The GHDL simulation shows up ok, with the register correctly loaded with 
> 0000011111111110000 after the 20 clocks, however Altera's quartus gives 
> 00000111110000011111.

> Exactly the same file is being fed to to Quartus II for synthesis!! But 
> Alteras RTL (and gate level) simulations do not behave as intended.

> Is there something with the coding style than can make Quartus infer an 
> absolutely different behaviour? Any help is very much appreciated!!

There are designs where the HDL code can simulate differently from
the usual synthesis. In that case, one could expect differences
from different simulators.

Unless you are doing post-route simulation, there are no delays
in use, but some signals are known to come after others.

The output of a FF will change after, never at the same time, as
the input.

You can't make any assumption, though, on the outputs of two FFs
with the same clock input. In simulation, one may be considered
before or after the other. In actual logic, with actual wire
delays, the result can be a race condition, where the result
is uncertain.

I didn't see in the logic where that happened, but maybe in
the part that wasn't shown. Especially dec_shift_ena.

-- glen


Article: 154015
Subject: Re: Completely puzzled: Strange shift register behaviour
From: rickman <gnuarm@gmail.com>
Date: Wed, 11 Jul 2012 13:13:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 11, 12:48 pm, o pere o <m...@somewhere.net> wrote:
> On 07/11/2012 02:02 PM, KJ wrote:
>
>
>
>
>
>
>
> > On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote:
> >> Hi,
>
> >> I am not an FPGA expert although this is not my first design. The
> >> problem that I am having for two days now, is that I am observing
> >> different results when simulating a design in GHDL and in Modelsim
> >> ALTERA starter edition.
>
> >> The design includes a shift register. The significant code is:
>
> >>     read_sro : process(s_sample)
> >>     begin
> >>       if rising_edge(s_sample) then
> >>         if ... --irrelevant here
> >>         end if;
> >>         if ...
> >>         end if;
> >>         if sr_burst_ena =3D&#39;1&#39; then  --First phase: store data=
 in shift_reg
> >>             new_data&lt;=3D sr_sro_wave&amp; new_data(c_burst_no-1 dow=
nto 1);
> >>          elsif dec_shift_ena =3D&#39;1&#39; then --Second phase: rotat=
e data
>
> >>             new_data&lt;=3D new_data(0)&amp; new_data(c_burst_no-1 dow=
nto 1);
>
> >>             --irrelevant, but included for completeness
> >>             max_cnt&lt;=3D max_cnt + 1;
> >>             if usum&gt; max then
> >>                max&lt;=3D usum;
> >>                max_pos&lt;=3D max_cnt;
> >>             end if;
> >>          end if;
> >>       end if;
> >>     end process read_sro;
>
> >> the clock signal s_sample is obtained from the main 50 MHz clock with
> >> the following process:
>
> >> sr_signals : process(clk)
> >> begin
> >>      if rising_edge(clk) then
> >>        if sr_clear =3D&#39;1&#39; or sr_burst_ena =3D&#39;1&#39; or de=
c_shift_ena =3D&#39;1&#39; then
> >>             s_sample&lt;=3D not s_sample;
> >>        end if;
> >>      ...
> >>      end if;
> >> end process sr_signals;
>
> >> I have uploaded some screenshots here:
>
> >> 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6
> >> 2- simulinkhttp://tinypic.com/r/2le743t/6
>
> >> It may be seen that the input signal (top signal in the GHDL result an=
d
> >> third from the top in SIMULINK) is zero during the first 5 s_sample
> >> clocks, then is at one during 10 clocks and zero again for the rest of
> >> the (up to 20) clocks.
>
> >> The GHDL simulation shows up ok, with the register correctly loaded wi=
th
> >> 0000011111111110000 after the 20 clocks, however Altera&#39;s quartus =
gives
> >> 00000111110000011111.
>
> >> Exactly the same file is being fed to to Quartus II for synthesis!! Bu=
t
> >> Alteras RTL (and gate level) simulations do not behave as intended.
>
> >> Is there something with the coding style than can make Quartus infer a=
n
> >> absolutely different behaviour? Any help is very much appreciated!!
>
> >> Pere
>
> > By generating an internal clock signal you're not following synchronous=
 design practice.  In an FPGA design that spells trouble.  What you need to=
 do to make it synchronous is:
>
> > - Change the 'sr_signals' process that currently generates 's_sample'. =
 What you'll want is for 's_sample' to be a one clock cycle pulse at the ap=
propriate time.  Modify your if statement to accomplish this.
> > - Modify the 'read_src' process to use the free running clock and 's_sa=
mple' like this
>
> > read_sro : process(clk)
> > begin
> >      if rising_edge(clk) then
> >         if (s_sample =3D '1') then
> >            -- Put all of the code you have that was previously within
> >            -- the "if rising_edge(s_sample) then" statement here
> >         end if;
> >      end if;
> > end process read_src;
>
> > The reason that generated clocks are bad news in an FPGA is that you ha=
ve essentially zero control over signal skew.  A signal generated in one cl=
ock domain can, depending on the routing, make it over into the other clock=
 domain even before the generated clock gets there, or perhaps after.  In y=
our case, you really have no way to say what skew there is between 'clk' an=
d 's_sample'.  The signals 'sr_burst_ena' and 'dec_shift_ena' are used in b=
oth of your processes and yet each can only be valid in one clock domain (y=
our posted code does not show those signal assignments so it is not clear i=
n which domain they have been generated, but I suspect it is in 'clk').
>
> > Kevin Jennings
>
> Kevin
>
> Thanks for your input!
>
> I know that this does not result in a synchronous design, and I was
> already thinking of rewriting it with clock enables, as you suggested.
>
> However, this was done because, in this case, there is no signal
> generated in the "clk" domain that is read by "s_sample". Actually
> "s_sample" is only used to read some signals from the outside world and
> the shift register more or less tries to correlate what is read in the
> present cycle with the previous ones.
>
> Is it correct to say that, in this case, "it doesn't matter"?
>
> Now, completely agreeing with your observation, I am still puzzled by
> the fact that the even the RTL simulation (which I assume does not take
> any delays into account) is not working properly. If you have a look at
> the simulation results, this is absolutely not a shift register!
>
> It seems that Altera's synthesis tool infers something quite
> different... but why??
>
> Pere

Your design is synchronous, but you have more than one clock, so you
need to be sure of the timing of signals that cross the clock
domains.  For example, the signals sr_clear, sr_burst_ena and
dec_shift_ena seem to be used in both the clk and the s_sample clock
domains without being synchonized.  I guess that might be ok if you
can make sure the delays in the s_sample clock don't result in one of
these signals changing on the edge of either clock.

If the simulation is not what you want, then there is likely something
wrong with the code.  But remember that while the simulation does not
account for logic delays, there are delta delays that mean signals
clocked by clk will have already changed by the time the remaining
code sees the change in s_sample.

Rick

Article: 154016
Subject: Re: Completely puzzled: Strange shift register behaviour
From: o pere o <me@somewhere.net>
Date: Thu, 12 Jul 2012 09:23:12 +0200
Links: << >>  << T >>  << A >>
On 07/11/2012 08:53 PM, glen herrmannsfeldt wrote:
> o pere o<me@somewhere.net>  wrote:
>
>> I am not an FPGA expert although this is not my first design. The
>> problem that I am having for two days now, is that I am observing
>> different results when simulating a design in GHDL and in Modelsim
>> ALTERA starter edition.
>
> (snip)
>
>> the clock signal s_sample is obtained from the main 50 MHz
>> clock with the following process:
>
>> sr_signals : process(clk)
>> begin
>>     if rising_edge(clk) then
>>       if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then
>>            s_sample<= not s_sample;
>>       end if;
>>     ...
>>     end if;
>> end process sr_signals;
>
> You don't show where dec_shift_ena comes from.

Sorry for the omission!

dec_shift_ena is generated as follows. First, I have a counter the is 
reset periodically:

clock_counter: process(clk) --counter counting over the symbol length
   begin
     if rising_edge(clk) then
        if tc_symbol = '1' then
           clk_count <= 0;
        else
           clk_count <= clk_count + 1;
        end if;
     end if;
   end process clock_counter;
   tc_symbol  <= '1' when clk_count=c_ticks_per_symbol-1 else '0';

 From this counter, I also generate some time markers, such as

   dec_shift_ena_pre <= '1' when (clk_count >= ...) and (...)
                        else '0';

which are resynchronized in

  process(clk)
   begin
      if rising_edge(clk) then
         ...
         dec_shift_ena <= dec_shift_ena_pre;
      end if;
   end process;



> (snip)
>
>> The GHDL simulation shows up ok, with the register correctly loaded with
>> 0000011111111110000 after the 20 clocks, however Altera's quartus gives
>> 00000111110000011111.
>
>> Exactly the same file is being fed to to Quartus II for synthesis!! But
>> Alteras RTL (and gate level) simulations do not behave as intended.
>
>> Is there something with the coding style than can make Quartus infer an
>> absolutely different behaviour? Any help is very much appreciated!!
>
> There are designs where the HDL code can simulate differently from
> the usual synthesis. In that case, one could expect differences
> from different simulators.
>
> Unless you are doing post-route simulation, there are no delays
> in use, but some signals are known to come after others.
>
> The output of a FF will change after, never at the same time, as
> the input.
>
> You can't make any assumption, though, on the outputs of two FFs
> with the same clock input. In simulation, one may be considered
> before or after the other. In actual logic, with actual wire
> delays, the result can be a race condition, where the result
> is uncertain.
>
> I didn't see in the logic where that happened, but maybe in
> the part that wasn't shown. Especially dec_shift_ena.
>
> -- glen
>

I get the same results with RTL and with post-route simulation (except 
for minor delays, as expected). I guess Altera's synthesis tool is doing 
something strange at exactly the half of the shif register new_data: The 
top half shifts correctly, but the bottom half looks as if it was 
inverted. I can't figure out how a timing issue could have this outcome, 
but I am probably missing something obvious -and hopefully someone can 
point this out :) !!

Pere

Article: 154017
Subject: Re: Completely puzzled: Strange shift register behaviour
From: o pere o <me@somewhere.net>
Date: Thu, 12 Jul 2012 09:35:07 +0200
Links: << >>  << T >>  << A >>
On 07/11/2012 10:13 PM, rickman wrote:
> On Jul 11, 12:48 pm, o pere o<m...@somewhere.net>  wrote:
>> On 07/11/2012 02:02 PM, KJ wrote:
>>
>>
>>
>>
>>
>>
>>
>>> On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote:
>>>> Hi,
>>
>>>> I am not an FPGA expert although this is not my first design. The
>>>> problem that I am having for two days now, is that I am observing
>>>> different results when simulating a design in GHDL and in Modelsim
>>>> ALTERA starter edition.
>>
>>>> The design includes a shift register. The significant code is:
>>
>>>>      read_sro : process(s_sample)
>>>>      begin
>>>>        if rising_edge(s_sample) then
>>>>          if ... --irrelevant here
>>>>          end if;
>>>>          if ...
>>>>          end if;
>>>>          if sr_burst_ena =&#39;1&#39; then  --First phase: store data in shift_reg
>>>>              new_data&lt;= sr_sro_wave&amp; new_data(c_burst_no-1 downto 1);
>>>>           elsif dec_shift_ena =&#39;1&#39; then --Second phase: rotate data
>>
>>>>              new_data&lt;= new_data(0)&amp; new_data(c_burst_no-1 downto 1);
>>
>>>>              --irrelevant, but included for completeness
>>>>              max_cnt&lt;= max_cnt + 1;
>>>>              if usum&gt; max then
>>>>                 max&lt;= usum;
>>>>                 max_pos&lt;= max_cnt;
>>>>              end if;
>>>>           end if;
>>>>        end if;
>>>>      end process read_sro;
>>
>>>> the clock signal s_sample is obtained from the main 50 MHz clock with
>>>> the following process:
>>
>>>> sr_signals : process(clk)
>>>> begin
>>>>       if rising_edge(clk) then
>>>>         if sr_clear =&#39;1&#39; or sr_burst_ena =&#39;1&#39; or dec_shift_ena =&#39;1&#39; then
>>>>              s_sample&lt;= not s_sample;
>>>>         end if;
>>>>       ...
>>>>       end if;
>>>> end process sr_signals;
>>
>>>> I have uploaded some screenshots here:
>>
>>>> 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6
>>>> 2- simulinkhttp://tinypic.com/r/2le743t/6
>>
>>>> It may be seen that the input signal (top signal in the GHDL result and
>>>> third from the top in SIMULINK) is zero during the first 5 s_sample
>>>> clocks, then is at one during 10 clocks and zero again for the rest of
>>>> the (up to 20) clocks.
>>
>>>> The GHDL simulation shows up ok, with the register correctly loaded with
>>>> 0000011111111110000 after the 20 clocks, however Altera&#39;s quartus gives
>>>> 00000111110000011111.
>>
>>>> Exactly the same file is being fed to to Quartus II for synthesis!! But
>>>> Alteras RTL (and gate level) simulations do not behave as intended.
>>
>>>> Is there something with the coding style than can make Quartus infer an
>>>> absolutely different behaviour? Any help is very much appreciated!!
>>
>>>> Pere
>>
>>> By generating an internal clock signal you're not following synchronous design practice.  In an FPGA design that spells trouble.  What you need to do to make it synchronous is:
>>
>>> - Change the 'sr_signals' process that currently generates 's_sample'.  What you'll want is for 's_sample' to be a one clock cycle pulse at the appropriate time.  Modify your if statement to accomplish this.
>>> - Modify the 'read_src' process to use the free running clock and 's_sample' like this
>>
>>> read_sro : process(clk)
>>> begin
>>>       if rising_edge(clk) then
>>>          if (s_sample = '1') then
>>>             -- Put all of the code you have that was previously within
>>>             -- the "if rising_edge(s_sample) then" statement here
>>>          end if;
>>>       end if;
>>> end process read_src;
>>
>>> The reason that generated clocks are bad news in an FPGA is that you have essentially zero control over signal skew.  A signal generated in one clock domain can, depending on the routing, make it over into the other clock domain even before the generated clock gets there, or perhaps after.  In your case, you really have no way to say what skew there is between 'clk' and 's_sample'.  The signals 'sr_burst_ena' and 'dec_shift_ena' are used in both of your processes and yet each can only be valid in one clock domain (your posted code does not show those signal assignments so it is not clear in which domain they have been generated, but I suspect it is in 'clk').
>>
>>> Kevin Jennings
>>
>> Kevin
>>
>> Thanks for your input!
>>
>> I know that this does not result in a synchronous design, and I was
>> already thinking of rewriting it with clock enables, as you suggested.
>>
>> However, this was done because, in this case, there is no signal
>> generated in the "clk" domain that is read by "s_sample". Actually
>> "s_sample" is only used to read some signals from the outside world and
>> the shift register more or less tries to correlate what is read in the
>> present cycle with the previous ones.
>>
>> Is it correct to say that, in this case, "it doesn't matter"?
>>
>> Now, completely agreeing with your observation, I am still puzzled by
>> the fact that the even the RTL simulation (which I assume does not take
>> any delays into account) is not working properly. If you have a look at
>> the simulation results, this is absolutely not a shift register!
>>
>> It seems that Altera's synthesis tool infers something quite
>> different... but why??
>>
>> Pere
>
> Your design is synchronous, but you have more than one clock, so you
> need to be sure of the timing of signals that cross the clock
> domains.  For example, the signals sr_clear, sr_burst_ena and
> dec_shift_ena seem to be used in both the clk and the s_sample clock
> domains without being synchonized.  I guess that might be ok if you
> can make sure the delays in the s_sample clock don't result in one of
> these signals changing on the edge of either clock.
>
> If the simulation is not what you want, then there is likely something
> wrong with the code.  But remember that while the simulation does not
> account for logic delays, there are delta delays that mean signals
> clocked by clk will have already changed by the time the remaining
> code sees the change in s_sample.
>
> Rick

Hi, Rick

the signals you are mentioning are being updated in the same 
process(clk) that creates s_sample. They are only read in the 
process(s_sample) as shown. However, there are no timing issues with 
this showing up in the post-route simulation (in hindsight, perhaps I 
was too lucky with this).

Otoh, the main point is that one simulation does what I want (and 
corresponds with the intended behaviour: the GHDL result) but the other 
one does not! GHDL simulates the semantics of VHDL, and Simulink 
simulates what Quartus' synthesis has inferred -which does not seem to 
be the same!

Pere

Pere

Article: 154018
Subject: Re: Completely puzzled: Strange shift register behaviour
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 12 Jul 2012 12:55:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
o pere o <me@somewhere.net> wrote:

(snip, I wrote)
>> You don't show where dec_shift_ena comes from.

> Sorry for the omission!

> dec_shift_ena is generated as follows. 
> First, I have a counter the is reset periodically:

> clock_counter: process(clk) --counter counting over the symbol length
>   begin
>     if rising_edge(clk) then
>        if tc_symbol = '1' then
>           clk_count <= 0;
>        else
>           clk_count <= clk_count + 1;
>        end if;
>     end if;
>   end process clock_counter;
>   tc_symbol  <= '1' when clk_count=c_ticks_per_symbol-1 else '0';

> From this counter, I also generate some time markers, such as

>   dec_shift_ena_pre <= '1' when (clk_count >= ...) and (...)
>                        else '0';

> which are resynchronized in

I read verilog much better, but this sounds suspicious.
Why does it need resynchronizing? 

>  process(clk)
>   begin
>      if rising_edge(clk) then
>         ...
>         dec_shift_ena <= dec_shift_ena_pre;
>      end if;
>   end process;

-- glen

Article: 154019
Subject: Re: Completely puzzled: Strange shift register behaviour
From: o pere o <me@somewhere.net>
Date: Thu, 12 Jul 2012 16:42:16 +0200
Links: << >>  << T >>  << A >>
On 07/12/2012 02:55 PM, glen herrmannsfeldt wrote:
> o pere o<me@somewhere.net>  wrote:
>
> (snip, I wrote)
>>> You don't show where dec_shift_ena comes from.
>
>> Sorry for the omission!
>
>> dec_shift_ena is generated as follows.
>> First, I have a counter the is reset periodically:
>
>> clock_counter: process(clk) --counter counting over the symbol length
>>    begin
>>      if rising_edge(clk) then
>>         if tc_symbol = '1' then
>>            clk_count<= 0;
>>         else
>>            clk_count<= clk_count + 1;
>>         end if;
>>      end if;
>>    end process clock_counter;
>>    tc_symbol<= '1' when clk_count=c_ticks_per_symbol-1 else '0';
>
>>  From this counter, I also generate some time markers, such as
>
>>    dec_shift_ena_pre<= '1' when (clk_count>= ...) and (...)
>>                         else '0';
>
>> which are resynchronized in
>
> I read verilog much better, but this sounds suspicious.
> Why does it need resynchronizing?

Being a combinational assignment, it is subject to glitches. The 
instants where they happen seemed to upset the post-route simulation, 
with complaints of hold time to short (iirc). BTW, the timing analyser 
did not complain at all. Making them a registered signal (and 
pre-compensating the one-cycle delay) cleared glitches and moved the 
transitions so that simulation goes ok.

Pere

>
>>   process(clk)
>>    begin
>>       if rising_edge(clk) then
>>          ...
>>          dec_shift_ena<= dec_shift_ena_pre;
>>       end if;
>>    end process;
>
> -- glen


Article: 154020
Subject: Re: Completely puzzled: Strange shift register behaviour
From: rickman <gnuarm@gmail.com>
Date: Thu, 12 Jul 2012 09:45:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 12, 3:35=A0am, o pere o <m...@somewhere.net> wrote:
> On 07/11/2012 10:13 PM, rickman wrote:
>
>
>
>
>
>
>
>
>
> > On Jul 11, 12:48 pm, o pere o<m...@somewhere.net> =A0wrote:
> >> On 07/11/2012 02:02 PM, KJ wrote:
>
> >>> On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote:
> >>>> Hi,
>
> >>>> I am not an FPGA expert although this is not my first design. The
> >>>> problem that I am having for two days now, is that I am observing
> >>>> different results when simulating a design in GHDL and in Modelsim
> >>>> ALTERA starter edition.
>
> >>>> The design includes a shift register. The significant code is:
>
> >>>> =A0 =A0 =A0read_sro : process(s_sample)
> >>>> =A0 =A0 =A0begin
> >>>> =A0 =A0 =A0 =A0if rising_edge(s_sample) then
> >>>> =A0 =A0 =A0 =A0 =A0if ... --irrelevant here
> >>>> =A0 =A0 =A0 =A0 =A0end if;
> >>>> =A0 =A0 =A0 =A0 =A0if ...
> >>>> =A0 =A0 =A0 =A0 =A0end if;
> >>>> =A0 =A0 =A0 =A0 =A0if sr_burst_ena =3D&#39;1&#39; then =A0--First ph=
ase: store data in shift_reg
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0new_data&lt;=3D sr_sro_wave&amp; new_data=
(c_burst_no-1 downto 1);
> >>>> =A0 =A0 =A0 =A0 =A0 elsif dec_shift_ena =3D&#39;1&#39; then --Second=
 phase: rotate data
>
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0new_data&lt;=3D new_data(0)&amp; new_data=
(c_burst_no-1 downto 1);
>
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0--irrelevant, but included for completene=
ss
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0max_cnt&lt;=3D max_cnt + 1;
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0if usum&gt; max then
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 max&lt;=3D usum;
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 max_pos&lt;=3D max_cnt;
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> >>>> =A0 =A0 =A0 =A0 =A0 end if;
> >>>> =A0 =A0 =A0 =A0end if;
> >>>> =A0 =A0 =A0end process read_sro;
>
> >>>> the clock signal s_sample is obtained from the main 50 MHz clock wit=
h
> >>>> the following process:
>
> >>>> sr_signals : process(clk)
> >>>> begin
> >>>> =A0 =A0 =A0 if rising_edge(clk) then
> >>>> =A0 =A0 =A0 =A0 if sr_clear =3D&#39;1&#39; or sr_burst_ena =3D&#39;1=
&#39; or dec_shift_ena =3D&#39;1&#39; then
> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0s_sample&lt;=3D not s_sample;
> >>>> =A0 =A0 =A0 =A0 end if;
> >>>> =A0 =A0 =A0 ...
> >>>> =A0 =A0 =A0 end if;
> >>>> end process sr_signals;
>
> >>>> I have uploaded some screenshots here:
>
> >>>> 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6
> >>>> 2- simulinkhttp://tinypic.com/r/2le743t/6
>
> >>>> It may be seen that the input signal (top signal in the GHDL result =
and
> >>>> third from the top in SIMULINK) is zero during the first 5 s_sample
> >>>> clocks, then is at one during 10 clocks and zero again for the rest =
of
> >>>> the (up to 20) clocks.
>
> >>>> The GHDL simulation shows up ok, with the register correctly loaded =
with
> >>>> 0000011111111110000 after the 20 clocks, however Altera&#39;s quartu=
s gives
> >>>> 00000111110000011111.
>
> >>>> Exactly the same file is being fed to to Quartus II for synthesis!! =
But
> >>>> Alteras RTL (and gate level) simulations do not behave as intended.
>
> >>>> Is there something with the coding style than can make Quartus infer=
 an
> >>>> absolutely different behaviour? Any help is very much appreciated!!
>
> >>>> Pere
>
> >>> By generating an internal clock signal you're not following synchrono=
us design practice. =A0In an FPGA design that spells trouble. =A0What you n=
eed to do to make it synchronous is:
>
> >>> - Change the 'sr_signals' process that currently generates 's_sample'=
. =A0What you'll want is for 's_sample' to be a one clock cycle pulse at th=
e appropriate time. =A0Modify your if statement to accomplish this.
> >>> - Modify the 'read_src' process to use the free running clock and 's_=
sample' like this
>
> >>> read_sro : process(clk)
> >>> begin
> >>> =A0 =A0 =A0 if rising_edge(clk) then
> >>> =A0 =A0 =A0 =A0 =A0if (s_sample =3D '1') then
> >>> =A0 =A0 =A0 =A0 =A0 =A0 -- Put all of the code you have that was prev=
iously within
> >>> =A0 =A0 =A0 =A0 =A0 =A0 -- the "if rising_edge(s_sample) then" statem=
ent here
> >>> =A0 =A0 =A0 =A0 =A0end if;
> >>> =A0 =A0 =A0 end if;
> >>> end process read_src;
>
> >>> The reason that generated clocks are bad news in an FPGA is that you =
have essentially zero control over signal skew. =A0A signal generated in on=
e clock domain can, depending on the routing, make it over into the other c=
lock domain even before the generated clock gets there, or perhaps after. =
=A0In your case, you really have no way to say what skew there is between '=
clk' and 's_sample'. =A0The signals 'sr_burst_ena' and 'dec_shift_ena' are =
used in both of your processes and yet each can only be valid in one clock =
domain (your posted code does not show those signal assignments so it is no=
t clear in which domain they have been generated, but I suspect it is in 'c=
lk').
>
> >>> Kevin Jennings
>
> >> Kevin
>
> >> Thanks for your input!
>
> >> I know that this does not result in a synchronous design, and I was
> >> already thinking of rewriting it with clock enables, as you suggested.
>
> >> However, this was done because, in this case, there is no signal
> >> generated in the "clk" domain that is read by "s_sample". Actually
> >> "s_sample" is only used to read some signals from the outside world an=
d
> >> the shift register more or less tries to correlate what is read in the
> >> present cycle with the previous ones.
>
> >> Is it correct to say that, in this case, "it doesn't matter"?
>
> >> Now, completely agreeing with your observation, I am still puzzled by
> >> the fact that the even the RTL simulation (which I assume does not tak=
e
> >> any delays into account) is not working properly. If you have a look a=
t
> >> the simulation results, this is absolutely not a shift register!
>
> >> It seems that Altera's synthesis tool infers something quite
> >> different... but why??
>
> >> Pere
>
> > Your design is synchronous, but you have more than one clock, so you
> > need to be sure of the timing of signals that cross the clock
> > domains. =A0For example, the signals sr_clear, sr_burst_ena and
> > dec_shift_ena seem to be used in both the clk and the s_sample clock
> > domains without being synchonized. =A0I guess that might be ok if you
> > can make sure the delays in the s_sample clock don't result in one of
> > these signals changing on the edge of either clock.
>
> > If the simulation is not what you want, then there is likely something
> > wrong with the code. =A0But remember that while the simulation does not
> > account for logic delays, there are delta delays that mean signals
> > clocked by clk will have already changed by the time the remaining
> > code sees the change in s_sample.
>
> > Rick
>
> Hi, Rick
>
> the signals you are mentioning are being updated in the same
> process(clk) that creates s_sample. They are only read in the
> process(s_sample) as shown. However, there are no timing issues with
> this showing up in the post-route simulation (in hindsight, perhaps I
> was too lucky with this).
>
> Otoh, the main point is that one simulation does what I want (and
> corresponds with the intended behaviour: the GHDL result) but the other
> one does not! GHDL simulates the semantics of VHDL, and Simulink
> simulates what Quartus' synthesis has inferred -which does not seem to
> be the same!
>
> Pere
>
> Pere

I don't know why you are expecting to see your problems or solutions
in any simulation.  A post route simulation uses typical timings and
can't be expected to be 100% realistic, even a chip can't be expected
to be the same as another chip.  That is why they use synchronous
concepts, meet the cycle timing and all other timing issues are
handled by the chip qualification and the design tools.

If the signal is generated in the clk domain and s_sample is generated
in the clk domain, you can't predict which delay will be longer and
you have a race condition between all the signals and the s_sample
clock.  One thing that would help is to generate the signals on one
edge of clk and generate s_sample on the other edge of clk.  Then you
know the timing on a course level and can constrain the timing of
paths from the clk to the s_sample clock domain... or just use an
enable instead of generating a new clock.

If you don't believe the timing is a problem, draw a timing diagram
showing *all* delays.  You will see the routing delay of s_sample can
be giving you trouble.

Rick

Article: 154021
Subject: Re: Completely puzzled: Strange shift register behaviour
From: rickman <gnuarm@gmail.com>
Date: Thu, 12 Jul 2012 09:51:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 12, 10:42=A0am, o pere o <m...@somewhere.net> wrote:
> On 07/12/2012 02:55 PM, glen herrmannsfeldt wrote:
>
>
> > o pere o<m...@somewhere.net> =A0wrote:
>
> > (snip, I wrote)
> >>> You don't show where dec_shift_ena comes from.
>
> >> Sorry for the omission!
>
> >> dec_shift_ena is generated as follows.
> >> First, I have a counter the is reset periodically:
>
> >> clock_counter: process(clk) --counter counting over the symbol length
> >> =A0 =A0begin
> >> =A0 =A0 =A0if rising_edge(clk) then
> >> =A0 =A0 =A0 =A0 if tc_symbol =3D '1' then
> >> =A0 =A0 =A0 =A0 =A0 =A0clk_count<=3D 0;
> >> =A0 =A0 =A0 =A0 else
> >> =A0 =A0 =A0 =A0 =A0 =A0clk_count<=3D clk_count + 1;
> >> =A0 =A0 =A0 =A0 end if;
> >> =A0 =A0 =A0end if;
> >> =A0 =A0end process clock_counter;
> >> =A0 =A0tc_symbol<=3D '1' when clk_count=3Dc_ticks_per_symbol-1 else '0=
';
>
> >> =A0From this counter, I also generate some time markers, such as
>
> >> =A0 =A0dec_shift_ena_pre<=3D '1' when (clk_count>=3D ...) and (...)
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else '0';
>
> >> which are resynchronized in
>
> > I read verilog much better, but this sounds suspicious.
> > Why does it need resynchronizing?
>
> Being a combinational assignment, it is subject to glitches. The
> instants where they happen seemed to upset the post-route simulation,
> with complaints of hold time to short (iirc). BTW, the timing analyser
> did not complain at all. Making them a registered signal (and
> pre-compensating the one-cycle delay) cleared glitches and moved the
> transitions so that simulation goes ok.
>
> Pere
>
>
> >> =A0 process(clk)
> >> =A0 =A0begin
> >> =A0 =A0 =A0 if rising_edge(clk) then
> >> =A0 =A0 =A0 =A0 =A0...
> >> =A0 =A0 =A0 =A0 =A0dec_shift_ena<=3D dec_shift_ena_pre;
> >> =A0 =A0 =A0 end if;
> >> =A0 =A0end process;
>
> > -- glen

There is a problem.  dec_shift_ena was transitioning in the setup/hold
time window of s_sample because the logic/routing delays of the two
paths were too close to equal.  The signal needs to be synced, but not
to the clk domain, to the s_sample domain!  Better to change the
timing altogether by generating s_sample on the opposite edge of
clk... or like I said above, use an enable rather than a new clock.

Rick

Article: 154022
Subject: Re: Completely puzzled: Strange shift register behaviour
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 12 Jul 2012 12:32:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, July 12, 2012 12:51:18 PM UTC-4, rickman wrote:
> 
> There is a problem.  dec_shift_ena was transitioning in the setup/hold
> time window of s_sample because the logic/routing delays of the two
> paths were too close to equal.  The signal needs to be synced, but not
> to the clk domain, to the s_sample domain!  Better to change the
> timing altogether by generating s_sample on the opposite edge of
> clk... or like I said above, use an enable rather than a new clock.
> 
> Rick

I pointed out exactly these points (use a clock enable and that he was using two signals in two different clock domains) in the very first reply to his post...maybe it will click this time.

KJ

Article: 154023
Subject: Re: Completely puzzled: Strange shift register behaviour
From: o pere o <me@somewhere.net>
Date: Fri, 13 Jul 2012 17:20:27 +0200
Links: << >>  << T >>  << A >>
On 07/11/2012 01:23 PM, o pere o wrote:
> Hi,
>
> I am not an FPGA expert although this is not my first design. The
> problem that I am having for two days now, is that I am observing
> different results when simulating a design in GHDL and in Modelsim
> ALTERA starter edition.
>
> The design includes a shift register. The significant code is:
>
> read_sro : process(s_sample)
> begin
> if rising_edge(s_sample) then
> if ... --irrelevant here
> end if;
> if ...
> end if;
> if sr_burst_ena = '1' then --First phase: store data in shift_reg
> new_data <= sr_sro_wave & new_data(c_burst_no-1 downto 1);
> elsif dec_shift_ena = '1' then --Second phase: rotate data
>
> new_data <= new_data(0) & new_data(c_burst_no-1 downto 1);
>
> --irrelevant, but included for completeness
> max_cnt <= max_cnt + 1;
> if usum > max then
> max <= usum;
> max_pos <= max_cnt;
> end if;
> end if;
> end if;
> end process read_sro;
>
> the clock signal s_sample is obtained from the main 50 MHz clock with
> the following process:
>
> sr_signals : process(clk)
> begin
> if rising_edge(clk) then
> if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then
> s_sample <= not s_sample;
> end if;
> ...
> end if;
> end process sr_signals;
>
> I have uploaded some screenshots here:
>
> 1- ghdl+gtkwave result http://tinypic.com/r/wklimq/6
> 2- simulink http://tinypic.com/r/2le743t/6
>
> It may be seen that the input signal (top signal in the GHDL result and
> third from the top in SIMULINK) is zero during the first 5 s_sample
> clocks, then is at one during 10 clocks and zero again for the rest of
> the (up to 20) clocks.
>
> The GHDL simulation shows up ok, with the register correctly loaded with
> 0000011111111110000 after the 20 clocks, however Altera's quartus gives
> 00000111110000011111.
>
> Exactly the same file is being fed to to Quartus II for synthesis!! But
> Alteras RTL (and gate level) simulations do not behave as intended.
>
> Is there something with the coding style than can make Quartus infer an
> absolutely different behaviour? Any help is very much appreciated!!
>
> Pere
>

Thanks to everybody for your inputs. Making the whole design work on 
only one clock (with suitable enables) solves the issue. This is really 
not a surprise.

However, I still have some questions on this. If I built my design from, 
lets say, discrete components, I might have problems with setup and hold 
times at the shift register (SR) input, but I would NEVER EVER get the 
results that showed up in the simulation:

The SR was initially cleared. The serial input to the SR is zero at the 
first clock but, surprisingly, a one appears at the 9th (!!) SR output 
after the first edge of the clock. Can anybody find a plausible 
explanation for this?

The second question is, is there a way to tell Quartus that it should 
synthesize something that resembles the physical circuit? I did tell 
Quartus that s_sample was a clock (and told the frequency), however this 
was obviously not sufficient. Any thoughts?

Pere



Article: 154024
Subject: Re: Completely puzzled: Strange shift register behaviour
From: rickman <gnuarm@gmail.com>
Date: Fri, 13 Jul 2012 08:37:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 13, 11:20=A0am, o pere o <m...@somewhere.net> wrote:
> On 07/11/2012 01:23 PM, o pere o wrote:
>
>
>
>
>
>
>
>
>
> > Hi,
>
> > I am not an FPGA expert although this is not my first design. The
> > problem that I am having for two days now, is that I am observing
> > different results when simulating a design in GHDL and in Modelsim
> > ALTERA starter edition.
>
> > The design includes a shift register. The significant code is:
>
> > read_sro : process(s_sample)
> > begin
> > if rising_edge(s_sample) then
> > if ... --irrelevant here
> > end if;
> > if ...
> > end if;
> > if sr_burst_ena =3D '1' then --First phase: store data in shift_reg
> > new_data <=3D sr_sro_wave & new_data(c_burst_no-1 downto 1);
> > elsif dec_shift_ena =3D '1' then --Second phase: rotate data
>
> > new_data <=3D new_data(0) & new_data(c_burst_no-1 downto 1);
>
> > --irrelevant, but included for completeness
> > max_cnt <=3D max_cnt + 1;
> > if usum > max then
> > max <=3D usum;
> > max_pos <=3D max_cnt;
> > end if;
> > end if;
> > end if;
> > end process read_sro;
>
> > the clock signal s_sample is obtained from the main 50 MHz clock with
> > the following process:
>
> > sr_signals : process(clk)
> > begin
> > if rising_edge(clk) then
> > if sr_clear =3D '1' or sr_burst_ena =3D '1' or dec_shift_ena =3D'1' the=
n
> > s_sample <=3D not s_sample;
> > end if;
> > ...
> > end if;
> > end process sr_signals;
>
> > I have uploaded some screenshots here:
>
> > 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6
> > 2- simulinkhttp://tinypic.com/r/2le743t/6
>
> > It may be seen that the input signal (top signal in the GHDL result and
> > third from the top in SIMULINK) is zero during the first 5 s_sample
> > clocks, then is at one during 10 clocks and zero again for the rest of
> > the (up to 20) clocks.
>
> > The GHDL simulation shows up ok, with the register correctly loaded wit=
h
> > 0000011111111110000 after the 20 clocks, however Altera's quartus gives
> > 00000111110000011111.
>
> > Exactly the same file is being fed to to Quartus II for synthesis!! But
> > Alteras RTL (and gate level) simulations do not behave as intended.
>
> > Is there something with the coding style than can make Quartus infer an
> > absolutely different behaviour? Any help is very much appreciated!!
>
> > Pere
>
> Thanks to everybody for your inputs. Making the whole design work on
> only one clock (with suitable enables) solves the issue. This is really
> not a surprise.
>
> However, I still have some questions on this. If I built my design from,
> lets say, discrete components, I might have problems with setup and hold
> times at the shift register (SR) input, but I would NEVER EVER get the
> results that showed up in the simulation:
>
> The SR was initially cleared. The serial input to the SR is zero at the
> first clock but, surprisingly, a one appears at the 9th (!!) SR output
> after the first edge of the clock. Can anybody find a plausible
> explanation for this?
>
> The second question is, is there a way to tell Quartus that it should
> synthesize something that resembles the physical circuit? I did tell
> Quartus that s_sample was a clock (and told the frequency), however this
> was obviously not sufficient. Any thoughts?
>
> Pere

I can't answer question one, but the answer is in the code and the
simulation.  If necessary you will need to step through the code that
assigns a value to the SR, but the answer will be there.  The real
point is that it doesn't matter really.  The simulation told you
something was wrong and you found the problem.  Is it important to
understand how the error was generated?

The second question is easy.  You don't tell the tool what the
"physical circuit" is really.  The tool tells you!  Telling Quartus
that your clock is a clock shouldn't be needed as it can figure that
out because the signal is clocking FFs.  There was no problem with the
tool.  The problem was exactly as KJ described in his first post, once
you create a clock from logic, you can't control the skew between the
two clocks and so lose control over setup and hold times.  The tool
also looses control over this as it depends on things the tool can't
control or even know about, the exact detailed timing of the chip.

In summary, generating clocks is bad ju-ju.  Don't cross the beams.

Rick



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search