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 Dec 22, 8:06=A0am, John_H <newsgr...@johnhandwork.com> wrote: > On Dec 22, 12:00=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > On Dec 22, 6:40=A0am, John_H <newsgr...@johnhandwork.com> wrote: > > > > Sometimes the simpler things can get in the way of complex issues. > > > > Are you certain your read enable and write enables are showing up > > > relative to the correct data? > > > It seems some people expect the read enable to indicate the valid dat= a > > > is being removed from the FIFO while others believe the read enable > > > should produce valid data on the following clock. > > > > Double check where the documentation says the valid data should be > > > relative to the enable pulse especially for the read, but check the > > > write as well. > > > ___ > > > > How deep do you want your FIFO? > > > Is latency an issue? > > > Do you want rd_en to indicate you're taking valid data or that the > > > next clock is valid? > > > You want wr_en to be present in the same clock cycle as the din, > > > right? > > > > Long time no post (partly because I miss having a real newsreader), > > > - John_H > > > Hi John, > > > 1 the FIFO is supposed to be SIMPLEST possible MGT receiver, FIFO > > wr_en is active when the incoming char is not IDLE. > > 2 Latency is absolutly NO issue, PPC is pulling the data extremly slow > > anyway :( > > 3 rd_en almost do not care, well currently it is wrong, 1 clock too > > late so PPC doesnt pull the last value from fifo (it is pulled when > > new data comes in), but this minor issue does really not explain the > > error where the fifo reads out out half of the old values > > > Antti > > If the rd_en is one cycle off, the data during that cycle is > undefined. > > If the rd_en is active for two cycles, the data extracted will be > precisely one cycle off for the rd_en pulses after the first. > > The specific FIFO implementation may provide what looks like valid > data - or not - during the first of those consecutive rd_en pulses. > > I would *love* to know how much data is "good" versus "bad" with the > rd_en realigned. > > - John_H Rereading some stuff, perhaps I wasn't clear: the data for a read pulse may be expected by the system the same clock as the read enable - indicating the design is "taking valid data" from the FIFO on that clock where rd_en and dout are both valid the same clock cycle - while the FIFO expects the dout to be valid the clock *after* the rd_en. Or vice-versa. It's this "which clock cycle" issue between rd_en and the dout corresponding to that rd_en that trips up some engineers.Article: 144676
On Dec 22, 3:06=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Dec 22, 12:00=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > On Dec 22, 6:40=A0am, John_H <newsgr...@johnhandwork.com> wrote: > > > > Sometimes the simpler things can get in the way of complex issues. > > > > Are you certain your read enable and write enables are showing up > > > relative to the correct data? > > > It seems some people expect the read enable to indicate the valid dat= a > > > is being removed from the FIFO while others believe the read enable > > > should produce valid data on the following clock. > > > > Double check where the documentation says the valid data should be > > > relative to the enable pulse especially for the read, but check the > > > write as well. > > > ___ > > > > How deep do you want your FIFO? > > > Is latency an issue? > > > Do you want rd_en to indicate you're taking valid data or that the > > > next clock is valid? > > > You want wr_en to be present in the same clock cycle as the din, > > > right? > > > > Long time no post (partly because I miss having a real newsreader), > > > - John_H > > > Hi John, > > > 1 the FIFO is supposed to be SIMPLEST possible MGT receiver, FIFO > > wr_en is active when the incoming char is not IDLE. > > 2 Latency is absolutly NO issue, PPC is pulling the data extremly slow > > anyway :( > > 3 rd_en almost do not care, well currently it is wrong, 1 clock too > > late so PPC doesnt pull the last value from fifo (it is pulled when > > new data comes in), but this minor issue does really not explain the > > error where the fifo reads out out half of the old values > > > Antti > > If the rd_en is one cycle off, the data during that cycle is > undefined. > > If the rd_en is active for two cycles, the data extracted will be > precisely one cycle off for the rd_en pulses after the first. > > The specific FIFO implementation may provide what looks like valid > data - or not - during the first of those consecutive rd_en pulses. > > I would *love* to know how much data is "good" versus "bad" with the > rd_en realigned. > > - John_H John, just LAST value remains in the FIFO nothing else wrong, this really is not an issue the system, the data corruption is NEVER wrong values. 1) double value 2) 1, 2, 3 missing values 3) rd addr ptr restart at random So ALL data what comes is good in that sense its data that has been pushed it. its just duplicates, missing or long repeats of old data. whatever the read enable is clock early or late it can not be cause the cause of the problem. I can also call it design feature if you so want. We read the data, and pop next one. Ok, its little buggy feature but several big companies call serious bugs a feature. AnttiArticle: 144677
On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote: > John, > > just LAST value remains in the FIFO nothing else wrong, this really > is not an issue the system, the data corruption is NEVER wrong values. > > 1) double value > 2) 1, 2, 3 missing values > 3) rd addr ptr restart at random > > So ALL data what comes is good in that sense its data that has been > pushed it. its just duplicates, missing or long repeats of old data. > > whatever the read enable is clock early or late it can not be cause > the cause of the problem. I can also call it design feature if you so > want. We read the data, and pop next one. Ok, its little buggy feature > but several big companies call serious bugs a feature. > > Antti If you haven't gotten the FIFO working yet, I'd love to bring up my VHDL coding with a FIFO to help you out within the next several hours. You gave the port declarations but I didn't see your needed FIFO depth. And is valid data the clock after the rd_en acceptable? It's good for me to get into VHDL and it sounds like you could use a little Christmas cheer. I've done Verilog FIFOs in the past with rock- solid results. Full asynch support, read past empty can generate an "invalid read" flag but not upset the later operation (for an absurd method of "clearing out a FIFO" for instance) while write past full will be entirely gated out with an error flag the following clock. - John_HArticle: 144678
Hello-- I am working on a custom board with a Cyclone II FPGA. Attached to the pins of the FPGA are six serial ADCs (AD7690 from Analog Devices). Each ADC has three pins which are controlled by the FPGA: #CS, MISO, SCLK and CNV. I am using the ADCs with the #CS-mode, 3-wire with busy signal interface. This means that a rising edge on CNV will initiate a conversion, and since #CS is always held high, a pull-up resistor on MISO will allow the ADC to signal to the master when the conversion is complete. This occurs when the ADC MISO output goes from high impedance to low impedance, causing the MISO signal to drop logic low. A data word is then read from the ADC by toggling the SCLK. The data word is output on MISO in a synchronous fashion to the SCLK signal. Strangely enough, it appears that when power is initially applied, MISO is low, although the pull-up resistor is present. With the FPGA not programmed, I have noticed that I can touch the #CS input with a multimeter probe, and MISO will go high. This behavior is similar for all of the six ADCs. Note that there is also a pull-up resistor on the #CS input. Using the Quartus II software, I have ensured that all un-used pins are tri-stated on startup. To verify operation, I am using the SignalTap II Logic Analyzer, which is bundled with the Quartus II software. What is really weird is that according to SignalTap II, the MISO of the 6th ADC does not want to go high after startup. All of the other MISO outputs of the ADCs go high after startup. The signal is represented as MISO[5] in the Quartus II pin planner, and is an input in the associated Verilog code. Moreover, SignalTap II tells me that the chip select #CS output of the 6th ADC is high. Using Verilog code, I have attempted to toggle the #CS of all ADCs. Doing so causes all MISO outputs of the ADCs to drop low (when #CS is low), and then to go high again (when #CS is high). However, according to the SignalTap II logic analyzer, MISO[5] remains at logic low. I have verified the connections from the FPGA to the ADCs, and all connections seem to be good. However, I have noticed some strange warnings in the Quartus II software: ------- Warning: Can't achieve timing requirement Clock Setup: 'my_pll:pll|altpll:altpll_component|_clk0' along 166 path(s). See Report window for details. Warning: Can't achieve timing requirement Clock Setup: 'clk' along 95 path(s). See Report window for details. Warning: Circuit may not operate. Detected 76 non-operational path(s) clocked by clock "altera_internal_jtag~TCKUTAP" with clock skew larger than data delay. See Compilation Report for details. ------- I suspect that these warnings may indicate that there is a problem with the timing analysis. Would anyone be able to shed some light on why the MISO[5] pin would always be at logic low? What would explain the behavior of touching the #CS pins with the multimeter to cause the MISO output to go high? NicholasArticle: 144679
On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > John, > > > just LAST value remains in the FIFO nothing else wrong, this really > > is not an issue the system, the data corruption is NEVER wrong values. > > > 1) double value > > 2) 1, 2, 3 missing values > > 3) rd addr ptr restart at random > > > So ALL data what comes is good in that sense its data that has been > > pushed it. its just duplicates, missing or long repeats of old data. > > > whatever the read enable is clock early or late it can not be cause > > the cause of the problem. I can also call it design feature if you so > > want. We read the data, and pop next one. Ok, its little buggy feature > > but several big companies call serious bugs a feature. > > > Antti > > If you haven't gotten the FIFO working yet, I'd love to bring up my > VHDL coding with a FIFO to help you out within the next several > hours. =A0You gave the port declarations but I didn't see your needed > FIFO depth. =A0And is valid data the clock after the rd_en acceptable? > > It's good for me to get into VHDL and it sounds like you could use a > little Christmas cheer. =A0I've done Verilog FIFOs in the past with rock- > solid results. =A0Full asynch support, read past empty can generate an > "invalid read" flag but not upset the later operation (for an absurd > method of "clearing out a FIFO" for instance) while write past full > will be entirely gated out with an error flag the following clock. > > - John_H- Hide quoted text - > > - Show quoted text - Hi John, I have only spare minute, please do not shoote me - when I reported all 4 FIFOs not working it was wrong, the non-xilinx fifo is not tested i replaced the un-unused FIFO I will retest and report results. what does look like valid result is that replacing one of 2 similar FIFOs the unused one, made the other one have 10 times less error have to give kids e-lectronics class this instant! AnttiArticle: 144680
Antti <antti.lukats@googlemail.com> wrote:
>On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>> On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote:
>>
>>
>>
>>
>>
>> > John,
>>
>> > just LAST value remains in the FIFO nothing else wrong, this really
>> > is not an issue the system, the data corruption is NEVER wrong values.
>>
>> > 1) double value
>> > 2) 1, 2, 3 missing values
>> > 3) rd addr ptr restart at random
>>
>> > So ALL data what comes is good in that sense its data that has been
>> > pushed it. its just duplicates, missing or long repeats of old data.
>>
>> > whatever the read enable is clock early or late it can not be cause
>> > the cause of the problem. I can also call it design feature if you so
>> > want. We read the data, and pop next one. Ok, its little buggy feature
>> > but several big companies call serious bugs a feature.
>>
>> > Antti
>>
>> If you haven't gotten the FIFO working yet, I'd love to bring up my
>> VHDL coding with a FIFO to help you out within the next several
>> hours. =A0You gave the port declarations but I didn't see your needed
>> FIFO depth. =A0And is valid data the clock after the rd_en acceptable?
>>
>> It's good for me to get into VHDL and it sounds like you could use a
>> little Christmas cheer. =A0I've done Verilog FIFOs in the past with rock-
>> solid results. =A0Full asynch support, read past empty can generate an
>> "invalid read" flag but not upset the later operation (for an absurd
>> method of "clearing out a FIFO" for instance) while write past full
>> will be entirely gated out with an error flag the following clock.
>>
>> - John_H- Hide quoted text -
>>
>> - Show quoted text -
>
>Hi John,
>
>I have only spare minute, please do not shoote me - when I reported
>all 4 FIFOs not working it was wrong, the non-xilinx fifo is not
>tested
>i replaced the un-unused FIFO
>
>I will retest and report results.
>what does look like valid result is that replacing one of 2 similar
>FIFOs the unused one, made the other one have 10 times less error
Does this mean that changing the design had effects in other unaltered
places? If yes, then you definitely have a clock-boundary crossing
problem.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 144681On Dec 22, 9:24=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > <snip> > > Hi John, > > I have only spare minute, please do not shoote me - when I reported > all 4 FIFOs not working it was wrong, the non-xilinx fifo is not > tested > i replaced the un-unused FIFO > > I will retest and report results. > what does look like valid result is that replacing one of 2 similar > FIFOs the unused one, made the other one have 10 times less error > > have to give kids e-lectronics class this instant! > Antti Since your change did not change the functionality of what you tested, but changed the timing due to going through place and route again, this sure sounds like it could be a timing problem to me. I am sure that you have already checked that static path analysis stated that all of your constraints were met, so generate a custom timing report and have it list the unconstrained paths. If something that matters is unconstrained, you are susceptible to strange behavior from the design. Since the symptoms are appearing at a FIFO, I would pay special attention to signals crossing between the clock domains. You mention that the FPGA is about 80% full. If you meant 80% of LUTs and FFs, you are getting into the region that the place and route tools are having to work hard to meet timing constraints. If something is unconstrained, it could be getting really poor placement and timing with respect to what it really needs. Regards, John McCaskill www.FasterTechnology.comArticle: 144682
snip > > Antti > > Since your change did not change the functionality of what you tested, > but changed the timing due to going through place and route again, > this sure sounds like it could be a timing problem to me. > > I am sure that you have already checked that static path analysis > stated that all of your constraints were met, so generate a custom > timing report and have it list the unconstrained paths. > > If something that matters is unconstrained, you are susceptible to > strange behavior from the design. Since the symptoms are appearing at > a FIFO, I would pay special attention to signals crossing between the > clock domains. You mention that the FPGA is about 80% full. If you > meant 80% of LUTs and FFs, you are getting into the region that the > place and route tools are having to work hard to meet timing > constraints. If something is unconstrained, =A0it could be getting > really poor placement and timing with respect to what it really needs. > > Regards, > > John McCaskillwww.FasterTechnology.com not very encouranging, I have had really hard times with Actel devices where i have witnessed a simple shift register at low as dirt clean clock to stop shifting if FPGA utilization did go above say 93% of versatales. There was no violations, nothing did show up in post place and route simulation, just chip was dead. Later i did read about MANUAL insertion of "inverting" clock tree to adjust the timings. This was scary! current design utilization is Slices 14K 73% brams 116 80% DSP 39 80% GT11 6 50% the device is slowest speed grade FX40 and there is not a single assembled with higher speed grade, so that testing is not possible. i just did clean some snow outside, hm actually there is no other explanation except XILINX TOOL messup, that is, the FIFO clocks are constrained, no violation reported, but tools generate non-working design. i will still test the non-xilinx fifo properly for good luck test, but then its time to redesign to 8b-32b DPRAM it would have much less logic in 125mhz domain, so there could be more hope. Actually first version of that module is ready, but it needs change of other HDL code, and change of firmware, so working fifo would be less work to, well if fifo would work thanks for all suggestion, i will continue with testing, and focusing on timing-hunt or then remove all fifo from that place AnttiArticle: 144683
On Dec 22, 11:32=A0am, Antti <antti.luk...@googlemail.com> wrote: > snip > > > > > > Antti > > > Since your change did not change the functionality of what you tested, > > but changed the timing due to going through place and route again, > > this sure sounds like it could be a timing problem to me. > > > I am sure that you have already checked that static path analysis > > stated that all of your constraints were met, so generate a custom > > timing report and have it list the unconstrained paths. > > > If something that matters is unconstrained, you are susceptible to > > strange behavior from the design. Since the symptoms are appearing at > > a FIFO, I would pay special attention to signals crossing between the > > clock domains. You mention that the FPGA is about 80% full. If you > > meant 80% of LUTs and FFs, you are getting into the region that the > > place and route tools are having to work hard to meet timing > > constraints. If something is unconstrained, =A0it could be getting > > really poor placement and timing with respect to what it really needs. > > > Regards, > > > John McCaskillwww.FasterTechnology.com > > not very encouranging, I have had really hard times with Actel devices Not trying to be discouraging Antti, I think you can find and fix this problem. > where i have witnessed a simple shift register at low as dirt clean > clock > to stop shifting if FPGA utilization did go above say 93% of > versatales. > There was no violations, nothing did show up in post place and route > simulation, just chip was dead. Later i did read about MANUAL > insertion of "inverting" clock tree to adjust the timings. This was > scary! > If you are using synchronous design techniques, and are treating the clocks properly by keeping them on the clock networks and only using the dedicated clocking resources to manipulate them, static path analysis should make sure that there are either no problems with the constraints being met no matter how full the chip is, or finding that there are timing problems. Where some of the hard to find problems creep in is unconstrained paths that should be constrained, improperly constrained paths, such as improper use of multi-cycle and false path constraints, and improper handling of asynchronous signals and clock domain crossing. Sometimes the tools can work against you if you are not careful. If you have two or three FFs in a series to synchronize a signal, you don't want to let the tools replicate those registers. > current design utilization is > Slices 14K 73% > brams 116 80% > DSP 39 80% > GT11 6 50% > Ok, I thought you meant that LUT or FF utilization was at 80%, if it is not LUTs and FFs that are at 80%, but the BRAMS and DSP blocks that should not be a problem. Since slices are only at 73%, you have plenty of LUTs and FFs left and the tools have lots of flexibility to work with. By default, the mapper will not put unrelated logic into the same slice, so it tends to spread it out to give place and route flexibility. I have many designs that are at 99% slice utilization well before I am finished adding stuff to them that place and route just fine. > the device is slowest speed grade FX40 > and there is not a single assembled with higher speed grade, so that > testing is not possible. If you are having clock domain crossing problems, a faster speed grade may move the problem around, but is not the real solution. > > i just did clean some snow outside, hm > actually there is no other explanation except XILINX TOOL messup, that > is, the FIFO clocks > are constrained, no violation reported, but tools generate non-working > design. Hope it is not the tools, that is hard to fix on your own! I think there are plenty of other possibilities. This sounds like a timing issue to me from what you have described. You can find it with the tools you have, it is just one of the more frustrating problems to deal with. Look at the unconstrained paths? What do you see? I don't think the FIFO is the cause of the problem, but it is where it shows up so put multiple ChipScope ILAs on it to cover the different clock domains. While not perfect, you can run the ILAs off of a clock that is a multiple of the clock domain it is sampling to get some timing info if you want. Something is going to look wrong here, follow the trail. Using the ILA tool in the FPGA editor you should be able to change which signals the ILA is monitoring and get a new bitstream to download in a matter of a few minutes since that does not require you to go through place and route again. I was doing this the last few days to see why something that was working in simulation was not working on the hardware, it is a powerful technique. > > i will still test the non-xilinx fifo properly for good luck test, but > then its time to redesign > to 8b-32b DPRAM it would have much less logic in 125mhz domain, so > there could be > more hope. Actually first version of that module is ready, but it > needs change of other > HDL code, and change of firmware, so working fifo would be less work > to, well if > fifo would work > > thanks for all suggestion, i will continue with testing, and focusing > on timing-hunt > or then remove all fifo from that place > > Antti Good luck, John McCaskill www.FasterTechnology.comArticle: 144684
> http://www.fpga4fun.com/ISEQuickStart.htmlgives a quick overview > of the basic steps of loading code in to an FPGA using ISE (as I think the > ML402 is Xilinx, there is a version for Quartis on the site as well if I'm > wrong). > Its for an older version of ISE so the screen shots aren't quite > correct but it gives the flow you need to compile and load a project which > is I think what you are asking for. It got me to the point of being able to > successfully compile, load and execute one of their example progams (writing > my own is likely quite another matter though :-)) into their Dragon board > using a later version of ISE. > At the end of it there is a reference to Xilinx tutorials for the > various versions of ISE (I haven't gotten that far yet though :-)) > > Peter Van Epp Thanks, Peter. Over the past couple months, I've succeeded in working with ISE VHDL- only projects, but now I've moved onto my first embedded design and am using only EDK. It is my understanding that when working with embedded processor projects, running it on an FPGA (in my case, the Virtex-4 on the ML402) is not as simple as downloading the bitstream (as is my experience with working with vhdl projects on a Xilinx Spartan3 board) . If I understand correctly, there are executables (ELF?) and such which must also be loaded to memory (DDR, SRAM) and then executed such that the project runs. It is these two things that I am unsure how to do. If I understand correctly, EDK11 can handle the bitstream downloading via Device Configuration -> Download Bitstream, but what's the deal with loading things into memory and executing them? Can anyone point me to some good references on this subject? Thanks! -Sean.Article: 144685
Sean, You can see how this is done on the latest V5 or V6 EDK projects, it is the same. There is a "download" software tool button, as well, if the code is in the external SRAM or DDR memories. The JTAG cable will download a shell tool, so you can copy the .elf file into the memory location needed, and then control the processor (start, stop, etc.). http://www.xilinx.com/products/boards/ml505/ml505_11.1_1/docs/ml505_bsb_design_creation.pdf slide 39, onwards, applies to the older boards and tools as well. The location of the pulldown menus might be different in the older versions, but it still works the same way (for .elf file loading). AustinArticle: 144686
Hello, I use spartan 3 starter kit to make two cores processors. So, can I put the two cores processors on the same PLB bus or not? and if it is possible, what is the best method to working with : using two PLB buses for each core processor or a single PLB bus for both?? thanks in advance. INES --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144687
Thanks, Austin, this was exactly what I needed. -Sean. > Sean, > > You can see how this is done on the latest V5 or V6 EDK projects, it > is the same. > > There is a "download" software tool button, as well, if the code is in > the external SRAM or DDR memories. =A0The JTAG cable will download a > shell tool, so you can copy the .elf file into the memory location > needed, and then control the processor (start, stop, etc.). > > http://www.xilinx.com/products/boards/ml505/ml505_11.1_1/docs/ml505_b... > > slide 39, onwards, applies to the older boards and tools as well. > > The location of the pulldown menus might be different in the older > versions, but it still works the same way (for .elf file loading). > > AustinArticle: 144688
Antti, Based on all the symptoms you have described, namely the read side of the fifo going crazy and getting stale or duplicated data strongly suggests that the problem is in the recovered clock. I once worked on a chip where the duty cycle of the recovered clock can vary widely and that the recovered clock even occasionally have a stretched cycle where the clock looked like it was missing a cycle. This was on an actual asic as opposed to an fpga. But the bottom line was that we had unintentionally assumed that the recovered clock would always be 50/50 duty cycle and that the recovered clock would never do strange things like skip a clock. If at all possible, I suggest you try the following. 1) I assume that you are using the recovered clock directly. If you are, try running the clock thru an onboard PLL and use the pll generated clock instead. If this helps your problem then do #2 below. 2) Route the recovered clock back out to a pin and observe it on a 1GHz scope. Configure the scope to trigger on anything less than 40/60 duty cycle. Good Luck....Article: 144689
I can't understand your answer given below. why did you opt for an asynchronous counter and how will you be able to set all the delays [1s, 10us] whith a synthesizer? actually what all the number stand for? Cheers > > One of the best high-frequency counters I've done in an FPGA was a > ripple counter. =A0Unlike a synchronous counter, a ripple counter only > has a single point of entry that you need to gate, and so is safe for > any asynchronous input signal up to hundreds of MHz. > > I wrapped a synchronous state machine around it that: > =A0 1) clock enables the first flip-flop in the counter > =A0 2) waits 1 second > =A0 3) deasserts the clock enable > =A0 4) waits 10 us for the ripple counter to settle out > =A0 5) registers the now static outputs back into the clocked domain > =A0 6) goto 1 > > The only problem is that you don't know for certain how long it will > take the ripple counter to settle out, but if you're willing to go way, > way overboard on that dead time then everything works like a dream. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order- Hide quoted text - > > - Show quoted text -Article: 144690
> > What is really weird is that according to SignalTap II, the MISO of the > 6th ADC does not want to go high after startup. All of the other MISO > outputs of the ADCs go high after startup. The signal is represented as > MISO[5] in the Quartus II pin planner, and is an input in the associated > Verilog code. Moreover, SignalTap II tells me that the chip select #CS > output of the 6th ADC is high. Using Verilog code, I have attempted to > toggle the #CS of all ADCs. Doing so causes all MISO outputs of the > ADCs to drop low (when #CS is low), and then to go high again (when #CS > is high). However, according to the SignalTap II logic analyzer, > MISO[5] remains at logic low. > Even more bizarre is that the problem seems to take care of itself after the FPGA reads data from the ADCs. Apparently after the ADCs are triggered, MISO goes high, and then drops low again just in time for the data to be read from each ADC. NicholasArticle: 144691
Guru wrote: > Hi all, > > I am building a new megapixel camera based on Spartan3A DSP 3400. For > one of the applications I would need H.264 core with a performance of > minimal 66Mpix/s. I prefer EDK HW core since the camera "brain" is > composed there. > Does anyone has anything to recommend? > > Best regards, > > Ales Perhaps the following FOSS project from SourceForge would be of interest? http://hardh264.sourceforge.net/ http://www.drtonygeorge.com/Video/h264/h264_rtl.htm Apparently the hardh264 core is written in VHDL. You will have to evaluate this IP to see if it suits your application with respect to performance. Sometimes purchasing IP is necessary for an application, but perhaps this IP may be more than good enough for your own project. As alawys, be sure to check the licensing of all IP that you either download or purchase.Article: 144692
> Even more bizarre is that the problem seems to take care of itself after > the FPGA reads data from the ADCs. Apparently after the ADCs are > triggered, MISO goes high, and then drops low again just in time for the > data to be read from each ADC. > Strange but true: it appears that CS[5], which is the chip-select of the 6th ADC, was never being assigned in the Quartus II pin-planner. Oddly enough, the pin planner showed that the pin was indeed being assigned. Could this be a bug in the pin planner? I don't know. However, it now appears that the problem is gone, and all of the MISO pins go high on startup. NicholasArticle: 144693
On Dec 20, 12:11=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Dec 20, 8:43=A0am, emeb <ebromba...@gmail.com> wrote: > > > > > On Dec 19, 10:25=A0am, ghelbig <ghel...@lycos.com> wrote: > > > > Details I should have included: > > > > The external clock is a synthesizer that defaults to 50MHz. =A0After > > > initialization, it is changed to 100MHz. =A0The DCM is used to reduce > > > the skew between the internal clock and the external clock and create > > > a half-speed clock for some of the logic. > > > > Some percentage of the time, the chip "just don't run"; my current > > > theory is that the clock comes up strange. > > > > I'm not getting anything useful from the status lines. =A0At the time > > > the frequency is changed, I get a pulse on status[1]; after that, the= y > > > are always low. =A0I've waited "forever", and the locked signal never > > > goes true. > > > > Thanks! > > > Another suggestion, probably as helpful as "is it plugged in?" - make > > sure that the logic which generates your DCM reset isn't being clocked > > by that DCM. I facepalmed this once... > > > Eric > > Yeah, that's an excellent idea. =A0Especially in a complicated design, > reset loops are easy to achieve... > > Pat I think I found a solution. The external clock is spec'd at 150 fS (150 femptoseconds) of jitter, so I didn't go there. The status lines are near useless; observed behavior does not match their description. No amount of futzing with reset would make it behave as documented. I am switching the synthesizer from 50MHz to 100MHz after initialization. According to the data sheet, either the low range (18~167 MHz) or the high range (48~280 MHz) should be "just fine". In practice, the high range works (the DCM regains lock), and the low range does not. Live and learn.Article: 144694
> Hi, > Thanks a lot for the code. However, this seems more like a replacement for > the opencores.org I2C master core! Might be. But I didn't look at opencores. > I was wanting to use this core since it supports all the > 'harder-to-support' I2C specifications and it has been debugged for quite > a > while now. The only problem is that it only brings things up to the 'byte' > level. There still needs to be a fair level of handshaking and pooling in > order to generate a transfer of the type'write ABCD at address 08'. You would simply put this in your data array: START,h08,ACK,hAB,ACK,hCD,ACK,STOP, Not sure what else you need. You don't say. Brad Smallridge Ai VisionArticle: 144695
On 22 Dez., 16:03, Nicholas Kinar <n.ki...@usask.ca> wrote: > ------- > Warning: Can't achieve timing requirement Clock Setup: > 'my_pll:pll|altpll:altpll_component|_clk0' along 166 path(s). See Report > window for details. > > Warning: Can't achieve timing requirement Clock Setup: 'clk' along 95 > path(s). See Report window for details. > > Warning: Circuit may not operate. Detected 76 non-operational path(s) > clocked by clock "altera_internal_jtag~TCKUTAP" with clock skew larger > than data delay. See Compilation Report for details. > ------- > > I suspect that these warnings may indicate that there is a problem with > the timing analysis. Your suspection is almost right. As you already found the problem on the pin, I suggest to get rid of these Warnings before they bite you next. If the timing requirement could not be achieved, you are not guaranteed, that your design will always work in the intended way, as in some situations your data will need longer to be correct than your clock signal allows, which means your clock will sample wrong data. It may be possible, that the slack is so small, that you will experience this only on some devices or on some temperatures, a large slack might affect every device on every temperature, but due to the nature of the path it may be undetected for longer time, until you set the device in the condition, when this long path is sensible. A typical long path in an adder through the carry. This adder will have no problem for pairs of input numbers that didn't stress the carry (e.g. 0 and n, 1+4,...). If you want to add two numbers that stress carry you will see that some bits have the correct value and other the wrong value, leading to complete strange results. bye ThomasArticle: 144696
Hello, I want to configure an FPGA (Altera Cyclone II) using JTAG programming method via USB. I have done a design using a PIC18F2550 and succedded in configuring Xilinx FPGA. I want to do the same thing fo Altera devices. Has anybody done that previously? The point where I am stuck is, I don't know the internal file formats of Altera files (e.g. rbf or sof files etc.) I need information about header and other details in the altera file. So I can skip them and transmit only the configuration data on JTAG to the FPGA. Specifically, if anyone can guide me about the file formats of Altera, I will be thankful. Thanking in advance.. Regards, Gopal AmlekarArticle: 144697
You might be better off using the PIC (or whatever mirco/processor) implement the serial programming. This method is well documented and very straightforward to implement. I'm not sure Altera publishes anything allowing you to configure using JTAG, other than their proprietary ByteBlaster, etc. gopal_amlekar wrote: > Hello, > > I want to configure an FPGA (Altera Cyclone II) using JTAG programming > method via USB. I have done a design using a PIC18F2550 and succedded in > configuring Xilinx FPGA. I want to do the same thing fo Altera devices. > > Has anybody done that previously? The point where I am stuck is, I don't > know the internal file formats of Altera files (e.g. rbf or sof files etc.) > I need information about header and other details in the altera file. So I > can skip them and transmit only the configuration data on JTAG to the > FPGA. > > Specifically, if anyone can guide me about the file formats of Altera, I > will be thankful. > > Thanking in advance.. > Regards, > Gopal Amlekar > > >Article: 144698
On 4 Dec, 10:30, Mathias Weierganz <mwe...@expires-31-12-2009.news- group.org> wrote: > As a beginner in FPGA design I run to the following problem: > I want to generate a 200MHz clock by the DCM from 2 different > clock sources, one is a 10MHz clock, the other is 60MHz. > My idea was to divide the 60MHz by 6 and alternatively > switch between the both clock-signals. > > Mathias I am slightly confused with your suggestion. To generate a 200mhz clock signal from a 10 (or 60) mhz clock input, you have just to set the DCM frequency multiplication to 20(or 20/6). Am I mistaken?Article: 144699
On Dec 24, 12:25=A0pm, Angus <angusdun...@googlemail.com> wrote: > On 4 Dec, 10:30, Mathias Weierganz <mwe...@expires-31-12-2009.news- > > group.org> wrote: > > As a beginner in FPGA design I run to the following problem: > > I want to generate a 200MHz clock by the DCM from 2 different > > clock sources, one is a 10MHz clock, the other is 60MHz. > > My idea was to divide the 60MHz by 6 and alternatively > > switch between the both clock-signals. > > > Mathias > > I am slightly confused with your suggestion. To generate a 200mhz > clock signal from a 10 (or 60) mhz clock input, you have just to set > the DCM frequency multiplication to 20(or 20/6). Am I mistaken? The issue would be switching clock sources on the fly. The DCM at least before Virtex 5 was completely programmed by the bitstream, so you couldn't change the multiplication / division factors without at least a partial reconfiguration. So the idea of creating the same input frequency from two sources seems sound. What you might lose is any constant phase relationship to the input clocks. However if this is just a frequency synthesis problem that shouldn't matter. There's no reason not to use a fabric signal to feed the DCM if you don't need that phase relationship back to the input source. I suppose the original idea was to allow two sources so the 200 MHz would be available even if only one of the two clocks is running. One note of caution, if you have two clocks and want to switch between them using a BUFGMUX, then you should be aware that the glitch prevention circuitry can prevent the switch from occurring if one of the clocks is not running. So it may be better to use a fabric-based mux followed by a simple BUFG. Regards, Gabor
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