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 Aug 9, 6:43=A0pm, Zhane <m...@hotmail.com> wrote: > erm > > I used the CoreGen to do it. > I set it up for 2 independent clocks. > > Ya.. my writing code is using the same clock as the clock that is fed > into the FIFO Zhane, you did not answer my question: How is the FIFO partitioned? What is each BRAM doing? 1 bit wide and 16K deep (as it should) or 9 bits wide and 2K deep (which is bad)? Peter AlfkeArticle: 134426
On Aug 10, 10:20=A0am, Peter Alfke <pe...@xilinx.com> wrote: > On Aug 9, 6:43=A0pm, Zhane <m...@hotmail.com> wrote: > > > erm > > > I used the CoreGen to do it. > > I set it up for 2 independent clocks. > > > Ya.. my writing code is using the same clock as the clock that is fed > > into the FIFO > > Zhane, > you did not answer my question: > How is the FIFO partitioned? What is each BRAM doing? > 1 bit wide and 16K deep (as it should) or 9 bits wide and 2K deep > (which is bad)? > Peter Alfke I dont know? Is it specified in the CoreGen?Article: 134427
Greetings, I'll start with my apologizes for being a complete newbie to the fpga world. I've acquired a spartan 3e starter board, and have completed some of the simpler tasks on fpga4fun.com. I am looking for some guidance on how to implement LVDS to control a LCD panel. I have the docs on the panel, it is a 1366 x 768 40" LCD from a tv. It uses 4 lvds pairs @ 80 mhz. I have the datasheet for the panel. They used a THC63LVDM83R in the tv to do the lvds connection to the panel, but I am having no luck sourcing one. So I am wondering if I can do without and if anyone has happened to have had experience doing so. Thanks for your time.Article: 134428
On 2008-08-10, News <News@News.com> wrote: > > I have the docs on the panel, it is a 1366 x 768 40" LCD from a tv. It > uses 4 lvds pairs @ 80 mhz. I have the datasheet for the panel. They > used a THC63LVDM83R in the tv to do the lvds connection to the panel, I did something similar with a 42" plasma display. The original driver was based on an embedded PC that had FPD-Link output, which is a standard similar to what you describe for getting video data over a flex cable in a laptop hinge. It used a DS90CF384 decoder because the panel takes. direct 24-bit parallel RGB. If you google your part you'll see close relatives of that named as alternates for your Thine part, so I bet your protocol is identical to FPD-Link, which has many driver options. If I remember right, 4-wire (clk + 3) is for 16-bit. The other option is to implement your own encoder in the FPGA, which will save you pins. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 134429
KJ wrote: > > It doesn't, and your example is not one where the registers are not > used either since they are all addressable therefore they must all be > implemented. If this is what the OP had in mind when he said he had > 'unused' registers then he is mistaken as well. > > KJ KJ, You miss the point. How do I tell the synthesiser to ignore registers I'm not going to use? Cheers, Syms.Article: 134430
On Sat, 9 Aug 2008 19:24:28 -0700 (PDT), Zhane <me75@hotmail.com> wrote: >On Aug 10, 10:20 am, Peter Alfke <pe...@xilinx.com> wrote: >> On Aug 9, 6:43 pm, Zhane <m...@hotmail.com> wrote: >> Zhane, >> you did not answer my question: >> How is the FIFO partitioned? What is each BRAM doing? >> 1 bit wide and 16K deep (as it should) or 9 bits wide and 2K deep >> (which is bad)? >> Peter Alfke > >I dont know? Is it specified in the CoreGen? Coregen writes a simulation model, which is a normal VHDL file. You can read that and see which simulation primitives it has used, e.g. RAMB16_something. These you can look up in the Spartan-3 Library Guide, to answer Peter's questions. That will also answer your own questions. - BrianArticle: 134431
On Aug 10, 8:44=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Sat, 9 Aug 2008 19:24:28 -0700 (PDT), Zhane <m...@hotmail.com> wrote: > >On Aug 10, 10:20=A0am, Peter Alfke <pe...@xilinx.com> wrote: > >> On Aug 9, 6:43=A0pm, Zhane <m...@hotmail.com> wrote: > >> Zhane, > >> you did not answer my question: > >> How is the FIFO partitioned? What is each BRAM doing? > >> 1 bit wide and 16K deep (as it should) or 9 bits wide and 2K deep > >> (which is bad)? > >> Peter Alfke > > >I dont know? Is it specified in the CoreGen? > > Coregen writes a simulation model, which is a normal VHDL file. > You can read that and see which simulation primitives it has used, e.g. > RAMB16_something. These you can look up in the Spartan-3 Library Guide, > to answer Peter's questions. That will also answer your own questions. > > - Brian the vhdl file is only a wrapper file. I dont see any Ram16? How should I find it? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LIBRARY ieee; USE ieee.std_logic_1164.ALL; -- synthesis translate_off Library XilinxCoreLib; -- synthesis translate_on ENTITY fifo_generator_v4_2_5bit IS port ( din: IN std_logic_VECTOR(4 downto 0); rd_clk: IN std_logic; rd_en: IN std_logic; rst: IN std_logic; wr_clk: IN std_logic; wr_en: IN std_logic; dout: OUT std_logic_VECTOR(4 downto 0); empty: OUT std_logic; full: OUT std_logic); END fifo_generator_v4_2_5bit; ARCHITECTURE fifo_generator_v4_2_5bit_a OF fifo_generator_v4_2_5bit IS -- synthesis translate_off component wrapped_fifo_generator_v4_2_5bit port ( din: IN std_logic_VECTOR(4 downto 0); rd_clk: IN std_logic; rd_en: IN std_logic; rst: IN std_logic; wr_clk: IN std_logic; wr_en: IN std_logic; dout: OUT std_logic_VECTOR(4 downto 0); empty: OUT std_logic; full: OUT std_logic); end component; -- Configuration specification for all : wrapped_fifo_generator_v4_2_5bit use entity XilinxCoreLib.fifo_generator_v4_2(behavioral) generic map( c_has_int_clk =3D> 0, c_rd_freq =3D> 1, c_wr_response_latency =3D> 1, c_has_srst =3D> 0, c_has_rd_data_count =3D> 0, c_din_width =3D> 5, c_has_wr_data_count =3D> 0, c_full_flags_rst_val =3D> 1, c_implementation_type =3D> 2, c_family =3D> "spartan3", c_use_embedded_reg =3D> 0, c_has_wr_rst =3D> 0, c_wr_freq =3D> 1, c_use_dout_rst =3D> 1, c_underflow_low =3D> 0, c_has_meminit_file =3D> 0, c_has_overflow =3D> 0, c_preload_latency =3D> 1, c_dout_width =3D> 5, c_rd_depth =3D> 65536, c_default_value =3D> "BlankString", c_mif_file_name =3D> "BlankString", c_has_underflow =3D> 0, c_has_rd_rst =3D> 0, c_has_almost_full =3D> 0, c_has_rst =3D> 1, c_data_count_width =3D> 16, c_has_wr_ack =3D> 0, c_use_ecc =3D> 0, c_wr_ack_low =3D> 0, c_common_clock =3D> 0, c_rd_pntr_width =3D> 16, c_use_fwft_data_count =3D> 0, c_has_almost_empty =3D> 0, c_rd_data_count_width =3D> 16, c_enable_rlocs =3D> 0, c_wr_pntr_width =3D> 16, c_overflow_low =3D> 0, c_prog_empty_type =3D> 0, c_optimization_mode =3D> 0, c_wr_data_count_width =3D> 16, c_preload_regs =3D> 0, c_dout_rst_val =3D> "0", c_has_data_count =3D> 0, c_prog_full_thresh_negate_val =3D> 65532, c_wr_depth =3D> 65536, c_prog_empty_thresh_negate_val =3D> 3, c_prog_empty_thresh_assert_val =3D> 2, c_has_valid =3D> 0, c_init_wr_pntr_val =3D> 0, c_prog_full_thresh_assert_val =3D> 65533, c_use_fifo16_flags =3D> 0, c_has_backup =3D> 0, c_valid_low =3D> 0, c_prim_fifo_type =3D> "8kx4", c_count_type =3D> 0, c_prog_full_type =3D> 0, c_memory_type =3D> 1); -- synthesis translate_on BEGIN -- synthesis translate_off U0 : wrapped_fifo_generator_v4_2_5bit port map ( din =3D> din, rd_clk =3D> rd_clk, rd_en =3D> rd_en, rst =3D> rst, wr_clk =3D> wr_clk, wr_en =3D> wr_en, dout =3D> dout, empty =3D> empty, full =3D> full); -- synthesis translate_on END fifo_generator_v4_2_5bit_a;Article: 134432
On Aug 9, 6:09=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > eromlignod wrote: > > It's a Spartan-3 and I picked it because of my large number of > > inputs. =A0Connecting an input from each of the 88 notes lets me avoid > > an elaborate tree of external multiplexers. =A0 > > Done right, the external fan-in design can save a lot of bulky wiring, > and keeps the looming in simple ribbon cable. > > We have done Serial/parallel chainable fan-in/fan-out systems > in designs, and it is very expandable, and simple to loom-up. > Also has natural cross talk advantages. > > You will already have 'remote PCBs' doing the front-end signal > conditioning ? > > How much you 'production enginerr' this, depends on how many of these > you hope to make. > > > I only sustain 44 of the > > strings at a time (every other note) because otherwise I get > > interference from adjacent driving magnets. > > > The system does not run all the time. =A0It only actively adjusts > > pitches for the first couple of minutes after you turn it on. =A0Once > > the strings stabilize at their in-tune pitch, all of the PWM duty > > cycles are frozen and maintained from that point on and the magnetic > > sustaining ceases. =A0When the musician is done playing, he switches it > > off. =A0The next time it is turned on, you get a new tuning for that > > day's conditions. =A0This also keeps the system simple, since there is > > only one button. > > Hmm... has this been proven on a working unit, in the field ? > > Better would be a system that can _prove_ what you stated, by > tracking the frequency even during a performance. It does not > have to adjust, but knowing just how many ppm the thing > has drifted, would seem a strong selling point > > -jg This would be difficult since no song ever plays all 88 notes. In fact the top and bottom few notes may never get played (I am a pianist myself and have never seen music written for A0 or C8). And if a note is played too quickly, like with staccato, there may not be enough clean vibrations to get an average. There is also the fact that a note's pitch changes slightly with volume. A louder note sounds a little sharp since there is more string excursion and thus more tension. My system magnetically sustains each string at a steady, repeatable volume, which is the same volume it is sustained at when the tuning is "recorded". The whole idea of the system is to get a fresh tuning in a few seconds on a daily basis. Every time you press that button, you could have spent $100 and over a hour of inconvenience. Don Kansas CityArticle: 134433
On Sun, 10 Aug 2008 13:42:55 +0100, "Symon" wrote: >KJ, >You miss the point. Betcha he didn't *really* miss the point :-) > How do I tell the synthesiser to ignore registers I'm > not going to use? even when you *do* use them, because all your writeable registers are also readable? Well, I'd be tempted to try to build a table of constants, indexed by register address, specifying various interesting details of each register. Better still, a table indexed by an enum containing register *names*, so that each named register's address can be specified separately. A register's record in the table might contain, for example: - a boolean to say whether it's implemented; - is it writeable; - which bits of it are populated. Given such a table it's probably not too hard to write a loop or maybe a generate-loop that creates the various registers the way you want them (or, in sid's case, don't want them). I have always found the whole business of register-maps a bit vexatious. Do you chuck all the registers into one big 'orrible module, so that you can specify their characteristics neatly in one place? That sounds nice, until you realise that this module now has a bazillion ports on it to carry the registers' contents to/from the rest of the design. Or do you sprinkle the registers around the design, so that you need only send the common databus to each part of the design and the physical I/O wiring is then localised to the place where you need it? That sounds nice, until you note that register addressing and configuration information is then distributed across a slew of different design files, and getting register readback organised nicely is pretty tiresome too. Given that most FPGA-sized designs only have one set of registers for the whole thing, a centralised package for the config information and distributed registers all of which access that package's (constant) data seems like a reasonable compromise. But I've never sorted out a solution that I really like and is truly general. cheers -- 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: 134434
>I've acquired a spartan 3e starter board, and have completed some of the > simpler tasks on fpga4fun.com. I am looking for some guidance on how >to implement LVDS to control a LCD panel. >I have the docs on the panel, it is a 1366 x 768 40" LCD from a tv. It >uses 4 lvds pairs @ 80 mhz. I have the datasheet for the panel. They >used a THC63LVDM83R in the tv to do the lvds connection to the panel, >but I am having no luck sourcing one. So I am wondering if I can do >without and if anyone has happened to have had experience doing so. You can proberbly use another LVTTL -> LVDS transmitter chip. Just pay attention to number of bits and lanes. The Spartan-3E is capable of transmitting LVDS on it's own. The bitrate is limited however to ~500-600 Mbps per differential pair. And the developer board needs a jumper setting to use 2.5V or such I think. There's a datasheet explicitly on using LVDS with Spartan chips from Xilinx. Bitstream format is also a bit backwards, but not a big deal. Please keep us posted on any progress ;)Article: 134435
Newman wrote: [...] > 3) Perhaps the rol in B' = (L + A' + B) rol (A'+B) could be > accomplished smoothly by block multipliers if hardware block > multipliers are available in a Cyclone II. Using a resource that may > have been unused sometimes is a good thing if it saves on other scare > ones. Good idea, unfortunately this is rotation not shift. Also, hardware multipliers are mostly 18 bit and have a delay of two clock cycles :( But I havent given up that yet, I just need to find a way to use multipliers more efficiently. > 4) I would guess that the logic associated with rol in item 3 is > large. Search the group for a barrel shifter to get some ideas. You are correct, This is where the logic blows up. The idea was two combine the rotation and addition somehow to make maximum use of the LUTs. I was also thinking of doing the first part of the rotation (rotate by 1 bit) in the first clock cycle and the rest in the second (the reason for doing the 1-bit first is because this will have the least impact on the longesth path)Article: 134436
Muzaffer Kal wrote: > On Tue, 22 Jul 2008 00:48:26 -0700 (PDT), tgau3qk4@gmail.com wrote: > > >As an intellectual exercise I have been playing with some > >cryptographic functions. Currently, I am looking at the RC5 ?key > >expander? (http://people.csail.mit.edu/rivest/Rivest-rc5.pdf): > > > >A' = (S + A + B) rol 3 > >B' = (L + A' + B) rol (A'+B) > > > >where ?rol? denotes rotate left and all variables are 32-bit. > > > > As far as I can tell you need 3 32 bit adders (C=A+B, S+C, L+C) and a > barrel shifter controlled by the bottom 5 bits of C for the second > "rol". The first rol is just moving wires around. The barrel shifter > would be large but can be implemented with a multiplier if your device > has them. You can probably calculate A in the first cycle with two > adders and in the second cycle do an add plus rol. A third cycle might > be helpful to reuse an adder. The problem is that both sides of the "rol" for computing B' depends on A', this makes pipelining very inefficient. For the record, this is my current implementation (which have lots of room for improvement): process(CLK_I) begin if rising_edge(CLK_I) then -- stage 1 tmp1 <= (S_I + A_I + B_I) rol 3; tmp2 <= L_I + B_I; tmp3 <= B_I + ((S_I + A_I + B_I) rol 3); -- stage 2 A_O <= tmp1; B_O <= (tmp1 + tmp2) rol to_integer( tmp3(4 downto 0) ); end if; end process;Article: 134437
eromlignod wrote: > On Aug 9, 6:09 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>Hmm... has this been proven on a working unit, in the field ? >> >>Better would be a system that can _prove_ what you stated, by >>tracking the frequency even during a performance. It does not >>have to adjust, but knowing just how many ppm the thing >>has drifted, would seem a strong selling point >> >>-jg > > This would be difficult since no song ever plays all 88 notes. In > fact the top and bottom few notes may never get played (I am a pianist > myself and have never seen music written for A0 or C8). And if a note > is played too quickly, like with staccato, there may not be enough > clean vibrations to get an average. > > There is also the fact that a note's pitch changes slightly with > volume. A louder note sounds a little sharp since there is more > string excursion and thus more tension. My system magnetically > sustains each string at a steady, repeatable volume, which is the same > volume it is sustained at when the tuning is "recorded". > > The whole idea of the system is to get a fresh tuning in a few seconds > on a daily basis. Every time you press that button, you could have > spent $100 and over a hour of inconvenience. Understood, but I am talking about making something that is both calibration/control system (when you push the button), and a measuring instrument (when playing). Sure, playing is dynamic, but you are not making control decisions, just checking the calibrations. Think of it as a seriously precise spectrum plot :) Is this a one-off, of do you hope to sell a number of these commercially (or seil the one-off to someone else, who will production-engineer it ?) -jgArticle: 134438
No prob...sorry I couldn't help more. If you do a fresh install, maybe just try removing those two programs, and double-checking the registry that the appropriate entries are gone...then just ISE to see if your upgraded version works right without MinGW there...I'd also be curious to see what a registry cleaner has to say about that entry...last time I cleaned my registry there was a buttload of useless entries (guess I should do it more often than every 5 years)...Article: 134439
"Symon" <symon_brewer@hotmail.com> wrote in message news:g7mnp3$v0h$1@aioe.org... > KJ wrote: >> >> It doesn't, and your example is not one where the registers are not >> used either since they are all addressable therefore they must all be >> implemented. If this is what the OP had in mind when he said he had >> 'unused' registers then he is mistaken as well. >> >> KJ > > > KJ, > You miss the point. How do I tell the synthesiser to ignore registers I'm > not going to use? You "tell the synthesizer", by not providing any mechanism for the output of the register to have any impact on any external I/O pins. That's always the way things get optimized away. In your example you had the following statement: data_to_cpu <= registers(cpu_address); Therefore, even if the CPU *will* never write to a certain set of registers, you've written code in such a way that synthesis must implement the entire set of 'registers' since the output data_to_cpu depends on all of them. By providing a meachanism for register(3) (as an example) to affect an output signal, you've forced it to implement register(3). One relatively simple way around this is the following: data_to_cpu <= registers(Masker(cpu_address)); where 'Masker' is some function that maps the entire input address space down to the allowable set of addresses. As a simple exercise, if 'Masker' always returned 0 then the synthesis tool will get rid of registers 1 on up, leaving only register(0). It will work as well for any other arbitrary 'Masker' function. As a side note, if 'register(3)' was not needed, one might be tempted to have a statement like register(3) <= (others <= '0') or some such. While the synthesis tool will use such a statement and produce less logic it is still implementing register(3), register(3) just happens to always return a 0. When all is said and done, doing it this way by having a set of 'zero registers' may produce less logic;it would depend on just how complicated the 'Masker' function gets. KJArticle: 134440
Newbie here. I'm trying to learn fpga (xilinx with verilog). So get ready for weeks of silly questions coming your way as i try to figure this thing out. Question : I remember that Xilinx Webpack had examples of Verilog code neatly arranged in a list. Code to do a shift and so on - stuff you could just cut and paste into your code and just change the name of the variables. I download Xilinx Webpack now and I cannot find it. Where is it? I looked under the Help menu but am unable to locate it.Article: 134441
On Aug 11, 1:20=A0am, vorange <orange...@yahoo.com> wrote: > Newbie here. =A0I'm trying to learn fpga (xilinx with verilog). =A0So get > ready for weeks of silly questions coming your way as i try to figure > this thing out. > > Question : > > I remember that Xilinx Webpack had examples of Verilog code neatly > arranged in a list. =A0Code to do a shift and so on - stuff you could > just cut and paste into your code and just change the name of the > variables. > > I download Xilinx Webpack now and I cannot find it. =A0Where is it? Wait! I think I found it. Click on the "lightbulb icon" :-) Its called Language Templates. Choose from the expanding menus. Alright, we're off to a good start.Article: 134442
On 11 =D7=90=D7=95=D7=92=D7=95=D7=A1=D7=98, 03:23, vorange <orange...@yahoo= .com> wrote: > On Aug 11, 1:20=C2=A0am, vorange <orange...@yahoo.com> wrote: > > > Newbie here. =C2=A0I'm trying to learn fpga (xilinx with verilog). =C2= =A0So get > > ready for weeks of silly questions coming your way as i try to figure > > this thing out. > > > Question : > > > I remember that Xilinx Webpack had examples of Verilog code neatly > > arranged in a list. =C2=A0Code to do a shift and so on - stuff you coul= d > > just cut and paste into your code and just change the name of the > > variables. > > > I download Xilinx Webpack now and I cannot find it. =C2=A0Where is it? > > Wait! =C2=A0I think I found it. > > Click on the "lightbulb icon" :-) > > Its called Language Templates. =C2=A0 Choose from the expanding menus. > > Alright, we're off to a good start. There are many examples for using xilinx tools and verilog at: http://bknpk.no-ip.biz http://bknpk.no-ip.biz/LEON/AHB_APB_leon/AHB_APB_verilog.html As well as free usb and sdio code. http://bknpk.no-ip.biz/usb_invitation_for_final_pj.html http://bknpk.no-ip.biz/SDIO/doc_1.htmlArticle: 134443
Hi All, I have a project that requires a small PLD and have honed in on the Altera series. Can someone explain the difference between the EPM7064x and the EPM3064x series please. Each shares: same number of CLBs, Icc and Fmax, JTAG. The 7k seems newer, but also about twice the price of the 3k (Digikey). Comments appreciated. Thanks, MarkArticle: 134444
can I read from the FIFO and write into it at the same time? when my 2 clocks are independentArticle: 134445
MarkAren wrote: > Hi All, > > I have a project that requires a small PLD and have honed in on the > Altera series. > > Can someone explain the difference between the EPM7064x and the > EPM3064x series please. > > Each shares: same number of CLBs, Icc and Fmax, JTAG. > > The 7k seems newer, but also about twice the price of the 3k > (Digikey). This was a strange exersise in marketing. IIRC The 3000 series was a lower cost target, but just very slightly crippled from the 7000 series. (ie not quite pin compatible. WHY do that?!) I think the 3000 series offers less IO on given device. I see the 7000 series has lost link-preference on the Altera website. These days, Altera's CPLDs are somewhat trailing edge, with Lattice 4000ZE being the newest technology (most recently released), followed by Atmel's ATF15xxBE, and then Xilinx XC2Cxx series. Speaking of Altera and CPLD's - whatever became of the touted Altera MAX III CPLDs ? Google finds a 2004 Altera road map that says : MAX III CPLDs - Intent: Solve Additional Board Management Issues - Adjust Density, Power & Cost According to Market Requirements Seems the plug was pulled on this ? -jgArticle: 134446
On Aug 11, 8:52=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > MarkAren wrote: > > Hi All, > > > I have a project that requires a small PLD and have honed in on the > > Altera series. > > > Can someone explain the difference between the EPM7064x and the > > EPM3064x series please. > > > Each shares: same number of CLBs, Icc and Fmax, JTAG. > > > The 7k seems newer, but also about twice the price of the 3k > > (Digikey). > > This was a strange exersise in marketing. IIRC > > The 3000 series was a lower cost target, but just very slightly crippled > from the 7000 series. (ie not quite pin compatible. WHY do that?!) > > I think the 3000 series offers less IO on given device. > > I see the 7000 series has lost link-preference on the Altera website. > > These days, Altera's CPLDs are somewhat trailing edge, with Lattice > 4000ZE being the newest technology (most recently released), followed by > Atmel's ATF15xxBE, and then Xilinx XC2Cxx series. > > Speaking of Altera and CPLD's - whatever became of the touted > Altera MAX III CPLDs ? > > Google finds a 2004 Altera road map that says : > MAX III CPLDs > - Intent: Solve Additional Board Management Issues > - Adjust Density, Power & Cost According to Market Requirements > > Seems the plug was pulled on this ? > > -jg Hi Jim, Thanks. Glad I am not going crazy. I am looking at a possible NIOS II project on one of their much larger parts. Main interest there is steepness and altitude of learning curve... Does look quite interesting though. I see you are also in NZ. -markArticle: 134447
On Jul 31, 5:52=A0am, chrisde...@gmail.com wrote: > Hi, > =A0 Does anybody have any experience in using the mex file provided by > xilinx core-generator for xfft_v5 to model the characteristics of the > bit-accurate FFT FPGA core in matlab? > =A0 =A0I put the mex file in the same directory as where i am running > matlab. and follow the instructions closely on how to call the mex > function > > this is the error i get. > > ?? invalid mex file C:\xfft_v5_0_bitacc_cmodel_mex.mexw32. the > specified module could not be found > > Error in use_mex 11 > [output, blkexpm, overflow] =3D xfft_v5_0_bitacc_mex(generics, 10, > input, scaling_sch,1 ); > > I have merely copied the matlab contents from page 19 of the pdf user > guide. It can be downloaded from here.http://www.xilinx.com/products/ipce= nter/FFT.htm > > I am using the same matlab 7.3 version as described and have put the > mex file in the directory which i am running the command. > > Chris First thing...you are in a wrong place.. To answer your question, when you are mexing you need to provide all the SUPPORTED .c files as arguments where the function definitions and function declarations are present. -dKArticle: 134448
> MarkAren wrote:
>> The 7k seems newer, but also about twice the price of the 3k
>> (Digikey).
The 7k is older.
I would use the 3k for new designs.
> Jim Granville wrote:
> This was a strange exercise in marketing. IIRC
> The 3000 series was a lower cost target, but just very slightly crippled
> from the 7000 series. (ie not quite pin compatible. WHY do that?!)
Maybe to maintain the margins on designs in production
while still winning some new designs.
> Speaking of Altera and CPLD's - whatever became of the touted
> Altera MAX III CPLDs ?
Maybe the ROI was better on big parts.
-- Mike Treseler
Article: 134449On Aug 11, 1:38=A0am, Zhane <m...@hotmail.com> wrote: > can I read from the FIFO and write into it at the same time? when my 2 > clocks are independent Of course you can read and write simultaneously. That's what a FIFO is there for. Have you ever read any FIFO description? Peter Alfke
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