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
On Nov 11, 6:34=A0pm, "k...@att.bizzzzzzzzzzzz" <k...@att.bizzzzzzzzzzzz> wrote: > On Thu, 11 Nov 2010 07:03:29 -0800, John Larkin > > > > <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > >On Thu, 11 Nov 2010 08:45:56 -0000, "Michael Kellett" > ><nos...@nospam.com> wrote: > > >>"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in mes= sage > >>news:iq5jd6t8vpelg53n1e1e5hdkqs7f0deu90@4ax.com... > > >>>http://www.theregister.co.uk/2010/11/09/marvell_armada_xp_arm_chip/ > > >>> All that beautiful room for vias. > > >>> John > > >>Very nice (the pattern - I don't have any use for the chip !). I wish m= ore > >>semi compnaies would think a bit more about the cost of using BGAs befo= re > >>connecting evey possible ball. > > >>Michael Kellett > > >The Altera chip we're going to use [1] is a solid rectangle of balls. > >Yuk. > > They're not all that bad. =A0Most of the center are power/ground so easie= r to > wire. =A0The problem is that without the doughnut hole there is no conven= ient > place to put decoupling and terminators (on the back). =A0The coarse pitc= hed > parts (1mm and .8mm) aren't hard to fan out, either. =A0We're stuck with = them > because of our SMT process anyway. =A0My problem is that no one makes > low-pincount parts with a coarse pitch. =A0They insist on .5 or even .4mm= ! > > >John > > >[1] We're migrating away from Xilinx. Great silicon, insanely broken > >software. > > I didn't have a lot of problems with Xilinx, other than it constantly wan= ted > to rebuild my libraries in a new location. =A0I like Altera's software mu= ch > better, though. There's a HUGE difference in package design for consumer products like mass-market microprocessors and PC chip sets, and embedded products like FPGA's and microcontrollers. For the consumer stuff the overall package size isn't as important as the ability to lay out the circuit on as few layers as possible. For embedded components its ALL about package size. The boards just keep getting smaller (look at cell phones). On a board the size of a PC motherboard, you don't want 12 layers, or fine pitch routing, or blind vias... Much better to have a 12-layer BGA substrate that brings out signals to 1.27mm spaced pads in an order that matches the surrounding chips so that the entire bus routes in one or two layers. But you can clearly see that these BGA packages are significantly larger than the silicon devices they support. On a cell phone sized board adding a couple layers or using blind vias or microvias won't increase the product price significantly. But having a chip that takes up the entire board would be a design killer. Regards, GaborArticle: 149626
On Nov 11, 3:03=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Thu, 11 Nov 2010 08:45:56 -0000, "Michael Kellett" > > > > > > <nos...@nospam.com> wrote: > > >"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in mess= age > >news:iq5jd6t8vpelg53n1e1e5hdkqs7f0deu90@4ax.com... > > >>http://www.theregister.co.uk/2010/11/09/marvell_armada_xp_arm_chip/ > > >> All that beautiful room for vias. > > >> John > > >Very nice (the pattern - I don't have any use for the chip !). I wish mo= re > >semi compnaies would think a bit more about the cost of using BGAs befor= e > >connecting evey possible ball. > > >Michael Kellett > > The Altera chip we're going to use [1] is a solid rectangle of balls. > Yuk. > > John > > [1] We're migrating away from Xilinx. Great silicon, insanely broken > software. I wouldn't rush a decision like that - especially when I know from a very good source that there is a major effort underway to improve the SW at Xilinx. I hear there is a upcoming version of the SW that will be a big step forward in terms of quality, speed, etc. So might be worth waiting a while, especially if you are familiar with the silicon already.Article: 149627
On Nov 11, 5:29=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Nov 11, 7:58=A0am, jc <jcappe...@optimal-design.com> wrote: > > > In summary, registering state bits and doing binary conversion allows > > Maybe I'm missing something here, and just need a clearer > explanation... > > What is the output of the binary conversion when the input is an > illegal state value? (Example: =A0Three bit one hot that ends up at > "111") > > How do you specify the binary conversion function when the input is an > enumerate type? =A0The t_my_type'pos(xyz) won't do it. =A0In the previous > example it would return a number from 0 to 2. =A0Even allowing that the > implementation of the function would compute two bits and therefore be > capable of returning 0 to 3, it does not cover the case that I > mentioned "111". =A0The fact that there are three bits implementing the > one hot encoding means that there are 8 possibilities, most of which > can not be specified in any fashion. > > Kevin Kevin, I suspect (as others pointed out here) that using the OTHERS clause in a case statement for the binary conversion of a non-2^n number of states isn't enough to ensure safe mode, i.e. if more than one one-hot flop goes high, go to recovery state. In which case it would be up to the user to flip the safe mode switch for the original fsm flops, or apply custom logic on the binary conversion side to detect the condition, if this detection is desired. Otherwise, I believe the binary conversion will 'mask' such invalid conditions. If I get time soon, I'm going to analyze a set of gates for such a binary conversion process to see exactly what it does for invalid conditions. Having said that, I'm confident that a binary conversion using the CASE statement after registering the one-hot flops is a valid way to follow the sequence of the fsm in an expected order. I've done this many times via chipscope. JohnArticle: 149628
2cents wrote: > On Nov 11, 3:03 pm, John Larkin > [...] >> [1] We're migrating away from Xilinx. Great silicon, insanely broken >> software. > > I wouldn't rush a decision like that - especially when I know from a > very good source that there is a major effort underway to improve the > SW at Xilinx. > I hear there is a upcoming version of the SW that will be a big step > forward in terms of quality, speed, etc. So might be worth waiting a > while, especially if you are familiar with the silicon already. Do you still believe in Father Christmas and the Easter Bunny too? Jeroen BellemanArticle: 149629
On 11/12/10 9:28 AM, jc wrote:
> Kevin, I suspect (as others pointed out here) that using the OTHERS
> clause in a case statement for the binary conversion of a non-2^n
> number of states isn't enough to ensure safe mode, i.e. if more than
> one one-hot flop goes high, go to recovery state. In which case it
> would be up to the user to flip the safe mode switch for the original
> fsm flops, or apply custom logic on the binary conversion side to
> detect the condition, if this detection is desired. Otherwise, I
> believe the binary conversion will 'mask' such invalid conditions. If
> I get time soon, I'm going to analyze a set of gates for such a binary
> conversion process to see exactly what it does for invalid
> conditions.
I've tested this and verified the XST produces identical CPLD jedec
files whether or not the "when OTHERS" is present in a state machine.
> Having said that, I'm confident that a binary conversion using the
> CASE statement after registering the one-hot flops is a valid way to
> follow the sequence of the fsm in an expected order. I've done this
> many times via chipscope.
> John
But doesn't this only work if the state machine doesn't go to an illegal
state? Otherwise, if it goes 2-hot for example, the binary conversion
can't indicate both states, and will be in effect a priority encoder.
I've found that providing an independent decode for each state, i.e.
make 4 registered debug bits for a 4-state enum is a pretty bullet proof
way of catching illegal states without having to delve into low level
state signal names post synthesis:
process(clk)
begin
if state = s0 then
state0_debugbit <= '1';
else
state0_debugbit <= '0';
end if;
end process;
process(clk)
begin
if state = s1 then
state1_debugbit <= '1';
else
state1_debugbit <= '0';
end if;
end process;
and so on...
So state0_debugbit will be identical (after a register delay) to the
1-hot state bit.
I think it should be possible to wrap this up in a loop like this:
type state_t is (s0,s1,s2,s3);
signal state: state_t;
signal state_debugbits(3 downto 0);
process(clk)
begin
for i in 0 to 3 loop
if state = state_t'val(i) then
state_debugbits(i) <= '1';
else
state_debugbits(i) <= '0';
end if;
end loop;
end process;
-Jeff
Article: 149630On Fri, 12 Nov 2010 06:19:16 -0800 (PST), 2cents <web@sharonmccormack.com> wrote: >On Nov 11, 3:03 pm, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Thu, 11 Nov 2010 08:45:56 -0000, "Michael Kellett" >> >> >> >> >> >> <nos...@nospam.com> wrote: >> >> >"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in message >> >news:iq5jd6t8vpelg53n1e1e5hdkqs7f0deu90@4ax.com... >> >> >>http://www.theregister.co.uk/2010/11/09/marvell_armada_xp_arm_chip/ >> >> >> All that beautiful room for vias. >> >> >> John >> >> >Very nice (the pattern - I don't have any use for the chip !). I wish more >> >semi compnaies would think a bit more about the cost of using BGAs before >> >connecting evey possible ball. >> >> >Michael Kellett >> >> The Altera chip we're going to use [1] is a solid rectangle of balls. >> Yuk. >> >> John >> >> [1] We're migrating away from Xilinx. Great silicon, insanely broken >> software. > >I wouldn't rush a decision like that - especially when I know from a >very good source that there is a major effort underway to improve the >SW at Xilinx. That's not surprising. You could say the same about Microsoft. The issue is that software, and software culture, can be so broken that it can't be fixed. >I hear there is a upcoming version of the SW that will be a big step >forward in terms of quality, speed, etc. So might be worth waiting a >while, especially if you are familiar with the silicon already. Then why aren't our FAEs telling us about it? Maybe because Xilinx fired all of them not so long ago. JohnArticle: 149631
On Nov 12, 3:06=A0pm, Jeroen Belleman <jer...@nospam.please> wrote: > 2cents wrote: > > On Nov 11, 3:03 pm, John Larkin > > [...] > >> [1] We're migrating away from Xilinx. Great silicon, insanely broken > >> software. > > > I wouldn't rush a decision like that - especially when I know from a > > very good source that there is a major effort underway to improve the > > SW at Xilinx. > > I hear there is a upcoming version of the SW that will be a big step > > forward in terms of quality, speed, etc. So might be worth waiting a > > while, especially if you are familiar with the silicon already. > > Do you still believe in Father Christmas and the Easter Bunny too? > > Jeroen Belleman It's easy to be dismissive - but believe it or not, Xilinx has been doing something about customer complaints regarding the SW tools. They have been working on the problem for a number of years. Have you seen PlanAhead? That's a taste of things to come, or so I'm told.Article: 149632
On Fri, 12 Nov 2010 08:23:02 -0800 (PST), 2cents <web@sharonmccormack.com> wrote: >On Nov 12, 3:06 pm, Jeroen Belleman <jer...@nospam.please> wrote: >> 2cents wrote: >> > On Nov 11, 3:03 pm, John Larkin >> > [...] >> >> [1] We're migrating away from Xilinx. Great silicon, insanely broken >> >> software. >> >> > I wouldn't rush a decision like that - especially when I know from a >> > very good source that there is a major effort underway to improve the >> > SW at Xilinx. >> > I hear there is a upcoming version of the SW that will be a big step >> > forward in terms of quality, speed, etc. So might be worth waiting a >> > while, especially if you are familiar with the silicon already. >> >> Do you still believe in Father Christmas and the Easter Bunny too? >> >> Jeroen Belleman > >It's easy to be dismissive - but believe it or not, Xilinx has been >doing something about customer complaints regarding the SW tools. >They have been working on the problem for a number of years. Have you >seen PlanAhead? That's a taste of things to come, or so I'm told. Planahead is a tool which they've acquired. If the same group is developing ISE 13, it would probably be an good improvement. The main problem with the tools is timing engine and constraint management. If the timing engine under trace & par is replaced with something which supports SDC that would solve most of the problems are having. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 149633
On Nov 12, 9:28=A0am, jc <jcappe...@optimal-design.com> wrote: > > Kevin, I suspect (as others pointed out here) that using the OTHERS > clause in a case statement for the binary conversion of a non-2^n > number of states isn't enough to ensure safe mode I fully understand that "when others" does not necessarily generate recovery logic. Altera (and I suspect other tools) require a specific synthesis tool setting in order to enable 'safe state machines'. With Quartus, the setting is called "Safe State Machine" and is defined as "Tells the compiler to implement state machines that can recover gracefully from an illegal state." >, i.e. if more than > one one-hot flop goes high, go to recovery state. In which case it > would be up to the user to flip the safe mode switch for the original > fsm flops, or apply custom logic on the binary conversion side to > detect the condition, if this detection is desired. I agree that this logic can be manually added and also that allowing an extra clock cycle to recover might be acceptable also but I'm not seeing how your suggestion of a binary conversion function can be specified in the source code. For example, the three bit 'one hot' encoded example will have three bits and therefore 8 states (3 legal, 5 not legal). In order to 'know' that there are 5 illegal states in the final implementation, one would have to know ahead of time that it would be one-hot encoded. If the implementation was binary encoded there would only be one illegal state. Now ask yourself, 1. For a given enumeration type of 'n' values, what is the range of the integer value that is the output of your function? Is it '0 to n - 1'? Is it '0 to 2^n - 1'? 2. Using your answer to #1, explain why your answer is correct and why the other suggested answer is wrong. Does the 'pos() VHDL attribute have the same range as the answer that you think is correct? 3. Explain how you guarantee that the implementation of the final synthesized result has the encoding that matches the assumption that went into your answer to #1 and how the wrong answer from #2 will never be synthesized. 4. Explain how your answer to #3 is portable across multiple tools. Or, to view it a different way, which recognized standard provides the basis for your guarantee on #3? Hint: Since #1 said enumerated type, the basis for any guarantee to #3 will not be the VHDL language standard. In the end, there is probably no way to use an enumerated type and make it through all of the above questions. Using Quartus, the only way to get a safe state machine is to use a tool specific setting...but on the other hand, the only reason that the tool specific setting is required is because the tool also decided it was OK to ignore the "when others" in the source code in the first place. > > Having said that, I'm confident that a binary conversion using the > CASE statement after registering the one-hot flops is a valid way to > follow the sequence of the fsm in an expected order. I've done this > many times via chipscope. Debug in chipscope may have been the OP's original question, but this sub-topic has to do with recovery from illegal states and being able to specify something that gets implemented. Kevin JenningsArticle: 149634
Allow me to clarify. I now consider the issues of illegal state detection and binary conversion as two separate points of discussion. In the latter, all I'm suggesting now is that here is a means for translating an fsm into a format better understood through chipscope and/or status regs, regardless of how that fsm is ultimately coded. I take the blame for suggesting originally that using the "OTHERS" clause in this binary conversion takes care of illegal states. I now agree that this is not the case. For illegal state detection, it's up to the designer to either use a synthesis switch so that the tools can add the overhead logic into the original fsm code--which is completely separate from the binary conversion part--or build in this detection/recovery manually. I suggested that doing this within the binary conversion realm could alleviate performance issues that could occur with safe mode built within the original fsm. Sorry for the confusion. John KJ wrote: > I fully understand that "when others" does not necessarily generate > recovery logic. Altera (and I suspect other tools) require a specific > synthesis tool setting in order to enable 'safe state machines'. With > Quartus, the setting is called "Safe State Machine" and is defined as > "Tells the compiler to implement state machines that can recover > gracefully from an illegal state." > >Article: 149635
On Nov 12, 10:18=A0am, Jeff Cunningham <j...@sover.net> wrote: > On 11/12/10 9:28 AM, jc wrote: > > But doesn't this only work if the state machine doesn't go to an illegal > state? Otherwise, if it goes 2-hot for example, the binary conversion > can't indicate both states, and will be in effect a priority encoder. > Yes, I agree that this works only for legal state transitions, and that the binary conversion for illegal states is not well defined (mainly because it depends on how the synthesis tool implements the said case statement. It's up to the designer to monitor and flag illegal states some other way, if necessary. JohnArticle: 149636
On Nov 12, 11:22=A0am, Muzaffer Kal <k...@dspia.com> wrote: > On Fri, 12 Nov 2010 08:23:02 -0800 (PST), 2cents > > > > <w...@sharonmccormack.com> wrote: > >On Nov 12, 3:06=A0pm, Jeroen Belleman <jer...@nospam.please> wrote: > >> 2cents wrote: > >> > On Nov 11, 3:03 pm, John Larkin > >> > [...] > >> >> [1] We're migrating away from Xilinx. Great silicon, insanely broke= n > >> >> software. > > >> > I wouldn't rush a decision like that - especially when I know from a > >> > very good source that there is a major effort underway to improve th= e > >> > SW at Xilinx. > >> > I hear there is a upcoming version of the SW that will be a big step > >> > forward in terms of quality, speed, etc. So might be worth waiting a > >> > while, especially if you are familiar with the silicon already. > > >> Do you still believe in Father Christmas and the Easter Bunny too? > > >> Jeroen Belleman > > >It's easy to be dismissive - but believe it or not, Xilinx has been > >doing something about customer complaints regarding the SW tools. > >They have been working on the problem for a number of years. Have you > >seen PlanAhead? That's a taste of things to come, or so I'm told. > > Planahead is a tool which they've acquired. If the same group is > developing ISE 13, it would probably be an good improvement. The main > problem with the tools is timing engine and constraint management. If > the timing engine under trace & par is replaced with something which > supports SDC that would solve most of the problems are having. > -- > Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Services > > http://www.dspia.com >From page 26 of : http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_3/Whats_New= _PlanAhead.pdf Adoption of Synopsys Design Constraint Tcl Infrastructure In the 12 release, the Tcl infrastructure in PlanAhead changed to accommodate the long-term plans for Xilinx to migrate toward Synopsys Design Constraints (SDC) for timing constraints. Regards, John McCaskill www.FasterTechnology.comArticle: 149637
Do your modules operate using different clocks? If so you may have clock boundary crossing problems. John Adair Enterpoint Ltd. - Home of Drigmorn3. The Spartan-6 Development Board. On Nov 12, 12:54=A0pm, "sridar" <srisridar@n_o_s_p_a_m.gmail.com> wrote: > Hi all, > > I am working on a design, where there are n modules. Each module is > connected with next module in sequential fashion. > > like, =A0data generator -> encoder 1 -> encoder 2-> modulator -> demodula= tor > -> decoder2 -> decoder1 > > The output of decoder1 should be same as data generator. I have tested ea= ch > module in FPGA =A0and also the following configurations > > data generator -> encoder 1 -> encoder 2-> =A0decoder2 ->decoder1 =A0 =A0= =A0 =A0 =A0 =A0 > =A0 ----------Works fine > > data generator -> encoder 2 -> =A0modulator -> demodulator =A0-> decoder2= =A0 =A0 =A0 > =A0----------Works fine > > But, when I integrate the all the modules, the design is not working as > expected. I need to reset the board for 5,6 times for the output to come > correctly. The timing analyzer reported no error. > > BTW, I designed all the modules using VHDL in ISE 12.3 and tried in two > hardware boards 1. Spartan-6 sp601 kit =A02. Spartan-3 based baord > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 149638
On Nov 12, 6:03=A0pm, John McCaskill <jhmccask...@gmail.com> wrote: > On Nov 12, 11:22=A0am, Muzaffer Kal <k...@dspia.com> wrote: > > > > > > > On Fri, 12 Nov 2010 08:23:02 -0800 (PST), 2cents > > > <w...@sharonmccormack.com> wrote: > > >On Nov 12, 3:06=A0pm, Jeroen Belleman <jer...@nospam.please> wrote: > > >> 2cents wrote: > > >> > On Nov 11, 3:03 pm, John Larkin > > >> > [...] > > >> >> [1] We're migrating away from Xilinx. Great silicon, insanely bro= ken > > >> >> software. > > > >> > I wouldn't rush a decision like that - especially when I know from= a > > >> > very good source that there is a major effort underway to improve = the > > >> > SW at Xilinx. > > >> > I hear there is a upcoming version of the SW that will be a big st= ep > > >> > forward in terms of quality, speed, etc. So might be worth waiting= a > > >> > while, especially if you are familiar with the silicon already. > > > >> Do you still believe in Father Christmas and the Easter Bunny too? > > > >> Jeroen Belleman > > > >It's easy to be dismissive - but believe it or not, Xilinx has been > > >doing something about customer complaints regarding the SW tools. > > >They have been working on the problem for a number of years. Have you > > >seen PlanAhead? That's a taste of things to come, or so I'm told. > > > Planahead is a tool which they've acquired. If the same group is > > developing ISE 13, it would probably be an good improvement. The main > > problem with the tools is timing engine and constraint management. If > > the timing engine under trace & par is replaced with something which > > supports SDC that would solve most of the problems are having. > > -- > > Muzaffer Kal > > > DSPIA INC. > > ASIC/FPGA Design Services > > >http://www.dspia.com > > From page 26 of : > > http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_3/Wha... > > Adoption of Synopsys Design Constraint Tcl Infrastructure > > In the 12 release, the Tcl infrastructure in PlanAhead changed to > accommodate the long-term plans for > Xilinx to migrate toward Synopsys Design Constraints (SDC) for timing > constraints. > > Regards, > > John McCaskillwww.FasterTechnology.com I guess we can say "There is a Father Christmas after all ....." I think we'll all be much happier with ISE 13. Big companies can do great things when motivated, and from what I hear, Xilinx are very motivated in this area.Article: 149639
On Nov 12, 6:19=A0am, 2cents <w...@sharonmccormack.com> wrote: > > I wouldn't rush a decision like that - especially when I know from a > very good source that there is a major effort underway to improve the > SW at Xilinx. > I hear there is a upcoming version of the SW that will be a big step > forward in terms of quality, speed, etc. So might be worth waiting a > while, especially if you are familiar with the silicon already. This grumpy old man says "Harrumph". Version 11 was NOT an improvement from version 10. I know of at least one design that works "just fine" when built with ISE-10, and fails to run with ISE-12. Version 12 is NOT an improvement over version 11. My current project works "just fine" with ISE-11, but ISE-12 fails to build a bit-stream. After two steps backward like this, I find your claim hard to believe. For what it's worth: I find it to be about the same level of difficulty to switch ISE<->Quartus as I find it to switch ISE-(n)<- >ISE-(n+1). And (with very few exceptions) by the time you get a feature out of Coregen/Megawizard, they all look the same. Back to the OP's original topic: Yeah, these new packages are tough. Good thing itty-bitty ceramics come in large values, and thank the heavens for 'via in pad'. RKArticle: 149640
On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein <d_s_klein@yahoo.com> wrote: >On Nov 12, 6:19 am, 2cents <w...@sharonmccormack.com> wrote: >> >> I wouldn't rush a decision like that - especially when I know from a >> very good source that there is a major effort underway to improve the >> SW at Xilinx. >> I hear there is a upcoming version of the SW that will be a big step >> forward in terms of quality, speed, etc. So might be worth waiting a >> while, especially if you are familiar with the silicon already. > >This grumpy old man says "Harrumph". > >Version 11 was NOT an improvement from version 10. I know of at least >one design that works "just fine" when built with ISE-10, and fails to >run with ISE-12. > >Version 12 is NOT an improvement over version 11. My current project >works "just fine" with ISE-11, but ISE-12 fails to build a bit-stream. > >After two steps backward like this, I find your claim hard to believe. > >For what it's worth: I find it to be about the same level of >difficulty to switch ISE<->Quartus as I find it to switch ISE-(n)<- >>ISE-(n+1). And (with very few exceptions) by the time you get a >feature out of Coregen/Megawizard, they all look the same. > >Back to the OP's original topic: Yeah, these new packages are tough. >Good thing itty-bitty ceramics come in large values, and thank the >heavens for 'via in pad'. We just splatter a few 0603 caps on the top side of the board, far enough from the FPGA that production can get their little optical inspection gidget in there. Works fine. Is via in pad safe? Is solder slurping a serious issue? I'd sure like to eliminate those dogbone things. JohnArticle: 149641
On Fri, 12 Nov 2010 05:54:03 -0800 (PST), Gabor <gabor@alacron.com> wrote: >On Nov 11, 6:34 pm, "k...@att.bizzzzzzzzzzzz" ><k...@att.bizzzzzzzzzzzz> wrote: >> On Thu, 11 Nov 2010 07:03:29 -0800, John Larkin >> >> >> >> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> >On Thu, 11 Nov 2010 08:45:56 -0000, "Michael Kellett" >> ><nos...@nospam.com> wrote: >> >> >>"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in message >> >>news:iq5jd6t8vpelg53n1e1e5hdkqs7f0deu90@4ax.com... >> >> >>>http://www.theregister.co.uk/2010/11/09/marvell_armada_xp_arm_chip/ >> >> >>> All that beautiful room for vias. >> >> >>> John >> >> >>Very nice (the pattern - I don't have any use for the chip !). I wish more >> >>semi compnaies would think a bit more about the cost of using BGAs before >> >>connecting evey possible ball. >> >> >>Michael Kellett >> >> >The Altera chip we're going to use [1] is a solid rectangle of balls. >> >Yuk. >> >> They're not all that bad. Most of the center are power/ground so easier to >> wire. The problem is that without the doughnut hole there is no convenient >> place to put decoupling and terminators (on the back). The coarse pitched >> parts (1mm and .8mm) aren't hard to fan out, either. We're stuck with them >> because of our SMT process anyway. My problem is that no one makes >> low-pincount parts with a coarse pitch. They insist on .5 or even .4mm! >> >> >John >> >> >[1] We're migrating away from Xilinx. Great silicon, insanely broken >> >software. >> >> I didn't have a lot of problems with Xilinx, other than it constantly wanted >> to rebuild my libraries in a new location. I like Altera's software much >> better, though. > > >There's a HUGE difference in package design for consumer products like >mass-market microprocessors and PC chip sets, and embedded products >like FPGA's and microcontrollers. For the consumer stuff the overall >package size isn't as important as the ability to lay out the circuit >on >as few layers as possible. Nonsense. There are many places where large packages aren't useful. Think: cell phones. >For embedded components its ALL about >package size. The boards just keep getting smaller (look at cell >phones). Cell phones aren't "consumer stuff"? You're confused. >On a board the size of a PC motherboard, you don't want 12 layers, or >fine pitch routing, or blind vias... Much better to have a 12-layer >BGA substrate that brings out signals to 1.27mm spaced pads in >an order that matches the surrounding chips so that the entire bus >routes >in one or two layers. But you can clearly see that these BGA packages >are significantly larger than the silicon devices they support. >On a cell phone sized board adding a couple layers or using blind >vias or microvias won't increase the product price significantly. But >having a chip that takes up the entire board would be a design >killer. I have no idea what you're talking about. You have it all inside out.Article: 149642
On Fri, 12 Nov 2010 04:02:20 -0800, Socrates wrote: > On Nov 11, 4:45Â pm, "noob13" > <matija.draganovic@n_o_s_p_a_m.hotmail.com> wrote: >> Hi, >> >> I'm developing a certain controller using Spartan3 FPGA. Since I have >> to communicate with another circuit that is using 5V signaling (similar >> to TTL, but HV level is above 3.5V) I was wondering if someone could >> recommend a good solution in a form of a "level shifter" circuit (I >> searched the internet and found a few ICs that could do the job. >> However, I could use a good recomendation though :) ). >> >> Tnx in advance.. > > I use SN74LVC8T245, which can be used to interface any voltage bus > (either 3.3V <-> 5V or 3.3V <-> 1.8V possible afaik). There are two > separate power pins for buffer sides: VccA and VccB. However, You will > need to switch direction pin for full IO. Also I had other part ADM3304 > afaik, can't remember exactly, but I am sure it was ADMxxxx. I used a 74ALVC164245 on my last project, which also has two supplies and direction inputs. The OP should look for parts with numbers matching the patters 74xxx3245 and 74xxx4245. One must read the datasheet carefully as some parts have restrictions on supply sequencing, yet others (with almost identical part numbers) don't have such restrictions. Regards, AllanArticle: 149643
On Nov 11, 8:45=A0am, "noob13" <matija.draganovic@n_o_s_p_a_m.hotmail.com> wrote: > Hi, > > I'm developing a certain controller using Spartan3 FPGA. Since I have to > communicate with another circuit that is using 5V signaling (similar to > TTL, but HV level is above 3.5V) I was wondering if someone could recomme= nd > a good solution in a form of a "level shifter" circuit (I searched the > internet and found a few ICs that could do the job. However, I could use = a > good recomendation though :) ). > check out the TI TXB0102 and other parts in the series. They're very versatile covering a lot of voltage levels, no need to deal with direction like on the 74LVC8T245 and similar parts. They have good ESD protection, support powering down one side without loading down the other, and come in microscopic packages if you need that sort of thing. There is also a TXS010x series that is similar, but used for open-drain type interfaces like I2C.Article: 149644
On Nov 12, 7:54=A0am, "sridar" <srisridar@n_o_s_p_a_m.gmail.com> wrote: > Hi all, > > I am working on a design, where there are n modules. Each module is > connected with next module in sequential fashion. > > like, =A0data generator -> encoder 1 -> encoder 2-> modulator -> demodula= tor > -> decoder2 -> decoder1 > > The output of decoder1 should be same as data generator. I have tested ea= ch > module in FPGA =A0and also the following configurations > > data generator -> encoder 1 -> encoder 2-> =A0decoder2 ->decoder1 =A0 =A0= =A0 =A0 =A0 =A0 > =A0 ----------Works fine > > data generator -> encoder 2 -> =A0modulator -> demodulator =A0-> decoder2= =A0 =A0 =A0 > =A0----------Works fine > > But, when I integrate the all the modules, the design is not working as > expected. I need to reset the board for 5,6 times for the output to come > correctly. The timing analyzer reported no error. > > BTW, I designed all the modules using VHDL in ISE 12.3 and tried in two > hardware boards 1. Spartan-6 sp601 kit =A02. Spartan-3 based baord > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com How about an occasional bit error between the modulator and demodulator causes the decoder1 to get lost where as decoder2 is more robust.Article: 149645
On Nov 12, 6:27=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein > > >Back to the OP's original topic: =A0Yeah, these new packages are tough. > >Good thing itty-bitty ceramics come in large values, and thank the > >heavens for 'via in pad'. > > We just splatter a few 0603 caps on the top side of the board, far > enough from the FPGA that production can get their little optical > inspection gidget in there. Works fine. > > Is via in pad safe? Is solder slurping a serious issue? I'd sure like > to eliminate those dogbone things. > > John No first hand experience, but I'm told if the vias are plated shut there is no solder slurping. More interesting to me is the decoupling capacitor issue. I took a class on high speed digital design once and the instructor claimed decoupling caps do not need to be as close as possible to the chip to be effective when power and ground planes are used. In essence the planes provide the current the chip needs as the wave front propagates to the cap. Certainly the trace from the via to the cap should be as short as possible. I believe that is what you are saying works for your dense BGAs. He did also make a case for using multiple values of caps to minimize resonances in the power decoupling circuits. BTW, he didn't just hand wave this stuff. Everything he told us in class was analyzed in theory, simulated in software and then tested in hardware. Lee Ritchey of Speeding Edge consultants. RickArticle: 149646
On Nov 12, 6:27 pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein > > >Back to the OP's original topic: Yeah, these new packages are tough. > >Good thing itty-bitty ceramics come in large values, and thank the > >heavens for 'via in pad'. > > We just splatter a few 0603 caps on the top side of the board, far > enough from the FPGA that production can get their little optical > inspection gidget in there. Works fine. > > Is via in pad safe? Is solder slurping a serious issue? I'd sure like > to eliminate those dogbone things. > > John No first hand experience, but I'm told if the vias are plated shut there is no solder slurping. More interesting to me is the decoupling capacitor issue. I took a class on high speed digital design once and the instructor claimed decoupling caps do not need to be as close as possible to the chip to be effective when power and ground planes are used. In essence the planes provide the current the chip needs as the wave front propagates to the cap. Certainly the trace from the via to the cap should be as short as possible. I believe that is what you are saying works for your dense BGAs. He did also make a case for using multiple values of caps to minimize resonances in the power decoupling circuits. BTW, he didn't just hand wave this stuff. Everything he told us in class was analyzed in theory, simulated in software and then tested in hardware. Lee Ritchey of Speeding Edge consultants. RickArticle: 149647
On 11/12/2010 6:27 PM, John Larkin wrote: > On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein > <d_s_klein@yahoo.com> wrote: > >> On Nov 12, 6:19 am, 2cents<w...@sharonmccormack.com> wrote: >>> >>> I wouldn't rush a decision like that - especially when I know from a >>> very good source that there is a major effort underway to improve the >>> SW at Xilinx. >>> I hear there is a upcoming version of the SW that will be a big step >>> forward in terms of quality, speed, etc. So might be worth waiting a >>> while, especially if you are familiar with the silicon already. >> >> This grumpy old man says "Harrumph". >> >> Version 11 was NOT an improvement from version 10. I know of at least >> one design that works "just fine" when built with ISE-10, and fails to >> run with ISE-12. >> >> Version 12 is NOT an improvement over version 11. My current project >> works "just fine" with ISE-11, but ISE-12 fails to build a bit-stream. >> >> After two steps backward like this, I find your claim hard to believe. >> >> For what it's worth: I find it to be about the same level of >> difficulty to switch ISE<->Quartus as I find it to switch ISE-(n)<- >>> ISE-(n+1). And (with very few exceptions) by the time you get a >> feature out of Coregen/Megawizard, they all look the same. >> >> Back to the OP's original topic: Yeah, these new packages are tough. >> Good thing itty-bitty ceramics come in large values, and thank the >> heavens for 'via in pad'. > > We just splatter a few 0603 caps on the top side of the board, far > enough from the FPGA that production can get their little optical > inspection gidget in there. Works fine. > > Is via in pad safe? Is solder slurping a serious issue? I'd sure like > to eliminate those dogbone things. > > John > I've used via-in-pad (for fine pitch bga's you really don't have many choices) and haven't had a problem as long as you adhere to the guidelines and choose your fabricator and assembler wisely. Here is a nice white paper done by a fabricator we often use. http://www.sanmina-sci.com/Solutions/pdfs/pcbres/Impact_of_Microvia-in-pad_Design_on_Void_Formation.pdfArticle: 149648
On Fri, 12 Nov 2010 20:14:35 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >No first hand experience, but I'm told if the vias are plated shut >there is no solder slurping. Duh. Basic capillary attraction is the engine, so if the capillary is already filled, there will be no (less) attraction.Article: 149649
On Fri, 12 Nov 2010 20:11:09 -0800 (PST), rickman <gnuarm@gmail.com> wrote: >On Nov 12, 6:27 pm, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein >> >> >Back to the OP's original topic: Yeah, these new packages are tough. >> >Good thing itty-bitty ceramics come in large values, and thank the >> >heavens for 'via in pad'. >> >> We just splatter a few 0603 caps on the top side of the board, far >> enough from the FPGA that production can get their little optical >> inspection gidget in there. Works fine. >> >> Is via in pad safe? Is solder slurping a serious issue? I'd sure like >> to eliminate those dogbone things. >> >> John > >No first hand experience, but I'm told if the vias are plated shut >there is no solder slurping. > >More interesting to me is the decoupling capacitor issue. I took a >class on high speed digital design once and the instructor claimed >decoupling caps do not need to be as close as possible to the chip to >be effective when power and ground planes are used. In essence the >planes provide the current the chip needs as the wave front propagates >to the cap. Certainly the trace from the via to the cap should be as >short as possible. I believe that is what you are saying works for >your dense BGAs. Right. The plane sandwich is a great high-speed bypassing system. It needs help at lower frequencies, which is what the caps do. The caps don't need to be especially close the the FPGA. I know one guy who doesn't use bypass caps at all, and his stuff works. > >He did also make a case for using multiple values of caps to minimize >resonances in the power decoupling circuits. BTW, he didn't just hand >wave this stuff. Everything he told us in class was analyzed in >theory, simulated in software and then tested in hardware. Lee >Ritchey of Speeding Edge consultants. I do a lot of TDR testing on board traces and planes. Simulation is OK if you can model the planes accurately. A lot of what I've seen doesn't. All I use is 0.33 uF 0603s, a few per FPGA per supply voltage. And every board has worked fine so far, including digital delay generators that pass a signal in/out of an FPGA three or four times and pick up under 30 ps RMS jitter. John
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