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
Hi, muthusnv@gmail.com wrote: > Has anyone successfully ported Petalinux in Microblaze (ML505) and There's an ML506 reference design in PetaLinux v0.30, which should be fairly simple to modify to run on a ML505. > used the SATA AHCI driver? > Is the AHCI driver from Petalinux distribution working OK? I'm not aware of anyone using it - it is jsut the same driver from a standard 2.6.20 kernel. Assuming you've got a working PCI layer up and running, I wouldn't expect great difficulties with the AHCI driver. Regards, JohnArticle: 129076
C-M, Chang wrote: > But unfortunately again, my boss deny to change design In that case, you are done. -- Mike TreselerArticle: 129077
Great adventures in Engineering: "Fix this, but do not change anything !" Peter Alfke On Feb 13, 6:31=A0pm, Mike Treseler <mike_trese...@comcast.net> wrote: > C-M, Chang wrote: > > But unfortunately again, my boss deny to change design > > In that case, you are done. > > =A0 =A0 =A0 =A0 =A0 =A0 -- Mike TreselerArticle: 129078
Out of a lot of 12 boards we've had two now that have experienced input pad failures (shorts to VCCO). These are LVDCI_25 IBUFs with VCCO = 2.5V. They are being driven by 2.5V LVCMOS output buffers from a Marvell Phy (RGMII interface). The Phy and Virtex-4 I/O are powered by the same 2.5V supply. The traces are in the 1.5" to 2" range and are unterminated. The engineer responsible for the board suspects overshoot, and says he has observed overshoot of up to 500mV on these lines (which happens to be the absolute max for Virtex-4 2.5V inputs). These traces and pins are not exposed so ESD is almost impossible as a cause of the failures. The Virtex-4 inputs are pretty beefy (well protected), and I personally have never seen an input buffer fail on any IC due to overshoot from a compatible driver (as opposed to being overvoltaged by an incompatible driver). So I have my doubts about overshoot causing the failures and want to make sure we understand this before building more boards. The current plan for the respin is to add series terminators to damp the signals. Even if the problem was not overshoot, the resistors are a good idea. I'm just looking for ideas and experiences on this. Thanks, boys (and girls!). RobArticle: 129079
>It's an interesting idea, and when mainstream processors start having >>16 cores, it will also be interesting to see when people start >"throwing away" things like x86 cores in a similar fashion. Let's hope they throw away the whole x86 architecture. It's flawed from the start.Article: 129080
Hi all, I am using Virtex 4 FPGA (XC4VFX100) in our application. In this, we find some erratic behaiour of FPGA. Whenever the bit file is loaded into the FPGA, there is a drop in core voltage(power module getting shutdown).Bit file gives such random behaviour uses particular three banks for its logic. Here we thought like this, it may be due to any internal damage in FPGA IOBs around that three banks. Here is the few points added, * We tried with a bit file that has high logic utilization (logic is not on that faulty banks. it uses other banks). It works fine. * Also we tried some other bit files with low logic utilization using that banks is working properly (power won't disturbed). * Whatever signals from that faulty banks are not shorted with VCC/ GND. We probed it. * Good core voltage power solution. Pls suggest me the solution to identify the exact source of that behaviour. Regards, VijayanArticle: 129081
On Feb 14, 10:22 am, Vijayan <vicchemi...@gmail.com> wrote: > Hi all, > > I am using Virtex 4 FPGA (XC4VFX100) in our application. In this, we > find some erratic behaiour of FPGA. > > Whenever the bit file is loaded into the FPGA, there is a drop in core > voltage(power module getting shutdown).Bit file gives such random > behaviour uses particular three banks for its logic. Here we thought > like this, it may be due to any internal damage in FPGA IOBs around > that three banks. > > Here is the few points added, > > * We tried with a bit file that has high logic utilization (logic is > not on that faulty banks. it uses other banks). It works fine. > * Also we tried some other bit files with low logic utilization using > that banks is working properly (power won't disturbed). > * Whatever signals from that faulty banks are not shorted with VCC/ > GND. We probed it. > * Good core voltage power solution. > > Pls suggest me the solution to identify the exact source of that > behaviour. > > Regards, > Vijayan Vijayan, I think that there is roughly a 10~20 % rise in current during configuration process, 1- What is the current being drawn from source during the configuration process in both working and failing bitstreams and is the voltage regulator capable of providing enough power and provide good voltage regulation under transients? 2- Have you seen X-ray inspection of BGA of short circuiting in those specific banks ? Just random thoughts, Hope some one with more experience would come up with better ideas. /MHArticle: 129082
i want information about fpga boards. for my application i required a fpga board with pcie interface and 10 Giga bit /s interface . i have searched a lot but i didn't find anyone. how can i find it. another question i want to ask is i am studying the manual of startix II GX PCI express development board .does it have 10 Gig interface. it has HSMC port. to use this card which daughter card will be used.but remember i need 10 Gig interface.Article: 129083
hi all, for my application i need a fpga board which has PCI express interface and 10 Gig ethernet or fibre channel interface. plz tell me if there is any board. one more thing startix II GX PCI Express development board of Altera has10 Gig interface or not if not which daughter card can be used to make it for 10 Gig.Article: 129084
On Wed, 13 Feb 2008 22:14:03 -0800 (PST), rabbiaqamar@yahoo.com wrote: >hi all, for my application i need a fpga board which has PCI express >interface and 10 Gig ethernet or fibre channel interface. plz tell me >if there is any board. >one more thing startix II GX PCI Express development board of Altera >has10 Gig interface or not If it's the development board I'm thinking of, it doesn't do 10Gb/s. The onboard StratixIIGX SERDES only works to about 6Gb/s. You could do 4G Fibrechannel or 1G Ethernet using the SFP sockets supplied. It's not too hard to roll your own 10Gb/s board though, but you'll need to use external SERDES parts if you want it to work. See AMCC, Vitesse, etc. A couple of years ago I would have said that XFP was the only 10Gb/s serial interface to use; now I would consider SFP+, as SFP+ will probably be much cheaper than XFP over the lifetime of products currently being designed. Regards, AllanArticle: 129085
<bobster.thelobster@yahoo.co.nz> wrote in message news:6e5dd37a-c594-479e-95a5-19d6136073bc@m34g2000hsf.googlegroups.com... > Sorry only half the post went :-) here it is again > > Hi Grumps, > > You say you¡¦re a beginner, so please allow me to offer the one piece > of advice that you should never waver from. > You are designing hardware, its not software, if you ignore that point > you¡¦ll join the ranks of people that are giving the industry a bad > name with their unstable designs. > Always try to imagine the circuit you¡¦re describing, and you won¡¦t go > far wrong. > > I¡¦m saying that only because you said you were a beginner, not because > of you code ƒº. > > > Anyway look at a state machine, it¡¦s usually a mishmash of flipflops > and logic gates. > A tristate is usually a buffer on a bus. In hardware that¡¦s 2 > different jobs. > > So do something like this > > 1st describe a tri-state buffer something like > > > signal MY_BUFFER_OUT, MY_BUFFER_IN, MY_BUFFER_CONTROL : std_logic; > > MY_BUFFER_OUT <= MY_BUFFER_IN when MY_BUFFER_CONTROL = ¡¥1¡¦ else ¡¥Z¡¦; > > Assign MY_BUFFER_CONTROL from your state machine, only assign 1 and 0 > to RDY, connect MY_BUFFER_OUT to your port and MY_BUFFER_IN to the > equivalent of RDY. > > This looks exactly the same if you think of it in software terms but > it¡¦s a different beast altogether if you take a hardware view. > I¡¦d just like to add, I¡¦m glad to see your using ISE, unlike the more > expensive tools it wont accept nonsense, my advice is stick with ISE > until your competent, then don¡¦t lose those good coding habbits. > > Let me know how it goes Bobsterthelobster Thanks for the advice and suggestions. Your code is (similar to) what I ended up doing. It's funny, I've been a hardware engineer for ages, and done FPGA design with Viewdraw schematics many years ago. We now have a VHDL department, so that's our preferred FPGA design route now. But this little project I thought I'd do myself. It works, and only takes 22 slices of a spartan3 (there is a little more to it than this 9-state state machine). I'm sure I'll be back here with more questions in the future. All the best.Article: 129086
"Vijayan" <vicchemical@gmail.com> wrote in message news:52a8d239-b0af-416a-8838-67ce47f90129@s13g2000prd.googlegroups.com... > Hi all, > > I am using Virtex 4 FPGA (XC4VFX100) in our application. In this, we > find some erratic behaiour of FPGA. > > Whenever the bit file is loaded into the FPGA, there is a drop in core > voltage(power module getting shutdown).Bit file gives such random > behaviour uses particular three banks for its logic. Here we thought > like this, it may be due to any internal damage in FPGA IOBs around > that three banks. Does the core vltg drop during configuration or after (or both) ?Article: 129087
Grumps schrieb: > [I posted this to comp.lang.vhdl, but maybe you FPGA experts know the > answer.] > > Hi > I'm not a VHDL expert, just learning, so please don't shout. > > I'm using Xilinx ISE9.2sp4 and have the following code as part of a state > machine: > CP_IN_OUTPUT_DECODE: process (state_cp_in) > begin > if state_cp_in = sta_idle then > RDY <= 'Z'; > BUSY <= '0'; > end if; > > if state_cp_in = sta_1 then > RDY <= '0'; > BUSY <= '0'; > end if; > > if state_cp_in = sta_2 then > RDY <= '1'; > BUSY <= '1'; > end if; > ... > ...etc > > The state machine goes from sta_idle, then to sta_1, then to sta_2, etc. > RDY is a pin on the device. > During operation, I can see RDY go low in sta_1, but not high in sta_2. I > know it gets to sta_2 as I can observe BUSY. I don't think RDY is tri-stated > in sta_2 as there is an external pull-up; it just stays low. Gray encoding > is used. > > If I change the RDY to rdyi (signal) and then have: > RDY <= 'Z' when state_cp_in = sta_idle else rdyi; > outside of the decode process then it all behaves itself. > > Apart from lack of experience, what mistake(s) have I made? > Thanks. > Hi Grumps, you did no simulation? so how can you be sure that your FSM ever enters sta_2 ? If you are using an if chain instead of a case for Output decoding you must keep in mind, that the last valid condition sets the output. even a typo can bring you in deep trouble. A case on the other hand has a more straightforward behavior. And the synthesis tool would complain when conditions appear twice. If RDY is a port there should be no problem with the 'Z' assignment. I strongly recommend to do a simulation. and if you like, you can try to rewrite your code like this (if applicable): case state_cp_in is when sta_idle => RDY <= 'Z'; BUSY <= '0'; when sta_1 => RDY <= '0'; BUSY <= '0'; when sta_2 => RDY <= '1'; BUSY <= '1'; ... end case; Have a nice synthesis EilertArticle: 129088
"backhus" <nix@nirgends.xyz> wrote in message news:fp0qmq$ebt$1@news.hs-bremen.de... > Grumps schrieb: >> [I posted this to comp.lang.vhdl, but maybe you FPGA experts know the >> answer.] >> >> Hi >> I'm not a VHDL expert, just learning, so please don't shout. >> >> I'm using Xilinx ISE9.2sp4 and have the following code as part of a state >> machine: >> CP_IN_OUTPUT_DECODE: process (state_cp_in) >> begin >> if state_cp_in = sta_idle then >> RDY <= 'Z'; >> BUSY <= '0'; >> end if; >> >> if state_cp_in = sta_1 then >> RDY <= '0'; >> BUSY <= '0'; >> end if; >> >> if state_cp_in = sta_2 then >> RDY <= '1'; >> BUSY <= '1'; >> end if; >> ... >> ...etc >> >> The state machine goes from sta_idle, then to sta_1, then to sta_2, etc. >> RDY is a pin on the device. >> During operation, I can see RDY go low in sta_1, but not high in sta_2. I >> know it gets to sta_2 as I can observe BUSY. I don't think RDY is >> tri-stated >> in sta_2 as there is an external pull-up; it just stays low. Gray >> encoding >> is used. >> >> If I change the RDY to rdyi (signal) and then have: >> RDY <= 'Z' when state_cp_in = sta_idle else rdyi; >> outside of the decode process then it all behaves itself. >> >> Apart from lack of experience, what mistake(s) have I made? >> Thanks. >> > Hi Grumps, > you did no simulation? so how can you be sure that your FSM ever enters > sta_2 ? Just a guess! All other state outputs seemed to follow my design. Only the RDY (which was the only one with the 'Z') was errant. What I posted was a cut-down version to make the issue clearer. > If you are using an if chain instead of a case for Output decoding you > must keep in mind, that the last valid condition sets the output. even a > typo can bring you in deep trouble. A case on the other hand has a more > straightforward behavior. And the synthesis tool would complain when > conditions appear twice. Yes, using an if chain. I can't see any typos, and all state conditions are tested. > If RDY is a port there should be no problem with the 'Z' assignment. RDY's an inout port. > I strongly recommend to do a simulation. I will. Not to check my design, which now works, but to see how the simulator works. > and if you like, you can try to rewrite your code like this (if > applicable): > > case state_cp_in is > when sta_idle => RDY <= 'Z'; > BUSY <= '0'; > when sta_1 => RDY <= '0'; > BUSY <= '0'; > when sta_2 => RDY <= '1'; > BUSY <= '1'; > ... > end case; I will try that. Should only take a few minutes. > Have a nice synthesis Thanks :)Article: 129089
chrisdekoh@gmail.com wrote: > Hi, > > 1) Does a microprocessor in debug mode run on a slower clock? I din > know that Sometimes cpus will run slower when you are using a debugger (for example, the debugger might have tracing features that require the cpu's cache to be disabled, or it might "simplify" the processor in other ways). However, I think what Alex meant was that the debug compile flags will generate slower code than when you pick flags for more optimisation. When using debug flags, the compiler will try to keep the structure of your program intact (such as its loops and functions), to make it easier to follow with a debugger. When doing full optimisation, the compiler will do more inlining and loop unrolling if that makes the code smaller and/or faster. > 2) under what circumstances should what variables be volatile? > A variable should be "volatile" to indicate that its value might be read or changed without the compiler knowing about it (including being accessed from another C function if the compiler does not know that it may also run at any time, such as an interrupt function or a separate thread). mvh., David > Chris > > > On Feb 14, 5:58 am, Alex Freed <al...@mirrow.com> wrote: >> GMM50 wrote: >>> Hi All: >>> This may indeed be a problem but how does debug make it all work. >>> george >> In my experience the most common scenario is a lack of "volatile" >> keyword. Debug version turns optimization off and release version >> optimizes a read of a hardware register out, 'cause it doesn't know it >> is hardware and nothing in the code changes it's value. >> >> The second possibility is a race condition. Dubug version may execute >> more slowly. >> >> -Alex. >Article: 129090
"Grumps" <grumpsnothere@hotmail.com> wrote in message news:61ibkcF1vc3kkU1@mid.individual.net... > "backhus" <nix@nirgends.xyz> wrote in message > news:fp0qmq$ebt$1@news.hs-bremen.de... >> Grumps schrieb: [ snipped ] >> and if you like, you can try to rewrite your code like this (if >> applicable): >> >> case state_cp_in is >> when sta_idle => RDY <= 'Z'; >> BUSY <= '0'; >> when sta_1 => RDY <= '0'; >> BUSY <= '0'; >> when sta_2 => RDY <= '1'; >> BUSY <= '1'; >> ... >> end case; > > I will try that. Should only take a few minutes. I replaced my original process based on lots of if <state> = <blah>, with the case method (above). It works! I don't fully understand why though. I simply replaced the "if state_cp_in = " with "when" in my original code so any typos would be preserved.Article: 129091
RobJ wrote: > Out of a lot of 12 boards we've had two now that have experienced > input pad failures (shorts to VCCO). These are LVDCI_25 IBUFs with > VCCO = 2.5V. They are being driven by 2.5V LVCMOS output buffers from > a Marvell Phy (RGMII interface). The Phy and Virtex-4 I/O are powered > by the same 2.5V supply. The traces are in the 1.5" to 2" range and > are unterminated. The engineer responsible for the board suspects > overshoot, and says he has observed overshoot of up to 500mV on these > lines (which happens to be the absolute max for Virtex-4 2.5V inputs). > > These traces and pins are not exposed so ESD is almost impossible as > a cause of the failures. The Virtex-4 inputs are pretty beefy (well > protected), and I personally have never seen an input buffer fail on > any IC due to overshoot from a compatible driver (as opposed to being > overvoltaged by an incompatible driver). So I have my doubts about > overshoot causing the failures and want to make sure we understand > this before building more boards. The current plan for the respin is > to add series terminators to damp the signals. Even if the problem > was not overshoot, the resistors are a good idea. I'm just looking > for ideas and experiences on this. > Thanks, boys (and girls!). > > Rob Hi Rob, I also doubt that the overshoot is to blame, and your caution is appropriate. Here's some questions, I apologise if some of them are teaching you to suck eggs! How do you know the I/P pad failure is short to VCCO? Did each board failed the same single FPGA pin? You've got a ground plane, right? What's the rise time of the signals? Did replacing the FPGA on the board fix the problem? How did your mate measure the overshoot? (I.e. can he work a high speed 'scope properly?) Does he wear an earth strap or nylon pants when probing? (Ahem!) Any 12V traces nearby on the board that a probe can short to these signal lines? Have you tried simulating with Hyperlynx or somesuch? Did you ask Xilinx to take a look at the broken parts? Are the two failures from the same batch? Are you sure the 2.5V power supply can't overvoltage? HTH. and good luck, Syms.Article: 129092
Allan Herriman wrote: > A couple of years ago I would have said that XFP was the only 10Gb/s > serial interface to use; now I would consider SFP+, as SFP+ will > probably be much cheaper than XFP over the lifetime of products > currently being designed. > > Regards, > Allan Hi Allan, Thanks for your post. Have you used SFP+ yourself yet? I'd be interested to hear your opinions and experiences. Thanks, Symon.Article: 129093
>I would like to know if a FPGA is suited for this application: sound >sources localization and separation. The algorithm comes in 3 steps: >sources detection using a steered beamformer (in frequency-domain), a >particle filter to track the sources and a combination of a geometric >source separation algorithm and a non-linear post-filter for source >separation. > >Also, the audio stream comes from an array of 8 microphones, and all >possible microphone pairs must be considered during the detection >phase. > >This algorithm is already implemented of a floating point DSP and I >would like to know if a FPGA could be a good choice to improve >performance. What aspect(s) of "performance" are you trying to improve? > >I heard that a FPGA wouldn't beat a DSP in floating point calculation, >what do you think about that? Still, I know that an implementation on >a FPGA will require a lot of work to translate the code anyway, so I >suppose it wouldn't be harder to rethink it directly in fixed point. Mostly true. FPGAs with hardware multipliers are essentially fixed-point, but can be extended to floating-point with sufficient "skill in the art". But if the algorithm will run fine on a fixed-point DSP, that might improve "performance" enough, anyway. > >The FPGA could be used to improve only a fraction of the algorithm >too. >Thanks for your comments. > >L-C >Article: 129094
hi, i have writen a pice of code which should impliment a value on the LEDs of my FPGA development board as the signal 'count' increases. However it is going strait to the ' when others => LEDs <= "00000000"; ' value. any help would be much appreciated... -- Declare signals signal CLK : std_logic; signal RST : std_logic; signal Count : std_logic_vector(21 downto 0); signal LEDs : std_logic_vector(7 downto 0); signal LEDVal : std_logic_vector(7 downto 0); signal Dir : std_logic; begin -- Tie unused signals User_Signals <= "ZZZZZZZZ"; IO_CLK_N <= 'Z'; IO_CLK_P <= 'Z'; IO <= (0=>LEDs(0), 1=>LEDs(3), 41=>LEDs(4), 42=>LEDs(1), 43=>LEDs(4), 44=>LEDs(5), 45=>LEDs(2), 46=>LEDs(7), others => 'Z'); -- Clock divider process (CLK, RST) begin if (RST='1') then Count <= (others=>'0'); elsif (CLK'event and CLK='1') then Count <= Count + 1; end if; end process; process (CLK, RST) begin case Count is when "0000000000000000000000" => LEDs <= "00000001"; when "0000000000000000000001" => LEDs <= "00000010"; when "0000000000000000000010" => LEDs <= "00000100"; when "0000000000000000000011" => LEDs <= "00001000"; when "0000000000000000000100" => LEDs <= "00001001"; . . when "0000000000000001111110" => LEDs <= "01000000"; when "0000000000000001111111" => LEDs <= "10000000"; when others => LEDs <= "00000000"; end case; end process;Article: 129095
On Feb 13, 11:33 am, "C-M, Chang" <cmchan...@gmail.com> wrote: > On 2$B7n(B13$BF|(B, $B2<8a(B9$B;~(B42$BJ,(B, KJ <kkjenni...@sbcglobal.net> wrote: > > Thanks KJ for anser and told my question clear. > But unfortunately again, my boss deny to change design (coding from > somewhere). > In my project, I think that ck125 and ck25 are set as global clock > network. I guess a global clock network need 4ns delay, so my ck125 > has 4ns delay, and ck25 has 8ns delay. (4ns from ck125 and 4ns itself > global clock network). > Does Quartus have any option let ck25 just has 4ns delay. > Or can i use something like: > set_instance_assignment -name MAX_DELAY 0.5ns -from regB -to regA, (i > think this no work) > or > set max_clock_arrival_skew ,min_data_arrival_skew or > SETUP_RELATIONSHIP > can someone told me in the situatuin which choise is better, and is > right, > Because i can not change code. > Thanks. > Just to make things worse, I think you might also only be looking at half of the problem. If you tell Quartus to also a fast timing model analysis you might find that you have hold time issues on some of the clock domain crossings. But even if you don't have any now, if you were to find some way to control the delay of ck25 to get rid of the setup problem then it is even more likely that you'd see the hold time problem. Bottom line....there is no way to generate a clock signal as the output of a flip flop clocked by some other clock and not create skew between those two clocks. That is the root of the problem that is showing up for you as setup issues (and possibly hold time issues as well). It's not a Quartus issue, or even an FPGA issue, it's nothing that you can add some magic constraint to engineer a fix. That's why there are PLLs/DLLs inside the more modern FPGAs because they can generate derived clocks from a source clock in a completely different manner and by doing so, they can precisely manage the phase relationship of the source and derived clocks. On a more positive note, it's possible that the original designers know all about the clock domain crossings and designed things such that when ck125 is generating a signal that is to be sampled by ck25 that they do not allow that signal to change around the time that the rising edge of ck25 is going to occur. Also any signal that gets clocked by ck25 and then gets sampled by ck125 does not get sampled around the time that ck25's rising edge has just occurred. If that's the case for each and every signal, then these clock domain transfers are being handled properly by design and all you have to do to get rid of the setup (and or hold) violations is to specify a multi- cycle constraint on those signals. Although a multi-cycle constraint 'could' be used by the synthesis engine to possibly optomize something, what it is mostly doing is saying that these signals are allowed to take more than one clock cycle to settle out so when performing the timing analysis the 8 ns clock period of ck125 is relaxed to say 16 ns or 24 ns (depending on what value you set multi_cycle to to correspond to 2 or 3 clock cycles). The problem is that it is far too easy to convince yourself that something will be stable for more than one clock cycle and not changing when you don't want it to be when in fact it isn't. Adding the multi_cycle constraint in some sense is simply saying that you don't want to be bothered with reports of supposed violations, the danger being that you analyzed it incorrectly. To analyze it though, you need to do a thorough simulation and inspection/understanding of the code to see if these assumptions are correct...and then re-run and re-check if the design changes in any way because that change may be done in such a way that it now violates the required multi cycle assumption. Lastly, if none of the above applies and the boss insists on no design changes then there isn't much of anything you can do other than change the random number seed, cross your fingers and hope....that isn't engineering and it won't be a robust solution but you might get lucky because luck will be your only ally. Kevin JenningsArticle: 129096
Hi Rob, Like Symon had quoted you have to provide more information, like: - Are the affected pins nearby to 2.5V pins or traces? I have seen board short circuit that happens only after assembly process due to thermal or mechanical stress. - Are you sure it is not related to board assembling process? - Did you extracted the Phy or FPGA to know which device is causing the short to 2.5V? - If the short doesn't happen in the moment the board is energyzed how long it takes to happen? Does the board/device increase in temperature before it happens? - Freezing the board changes the behavior? - Only when all possible board related causes can be discarded then the stress could be reason and only then the talk about overshoot or silicon behavior should arise. Good luck, -AugustoArticle: 129097
I've implemented a flash programmer for the EPCS1 serial flash, attached to a Cyclone, using the Serial Flash Loader entity. Programming and reading the flash works, but how do I create the data for programming it? I've programmed it with a Byte Blaster and a JIC file from within Quartus and comparing the content which was flashed with a RBF file, it looks like every byte is just mirrored (from LSB to MSB instead of MSB to LSB) and some bits at the beginning are different. Is it safe to use this RBF file for flashing the flash? Another question: I would like to compare the flash content with some external file whenever the system starts, if an update is needed. Would be good, if I could just read some checksum or date signature inside the flash (currently I'm writing my own checksum at the last block of the flash). Is there a documentation of the RBF file format? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 129098
On Thu, 14 Feb 2008 04:50:13 -0800 (PST), rossalbi <rossalbi@hotmail.com> wrote: >hi, i have writen a pice of code which should impliment a value on >the >LEDs of my FPGA development board as the signal 'count' increases. >However it is going strait to the ' when others => LEDs <= >"00000000"; How do you know it is going straight to that state? You don't tell us what the CLK signal is ... 1 Hz? 80 MHz? A push button? - BrianArticle: 129099
L-C <Louis-Charles.Caron@usherbrooke.ca> writes: > I would like to know if a FPGA is suited for this application: sound > sources localization and separation. The algorithm comes in 3 steps: > sources detection using a steered beamformer (in frequency-domain), a > particle filter to track the sources and a combination of a geometric > source separation algorithm and a non-linear post-filter for source > separation. > > Also, the audio stream comes from an array of 8 microphones, and all > possible microphone pairs must be considered during the detection > phase. > > This algorithm is already implemented of a floating point DSP and I > would like to know if a FPGA could be a good choice to improve > performance. In that case, profile your current implementatio. Find out which piece of code is the causing you most problems. Focus on that, you might find it amenable to FPGA implementation (but don't discount the overhead of moving data from your DSP to the FPGA). I wouldn't attempt to move the whole thing into hardware, although you could put the bits that remain software into an FPGA processor, in which case the "acceleration " hardware can be much more closely coupled with the SW. > > I heard that a FPGA wouldn't beat a DSP in floating point calculation, > what do you think about that? Depends - a big FPGA can do a *lot* of FP in parallel, if your algorithms are amenable. HTH, Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
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