Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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/~randrakaArticle: 19701
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/~randrakaArticle: 19702
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/~randrakaArticle: 19703
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/~randrakaArticle: 19704
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/~randrakaArticle: 19705
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/~randrakaArticle: 19706
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/~randrakaArticle: 19707
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/~randrakaArticle: 19708
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/~randrakaArticle: 19709
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/~randrakaArticle: 19710
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/~randrakaArticle: 19711
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/~randrakaArticle: 19712
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 FederationArticle: 19713
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' - jgArticle: 19714
> 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
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, BerniArticle: 19716
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! ---JoelArticle: 19717
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
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
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 LarkinArticle: 19720
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
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/~randrakaArticle: 19722
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/~randrakaArticle: 19723
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/~randrakaArticle: 19724
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:
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