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 Jan 17, 2:09=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > aleksa wrote: > > Is now everything ok? > > NO. > Reread the previous posts > "And here is your problem. =A0You're using RD and ADDR asynchronously." > > "_DON'T_USE_THE_RD_SIGNAL_AS_AN_ASYNCHRONOUS_SIGNAL_" > > > IRQFLAGS : process (cCLKMAIN, RD) begin > > RD is not a clock. > RD is a plain input. > cCLKMAIN is the only clock. > to detect a 0, 1 sequence on RD, use a shift register on cCLKMAIN > > Good night and good luck. > > =A0 =A0 =A0 -- Mike Treseler RD IS connected to a global clock pin. RD pulse is 70nS so I can't test it with a 50nS CLKMAIN, right? Using Spartan II.Article: 137451
Hi, I am using a Digilent Basys Board with Xilinx Spartan 3e. I have an I2C controller configured to FPGA, which reads data from externally connected I2C EEPROM through the pmod connectors on the basys board. I am having below problems. 1) FPGA happens to work only once(outputs correct result on the leds) when configured. When I the reset I2C controller, the functionality does not repeat instead all leds are lit or off. 2) When I reset(or switch the power off and on) the FPGA and try to re- configure it, the chip does not work as expected. But when I pull the EEPROM off the breadboard, reconnect it, reset the FPGA and reconfigure it, then I get the result, only for the first time. I tried simulating by giving reset many times in the testbench and results were as expected in the simulation. Why am I having issues in the hardware? Can any one please help? Thanks.Article: 137452
A month back i did successful testing of partial reconguration. When i tried to do the same thing again on another computer (as that computer is no more available to me) , I installed the ise , patch and all in similar manner. I am able to do the things only till Exploreahead runs. When i give the command RUN PR ASSEMBLE, it shows 'PR assemble is done' in a second (as contrary to long time taken when i did it successfully) . It doesnt form the static_full.bit in merge directory , instead some .bitgen are found in PRAtmpdir folder. I have attached the output file of run PR assmble step with it and screenshot of the files formed by it in merge directory. Please help me to find out the problem. I have tried installing everything again atleast 5-6 times assuming that i might have commited any mistake during installation. I have done partial reconfigution earlier with the same setups, so i am not able to find out the reason for this setup not forming the bitstream. Only .bitgen's are formed,.bit's is not getting formed. While doing partial reconfiguration using Planahead , when i run the command hdi:: param set -name project.enablePR -bvalue yes the an error comes saying parameter "project.enablePR" does not exist. Can it be the reason for all this.? I am setting the project as PR from file-->set PR project in planahead.Article: 137453
On Jan 17, 2:17=A0am, Digi Suji <digis...@gmail.com> wrote: > Hi, > > I am using a Digilent Basys Board with Xilinx Spartan 3e. I have an > I2C controller configured to FPGA, which reads data from externally > connected I2C EEPROM through the pmod connectors on the basys board. I > am having below problems. > > 1) FPGA happens to work only once(outputs correct result on the leds) > when configured. When I the reset I2C controller, the functionality > does not repeat instead all leds are lit or off. > > 2) When I reset(or switch the power off and on) the FPGA and try to re- > configure it, the chip does not work as expected. But when I pull the > EEPROM off the breadboard, reconnect it, reset the FPGA and > reconfigure it, then I get the result, only for the first time. > > I tried simulating by giving reset many times in the testbench and > results were as expected > in the simulation. Why am I having issues in the hardware? > > Can any one please help? > > Thanks. Is the output from the EEPROM driving one of the FPGA's dual-porpose configuration pins? Which FPGA configuration mode are you using?Article: 137454
On Jan 15, 9:15=A0pm, "robj" <r...@abc.net> wrote: > <iko...@alumni.technion.ac.il> wrote in message > > news:1188838781.893882.166580@r29g2000hsg.googlegroups.com... > > >I was trying to estimate the power consumption of IGLOO AGL600V2 FPGA > > from Actel with IGLOO power calculator (posted on Actel website). I > > received very astonishing results. [... snip ...] From previous experience, be very skeptical in the answers provided by the power "estimators". I haven't tried the Actel estimator so theirs might be quite good. The Xilinx estimator, at least is 9.1i, seems to be overly pessimistic (the acutal power measured in system was about 40% lower). > > I'm using IGLOO now for exactly the reasons you state. The main differenc= e > vs. SRAM-based FPGAs is the insanely low static current (measured in uW e= ven > in the largest device in the family). The dynamic current is on the order= of > 30-40% vs. those guys from what I've seen. As a test I compiled a real > design into a Xilinx XC2V250 and an AGL600V2. These devices are roughly > comparable in size. I then and used the vendor tools to estimate power on > the placed and routed designs. Here's what I got: > > XC2V250-4CS144: > > Max clock frequency: 119MHz > Flip flops: 757/3072 (24%) > 4-input LUTs: 817/3072 (26%) > Block RAMs: 5/24 > Estimated power: 253mW* (using Xilinx's XPower tool) > =A0 Static: 32mW > =A0 Dynamic: 221mW > > * Calculated at 80MHz with 12.5% data toggle rate. > > AGL600V2-FG144: > > Max clock frequency: 33.3MHz > Flip flops: 870 > Total VersaTiles: 4974/13824 (36%) > Block RAMs: 5/24 > Estimated power: 66mW** (using Actel's SmartPower tool) > =A0 Static: 0.067mW (67uW) > =A0 Dynamic: 66mW > > ** Calculated at 80MHz with 12.5% data toggle rate (even though design wo= n't > run that fast). > > The IGLOO power is ~25% of the Xilinx power at the same frequency, and th= e > IGLOO static power is only 67 uW (~1/500th of the Xilinx). Truly amazing. > You pay the price for that low power, though, as the design runs 3.5x as > fast in the Xilinx. But for some designs, like the one I'm working on now= , > low power is paramount. Again, be careful comparing power estimators. Both are just an approximation of the real design unless you do much more careful analysis. It's difficult to compare one broad side of a barn against another. That said, Igloo certain has much better static power than many other FPGAs. BTW, if you're looking for low power, also check out the SiliconBlue iCE65 FPGA family. After years of working with other FPGAs, I thought I blew a fuse on my bench supply until I realized that the SiliconBlue FPGA was only using 27 uA of static current (measured with a much better quality meter). The built-in analog meter on the supply looked like it was pegged at 0 current. The SiliconBlue parts also have very low dynamic power, much lower than Spartan-3A or Cyclone III parts but aren't as fast. All three families use a 1.2V supply. The SiliconBlue parts also supposedly support 1.0V, which will reduce power consumption even more, although I haven't tried that yet. > As for the Coolrunner-II, the Coolrunner is a 1.8V part vs. 1.2V for the > IGLOO V2. That's a 50% power difference right off the bat. The rest must > just be differences in the design and process. Actually, the dynamic power is related to the square of the voltages (fCV^2). If I'm doing my math correctly (a dangerous thing on a weekend), then the 1.2V parts should use about 44% less dynamic power, or less than half the dynamic power of the 1.8V part. (1.2V^2/1.8V^2). Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 137455
hi all, it's funny to see the Actel crowd pop up :-) several posters posted : >>> XC2V250-4CS144: >>> Max clock frequency: 119MHz >>> AGL600V2-FG144: >>> Max clock frequency: 33.3MHz that's quite possible, and a technology change can have such results. It reminds me that I once run some extremely optimised code faster on a P200MMX than on a P2-233MHz. The architectural details were completely different, and a port from a 4-LUT to a 3-tile can have this effect. Silicon technologies have their effect too. >> They're great for what they do well but just be wary if you need >> to push the performance (at all). > > Igloo is slow, that's true, but ProAsic3 should be able to handle 66 > Mhz. My current ProAsic3 is running at 160 Mhz, using vanilla vhdl. > No special constraints or manually placed logic blocks were needed > other than specifying clock speed. My current target is 100MHz with standard A3P, and I get 105-110MHz with a 6-tile critical datapath. Remove 2 when a blockRAM is used. So a 3-input "tile" counts for around 1,5ns, incl. connections, in average. With that in mind, one can estimate the pipelining effort. I second what the precedent posters say : the Actel parts are nice and satisfying for what they do. Now, for a ultra-high performance project, they won't fit. Since I've long forgotten my gigaherz dreams, it's not an issue for me, particularly if it can be powered from a smal(ler) battery. have fun, -- http://ygdes.com / http://yasep.orgArticle: 137456
Hi guys, I've written a VHDL entity in which I'm instantiating a distributed memory block generated by Xilinx CoreGen. Now, I want to use this entity a number of times in a bigger design. In each instantiation, I need to initialize the memory with different contents (.coe file). Since only one .xco file is generated for the dist. memory, I am not sure if there is a way to do so. Has anybody done the same thing? Can you suggest me any alternatives?Article: 137457
On Jan 17, 2:13=A0pm, Prevailing over Technology <steve.kn...@prevailing- technology.com> wrote: > On Jan 17, 2:17=A0am, Digi Suji <digis...@gmail.com> wrote: > > > > > Hi, > > > I am using a Digilent Basys Board with Xilinx Spartan 3e. I have an > > I2C controller configured to FPGA, which reads data from externally > > connected I2C EEPROM through the pmod connectors on the basys board. I > > am having below problems. > > > 1) FPGA happens to work only once(outputs correct result on the leds) > > when configured. When I the reset I2C controller, the functionality > > does not repeat instead all leds are lit or off. > > > 2) When I reset(or switch the power off and on) the FPGA and try to re- > > configure it, the chip does not work as expected. But when I pull the > > EEPROM off the breadboard, reconnect it, reset the FPGA and > > reconfigure it, then I get the result, only for the first time. > > > I tried simulating by giving reset many times in the testbench and > > results were as expected > > in the simulation. Why am I having issues in the hardware? > > > Can any one please help? > > > Thanks. > > Is the output from the EEPROM driving one of the FPGA's dual-porpose > configuration pins? =A0Which FPGA configuration mode are you using? Thanks for the response. Yes external I2C EEPROM is driving FPGA's dual purpose config pins. Will this cause a problem? I am using spartan 3e TQ-144 FPGA. I could not find mode pins on this fpga's footprint. How do I set master serial mode config for this FPGA? Please help if I am wrong. ThanksArticle: 137458
On Jan 17, 2:13=A0pm, Prevailing over Technology <steve.kn...@prevailing- technology.com> wrote: > On Jan 17, 2:17=A0am, Digi Suji <digis...@gmail.com> wrote: > > > > > Hi, > > > I am using a Digilent Basys Board with Xilinx Spartan 3e. I have an > > I2C controller configured to FPGA, which reads data from externally > > connected I2C EEPROM through the pmod connectors on the basys board. I > > am having below problems. > > > 1) FPGA happens to work only once(outputs correct result on the leds) > > when configured. When I the reset I2C controller, the functionality > > does not repeat instead all leds are lit or off. > > > 2) When I reset(or switch the power off and on) the FPGA and try to re- > > configure it, the chip does not work as expected. But when I pull the > > EEPROM off the breadboard, reconnect it, reset the FPGA and > > reconfigure it, then I get the result, only for the first time. > > > I tried simulating by giving reset many times in the testbench and > > results were as expected > > in the simulation. Why am I having issues in the hardware? > > > Can any one please help? > > > Thanks. > > Is the output from the EEPROM driving one of the FPGA's dual-porpose > configuration pins? =A0Which FPGA configuration mode are you using? Yes, output from EEPROM is driving FPGA's dual-purpose pins. I am using Spartan3E based BASYS board, I cannot set the mode pins of my choice. I2C master controller is being implemented in FPGA which is supposed to read data from external I2C EEPROM. Can you tell me what is the issue? Thanks.Article: 137459
aleksa wrote: > RD pulse is 70nS so I can't > test it with a 50nS CLKMAIN, right? http://www.fpga4fun.com/CrossClockDomain2.htmlArticle: 137460
On Jan 17, 8:09=A0pm, Ehsan <ehsan.hosse...@gmail.com> wrote: > Hi guys, > > I've written a VHDL entity in which I'm instantiating a distributed > memory block generated by Xilinx CoreGen. Now, I want to use this > entity a number of times in a bigger design. In each instantiation, I > need to initialize the memory with different contents (.coe file). > Since only one .xco file is generated for the dist. memory, I am not > sure if there is a way to do so. Has anybody done the same thing? Can > you suggest me any alternatives? If you want initialize the contents of each RAM from a separate .coe file, you will need to run CoreGen for each distinct .coe file. So each instance will have a distinct .xco file as well, even though the settings may be the same except for the .coe file. .xco files are in a text format, and you could copy the first one to a number of other .xco files and then use a text editor to change the path for the .coe file in each new .xco file. You can then add the new .xco files to your project and "regenerate cores". Regards, GaborArticle: 137461
"Ehsan": > I've written a VHDL entity in which I'm instantiating a distributed > memory block generated by Xilinx CoreGen. Now, I want to use this > entity a number of times in a bigger design. In each instantiation, I > need to initialize the memory with different contents (.coe file). > Since only one .xco file is generated for the dist. memory, I am not > sure if there is a way to do so. Has anybody done the same thing? Can > you suggest me any alternatives? No, sorry. Why do people use coregen to generate logic that xst can directly infer from HDL? Any advantage using coregen? Gruss Jan BrunsArticle: 137462
Jan Bruns wrote:
> Why do people use coregen to generate logic that xst can directly
> infer from HDL?
comp.arch.fpga is historically oriented
toward xilinx cores and demo boards rather than synthesis.
HDL synthesis fans tend to hang in the vhdl and verilog groups.
> Any advantage using coregen?
Not to me.
If I didn't know vhdl and modelsim,
and if I were in a frantic hurry,
I can imagine giving it a try.
-- Mike Treseler
Article: 137463I stumbled upon SiliconBlue a month or two ago. Had never heard of them before. Very impressive power numbers, but the performance looks very limited. From looking at some of their reference designs I got the impression 15-20MHz would be about the limit for anything reasonably complex. Can you give any info on how you're using the parts and what kind of performance you're seeing? The static current numbers are not much different than IGLOO, but IGLOO has enough horsepower to do some real processing. Just nothing close to a Virtex-5 or Stratix-III. RobArticle: 137464
Hi all, I'm a VHDL beginner and I've a trouble with a simple VHDL piece code. Writing the same thing in two ways that (appearently to me) seem to be the same, produce different resuls. In one case the code is synthesized, in the other it is not. This is the first piece of code, written as a process. It is well synthesized: sample_parallel_data : process(SYS_CK_IN,RESET) begin if(RESET = '0') then tx_data <= (others => '0'); elsif(rising_edge(SYS_CK_IN)) then if(counter mod (SYS_CK_RATIO/2) = 0) then if(last_lr_ck = '1') then tx_data <= "0" & DATA_R(IN_WIDTH-1 downto 0) & "0000000"; else tx_data <= "0" & DATA_L(IN_WIDTH-1 downto 0) & "0000000"; end if; else tx_data <= tx_data(BITXCH-2 downto 0) & '0'; --shift data left end if; end if; end process; Now there's the some code, written as a concurrent statement... this one reports me the error "Signal tx_data cannot be synthesized, bad synchronous description." tx_data <= (others => '0') when RESET='0' else '0' & DATA_L(IN_WIDTH-1 downto 0) & "0000000" when rising_edge(SYS_CK_IN) and (counter mod (SYS_CK_RATIO/2) = 0) and last_lr_ck = '1' else '0' & DATA_R(IN_WIDTH-1 downto 0) & "0000000" when rising_edge(SYS_CK_IN) and (counter mod (SYS_CK_RATIO/2) = 0) and last_lr_ck = '0' else tx_data(BITXCH-2 downto 0) & '0' when rising_edge(SYS_CK_IN); Why are these piece of code different? It appear the same thing in my mind ! Thanks all, Primiano Tucci -- http://www.primianotucci.com/Article: 137465
I forgot some details, tx_data is a signal signal signal tx_data : std_logic_vector(BITXCH-1 downto 0); DATA_L and DATA_R are two input ports DATA_L : in std_logic_vector(IN_WIDTH-1 downto 0); DATA_R : in std_logic_vector(IN_WIDTH-1 downto 0); BITXCH is a constant = 32 IN_WIDTH is a constant = 24 Thanks Primiano Tucci -- http://www.primianotucci.com/Article: 137466
On Sun, 18 Jan 2009 11:28:00 -0800, Mike Treseler wrote: >Jan Bruns wrote: > >> Why do people use coregen to generate logic that xst can directly >> infer from HDL? > >comp.arch.fpga is historically oriented >toward xilinx cores and demo boards rather than synthesis. >HDL synthesis fans tend to hang in the vhdl and verilog groups. > > > Any advantage using coregen? > >Not to me. I'm an out-and-out HDL fan - I was fighting to get away from schematics back in 1980ish, when PALASM gave me the first glimmer of light at the end of the tunnel - but there are times when Coregen/Megawizard/you-name-it is worth its weight in silicon; I'm quite happy to let someone else design two-clock FIFOs for me, for example. And I accept its usefulness for PLLs and suchlike. But there's no doubt that seeing stuff like magnitude comparators in Coregen has a severely unfavourable effect on my blood pressure and language. Let's see now: HDL: ~~~~ if A > B then ... Coregen/MegaWizard/...: ~~~~~~~~~~~~~~~~~~~~~~~ a. Start up wizard. Go to brew coffee. It's running by the time you return from the kitchen. b. Choose correct flavour of comparator. Drink some coffee. c. Wade through several dialog screens. Coffee cools. d. Hit "Finish". Chew pencil fretfully, consider ordering faster hard disk or even more memory. e. Inspect output files, which are hard to find among the 457 other files in the project directory, none of which you recall creating and few of which interest you. Locate the sixteen files relating to the comparator, identify the three of those that you really care about. f. Create instance of comparator in HDL code. Create otherwise useless comparison-result signal. Get data types wrong. Iterate until successful compilation. g. Remember that the primitives libraries need compiling. Start the script (if you can find it); go to brew more coffee. h. Simulate. Speculate that preposterous results may be caused by swapping the comparator's inputs so that we get < rather than > comparison. Open bottle of something much stronger than coffee. i. Iterate over f,g,h until results not preposterous. Progressively consume contents of bottle. j. Synthesize, test on bench. Observe extreme distortion of output signals from FPGA and DAC. Cast suspicion on comparator. Speculate that inappropriate choice of signed or unsigned arithmetic may be the root cause, but by now the effects of the bottle are sufficiently advanced that you can't remember the difference. k. Children and/or partner return from work/college/school and greet you fondly. Scream at them irrationally. l. Return to (a) and start over. Iterate until narcolepsis. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137467
Mike Treseler <mtreseler@gmail.com> wrote: > Jan Bruns wrote: >> Why do people use coregen to generate logic that xst can directly >> infer from HDL? > comp.arch.fpga is historically oriented > toward xilinx cores and demo boards rather than synthesis. > HDL synthesis fans tend to hang in the vhdl and verilog groups. Some get cross posted, and likely some FPGA questions get asked only in the comp.lang.* groups. > > Any advantage using coregen? > Not to me. Not having used coregen recently, it might be that in some cases it results in more compact or speedier results. The more the tools know about what you are actually trying to do the better the results are likely to be. It you don't need every last LUT and nanosecond then infer directly. Otherwise, instantiate the results of coregen into the HDL design. Or do both and see which gives better results. -- glenArticle: 137468
On Sun, 18 Jan 2009 12:59:55 -0800 (PST), p.tucci wrote:
>Writing the same thing in two ways that (appearently to me) seem to be
>the same, produce different resuls.
>
>In one case the code is synthesized, in the other it is not.
>
>This is the first piece of code, written as a process.
>It is well synthesized:
Yes, because it follows the standard synthesis template
that all synth tools understand.
> sample_parallel_data : process(SYS_CK_IN,RESET) begin
> if(RESET = '0') then
> tx_data <= (others => '0');
> elsif(rising_edge(SYS_CK_IN)) then
[... do interesting things to tx_data...]
> end if;
> end process;
>Now there's the some code, written as a concurrent statement... this
>one reports me the error
>"Signal tx_data cannot be synthesized, bad synchronous description."
>tx_data <=
> (others => '0') when RESET='0'
> else
> '0' & DATA_L(IN_WIDTH-1 downto 0) & "0000000"
> when rising_edge(SYS_CK_IN)
> and (counter mod (SYS_CK_RATIO/2) = 0)
> and last_lr_ck = '1'
> else
> '0' & DATA_R(IN_WIDTH-1 downto 0) & "0000000"
> when rising_edge(SYS_CK_IN)
> and (counter mod (SYS_CK_RATIO/2) = 0)
> and last_lr_ck = '0'
> else
> tx_data(BITXCH-2 downto 0) & '0'
> when rising_edge(SYS_CK_IN);
I agree with you that the two pieces of code should simulate
in the same way (I haven't checked the details, but it certainly
looks about right). However, the second example has at least
two problems that would surely cause many synthesis tools to fail:
(1) You have three distinct "else" branches, and EACH BRANCH
has a clock edge test in it. Synthesis tools usually expect
the clock edge test to be at the outermost level of nesting.
(2) In two of those three branches, you have other logic ANDed
with the clock edge test. Again this doesn't match the
synthesisable template, and many (maybe even "all") synth
tools will reject it.
I'm not promising, but you MAY find that the following form
synthesises OK:
tx_data <=
(others => '0')
when RESET='0'
else
func(tx_data, DATA_L, DATA_R, last_lr_ck)
when rising_edge(SYS_CK_IN);
where "func()" is a function that performs all the
necessary next-state logic - essentially, the body
of the clocked branch of your first, successful process.
But it's far better to stick to the standard template,
especially in cases like this where there is no benefit
to using a different style.
~~~~~~~~~~~~
Be aware that you'll probably get a better response
on comp.lang.vhdl for pure VHDL questions like this.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 137469On Jan 19, 2:16=A0am, Gabor <ga...@alacron.com> wrote: > On Jan 17, 8:09=A0pm, Ehsan <ehsan.hosse...@gmail.com> wrote: > > > Hi guys, > > > I've written a VHDL entity in which I'm instantiating a distributed > > memory block generated by Xilinx CoreGen. Now, I want to use this > > entity a number of times in a bigger design. In each instantiation, I > > need to initialize the memory with different contents (.coe file). > > Since only one .xco file is generated for the dist. memory, I am not > > sure if there is a way to do so. Has anybody done the same thing? Can > > you suggest me any alternatives? > > If you want initialize the contents of each RAM from a > separate .coe file, you will need to run CoreGen for each > distinct .coe file. =A0So each instance will have a distinct > .xco file as well, even though the settings may be the > same except for the .coe file. > > .xco files are in a text format, and you could copy the > first one to a number of other .xco files and then use > a text editor to change the path for the .coe file in > each new .xco file. =A0You can then add the new .xco files > to your project and "regenerate cores". > > Regards, > Gabor "Gabor" My design has a hierarchy like this: Module TOP -> Module A -> DistMem I need to instantiate Module A 16 times in the TOP. If I generated 16 .xco files for DistMem, Does it mean I need to generate 16 "Module A"s as well? So, I have a new problem now, how to instantiate Module A in the TOP module and tell it which .xco (or DistMem component) to be used? BTW, I'm using VHDL. ThanksArticle: 137470
Hey guys, I am writing to a RAM at a 40MHz pixel input from a camera, but need to access it at 25MHz for VGA output. Is it fine to disable the RAM between storing/accessing and change the clocks and other lines over then re-assert the enable? Is there a better way to do this? If it would be fine, for how many clock cycles should I dis-assert the enable while mux-ing inputs? Cheers, GintsArticle: 137471
reganireland@gmail.com wrote: > Hey guys, > > I am writing to a RAM at a 40MHz pixel input from a camera, but need > to access it at 25MHz for VGA output. Is it fine to disable the RAM > between storing/accessing and change the clocks and other lines over > then re-assert the enable? Is there a better way to do this? > > If it would be fine, for how many clock cycles should I dis-assert the > enable while mux-ing inputs? > You're not describing the type of RAM, which makes this question rather hard to answer. -hpaArticle: 137472
On Jan 18, 8:50=A0pm, Ehsan <ehsan.hosse...@gmail.com> wrote: > On Jan 19, 2:16=A0am, Gabor <ga...@alacron.com> wrote: > > > > > On Jan 17, 8:09=A0pm, Ehsan <ehsan.hosse...@gmail.com> wrote: > > > > Hi guys, > > > > I've written a VHDL entity in which I'm instantiating a distributed > > > memory block generated by Xilinx CoreGen. Now, I want to use this > > > entity a number of times in a bigger design. In each instantiation, I > > > need to initialize the memory with different contents (.coe file). > > > Since only one .xco file is generated for the dist. memory, I am not > > > sure if there is a way to do so. Has anybody done the same thing? Can > > > you suggest me any alternatives? > > > If you want initialize the contents of each RAM from a > > separate .coe file, you will need to run CoreGen for each > > distinct .coe file. =A0So each instance will have a distinct > > .xco file as well, even though the settings may be the > > same except for the .coe file. > > > .xco files are in a text format, and you could copy the > > first one to a number of other .xco files and then use > > a text editor to change the path for the .coe file in > > each new .xco file. =A0You can then add the new .xco files > > to your project and "regenerate cores". > > > Regards, > > Gabor > > "Gabor" > > My design has a hierarchy like this: > > Module TOP -> Module A -> DistMem > > I need to instantiate Module A 16 times in the TOP. If I generated > 16 .xco files for DistMem, Does it mean I need to generate 16 "Module > A"s as well? > So, I have a new problem now, how to instantiate Module A in the TOP > module and tell it which .xco (or DistMem component) to be used? > BTW, I'm using VHDL. > > Thanks I would suggest using generics in your Module A to determine the version of initialized memory to use. Then each instantiation would use the same Module A with a different value for the generic.Article: 137473
reganireland@gmail.com wrote: > I am writing to a RAM at a 40MHz pixel input from a camera, but need > to access it at 25MHz for VGA output. Is it fine to disable the RAM > between storing/accessing and change the clocks and other lines over > then re-assert the enable? Is there a better way to do this? Run the ram at 40MHz and synchronize the slow process using a fifo, or handshakes: http://www.fpga4fun.com/CrossClockDomain2.html http://www.fpga4fun.com/CrossClockDomain3.htmlArticle: 137474
On Jan 18, 12:29=A0pm, "robj" <r...@abc.net> wrote: > I stumbled upon SiliconBlue a month or two ago. Had never heard of them > before. Very impressive power numbers, but the performance looks very > limited. From looking at some of their reference designs I got the > impression 15-20MHz would be about the limit for anything reasonably > complex. Can you give any info on how you're using the parts and what kin= d > of performance you're seeing? > > The static current numbers are not much different than IGLOO, but IGLOO h= as > enough horsepower to do some real processing. Just nothing close to a > Virtex-5 or Stratix-III. > > Rob Hi Rob, It doesn't look like that our design is pushing performance on the iCE65 part. The design has an E3/T3 interface that operates at either a 34.368 MHz or 44.736 MHz carrier frequency. At the carrier frequency, it's mostly state machines and counters. The input path is divided down both to save power and to provide far more timing margin. The performance/margin also improved with the December release of the "iCEcube" software. I can see that the "safe" low-effort operating frequency for the part is probably 40 MHz and below. It looks like 40 to 60 MHz takes some work. It looks like you can do pipelined or shift-register functions up to about 80ish MHz. High frequency is usually the killer for low- power so I think most low-power applicatons will operate less than this. Their 1.0V operating mode likely reduces the performance, but I haven't tried it yet. The 1.2V mode already saves us significant amounts of power. The great news is that the design operates at about 30-50 uA in low- power mode (32.768 kiloHertz). -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.com
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