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 7/30/2013 5:11 PM, Theo Markettos wrote: > already5chosen@yahoo.com wrote: >> If "nice" = 100 pin QFP, then yes, except for ancient Cyclone-I, Altera >> does not have anything nice. >> >> But if 144 pin QFP is also o.k. then there are relatively modern Cyclone >> III devices. Voltage and the rest is more or less the same as Xilinx. > > There's some Cyclone IVs in 144ish QFP too. I would love to use a 144 pin QFP, but they don't fit on the board. It is a very narrow daughtercard, only 0.85" wide and the 144 QFP is 0.86" wide without counting the pad over hang. A 17x17mm 256 BGA is the best of the rest so far. It has a 1 mm pitch although I haven't looked at what it takes to get vias between the balls. I expect I will need to be willing to push below the comfort zone of 6/6 mil space/trace and maybe below 10 mil drill. One nice thing about the 256 BGA is that I only need to reach the power and ground pins and the outer ring or two to get my 62 I/Os. I can ignore the rest of the balls. -- RickArticle: 155626
On 7/30/2013 3:50 PM, Jon Elson wrote: > rickman wrote: > > >> The Xilinx parts are interesting. Spartan 3 devices come in 100 QFPs >> and have enough of the "right stuff" inside including multipliers which >> I can use. But that external flash needs a spot on the board and I have >> to use a 1.2 volt regulator for the core. The XP parts use an internal >> regulator and run from 3.3 volts only. Xilinx has a rep for keeping >> parts in production for a long, long time, but the S3 line came out in >> 2005, same as the XP line. Spartan 6 parts give a *lot* more >> functionality, but I'd have to use a 256 pin 1.0 mm BGA *and* external >> flash *and* the 1.2 volt supply *and* they are twice the price. Maybe >> I'll talk to the disties. Maybe they can do something about the price >> at least. >> > Spartan 3AN has internal flash. I don't recall if there is a 100-pin > version, I am using the 144-pin version in a couple products. > I refuse to go to BGAs until there are no leaded parts remaining > available. No S3AN in 100 pin QFP, this may be because it is a dual die configuration or more likely they just don't expect to sell a lot of this size. I haven't bothered to check the price either. They do have a FTG256 which might do the job. I expect I can find the space for a very small 8 pin flash part if I go QFN. Again, I need to dig more. I've just started looking... Actually my main concern with the external flash is the whole JTAG programming at the factory and/or lab thing, but there are likely many ways to deal with that including having them programmed before assembly. It is just that I've been using these Flash FPGAs for some time now and I'm very used to them. -- RickArticle: 155627
On 7/30/2013 6:02 PM, Jon Elson wrote: > GaborSzakacs wrote: > > >> I'm pretty sure that the 144-pin package is the smallest with flash. >> In any case it's not a big win over an external SPI flash part. The >> difference in footprint between 100 TQFP and 144 TQFP is more than >> the flash footprint. Not to mention there's a price premium for that >> multi-die package. >> > Right, unless I have a pretty strong reason to use the 3AN, I use > the Spartan 3, and the SST flash chips, which are insanely cheap. > I wrote my own programmer code for those. Spartan 2E needed some > interface fooling around to command the memory to start dumping at > location zero, but the 3A knows how to do it by setting some config > pins. This is the stuff I'm concerned about with the external flash. But it is just a mater of figuring out how to do it and then doing that... Too bad I don't have space for an MCU. The design could use one, but if it happens it will be *inside* the FPGA. Just no board space at all. In fact, I'm skipping Altera for the moment and skipping over to MicroSemi and Cypress to see if their combination CPU/Logic devices might do the job well and let me eliminate the stereo CODEC to (another part that could go obsolete at any time). I seem to recall that the Cypress part might be just the ticket but the MicroSemi part runs some $50 at the low point. The current Lattice part is running under $10. Although, if the CODEC could be absorbed inside an MCU, there is some board space at that point, about 6.5mm sq. But how many MCUs can do 16 bit, CD quality audio on two channels? Maybe Analog Devices, but their MCU parts don't give me confidence in their longevity. It also has to read the external flash and dump it into the FPGA so those tiny audio DSPs are out. -- RickArticle: 155628
On Tuesday, July 30, 2013 5:01:28 AM UTC+2, ske...@gmail.com wrote: > Hi everyone. I'm trying to find out if, at high speeds, it is necessary t= o clock every other register using every other clock transition. For instan= ce, clocking every other register in a shift register using the positive cl= ock transition and the rest use the negative clock transition. This VHDL ma= y help explain: >=20 >=20 >=20 > I know this works at lower speeds: >=20 >=20 >=20 > if(clk'event and clk=3D'1')then >=20 > D <=3D C; >=20 > C <=3D B; >=20 > B <=3D A; >=20 > A <=3D input; >=20 > end if; >=20 >=20 >=20 > But I wonder if at higher speeds this sort of coding is required: >=20 >=20 >=20 > if(clk'event and clk=3D'1')then >=20 > D <=3D C; >=20 > B <=3D A; >=20 > end if >=20 > if(clk'event and clk=3D'0')then >=20 > C <=3D B; >=20 > A <=3D input; >=20 > end if; >=20 >=20 >=20 > That way, in my second example, "B" for instance captures it's data in th= e middle of "A's" data eye. Is this coding style required above some speed?= If so, does anyone know how to find out what that speed is or just tell me= some general approximate? no you shouldn't do that it doesn't gain anything, if anything it'll make t= hings slower.=20 in you example using both edges the output of A only has half as much time = to get to input of B so it will only be able to run half as fast FPGAs are generally designed so the clock arrives at all FFs at the same ti= me so all you need to check is if the path takes less time than a clock cycle = minus setup time and the hold time on FFs are zero or less so that paths can be arbitrarily = fast -LasseArticle: 155629
On Wednesday, July 31, 2013 12:40:20 AM UTC+2, rickman wrote: > On 7/30/2013 5:11 PM, Theo Markettos wrote: > > > already5chosen@yahoo.com wrote: > > >> If "nice" = 100 pin QFP, then yes, except for ancient Cyclone-I, Altera > > >> does not have anything nice. > > >> > > >> But if 144 pin QFP is also o.k. then there are relatively modern Cyclone > > >> III devices. Voltage and the rest is more or less the same as Xilinx. > > > > > > There's some Cyclone IVs in 144ish QFP too. > > > > I would love to use a 144 pin QFP, but they don't fit on the board. It > > is a very narrow daughtercard, only 0.85" wide and the 144 QFP is 0.86" > > wide without counting the pad over hang. A 17x17mm 256 BGA is the best > > of the rest so far. It has a 1 mm pitch although I haven't looked at > > what it takes to get vias between the balls. I expect I will need to be > > willing to push below the comfort zone of 6/6 mil space/trace and maybe > > below 10 mil drill. > http://bmc.bu.edu/bmc/asd/tester/xapp157.pdf says 6/6 and 12mil drill is doable -LasseArticle: 155630
> In fact, I'm skipping Altera for the moment If you have some reasonable time that you can bridge with your LTB parts, I think you should really contact your local Altera FAE to see if he has some news for you. Personally, I like Quartus the most by far when comparing it with the software from the other vendors (just look at SignalTap, for example). (I have no Vivado experience, however...) Regards, Thomas www.entner-electronics.comArticle: 155631
> and the hold time on FFs are zero or less so that paths can be arbitrarily fast > > -Lasse This I did not know. I feel like it should have come to me before now. Oh well. Thanks everyone!Article: 155632
On 7/30/2013 11:37 AM, rickman wrote: > Spartan 6 parts give a *lot* more functionality, but I'd have to use > a 256 pin 1.0 mm BGA *and* external flash *and* the 1.2 volt supply > *and* they are twice the price. Maybe I'll talk to the disties. > Maybe they can do something about the price at least. The smaller Spartan 6 parts do come in a 144 pin TQFP package. Too small? Rob.Article: 155633
rickman wrote: > No S3AN in 100 pin QFP, this may be because it is a dual die > configuration or more likely they just don't expect to sell a lot of > this size. I haven't bothered to check the price either. They do have > a FTG256 which might do the job. I expect I can find the space for a > very small 8 pin flash part if I go QFN. Again, I need to dig more. > I've just started looking... > The smallest Spartan 3A is under $10, the 3AN is about $15. > Actually my main concern with the external flash is the whole JTAG > programming at the factory and/or lab thing, but there are likely many > ways to deal with that including having them programmed before assembly. > It is just that I've been using these Flash FPGAs for some time now > and I'm very used to them. > The 3AN can be programmed by JTAG, the SST serial EPROM I use on the 3A is not JTAG, although a flexible programmer or tester could easily be "taught" the protocol. I chose this device so I could have field-replaceable firmware. I had to make an SO-8 to DIP converter board though, as the SST chip is only available in a couple SMT packages. JonArticle: 155634
On 7/30/2013 9:03 PM, Rob Doyle wrote: > On 7/30/2013 11:37 AM, rickman wrote: >> Spartan 6 parts give a *lot* more functionality, but I'd have to use >> a 256 pin 1.0 mm BGA *and* external flash *and* the 1.2 volt supply >> *and* they are twice the price. Maybe I'll talk to the disties. >> Maybe they can do something about the price at least. > > The smaller Spartan 6 parts do come in a 144 pin TQFP package. Too small? > > Rob. Apparently the 144 TQ package is too big (physically). And once you look at a 256-ball 1mm BGA you could find any number of devices including those from Lattice (XP2?). For internals, the smallest Spartan 6 is about the size of the original XP part he was using. As to price, we never pay anything near list for Xilinx parts, but we don't get the same steep discount on Spartan 6 as we do on other series. -- GaborArticle: 155635
On 7/30/2013 7:44 PM, langwadt@fonz.dk wrote: > On Wednesday, July 31, 2013 12:40:20 AM UTC+2, rickman wrote: >> On 7/30/2013 5:11 PM, Theo Markettos wrote: >> >>> already5chosen@yahoo.com wrote: >> >>>> If "nice" = 100 pin QFP, then yes, except for ancient Cyclone-I, Altera >> >>>> does not have anything nice. >> >>>> >> >>>> But if 144 pin QFP is also o.k. then there are relatively modern Cyclone >> >>>> III devices. Voltage and the rest is more or less the same as Xilinx. >> >>> >> >>> There's some Cyclone IVs in 144ish QFP too. >> >> >> >> I would love to use a 144 pin QFP, but they don't fit on the board. It >> >> is a very narrow daughtercard, only 0.85" wide and the 144 QFP is 0.86" >> >> wide without counting the pad over hang. A 17x17mm 256 BGA is the best >> >> of the rest so far. It has a 1 mm pitch although I haven't looked at >> >> what it takes to get vias between the balls. I expect I will need to be >> >> willing to push below the comfort zone of 6/6 mil space/trace and maybe >> >> below 10 mil drill. >> > > http://bmc.bu.edu/bmc/asd/tester/xapp157.pdf > > says 6/6 and 12mil drill is doable > > > -Lasse Thanks for the link, that saved me a little bother. But I'll still need to run through the calcs myself. A quick check says this works. Still, I'm not crazy about using a 256 ball part when I only need 62 I/O... lol Better than no choice at all. -- RickArticle: 155636
On 7/30/2013 9:50 PM, Jon Elson wrote: > rickman wrote: > > >> No S3AN in 100 pin QFP, this may be because it is a dual die >> configuration or more likely they just don't expect to sell a lot of >> this size. I haven't bothered to check the price either. They do have >> a FTG256 which might do the job. I expect I can find the space for a >> very small 8 pin flash part if I go QFN. Again, I need to dig more. >> I've just started looking... >> > The smallest Spartan 3A is under $10, the 3AN is about $15. > >> Actually my main concern with the external flash is the whole JTAG >> programming at the factory and/or lab thing, but there are likely many >> ways to deal with that including having them programmed before assembly. >> It is just that I've been using these Flash FPGAs for some time now >> and I'm very used to them. >> > The 3AN can be programmed by JTAG, the SST serial EPROM I use on > the 3A is not JTAG, although a flexible programmer or tester > could easily be "taught" the protocol. I chose this device > so I could have field-replaceable firmware. I had to make an > SO-8 to DIP converter board though, as the SST chip is only > available in a couple SMT packages. Yeah, I am supposed to provide JTAG programmability through the equipment this daughtercard is plugged into. That is, I provide the JTAG port, it is up to them to do the software to program it. That is one of my concerns with an external seral prom. May not be easy to do in an 8 pin package... But if they can learn the protocol, maybe that would work too. We'll see. After 5 years we still have not required this functionality. But I'll be pushing for increased capability in the new version to allow it to be sold into new areas. So remote updates may be more important then. -- RickArticle: 155637
On 7/30/2013 10:25 PM, Gabor wrote: > On 7/30/2013 9:03 PM, Rob Doyle wrote: >> On 7/30/2013 11:37 AM, rickman wrote: >>> Spartan 6 parts give a *lot* more functionality, but I'd have to use >>> a 256 pin 1.0 mm BGA *and* external flash *and* the 1.2 volt supply >>> *and* they are twice the price. Maybe I'll talk to the disties. >>> Maybe they can do something about the price at least. >> >> The smaller Spartan 6 parts do come in a 144 pin TQFP package. Too small? >> >> Rob. > > Apparently the 144 TQ package is too big (physically). And once you > look at a 256-ball 1mm BGA you could find any number of devices > including those from Lattice (XP2?). For internals, the smallest > Spartan 6 is about the size of the original XP part he was using. > > As to price, we never pay anything near list for Xilinx parts, but > we don't get the same steep discount on Spartan 6 as we do on other > series. There is some irony, the parts the smallest Spartan 6 comes in are *too* small in terms of ball pitch. They require PCB design rules down to 3/3 trace/space. To get a FTG256 BGA you have to bump up to the next size which is some four times bigger than the part I'm using now. It has nearly 6K LUTs and they are 6 input LUTs rather than 4 input. It also has tons of multipliers and RAM, so it is a *lot* more device. The Digikey price is about double too..., but that can be negotiable. -- RickArticle: 155638
On 7/30/2013 2:37 PM, rickman wrote: > > I have yet to check out the Altera line. I don't remember them having > anything I liked in a nice package. But that will be something to do > later today. I guess I should check out the Micro-Semi line as well. > It's been a while since I looked hard at their parts and, oh yeah, there > is the PSOC from Cypress. I don't think that was an option at the time I > did this design. I went to the Cypress web site and I can't find a data sheet on their PSOC parts. They also encrypt the info on the broad classes of devices behind marketing speak. So I can't even get a feel for what they are capable of. -- RickArticle: 155639
On 29/07/2013 22:14, rickman wrote: [] >> Everyone's old favorite asynchronous serial RS232 usually uses a >> clock at 16x, though I have seen 64x. From the beginning of the >> start bit, it counts half a bit time (in clock cycles), verifies >> the start bit (and not random noise) then counts whole bits and >> decodes at that point. So, the actual decoding is done with a 1X >> clock, but with 16 (or 64) possible phase values. It resynchronizes >> at the beginning of each character, so it can't get too far off. > > Yes, that protocol requires a clock matched to the senders clock to at > least 2.5% IIRC. The protocol the OP describes has much longer char > sequences which implies much tighter clock precision at each end and I'm > expecting it to use a clock recovery circuit... but maybe not. I think > he said they don't use one but get "frequent" errors. At the physical level the bit stuffing will allow to resync continuously therefore I'm not concerned if there's a clock recovery circuit. We are using 40MHz (0.5 ppm stability) but after few seconds you can already see how many cycles two clocks can drift apart. > I've never analyzed an async design with longer data streams so I don't > know how much precision would be required, but I"m sure you can't do > reliable data recovery with a 2x clock (without a pll). I think this > would contradict the Nyquist criterion. <neatpick mode on> Nyquist criterion has nothing to do with being able to sample data. As a matter of fact your internal clock is perfectly capable to sample data flowing in your fpga without the need to be 2x the data rate. <neatpick mode off> > In my earlier comments when I'm talking about a PLL I am referring to a > digital PLL. I guess I should have said a DPLL. Why bothering? If you have a PLL on your FPGA you can profit of it, otherwise you need something fancier.Article: 155640
On 30/07/2013 06:45, Richard Damon wrote: [] >> Uhm, since there's a sync pattern of '111' I have to assume that no >> frame is transmitted when only zeros are flowing (with the '1' stuffed >> every 6 zeros). > > My assumption for the protocol would be that between frames an "all > zero" pattern is sent. (note that this is on the layer above the raw > transport level, where every time 6 zeros are sent, a 1 is added). Thus > all frames will begin with three 1s in a row, as a signal for start of > frame (and also gives a lot of transitions to help lock the clock if > using a pll). A frame is defined as follows: - sync :'111' - header: dtype (4) - n.u.(2) - length (10) - data : (16) * length in principle between frames there can be any number of zeros (with bit stuffing). An 'all zero' pattern in this sense might be of any number of bits. [] >> I'm thinking about having a system clock multiplied internally via PLL >> and then go for a x4 or x8 in order to center the bit properly. > > I would think that sampling at 4x of the data rate is an minimum, faster > will give you better margins for frequency errors. So with a 20 MHz data > rate, you need to sample the data at 80 MHz, faster can help, and will > cause less jitter in your recovered data clock out. I also agree with you, no way a 2x would be sufficient to recover a phase shift. > > Note that the first level of processing will perform data detection and > clock recovery, and this might be where the 40 MHz came from, a 40 MHz > processing system can be told most of the time to take data every other > clock cycle, but have bandwidth to at times if the data is coming in > slightly faster to take data on two consecutive clocks. A 40 MHz would be sampling 2x, which is clearly not sufficient. > You don't want > to make this clock much faster than that, as then it becomes harder to > design for no benefit. Any higher speed bit detection clock needs to > have the results translated to this domain for further processing. (You > could also generate a recovered clock, but that starts you down the road > to an async design as the recovered clock isn't well related to your > existing clock, being a combinatorial result of registers clocked on > your sampling clock.) The deframed data (the data portion of the above mentioned frame structure) are going into a fifo, I think I can rework it to be a dual clock fifo to cross domain.Article: 155641
On 7/31/2013 3:36 AM, alb wrote: > On 29/07/2013 22:14, rickman wrote: > [] >>> Everyone's old favorite asynchronous serial RS232 usually uses a >>> clock at 16x, though I have seen 64x. From the beginning of the >>> start bit, it counts half a bit time (in clock cycles), verifies >>> the start bit (and not random noise) then counts whole bits and >>> decodes at that point. So, the actual decoding is done with a 1X >>> clock, but with 16 (or 64) possible phase values. It resynchronizes >>> at the beginning of each character, so it can't get too far off. >> >> Yes, that protocol requires a clock matched to the senders clock to at >> least 2.5% IIRC. The protocol the OP describes has much longer char >> sequences which implies much tighter clock precision at each end and I'm >> expecting it to use a clock recovery circuit... but maybe not. I think >> he said they don't use one but get "frequent" errors. > > At the physical level the bit stuffing will allow to resync continuously > therefore I'm not concerned if there's a clock recovery circuit. > > We are using 40MHz (0.5 ppm stability) but after few seconds you can > already see how many cycles two clocks can drift apart. > >> I've never analyzed an async design with longer data streams so I don't >> know how much precision would be required, but I"m sure you can't do >> reliable data recovery with a 2x clock (without a pll). I think this >> would contradict the Nyquist criterion. > > <neatpick mode on> > Nyquist criterion has nothing to do with being able to sample data. As a > matter of fact your internal clock is perfectly capable to sample data > flowing in your fpga without the need to be 2x the data rate. > <neatpick mode off> I don't know what you are talking about. If you asynchronously sample, you very much do have to satisfy the Nyquist criterion. A 2x clock, because it isn't *exactly* 2x, can *not* be used to capture a bitstream so that you can find the the transitions and know which bit is which. Otherwise there wouldn't be so many errors in the existing circuit. >> In my earlier comments when I'm talking about a PLL I am referring to a >> digital PLL. I guess I should have said a DPLL. > > Why bothering? If you have a PLL on your FPGA you can profit of it, > otherwise you need something fancier. Not sure of your context. You can't use the PLL on the FPGA to recover the clock from an arbitrary data stream. It is not designed for that and will not work because of the gaps in data transitions. It is designed to allow the multiplication of clock frequencies. A DPLL can be easily designed to recover the clock, but needs to be greater than 3x the data rate in order to distinguish the fast condition from the slow condition. You can use the FPGA PLL to multiply your clock from 2x to 4x to allow the DPLL to work correctly. -- RickArticle: 155642
On Tuesday, July 30, 2013 6:25:03 PM UTC-5, lang...@fonz.dk wrote: > and the hold time on FFs are zero or less so that paths can be=20 > arbitrarily fast=20 Zero (or less) hold time on FFs is not true for all FPGAs. It also does not= account for finite skew between clock arrival at different FFs, even using= a "global clock net". As to the original problem that the alternate-edge clocking scheme is presu= mably trying to solve, there is a one-clock-cycle delay between A & C. But = there are 2 t_setup and 2 t_clk2out times, since you are using an additiona= l register on the opposite clock edge between A and C. You would be better = off to perform the operations for B and C combinatorially in series between= A & C, without trying to use a register for B in between them. AndyArticle: 155643
[snip] > >A frame is defined as follows: > >- sync :'111' >- header: dtype (4) - n.u.(2) - length (10) >- data : (16) * length > >in principle between frames there can be any number of zeros (with bit >stuffing). An 'all zero' pattern in this sense might be of any number of >bits. > [snip] Unless 'length' is limited, your worst case has header "0000001111111111" (with an extra bit stuffed) followed by 16 * 1023 = 16368 zeros, which will have 2728 ones stuffed into them. Total line packet length is 19113 symbols. If the clocks are within 1/19114 of each other, the same number of symbols will be received as sent, ASSUMING no jitter. You can't assume that, but if there is 'not much' jitter then perhaps 1/100k will be good enough for relative drift to not need to be corrected for. So, for version 1, use the 'sync' to establish the start of frame and the sampling point, simulate the 'Rx fast' and 'Rx slow' cases in parallel, and see whether it works. BTW, this is off-topic for C.A.F., as it is a system design problem not related to the implementation method. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 155644
On Wednesday, July 31, 2013 2:39:03 PM UTC+2, jone...@comcast.net wrote: > On Tuesday, July 30, 2013 6:25:03 PM UTC-5, lang...@fonz.dk wrote: > > > and the hold time on FFs are zero or less so that paths can be > > > arbitrarily fast > > > > Zero (or less) hold time on FFs is not true for all FPGAs. It also does not account for finite skew between clock arrival at different FFs, even using a "global clock net". > then the tools better hide that if you want to use it for anything if you don't have zero hold you can't tell if the path between two FFs might happen to be less that the required hold and if you could what would you do? insert some dummy logic to add some delay? and if you can't assume the the skew is effectively zero how are you going to do a synchronous design? -LasseArticle: 155645
On Wednesday, July 31, 2013 1:44:17 PM UTC+2, rickman wrote: > On 7/31/2013 3:36 AM, alb wrote: > > > On 29/07/2013 22:14, rickman wrote: > > > [] > > >>> Everyone's old favorite asynchronous serial RS232 usually uses a > > >>> clock at 16x, though I have seen 64x. From the beginning of the > > >>> start bit, it counts half a bit time (in clock cycles), verifies > > >>> the start bit (and not random noise) then counts whole bits and > > >>> decodes at that point. So, the actual decoding is done with a 1X > > >>> clock, but with 16 (or 64) possible phase values. It resynchronizes > > >>> at the beginning of each character, so it can't get too far off. > > >> > > >> Yes, that protocol requires a clock matched to the senders clock to at > > >> least 2.5% IIRC. The protocol the OP describes has much longer char > > >> sequences which implies much tighter clock precision at each end and I'm > > >> expecting it to use a clock recovery circuit... but maybe not. I think > > >> he said they don't use one but get "frequent" errors. > > > > > > At the physical level the bit stuffing will allow to resync continuously > > > therefore I'm not concerned if there's a clock recovery circuit. > > > > > > We are using 40MHz (0.5 ppm stability) but after few seconds you can > > > already see how many cycles two clocks can drift apart. > > > > > >> I've never analyzed an async design with longer data streams so I don't > > >> know how much precision would be required, but I"m sure you can't do > > >> reliable data recovery with a 2x clock (without a pll). I think this > > >> would contradict the Nyquist criterion. > > > > > > <neatpick mode on> > > > Nyquist criterion has nothing to do with being able to sample data. As a > > > matter of fact your internal clock is perfectly capable to sample data > > > flowing in your fpga without the need to be 2x the data rate. > > > <neatpick mode off> > > > > I don't know what you are talking about. If you asynchronously sample, > > you very much do have to satisfy the Nyquist criterion. A 2x clock, > > because it isn't *exactly* 2x, can *not* be used to capture a bitstream > > so that you can find the the transitions and know which bit is which. > > Otherwise there wouldn't be so many errors in the existing circuit. > > > > > > >> In my earlier comments when I'm talking about a PLL I am referring to a > > >> digital PLL. I guess I should have said a DPLL. > > > > > > Why bothering? If you have a PLL on your FPGA you can profit of it, > > > otherwise you need something fancier. > > > > Not sure of your context. You can't use the PLL on the FPGA to recover > > the clock from an arbitrary data stream. It is not designed for that > > and will not work because of the gaps in data transitions. It is > > designed to allow the multiplication of clock frequencies. A DPLL can > > be easily designed to recover the clock, but needs to be greater than 3x > > the data rate in order to distinguish the fast condition from the slow > > condition. > > > > You can use the FPGA PLL to multiply your clock from 2x to 4x to allow > > the DPLL to work correctly. > or do like many USB PHYs, assume the 2x clock in reasonably 50/50 and use a DDR input flop to sample at 4x -LasseArticle: 155646
langwadt@fonz.dk wrote: (snip, someone wrote) >> Zero (or less) hold time on FFs is not true for all FPGAs. >> It also does not account for finite skew between clock >> arrival at different FFs, even using a "global clock net". > then the tools better hide that if you want to use it for anything > if you don't have zero hold you can't tell if the path between > two FFs might happen to be less that the required hold and if you > could what would you do? insert some dummy logic to add some delay? The FF's don't have to have zero hold time, they just have to have a hold time less than the shortest route between a previous FF. I remember in the TTL days, with zero hold time one could wire from one output pin to an input, such as Qbar to D. That was guaranteed to work. In the case of FGPAs, though, you have the FPGA routine fabric to go through. There will be a minimum length route. > and if you can't assume the the skew is effectively zero how > are you going to do a synchronous design? Well, again, if the clock skew plus hold time is less than the minimum length route, you won't notice it. For some FPGA families and tools, one can hand route at least some signals. If there was a possible route faster than skew plus hold, the data sheet should tell you about it. -- glenArticle: 155647
On Wednesday, July 31, 2013 9:22:53 PM UTC+2, glen herrmannsfeldt wrote: > langwadt@fonz.dk wrote: > > > > (snip, someone wrote) > > >> Zero (or less) hold time on FFs is not true for all FPGAs. > > >> It also does not account for finite skew between clock > > >> arrival at different FFs, even using a "global clock net". > > > > > then the tools better hide that if you want to use it for anything > > > > > if you don't have zero hold you can't tell if the path between > > > two FFs might happen to be less that the required hold and if you > > > could what would you do? insert some dummy logic to add some delay? > > > > The FF's don't have to have zero hold time, they just have to > > have a hold time less than the shortest route between a previous FF. > > > > I remember in the TTL days, with zero hold time one could wire > > from one output pin to an input, such as Qbar to D. That was > > guaranteed to work. > > > > In the case of FGPAs, though, you have the FPGA routine fabric > > to go through. There will be a minimum length route. > > > > > and if you can't assume the the skew is effectively zero how > > > are you going to do a synchronous design? > > > > Well, again, if the clock skew plus hold time is less than the > > minimum length route, you won't notice it. > > > > For some FPGA families and tools, one can hand route at least > > some signals. If there was a possible route faster than skew > > plus hold, the data sheet should tell you about it. > > > > -- glen what I mean isn't that hold and skew should literally have to be zero but it should be so that you can design as if it was and it is guaranteed to work -LasseArticle: 155648
rickman wrote: > On 7/30/2013 9:50 PM, Jon Elson wrote: >> rickman wrote: >> >>> >> The smallest Spartan 3A is under $10, the 3AN is about $15. >> >>> Actually my main concern with the external flash is the whole JTAG >>> programming at the factory and/or lab thing, but there are likely many >>> ways to deal with that including having them programmed before assembly. >>> It is just that I've been using these Flash FPGAs for some time now >>> and I'm very used to them. >>> >> The 3AN can be programmed by JTAG, the SST serial EPROM I use on >> the 3A is not JTAG, although a flexible programmer or tester >> could easily be "taught" the protocol. I chose this device >> so I could have field-replaceable firmware. I had to make an >> SO-8 to DIP converter board though, as the SST chip is only >> available in a couple SMT packages. > > Yeah, I am supposed to provide JTAG programmability through the > equipment this daughtercard is plugged into. That is, I provide the > JTAG port, it is up to them to do the software to program it. That is > one of my concerns with an external seral prom. May not be easy to do > in an 8 pin package... But if they can learn the protocol, maybe that > would work too. We'll see. After 5 years we still have not required > this functionality. But I'll be pushing for increased capability in the > new version to allow it to be sold into new areas. So remote updates > may be more important then. > Most recent parts from Xilinx including Spartan 3A have SPI master mode configuration, requiring nothing extra over the SPI flash itself and a handful of resistors. Indirect SPI flash programming over JTAG is supported by Impact, and you can generate SVF files to do the programming with an embedded processor. Also because the pins used for SPI config become I/O after config, you can use the SPI flash in your design, and possibly come up with a more "native" solution to field updates (without using JTAG). -- GaborArticle: 155649
On 7/31/2013 2:30 PM, langwadt@fonz.dk wrote: > On Wednesday, July 31, 2013 1:44:17 PM UTC+2, rickman wrote: >> >> You can use the FPGA PLL to multiply your clock from 2x to 4x to allow >> the DPLL to work correctly. >> > > or do like many USB PHYs, assume the 2x clock in reasonably 50/50 and use > a DDR input flop to sample at 4x Yes, that would be interesting to design actually, the logic gets two bits at the same time rather than one bit, I guess it makes the machine a bit more complicated in that you have to deal with four states and four possible input combinations. Still, not a big deal, just a bit of work on paper to understand the logic needed. -- Rick
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