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 19700

Article: 19700
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:32:56 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net.  Additionally, you get horizontal backbones which connect the
12 vertical long lines in each column.  With heavy loading, these seem to get
pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19701
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:32:56 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net.  Additionally, you get horizontal backbones which connect the
12 vertical long lines in each column.  With heavy loading, these seem to get
pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19702
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:32:57 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net.  Additionally, you get horizontal backbones which connect the
12 vertical long lines in each column.  With heavy loading, these seem to get
pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19703
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:32:59 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net.  Additionally, you get horizontal backbones which connect the
12 vertical long lines in each column.  With heavy loading, these seem to get
pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19704
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:32:59 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net.  Additionally, you get horizontal backbones which connect the
12 vertical long lines in each column.  With heavy loading, these seem to get
pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19705
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:33:07 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net and can only drive clock pins in the design.  Additionally, you
get horizontal backbones which connect the 12 vertical long lines in each column.
With heavy loading, these seem to get pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19706
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:33:14 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net and can only drive clock pins in the design.  Additionally, you
get horizontal backbones which connect the 12 vertical long lines in each column.
With heavy loading, these seem to get pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19707
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:33:18 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net and can only drive clock pins in the design.  Additionally, you
get horizontal backbones which connect the 12 vertical long lines in each column.
With heavy loading, these seem to get pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19708
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:33:58 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net and can only drive clock pins in the design.  Additionally, you
get horizontal backbones which connect the 12 vertical long lines in each column.
With heavy loading, these seem to get pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19709
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:33:59 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net and can only drive clock pins in the design.  Additionally, you
get horizontal backbones which connect the 12 vertical long lines in each column.
With heavy loading, these seem to get pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>         x--x            x--x
>       --|  |--------c---|  |--
>   |>--a->  |     ---b--->  |
>     |   |  |     |      |  |
>     |   x--x     |      x--x
>     |            |
>     -------------
>
> this is a nasty problem involving minimum delays, and can only be
> fixed by custom creation of clock trees. if you now split 'a' and 'b'
> into different tracks, and introduce a 150ps uncertainty in their
> source timing, then you have a much more difficult problem. granted,
> it'll probably work, but i won't be doing it until i see it guaranteed
> in the datasheet.
>
> if you do use a DLL and split the two clocks, then you can arrange to
> clock the 2 F/Fs at different times, as peter suggested. this would be
> a good fix, apart from (1) any signals passing between the 2 domains
> now only have approximately half of the period of the high-frequency
> clock available to them, rather than the whole period, and (2) this is
> - i think - difficult to constrain.
>
> i agree that, in general, it often makes more sense to route multiple
> clocks than to use a CE. this is the way that large SOC designs are
> going, and it will become more relevant to us as FPGA die sizes
> increase. however, there's one critical argument that generally makes
> this a no-starter. the most important part of any FPGA or ASIC
> development is verification. xilinx's timing constraint mechanism is
> good (much better than others i've seen), but it's still next to
> impossible to constrain a design where a significant number of signals
> pass between clock domains. on the other hand, it's trivially easy to
> constrain a design which uses clock enables, which makes the choice a
> no-brainer. you can verify your multi-clock design with timing
> simulation, but there's always the possibility that you'll miss the
> path that makes your design fail.
>
> one more point: if your clock-enabled design fails due to a routing
> and fanout problem, then it's generally easy to fix, which certainly
> isn't true of a multi-clock design.
>
> evan

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19710
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:34:01 GMT
Links: << >>  << T >>  << A >>
Spartan is pretty much the same as the 4000E family - 8 BUFGs, 4 primary which can
connect to external clocks and 4 secondary which get sourced from internal nets.

In Virtex, you only get 4 BUFGs.  Those can be sourced by the clock pin, the DLL
or an internal net and can only drive clock pins in the design.  Additionally, you
get horizontal backbones which connect the 12 vertical long lines in each column.
With heavy loading, these seem to get pretty slow, and they are not low skew.

The outputs from the DLLs can be put directly onto the low skew global clock
networks.  The low skew between the 1x and 2x clocks is pretty much maintained by
the low skew networks, as the routing is virtually identical.  Xilinx tells me
that the maximum skew between two clocks sourced by the same DLL as measured at a
CLB clock input is less than the clock to Q, shortest connection to another
register and setup of the second register anywhere on the array.  I haven't seen
such a statement in the data book though, so you have good reason to be skeptical
(The only number I've seen is the maximum skew on one global net, nothing about
minimum numbers for clock to Q, routing and setup).

Working in their favor, they have virtually identical clock distribution networks,
sourced by the same DLL though the same number of pass gates in the same local
area of the die.  The shortest register to register routing delays will be for
registers that are close to one=another (different slices in one CLB is the
closest), and in those cases, the clock skew is going to be the smallest because
the clock path over the global network is the same for both clocks.  At greater
distances, the routing delays increase, so there is more room for clock skew
before it becomes a problem.



eml@riverside-machines.com.NOSPAM wrote:

> On Sat, 08 Jan 2000 00:00:50 GMT, Ray Andraka <randraka@ids.net>
> wrote:
>
> >The clock skew between the DLL 1x and 2x outputs is smaller than the clock to
> >Q and set up of the flip-flops, so you won't run into problems crossing the
> >clock domain boundary for two clocks generated by the _SAME_ DLL.  The only
> >disadvantage I see to using the DLL is the finite start up time required for
> >the DLL to stabilize.
>
> you're not taking into account routing delays. the fpga manufacturer
> guarantees (i hope) that this will work, where 'a' is a short segment,
> 'b' is a long maximally-loaded segment, and 'c' is minimally loaded:
>
>

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19711
Subject: Re: Optimizing VHDL for Altera
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 03:34:02 GMT
Links: << >>  << T >>  << A >>
Synplicity does a pretty good job with adders already.  The adders will get
implemented using the Altera carry chain, which is the way you want it to work.
Altera's array is not very strong for arithmetic applications, which is probably

the root of your not fitting.  When the carry chain is utilized, the altera LE's

are put in the "arithmetic" mode, which breaks each 4 input Look-Up Table
(4-LUT) into a pair of 3-LUTs, one for the carry to the next bit and one for the

sum function.  One input to each of those LUTs is the carry from the previous
bit, so any arithmetic function with more than two inputs is forced to two
levels of logic, and thus two LE's per bit.  If you use the register clock
enable, the clock enable input to the LE steals one of the LUT inputs too, so
for arithmetic, you are down to a 1 input arithmetic function if you want to
stay in one level of logic.  The bottom line here is if you are doing clock
enables, accumulators with load or synch clear, adder/subtractors or any other 3

or more input arithmetic you'll end up using 2 LE's per bit per function.
Xilinx FPGAs have a different carry chain structure that permits 2 bits of 3
input arithmetic per CLB for 4000 and spartan series, or 4 input arithmetic in
Virtex and Spartan II.

Also, in most DSP algorithms you wind  up with a need for sample delays (taps in

a filter, etc).  In Altera devices, the delays are implemented in the LE
registers, which means you use up an LE for each bit of each clock of delay.
Xilinx devices allow you to turn the 4-LUTs into 16x1 memories, which can be
used as 16 bit shift registers.  Synplicity will infer those shift registers
from your RTL code for Virtex, but not for 4000 series (4000 series requires a
counterfor the memory).

You might be able to revisit your algorithm to find a better way to do it.
Doing so will decrease the size of the design both in the Altera device and in
your ASIC.  As far as architectural optimizations, you will do better in Altera
if you design keeping in mind the structure of the LE's but where your target is

an ASIC, I don't think you'll get real far that way.  You can also use the EABs
as function look-ups if you are not already using them for something else.
Here, the Idea is to map stuff that takes up alot (several levels) of logic into

the EAB.  Of course, that won't map well to the ASIC either.

Can you run at a higher clock rate and time multiplex the multiple channels
through the same set of hardware?  Alternatively, at a 10 MHZ, you should be
able to some of the processing bit-serial, again at a higher system clock.



Berni Joss wrote:

> I am working on a VHDL design to be synthesized on an Altera 10k100 for
> debugging and on an ASIC standard cell library for production.
>
> The current code base does not fit into an Altera 10k100 (Synplicity claims
> 120% device usage).
> The tools used are Synplicity and Max PlusII for the FPGA and Synopsis for
> the ASIC.
> Speed is less than 10MHz.
> The code implements a multi channel DSP sensor interface and signal
> processing, involving among others many adders. There are also some 40 byte
> wide configuration registers accessed by an serial interface.
> All algorithms are RTL style using unsigned() bit vectors.
>
> I'm not very familiar with Altera's architecture.
>
> Can you suggest any "tricks" ?
> Are there good an bad ways (for Altera's architecture) to describe e.g. a 12
> bit adder?
> Or do you have any hints on where I can find useful information for trying
> to reduce the resource usage in Altera FPGA but keeping in mind that the
> same code must also be compiled efficiently by Synopsis on a standard cell
> library.
>
> All suggestions are very welcome, Thank you in advance,
> Berni

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19712
Subject: How to upgrade Foundation 1.4 to build Spartan-XL code?
From: "Sergey Vlasov" <sv.@itam.nsc.ru>
Date: Sun, 9 Jan 2000 12:47:07 +0600
Links: << >>  << T >>  << A >>
I generate Spartan FPGA configuration codes with My Foundation 1.4 package.
I thought (as per Xilinx PLD 1988 databook) Spartan XL is code compatible,
purchased some and now think it is incompatible. (In 1.4 there are no
codegen for XL.)
Is it correct?

Is there a way to convert Spartan code to Spartan XL if I do not use
special 'XL features?

Is there a way to upgrade FNDTN 1.4 to generate XL code other than to
purchase FNDTN 2.1?

I didn't find on Xilinx Web words about an upgrade. Is it possible at all?

Thank you.
Sergey Vlasov
project manager
AO Tyumenpromgeophysica.
Novosibirsk
Russian Federation



Article: 19713
Subject: Re: Design security
From: jim granville <jim.granville@DesignTools.co.nz>
Date: Sun, 09 Jan 2000 20:15:38 +1300
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> In article <3870B679.D84288FD@ids.net>,
>  Ray Andraka <randraka@ids.net> writes:
> > The problem with putting an OTP key in the device, is that the non-volatile
> > cells can't be fabricated without additional process steps.  The FPGA
> > process is essentially the same as DRAM, which lets it be done with bleeding
> > edge process.  Put PROM cells on there, and you lose the speed.
> 
> I'm not a silicon guru.  This case is different from a normal
> PROM in that we don't need a lot of bits.

But you do - the whole config memory needs to go on chip, not just the
security bit(s), and  you'll want the config memory re-writable as well,
otherwise the anitfuse devices are equivalent.
 
 A few bits of write-once is not a big problem - you just arrange a
kill-able element.

 Gatefield/Actel have FLASH FPGA, but the very leading edge will always
be
RAM based.

 A design option for the security paranoid is to split the design
between
the FPGA, and a sister CPLD - the FPGA can be cloned, but the system
cannot.
In a QFP44 you can get 64/72 Macrocells, which can be quite a 'lock'

- jg


Article: 19714
Subject: Re: Design security
From: murray@pa.dec.com (Hal Murray)
Date: 9 Jan 2000 08:49:30 GMT
Links: << >>  << T >>  << A >>

> But you do - the whole config memory needs to go on chip, not just the
> security bit(s), and  you'll want the config memory re-writable as well,
> otherwise the anitfuse devices are equivalent.

Sorry I wasn't clear.  I was thinking of the case where the bit stream
was encrypted and there was some decryption logic on the FPGA.  Then
the only storage you need on the FPGA is for the decryption key.

I like your suggestion of making the key area write-once.


Humm..  Suppose we had an FPGA that processed and encrypted bit
stream.  How good does the encryption have to be?

I've seen a lot of work on designing encryption algorithims that
are good and can be implemented to run fast on modern CPUs.  Is
there any work on algorithims that use minimal silicon area?

-- 
These are my opinions, not necessarily my employers.
Article: 19715
Subject: Re: Optimizing VHDL for Altera
From: "Berni Joss" <berni_13@yahoo.com>
Date: Sun, 9 Jan 2000 10:09:10 +0100
Links: << >>  << T >>  << A >>
Thank you for the explanations.

> stay in one level of logic.  The bottom line here is if you are doing
clock
> enables, accumulators with load or synch clear, adder/subtractors or any
other 3
> or more input arithmetic you'll end up using 2 LE's per bit per function.

The registers of my adders do indeed have a clock enable input ..

> Xilinx FPGAs have a different carry chain structure that permits 2 bits of
3
> input arithmetic per CLB for 4000 and spartan series, or 4 input
arithmetic in
> Virtex and Spartan II.

Unfortunately at this point changing from Altera to Xilinx reprensts a lot
of work (and cost). So, as you suggest, I'll start looking into LEs, EABs.

> Also, in most DSP algorithms you wind  up with a need for sample delays
(taps in
> a filter, etc).  In Altera devices, the delays are implemented in the LE
> registers, which means you use up an LE for each bit of each clock of
delay.

The filter channels do indeed take a larger than expected amount of
resources.

> You might be able to revisit your algorithm to find a better way to do it.
> Doing so will decrease the size of the design both in the Altera device
and in
> your ASIC.

This makes sense, I guess you're suggesting I should spend more time
understanding how Synplicity will attempt to map my  code onto the target
architectures.

> your ASIC.  As far as architectural optimizations, you will do better in
Altera
> if you design keeping in mind the structure of the LE's but where your
target is
> an ASIC, I don't think you'll get real far that way.

The choice of the 10k100 Altera had been made assuming there would be a lot
of spare resources as well as timing margin to allow us synthesizing the
design without worrying about the FPGA architecture ... our estimations
where off by a factor of 4 at least!

> Can you run at a higher clock rate and time multiplex the multiple
channels
> through the same set of hardware?  Alternatively, at a 10 MHZ, you should
be
> able to some of the processing bit-serial, again at a higher system clock.

We thought of multiplexing to reduce ASIC size ... but where reluctant to
increase complexity  before having debugged the algorithms.

I didn't consider bit-serial yet (I'm relatively new to DSP design).

Also, as the logic will be part of a mixed signal ASIC together with
low-noise analog processing, there are some concerns about digital switching
noise.
I'm sure many of you are well experienced in this topic, digital noise in
mixed signal ASICs. Should I expect any increase (or decrease??) of digital
noise when changing to a multiplexed architecture?
Does bit serial generate more noise?
Which noise coupling paths should I fear most?

Your suggestions are much appreciated,
Berni



Article: 19716
Subject: Re: Disable clockbuffer for only a single flip-flop
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sun, 9 Jan 2000 01:42:39 -0800
Links: << >>  << T >>  << A >>
Ray,

Ray Andraka <randraka@ids.net> wrote in message
news:3877C3F7.8EA387E3@ids.net...
> The outputs from the DLLs can be put directly onto the low skew global
clock
> networks.  The low skew between the 1x and 2x clocks is pretty much
maintained by
> the low skew networks, as the routing is virtually identical.  Xilinx
tells me
> that the maximum skew between two clocks sourced by the same DLL as
measured at a
> CLB clock input is less than the clock to Q, shortest connection to
another
> register and setup of the second register anywhere on the array.

This is the second time you've mentioned this as of late... I take it the
idea is take if you have Clk 1 firing at t0 and the skew on Clk 2 is such
that it fires at t0+/-delta, and you're feeding the output of flop 1
(clocked by Clk 1) to the input of flop 2 (clocked by Clk 2, the frequency
of which is a multiple of or integral divisor of Clk 1), you're safe in any
case because:

-- With Clk 2 firing at t0+delta, since delta is less than clock to Q of
flop 1, and flop 2 has a zero hold time requirement (and the tools have told
you that setup is OK -- setup is only helped in this instance), you know
that flop 2 will always get the "old" value of flop 1 that it wants instead
of accidentally getting the newly output value of flop 1.
-- With Clk 2 firing at t0-delta, clearing you're looking at the old value
of flop 1 that you're after.  In this case, however, the delta value
directly reduces the setup time to flop 2... if your timing was really tight
to begin with, what's to guarantee that you won't have a setup time
violation in this instance?

BTW, at least on the news server I use, your post here showed up about ten
times!

---Joel



Article: 19717
Subject: Make thousands$$$$ form only $6!!!!!!!!!!!!!!!!!
From: "Jess" <jessica_jahshua@hotmail.com>
Date: 9 Jan 2000 03:22:51 -0800
Links: << >>  << T >>  << A >>

Make thousands form only $6!!!!!!!!!!!!!!!!!
TURN $6.00 INTO $42,000!! 
FIND OUT HOW! 


THIS IS NO SCAM IT REALLY WORKS! FOR RESULTS YOU MUST
FOLLOW ALL THE SIMPLE INSTRUCTIONS AND THEY MUST BE
FOLLOWED EXACTLY! NO HALF-STEP-IN'!!! Turn $6.00 into $42,000... read
this to find out how!!!! READING THIS COULD CHANGE YOUR LIFE!!!! I
found this on a website and decided to try it. This says you can make thousands of
cash within weeks with only an initial investment of $6.00!! So I thought, "Yeah
right, this must be a scam", but like most of us, I was curious, so I kept reading.
Anyway, it said that you send $1.00 to each of the 6 names and address stated in
the article. You then place your own name and address in the bottom of the list at
#6, and post the article in at least 200 (or MORE!) news groups. (There are
thousands) No catch, that was it. So after thinking it over, and talking to a few
people first, I thought about trying it. I figured: "what have I got to lose except 6
stamps and $6.00-I'm already a**ed out right? Then, I started getting cash in the
mail!! I was shocked!! I figured it would end soon, but the dough just kept coming
in. In my first week, I made about $25.00. By the end of the second week I had
made a total of over $1,000.00!! In the third week I had over $10,000.00 and it's
still growing. This is now my fourth week and I have made a total of just over
$42,000.00 and it's still coming in rapidly. It's certainly worth $6.00, and stamps!
Let me tell you how this works and most importantly, why it works... Also, make
sure you print a copy of this article NOW, so you can get the information off of it
as you need it. I promise you that if you follow the directions exactly, that you will
start making more cash than you thought possible by doing something so easy!!!
Suggestion: Read this entire message carefully! (Print it out or download it)
Follow the simple directions and watch the cash come in!! It's easy. It's legal. And,
your investment is only $6.00 (plus postage) IMPORTANT: This is not a rip-off;
it is not indecent; it is not illegal; and it is virtually no risk - it really works!!!! If
all of the following instructions are adhered to, you will receive extraordinary
dividends. PLEASE NOTE: Please follow these directions EXACTLY, and
$50,000 or more can be yours in 20 to 60 days. This program remains successful
because of the honesty and integrity of the participants. Please continue its
success by carefully adhering to the instructions. You will now become part of
the Mail Order business. In this business your product is not solid and tangible,
it's a service. You are in the business of developing Mailing Lists. Many large
corporations are happy to pay big bucks for quality lists. However, the cash made
from the mailing lists is secondary to the income which is made from people
like you and me asking to be included in that list. Here are the 4 easy steps to
success: STEP 1: Get 6 separate pieces of paper and write the following on each
piece of paper "PLEASE PUT ME ON YOUR MAILING LIST". Now get 6 us
$1.00 bills and place ONE inside EACH of the 6 pieces of paper so the bill will
not be seen through the envelope (to prevent thievery). Next, place one paper in
each of the 6 envelopes and seal them. You should now have 6 sealed envelopes,
each with a piece of paper stating the above phrase, your name and address, and a
$1.00 bill. What you are doing is creating a service. THIS IS ABSOLUTELY
LEGAL! You are requesting a legitimate service and you are paying for it! Like
most of us I was a little skeptical and a little worried about the legal aspects of it
all. So I checked it out with the U.S. Post Office (1-800-725-2161) and they
confirmed that it is indeed legal! Mail the 6 envelopes to the following addresses:
#1)Monique' Washington 212 Victoria Dr. , Coatesville PA 19320 #2) Julia
Cardenas P.O. Box 2316 Miami, FL 33125 #3)R Frank 1775 Redondo St San
Diego, CA 92107 #4)Sherina Velega, 3610 Carroll Dr., Florence, SC 29506 #5)P
Johnson HHT 1/7 CAV Fort Hood, TX 76544.#6) Jjess, 5914 Marta Dr., Tampa,
FL.33617  STEP 2: Now take the #1 name off the list that you see above, move
the other names up (6 becomes 5, 5 becomes 4, etc...) and add YOUR name as
number 6 on the list. STEP 3: Change anything you need to, but try to keep this
article as close to original as possible. Now, post your amended article to at least
200 news groups. (I think there are close to 24,000 groups) All you need is 200,
but remember, the more you post, the more cash you make! This is perfectly legal.
If you have any doubts, refer to Title 18 Sec. 1302 & 1341 of the Postal lottery
laws. Keep a copy of these steps for yourself and, whenever you need cash, you
can use it again and again. PLEASE REMEMBER that this program remains
successful because of the honesty and integrity of the participants and by
their carefully adhering to the directions. Look at it this way. If you are of
integrity, the program will continue and the cash that so many others have
received will come your way.  NOTE: You may want to retain every name and
address sent to you, either on a computer or a hard copy and keep the notes people
send you. This VERIFIES that you are truly providing a service. (Also it might be
a good idea to wrap the $1 bill in dark paper to reduce the risk of mail theft) So, as
each post is downloaded and the directions carefully followed, six members will
be reimbursed for their participation as a List Developer with one dollar each.
Your name will move up the list geometrically so that when your name reaches the
#1 position you will be receiving thousands of cash in CASH!!! What an
opportunity for only $6.00 ($1.00 for each of the first six people listed above)
Send it now, add your own name to the list and you're in business!
------DIRECTIONS----- FOR HOW TO POST TO NEWSGROUPS-----------
STEP 1) You do not need to re-type this entire letter to do your own posting.
Simply put your cursor at the beginning of this letter and drag your cursor to the
bottom of this document, and select "copy" from the edit menu. This will copy the
entire letter into the computer's memory. STEP 2) Open a blank "notepad" file and
place your cursor at the top of the blank page. From the edit menu select "paste".
This will paste a copy of the letter into notepad so that you can add your name to
the list. STEP 3)Save your new notepad file as a .txt file. If you want to do your
postings in different settings, you'll always have this file to go back to. STEP
4)Use Netscape or Internet explorer and try searching for various newsgroups
(on-line forums, message boards, chat sites, discussions.) STEP 5) Visit these
message boards and post this article as a new message by highlighting the text of
this letter and selecting paste from the edit menu. Fill in he Subject, this will be the
header that everyone sees as they scroll through the list of postings in a particular
group, click the post message button. You're done with your first one!
Congratulations... THAT'S IT! All you have to do is jump to different newsgroups
and post away, after you get the hang of it, it will take about 30 seconds for each
newsgroup! **REMEMBER, THE MORE NEWSGROUPS YOU POST IN, THE
MORE Cash YOU WILL MAKE!! BUT YOU HAVE TO POST A MINIMUM
OF 200** That's it! You will begin receiving cash from around the world within
days! You may eventually want to rent a P.O. Box due to the large amount of mail
you will receive. If you wish to stay anonymous, you can invent a name to use, as
long as the postman will deliver it. ** JUST MAKE SURE ALL THE
ADDRESSES ARE CORRECT** Now the WHY part: Out of 200 postings, say I
receive only 5 replies (a very low example). So then I made $5.00 with my name at
#6 on the letter. Now, each of the 5 persons who just send me $1.00 make the
MINIMUM 200 postings, each with my name at #5 and only 5 persons respond to
each of the original 5, that is another $25.00 for me, now those 25 each make 200
MINIMUM posts with my name at #4 and only 5 replies each, I will bring in an
additional $125.00! Now those 125 persons turn around and post the MINIMUM
200 with my name at #3 and only receive 5 replies each, I will make an additional
$626.00! OK, now here is the fun part, each of those 625 persons post a
MINIMUM 200 letters with my name at #2 and they each only receive 5 replies,
that just made me $3,125.00!!! Those 3,125 persons will all deliver this message
to 200 newsgroups with my name at #1 and if still 5 persons per 200 newsgroups
react I will receive $15,625.00! With an original investment of only $6.00!
AMAZING! When your name is no longer on the list, you just take the latest
posting in the newsgroups, and send out another $6.00 to the names on the list,
putting your name at number 6 again. And start posting again. The thing to
remember is: do you realize that thousands of people all over the world are joining
the Internet and reading these articles everyday?, JUST LIKE YOU are now!! So,
can you afford $6.00 and see if it really works?? I think so... People have said,
"what if the plan is played out and no one sends you the cash? So what! What are
the chances of that happening when there are tons of new honest users and new
honest people who are joining the Internet and newsgroups everyday and are
willing to give it a try? Estimates are at 20,000 to 50,000 new users, everyday,
with thousands of those joining the actual Internet. Remember, play FAIRLY
and HONESTLY and this will really work. I was skeptical too, but not
anymore!! 


Article: 19718
Subject: Re: Optimizing VHDL for Altera
From: mcjy@my-deja.com
Date: Sun, 09 Jan 2000 14:12:35 GMT
Links: << >>  << T >>  << A >>
If you are using MaxplusII, in Global Logic
Synthesis option, you should able to find
Auto Implement in EAB.  This can convert
some of the logic into EAB blocks. But
if you are using 3rd parties tools I
don't know if this option is available.
This option, however, may make your design
run slower.

from
Joe

In article <947408955.979827@unet.urbanet.ch>,
  "Berni Joss" <berni_13@yahoo.com> wrote:
> Thank you for the explanations.
>
> > stay in one level of logic.  The bottom line here is if you are
doing
> clock
> > enables, accumulators with load or synch clear, adder/subtractors or
any
> other 3
> > or more input arithmetic you'll end up using 2 LE's per bit per
function.
>
> The registers of my adders do indeed have a clock enable input ..
>
> > Xilinx FPGAs have a different carry chain structure that permits 2
bits of
> 3
> > input arithmetic per CLB for 4000 and spartan series, or 4 input
> arithmetic in
> > Virtex and Spartan II.
>
> Unfortunately at this point changing from Altera to Xilinx reprensts a
lot
> of work (and cost). So, as you suggest, I'll start looking into LEs,
EABs.
>
> > Also, in most DSP algorithms you wind  up with a need for sample
delays
> (taps in
> > a filter, etc).  In Altera devices, the delays are implemented in
the LE
> > registers, which means you use up an LE for each bit of each clock
of
> delay.
>
> The filter channels do indeed take a larger than expected amount of
> resources.
>
> > You might be able to revisit your algorithm to find a better way to
do it.
> > Doing so will decrease the size of the design both in the Altera
device
> and in
> > your ASIC.
>
> This makes sense, I guess you're suggesting I should spend more time
> understanding how Synplicity will attempt to map my  code onto the
target
> architectures.
>
> > your ASIC.  As far as architectural optimizations, you will do
better in
> Altera
> > if you design keeping in mind the structure of the LE's but where
your
> target is
> > an ASIC, I don't think you'll get real far that way.
>
> The choice of the 10k100 Altera had been made assuming there would be
a lot
> of spare resources as well as timing margin to allow us synthesizing
the
> design without worrying about the FPGA architecture ... our
estimations
> where off by a factor of 4 at least!
>
> > Can you run at a higher clock rate and time multiplex the multiple
> channels
> > through the same set of hardware?  Alternatively, at a 10 MHZ, you
should
> be
> > able to some of the processing bit-serial, again at a higher system
clock.
>
> We thought of multiplexing to reduce ASIC size ... but where reluctant
to
> increase complexity  before having debugged the algorithms.
>
> I didn't consider bit-serial yet (I'm relatively new to DSP design).
>
> Also, as the logic will be part of a mixed signal ASIC together with
> low-noise analog processing, there are some concerns about digital
switching
> noise.
> I'm sure many of you are well experienced in this topic, digital noise
in
> mixed signal ASICs. Should I expect any increase (or decrease??) of
digital
> noise when changing to a multiplexed architecture?
> Does bit serial generate more noise?
> Which noise coupling paths should I fear most?
>
> Your suggestions are much appreciated,
> Berni
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19719
Subject: On chip Oscillator
From: "Robert Larkin" <robert@rlarkin.freeserve.co.uk>
Date: Sun, 9 Jan 2000 17:39:43 -0000
Links: << >>  << T >>  << A >>
Regarding the on chip clock on Xilinx 4005 FPGAs. Are any any external RC
components needed? I couldn't seem to find an application  note dealing with
this question. Also does any one have any real idea of its reliability?

Thanks
Robert Larkin



Article: 19720
Subject: Re: Make thousands$$$$ form only $6!!!!!!!!!!!!!!!!!
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Sun, 09 Jan 2000 11:20:07 -0800
Links: << >>  << T >>  << A >>
On 9 Jan 2000 03:22:51 -0800, "Jess" <jessica_jahshua@hotmail.com>
wrote:

|
|Make thousands form only $6!!!!!!!!!!!!!!!!!
|

Jessica,

Does it involve learning how to spell?

John



= = = = = = = = = = = = = =

Don't assume malice when incompetance will do.
Article: 19721
Subject: Re: How to upgrade Foundation 1.4 to build Spartan-XL code?
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 20:34:22 GMT
Links: << >>  << T >>  << A >>
You need to run through the bit strean generation again for the XL device.
While the same design can go into a Spartan or spartan XL of the same size, the
bitstreams are different.  Your constraints, pin assignments and any
floorplanning will apply to either.

Sergey Vlasov wrote:

> I generate Spartan FPGA configuration codes with My Foundation 1.4 package.
> I thought (as per Xilinx PLD 1988 databook) Spartan XL is code compatible,
> purchased some and now think it is incompatible. (In 1.4 there are no
> codegen for XL.)
> Is it correct?
>
> Is there a way to convert Spartan code to Spartan XL if I do not use
> special 'XL features?
>
> Is there a way to upgrade FNDTN 1.4 to generate XL code other than to
> purchase FNDTN 2.1?
>
> I didn't find on Xilinx Web words about an upgrade. Is it possible at all?
>
> Thank you.
> Sergey Vlasov
> project manager
> AO Tyumenpromgeophysica.
> Novosibirsk
> Russian Federation

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19722
Subject: Re: Optimizing VHDL for Altera
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 20:50:13 GMT
Links: << >>  << T >>  << A >>


Berni Joss wrote:

> Thank you for the explanations.
>
> > stay in one level of logic.  The bottom line here is if you are doing
> clock
> > enables, accumulators with load or synch clear, adder/subtractors or any
> other 3
> > or more input arithmetic you'll end up using 2 LE's per bit per function.
>
> The registers of my adders do indeed have a clock enable input ..
>
> > Xilinx FPGAs have a different carry chain structure that permits 2 bits of
> 3
> > input arithmetic per CLB for 4000 and spartan series, or 4 input
> arithmetic in
> > Virtex and Spartan II.
>
> Unfortunately at this point changing from Altera to Xilinx reprensts a lot
> of work (and cost). So, as you suggest, I'll start looking into LEs, EABs.
>
> > Also, in most DSP algorithms you wind  up with a need for sample delays
> (taps in
> > a filter, etc).  In Altera devices, the delays are implemented in the LE
> > registers, which means you use up an LE for each bit of each clock of
> delay.
>
> The filter channels do indeed take a larger than expected amount of
> resources.
>

I wasn't sure if you had filters in there or not.  How are they implemented?
FIR or IIR? how many coefficients?  If you haven't already, you should look at
the distributed arithmetic algorithm.

>
> > You might be able to revisit your algorithm to find a better way to do it.
> > Doing so will decrease the size of the design both in the Altera device
> and in
> > your ASIC.
>
> This makes sense, I guess you're suggesting I should spend more time
> understanding how Synplicity will attempt to map my  code onto the target
> architectures.
>

This is an unfortunate state of affairs.  The silicon vendors are shooting for
more of a push the button and let it go design environment, but I think with the
mushrooming chip sizes and capabilities, programming of the chips is actually
getting harder for the occasional user instead of easier as was the goal.  In
shooting for this push-button goal, the vendors have all but ignored the needs
of the expert users making the software more difficult for everyone.

>
> > your ASIC.  As far as architectural optimizations, you will do better in
> Altera
> > if you design keeping in mind the structure of the LE's but where your
> target is
> > an ASIC, I don't think you'll get real far that way.
>
> The choice of the 10k100 Altera had been made assuming there would be a lot
> of spare resources as well as timing margin to allow us synthesizing the
> design without worrying about the FPGA architecture ... our estimations
> where off by a factor of 4 at least!

Don't feel bad.  I run into this alot.  Altera is great for random logic and
stuff with lots of state machines.  It falls seriously short for DSP
applications because of the reasons I stated in my last post, as well as the
fact that its routing does not favor lots of bus-wide local connections like
those you wind up with in adder trees.


>
>
> > Can you run at a higher clock rate and time multiplex the multiple
> channels
> > through the same set of hardware?  Alternatively, at a 10 MHZ, you should
> be
> > able to some of the processing bit-serial, again at a higher system clock.
>
> We thought of multiplexing to reduce ASIC size ... but where reluctant to
> increase complexity  before having debugged the algorithms.
>
> I didn't consider bit-serial yet (I'm relatively new to DSP design).
>
> Also, as the logic will be part of a mixed signal ASIC together with
> low-noise analog processing, there are some concerns about digital switching
> noise.

Well founded concerns.  You need to pay special attention to your layout and
power supplies.

>
> I'm sure many of you are well experienced in this topic, digital noise in
> mixed signal ASICs. Should I expect any increase (or decrease??) of digital
> noise when changing to a multiplexed architecture?
> Does bit serial generate more noise?
> Which noise coupling paths should I fear most?
>

Its a trade of one noise for another.  The clock rates for bit serial designs
are much higher, so you've got more potential for clock leakage.  On the
otherhand, the logic is much smaller and tends to have only very local
connections so you don't have the big radiators you have in a parallel
implementation.  Careful layout will avoid problems.  The same applied for a
mux'd architecture.

>
> Your suggestions are much appreciated,
> Berni

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19723
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Sun, 09 Jan 2000 21:00:20 GMT
Links: << >>  << T >>  << A >>
You have two cases.  First is the case where the destination FF is clocked
slightly ahead of the source FF.  In that case, as you point out, there is no
way for the data to beat the clock to the destination FF.  It does slightly
erode the setup margin for a signal that uses up the whole clock cycle.
Presumably this is accounted for in the static timing analysis worst case delay
numbers.

The second case is where the destination FF is clocked slightly ahead of the
source FF.  In this case, if the signal path were shorter than the clock skew,
you'd end up with a race condition.  Here's where the device characteristics
have to conspire to help out.  In your favor, the signal out of the flip-flop
travels through at least a switch, and often a LUT before getting to the next
FF, while the clocks for the two are distributed on skew controlled, virtually
identical networks.  As long as the route delay is greater than the skew (plus
or minus setup/hold and Tcq considerations) you don't have a problem.

Yeah, I saw the billions and billions of posts.  I don't know what happened
there.  I cancelled all but one today when I saw them.

Joel Kolstad wrote:

> Ray,
>
> Ray Andraka <randraka@ids.net> wrote in message
> news:3877C3F7.8EA387E3@ids.net...
> > The outputs from the DLLs can be put directly onto the low skew global
> clock
> > networks.  The low skew between the 1x and 2x clocks is pretty much
> maintained by
> > the low skew networks, as the routing is virtually identical.  Xilinx
> tells me
> > that the maximum skew between two clocks sourced by the same DLL as
> measured at a
> > CLB clock input is less than the clock to Q, shortest connection to
> another
> > register and setup of the second register anywhere on the array.
>
> This is the second time you've mentioned this as of late... I take it the
> idea is take if you have Clk 1 firing at t0 and the skew on Clk 2 is such
> that it fires at t0+/-delta, and you're feeding the output of flop 1
> (clocked by Clk 1) to the input of flop 2 (clocked by Clk 2, the frequency
> of which is a multiple of or integral divisor of Clk 1), you're safe in any
> case because:
>
> -- With Clk 2 firing at t0+delta, since delta is less than clock to Q of
> flop 1, and flop 2 has a zero hold time requirement (and the tools have told
> you that setup is OK -- setup is only helped in this instance), you know
> that flop 2 will always get the "old" value of flop 1 that it wants instead
> of accidentally getting the newly output value of flop 1.
> -- With Clk 2 firing at t0-delta, clearing you're looking at the old value
> of flop 1 that you're after.  In this case, however, the delta value
> directly reduces the setup time to flop 2... if your timing was really tight
> to begin with, what's to guarantee that you won't have a setup time
> violation in this instance?
>
> BTW, at least on the news server I use, your post here showed up about ten
> times!
>
> ---Joel

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19724
Subject: Re: Decoding RSPC (Reed Solomon Product Code)
From: jhirbawi@yahoo.com
Date: Mon, 10 Jan 2000 00:27:44 GMT
Links: << >>  << T >>  << A >>
In article <84savt$bo2$1@violet.singnet.com.sg>,
  "MK Yap" <mkyap@ieee.org> wrote:
> Hi,
>
> I'm writing a prog (VHDL or C) to enable block encoding and decoding
of CD
> sectors.  In the ECC (error correction coding) field, RSPC(Reed
Solomon
> Product Code) is used. The RSPC is a product code over GF(2^8)
producing P
> and Q parity bytes.  The GF(2^8) field is generated by the primitive
> polynomial
> P(x) = x^8 + x^4 + x^3 + x^2 + 1
> The P parities are (26,24) RS codeword over GF(2^8) and the Q parities
are
> (45,43) RS codeword over GF(2^8).
>
> My question is: How can I write the encoding and decoding algorithm
for the
> ECC field?? The RS used are non standard RS codes (n,k) in which n is
> usually n=2^m -1 which m=8 in this case...
> I tried to look for more info from books but it is really limited... I
came
> across some books saying that conventional RS decoding can be used..
that is
> the berlekamp, Peterson and Weldon algorithm.  But I see no connection
> between them coz the derivation is based on a fundamental which is
> different.
>
> Pls enlighten... by providing some books, paper, web site or perhaps
> explanation of theory behind them...  Thank you very much!!

You're dealing with shortened Reed-Solomon codes; you may not find much
that specifically describes their encoding and decoding beacause it is
almost the same as the non-shortened version. For the encoder, encode as
a generic cyclic code over GF(2^8). For the decoding the Euclidean
Algoithm decoder will work for the shortened codes the same way it would
for the non-shortened ones with n=your codeword length instead of 2^m-1.
I'm sure the Berlekamp-Massey algorithm will also work with only minor
modifications.

Jacob Hirbawi.


Sent via Deja.com http://www.deja.com/
Before you buy.


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