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
tenteric wrote: (snip) > I know that. But I'm interesting, is there any real-world cases when > FPGA design was successfull in heavy scientific computation, where > outcome compensating FPGA cost + design cost, etc. There are some I know for searching DNA sequences. I believe they were reasonably successful at overcoming costs, etc. Systolic array is my favorite for such processors. -- glenArticle: 113251
tenteric wrote: (snip) > I need to be more precise - my passion is just very fast computation - > I'm very interesting in implementing any math algorithm thus it will > work as fast as it can. My favorite architecture for such specialized processors is the systolic array. The ones I have seen used are for algorithms using 16 bit fixed point, which is easy. If you want 64 bit floating point it takes a lot more cells, but may be just about reasonable. If you can do it in 64 bit fixed point that would be somewhat easier (that is, more computation per device). -- glenArticle: 113252
John_H wrote: Regarding the frequency range of noise due to sample clock jitter (sampling using an ADC much faster than required for a given band-limited signal): > Since the noise you'll see from the clock jitter will be spread across > the full 25 MHz bandwidth of your 50 MS/s data stream On a second reading, I was wondering if you could explain this a bit further. In the worst-case scenario, we would have an input signal with a purely 4.2 MHz frequency component (would never happen for video, but just for the arguement). If two samples were taken, each experiencing maximum sample clock jitter, but in opposite directions, then they would be seperated by (sample time + 2 * jitter). However, we would treat them as if they were seperated by only (sample time). Wouldn't this only introduce noise up to a frequency of: 4.2 MHz * (sample time + 2 * jitter) / (sample time) ? ie, for 250 ps of jitter on a 20 ns clock, with a 4.2 MHz signal being sampled, I could expect to see noise up to 4.305 MHz...? Or, instead of assuming an input with a purely 4.2 MHz component, go to the other extreme. Assume the input is a constant DC signal. The jitter on the sampling clock wouldn't cause any noise at all here, would it? Please excuse the simple question, this is probably something elementary, but it's new to me! SeanArticle: 113253
Symon wrote: (snip on asynchronous (self timed) logic) > I challenge you to design a metastability free traffic light controller from > 'metastability solved' asynchronous logic. The lights are at a crossroads > out in the sticks with low traffic volume. They are nomally both set RED > until a car comes along. The lights then go GREEN in the direction from > which a vehicle comes from. Make sure your logic doesn't go metastable when > two cars arrive simultaneously from two orthogonal directions. Your > controller must work no matter with whatever time difference the two cars > arrive, and must work on EVERY occasion for EVERY car arrival timing > scenario. Even one mistake in the lifetime of the universe is FAR, FAR too > often for this junction! I went back to see what I wrote before. I didn't say that it never went metastable, only that it wasn't a problem. I was told that sometimes one would see the console lights stop for a little while until the metastability was resolved. For the traffic light I would expect a possible delay from when the cars arrived until one of the lights turned green. As long as both lights can't turn green at the same time, you are still safe. But current FPGAs are not very well designed for self timed logic. All the flip-flops are completely useless! It has been many years since I thought about actual designs (when KA-10's were around). -- glenArticle: 113254
davidc@ad-holdings.co.uk wrote: >Hi, > >I'm trying to create a Count Leading Zero (CLZ) in VHDL for a project >but i'm having difficulty in finding any information what so ever apart >from an explanation as to what it does, can anyone help? What you need is a priority encoder: function priority8to3(inval : std_logic_vector(7 downto 0)) return std_logic_vector is variable ret : integer; variable a: std_logic_vector(2 downto 0); begin a := "000"; --priority encoder. By looping from 7 downto 0, the priority --can be reversed. prio_loop: for i in 0 to 7 loop if inval(i)='1' then ret := i; exit prio_loop; end if; end loop; return a + ret; end; -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 113255
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:9KydnQ6z6aBF_efYnZ2dnUVZ_rKvnZ2d@comcast.com... > Symon wrote: > > (snip on asynchronous (self timed) logic) > >> I challenge you to design a metastability free traffic light controller >> from 'metastability solved' asynchronous logic. The lights are at a >> crossroads out in the sticks with low traffic volume. They are nomally >> both set RED until a car comes along. The lights then go GREEN in the >> direction from which a vehicle comes from. Make sure your logic doesn't >> go metastable when two cars arrive simultaneously from two orthogonal >> directions. Your controller must work no matter with whatever time >> difference the two cars arrive, and must work on EVERY occasion for EVERY >> car arrival timing scenario. Even one mistake in the lifetime of the >> universe is FAR, FAR too often for this junction! > > I went back to see what I wrote before. I didn't say that it never went > metastable, only that it wasn't a problem. I was told that sometimes one > would see the console lights stop for a little while until the > metastability was resolved. For the traffic light I would expect a > possible delay from when the cars arrived until one of the lights > turned green. As long as both lights can't turn green at the same time, > you are still safe. > Hi Glen, Weeeelll, yes and no! I was just trying to make a point that there is a finite probability that the lights will stay red until the drivers drop dead of old age. Not exactly safe! Nearly, but not exactly. :-) Likewise, the PDP-10 console lights _could_ stop for months. So, I would respectfully disagree with your statement that "The solution to metastability is asynchronous logic (also called self-timed logic).". Furthermore, the implication that synchronous design is any worse than asynchonous design I think is not true. As Mike said in his post, "The D-flop is also an asynchronous circuit.". > > But current FPGAs are not very well designed for self timed logic. All > the flip-flops are completely useless! It has been many years since I > thought about actual designs (when KA-10's were around). > > -- glen > Right, I agree you make a good point that FPGAs are not the route to take for asynchronous logic circuits. Best regards, Symon.Article: 113256
Hi, I would like to send some data back via my jtag cable from my spartan-3 board to the computer. I have read the article below, but it appears that this method works only with modelsim. http://www.xilinx.com/publications/xcellonline/xcell_53/xc_pdf/xc_jtag53.pdf I'm to cheap to buy modelsim at present and would enjoy the exercise of creating something of my own, I am currently using the Xilinx webpack 7.1 Can anyone propose a method in which i can send simple data back? will it be a case of instansiating the JTAG within the spartan and doing it this way? can I avoid reinventing by using some TCL and interact with something within the ISE for doing this? (is there a good tutorial on TCL aimed specifically at Xilinx tools, i can find bits and pieces but nothing from the ground up, i've messed with the shell but thats really as far as i got in terms of doing anything productive) Cheers DavidArticle: 113257
All, I'm having an extraoridnarily difficult time with my first FPGA project and am very frustrated. I have a board designed around the EP1C6 Cyclone device. The Quartus programmer is able to detect the EP1C6 on a JTAG boundary scan. I'm able to initiate programming the device over the JTAG port, but Quartus gives me an error CONF_DONE failed to go high on device 1. I reviewed the Cyclone datasheet, and 13-19 in particular, "JTAG Configuration of Single Cyclone FPGA." This diagram does not show CONF_DONE going to the programming header. Why is Quartus complaining that CONF_DONE isn't going high when that signal isn't supposed to go to the programming header? More importantly, is there anything I can do to circumvent this problem? Many thanks, -NevoArticle: 113258
I get this error trying to program a serial device using a homemade ByteBlaster II cable as described in Altera's "ByteBlaster II Download Cable User's Guide." I thought this cable supports active serial programming. What am I doing wrong? Thanks, -NevoArticle: 113259
As long as you limit yourself to 10BASE-T, it is quite possible to implement the PHY in the FPGA, and for very low logic usage. See an implementation example http://www.fpga4fun.com/10BASE-T0.html "Steve" <eejju@polyu.edu.hk> wrote in message news:1165494117.52713@nsserver1.polyu.edu.hk... > Hi all, > > I want to add an Ethernet interface to my FPGA board for data > transmission. But I'm not sure which scheme I should use. > > A) There's a PHY on the FPGA board, but I don't have much knowledge or > experience on MAC. The protocol seems complicated and not easy to > implement in a short time. Is it possible to develop a small and simple > MAC? My idea is packing data to form a standard TCP or UDP packet and > using the PHY to send out or receive it. Another reason I don't want using > a full MAC is it costs too much resources (~2000 slices). If I use > MicroBlaze+OPB MAC, I can't afford the license fee. > > B) Using another external Ethernet micro-controller, such as Rabbit > microprocessor. I can develop an interface between FPGA and uC for data > transmission. But I'm wondering how fast the speed is? > > C) Using micro-controller + (MAC+PHY Ethernet single chip). Then porting > uClinux or lwip to the uC and hanging FPGA to the address/data bus of the > uC. > > Any suggestions? Thank you. > > JJ >Article: 113260
jim wrote: > get the following error while trying to create a test bench. If this is a vhdl testbench, post the code to comp.lang.vhdl -- Mike TreselerArticle: 113261
> The un-operated functions are not fixed !!! Malfunctions are > irregular..................... > Also, the source of VHDL had been verified in Altera device > (EPF10K100ARC240) > In Altera, all functions are operated correctly........... Altera-devices power-up with all FFs set to 0, while Actel power-up random, I think. Do you have a proper reset-circuit? Thomas www.entner-electronics.comArticle: 113262
sp_mclaugh@yahoo.com wrote: <snip> > As did I ! I'm looking into the differential clock approach now, though > I fear that it won't be do-able. I *think* the Spartan 3 can do > differential output, using special features of the IOB's, but it seems > that some external setup/calibration components (resistors) are > required. It would be up to Digilent (producer of my starter board) to > have properly implemented these. There appear to be quite a few > "special" output modes (ie, LVPECL, etc) and I would be lucky for them > to have implemented exactly the one I need. Building my own PCB for the > Spartan is out of the question at this time (it would take me a year or > more to learn all the necessary skills). I could be mistaken - maybe > there is an easy way. That's just my current best-guess after a few > hours of research. Driven differential signals don't need the resistor networks in the Spartan3. You can generate an LVDS signal from pins marked as complementary pairs without any passives involved; a 100 ohm differential termination at the differential ADC clock is still important. The ideal situation would have these signals routed next to each other with specific differential impedances but I expect your best bet will be to find the complementary signals that don't have anything else routed between and are roughly the same length. There might not be a lot to choose from. If I recall, the Digilent Spartan3 board has a 40-pin header with one power and one ground (or similarly abysmal path for return currents. The header you connect to might be responsible for introducing most of your system jitter per Gabor's comments on return current. If you have many unused signals on that connector, driving them to output logic low with a strong IOBSTANDARD will help. Changing them to hard wired grounds would be better still. I believe the ribbon cable helps add to the size of the crosstalk effects so keeping that short will also help. But the differential clock is that much more attractive. You might consider using a "dead bug" addition to your Digilent board. There are small differential drivers available. If you tack the chip upside down by the oscillator (imagine a bug with its legs in the air) you can wire the oscillator output right to the discrete differential driver input. Use a twisted pair to deliver this clock directly to a 2-pin header on your ADC board. If you're not designing the board and it already has only a single-ended input, you can tack a differential receiver to your ADC board in the same way. If you use this approach to deliver a very clean clock (making up for a poorly designed signal header) consider hot-gluing or epoxying the twisted pair to the board so you have a mechanical strain relief that keeps the wires from ripping off your tacked-on chip. <snip> > That's good to know. I wonder if I should still worry about routing the > clock through the FPGA's output header to drive the ADC. Perhaps there > would be added jitter due to other reasons, such as active switching > flip-flops near the driving IOB... ? I'm basically repeating this from > another post I've read, I don't know what order of noise we're talking > about here, and whether it's negligible compared to my poor oscillator. If you're using "mild" I/O switching strengths, you'll be better off than using strong drives. If you look at the data sheet for SSO recommendations, you'll see which standards tend to be nasty and which "play nice." If you're dealing with inputs rather than outputs, things will be much better - it's the current surge from driving the outputs that cause the majority of the jitter-inducing crosstalk. <snip> <snip> > Ah yes, a timing budget is something I will be doing. Of course, the > rest of my design isn't finished yet, so I don't yet know what type of > max setup times I'll need. I guess if I use input buffers (using > IOB's), the setup time to get the data into the FPGA will be > independent of the rest of my design, right? I've never touched any IOB > features before, but it seems easy (just set a single attribute, I > think...?). If you arrange the design to register the ADC outputs directly in the FPGA's IOBs, you can find the setup and hold times in the Spartan3 data sheet without having to look at the Timing Analyzer report. Even when I specify register packing in IOBs and use input registers, I still use OFFSET IN (BEFORE) constraints on my input signals to get a very big warning if something didn't end up in the IOB like I planned. > On the other hand, couldn't I avoid the issue altogether by using a DCM > to adjust my FPGA clock by the clock-to-out time of the ADC? That way, > the data is ready right on the rising edge of my FPGA clock. It seems > that I can make adjustments in increments of 1/256 of my clock > frequency. The DCM gives you flexibility. But when you do your timing budget, you might find there's a better way to reduce the uncertainties rather than just shifting the clock by the reported delay. The shift might be close to optimal but the delay is specified as a worst case, not typical. When you have a "best clock scheme" figured out and the DCM isn't *between* the oscillator and the ADC, you might get better results with the DCM but not necessarily withe any added phase shift. <snip> > So in essence, by sampling at 50 MSPS rather than the minimum of 8.4 > MSPS, and then applying a low pass with cutoff around 4.2 MHz, I'm > getting rid of about (25-4.2)/25 * 100% = 83% of the noise to to jitter > on the ADC clock (assuming the noise content is uniformly distributed > from 0 to 25 MHz)... Does that calculation sound right (assumes ideal > filters, etc)? If so, what a pleasant surprise! It *sounds* right but I haven't been performing these calculations myself recently so my view from 20,000 feet says it's pretty reasonable. >> You seem on target with knowing much of what to look for in the design. >> I hope it's fun. > > I appreciate the kind words, though I think I'm right on the borderline > capability-wise. Let's hope I'm not right below that line - close > enough to waste a lot of time, but just too far to ever get it working! > But yes, it should be a fun project. > > The info you gave was very helpful, thanks! > > Regards, > > SeanArticle: 113263
Tommy Thorn ha scritto: > > > Maybe I misunderstood, but it already does synthesize. David Ashley, as > > > posted here earlier, did the needed modification to get it running on > > > the Spartan 3E Start Kit. With just a .ucf adjustment, it worked on > > > Digilent's Spartan 3E1600 board. Hi, thanks for the answer; I downloaded the code an I try to sintetize it with ISE Webpack 8.2i (Xilinx XST Compiler) but in my Spartan 3E starter kit board don't work (ddr sdram Micron MT46V32M16TG-6T). I don't know how can I debug the core; maybe is possible to use the chipscope, but I never use it before an I don't know if is the right tools to use. I guess wich is the things that I must to carefully syntetize to obtain the goal (like the working simulation). DanieleArticle: 113264
sp_mclaugh@yahoo.com wrote: > John_H wrote: > > Regarding the frequency range of noise due to sample clock jitter > (sampling using an ADC much faster than required for a given > band-limited signal): > >> Since the noise you'll see from the clock jitter will be spread across >> the full 25 MHz bandwidth of your 50 MS/s data stream > > On a second reading, I was wondering if you could explain this a bit > further. In the worst-case scenario, we would have an input signal with > a purely 4.2 MHz frequency component (would never happen for video, but > just for the arguement). If two samples were taken, each experiencing > maximum sample clock jitter, but in opposite directions, then they > would be seperated by (sample time + 2 * jitter). However, we would > treat them as if they were seperated by only (sample time). > > Wouldn't this only introduce noise up to a frequency of: > 4.2 MHz * (sample time + 2 * jitter) / (sample time) ? > > ie, for 250 ps of jitter on a 20 ns clock, with a 4.2 MHz signal being > sampled, I could expect to see noise up to 4.305 MHz...? The jitter introduces amplitude errors, not frequency errors. Any amplitude or frequency error can induce problems in the other domain (which is why the ADC frequency error - phase, actually - induces the amplitude error). You're analyzing the signal as if it's in an ideal sampling domain so the errors will show up as amplitude noise. > Or, instead of assuming an input with a purely 4.2 MHz component, go to > the other extreme. Assume the input is a constant DC signal. The jitter > on the sampling clock wouldn't cause any noise at all here, would it? The jitter won't induce noise on the DC signal, correct. Great observation. You still get the benefit of the ADC noise being reduced at DC. > Please excuse the simple question, this is probably something > elementary, but it's new to me! > > Sean If you were to only sample at 8.4 MS/s, your 4.2 MHz sinewave would have maximum sample errors at the highest slew of the signal with maximum deviations that constructively add to produce the maximum error. When you have a 50 MS/s stream looking at the 4.2 MHz signal, your maximum values are still the maximums but you throw many other samples in with that same period. Each sample point will have similar noise power, but weighted by the signal slew rate; the top and bottom of the sinusoid are closer to DC for jitter analysis reasons so the noise power isn't constant for all sample points but significantly reduced in the slower slew regions. Filtering over the wider bandwidth allows the worst sample errors to be filtered with the smallest sample errors leading to an overall reduction in jitter-induced noise. I would expect most of your jitter to be high-frequency since you're coming from a crystal source with the induced noise coming from that "ideal" signal getting phase distortions through various buffer stages from the slight induced shifts of threshold point. Higher frequency jitter is easier to remove from your overall system noise than low frequency jitter that induces real phase shifts in your observed data.Article: 113265
"ed_h" <ehenciak@gmail.com> wrote in message news:1165645305.866775.178560@16g2000cwy.googlegroups.com... >I got this working today using the following configuration : Congratulations! You should feel good now! :) I am now trying to get MGTs running and don't feel even half as good as you probably are :( /MikhailArticle: 113266
"Gabor" <gabor@alacron.com> wrote: > >sp_mclaugh@yahoo.com wrote: >> Hello, >> >> I'm in the middle of a project which involves digitizing and decoding >> baseband NTSC composite video. Right off the top, I'll let everybody >> know that this is part of an educational project (part of it for a >> university project, though it's largely a hobbyist type project). I >> realize that the project will be useless in a couple years, and that >> there are pre-made devices out there, but I still want to do it. >> >> That being said, I think the hardest part of the whole project (for me) >> is just getting the data into the FPGA (cleanly)! I know very little >> about clock management, and I'm worried that I'm pushing the limits of >> my setup. Let me briefly describe what I'm doing. >> >> The traditional way to sample NTSC video, as I understand it, is to use >> dedicated chips to derive a "pixel clock" off of the hsync. This clock >> then feeds the ADC, and perhaps the FPGA. I am not doing this. I am >> using a fixed, free-running crystal oscillator clock (50 MHz Epson >> SG-8002JF). For the record, that clock came on my Digilent Spartan 3 >> starter board, which I'm using for the project. I plan on sampling at >> the full 50 MSPS, even though the video signal is band-limited to about >> 4.2 MHz. >> > >Quick calculation: >using 4.2 MHz full scale (of the ADC input range) sine wave >4.2MHz is about 26 Mradians/s >ADC input range corresponds to -1 to +1 of normalized sine >1 LSB of 8-bit ADC is therefore 1/128 (normalized). >1 / (26M * 128) is about 0.3 nS > >So for a 1 LSB sampling error, you could live with 300 pSec of >sampling jitter. My guess is that the threads you looked at >were concerned about significantly smaller acceptable jitter, >as would be the case in most networking applications where >the sampling rate and bandwidth are closer to the same >frequency. Isn't this calculation a bit crude? I suppose the spectrum of the jitter is also important. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 113267
Nevo wrote: > Why is Quartus complaining that CONF_DONE isn't going high when that signal > isn't supposed to go to the programming header? More importantly, is there > anything I can do to circumvent this problem? Quartus, using JTAG, can read the state of this pin without it having to be run to the header. Break out the scope and connect it to CONF_DONE. Does it go high? If not, then the FPGA is not properly configured. This can be caused by a faulty JTAG connection, something holding CONF_DONE low, etc. MarcArticle: 113268
As for your previous post, I've got it printed up and sitting on my workbench area. Lots of good info in there. I'll just respond to this one for now. John_H wrote: > sp_mclaugh@yahoo.com wrote: > > In the worst-case scenario, we would have an input signal with > > a purely 4.2 MHz frequency component (would never happen for video, but > > just for the arguement). If two samples were taken, each experiencing > > maximum sample clock jitter, but in opposite directions, then they > > would be seperated by (sample time + 2 * jitter). However, we would > > treat them as if they were seperated by only (sample time). > > > > Wouldn't this only introduce noise up to a frequency of: > > 4.2 MHz * (sample time + 2 * jitter) / (sample time) ? > > > > ie, for 250 ps of jitter on a 20 ns clock, with a 4.2 MHz signal being > > sampled, I could expect to see noise up to 4.305 MHz...? > > The jitter introduces amplitude errors, not frequency errors. Any > amplitude or frequency error can induce problems in the other domain > (which is why the ADC frequency error - phase, actually - induces the > amplitude error). You're analyzing the signal as if it's in an ideal > sampling domain so the errors will show up as amplitude noise. Yes, but assume that we have a pure 4.2 MHz sine wave, and we sample where the slew rate is fastest (at the zero crossings, if the sinusoid goes from -1 to +1). Call the difference between two such samples max_change. Then, with worst-case jitter, instead of seeing max_change between two samples, we see max_change * (t_sample + 2*t_jitter) / (t_sample). This assumes a first-order expansion around the fast-slew area. In other words, treat that area as having a constant slope (good approx for a sinusoid), so the amplitude between samples is linearly related to the time between samples. But, once we read the values into the FPGA, we treat them as if they were only seperated by t_sample. If the change-per-unit-time increases, doesn't that directly translate to a change in maximum frequency? So... is my 4.305 MHz cutoff above correct? > > Or, instead of assuming an input with a purely 4.2 MHz component, go to > > the other extreme. Assume the input is a constant DC signal. The jitter > > on the sampling clock wouldn't cause any noise at all here, would it? > > The jitter won't induce noise on the DC signal, correct. Great > observation. You still get the benefit of the ADC noise being reduced > at DC. So what happens between these two extremes (signal being either completely DC or completely high frequency - 4.2 MHz)? Surely if the signal was completely 1 Hz, we wouldn't expect to see jitter uniformly distributed from 0 to 25 MHz, correct? Shouldn't the maximum frequency of jitter-induced noise be a percent (>100%) of the maximum frequency of the input signal? > If you were to only sample at 8.4 MS/s, your 4.2 MHz sinewave would have > maximum sample errors at the highest slew of the signal with maximum > deviations that constructively add to produce the maximum error. Yes, I think we are talking about the same thing (compare to what I mentioned above). ie, the first sample is jittered so that it occurs too early, while the second occurs too late -- and all of this happening where slew is the highest. > When > you have a 50 MS/s stream looking at the 4.2 MHz signal, your maximum > values are still the maximums but you throw many other samples in with > that same period. Each sample point will have similar noise power, but > weighted by the signal slew rate; the top and bottom of the sinusoid are > closer to DC for jitter analysis reasons so the noise power isn't > constant for all sample points but significantly reduced in the slower > slew regions. Filtering over the wider bandwidth allows the worst > sample errors to be filtered with the smallest sample errors leading to > an overall reduction in jitter-induced noise. Ah, now that does make sense to me. If my signal really *was* just a sinusoid (ie, a single tone), then maybe I could even develop some algorithm to pick out the min and max samples (where slew was lowest). Of course, that's not possible with my (real) video signal. > I would expect most of your jitter to be high-frequency since you're > coming from a crystal source with the induced noise coming from that > "ideal" signal getting phase distortions through various buffer stages > from the slight induced shifts of threshold point. Higher frequency > jitter is easier to remove from your overall system noise than low > frequency jitter that induces real phase shifts in your observed data. The source of the jitter is beyond my knowledge, but this is certainly good to hear. I will definitely low-pass my signal as close as I can to 4.2 MHz (depending on how steep my filter is, which depends on how much FPGA real estate I have to spare). One last question/comment. Wouldn't this be an ideal example of when to use dithering? ie, my LSB isn't really significant, so I shouldn't treat it as if it was. I've never used dithering before, but maybe I can use an LFSR (linear feedback shift register) or some other technique to add one LSB of randomness to the samples... ?Article: 113269
I got my self stuck in that I have a V4 design with a 16-bit flash and a 32-bit peripheral device on the same external bus. I am using a opb_emc with two memory banks and datawidth matching to talk to them. The problem is I connected the wrong 16 data lines to the 16-bit flash. If I swap the halves in my .ucf the flash works fine but the peripheral regs are word swapped. If I swap them back the peripheral device is fine but obviously flash no longer works. The question: looks like the opb_emc VHDL is somewhere in the bowels of EDK. Dare I try to hack that code to use the other 16 data lines when performing a datawidth match for the 16-bit bank? Is there a cleaner solution? Thanks, ClarkArticle: 113270
On 2006-12-09, beagle197@hotmail.com <beagle197@hotmail.com> wrote: > to develop a custom data encoder(*3) Verilog module that can be > accessed via C, and I am trying to determine if developing the module > as device that attaches to the OPB would be a good choice of There's a Xilinx IP block called opb_ipif (IP interface) specifically for this. If you're using XPS there's a wizard to make IP blocks and one of the steps will offer to drag one of these in for you. The OBP BRAM block is just a thin layer between a BRAM and an opb_ipif, for example. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 113271
On 2006-12-10, Anonymous <someone@microsoft.com> wrote: > I got my self stuck in that I have a V4 design with a 16-bit flash and a > 32-bit peripheral device on the same external bus. I am using a opb_emc with > two memory banks and datawidth matching to talk to them. The problem is I > connected the wrong 16 data lines to the 16-bit flash. Write a wrapper that muxes your data bus by looking at the chip enable lines from the EMC. You'll need to connect to the Mem_DQ_I/O/T (at least in Verilog, maybe VHDL can mux an inout?) rather than the Mem_DQ_IO. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 113272
Nevo, I'm not sure if you're using a development board or a board designed by you, but the CONF_DONE needs to have an external pull-up on the board. What is the mode of configuration? What are you using for your configuration device? Rob "Nevo" <nevo_n@hotmail.com> wrote in message news:SmCeh.122$495.9@trnddc06... > All, > > I'm having an extraoridnarily difficult time with my first FPGA project > and am very frustrated. > > I have a board designed around the EP1C6 Cyclone device. The Quartus > programmer is able to detect the EP1C6 on a JTAG boundary scan. I'm able > to initiate programming the device over the JTAG port, but Quartus gives > me an error CONF_DONE failed to go high on device 1. > > I reviewed the Cyclone datasheet, and 13-19 in particular, "JTAG > Configuration of Single Cyclone FPGA." > > This diagram does not show CONF_DONE going to the programming header. > > Why is Quartus complaining that CONF_DONE isn't going high when that > signal isn't supposed to go to the programming header? More importantly, > is there anything I can do to circumvent this problem? > > Many thanks, > > -Nevo >Article: 113273
Hello, I am working with FFT v.3.2 from Xilinx. Some questions relate directly to that core, some do not. 1. Why is block floating point unavailable for Pipelined/streaming FFT? Is it because the dynamic range is too hard to predict? 2. a) Is the output of A/D converter fixed point (generally)? b) Then only division can introduce floating point, right? 3. For the output ordering, the output data can be presented either in natural order or in bit/digit reverse order. Presenting data in natural order requires additional resources. a) Does it mean that the output of radix-2 butterflies is in bit/digit reverse order? b) Also, isn't the output the frequency spectrum, so what does bit/digit reverse order represent? c) Why would anyone want the output data with the indexes that are (binary number) reversed? 4. In version 3.1, when using Pipelined I/O the data had to be scaled, in version 3.2 user has a choice of scaled and unscaled data. Why would someone want to use unscaled (unless you always know what your inputs are)? Thanks, VitaliyArticle: 113274
Hello,
I am using FFT v3.2 core from Xilinx. I have Xilinx ISE/Model Sim. The
outputs of the core are xk_re and xn_re.
1) I am expanding Xilinx-provided test bench file. I am trying to write
the outputs to .out file. Below are the lines of the code I'm using for
that.
if (done='1' and busy='1') then
i1<=1;
end if;
while (busy='1' and i1=1) loop
write(my_line, xk_re);
writeline(my_output, my_line);
wait until clk='1';
end loop;
Basically, I want to write new value each clock cycle. However, the
above procedure prevents the output produced (meaning xk_re and xn_re
stay at 0, however xk_index does incrementat each clock cycle after
done bit is issued by the core.
I have also tried the following just to see if writing anything (simple
counter in this case) during the time the data is supposed to be
produced will prevent the data to be output. And, inded, the data was
not produce (xk_im and xk_re remained at zero).
if (done='1' and busy='1') then
i1<=1;
end if;
while (busy='1' and i1=1) loop
write(my_line, i2);
writeline(my_output, my_line);
i2<=i2+1;
wait until clk='1';
end loop;
Any suggestions?
2) The output of the core is two's complement. Is there a standard
procedure in VHDL to transform the data from two's complement to
integer?
Thanks,
Vitaliy
Ryerson University
----------------------------------------------------
-- Input 9.375 MHz (period - 106.67ns) signal.
-- This should apper in bin 768
-- Fs = 50 MHz (period - 20 ns)
-- FFT Points = 4096
-- Bin Size = 50 MHz / 4096 points = 12.207 kHz
-- 9.375 MHz / 12.207 kHz = 768 Bin
----------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
use ieee.std_logic_arith.all;
use ieee.numeric_std.all;
use std.textio.all;
use ieee.std_logic_textio.all;
ENTITY design_top_tb IS
END design_top_tb;
ARCHITECTURE behavior OF design_top_tb IS
constant CLOCK_PERIOD : time := 20 ns;
constant HALF_CLOCK_PERIOD : time := CLOCK_PERIOD / 2;
file DATA_FILE : text is in "Copy_of_sine_9_375mhz_1.dat";
COMPONENT design_top
PORT(
xn_re : IN std_logic_vector(23 downto 0);
xn_im : IN std_logic_vector(23 downto 0);
start : IN std_logic;
nfft : IN std_logic_vector(3 downto 0);
nfft_we : IN std_logic;
fwd_inv : IN std_logic;
fwd_inv_we : IN std_logic;
scale_sch : IN std_logic_vector(11 downto 0);
scale_sch_we : IN std_logic;
ce : IN std_logic;
clk : IN std_logic;
rst : IN std_logic;
xk_re : OUT std_logic_vector(23 downto 0);
xk_im : OUT std_logic_vector(23 downto 0);
xn_index : OUT std_logic_vector(11 downto 0);
xk_index : OUT std_logic_vector(11 downto 0);
rfd : OUT std_logic;
busy : OUT std_logic;
dv : OUT std_logic;
edone : OUT std_logic;
done : OUT std_logic;
ovflo : OUT std_logic;
locked : OUT std_logic
);
END COMPONENT;
SIGNAL i : integer;
SIGNAL i1 : integer:=2; --used for writing
SIGNAL i2 : integer:=1;
SIGNAL xn_re : std_logic_vector(23 downto 0) :=
"000000000000000000000000";
SIGNAL xn_im : std_logic_vector(23 downto 0) :=
"000000000000000000000000";
SIGNAL start : std_logic := '0';
SIGNAL nfft : std_logic_vector(3 downto 0) := "1100"; -- for 4096 pt
fft
SIGNAL nfft_we : std_logic := '0';
SIGNAL fwd_inv : std_logic := '1'; -- FFT=1 IFFT=0
SIGNAL fwd_inv_we : std_logic := '0';
SIGNAL scale_sch : std_logic_vector(11 downto 0) := "000000000000";
SIGNAL scale_sch_we : std_logic;
SIGNAL ce : std_logic := '1'; -- FFT always enabled
SIGNAL clk : std_logic := '0';
SIGNAL rst : std_logic := '1'; -- Start with DCM in reset
SIGNAL xk_re : std_logic_vector(23 downto 0);
SIGNAL xk_im : std_logic_vector(23 downto 0);
SIGNAL xn_index : std_logic_vector(11 downto 0);
SIGNAL xk_index : std_logic_vector(11 downto 0);
SIGNAL rfd : std_logic := '0';
SIGNAL busy : std_logic := '0';
SIGNAL dv : std_logic := '0';
SIGNAL edone : std_logic := '0';
SIGNAL done : std_logic := '0';
SIGNAL ovflo : std_logic := '0';
SIGNAL locked : std_logic := '0';
BEGIN
uut: design_top PORT MAP(
xn_re => xn_re,
xn_im => xn_im,
start => start,
nfft => nfft,
nfft_we => nfft_we,
fwd_inv => fwd_inv,
fwd_inv_we => fwd_inv_we,
scale_sch => scale_sch,
scale_sch_we => scale_sch_we,
ce => ce,
clk => clk,
rst => rst,
xk_re => xk_re,
xk_im => xk_im,
xn_index => xn_index,
xk_index => xk_index,
rfd => rfd,
busy => busy,
dv => dv,
edone => edone,
done => done,
ovflo => ovflo,
locked => locked
);
-- Clock
clock_proc : process
begin
wait for HALF_CLOCK_PERIOD;
clk <= not clk;
end process;
control : process
begin
wait for (100 ns+(CLOCK_PERIOD)); --wait for
GSR
rst <= '0'; --release DCM
reset
wait until (locked = '1' and locked'event); --wait for
DCM lock
wait for ((HALF_CLOCK_PERIOD)+(CLOCK_PERIOD*2));
nfft_we <= '1';
fwd_inv_we <= '1';
scale_sch <= "010101010101";
scale_sch_we <= '1';
wait for CLOCK_PERIOD;
nfft_we <= '0';
fwd_inv_we <= '0';
scale_sch_we <= '0';
wait for CLOCK_PERIOD;
start <= '1'; --start
loading and transform
wait for (CLOCK_PERIOD*8192);
wait; -- will wait forever
end process;
data_read : process
variable input_line : line;
variable input_data : integer;
file my_output : TEXT open WRITE_MODE is "file_io.out";
-- above declaration should be in architecture declarations for
multiple
variable my_line : LINE;
variable my_output_line : LINE;
begin
i <= 0;
xn_re <= "000000000000000000000000";
xn_im <= "000000000000000000000000";
wait for CLOCK_PERIOD; -- push data
to negative edge transition
while not endfile(DATA_FILE) loop
readline(DATA_FILE, input_line);
read(input_line, input_data);
xn_re <= conv_std_logic_vector(input_data, 24);
i <= i + 1; --line index that returns the line number of the
input file
wait for CLOCK_PERIOD;
end loop;
if (done='1' and busy='1') then
i1<=1;
-- if (i1=0) then
-- i2<=1;
end if;
while (busy='1' and i1=1) loop
write(my_line, xk_re);
writeline(my_output, my_line);
---- i1 <= i1-1;
wait until clk='1';
end loop;
-- if (i1=0) then
-- i2<=1;
-- end if;
-- wait for CLOCK_PERIOD * 12500; --12500
-- ASSERT (FALSE) REPORT
-- "Simulation successful (not a failure). No problems detected."
-- SEVERITY FAILURE;
end process;
----
END;
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