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 Aug 8, 1:20=A0am, laserbeak43 <laserbea...@gmail.com> wrote: > found a xilinx entry in the registry when searching "mingw" but the > value in it was "MinGW^e" > doubt that has anything to do with it. Still, it could be worth backing up the registry and seeing what happens when you remove that entry...after all, they are two seperate programs that should not have anything to do with one another, yet there they are sharing name space in the registry. I have MinGW as well and there is no registry entry that shows up "xilinx" when I search for "mingw." Also, Xilinx does not show up at all in my system path, though, like I said, on my ISE 9.2 install I have a "Xilinx" variable set to my install directory. I haven't yet figured out how to mess with the paths inside ISE itself.Article: 134401
Jim Granville wrote: > Block RAM arrays would be one way to pack this into a smaller > FPGA, and just clone the Array-Scan as needed. > eg if you have the time-budget to scan 50 into one block RAM, > then 3 repeats supports 150 channels... 18 bit counters > are good, as the reciprocal Cycle Ctr 'scales' these to > similar times. > (so precison is largely independant of freauency) > > The Dual-port access to Block Rams, would allow > the Cycle Ctr, and TimeCtr to share a block, > typical block is 1K x 18, so 50 T_Ctrs, 50 captures, > and 50 C_Ctrs + Preloads, is only 200 RAM-lines. I see a good, recent Xilinx WP here "Creative Uses of Block RAM" By: Peter Alfke http://www.xilinx.com/support/documentation/white_papers/wp335.pdf So Peter may be able to comment on how many Counters, you could practically 'pack into' Xilinx BlockRam, on a 1-2us Frame time ? [Tho even the smallest Xilinx device has 4 block rams..] The OP may find pin-count dictates the fpga, if he wants to do a single-package parallel wiring design. Practical wiring decisions might point to a fast serial backplane to collect the signals ? Something like a clone of the 4 bit SPI, done in 4-5 very bottom-end cpld's, would feed 24-26-30 bits into practical 'ribbon-cable' widths and speeds. That would avoid paying for a bigger fpga, just to get the pins.... -jgArticle: 134402
Hi again, thank you for your reply! > There is also a U-Boot Version 1.1.4 from Xilinx out there which has > quite a lot of Xilinx specific support (Though I must admit, that I > haven't had a look at the current u-boot-git. THAT's the point: The Xilinx git. I simply didn't know it! And I used the old "ppc" arch, not yet "powerpc". I now have an emaclite running. It is connected to the ML403's Marvell PHY via MII data lines without management interface. The driver seems to work. But everything is VERY slow and I see a lot of packet loss. Trying to wget something from my PC results in approx 10kB/s (yes, KILObytes...!). I don't know what's wrong - and being not too keen to know about. I want to switch to the xps_ll_temac now. This raises new questions: - Does the Marvell PHY support GMII (I currently think so)? - What is the GXP_Clk signal for?!? - Are there any other important things to know? - Does anybody have the Marvell Alaska PHY's datasheet? I would be VERY glad to get it - but Marvell doesn't provide any information :-( > I do use the HardTemac as it saves some BRAMs and Slices (and I am > always lacking those ;-)) With xps_ll_temac I think? As the plb_temac doesn't exist for me... >> How do I correctly set up the FX12's Tri-mode Emac with Linux and U-Boot? >> > > I think the Linuxppcembedded-Mailinglist might be a more convenient and > informative place to ask this. Oh, nice to know. I'll subscribe there - if I find the list... found... subscribed :-) Best wishes, Philipp :-) -- You have to reboot your computer after powerfail? Haha! http://h316.hachti.deArticle: 134403
You could use a board that has a 2x6 or two 1x6 Digilent PMOD connections and then use the Digilent SD PMOD http://www.digilentinc.com/Products/Detail.cfm?Prod=PMOD-SD&Nav1=Products&Nav2=Peripheral. Some candidates include: - Avnet Spartan-3A 400A Eval board (www.em.avnet.com/spartan3a-evl) - Xilinx Spartan-3A DSP 1800A Starter (www.xilinx.com/s3adspstarter) - Xilinx Spartan-3A 700A Starter (www.xilinx.com/s3astarter) BryanArticle: 134404
"Bryan" <bryan.fletcher@avnet.com> wrote in message news:a81b6767-e27e-434a-b273-1b49747b7dd8@n33g2000pri.googlegroups.com... > You could use a board that has a 2x6 or two 1x6 Digilent PMOD > connections and then use the Digilent SD PMOD > http://www.digilentinc.com/Products/Detail.cfm?Prod=PMOD-SD&Nav1=Products&Nav2=Peripheral. > > Some candidates include: > - Xilinx Spartan-3A DSP 1800A Starter (www.xilinx.com/s3adspstarter) I happened to have one of these lying around, and I just ordered the SDPMOD and cable. Looks like it's exactly what I'm looking for. Thanks. Anybody know of any open source SD mode controller? The only open core project I can find is SPI. Thanks PeteArticle: 134405
Hi, Does anyone know of an appnote showing the recommended breakout routing for the cyclone3 484BGA package? I am currently working on a PCB with this IC and am wondering about the most efficient way to break it out. I am using tiny vias between the 1mm pitch BGA pads, mainly wondering the best places to put the 3.3V supply and PLL supply decoupling caps, and the best way to deal with the 3.3V and GND pins on the third and fourth rows in respectively. cheers, JamieArticle: 134406
ahhh, very interesting. I was getting tired of all the problems and went back to 7.1i I must admit that i am tempted to try that again though. hmm i'd like to back my pc up and then give it another shot on a fresh install of windows. maybe i'll do that this week. thanks for all of your help and words of encouragement! i'll let you know what happens!! andersod2 wrote: > On Aug 8, 1:20=EF=BF=BDam, laserbeak43 <laserbea...@gmail.com> wrote: > > found a xilinx entry in the registry when searching "mingw" but the > > value in it was "MinGW^e" > > doubt that has anything to do with it. > > Still, it could be worth backing up the registry and seeing what > happens when you remove that entry...after all, they are two seperate > programs that should not have anything to do with one another, yet > there they are sharing name space in the registry. I have MinGW as > well and there is no registry entry that shows up "xilinx" when I > search for "mingw." > > Also, Xilinx does not show up at all in my system path, though, like I > said, on my ISE 9.2 install I have a "Xilinx" variable set to my > install directory. I haven't yet figured out how to mess with the > paths inside ISE itself.Article: 134407
I want to program a XCR3128X... (XPLA3) coolrunner so that I have the jedec file as a result (I know my way from then on). I looked at Xilinx' website and they do offer a free package for that but it is 2G+ of size(!). Last time I downloaded something for a similar purpose (the PHDL thing) it was well below 10M.... I really want only a translation from logic equations to jedec, no optimization, no simulation, nothing more - is that achievable using the 2G package? (I guess it is, IIRC I read something saying ABEL <-> PHDL was not a huge issue, but some hint/confirmation would not hurt) Alternatively, can I locate some other free resource which is less huge and will do the job? This comes from someone who has written a complete toolchain for the old - Philips - Coolrunner and so is used to have things under control... Thanks, Didi ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/Article: 134408
Didi wrote: > I want to program a XCR3128X... (XPLA3) coolrunner so that > I have the jedec file as a result (I know my way from then on). > > I looked at Xilinx' website and they do offer a free package > for that but it is 2G+ of size(!). Last time I downloaded something > for a similar purpose (the PHDL thing) it was well below 10M.... Isn't progress great! ;) There was a time when Xilinx let you download JUST the CPLD portion of the tools, but perhaps no longer... > I really want only a translation from logic equations to jedec, > no optimization, no simulation, nothing more - is that achievable > using the 2G package? (I guess it is, IIRC I read something saying > ABEL <-> PHDL was not a huge issue, but some hint/confirmation > would not hurt) AFAIK, Xilinx still have ABEL in the tools, they took the trouble a while ago to make a ABEL -> VHDL flow, which was good to preserve legacy code, and good the those projects that don't need VHDL source. (Of course, you now do have to have the VHDL tools, even if they are pushed to the background....) > > Alternatively, can I locate some other free resource which is less > huge and will do the job? > > This comes from someone who has written a complete toolchain for > the old - Philips - Coolrunner and so is used to have things under > control... You could look around for some old Flow tools, and use those ? Xilinx have some on the ISE Classics area, but the map page omits to indicate any Size. If you can use the Atmel ATF1502BE, (tqfp100) the tool flow for that is lean by comparison :) 20MB download, and that can be pruned to under 5MB, if you want just command line flow. -jgArticle: 134409
On Aug 9, 6:20=A0am, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Didi wrote: > > I want to program a XCR3128X... (XPLA3) coolrunner so that > > I have the jedec file as a result (I know my way from then on). > > > I looked at Xilinx' website and they do offer a free package > > for that but it is 2G+ of size(!). Last time I downloaded something > > for a similar purpose (the PHDL thing) it was well below 10M.... > > Isn't progress great! =A0;) > > There was a time when Xilinx let you download =A0JUST the CPLD > portion of the tools, but perhaps no longer... It's still there: http://www.xilinx.com/support/download/i101winpt.htm although the single file download has certainly grown (thanks to their "improved" user interface?) to almost 1 gigabyte. Perhaps the web install will only download the pieces that are important to you and shave a few hundred megabytes(!) off. MarcArticle: 134410
On Aug 8, 9:25=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Jim Granville wrote: > > Block RAM arrays would be one way to pack this into a smaller > > FPGA, and just clone the =A0Array-Scan as needed. > > eg if you have the time-budget to scan 50 into one block RAM, > > then 3 repeats supports 150 channels... 18 bit counters > > are good, as the reciprocal Cycle Ctr 'scales' these to > > similar times. > > (so precison is largely independant of freauency) > > > The Dual-port access to Block Rams, would allow > > the Cycle Ctr, and TimeCtr to share a block, > > typical block is 1K x 18, so 50 T_Ctrs, 50 captures, > > and 50 C_Ctrs + Preloads, is only 200 RAM-lines. > > =A0 I see a good, recent Xilinx WP here > "Creative Uses of Block RAM" =A0By: Peter Alfke > > http://www.xilinx.com/support/documentation/white_papers/wp335.pdf > > =A0 So Peter may be able to comment on how many Counters, you > could practically 'pack into' Xilinx BlockRam, on a 1-2us Frame time ? > =A0 [Tho even the smallest Xilinx device has 4 block rams..] > > The OP may find pin-count dictates the fpga, if he wants to do a > single-package parallel wiring design. > =A0 Practical wiring decisions might point to a fast serial backplane > to collect the signals ? > =A0 Something like a clone of the 4 bit SPI, done in 4-5 very bottom-end > cpld's, would feed 24-26-30 bits into practical 'ribbon-cable' > widths and speeds. That would avoid paying for a bigger fpga, just > to get the pins.... > > -jg It's a Spartan-3 and I picked it because of my large number of inputs. Connecting an input from each of the 88 notes lets me avoid an elaborate tree of external multiplexers. I only sustain 44 of the strings at a time (every other note) because otherwise I get interference from adjacent driving magnets. The system does not run all the time. It only actively adjusts pitches for the first couple of minutes after you turn it on. Once the strings stabilize at their in-tune pitch, all of the PWM duty cycles are frozen and maintained from that point on and the magnetic sustaining ceases. When the musician is done playing, he switches it off. The next time it is turned on, you get a new tuning for that day's conditions. This also keeps the system simple, since there is only one button. Don Kansas CityArticle: 134411
eromlignod wrote: > It's a Spartan-3 and I picked it because of my large number of > inputs. Connecting an input from each of the 88 notes lets me avoid > an elaborate tree of external multiplexers. I only sustain 44 of the > strings at a time (every other note) because otherwise I get > interference from adjacent driving magnets. > > The system does not run all the time. It only actively adjusts > pitches for the first couple of minutes after you turn it on. Once > the strings stabilize at their in-tune pitch, all of the PWM duty > cycles are frozen and maintained from that point on and the magnetic > sustaining ceases. When the musician is done playing, he switches it > off. The next time it is turned on, you get a new tuning for that > day's conditions. This also keeps the system simple, since there is > only one button. > > Don > Kansas City So the tuning mode results in a constant square wave for each of the 44 channels? I was wondering how the system would decide when the square wave was "stable enough" to have reliable measurements. The continuous feed simplifies many decisions. The "Spartan-3" mention supplies a family, but the curiosity was more around the size of the part for the number of BlockRAMs and LUT resources (which is also different for S3, S3E, and S3A). If you have a table full of count values, do you then just want to read these with an external processor? Do you want to have processing done on the signals inside the FPGA? Personally, I liked the earlier suggestion of defining the target period count and just measuring the delta value: the period error. The approach I'd enjoy coding up would use the distributed SelectRAM memories as counters and use an "octave counter" configuration (my concept for the unique requirements of your project) which would count the C8 period every 2 clocks, C7 every 4, C6 every 8, all the way down to C1 and C2 each counted only every 128 clocks. All eight octaves count with the same percent resolution relative to the period and use significantly less logic than one counter per key. 6 channels of the octave counter then give you the 44 channels at a time with a 2:1 mux to select odd or even keys. The octave counter only needs to be used for the 3 LSbits and a single BlockRAM used to coordinate the counts and accumulate the 44 channels by adding the LSbits. Two BlockRAMs would make the whole configuration easier to allow a dual-port for the accumulator on one and the full count (plus scaling?) into one port of the 2nd BlockRAM while the processor side has full access to the other port of the 2nd BlockRAM. In the period counter arrangement, the largest error would be on the high frequency side so a 1/100 semitone error on C8 gives a 138ns error for a single cycle. The "every other clock" at 50MHz for this highest octave easily gives a single-cycle measurement that would give the accuracy you need (80ns error from both sides of a single count); at this point your system error is probably much more an issue of the noise (measurement jitter) in the square waves from the sensors. The octave counter approach give you the same percentage error on all octaves for a single key. As pointed out by someone earlier, counting multiple consecutive periods rather than averaging multiple counts gives you a much higher precision, spreading the 80ns error I mentioned above over multiple periods rather than just one for a per-period error of 80ns/N for an N period count. Using BlockRAMs to hold the main part of the counters, you have 36 bits to play with for free. Since the octave counter scales by a factor of 2 for each octave, all the counts are the same relative size. If you wanted to pursue the error count rather than the raw count values for each period, you could even multiply the errors by a defined constant for each key to give you a scaled error that's appropriate to feed your system adjustments and have all your processing easily handled within the single FPGA. This kind of stuff is just fun.Article: 134412
I'm working with a Spartan FPGA using ISE. I have a large array of 8 bit numbers, but due to the nature of the device, some of them are not used. Is there a way to eliminate those particular registers so that they don't take up space? For example, if I have an array with 100 8-bit registers like this: reg [7:0] array [99:0]; and I'm not using registers [22], [45], [66], or [92], can I somehow remove those registers from the final design? sidArticle: 134413
"sid" <sylvestersn@yahoo.com> wrote in message news:2059f53b-6bb3-4552-b918-a4fecaff421b@k30g2000hse.googlegroups.com... > I'm working with a Spartan FPGA using ISE. I have a large array of 8 > bit numbers, but due to the nature of the device, some of them are not > used. Is there a way to eliminate those particular registers so that > they don't take up space? > > For example, if I have an array with 100 8-bit registers like this: > > reg [7:0] array [99:0]; > > and I'm not using registers [22], [45], [66], or [92], can I somehow > remove those registers from the final design? > Synthesis will automatically do that for you KJArticle: 134414
KJ wrote:
> "sid" <sylvestersn@yahoo.com> wrote in message
> news:2059f53b-6bb3-4552-b918-a4fecaff421b@k30g2000hse.googlegroups.com...
>> I'm working with a Spartan FPGA using ISE. I have a large array of 8
>> bit numbers, but due to the nature of the device, some of them are
>> not used. Is there a way to eliminate those particular registers so
>> that they don't take up space?
>>
>> For example, if I have an array with 100 8-bit registers like this:
>>
>> reg [7:0] array [99:0];
>>
>> and I'm not using registers [22], [45], [66], or [92], can I somehow
>> remove those registers from the final design?
>>
>
> Synthesis will automatically do that for you
>
> KJ
KJ,
In some circumstances, maybe, but look at this scenario:-
process(clk,res)
begin
if res = '1' then
registers <= all_zeros;
elsif rising_edge(clk) then
registers(cpu_address) <= data_from_cpu;
end if;
end process;
data_to_cpu <= registers(cpu_address);
How does the synthesiser know which addresses the CPU never uses?
Cheers, Syms.
Article: 134415"Symon" <symon_brewer@hotmail.com> wrote in message news:g7kioq$3ld$1@aioe.org... > KJ wrote: >> "sid" <sylvestersn@yahoo.com> wrote in message >> news:2059f53b-6bb3-4552-b918-a4fecaff421b@k30g2000hse.googlegroups.com... >>> >>> and I'm not using registers [22], [45], [66], or [92], can I somehow >>> remove those registers from the final design? >>> >> >> Synthesis will automatically do that for you >> >> KJ > > KJ, > In some circumstances, maybe, but look at this scenario:- > > > > process(clk,res) > begin > if res = '1' then > registers <= all_zeros; > elsif rising_edge(clk) then > registers(cpu_address) <= data_from_cpu; > end if; > end process; > > data_to_cpu <= registers(cpu_address); > > > > How does the synthesiser know which addresses the CPU never uses? > It doesn't, and your example is not one where the registers are not used either since they are all addressable therefore they must all be implemented. If this is what the OP had in mind when he said he had 'unused' registers then he is mistaken as well. KJ > Cheers, Syms. > > > > >Article: 134416
Philipp Hachtmann wrote: > Hi again, > > thank you for your reply! > >> There is also a U-Boot Version 1.1.4 from Xilinx out there which has >> quite a lot of Xilinx specific support (Though I must admit, that I >> haven't had a look at the current u-boot-git. > > THAT's the point: The Xilinx git. I simply didn't know it! > And I used the old "ppc" arch, not yet "powerpc". > > I now have an emaclite running. It is connected to the ML403's Marvell > PHY via MII data lines without management interface. > The driver seems to work. > But everything is VERY slow and I see a lot of packet loss. Trying to > wget something from my PC results in approx 10kB/s (yes, KILObytes...!). > I don't know what's wrong - and being not too keen to know about. I want > to switch to the xps_ll_temac now. > > This raises new questions: > > - Does the Marvell PHY support GMII (I currently think so)? Yes it does, I do use it. > - What is the GXP_Clk signal for?!? I don't have this one :-( But as a hint: use the BaseSystemBuilder Wizzard to generate a Design with Hard-Temac and copy from there to Your Design ;-) > - Are there any other important things to know? Well, there is a sack of rice in China, okok ;-) Well with u-boot Autonegotiation-Code didnÄt work fine for us, we changed that, maybe I'll find that patch somewhere, I promise to look for it... > > - Does anybody have the Marvell Alaska PHY's datasheet? I would be VERY > glad to get it - but Marvell doesn't provide any information :-( > Haha, Marvell obviously does NOT want to sell any chips, at least they would even have wanted a full story about the project behind our own custom board, well other fathers do have good-looking daughters as well. Normally You do not need that datasheet. The registers You basically need are defined by the GMII-Standard everything beyond is not needed (though might be convenient). > >> I do use the HardTemac as it saves some BRAMs and Slices (and I am >> always lacking those ;-)) > With xps_ll_temac I think? As the plb_temac doesn't exist for me... > Well actually I started with my ML403 when EDK 8.1 was state of art and I do not change my base system just because Xilinx thinks that ll_temac is more suitable for them (or even just think of those crazy wrappers around the PPC405 just to use a PPC440 similar memory-interface, sometimes I think some people are really crazy ... >>> How do I correctly set up the FX12's Tri-mode Emac with Linux and >>> U-Boot? >>> >> >> I think the Linuxppcembedded-Mailinglist might be a more convenient >> and informative place to ask this. > Oh, nice to know. I'll subscribe there - if I find the list... found... > subscribed :-) > > > Best wishes, > > Philipp :-) > > Regards, LorenzArticle: 134417
Hi, How does the vertical migration, using different parts with the same package work with the altera cyclone 3 devices? For the EP3C40 and EP3C16 parts in the FBGA464 packages, pin D7 is gnd on the 16K part, and D7 is diffio on the 40K part. Also some gnd pins on the 40K part are I/O on the 16K part. So to design a PCB that can work with both of these parts alot of extra I/O will have to be grounded I guess? cheers, JamieArticle: 134418
eromlignod wrote: > It's a Spartan-3 and I picked it because of my large number of > inputs. Connecting an input from each of the 88 notes lets me avoid > an elaborate tree of external multiplexers. Done right, the external fan-in design can save a lot of bulky wiring, and keeps the looming in simple ribbon cable. We have done Serial/parallel chainable fan-in/fan-out systems in designs, and it is very expandable, and simple to loom-up. Also has natural cross talk advantages. You will already have 'remote PCBs' doing the front-end signal conditioning ? How much you 'production enginerr' this, depends on how many of these you hope to make. > I only sustain 44 of the > strings at a time (every other note) because otherwise I get > interference from adjacent driving magnets. > > The system does not run all the time. It only actively adjusts > pitches for the first couple of minutes after you turn it on. Once > the strings stabilize at their in-tune pitch, all of the PWM duty > cycles are frozen and maintained from that point on and the magnetic > sustaining ceases. When the musician is done playing, he switches it > off. The next time it is turned on, you get a new tuning for that > day's conditions. This also keeps the system simple, since there is > only one button. Hmm... has this been proven on a working unit, in the field ? Better would be a system that can _prove_ what you stated, by tracking the frequency even during a performance. It does not have to adjust, but knowing just how many ppm the thing has drifted, would seem a strong selling point -jgArticle: 134419
John_H wrote: > The octave counter only needs to be used for the 3 LSbits and a single > BlockRAM used to coordinate the counts and accumulate the 44 channels by > adding the LSbits. Two BlockRAMs would make the whole configuration > easier to allow a dual-port for the accumulator on one and the full > count (plus scaling?) into one port of the 2nd BlockRAM while the > processor side has full access to the other port of the 2nd BlockRAM. With counters, normally you have a capture register, so that gives the processor something relatively static to read, > In the period counter arrangement, the largest error would be on the > high frequency side so a 1/100 semitone error on C8 gives a 138ns error > for a single cycle. The "every other clock" at 50MHz for this highest > octave easily gives a single-cycle measurement that would give the > accuracy you need (80ns error from both sides of a single count); Correct. What you describe, with variable capture cycles, is a reciprocal frequecny counter. There are three choices for the Cycles-to-time-over count determination in a reciprocal frequecny counter. a) it can be hard coded. (which I think is what you describe) b) it can be preloaded via SW, which allows elasticity in the gate times. (one might try varying times to reduce beat effects) c) It is Auto-Set by a desired gate time, and smarter logic takes the first whole cycle number larger than the gate time. Option c) is the full benchtop reciprocal Counter, and b) is the variant I'd suggest for this project. Lets SW have full control, without recompile of FPGA, but saves some logic & data bandwidth from c) > As pointed out by someone earlier, counting multiple consecutive periods > rather than averaging multiple counts gives you a much higher precision, > spreading the 80ns error I mentioned above over multiple periods rather > than just one for a per-period error of 80ns/N for an N period count. > Using BlockRAMs to hold the main part of the counters, you have 36 bits > to play with for free. Since the octave counter scales by a factor of 2 > for each octave, all the counts are the same relative size. Yes, with a little design care, on a reciprocal counter you can extend the precision across multiple readings. The trick to to not lose time-counts, or edge-counts - If your HE does that, then [Cycles/Time] can be added downstream for very high precisions. This would enable research into the milli-kelvin thermal shifts going down, long before they became audible Perhaps a variant of this capture-pathway, could be a 'wide tuner' for general piano use - more sales ? Would slash the skill and time needed to tune manually a pianoArticle: 134420
I have a Spartan 3E XC3S500E. According to the data sheet, it has 20 blocks of ram, totalling up to 368,640 bits. I've used it for my FIFO core, which is 5bits width and 65k depth. However, the amount of data that I managed to store inside, seems to be way lesser than 368,640bits. Even before reach 100,000bits, the FIFO output a write_full signal, telling me that it's full. I've no other cores, except my own code. Are there any other mechanism that uses the blockram even though it is not indicated on the Summary page inside my Xilinx ISE?Article: 134421
"Zhane" <me75@hotmail.com> wrote in message news:4b0f65af-207b-41d6-836d-378947084936@b30g2000prf.googlegroups.com... > However, the amount of data that I managed to store inside, seems to > be way lesser than 368,640bits. Even before reach 100,000bits, the > FIFO output a write_full signal, telling me that it's full. > 1. How did you validate the actual number of fifo writes that you performed? Presumably your counter is counting more than once for each time that you think you do a write. 2. What causes the fifo to be written to? Is that signal generated synchronously to the same clock that clocks the fifo? > I've no other cores, except my own code. Are there any other mechanism > that uses the blockram even though it is not indicated on the Summary > page inside my Xilinx ISE? 1. Start with a simulation, get that working. 2. Validate that the inputs to the simulation of the device match what is happening on the actual device Since your code is implementing the fifo, keep in mind that the fifo signal is *saying* that the fifo is full, it might not in fact be *full*. Memory does not send out a signal indicating that it is full, logic that counts events does. KJArticle: 134422
On Aug 9, 4:36=A0pm, Zhane <m...@hotmail.com> wrote: > I have a Spartan 3E XC3S500E. According to the data sheet, it has 20 > blocks of ram, totalling up to 368,640 bits. > > I've used it for my FIFO core, which is 5bits width and 65k depth. > > However, the amount of data that I managed to store inside, seems to > be way lesser than 368,640bits. Even before reach 100,000bits, the > FIFO output a write_full signal, telling me that it's full. > > I've no other cores, except my own code. Are there any other mechanism > that uses the blockram even though it is not indicated on the Summary > page inside my Xilinx ISE? Zhane, you are building a narrow and very deep FIFO. Obviously it does not fit into one BlockRAM. How did you partition it? You should use 5 BRAMs in parallel, each 1 bit wide, and 4 such structures in series for the required depth. That would be most efficient, and would also be fairly simple. This is the only reasonable partitioning. Perhaps you made each BRAM 9 bits wide, and concatenated 20 of them, but that would give you only a depth of about 40k location, since you wasted 4 out of 9 memory locations. You did not mention speed and asynchronous vs synchronous operation. Thus I assume you have no problms there. How did you design the FIFO? Did you use a Wizard, or CoreGen? Peter Alfke, Xilinx ApplicationsArticle: 134423
erm I used the CoreGen to do it. I set it up for 2 independent clocks. Ya.. my writing code is using the same clock as the clock that is fed into the FIFOArticle: 134424
On Aug 10, 7:50=A0am, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Zhane" <m...@hotmail.com> wrote in message > > news:4b0f65af-207b-41d6-836d-378947084936@b30g2000prf.googlegroups.com... > > > However, the amount of data that I managed to store inside, seems to > > be way lesser than 368,640bits. Even before reach 100,000bits, the > > FIFO output a write_full signal, telling me that it's full. > > 1. How did you validate the actual number of fifo writes that you perform= ed? > Presumably your counter is counting more than once for each time that you > think you do a write. > 2. What causes the fifo to be written to? =A0Is that signal generated > synchronously to the same clock that clocks the fifo? > > > I've no other cores, except my own code. Are there any other mechanism > > that uses the blockram even though it is not indicated on the Summary > > page inside my Xilinx ISE? > > 1. Start with a simulation, get that working. > 2. Validate that the inputs to the simulation of the device match what is > happening on the actual device > > Since your code is implementing the fifo, keep in mind that the fifo sign= al > is *saying* that the fifo is full, it might not in fact be *full*. =A0Mem= ory > does not send out a signal indicating that it is full, logic that counts > events does. > > KJ my code is working both in simulation and in real application. Just that when I starts to write a little bit more into the fifo, the fifo's output signal says that it is full and refuse to let me write anymore.
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