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 Jan 22, 4:08 pm, tersono <ethel.thef...@ntlworld.com> wrote: > On Tue, 22 Jan 2008 12:33:38 -0800 (PST), shadfc > > <jay.winein...@gmail.com> wrote: > > <snip>> I am using pin D7 on the J4 Header as a test input for a single > >gate. I have that pin specified in the UCF as follows: > > > NET "gateA" LOC = "D7" | IOSTANDARD = LVTTL | SLEW = SLOW | > >DRIVE = 6 ; > > <snip> > > I'm probably not addressing the main problem here, but... > > for an input, do you need specify SLEW and DRIVE? > > (Indeed, does it make sense to do so?) > > Correction invited. > -- > Per ardua ad nauseam Probably not. I had it configured without them previously and the same problem existed then, so I just grabbed the relevant lines for each pin from the boards starter guide (UG320).Article: 128351
On Jan 22, 12:33=A0pm, shadfc <jay.winein...@gmail.com> wrote: > Hi, > =A0 =A0 I'm trying to create a "chrono" to measure the muzzle velocity of > a paintball gun. =A0Basically, I'm just making a two gate system out of > some IR leds and photosensors which will hook into my Spartan 3E > Starter board. The FPGA will measure the time (clock ticks, really) > between gate changes and then do the division to arrive at the > velocity, which it will display on the LCD. > =A0 =A0I'm having some problems getting the inputs into the FPGA to > register correctly. =A0The gate circuit uses the QSE156 (http://www.fairch= ildsemi.com/ds/QS/QSE156.pdf) photosensor by Fairchild which > provides a TTL/LSTTL compatible output. =A0Following the Xilinx > guidelines for making 5V inputs safe, I've connected the TTL output to > the board through a 390Ohm series resister. > =A0 =A0I am using pin D7 on the J4 Header as a test input for a single > gate. =A0I have that pin specified in the UCF as follows: > > =A0 =A0 =A0 =A0 NET "gateA" LOC =3D "D7" | IOSTANDARD =3D LVTTL | SLEW =3D= SLOW | > DRIVE =3D 6 ; > > =A0 =A0Now, the problem I am having is that I cant get the input to be > stable on both high and low signals from the photosensor. =A0It appears > to oscillate at a fairly high frequency (MHz range). I tried to > debounce the input (with 16 bits) and then incremented a counter on > every rising edge of the stabilized input, but using the Spartans 8 > LEDs to display the counter still was a blur. =A0So, by that, I surmised > that the input is oscillating between high and low. > =A0 =A0I would appreciate any input on this since I'm at a loss. =A0Do I > have my FPGA input settings correct? =A0Must I use a wire less than X > inches to connect the output of the photosensor to the board? Etc, > etc. =A0What am I missing? > > thanks > Jay The drive and slew are "don't cares" for the case of the input. The oscillation is odd. Do you have a decoupling cap anywhere near your sensor? I could see an issue if the sensor switches, causing the VCC at the sensor to drop, causing the sensor to switch, and so on. The switching time is specified in the data sheet as microseconds suggesting the device is completely unstable by your measurements. The FPGA should be fine. I'd suggest wiring the sensor input through the FPGA to two of your LEDs: one to indicate "on" and one to indicate "off" such that two LEDs of the same intensity indicate ~ 50% each way. It sure sounds like you could use an oscilloscope. - John_HArticle: 128352
On Jan 22, 11:21=A0am, "Symon" <symon_bre...@hotmail.com> wrote: > > Hi Peter, > Will the hardware and HDL be open source? You might find some of us might > like to add some custom features. I guess it'll have a 2x7 JTAG download, > connector, right? > Cheers, Syms. The plan is to offer frequency control as well as functional reconfiguration via USB. JTAG configuration has always been available on all the boxes that we built in the past. (2 years ago we built 250 boxes of the previous generation, to equip our FAEs. Only 640 MHz, 70 ps jitter + some wander. We have tougher goals now !) Peter AlfkeArticle: 128353
shadfc wrote: > Hi, > The gate circuit uses the QSE156 (http:// > www.fairchildsemi.com/ds/QS/QSE156.pdf) photosensor by Fairchild which > provides a TTL/LSTTL compatible output. Following the Xilinx > guidelines for making 5V inputs safe, I've connected the TTL output to > the board through a 390Ohm series resister. These devices have schmitt transfers, so if it really is oscillating, check the powersupply decoupling. Being a high gain analog front end, It will need very good decoupling right at the device. You will probably also need to shroud the sensor, as across-paint-ball distances are at the upper end. -jgArticle: 128354
On Jan 22, 5:20 pm, John_H <newsgr...@johnhandwork.com> wrote: > On Jan 22, 12:33 pm, shadfc <jay.winein...@gmail.com> wrote: > > > > > Hi, > > I'm trying to create a "chrono" to measure the muzzle velocity of > > a paintball gun. Basically, I'm just making a two gate system out of > > some IR leds and photosensors which will hook into my Spartan 3E > > Starter board. The FPGA will measure the time (clock ticks, really) > > between gate changes and then do the division to arrive at the > > velocity, which it will display on the LCD. > > I'm having some problems getting the inputs into the FPGA to > > register correctly. The gate circuit uses the QSE156 (http://www.fairchildsemi.com/ds/QS/QSE156.pdf) photosensor by Fairchild which > > provides a TTL/LSTTL compatible output. Following the Xilinx > > guidelines for making 5V inputs safe, I've connected the TTL output to > > the board through a 390Ohm series resister. > > I am using pin D7 on the J4 Header as a test input for a single > > gate. I have that pin specified in the UCF as follows: > > > NET "gateA" LOC = "D7" | IOSTANDARD = LVTTL | SLEW = SLOW | > > DRIVE = 6 ; > > > Now, the problem I am having is that I cant get the input to be > > stable on both high and low signals from the photosensor. It appears > > to oscillate at a fairly high frequency (MHz range). I tried to > > debounce the input (with 16 bits) and then incremented a counter on > > every rising edge of the stabilized input, but using the Spartans 8 > > LEDs to display the counter still was a blur. So, by that, I surmised > > that the input is oscillating between high and low. > > I would appreciate any input on this since I'm at a loss. Do I > > have my FPGA input settings correct? Must I use a wire less than X > > inches to connect the output of the photosensor to the board? Etc, > > etc. What am I missing? > > > thanks > > Jay > > The drive and slew are "don't cares" for the case of the input. The > oscillation is odd. Do you have a decoupling cap anywhere near your > sensor? I could see an issue if the sensor switches, causing the VCC > at the sensor to drop, causing the sensor to switch, and so on. The > switching time is specified in the data sheet as microseconds > suggesting the device is completely unstable by your measurements. > The FPGA should be fine. > > I'd suggest wiring the sensor input through the FPGA to two of your > LEDs: one to indicate "on" and one to indicate "off" such that two > LEDs of the same intensity indicate ~ 50% each way. It sure sounds > like you could use an oscilloscope. > > - John_H I tried what you suggested and wired the LEDs so that half are on when the input is high and the other half are on when the input is low. With my gate circuit disconnected, the LEDs sit in the off (input low) state, but as soon as I connect my circuit, they all light up and are a little dimmer (meaning they are switching fairly quickly). Decoupling/bypassing but thats a new topic for me -- I dont have anything in the circuit to do that at the moment. I scavenged a 5V power converter from an old 802.11B linksys AP to run this circuit and found a compatible plug and soldered 2 leads onto it and stuck those into my breadboard. JayArticle: 128355
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:19OdnZDlTN_j_QvanZ2dneKdnZydnZ2d@giganews.com... >> >> Or, ignore that stuff, sooo 20th C. Better bypass here:- >> http://www.x2y.com/ > > IMHO the LLM21 are better ;-) > > Marc > > Hi Marc, 25 amps? You madman! Anyway, if you get a spare moment, I'd appreciate you opinion of:- http://www.x2y.com/bypass/measure/comparative_decoupling.pdf pg. 16. They talk about "X2Y vs. Reverse Aspect Ratio Capacitors". I'm planning on going for X2Y on my next design, but I'd be interested in your analysis... Cheers, Syms.Article: 128356
"Allan Herriman" <allanherriman@hotmail.com> wrote in message news:e6nbp3pah684v23q800l26r7mtug8e6dk4@4ax.com... > On Tue, 22 Jan 2008 01:00:49 -0800 (PST), kislo > <kislo02@student.sdu.dk> wrote: > >>... decoupling network ... >> .. i dont have the luxury of a software tool to help me simulate and >> analyse > > The headers in your post suggest you are using Windows. That's good, > because you can download LTSpice and use that. > > http://www.linear.com/designtools/software/switchercad.jsp > > Like all simulations, the results are only as good as your models. In > particular, you'll end up with lumped approximations which may result > in resonances that don't appear on the real board. > (The real board will have distributed capacitance, and also dielectric > loss (which gets rid of a lot of the impedance peaks).) > > Regards, > Allan Hi Allan, I second that. I thought I'd mention that there's also a Yahoo group for LTSpice users. http://tech.groups.yahoo.com/group/LTspice/ HTH., Syms.Article: 128357
>Look up the specs on the caps for the parasitic L and R. Now you can >build a spreadsheet that calculates the complex impedance Z as a >function of frequency of each cap type (i.e. 10uF, 4.7uF, etc.). The L depends strongly on how you connect the cap to the power/ground planes. How many vias are you using? Where are they placed? What is the via diameter? Is there a trace from the cap pad to the via? ... -- These are my opinions, not necessarily my employer's. I hate spam.Article: 128358
On Tue, 22 Jan 2008 01:00:49 -0800 (PST), kislo <kislo02@student.sdu.dk> wrote: >Hi, i am currently trying to figure out the number and values of a >decoupling network for a spartan3e 500k (powered by the triple power >supply from texas instruments TPS75003) .. i dont have the luxury of a >software tool to help me simulate and analyse, but i just want a good >estimate which can be supported by theoretic statements. I have read >xapp623 (Power Distribution System (PDS) Design), and calculated the >number and values of capacitors using the method in the application >node. This is the results: >Vccint - 1.2V 8 supply pins > 1 - 4,7uF > 2 - 0.47uF > 5 - 0.047uF > >Vccaux - 2.5V 8 supply pins > 1 - 4,7uF > 2 - 0.47uF > 5 - 0.047uF > >Vcco - 3.3V 14 supply pins > 1 - 10uF > 2 - 4.7uF > 4 - 0.47uF > 8 - 0.047uF > >So here i start wondering ... the application node method is to have >one capacitor per vcc/gnd pin ... according to my knowledge (probably >bad), the decoupling capacitors should be determined from the >(frequency dependent)dynamic current requirement of the fpga. Since im >designing the decoupling network for a unknown fpga utialization i am >only interrested in the worst case scenario. If we take Vccint for >example: > >1.2V 5% tolerance - 2A max - 0.5ns risetimes > >Inorder for the voltage ripple to be under 5% for the bandwidth of >0.35/0.5ns = 700Mhz, the impedance of the PDS must be below : >(1.2V*0.05)/2A = 0.03R >Inorder for this to be realised i need INSANLY many decoupling >capacitors. By placing 14 0.0047uF, 10 0.047uF, 2 0.47uF I can stay >below 0.03R for a 80Mhz bandwith .... that means i still need to cover >up to 700Mhz :/ .. but this result is far from what result i got from >the xilinx application note .. > >I know that the previous calculations assumed that the current demand >for the harmonics were 2A for the entire bandwidth, but how does the >current relate to the harmonics of a signal transitions? if i got >50Mhz swiching frequency will the current drop with 20db/decade, just >as the amplitude of the harmonics? > >regards kim > > > > > > > > What we'd do is make sure each voltage has a pretty hunky copper pour that's separated from the ground plane by a thin dielectric layer. Then bypass each pour to ground with maybe four to six 0.33 uF, 0603 ceramic caps. That's it. JohnArticle: 128359
Any (specific) advice on a simlpe and cheap Xilinx board for data capture? I want to capture about 5-10 minutes of digital data from an RF. The highest rate that I need to handle is 4-bit data at almost 33 MHz. Let's just call it 16.5 MBps, or 990 MB per minute, let's say 1GB per minute. Of course this is real time - I can't miss even one sample. I just timed the write speed to an external hard drive over my USB port (4GB files). It was just at 1GB per minute for write and about 1.6 GB/min for read. So USB "might" work. I'd pay a little extra for a board that was easy to use in terms of the C interface and getting the IO working. Cheers, GilArticle: 128360
shadfc schrieb: > Hi, > I'm trying to create a "chrono" to measure the muzzle velocity of > a paintball gun. Basically, I'm just making a two gate system out of > some IR leds and photosensors which will hook into my Spartan 3E > Starter board. The FPGA will measure the time (clock ticks, really) > between gate changes and then do the division to arrive at the > velocity, which it will display on the LCD. > I'm having some problems getting the inputs into the FPGA to > register correctly. The gate circuit uses the QSE156 (http:// > www.fairchildsemi.com/ds/QS/QSE156.pdf) photosensor by Fairchild which > provides a TTL/LSTTL compatible output. Following the Xilinx > guidelines for making 5V inputs safe, I've connected the TTL output to > the board through a 390Ohm series resister. > I am using pin D7 on the J4 Header as a test input for a single > gate. I have that pin specified in the UCF as follows: > > NET "gateA" LOC = "D7" | IOSTANDARD = LVTTL | SLEW = SLOW | > DRIVE = 6 ; > > Now, the problem I am having is that I cant get the input to be > stable on both high and low signals from the photosensor. It appears > to oscillate at a fairly high frequency (MHz range). I tried to > debounce the input (with 16 bits) and then incremented a counter on > every rising edge of the stabilized input, but using the Spartans 8 > LEDs to display the counter still was a blur. So, by that, I surmised > that the input is oscillating between high and low. > I would appreciate any input on this since I'm at a loss. Do I > have my FPGA input settings correct? Must I use a wire less than X > inches to connect the output of the photosensor to the board? Etc, > etc. What am I missing? > > thanks > Jay Hi Jay, some more hints: Are you sure that the sensor device is a QSE156 (red mark) and not accidently a QSE158/9 (green/blue mark) The later ones have open collector outputs causing the open CMOS inputs to swing when used without a pullup. You mentioned long wires. Are they shielded or at least twisted pair wires? Maybe some other device induces wrong signals to the input. Do you have a scope around, to see how your sensor signal (and power) actually behave? You also may try another input. Maybe your pcb is broken on that line causing the input to be open all the time. Invoking the internal pullup on the desired input should have some effect. Check it. Good luck EilertArticle: 128361
piotr.nowak21@gmail.com schrieb: > Helo! > I'm using a newest ver. of ISE and EDK (with all SP) on Linux Ubuntu > (last relese), and I expirience a problem with UART. I've created two > identical basic projects, one using 9.1 (on Windows) and the other > using 9.2. (on Linux). Projects contains MB processor with UART lite > only (uart is set as stdin/out), and TestApp_Memory generated > application. The project created on Win (EDK 9.1) is working properly > (i recive a simple message on HyperTerminal), but this one built on > Linux (EDK 9.2) isn't (rs-232 terminal is empty). So I decided to > check if the programming file (download.bit) from one system will work > on the another. Using iMPACT, I programmed the device on Linux with > file generated on Win., and on Win. using file from Linux. What was > happend? Device programmed on Linux (EDK9.2) is working, and this one > programmend on Win.(EDK9.1) isn't. So I'm confused, for me it looks > like EDK9.2 is not generating proper programming file. Any sugestion? > > ps. Board is EDK S3E Starter Kit > Sorry for my English :) > > Best regards Peter. Hi Peter, you must have missed something. I am using ISE/EDK9.2 on Linux. The Uart Lite is doing fine. Try to import the EDK project from Win (ISE 9.1) into your Linux (ISE 9.2) and see what happens. -MarkusArticle: 128362
well, im looking for a more theoretic answer for determing the decoupling capacitors ... if i switch 2A with a risetime of 0.5ns how can i determine the current vs frequency or the impedance vs frequency for the harmonics of 50Mhz switching frequency ... the impedance requirement cant be constant over the complete frequency spectrumArticle: 128363
On Jan 22, 8:27 pm, Andy <jonesa...@comcast.net> wrote: > On Jan 22, 12:21 pm, Pablo <pbantu...@gmail.com> wrote: > > > > > On 22 ene, 19:12, KJ <kkjenni...@sbcglobal.net> wrote: > > > > On Jan 22, 1:02 pm, Pablo <pbantu...@gmail.com> wrote: > > > <snip> > > > > > Thanks kevin, I will try to explain as better as possible. Of course, > > > > my English is not perfect. > > > > > My real code is this: > > > > > if(read='1' and empty='0') then > > > > addr := (addr + 1)mod(64); -- So as you said, > > > > addr INCREMENTS its value until 64. In this moment it init to 0. > > > > That's the use of mod. > > > > end if; > > > > > My confusion is the following: > > > > > Addr is defined as an Integer Variable in the proccess body. Of course > > > > is not constant, so its value is increment in each clock cycle. > > > > So: Could I use mod in my code??? > > > > Yes. It will synthesize just fine because you're trying to get the > > > value of (Addr +1) mod 64 and 64 is a power of 2. > > > > > Could Mod operator be used with > > > > variables or signals?? > > > > Yes. > > > > Kevin Jennings > > > I suppose so, but kevin, I think that Xilinx doesn't synthesizes this. > > The design fails in the moment that I include the Mod Operator. > > > Pablo > > What is it doing that you don't like? Are you getting an error message > from XST, or is it not simulating the way you think it should, or > what? > > You should know that 0 <= (N mod 64) <= 63, not 64. > > Andy Yes Andy, this is ok; 0 to 63. No problem. The problem is that design fails when I do this operation. Xilinx doesn't get any error message.Article: 128364
On Jan 22, 8:26 pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Jan 22, 1:21 pm, Pablo <pbantu...@gmail.com> wrote: > <snip> > > > > > I suppose so, but kevin, I think that Xilinx doesn't synthesizes this. > > The design fails in the moment that I include the Mod Operator. > > Then either > - Don't use Xilinx if it doesn't support computing X mod 64 > - Change the code to be of the form shown below > > if (addr = 63) then > addr <= 0 > else > addr <= addr - 1 > end if; > > KJ I have already tried to implement this design, but the system fails again. I think this is a delay problem.Article: 128365
Hallo to everyone, I should generate a pwm sinusoidal signal of a frequency lower than 500 Hz. I have seen DDS Compiler into Coregen, but it seems useful to drive a DAC. My aim instead is to output a pwm signal. Any suggestion? Many Thanks, MarcoArticle: 128366
Marco T. wrote: > I should generate a pwm sinusoidal signal of a frequency lower than > 500 Hz. > > I have seen DDS Compiler into Coregen, but it seems useful to drive a > DAC. > > My aim instead is to output a pwm signal. > > Any suggestion? Hook up the output data from the DDS to a separate PWM module.Article: 128367
"Symon" <symon_brewer@hotmail.com> wrote > "Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message >>> >>> Or, ignore that stuff, sooo 20th C. Better bypass here:- >>> http://www.x2y.com/ >> >> IMHO the LLM21 are better ;-) >> >> Marc >> >> > Hi Marc, > > 25 amps? You madman! I was surprised too and I had to redesign my power supply. :( It's a Stratix II 180 full at 86% and running at 200MHz. > Anyway, if you get a spare moment, I'd appreciate you opinion of:- > http://www.x2y.com/bypass/measure/comparative_decoupling.pdf > pg. 16. They talk about "X2Y vs. Reverse Aspect Ratio Capacitors". > I'm planning on going for X2Y on my next design, but I'd be interested in > your analysis... They compared to an 8 pins IDC connector which has an ESL of 100pH. The LLM21 has a 45pH ESL. The 2 added pins make a big difference as they are placed on the short sides of the caps. Some people even prefer 0402s to X2Y: http://www.freelists.org/archives/si-list/05-2005/msg00331.html For decoupling the other supply rails, I used one 2.2µF 0402 per pin + 2 x 100µF 1210 and 1 x 1500µF Tantalum. There are also other low ESL caps like the LGA and LICA: http://www.avx.com/docs/catalogs/lga2t.pdf http://www.avx.com/docs/catalogs/licarray.pdf MarcArticle: 128368
"kislo" <kislo02@student.sdu.dk> wrote in message news:485539ea-77fc-4595-93ab-f48ae4eb76c7@m34g2000hsb.googlegroups.com... > well, im looking for a more theoretic answer for determing the > decoupling capacitors ... if i switch 2A with a risetime of 0.5ns how > can i determine the current vs frequency or the impedance vs frequency > for the harmonics of 50Mhz switching frequency ... the impedance > requirement cant be constant over the complete frequency spectrum Hi Kim, There lies the problem. You're not going to get a proper answer without considering the physical layout of the system. As Hal says, the layout and attachment of the caps is as important as their own characteristics. Also, remember that you're trying to bypass the IC die, not the pads for the BGA on the PCB. So, the BGA package and its balls must be part of the calculation, indeed it can have a significant effect. IC manufacturers embed bypass caps in the package for good reason. All this must be taken into account. You should consider the design loaded into the FPGA. If you can reduce the number of simultaneously switching circuits, the PDS requirement is easier to meet. The only way I know of to get an accurate answer to your question is to model the whole lot in a 3-D field solver like HFSS. As you're a student (I guess) maybe Ansoft will lend you a seat? You also need to talk to your FPGA vendor to get models of their package. If you do this, we'd all be grateful to see the results! John's solution is a good one; I would maybe consider substituting the X2Y parts for his 0603 parts. Try googling puddle site:x2y.com to read how a copper 'puddle', like John's pours, can 'pool' vias. Lastly, these days the capacitors are often cheaper than the cost to attach them. Fewer more expensive parts can be a cost saver. HTH., Syms.Article: 128369
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:7aOdnZlxXLP2jAranZ2dnUVZ8sylnZ2d@giganews.com... > >> Anyway, if you get a spare moment, I'd appreciate you opinion of:- >> http://www.x2y.com/bypass/measure/comparative_decoupling.pdf >> pg. 16. They talk about "X2Y vs. Reverse Aspect Ratio Capacitors". >> I'm planning on going for X2Y on my next design, but I'd be interested in >> your analysis... > > They compared to an 8 pins IDC connector which has an ESL of 100pH. The > LLM21 has a 45pH ESL. > The 2 added pins make a big difference as they are placed on the short > sides of the caps. > > Some people even prefer 0402s to X2Y: > http://www.freelists.org/archives/si-list/05-2005/msg00331.html > > For decoupling the other supply rails, I used one 2.2µF 0402 per pin + 2 x > 100µF 1210 and 1 x 1500µF Tantalum. > > There are also other low ESL caps like the LGA and LICA: > http://www.avx.com/docs/catalogs/lga2t.pdf > http://www.avx.com/docs/catalogs/licarray.pdf > > Marc > > Hi Marc, Many thanks, that's very interesting. I misread the Murata datasheet and got the LLMs mixed up with LLLs. (I must stop posting late after returning from the pub!) The AVX parts are neat too. That gives me plenty to think about. Much appreciated, Syms.Article: 128370
"Pablo" <pbantunez@gmail.com> wrote in message news:9cd1b28e-6b26-4f48-b187-7dbcfb69fb12@21g2000hsj.googlegroups.com... > On Jan 22, 8:26 pm, KJ <kkjenni...@sbcglobal.net> wrote: >> On Jan 22, 1:21 pm, Pablo <pbantu...@gmail.com> wrote: >> <snip> > > I have already tried to implement this design, but the system fails > again. I think this is a delay problem. > I've asked before and you haven't responded....last time.... - WHAT is the failure? - Have you simulated the design? - Does the simulation produce the results you expect? Kevin JenningsArticle: 128371
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:7aOdnZlxXLP2jAranZ2dnUVZ8sylnZ2d@giganews.com... > > Some people even prefer 0402s to X2Y: > http://www.freelists.org/archives/si-list/05-2005/msg00331.html > Did you click 'Thread Next'? Ouch! Syms.Article: 128372
On 23 Jan., 07:37, g...@radix20.com wrote: > Any (specific) advice on a simlpe and cheap Xilinx board for data > capture? > > I want to capture about 5-10 minutes of digital data from an RF. The > highest rate that I need to handle is 4-bit data at almost 33 MHz. > Let's just call it 16.5 MBps, or 990 MB per minute, let's say 1GB per > minute. Of course this is real time - I can't miss even one sample. > > I just timed the write speed to an external hard drive over my USB > port (4GB files). It was just at 1GB per minute for write and about > 1.6 GB/min for read. So USB "might" work. > > I'd pay a little extra for a board that was easy to use in terms of > the C interface and getting the IO working. USB has transfer modes with a bandwidth guarantee. This goes up to about 40MBytes/s. The problem migh be whether your PC can handle this (USB drivers can have high CPU load depending on the chipset) Kolja SulimmaArticle: 128373
On 23 ene, 12:36, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Pablo" <pbantu...@gmail.com> wrote in message > > news:9cd1b28e-6b26-4f48-b187-7dbcfb69fb12@21g2000hsj.googlegroups.com...> On Jan 22, 8:26 pm, KJ <kkjenni...@sbcglobal.net> wrote: > >> On Jan 22, 1:21 pm, Pablo <pbantu...@gmail.com> wrote: > >> <snip> > > > I have already tried to implement this design, but the system fails > > again. I think this is a delay problem. > > I've asked before and you haven't responded....last time.... > - WHAT is the failure? > - Have you simulated the design? > - Does the simulation produce the results you expect? > > Kevin Jennings Thanks but I suppose that I cannot explain the problem as you would like. Thanks again. PabloArticle: 128374
On Jan 23, 2:40 am, Pablo <pbantu...@gmail.com> wrote: > On Jan 22, 8:27 pm, Andy <jonesa...@comcast.net> wrote: > > > > > On Jan 22, 12:21 pm, Pablo <pbantu...@gmail.com> wrote: > > > > On 22 ene, 19:12, KJ <kkjenni...@sbcglobal.net> wrote: > > > > > On Jan 22, 1:02 pm, Pablo <pbantu...@gmail.com> wrote: > > > > <snip> > > > > > > Thanks kevin, I will try to explain as better as possible. Of course, > > > > > my English is not perfect. > > > > > > My real code is this: > > > > > > if(read='1' and empty='0') then > > > > > addr := (addr + 1)mod(64); -- So as you said, > > > > > addr INCREMENTS its value until 64. In this moment it init to 0. > > > > > That's the use of mod. > > > > > end if; > > > > > > My confusion is the following: > > > > > > Addr is defined as an Integer Variable in the proccess body. Of course > > > > > is not constant, so its value is increment in each clock cycle. > > > > > So: Could I use mod in my code??? > > > > > Yes. It will synthesize just fine because you're trying to get the > > > > value of (Addr +1) mod 64 and 64 is a power of 2. > > > > > > Could Mod operator be used with > > > > > variables or signals?? > > > > > Yes. > > > > > Kevin Jennings > > > > I suppose so, but kevin, I think that Xilinx doesn't synthesizes this. > > > The design fails in the moment that I include the Mod Operator. > > > > Pablo > > > What is it doing that you don't like? Are you getting an error message > > from XST, or is it not simulating the way you think it should, or > > what? > > > You should know that 0 <= (N mod 64) <= 63, not 64. > > > Andy > > Yes Andy, this is ok; 0 to 63. No problem. > > The problem is that design fails when I do this operation. Xilinx > doesn't get any error message. I still don't know what you mean by "the design fails". Do you get a netlist or bit file for the FPGA? Does the simulation not run as you expected? Does the FPGA not run as expected? I went back and looked at your original post. There may be other problems (sensitivity list, clock clause, etc.) can you post the entire process for us? Andy
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