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 11/23/2016 6:18 PM, Tim Wescott wrote: > On Wed, 23 Nov 2016 13:55:32 -0800, lasselangwadtchristensen wrote: > >> Den onsdag den 23. november 2016 kl. 20.56.00 UTC+1 skrev Tim Wescott: >>> On Wed, 23 Nov 2016 13:51:30 -0500, rickman wrote: >>> >>>> I use a Lattice LFXP3C-3TN100C on a production board that has been >>>> made for several years with quantities in the thousands. The >>>> HW-USBN-2A JTAG programmer typically works without complaint, both of >>>> them. One is a Lattice unit and the other is a Chinese knockoff. >>>> >>>> We are trying to finish a run of 600+ units and most have completed >>>> testing, but we have around 60 that can not be programmed. We get an >>>> error that the device ID can't be verified. The value returned is >>>> 0xFFFFFFFE while the expected value is 0x01255043. I would say there >>>> is a problem with a bad trace, but then I would expect *all* F's >>>> rather than just one bit being a zero. >>>> >>>> I've traced the signals and they are getting where they belong. >>>> Signals TDI and TMS are pulled up to 3.3 volts while TCK is not and >>>> only reaches 2.0 volts. I can see transitions on TDI with pulses in >>>> the microsecond range. This is the same with working boards. >>>> >>>> These chips only need Vcc, PROG_N high and the four JTAG signals, >>>> TMS, TCK, TDO and TDI to be connected in order to program them. We >>>> seem to have all that. >>>> >>>> Any ideas on what to check? The test fixture will program a good >>>> board just fine. But these 60 units can't even pass chip ID >>>> verification. I think I'm ready to replace the FPGA on one of them. >>> >>> Have you looked at the TDO line while the thing is ID-ing the chip? >>> Are you getting something that looks like 0x01255043 in there, or all >>> ones? If you can get your hands on one good and some bad boards you >>> should learn something. >>> >>> An exponentially decaying high voltage might come across as 0xfffffffe, >>> but I would expect that it would then sometimes come across as all 'f', >>> or sometimes as 0xfffffffc, 0xfffffff8, etc. >> >> or rising voltage if the data is sent LSB first > > Then it would be much easier to believe a reliable 0 LSB with all ones > following. BTW, thanks to everyone for the suggestions. :) -- Rick CArticle: 159501
On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote: > Here's an interesting synthesis result. I synthesized this with Vivado > for Virtex-7: > > reg [68:0] x; > reg x_neq_0; > always@(posedge clk) x_neq_0 <= x!=0; // version 1 > > Then I rephrased the logic: > > reg [68:0] x; > reg x_neq_0; > always@(posedge clk) x_neq_0 <= |x; // version 2 > > These should be the same, right? > > Version 1 uses 23 3-input LUTs on the first level followed by a 23-long > carry chain (6 CARRY4 blocks). This is twice as big as it should be. > > Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15 > total. > > Neither is optimal. What I really want is a combination, 12 6-input > LUTs followed by 3 CARRY4s. > > This is supposed to be the era of high-level synthesis... Reading this whole thread, I'm reminded of a gripe I have about the FPGA manufacturers, or at least Xilinx and Altera. If they -- or just any one of them -- would PUBLISH the details of how their bitfiles map to the workings of their FPGAs, then all of a sudden that company's stuff would be the subject of all the intensive university research on FPGA optimization that you might desire, and possibly even see an open-source tools ecology grow around its parts. It wouldn't immediately lead to nirvana, but it may at least lead to more and better optimization, and lots of people experimenting with different optimization approaches. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!Article: 159502
On 11/25/2016 4:26 PM, Tim Wescott wrote: > > Reading this whole thread, I'm reminded of a gripe I have about the FPGA > manufacturers, or at least Xilinx and Altera. > > If they -- or just any one of them -- would PUBLISH the details of how > their bitfiles map to the workings of their FPGAs, then all of a sudden > that company's stuff would be the subject of all the intensive university > research on FPGA optimization that you might desire, and possibly even > see an open-source tools ecology grow around its parts. > > It wouldn't immediately lead to nirvana, but it may at least lead to more > and better optimization, and lots of people experimenting with different > optimization approaches. Let's say I am Xilinx... I have a bazillion dollars of investment into my products and the support software. I sell to large companies who want reliable, consistent products. I open up my chip design and a bunch of university idealists start creating tools for my devices. The tools work to varying degrees and are used for a number of different designs by a wide variety of groups. So what happens when some of these groups report problems "with the chips"? Are these problems really with the chips or with the tools? If any of these groups ask us to deal with these problems, how do we begin? In other words, how do we keep these tools from causing problems with our reputation? -- Rick CArticle: 159503
On Fri, 25 Nov 2016 23:57:31 -0500, rickman wrote: > On 11/25/2016 4:26 PM, Tim Wescott wrote: >> >> Reading this whole thread, I'm reminded of a gripe I have about the >> FPGA manufacturers, or at least Xilinx and Altera. >> >> If they -- or just any one of them -- would PUBLISH the details of how >> their bitfiles map to the workings of their FPGAs, then all of a sudden >> that company's stuff would be the subject of all the intensive >> university research on FPGA optimization that you might desire, and >> possibly even see an open-source tools ecology grow around its parts. >> >> It wouldn't immediately lead to nirvana, but it may at least lead to >> more and better optimization, and lots of people experimenting with >> different optimization approaches. > > Let's say I am Xilinx... I have a bazillion dollars of investment into > my products and the support software. I sell to large companies who > want reliable, consistent products. I open up my chip design and a > bunch of university idealists start creating tools for my devices. The > tools work to varying degrees and are used for a number of different > designs by a wide variety of groups. > > So what happens when some of these groups report problems "with the > chips"? Are these problems really with the chips or with the tools? If > any of these groups ask us to deal with these problems, how do we begin? > > In other words, how do we keep these tools from causing problems with > our reputation? "You have reached the Xilinx automated help line. To ask about problems using our chips with unapproved tools, please hang up now..." But yes, I see your point. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!Article: 159504
On 25/11/16 21:26, Tim Wescott wrote: > On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote: > >> Here's an interesting synthesis result. I synthesized this with Vivado >> for Virtex-7: >> >> reg [68:0] x; >> reg x_neq_0; >> always@(posedge clk) x_neq_0 <= x!=0; // version 1 >> >> Then I rephrased the logic: >> >> reg [68:0] x; >> reg x_neq_0; >> always@(posedge clk) x_neq_0 <= |x; // version 2 >> >> These should be the same, right? >> >> Version 1 uses 23 3-input LUTs on the first level followed by a 23-long >> carry chain (6 CARRY4 blocks). This is twice as big as it should be. >> >> Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15 >> total. >> >> Neither is optimal. What I really want is a combination, 12 6-input >> LUTs followed by 3 CARRY4s. >> >> This is supposed to be the era of high-level synthesis... > > Reading this whole thread, I'm reminded of a gripe I have about the FPGA > manufacturers, or at least Xilinx and Altera. > > If they -- or just any one of them -- would PUBLISH the details of how > their bitfiles map to the workings of their FPGAs, then all of a sudden > that company's stuff would be the subject of all the intensive university > research on FPGA optimization that you might desire, and possibly even > see an open-source tools ecology grow around its parts. > > It wouldn't immediately lead to nirvana, but it may at least lead to more > and better optimization, and lots of people experimenting with different > optimization approaches. Many people have suggested that advantage. I presume the information will never be released because the information is - not part of an "API" that is guaranteed over time - highly proprietary, - highly device specific, - possibly varies and is corrected over time (Xilinx is good at suite updates) - only available in a form that is directly relevant to their design tools, i.e. tightly coupled) and hence is - difficult for someone else to interpret and process correctly - opens all sorts of cans of worms if a third party gets it wrong Analogy: Intel guarantee the "machine code API" of their processors, but the detailed internal structure is closely and varies significantly across processor generations.Article: 159505
On 11/25/16 4:26 PM, Tim Wescott wrote: > Reading this whole thread, I'm reminded of a gripe I have about the FPGA > manufacturers, or at least Xilinx and Altera. > > If they -- or just any one of them -- would PUBLISH the details of how > their bitfiles map to the workings of their FPGAs, then all of a sudden > that company's stuff would be the subject of all the intensive university > research on FPGA optimization that you might desire, and possibly even > see an open-source tools ecology grow around its parts. > > It wouldn't immediately lead to nirvana, but it may at least lead to more > and better optimization, and lots of people experimenting with different > optimization approaches. > The big issue is that much of the information that would be included in such a publication is information classified by the companies has highly competition sensitive. While companies document quite well the basic structure of the fundamental Logic Elements and I/O Blocks (and other special computational blocks), what is normally not well described, except in very general terms, is the routing. In many ways the routing is the secret sauce that will make or break a product line. If the routing is too weak, users will find they can't use a lot of the logic in the device (what they think they are paying for), too much routing and the chips get slower and too expensive (since building the routing IS a significant part of the cost of a device). To 'Open Source' the bitfiles, you be necessity need to explain and document how you configured your sparse routing matrix, which may well help your competitors next generation of products, at the cost of your future products.Article: 159506
> So what happens when some of these groups report problems "with the=20 > chips"? Are these problems really with the chips or with the tools? If= =20 > any of these groups ask us to deal with these problems, how do we begin? >=20 > In other words, how do we keep these tools from causing problems with=20 > our reputation? I can totally understand why Xilinx wouldn't want to mess with this. It's = a support nightmare and customers would definitely associate poor open-sour= ce software with the chips. I'm not even convinced that open-source tools = would be any better. At least, in the worst case, I can instantiate primitives, but I wish the t= ools gave me a little more ability to override bad decisions without doing = that. There are a lot of case in which I can do a better job but if I put = in KEEPs, the tools ignore them, leaving me little choice but to instantiat= e primitives. Another thing they could do is to have more synthesis direct= ives. There are lots of good structures in the hardware, such as F7-F9 mux= es, that the synthesizer almost refuses to use, and I can only make use of = by using primitives. Perhaps a directive would allow me to infer a mux but= to force (*USE_F7*). And the built-in FIFOs: why can't I infer them? Preferably using the push= /pop keywords from SystemVerilog. That is the kind of "high-level synthesi= s" I am looking for: to not have to write structural HDL. These kinds of = incremental changes to their tools would be far more useful than their HLS = or AccelDSP or whatever. I wish, after working on this since 1984, they had more solid synthesis. T= here is supposed to be an intermediate layer between language-parsing and s= ynthesis to primitives. When I write the same logic in two slightly differ= ent ways and get totally different primitives, I know that something is klu= dged. When I have to DeMorganize by hand to get better synthesis something= is wrong. I am being paid to work out complex problems in Galois arithmet= ic, not to do freshman-level Boolean logic.Article: 159507
Tom Gardner <spamjunk@blueyonder.co.uk> wrote: > Analogy: Intel guarantee the "machine code API" of > their processors, but the detailed internal structure > is closely and varies significantly across processor > generations. There is indeed work going on into FPGA 'virtualisation' - creating vendor-neutral intermediate structures that open tools can compile down to, that either vendor tools can pick up and compile or will map to some pre-synthesised FPGA-on-FPGA. I'm not sure if there's anything near mainstream, but I can see it's going to become increasingly relevant - if Microsoft have a datacentre containing a mix of Virtex 6, Virtex 7, Ultrascale, Stratix V, Stratix 10, ... FPGAs, based on whatever models were cheap when they bought that batch of servers, the number of images that needs to be supported will start multiplying and so an 'ISA' for FPGAs would help the heterogeneity problem. TheoArticle: 159508
rickman wrote: > I use a Lattice LFXP3C-3TN100C on a production board that has been made > for several years with quantities in the thousands. The HW-USBN-2A JTAG > programmer typically works without complaint, both of them. One is a > Lattice unit and the other is a Chinese knockoff. > > We are trying to finish a run of 600+ units and most have completed > testing, but we have around 60 that can not be programmed. We get an > error that the device ID can't be verified. The value returned is > 0xFFFFFFFE while the expected value is 0x01255043. I would say there is > a problem with a bad trace, but then I would expect *all* F's rather > than just one bit being a zero. > All F's indicate a level problem on the data line(s) to me. Check termination and levels - or watch it with a very high Z scope if you can get the triggering right. Adding a scope Heisenbergs the circuit but that may offer inspiration in solutions. > I've traced the signals and they are getting where they belong. Signals > TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches > 2.0 volts. I can see transitions on TDI with pulses in the microsecond > range. This is the same with working boards. > Are these inherently 3 volt parts? If not, ithe corcuit is overterminated. > These chips only need Vcc, PROG_N high and the four JTAG signals, TMS, > TCK, TDO and TDI to be connected in order to program them. We seem to > have all that. > > Any ideas on what to check? The test fixture will program a good board > just fine. But these 60 units can't even pass chip ID verification. I > think I'm ready to replace the FPGA on one of them. > -- Les CargillArticle: 159509
On 11/27/2016 1:57 PM, Les Cargill wrote: > rickman wrote: >> I use a Lattice LFXP3C-3TN100C on a production board that has been made >> for several years with quantities in the thousands. The HW-USBN-2A JTAG >> programmer typically works without complaint, both of them. One is a >> Lattice unit and the other is a Chinese knockoff. >> >> We are trying to finish a run of 600+ units and most have completed >> testing, but we have around 60 that can not be programmed. We get an >> error that the device ID can't be verified. The value returned is >> 0xFFFFFFFE while the expected value is 0x01255043. I would say there is >> a problem with a bad trace, but then I would expect *all* F's rather >> than just one bit being a zero. >> > > > All F's indicate a level problem on the data line(s) to me. Check > termination and levels - or watch it with a very high Z scope if you > can get the triggering right. The return data wasn't all 1s. It was all 1s other than a single bit which was zero. All ones can have multiple problems. The output is one. TCK not getting to the chip is another. Funny thing... I did a Google search on 0xFFFFFFFE and found my own reply to someone else having a similar problem. In the end he simply had an unknown connection issue which cleared up while fiddling with it all. Seems the 0xFFFFFFFE result is a common problem when the cabling is not right. In this case it was the TDI signal. > Adding a scope Heisenbergs the circuit but that may offer inspiration > in solutions. > >> I've traced the signals and they are getting where they belong. Signals >> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches >> 2.0 volts. I can see transitions on TDI with pulses in the microsecond >> range. This is the same with working boards. >> > > Are these inherently 3 volt parts? If not, ithe corcuit is overterminated. Not sure what you intended to say here. But I forgot to mention that another issue that confused the debug was a difference between the Lattice programming adapter and the Chinese device I bought a while back and has been working ok. Seems the Chinese programmer only pulls the outputs to around 2 volts leaving no voltage margin in the worst case. I only see this on one signal as the others are pulled high. TCK is pulled low as recommended by some reference I encountered a long time ago. This prevents the single rising edge that would be detected on power up. A 4.7K resistor shouldn't be a problem for any decent device, but obviously chip in the Chinese programmer isn't a "decent device". So seeing the 2 volt Vhi on just one pin made me look at the test board to see what was holding it low. lol -- Rick CArticle: 159510
rickman wrote: > On 11/27/2016 1:57 PM, Les Cargill wrote: >> rickman wrote: >>> I use a Lattice LFXP3C-3TN100C on a production board that has been made >>> for several years with quantities in the thousands. The HW-USBN-2A JTAG >>> programmer typically works without complaint, both of them. One is a >>> Lattice unit and the other is a Chinese knockoff. >>> >>> We are trying to finish a run of 600+ units and most have completed >>> testing, but we have around 60 that can not be programmed. We get an >>> error that the device ID can't be verified. The value returned is >>> 0xFFFFFFFE while the expected value is 0x01255043. I would say there is >>> a problem with a bad trace, but then I would expect *all* F's rather >>> than just one bit being a zero. >>> >> >> >> All F's indicate a level problem on the data line(s) to me. Check >> termination and levels - or watch it with a very high Z scope if you >> can get the triggering right. > > The return data wasn't all 1s. It was all 1s other than a single bit > which was zero. All ones can have multiple problems. The output is > one. TCK not getting to the chip is another. > Sorry; my visual cortex returned all 1s for the 0xFFFFFFFE .... :) > Funny thing... I did a Google search on 0xFFFFFFFE and found my own > reply to someone else having a similar problem. In the end he simply > had an unknown connection issue which cleared up while fiddling with it > all. Seems the 0xFFFFFFFE result is a common problem when the cabling > is not right. In this case it was the TDI signal. > That's a scream. Woohoo! Fixed. > >> Adding a scope Heisenbergs the circuit but that may offer inspiration >> in solutions. >> >>> I've traced the signals and they are getting where they belong. Signals >>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches >>> 2.0 volts. I can see transitions on TDI with pulses in the microsecond >>> range. This is the same with working boards. >>> >> >> Are these inherently 3 volt parts? If not, ithe corcuit is >> overterminated. > > Not sure what you intended to say here. R(termination) too low. Not enough current, IOW... > But I forgot to mention that > another issue that confused the debug was a difference between the > Lattice programming adapter and the Chinese device I bought a while back > and has been working ok. Seems the Chinese programmer only pulls the > outputs to around 2 volts leaving no voltage margin in the worst case. I > only see this on one signal as the others are pulled high. TCK is > pulled low as recommended by some reference I encountered a long time > ago. This prevents the single rising edge that would be detected on > power up. A 4.7K resistor shouldn't be a problem for any decent device, > but obviously chip in the Chinese programmer isn't a "decent device". > Yuck. > So seeing the 2 volt Vhi on just one pin made me look at the test board > to see what was holding it low. lol > > :) -- Les CargillArticle: 159511
rickman wrote: > On 11/27/2016 1:57 PM, Les Cargill wrote: >> rickman wrote: >>> I use a Lattice LFXP3C-3TN100C on a production board that has been made >>> for several years with quantities in the thousands. The HW-USBN-2A JTAG >>> programmer typically works without complaint, both of them. One is a >>> Lattice unit and the other is a Chinese knockoff. >>> >>> We are trying to finish a run of 600+ units and most have completed >>> testing, but we have around 60 that can not be programmed. We get an >>> error that the device ID can't be verified. The value returned is >>> 0xFFFFFFFE while the expected value is 0x01255043. I would say there is >>> a problem with a bad trace, but then I would expect *all* F's rather >>> than just one bit being a zero. >>> >> >> >> All F's indicate a level problem on the data line(s) to me. Check >> termination and levels - or watch it with a very high Z scope if you >> can get the triggering right. > > The return data wasn't all 1s. It was all 1s other than a single bit > which was zero. All ones can have multiple problems. The output is > one. TCK not getting to the chip is another. > > Funny thing... I did a Google search on 0xFFFFFFFE and found my own > reply to someone else having a similar problem. In the end he simply > had an unknown connection issue which cleared up while fiddling with it > all. Seems the 0xFFFFFFFE result is a common problem when the cabling > is not right. In this case it was the TDI signal. > > >> Adding a scope Heisenbergs the circuit but that may offer inspiration >> in solutions. >> >>> I've traced the signals and they are getting where they belong. Signals >>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches >>> 2.0 volts. I can see transitions on TDI with pulses in the microsecond >>> range. This is the same with working boards. >>> >> >> Are these inherently 3 volt parts? If not, ithe corcuit is >> overterminated. > > Not sure what you intended to say here. But I forgot to mention that > another issue that confused the debug was a difference between the > Lattice programming adapter and the Chinese device I bought a while back > and has been working ok. Seems the Chinese programmer only pulls the > outputs to around 2 volts leaving no voltage margin in the worst case. I > only see this on one signal as the others are pulled high. TCK is > pulled low as recommended by some reference I encountered a long time > ago. This prevents the single rising edge that would be detected on > power up. A 4.7K resistor shouldn't be a problem for any decent device, > but obviously chip in the Chinese programmer isn't a "decent device". > > So seeing the 2 volt Vhi on just one pin made me look at the test board > to see what was holding it low. lol > > Maybe the Chinese programmer uses an open-drain output with a pull-up to Vref rather than powering an active driver with Vref? It would be very strange for an active driver to limit its output to 2V with only 4.7K pulling down (426uA nominal). -- GaborArticle: 159512
On 11/29/2016 9:01 AM, GaborSzakacs wrote: > rickman wrote: >> On 11/27/2016 1:57 PM, Les Cargill wrote: >>> rickman wrote: >>>> I use a Lattice LFXP3C-3TN100C on a production board that has been made >>>> for several years with quantities in the thousands. The HW-USBN-2A >>>> JTAG >>>> programmer typically works without complaint, both of them. One is a >>>> Lattice unit and the other is a Chinese knockoff. >>>> >>>> We are trying to finish a run of 600+ units and most have completed >>>> testing, but we have around 60 that can not be programmed. We get an >>>> error that the device ID can't be verified. The value returned is >>>> 0xFFFFFFFE while the expected value is 0x01255043. I would say >>>> there is >>>> a problem with a bad trace, but then I would expect *all* F's rather >>>> than just one bit being a zero. >>>> >>> >>> >>> All F's indicate a level problem on the data line(s) to me. Check >>> termination and levels - or watch it with a very high Z scope if you >>> can get the triggering right. >> >> The return data wasn't all 1s. It was all 1s other than a single bit >> which was zero. All ones can have multiple problems. The output is >> one. TCK not getting to the chip is another. >> >> Funny thing... I did a Google search on 0xFFFFFFFE and found my own >> reply to someone else having a similar problem. In the end he simply >> had an unknown connection issue which cleared up while fiddling with >> it all. Seems the 0xFFFFFFFE result is a common problem when the >> cabling is not right. In this case it was the TDI signal. >> >> >>> Adding a scope Heisenbergs the circuit but that may offer inspiration >>> in solutions. >>> >>>> I've traced the signals and they are getting where they belong. >>>> Signals >>>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only >>>> reaches >>>> 2.0 volts. I can see transitions on TDI with pulses in the microsecond >>>> range. This is the same with working boards. >>>> >>> >>> Are these inherently 3 volt parts? If not, ithe corcuit is >>> overterminated. >> >> Not sure what you intended to say here. But I forgot to mention that >> another issue that confused the debug was a difference between the >> Lattice programming adapter and the Chinese device I bought a while >> back and has been working ok. Seems the Chinese programmer only pulls >> the outputs to around 2 volts leaving no voltage margin in the worst >> case. I only see this on one signal as the others are pulled high. >> TCK is pulled low as recommended by some reference I encountered a >> long time ago. This prevents the single rising edge that would be >> detected on power up. A 4.7K resistor shouldn't be a problem for any >> decent device, but obviously chip in the Chinese programmer isn't a >> "decent device". >> >> So seeing the 2 volt Vhi on just one pin made me look at the test >> board to see what was holding it low. lol >> >> > > Maybe the Chinese programmer uses an open-drain output with a pull-up > to Vref rather than powering an active driver with Vref? It would be > very strange for an active driver to limit its output to 2V with only > 4.7K pulling down (426uA nominal). I'm not sure what circuit you are imagining. What you call Vref is Vcc from the unit under test, which is 3.3 volts in the case. Also, passive pullup/down is very slow compared to the logic it is driving. That is a great way to create noise in your circuit. I can only assume there is something between the Vcc in and the driver, perhaps a protection circuit. The 2 volts was measured with no load other than the voltmeter. -- Rick CArticle: 159513
rickman wrote: > On 11/29/2016 9:01 AM, GaborSzakacs wrote: >> rickman wrote: >>> On 11/27/2016 1:57 PM, Les Cargill wrote: >>>> rickman wrote: >>>>> I use a Lattice LFXP3C-3TN100C on a production board that has been >>>>> made >>>>> for several years with quantities in the thousands. The HW-USBN-2A >>>>> JTAG >>>>> programmer typically works without complaint, both of them. One is a >>>>> Lattice unit and the other is a Chinese knockoff. >>>>> >>>>> We are trying to finish a run of 600+ units and most have completed >>>>> testing, but we have around 60 that can not be programmed. We get an >>>>> error that the device ID can't be verified. The value returned is >>>>> 0xFFFFFFFE while the expected value is 0x01255043. I would say >>>>> there is >>>>> a problem with a bad trace, but then I would expect *all* F's rather >>>>> than just one bit being a zero. >>>>> >>>> >>>> >>>> All F's indicate a level problem on the data line(s) to me. Check >>>> termination and levels - or watch it with a very high Z scope if you >>>> can get the triggering right. >>> >>> The return data wasn't all 1s. It was all 1s other than a single bit >>> which was zero. All ones can have multiple problems. The output is >>> one. TCK not getting to the chip is another. >>> >>> Funny thing... I did a Google search on 0xFFFFFFFE and found my own >>> reply to someone else having a similar problem. In the end he simply >>> had an unknown connection issue which cleared up while fiddling with >>> it all. Seems the 0xFFFFFFFE result is a common problem when the >>> cabling is not right. In this case it was the TDI signal. >>> >>> >>>> Adding a scope Heisenbergs the circuit but that may offer inspiration >>>> in solutions. >>>> >>>>> I've traced the signals and they are getting where they belong. >>>>> Signals >>>>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only >>>>> reaches >>>>> 2.0 volts. I can see transitions on TDI with pulses in the >>>>> microsecond >>>>> range. This is the same with working boards. >>>>> >>>> >>>> Are these inherently 3 volt parts? If not, ithe corcuit is >>>> overterminated. >>> >>> Not sure what you intended to say here. But I forgot to mention that >>> another issue that confused the debug was a difference between the >>> Lattice programming adapter and the Chinese device I bought a while >>> back and has been working ok. Seems the Chinese programmer only pulls >>> the outputs to around 2 volts leaving no voltage margin in the worst >>> case. I only see this on one signal as the others are pulled high. >>> TCK is pulled low as recommended by some reference I encountered a >>> long time ago. This prevents the single rising edge that would be >>> detected on power up. A 4.7K resistor shouldn't be a problem for any >>> decent device, but obviously chip in the Chinese programmer isn't a >>> "decent device". >>> >>> So seeing the 2 volt Vhi on just one pin made me look at the test >>> board to see what was holding it low. lol >>> >>> >> >> Maybe the Chinese programmer uses an open-drain output with a pull-up >> to Vref rather than powering an active driver with Vref? It would be >> very strange for an active driver to limit its output to 2V with only >> 4.7K pulling down (426uA nominal). > > I'm not sure what circuit you are imagining. What you call Vref is Vcc > from the unit under test, which is 3.3 volts in the case. Also, passive > pullup/down is very slow compared to the logic it is driving. That is a > great way to create noise in your circuit. > > I can only assume there is something between the Vcc in and the driver, > perhaps a protection circuit. The 2 volts was measured with no load > other than the voltmeter. > I think you imagined it right. It wouldn't be a good way to drive TCK. Another possibility is that they used an active drive dircuit at some higher voltage (3.3V or more) and then connect via a simple FET-based level shifter like the old QuickSwitch parts. Then the active drive would only go up to the point where the FET starts to turn off because its source gets within Vgth of Vref. You'd need a pullup to get the signal beyond that point. Your weak pulldown would fight that pullup and limit the high drive. In any case it seems an odd way to build a programmer, given the easy availability of LVCMOS buffers that can work at low voltage while taking up to 5V on their inputs. -- GaborArticle: 159514
On 11/29/2016 2:06 PM, GaborSzakacs wrote: > rickman wrote: >> On 11/29/2016 9:01 AM, GaborSzakacs wrote: >>> rickman wrote: >>>> On 11/27/2016 1:57 PM, Les Cargill wrote: >>>>> rickman wrote: >>>>>> I use a Lattice LFXP3C-3TN100C on a production board that has been >>>>>> made >>>>>> for several years with quantities in the thousands. The HW-USBN-2A >>>>>> JTAG >>>>>> programmer typically works without complaint, both of them. One is a >>>>>> Lattice unit and the other is a Chinese knockoff. >>>>>> >>>>>> We are trying to finish a run of 600+ units and most have completed >>>>>> testing, but we have around 60 that can not be programmed. We get an >>>>>> error that the device ID can't be verified. The value returned is >>>>>> 0xFFFFFFFE while the expected value is 0x01255043. I would say >>>>>> there is >>>>>> a problem with a bad trace, but then I would expect *all* F's rather >>>>>> than just one bit being a zero. >>>>>> >>>>> >>>>> >>>>> All F's indicate a level problem on the data line(s) to me. Check >>>>> termination and levels - or watch it with a very high Z scope if you >>>>> can get the triggering right. >>>> >>>> The return data wasn't all 1s. It was all 1s other than a single bit >>>> which was zero. All ones can have multiple problems. The output is >>>> one. TCK not getting to the chip is another. >>>> >>>> Funny thing... I did a Google search on 0xFFFFFFFE and found my own >>>> reply to someone else having a similar problem. In the end he simply >>>> had an unknown connection issue which cleared up while fiddling with >>>> it all. Seems the 0xFFFFFFFE result is a common problem when the >>>> cabling is not right. In this case it was the TDI signal. >>>> >>>> >>>>> Adding a scope Heisenbergs the circuit but that may offer inspiration >>>>> in solutions. >>>>> >>>>>> I've traced the signals and they are getting where they belong. >>>>>> Signals >>>>>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only >>>>>> reaches >>>>>> 2.0 volts. I can see transitions on TDI with pulses in the >>>>>> microsecond >>>>>> range. This is the same with working boards. >>>>>> >>>>> >>>>> Are these inherently 3 volt parts? If not, ithe corcuit is >>>>> overterminated. >>>> >>>> Not sure what you intended to say here. But I forgot to mention that >>>> another issue that confused the debug was a difference between the >>>> Lattice programming adapter and the Chinese device I bought a while >>>> back and has been working ok. Seems the Chinese programmer only pulls >>>> the outputs to around 2 volts leaving no voltage margin in the worst >>>> case. I only see this on one signal as the others are pulled high. >>>> TCK is pulled low as recommended by some reference I encountered a >>>> long time ago. This prevents the single rising edge that would be >>>> detected on power up. A 4.7K resistor shouldn't be a problem for any >>>> decent device, but obviously chip in the Chinese programmer isn't a >>>> "decent device". >>>> >>>> So seeing the 2 volt Vhi on just one pin made me look at the test >>>> board to see what was holding it low. lol >>>> >>>> >>> >>> Maybe the Chinese programmer uses an open-drain output with a pull-up >>> to Vref rather than powering an active driver with Vref? It would be >>> very strange for an active driver to limit its output to 2V with only >>> 4.7K pulling down (426uA nominal). >> >> I'm not sure what circuit you are imagining. What you call Vref is >> Vcc from the unit under test, which is 3.3 volts in the case. Also, >> passive pullup/down is very slow compared to the logic it is driving. >> That is a great way to create noise in your circuit. >> >> I can only assume there is something between the Vcc in and the >> driver, perhaps a protection circuit. The 2 volts was measured with >> no load other than the voltmeter. >> > > I think you imagined it right. It wouldn't be a good way to drive TCK. > Another possibility is that they used an active drive dircuit at some > higher voltage (3.3V or more) and then connect via a simple FET-based > level shifter like the old QuickSwitch parts. Then the active drive > would only go up to the point where the FET starts to turn off because > its source gets within Vgth of Vref. You'd need a pullup to get the > signal beyond that point. Your weak pulldown would fight that pullup > and limit the high drive. In any case it seems an odd way to build > a programmer, given the easy availability of LVCMOS buffers that can > work at low voltage while taking up to 5V on their inputs. Once we get this batch of boards out the door, I will get both programmers back and do a teardown to see what they use. I thought the Chinese programmer was a copy, but I've noticed it does not produce the same signals on the JTAG interface when failing. I haven't tried to compare the signals when it works ok. -- Rick CArticle: 159515
Kevin Neilson <kevin.neilson@xilinx.com> wrote: >> I'm not enough of an FPGA guy to make really deep comments, but this >> looks like the state of C compilers about 20 or so years ago. When I >> started coding in C one had to write the code with an eye to the assembly >> that the thing was spitting out. Now, if you've got a good optimizer >> (and the gnu C optimizer is better than I am on all but a very few of the >> processors I've worked with recently), you just express your intent and >> the compiler makes it happen most efficiently. >> > I know! I often feel like I'm a software guy, but stuck in the 80s, > poring over every line generated by the assembler to make sure it's optimized. There is an IEEE standard for synthesizable VHDL. https://standards.ieee.org/findstds/standard/1076.6-2004.html But is *is* like writing C per-ANSI, when every compiler had its own variant. -- mac the nafArticle: 159516
In article <1973855991.502148597.323655.acolvin-efunct.com@news.eternal-september.org>, mac <acolvin@efunct.com> wrote: >Kevin Neilson <kevin.neilson@xilinx.com> wrote: >>> I'm not enough of an FPGA guy to make really deep comments, but this >>> looks like the state of C compilers about 20 or so years ago. When I >>> started coding in C one had to write the code with an eye to the assembly >>> that the thing was spitting out. Now, if you've got a good optimizer >>> (and the gnu C optimizer is better than I am on all but a very few of the >>> processors I've worked with recently), you just express your intent and >>> the compiler makes it happen most efficiently. >>> >> I know! I often feel like I'm a software guy, but stuck in the 80s, >> poring over every line generated by the assembler to make sure it's optimized. > > >There is an IEEE standard for synthesizable VHDL. >https://standards.ieee.org/findstds/standard/1076.6-2004.html > >But is *is* like writing C per-ANSI, when every compiler had its own >variant. There's a IEEE standard for the synthesizeable subset of Verilog-2001 too: (IEEE 1364.1 - 2002) I know it well, as I contributed to it. It's a shame they never did one for SystemVerilog. It was suggested, but some internal politicking on the working group struck it down. It's left us with a hit-and-miss method of finding the least common ground between toolsets. We're actively struggling with this now. But this doesn't change Kevin's observations much. Defining what the tool should accept, still gives the tool a LOT of leeway on HOW to build it - as Kevin's shown with this example. After all, all implementions shown in this example are "correct". Some are just more optimal than others (and like always the definition of "optimal" isn't concrete...) Regards, MarkArticle: 159517
Emulating an SD card in FPGA - with =E2=80=9Cdata=E2=80=9D stored over USB = on host PC. =20 I=E2=80=99m testing single board computers and wearing out SD card by const= antly flashing them with different builds, not to mention it tiring to keep= swapping cards in & out. So I=E2=80=99d like to emulate and SD card and = =E2=80=9Cstore=E2=80=9D the data on a host pc connected via USB. =20 Diagram: =20 microSD interface <=E2=80=94 FPGA =E2=80=94> USB <=E2=80=94=E2=80=94> Host = computer with SSD storage =20 I will be using the SD 4-bit interface and would like to hit transfer speed= s > 50MB/s, the clock should be ~100Mhz. =20 Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have those r= ight now, something more purpose specific and cheaper would be helpful to k= now as well.Article: 159518
On 11/30/2016 4:49 PM, Sri G wrote: > Emulating an SD card in FPGA - with “data” stored over USB on host PC. > > I’m testing single board computers and wearing out SD card by constantly flashing them with different builds, not to mention it tiring to keep swapping cards in & out. So I’d like to emulate and SD card and “store” the data on a host pc connected via USB. > > Diagram: > > microSD interface <— FPGA —> USB <——> Host computer with SSD storage > > I will be using the SD 4-bit interface and would like to hit transfer speeds > 50MB/s, the clock should be ~100Mhz. > > Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have those right now, something more purpose specific and cheaper would be helpful to know as well. I did a little search and found a hackaday page on this by antti.lukats. I have seen him around here before talking about his interesting projects. The hackaday page doesn't seem to include files or even any detail, just a photo. If you can get in touch with him, I expect he could share his HDL and maybe some of his thoughts. Interesting project. Is an SD card dimensions compatible with a standard 0.062 inch thick PCB? I can find that the SD card is 0.083 inches thick (2.1 mm) I believe the pins are recessed with raised sections between them making the contact area a different thickness. On the other hand, SD is not really an open spec. Can you use USB flash memory instead? That should be a lot easier to interface to. -- Rick CArticle: 159519
On 11/30/2016 6:05 PM, rickman wrote: > On 11/30/2016 4:49 PM, Sri G wrote: >> Emulating an SD card in FPGA - with “data” stored over USB on host PC. >> >> I’m testing single board computers and wearing out SD card by >> constantly flashing them with different builds, not to mention it >> tiring to keep swapping cards in & out. So I’d like to emulate and SD >> card and “store” the data on a host pc connected via USB. >> >> Diagram: >> >> microSD interface <— FPGA —> USB <——> Host computer with SSD storage >> >> I will be using the SD 4-bit interface and would like to hit transfer >> speeds > 50MB/s, the clock should be ~100Mhz. >> >> Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have >> those right now, something more purpose specific and cheaper would be >> helpful to know as well. > > I did a little search and found a hackaday page on this by antti.lukats. > I have seen him around here before talking about his interesting > projects. The hackaday page doesn't seem to include files or even any > detail, just a photo. If you can get in touch with him, I expect he > could share his HDL and maybe some of his thoughts. > > Interesting project. Is an SD card dimensions compatible with a > standard 0.062 inch thick PCB? I can find that the SD card is 0.083 > inches thick (2.1 mm) I believe the pins are recessed with raised > sections between them making the contact area a different thickness. > > On the other hand, SD is not really an open spec. Can you use USB flash > memory instead? That should be a lot easier to interface to. Forgot the link... https://hackaday.io/project/6946-sd-card-emulator-lattice-xp -- Rick CArticle: 159520
rickman <gnuarm@gmail.com> wrote: > On 11/30/2016 4:49 PM, Sri G wrote: > > Emulating an SD card in FPGA - with “data” stored over USB on host PC. > > > > I’m testing single board computers and wearing out SD card by constantly > > flashing them with different builds, not to mention it tiring to keep > > swapping cards in & out. So I’d like to emulate and SD card and “store” > > the data on a host pc connected via USB. > > > > Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have > > those right now, something more purpose specific and cheaper would be > > helpful to know as well. > > I did a little search and found a hackaday page on this by antti.lukats. > I have seen him around here before talking about his interesting > projects. The hackaday page doesn't seem to include files or even any > detail, just a photo. If you can get in touch with him, I expect he > could share his HDL and maybe some of his thoughts. I suspect it's just SPI mode, but you never know. > Interesting project. Is an SD card dimensions compatible with a > standard 0.062 inch thick PCB? I can find that the SD card is 0.083 > inches thick (2.1 mm) I believe the pins are recessed with raised > sections between them making the contact area a different thickness. It's possible to make something - you may have to pad the topside of a 1.6mm PCB with some material, or just fab a 2mm PCB. MicroSD is 1mm which is a common PCB thickness. > On the other hand, SD is not really an open spec. It is, as long as you aren't interested in the 'Secure' part of it that nobody uses. https://www.sdcard.org/downloads/pls/ Emulating an SD card is doable, but tedious. The interface is designed to be driven at both ends by software, so there's lots of state machines you have to implement. Also if you want 50MB/s then that's 50MHz DDR - that might be in the part that needs switching signalling down to 1.8v (I can't remember the cutoff). The higher speeds are more complex to work with. > Can you use USB flash memory instead? That should be a lot easier to > interface to. Something I've scoped out but not actually built is a double-ended SD card. One end goes in the system under test, the other end goes in a USB SD reader. On the card is a microSD socket with a real card in it and some analogue switches. Flip the switches one way and the card is 'plugged' into the test system, flip them the other way and it connects to the PC. Combine this with some GPIOs for control and some power switching and you can do automated testing - eg flash disc image to SD card with PC, 'plug' it into test system, boot SBC from SD and run tests, turn off SBC and 'plug' into PC, read off results. Rinse and repeat for every build of the software. TI has some nice SD mux chips, for instance: http://www.ti.com/lit/ds/symlink/ts3a27518e-q1.pdf I can't remember the one I've used most recently, but it was in that family. Ah, looks like somebody did it already: http://hackaday.com/2014/06/08/the-in-circuit-sd-card-switch/ I'm sure there are easier ways to do this than SD emulation - the same idea with USB for instance. But some SBCs like the Raspberry Pi (until recently at least) like booting from SD. Theo (I have form on evil SD interfaces - my current hackery is a DIMM to SD card interface...)Article: 159521
> But is *is* like writing C per-ANSI, when every compiler had its own variant. pre-ANSI The churn in language revisions isn't helping eitherArticle: 159522
I stumbled on that project but its almost 10 years old! Nevertheless, I reached out to Antti Luktas, hopefully he's not too busy to get back to me :) Making the physical connection isn't too difficult: https://www.amazon.com/48cm-Sd-micro-Card-Extender-Cable/dp/B007WYRO7O Even jumper cables are suitable at 350 Mhz.. The specification for the SD protocol is nearly completely available in the Simple SD Specification freely available on sdcard.org - the state machines I'd need are bootup (3.3v), negotiating to high speed (which switches to 1.8v) and data transfer. The SD-MUX option wears out, I've run through a couple SD cards already which is why I'm looking into the FPGA approach - not to mention faster in speed. I'm uncertain about FPGA sizing and FPGA's in general which is why I posted here - there doesn't seem to be any relatable data between different FPGA manufacturers and I'm trying to keep costs low if I need to make a lot of boards.Article: 159523
I stumbled on that project but its almost 10 years old! Nevertheless, I reached out to Antti Luktas, hopefully he's not too busy to get back to me :) Making the physical connection isn't too difficult: https://www.amazon.com/48cm-Sd-micro-Card-Extender-Cable/dp/B007WYRO7O Even jumper cables are suitable at 350 Mhz.. The specification for the SD protocol is nearly completely available in the Simple SD Specification freely available on sdcard.org - the state machines I'd need are bootup (3.3v), negotiating to high speed (which switches to 1.8v) and data transfer. The SD-MUX option wears out, I've run through a couple SD cards already which is why I'm looking into the FPGA approach - not to mention faster in speed. I'm uncertain about FPGA sizing and FPGA's in general which is why I posted here - there doesn't seem to be any relatable data between different FPGA manufacturers and I'm trying to keep costs low if I need to make a lot of boards.Article: 159524
On 26/11/16 05:57, rickman wrote: > On 11/25/2016 4:26 PM, Tim Wescott wrote: >> >> Reading this whole thread, I'm reminded of a gripe I have about the FPGA >> manufacturers, or at least Xilinx and Altera. >> >> If they -- or just any one of them -- would PUBLISH the details of how >> their bitfiles map to the workings of their FPGAs, then all of a sudden >> that company's stuff would be the subject of all the intensive university >> research on FPGA optimization that you might desire, and possibly even >> see an open-source tools ecology grow around its parts. >> >> It wouldn't immediately lead to nirvana, but it may at least lead to more >> and better optimization, and lots of people experimenting with different >> optimization approaches. > > Let's say I am Xilinx... I have a bazillion dollars of investment into > my products and the support software. I sell to large companies who > want reliable, consistent products. I open up my chip design and a > bunch of university idealists start creating tools for my devices. The > tools work to varying degrees and are used for a number of different > designs by a wide variety of groups. > > So what happens when some of these groups report problems "with the > chips"? Are these problems really with the chips or with the tools? If > any of these groups ask us to deal with these problems, how do we begin? > > In other words, how do we keep these tools from causing problems with > our reputation? > This is a point, although a weak one. The same should also happen to the microcontroller industry... but does not. They are quite happy selling chips that are being programmed by the open-sourced gcc toolchain. Pere
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