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 Tue, 28 Jul 2015 10:06:48 +0000 (UTC) Brian Drummond <brian@shapes.demon.co.uk> wrote: > On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote: > > > Those who have been in this business long enough may > > remember the line of parts Xilinx made specifically to > > support an open bit stream. [...] I'm pretty sure there > > is no mention of these parts anywhere on their site now. Or > > did I only dream all of that? > > Indeed you didn't dream the XC6200 series. It wasn't so much > that Xilinx developed them, as they bought the company that > did (Algotronics or Algotronix I think, based in Edinburgh). > Presumably they bought them for tech in general or possibly > some key patents rather than the specific device family. > > Which was something of a dead end in other respects, too fine > grained (I believe' 1 gate, 1FF per CLB). Much simpler and > more regular, but wouldn't scale too well to million-CLB > devices dominated by routing, where the XC4000 and later > devices would give the same capacity with a much smaller and > cheaper die. How about half a half a LUT or FF per CLB then? The Microsemi "IGLOO nano Low Power Flash" FPGAs are very similar in size and capability to the Lattice iCE40 range, except: The basic building block is either a flop or a LUT3 equivalent circuit, and these are then grouped into 8x8 blocks. [1] Innovation seems to come from smaller companies: as Lattice inherited the iCE40 series from SiliconBlue, Microsemi got the IGLOO parts from Actel, and the technology seen even earlier with ConcurrentLogic. An open-source toolchain for the IGLOO parts could be an unusually powerful tool in the hands of a creative designer. Jan Coombs -- [1] pg 73 of http://www.microsemi.com/document-portal/doc_view/130695-igloo-nano-low-power-flash-fpgas-datasheet email valid, else fix dots and hyphen jan4clf2014@murrayhyphenmicroftdotcodotukArticle: 158051
On 7/28/2015 3:55 PM, Jan Coombs <Jan-54 wrote: > On Tue, 28 Jul 2015 10:06:48 +0000 (UTC) > Brian Drummond <brian@shapes.demon.co.uk> wrote: > >> On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote: >> >>> Those who have been in this business long enough may >>> remember the line of parts Xilinx made specifically to >>> support an open bit stream. [...] I'm pretty sure there >>> is no mention of these parts anywhere on their site now. Or >>> did I only dream all of that? >> >> Indeed you didn't dream the XC6200 series. It wasn't so much >> that Xilinx developed them, as they bought the company that >> did (Algotronics or Algotronix I think, based in Edinburgh). >> Presumably they bought them for tech in general or possibly >> some key patents rather than the specific device family. >> >> Which was something of a dead end in other respects, too fine >> grained (I believe' 1 gate, 1FF per CLB). Much simpler and >> more regular, but wouldn't scale too well to million-CLB >> devices dominated by routing, where the XC4000 and later >> devices would give the same capacity with a much smaller and >> cheaper die. > > How about half a half a LUT or FF per CLB then? > > The Microsemi "IGLOO nano Low Power Flash" FPGAs are very > similar in size and capability to the Lattice iCE40 range, > except: > > The basic building block is either a flop or a LUT3 equivalent > circuit, and these are then grouped into 8x8 blocks. [1] > > Innovation seems to come from smaller companies: as Lattice > inherited the iCE40 series from SiliconBlue, I wouldn't say Lattice "inherited" the iCE40 family. That was what they bought, the rest of the SiBlue company came for free. > Microsemi > got the IGLOO parts from Actel, and the technology seen > even earlier with ConcurrentLogic. I don't think Concurrent Logic ended up in the hands of Actel. I know they were bought by Atmel and died a very slow death of being unfunded. I received training from the guy at Atmel who was the champion of that line. They never made an effort to keep up with process technology advances to reduce the costs. That said, I expect they knew the way to go was something more like the Xilinx/Altera routes. The fine grained architecture without routing resources just won't work for larger designs. As Xilinx used to say, "We sell you the routing and give you the logic for free." > An open-source toolchain for the IGLOO parts could be an > unusually powerful tool in the hands of a creative designer. I have looked at the Igloo parts but never been impressed. Why would an open source tool chain improve them or any other part? -- RickArticle: 158052
On Tue, 28 Jul 2015 16:10:51 -0400 rickman <gnuarm@gmail.com> wrote: > On 7/28/2015 3:55 PM, Jan Coombs <Jan-54 wrote: > > An open-source toolchain for the IGLOO parts could be an > > unusually powerful tool in the hands of a creative designer. > > I have looked at the Igloo parts but never been impressed. > Why would an open source tool chain improve them or any other > part? Because open source tools allow exploration of techniques which are restricted using regular tools. a) iCE40 - see rest of thread. (Note suggestion to buy 3 iCE40 sticks if using IceStorm, one or more parts might die during (mal?)practice) b) IGLOO - because you would then be able to create complex logic without the noise or random signal states inherent in using lookup tables. One possibility might be asynchronous logic. c) [others] no idea, unless they are close relatives of the above parts. (like ProASIC3) Jan Coombs -- email valid, else fix dots and hyphen jan4clf2014@murrayhyphenmicroftdotcodotukArticle: 158053
rickman wrote: > On 7/26/2015 5:24 PM, Tomas D. wrote: >> "rickman" <gnuarm@gmail.com> wrote in message >> news:moufqn$8d1$1@dont-email.me... >>> Someone is looking to generate compressed images in an FPGA to display >>> graph data on a browser. Looking around the GIF, TIFF or PNG formats >>> seem >>> rather straightforward to implement. Anyone know of an >>> implementation of >>> one of these in an HDL? It doesn't need to implement the entire >>> standard, >>> just enough to generate one image style. >> >> There are lots of JPEG encoders out there. Maybe use one? > > Thanks for the advice. I will use it in the spirit it was intended. :) > JPEG is not very good at reproducing line art with high contrast ratio. For example save a screen capture in TIFF, PNG, and JPEG and you'll see that JPEG gives the most blurring and artefacts unless you set it for very little compression. PNG is quite good at achieving compression on computer-generated images with text or line drawings. -- GaborArticle: 158054
On 7/29/2015 5:50 AM, Jan Coombs <Jan-54 wrote: > On Tue, 28 Jul 2015 16:10:51 -0400 > rickman <gnuarm@gmail.com> wrote: > >> On 7/28/2015 3:55 PM, Jan Coombs <Jan-54 wrote: >>> An open-source toolchain for the IGLOO parts could be an >>> unusually powerful tool in the hands of a creative designer. >> >> I have looked at the Igloo parts but never been impressed. >> Why would an open source tool chain improve them or any other >> part? > > Because open source tools allow exploration of techniques which > are restricted using regular tools. I'm not sure what this means. What "techniques" are restricted by the vendor's tools? Are we talking about techniques that are useful in a design environment or research? > a) iCE40 - see rest of thread. (Note suggestion to buy 3 iCE40 > sticks if using IceStorm, one or more parts might die during > (mal?)practice) I thoought I had read the thread. What did I miss? All I've seen is that there are alternative tools available that may or may not be as good as the vendor's tools. Other than not having to fight the licensing, what improvement do the alternative tools provide? > b) IGLOO - because you would then be able to create complex > logic without the noise or random signal states inherent in > using lookup tables. One possibility might be asynchronous > logic. ??? What logic won't the Igloo tools create? Sounds like I clearly need to avoid the Microsemi parts. > c) [others] no idea, unless they are close relatives of the > above parts. (like ProASIC3) ok -- RickArticle: 158055
On 7/29/2015 8:57 PM, foxaudioresearch@gmail.com wrote: > This is a very nice testimonial to some Forth hacking. > > http://hackaday.com/2015/07/28/open-source-fpga-toolchain-builds-cpu/ > > Youtube video is here https://www.youtube.com/watch?v=rdLgLCIDSk0 Not intending to rain on anyone's parade, just asking a question. Why does the forth community care if the FPGA development tools are open source? The commercial tools don't really restrict the design of a CPU in any way does it? The only real issue I've ever had with the commercial FPGA tools is the license which is a PITA to deal with once a year when it has to be renewed or when moving to a new machine. Is it more a conceptual thing than a practical thing? BTW, there is a very small board with the smallest FPGA on it which fits the pinout of a 8 pin DIP version of a CPU. Here is the post I made about this in the FPGA related groups with a couple more links... >> I am very impressed. I was reading about Antti's incredibly tiny FPGA >> project board and saw a mention of a FOSS FPGA toolchain. Not just the >> compiler, but the entire bitstream generation! >> >> http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/ >> >> >> Several people have built on each other's work to provide "a fully open >> source Verilog to bitstream development tool chain for the Lattice >> iCE40LP with support for more devices in the works." >> >> http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/ >> >> https://github.com/cseed/arachne-pnr >> >> I haven't tried any of it yet, but I am very impressed that they are >> reverse engineering the devices so that they can generate bit streams >> and not rely on the vendor. > > I found another link relating to the tools called "IceStorm". > > http://www.clifford.at/icestorm/ Cross-posting to the FPGA group to get some cross-pollination. -- RickArticle: 158056
In our system a signal is passed through a couple of fifos inside FPGA and then onto external sdram to be read by application software. All looks ok except that some units in the field show occasional errors in that signal read from sdram. The error is as follows: odd samples are offset by 8 samples from the even. So if we remove this offset then signal looks ok. I can't reproduce the error in the lab. So I depend on some speculations. It could be the fifos or the sdram. Anyone has come across such issue? my suspicion is on the sdram as it is configured as 8 pages? Also the sdram itself has an internal fifo that muxes 128 bits onto 16 (again factor of 8)? any input appreciated. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158057
On Thursday, July 30, 2015 at 5:05:50 AM UTC-4, kaz wrote: > In our system a signal is passed through a couple of fifos inside FPGA an= d > then onto external sdram to be read by application software. All looks ok > except that some units in the field show occasional errors in that signal > read from sdram. The error is as follows: odd samples are offset by 8 > samples from the even. So if we remove this offset then signal looks ok. >=20 > I can't reproduce the error in the lab. So I depend on some speculations. > It could be the fifos or the sdram. Anyone has come across such issue? my > suspicion is on the sdram as it is configured as 8 pages? Also the sdram > itself has an internal fifo that muxes 128 bits onto 16 (again factor of > 8)? any input appreciated. >=20 > Kaz Is the problem that the data is off by 8, or that the data gets stored in a= location that is off by 8? If it's that the data is off by 8, then the nu= mber of sdram pages or the sdram muxing is not relevant. What exactly do y= ou mean by 'off by 8'? Is data bit 3 in the wrong state? Is it that data = bit 3 is always 1 when wrong or is it that data bit 3 is wrong, and when it= is wrong that bit might be 1 or it might be 0. I would also highly doubt that the problem is in the commercial sdram, almo= st without doubt it is in something that you have designed, not elsewhere. - Has your design passed static timing analysis? - Are all of the I/O and clock frequencies correctly specified to the timin= g analysis tool? - Try warming up the part with a heat gun or cooling it off with cool spray= in the lab. Does the design still work in the lab? If not, you have a ti= ming problem. In fact, based on your description so far, it is almost certainly a timing = issue, so that would be the best place to start looking. KevinArticle: 158058
>Is the problem that the data is off by 8, or that the data gets stored in >a location that is off by 8? If it's that the data is off by 8, then the >number of sdram pages or the sdram muxing is not relevant. What exactly do >you mean by 'off by 8'? Is data bit 3 in the wrong state? Is it that data >bit 3 is always 1 when wrong or is it that data bit 3 is wrong, and when >it is wrong that bit might be 1 or it might be 0. data is 16 bits wide, nothing wrong with bits. all sample values are correct. odd samples do not follow their even members e.g. if a correct stream is indexed as 0,1,2,3,4,5,6,7,8,9,10...etc then what we get is: 0,9,2,11,4,13,6,15,8,17,10 Thus all samples are correct individually. even stream is correct as 0,2,4,6,8... and odd stream is also correct as sequence 9,11,13,15,...etc but there is this offset where instead of 0,1,2,3.. I get 0,9,2,11... >- Has your design passed static timing analysis? yes certainly, >- Are all of the I/O and clock frequencies correctly specified to the >timing analysis tool? yes >- Try warming up the part with a heat gun or cooling it off with cool >spray in the lab. Does the design still work in the lab? If not, you have a >timing problem. can't do that in the field, units are concealed mobile radio heads. we have deployed many thousands of them. only a tiny percentage shows the issue. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158059
>- Try warming up the part with a heat gun or cooling it off with cool >spray in the lab. Does the design still work in the lab? If not, you have a >timing problem. > >In fact, based on your description so far, it is almost certainly a timing >issue, so that would be the best place to start looking. > >Kevin We have done that in the lab, warming/freezing across full range but could not reproduce the issue. test was iterated over thousand times to catch any intermittent behaviour but all passed. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158060
"kaz" wrote in message=20 news:0p6dneVQkdmemifInZ2dnUU7-b2dnZ2d@giganews.com... >Is the problem that the data is off by 8, or that the data gets stored in >a location that is off by 8? If it's that the data is off by 8, then the >number of sdram pages or the sdram muxing is not relevant. What = exactly do >you mean by 'off by 8'? Is data bit 3 in the wrong state? Is it that data >bit 3 is always 1 when wrong or is it that data bit 3 is wrong, and = when >it is wrong that bit might be 1 or it might be 0. data is 16 bits wide, nothing wrong with bits. all sample values are correct. odd samples do not follow their even members e.g. if a correct stream is indexed as 0,1,2,3,4,5,6,7,8,9,10...etc then what we get is: 0,9,2,11,4,13,6,15,8,17,10 Thus all samples are correct individually. even stream is correct as 0,2,4,6,8... and odd stream is also correct as sequence = 9,11,13,15,...etc but there is this offset where instead of 0,1,2,3.. I get 0,9,2,11... >- Has your design passed static timing analysis? yes certainly, >- Are all of the I/O and clock frequencies correctly specified to the >timing analysis tool? yes >- Try warming up the part with a heat gun or cooling it off with cool >spray in the lab. Does the design still work in the lab? If not, you have a >timing problem. can't do that in the field, units are concealed mobile radio heads. we have deployed many thousands of them. only a tiny percentage shows the issue. ***************************************************************** Sounds like you have a conflict between your SDRAM column addressing and = the=20 setting of the SDRAM's burst mode. If your column address does not step in lumps of SDRAM burst addressing = then=20 your output data sequencing can (and will) get screwed. Make sure you have correctly specified the burst length for your SDRAM=20 driver and make sure your column address stepping agrees. Andy=20Article: 158061
On 7/30/2015 5:05 AM, kaz wrote: > In our system a signal is passed through a couple of fifos inside FPGA and > then onto external sdram to be read by application software. All looks ok > except that some units in the field show occasional errors in that signal > read from sdram. The error is as follows: odd samples are offset by 8 > samples from the even. So if we remove this offset then signal looks ok. > > I can't reproduce the error in the lab. So I depend on some speculations. > It could be the fifos or the sdram. Anyone has come across such issue? my > suspicion is on the sdram as it is configured as 8 pages? Also the sdram > itself has an internal fifo that muxes 128 bits onto 16 (again factor of > 8)? any input appreciated. You haven't said anything about your FPGA design in terms of where you could lose 8 samples of data or how your data is split between the odd and even samples. If your FPGA design does not split the data between odd and even, I'm not sure how you could have this problem. You also don't mention if the "lost" 8 samples of odd data ever show up somewhere or if it is just a synchronization problem from the first sample. Is there a place in your design where the odd and even samples are handled separately? Are you using two ADC converters to sample the same analog at a higher rate, for example? Do you write the odd/even samples to the SDRAM separately? -- RickArticle: 158062
>You haven't said anything about your FPGA design in terms of where you >could lose 8 samples of data or how your data is split between the odd >and even samples. If your FPGA design does not split the data between >odd and even, I'm not sure how you could have this problem. > The 8 samples are not lost but odd substream is offset from the even substream regularly. Inside fpga the data is never split up into odd/even streams. data 16 bit wide enters a fifo (dc fifo with 16 bits output width). Then into another fifo(sc with output width 32 bits) then back to 16 bits at i/o to sdram. The two fifos are few words deep but could be a cause in theory i.e. if fifo ptr toggles between two separate counting sequences. Though Altera experts looked at them and were happy about the design and we added extra pipe just in case. >Do you write the odd/even samples to the SDRAM separately? > >Rick no. The problem is also sometimes self rectifying after some time. I assume that a glitch in control signals to sdram may change the column addressing mechanism as suggested by Andy but the sdram is 8k x128 x 128 x 8 banks thus 16 bits of data is muxed as 128 bits into each cell! Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158063
On Thursday, July 30, 2015 at 7:32:59 AM UTC-4, kaz wrote: > >- Try warming up the part with a heat gun or cooling it off with cool > >spray in the lab. Does the design still work in the lab? If not, you > have a > >timing problem. > > > >In fact, based on your description so far, it is almost certainly a > timing > >issue, so that would be the best place to start looking. > > > >Kevin >=20 > We have done that in the lab, warming/freezing across full range but coul= d > not reproduce the issue. test was iterated over thousand times to catch > any intermittent behaviour but all passed. >=20 > Kaz >=20 Some next steps to consider... - You did the thermal testing with field return boards that exhibited the p= roblem, correct? - Are there other differences between lab use and field use that could cont= ribute such as with the power supply? The power supply is probably a stret= ch given the symptoms you describe, but just wondering what environmental d= ifferences might be going on. - What kind of DRAM are you using? - Commercial IP for the controller or home grown? - Since you said in another post that the data starts at 16 bits, widens to= 32 (I presume at input to the DRAM Controller) and then narrows back down = to 16 at the I/O pins. Are clock domains being crossed along the way? Is = your timing analysis set to ignore crossings? If so, shut that off and re-= analyze each crossing. - How does the DDR controller receive input commands? By that I mean is it= given addresses for each read/write to be performed or is it given a start= address and a burst size? If given a start address and burst size, then t= hat would likely exonerate everything that is upstream of the DRAM controll= er (except for possible clock domain crossing issues) - Review the PCB routing and look at signal integrity on the PCB? Focus on getting the field returns to fail in the lab. Without that you'll= have no way to verify any potential fix candidate. Kevin JenningsArticle: 158064
On Thu, 30 Jul 2015 06:14:11 -0500, kaz wrote: > >>- Has your design passed static timing analysis? > yes certainly, > Then are you certain all your timing constraints are correct? I'm with KJ, this problem description makes me immediately leap to a timing problem. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 158065
On 7/30/2015 12:56 PM, kaz wrote: >> You haven't said anything about your FPGA design in terms of where you >> could lose 8 samples of data or how your data is split between the odd >> and even samples. If your FPGA design does not split the data between >> odd and even, I'm not sure how you could have this problem. >> > > The 8 samples are not lost but odd substream is offset from the even > substream regularly. > > Inside fpga the data is never split up into odd/even streams. data 16 bit > wide enters a fifo (dc fifo with 16 bits output width). Then into another > fifo(sc with output width 32 bits) then back to 16 bits at i/o to sdram. How large is a "sample"? > The two fifos are few words deep but could be a cause in theory i.e. if > fifo ptr toggles between two separate counting sequences. Though Altera > experts looked at them and were happy about the design and we added extra > pipe just in case. ??? The two FIFOs are sequential, not parallel, right? So how would the cause a shift in the odd/even data? Do the FIFOs use block RAM? I don't recall Altera having distributed memory so I guess block RAM is the only thing available. That means the FIFO memory is one block of memory unless you have fairly large FIFOs. Is any of this right? >> Do you write the odd/even samples to the SDRAM separately? >> >> Rick > no. > > The problem is also sometimes self rectifying after some time. > > I assume that a glitch in control signals to sdram may change the column > addressing mechanism as suggested by Andy but the sdram is 8k x128 x 128 x > 8 banks thus 16 bits of data is muxed as 128 bits into each cell! Not following this well. I think you are simply saying that the internal writes in the SDRAM are 128 bits so your 16 bit samples(?) are written 8 at a time. Unless you have some separation of odd/even samples I don't see how that would matter. How do you have your burst addressing set? There are different modes with different addressing. Only one is sequential. It has been too long since I've worked with SDRAM and I don't recall what that is all about. If this is the issue, it won't reproduce the symptoms as you have described. I believe you say that at the beginning of the fault 8 odd samples are dropped leaving the rest of the sequence out of alignment with the even samples. If they aren't dropped, where do they show up? With a burst addressing error the samples would be moved about, scrambled in some way, but not lost at all. When the unit "recovers", where does the extra data come from? Are 8 odd samples repeated? If you can figure out more details of the glitch at the beginning and end of the error sequence it might help explain where the problem is. -- RickArticle: 158066
kaz <37480@fpgarelated> wrote: > >>Is the problem that the data is off by 8, or that the data gets stored >> in a location that is off by 8? If it's that the data is off by 8, >> then the number of sdram pages or the sdram muxing is not relevant. (snip) > data is 16 bits wide, nothing wrong with bits. all sample values are > correct. > odd samples do not follow their even members e.g. if a correct stream is > indexed as 0,1,2,3,4,5,6,7,8,9,10...etc then what we get is: > 0,9,2,11,4,13,6,15,8,17,10 Somehow this reminds me of something from years ago, which was using real IC FIFOs instead of FPGA ones. Somehow the system wasn't following FULL and ALMOST FULL, and would wrap the FIFO. But that usually results in data loss, which you seem to indicate doesn't happen. I don't know SDRAM timing enough to say. If all the data paths are 16 bits, it is funny to have an offset on eight bit boundaries! -- glenArticle: 158067
I will try to give more details instead of my "reduced simplified version" and hopefully answer some of your questions. I am talking about a DPD functionality where software reads from sdram 2,457,600 samples of each of TxI,TxQ,sRxI,sRxQ. all these four slots are 16 bits signed and interleaved in above order giving a total stream size of 2,457,600 x 4 samples. inside FPGA: TxI and TxQ are first concatenated as(16 x 2 bits), then passed through a small dc fifo for clock crossing. sRxI and sRxQ are data received from Tx after going through DAC & PA then sampled back by an ADC for DPD algorithm. sRxI and sRxQ are also concatenated as 16 x 2 bits. They also go through their dc fifo for clock crossing. Then all four data are concatenated as 16 x 4 = 64 bits. The stream is then passed as 128 bits using sc fifo for sdram controller IF (Altera sdram controller). At the i/o data is passed as two streams each 16 bits and each has its own sdram. Thus we have two sdrams (one for Tx data and one for sRx data) Almost all field units work without any problem. Occasionally, it is reported that DPD algorithm fails and when I looked at captured files I noticed that sRx data was ok but TxI and TxQ each shows same problem I described where their odd samples had shifted location relative to even ones. So instead of the normal order of 0,1,2,3,4,...etc. I noticed it was 0,9,2,11,4,13,6,15,8,... from beginning to the end of 2,456,7600 Apart from that there is no other error and all values are correct judging by spectrum and time domain. What happens at the moment of the glitch we don't know, I haven't tested any failed units in the lab though I requested that. We have inserted some extra logic to capture data directly from fifos in case of the event but we failed to reproduce the error. Units are in different countries and it is hard to keep track of debugging. My first conclusion is that there must be memory involved and it must be a case of read/write toggling. The basic fpga concatenation logic does not involve storage and so is ruled out. FPGA fifos are block ram based and we have hundreds of them all across the design for various parts without issues. sdram controller and i/o timing have been done by Altera experts. Design is timing clean, lab tested across full range of temperature. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158068
kaz <37480@fpgarelated> wrote: > I will try to give more details instead of my "reduced simplified version" > and hopefully answer some of your questions. (snip) > inside FPGA: > TxI and TxQ are first concatenated as(16 x 2 bits), then > passed through a small dc fifo for clock crossing. How small is this FIFO? (depth x width) By they way, it is usual to use Gray code when passing the FIFO address across the clock domain. I think they convert back, but maybe just address the BRAM with Gray code. -- glenArticle: 158069
On 7/30/2015 4:24 PM, kaz wrote: > I will try to give more details instead of my "reduced simplified version" > and hopefully answer some of your questions. > > I am talking about a DPD functionality where software reads from sdram > 2,457,600 samples of each of TxI,TxQ,sRxI,sRxQ. > all these four slots are 16 bits signed and interleaved in above order > giving a total stream size of 2,457,600 x 4 samples. > > inside FPGA: > TxI and TxQ are first concatenated as(16 x 2 bits), then passed through a > small dc fifo for clock crossing. Should I assume DC means "dual clock"? So this FIFO is 32 bits wide? > sRxI and sRxQ are data received from Tx after going through DAC & PA then > sampled back by an ADC for DPD algorithm. sRxI and sRxQ are also > concatenated as 16 x 2 bits. They also go through their dc fifo for clock > crossing. > > Then all four data are concatenated as 16 x 4 = 64 bits. > > The stream is then passed as 128 bits using sc fifo for sdram controller > IF (Altera sdram controller). At the i/o data is passed as two streams > each 16 bits and each has its own sdram. Thus we have two sdrams (one for > Tx data and one for sRx data) I don't find this part clear at all. Above you say the data stream is 64 bits, then 128, then two streams of 16 bits. So the data is packed with one sample of each of the four data streams (TxI,TxQ,sRxI,sRxQ) to make 64 bits, then two words of this are grouped to make 128 bits. But then it is all broken back down into 16 bit individual samples? > Almost all field units work without any problem. Occasionally, it is > reported that DPD algorithm fails and when I looked at captured files I > noticed that sRx data was ok but TxI and TxQ each shows same problem I > described where their odd samples had shifted location relative to even > ones. So instead of the normal order of 0,1,2,3,4,...etc. I noticed it was > 0,9,2,11,4,13,6,15,8,... from beginning to the end of 2,456,7600 So you can't say what happened to samples 1, 3, 5, etc? The data is being handed to the SDRAM as 16 bit samples, TxI0, TxQ0, TxI1, TxQ1,...? So when you have the glitch the alignment is shifted for both TxI and TxQ or just one? If both, that would be 16 samples of 16 bit data, right? > Apart from that there is no other error and all values are correct judging > by spectrum and time domain. > > What happens at the moment of the glitch we don't know, I haven't tested > any failed units in the lab though I requested that. We have inserted some > extra logic to capture data directly from fifos in case of the event but > we failed to reproduce the error. Units are in different countries and it > is hard to keep track of debugging. > > My first conclusion is that there must be memory involved and it must be a > case of read/write toggling. The basic fpga concatenation logic does not > involve storage and so is ruled out. FPGA fifos are block ram based and we > have hundreds of them all across the design for various parts without > issues. > sdram controller and i/o timing have been done by Altera experts. > > Design is timing clean, lab tested across full range of temperature. > > Kaz -- RickArticle: 158070
>> inside FPGA: >> TxI and TxQ are first concatenated as(16 x 2 bits), then >> passed through a small dc fifo for clock crossing. > >How small is this FIFO? (depth x width) > >By they way, it is usual to use Gray code when passing the FIFO >address across the clock domain. I think they convert back, but >maybe just address the BRAM with Gray code. > >-- glen it is dual clock fifo(368.64Mhz => 245.76MHz, 32 bits wide, 16 words deep it is altera core, we just write/read under our rate control logic avoiding empty/full situation The sRx fifo is 245.76 => 245.76 with same above width/depth Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158071
>On 7/30/2015 4:24 PM, kaz wrote: >I don't find this part clear at all. Above you say the data stream is >64 bits, then 128, then two streams of 16 bits. So the data is packed >with one sample of each of the four data streams (TxI,TxQ,sRxI,sRxQ) to >make 64 bits, then two words of this are grouped to make 128 bits. But >then it is all broken back down into 16 bit individual samples? > correct, that is how it is designed (I assume it is to do with SOPC interface) > >So you can't say what happened to samples 1, 3, 5, etc? The data is >being handed to the SDRAM as 16 bit samples, TxI0, TxQ0, TxI1, TxQ1,...? > correct I should correct myself about the offset value, it is 16 samples(not 8) in the sense of stream index i.e. I get samples in the order 0,17,2,19,4,21,...etc >So when you have the glitch the alignment is shifted for both TxI and >TxQ or just one? If both, that would be 16 samples of 16 bit data, right? > both I and Q symmetrically, if I reverse the offset of both I get proper signal. I don't have two captures and I assume the error wraps. >> Kaz > > >-- > >Rick --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158072
Out of curiosity, I wrote a script to explore with different options in the= Vivado software (2014.4), especially on the synthesis options under SYNTH_= DESIGN, like FSM_extraction, MAX_BRAM etc. The script stops after synthesis= , just enough to get the timing estimate. I explore everything except the d= irective because it seems like you use the directive, you cannot manually s= et the options My goal is to see if it will give me a better result before I move on to im= plementation. However, out of the 50 different results I see that a lot of = the estimated worst slacks and timing scores are the same. About 40% of the= results report the same values. I ran on 3 sample designs and it gave me t= he same thing. So my question is, is there a way to differentiate what is a better synthes= is result? What should I look at in the report?=20Article: 158073
On Thu, 30 Jul 2015 20:23:12 -0700, James07 wrote: > Out of curiosity, I wrote a script to explore with different options in > the Vivado software (2014.4), especially on the synthesis options under > SYNTH_DESIGN, like FSM_extraction, MAX_BRAM etc. The script stops after > synthesis, just enough to get the timing estimate. I explore everything > except the directive because it seems like you use the directive, you > cannot manually set the options > > My goal is to see if it will give me a better result before I move on to > implementation. However, out of the 50 different results I see that a > lot of the estimated worst slacks and timing scores are the same. About > 40% of the results report the same values. I ran on 3 sample designs and > it gave me the same thing. > > So my question is, is there a way to differentiate what is a better > synthesis result? What should I look at in the report? Did you also differentiate by resource usage? Same timing result and lower usage would count as better, but sometimes different settings will, after optimisation, yield the same result. It's also worth trying ISE, with both the old and new VHDL parser (though switching parsers is more likely to dance round bugs than improve synth results). While Vivado is relatively new, ISE has been heavily tuned across the years and I wouldn't be surprised to find it sometimes gives better results. If you try it, I'd be interested to see your conclusions. -- BrianArticle: 158074
On Thu, 30 Jul 2015 04:05:45 -0500, kaz wrote: > In our system a signal is passed through a couple of fifos inside FPGA > and then onto external sdram to be read by application software. All > looks ok except that some units in the field show occasional errors in > that signal read from sdram. The error is as follows: odd samples are > offset by 8 samples from the even. So if we remove this offset then > signal looks ok. > > I can't reproduce the error in the lab. So I depend on some > speculations. It could be the fifos or the sdram. Anyone has come across > such issue? my suspicion is on the sdram as it is configured as 8 pages? > Also the sdram itself has an internal fifo that muxes 128 bits onto 16 > (again factor of 8)? any input appreciated. Focus on reproducing it in the lab - or in simulation. Xilinx FPGAs have multiple clock modules (DCMs) - you're using Altera so you'll have to translate terms. These have ways of generating a derivative clock with adjustable timing for clock phase adjustment : I have attacked similar problems by setting up the timing in a software-writable register, running memtests with every possible phase adjustment and mapping out the valid range of timings. If you have one or more of these spare, attach it to the SDRAM clock, and if you have another, attach it to your incoming data register, or your SDRAM address bus output, etc... Now you can run memory tests, stretching the timings until it fails. Hopefully one of the failure modes (but not more than one) will reproduce the error you are seeing. In my case, having found the likely failure mode this way, I was able to reproduce the effect in simulation, the rest was plain sailing. Incidentally I also recall a correlation between memory manufacturer and one failure mechanism : I concluded there was nothing specific wrong with the memory itself, but some disagreement between it and my RAM interface; I could make that one go away by specifying another memory. Is there any such variability in your case? -- Brian
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