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 Hans, also see my other post. > Can't you co-simulate? that is, put a SystemC/FLI/VHPI wrapper around your > C code and load that into your simulator? Alternatively, use shared > memory/files/sockets to communicate between your C code and your > simulator. I need floating point operators which produce the same result as the Xilinx FP Cores (bit-accurate, not cycle accurate). Shared memory/files/sockets sound like a lot of work. > If you do translate, how are you planning to validate your translated > model? Remember you are converting from a concurrent to a sequential > language which might not be that easy..., I think the Xilinx Cores don't include feedback paths, only a forward pipeline. This should not be so difficult to translate. Validation could be done by applying the same stimuli to a HDL and the C Simulation and comparing the outputs. Thanks, SimonArticle: 104426
Hi Gilles, try to set the env variable export LD_ASSUME_KERNEL=2.4.1 (when using bash) and then run Synplify. Perhaps that helps? Best, Simon "Gilles GEORGES" <georges@irisa.fr> wrote in message news:e7r0lp$23a$1@amma.irisa.fr... > Dear all, > > I'm trying to install a FPGA development platform under a Linux Fedora > Core 5. > The only tool not working is Synplify. I have tried two different versions > (7.3.3 and 8.5.1) but got same problem. > > when trying to launch synplify_pro i got this : > --------------------------------------------- > [georges@remix0 share]$ /local/share/fpga_85/bin/synplify_pro > > *************************************************************** > > Warning: You are running on an unsupported platform > 'synplify_pro' only supports Redhat Enterprise Linux 3,4, SuSE > Enterprise Linux Server 9 > > current platform: Fedora Core release 5 (Bordeaux) > Kernel \r on an \m > > *************************************************************** > > /local/share/fpga_85/linux/mbin/synplify: relocation error: > /local/share/fpga_85/linux/mfw/lib-linux_optimized/libkernel32.so: symbol > errno, version GLIBC_2.0 not defined in file libc.so.6 with link time > reference > [georges@remix0 share]$ > ------------------------------------------- > > The FC5 seems not to be supported, does anyone experience to make it run > under FC5 ? > I plan to try why a FC4, any expérience ? > > Thanks in advance > > GillesArticle: 104427
Hi, I am using the platform studio first time.I like to know how i can add my testbenches and remove the microblaze processor from the setup. I am trying to generate the controller for my V4MB lx60 board and i want to test the ddr in the board.From the tool(platform studio) i can select the pheripherals and the processor etc but didnt have any idea how can i use this to test my ddr.I tried to generate the hdl code.But all the controllers are ipcores(black box) and i wont be able to synthesize it using xilinx ise(library for these ipcores are missing). regards subinArticle: 104428
Hi there, I'm experiencing some problems with a 64 MB Compact Flash and xilfatfs on the XUP board: since I wasn't able to open in write mode more than one file each time, I tried to reformat the Compact Flash. I reformatted it with mkdosfs in FAT16 and it works perfectly for reprogramming the FPGA, but now I can't open any file in write mode (although everything seems correct in the software platform settings: write support is enabled). Does anybody has any idea why it doesn't work? Any possible solution? Thank you very much!!! The Mighty ShamanArticle: 104429
Hello all, Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in the design??? The design works perfectly OK in WebPACK version 7.1i04, so I would assume that something drastic as this should not happen. The VHDL code also works on Altera FPGAs. I am using Spartan3 here. I must be doing something obviously wrong, but what? Anyone can shed a light on it? It would be much appreciated. , The design is the 8051-microcontroller, version 1.4, with patches from http://www.oregano.at/ip/8051.htm Initially all RAM's are synthesized as in the 7.1i version, but are later largely removed. The VHDL code of one of the RAMs can be found below. The directory with the complete design can be found at http://www.cs.rug.nl/~sietse/8051 But here are the relevant (i think) parts of the log: FROM THE SYNTHESIS REPORT: ========================= Synthesizing Unit <mc8051_ramx>. Related source file is "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl". WARNING:Xst:647 - Input <reset> is never used. WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used. Found 8192x8-bit single-port block RAM for signal <extram>. ----------------------------------------------------------------------- | mode | read-first | | | aspect ratio | 8192-word x 8-bit | | | clock | connected to signal <clk> | rise | | write enable | connected to signal <ram_wr_i> | high | | address | connected to signal <int_ram_adr> | | | data in | connected to signal <ram_data_i> | | | data out | connected to signal <ram_data_o> | | | ram_style | Auto | | ----------------------------------------------------------------------- Summary: inferred 1 RAM(s). Unit <mc8051_ramx> synthesized. AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER: ============================================== Macro Statistics # Block RAMs : 3 128x8-bit single-port block RAM : 1 16384x8-bit single-port block RAM : 1 8192x8-bit single-port block RAM : 1 SO THE RAMs are synthesized initially! ====================================== THEN A NUMBER (7) OF STRANGE INFOs: =================================== INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are equivalent, second RAM is removed DON'T KNOW WHAT THIS MEANS. AND THE FINAL (synthesizer) REPORT NOTES: =========================== # RAMS : 2 # RAMB16_S1 : 1 # RAMB16_S9 : 1 SO MOST RAMs ARE GONE!!! ======================= ======================= What is going wrong here? Anyone an idea? I also installed the WebPack on two different machines. Regards, Sietse Achterop Computing Science department University of Groningen PS. I want to use this design in a number of courses that I am giving here. =============================================================== The VHDL RAM descriptions are like: library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_arith.all; entity mc8051_ramx is port (clk : in std_logic; -- clock signal reset : in std_logic; -- reset signal ram_data_i : in std_logic_vector(7 downto 0); -- data input ram_data_o : out std_logic_vector(7 downto 0); -- data output ram_adr_i : in std_logic_vector(15 downto 0); -- adresses ram_wr_i : in std_logic); -- read=0, write=1 end mc8051_ramx; architecture behav of mc8051_ramx is type ram_type is array (8191 downto 0) of std_logic_vector(7 downto 0); signal extram: ram_type; signal int_ram_adr : std_logic_vector(12 downto 0); begin int_ram_adr <= ram_adr_i(12 downto 0); p_read : process (clk) begin if rising_edge(clk) then ram_data_o <= extram(conv_integer(unsigned(int_ram_adr))); end if; end process p_read; p_write : process (clk) begin if rising_edge(clk) then if (ram_wr_i='1') then extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i; end if; end if; end process p_write; end behav;Article: 104430
Implement a UART on your 10KE. I assume that when you're able to build CDMA, then a UART will be a piece of cake. Regards, Luc On 27 Jun 2006 03:27:41 -0700, "lenile84" <EzzEldine@gmail.com> wrote: > i need a VHDL code for interface between a pc and FPGA kit (flex10ke) >to exchange data. >this programme i will use to make a demo for our project which is >implementing CDMA is95 on the that kit by sending users from serial >port on pc to kit and receive it again to another pc . >the two pc act as BAse station and mobile set. thanks in advance. >e-mail ezzeldine@gmail.comArticle: 104431
user@domain.invalid wrote: > something I don't know whats wrong here, but my email is: sietse@cs.rug.nl Regards, Sietse AchteropArticle: 104432
Hi Simon, I already tried this but the use of LD_ASSUME_KERNEL is not supported with Fedora Core 5. Nothing working when setting this variable, so not the issue for this problem. Thanks Gilles Simon Heinzle a écrit : > Hi Gilles, > > try to set the env variable > > export LD_ASSUME_KERNEL=2.4.1 > > (when using bash) and then run Synplify. Perhaps that helps? > > Best, > Simon > > "Gilles GEORGES" <georges@irisa.fr> wrote in message > news:e7r0lp$23a$1@amma.irisa.fr... > >>Dear all, >> >>I'm trying to install a FPGA development platform under a Linux Fedora >>Core 5. >>The only tool not working is Synplify. I have tried two different versions >>(7.3.3 and 8.5.1) but got same problem. >> >>when trying to launch synplify_pro i got this : >>--------------------------------------------- >>[georges@remix0 share]$ /local/share/fpga_85/bin/synplify_pro >> >>*************************************************************** >> >>Warning: You are running on an unsupported platform >> 'synplify_pro' only supports Redhat Enterprise Linux 3,4, SuSE >>Enterprise Linux Server 9 >> >> current platform: Fedora Core release 5 (Bordeaux) >>Kernel \r on an \m >> >>*************************************************************** >> >>/local/share/fpga_85/linux/mbin/synplify: relocation error: >>/local/share/fpga_85/linux/mfw/lib-linux_optimized/libkernel32.so: symbol >>errno, version GLIBC_2.0 not defined in file libc.so.6 with link time >>reference >>[georges@remix0 share]$ >>------------------------------------------- >> >>The FC5 seems not to be supported, does anyone experience to make it run >>under FC5 ? >>I plan to try why a FC4, any expérience ? >> >>Thanks in advance >> >>Gilles > > >Article: 104433
"sjulhes" <t@aol.fr> wrote in message news:449fff97$0$31655$636a55ce@news.free.fr... > Thanks for the answers but as I don't know anything in verilog (!) could someone give me a little > example of how to declare a verilog component in a vhdl file and how to instanciate it in the vhdl > file. > Thank you. > Stéphane. As Duane shows below(/above), a single wire maps to std_logic and a vector to a std_logic_vector of the correct width. Nial.Article: 104434
Thank you for your help, I did manage to make my VHDL bench compile with the verilog model. Stéphane. "Duane Clark" <junkmail@junkmail.com> a écrit dans le message de news: SYTng.73160$4L1.13281@newssvr11.news.prodigy.com... > sjulhes wrote: >> Thanks for the answers but as I don't know anything in verilog (!) could >> someone give me a little example of how to declare a verilog component in >> a vhdl file and how to instanciate it in the vhdl file. > > There is no special syntax for Verilog models. For instance, I use the > Micron models for the mt16vddf12864. It starts out with: > > module mt16vddf12864 (Dq, Dqs, Addr, Ba, Clk, Clk_n, Cke, Cs_n, Ras_n, > Cas_n, We_n, Dm); > inout [0 : 63] Dq; > inout [0 : 7] Dqs; > input [0 : 12] Addr; > input [0 : 1] Ba; > input [0 : 2] Clk; > input [0 : 2] Clk_n; > input [0 : 1] Cke; > input [0 : 1] Cs_n; > input Ras_n; > input Cas_n; > input We_n; > input [0 : 7] Dm; > > > And it is compiled into the work directory with: > vlog mt16vddf12864.v > > > My testbench contains: > > -- MICRON DDR SDRAM Simulation Model > DIMM : entity mem.MT16VDDF12864 > port map ( > Dq => DDR_DQ, > Dqs => DDR_DQS, > -- Addr => DDR_Addr(C_DDR_AWIDTH-11 to 12), > Addr => DDR_Addr(0 to 12), > Ba => DDR_BankAddr, > Clk(0) => DDR_Clk_0, > Clk(1) => DDR_Clk_1, > Clk(2) => DDR_Clk_0, > Clk_n(0) => DDR_Clkn_0, > Clk_n(1) => DDR_Clkn_1, > Clk_n(2) => DDR_Clkn_0, > Cke => DDR_CKE, > Cs_n => DDR_CSn, > Ras_n => DDR_RASn, > Cas_n => DDR_CASn, > We_n => DDR_WEn, > Dm => DDR_DM > ); > > Where my project.mpf file contains: > [Library] > mem = $MODELS/mem/work > > Which is where I compiled the Micron models.Article: 104435
When using the dcm clkin_divide_by_2 attribute on a V2P DCM, if the clk0 output is fed into the clkfb input, will clk0 be in phase with clkin? MattArticle: 104436
I have a monta vista linux preview kit 3.1 runnig on a ml403 GSRD based design. Now i have the problem to get the linux runnig out of the compact flash card from Systemace on ML403. Who has as solution for thatArticle: 104437
Simon Heinzle (sheinzle@inf.ethz.ch) wrote: : Hi John and cds, : We have an arithmetic C model with standard IEEE single precision floats. : However, in our FPGA implementation we use several different (custom) : floating point formats, mainly due to the limited resources. : The C model is used to generate stimuli vectors for the HDL simulation. : Surely we play tricks to quantize the intermediate results of the single : precision operations, but the results often differ (in a few bits) from the : HDL simulation, which is quite annoying (and not practical for automated : testing). : In short: I'm just looking for a bit-accurate (non cycle-accurate) model of : the Floating Point Operators from Xilinx. I'll second that request in light of Ben Jones' posting. Simon, I don't know if you are aware of GHDL? It's a VHDL front end for GCC which spits out object files, so you may be able to compile the Xilinx Behavioural model into a form you can link C code against... What sort of performance would you be happy with compared to machine native floats? Cheers, ChrisArticle: 104438
you have a 8K memory but it seems from the log file that you are not using the all the address bits, WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used. which means that you basically need only 1K from the total of 8K and XST remove the rest, I think this make sense if you keep these addresses tied to a constant. Aurash user@domain.invalid wrote: > Hello all, > > Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in > the design??? > The design works perfectly OK in WebPACK version 7.1i04, so I would > assume that something > drastic as this should not happen. > The VHDL code also works on Altera FPGAs. > I am using Spartan3 here. > > I must be doing something obviously wrong, but what? > Anyone can shed a light on it? It would be much appreciated. > > , > The design is the 8051-microcontroller, version 1.4, with patches from > http://www.oregano.at/ip/8051.htm > > Initially all RAM's are synthesized as in the 7.1i version, but are > later largely removed. > The VHDL code of one of the RAMs can be found below. > The directory with the complete design can be found at > http://www.cs.rug.nl/~sietse/8051 > > But here are the relevant (i think) parts of the log: > > FROM THE SYNTHESIS REPORT: > ========================= > > Synthesizing Unit <mc8051_ramx>. > Related source file is > "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl". > WARNING:Xst:647 - Input <reset> is never used. > WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used. > Found 8192x8-bit single-port block RAM for signal <extram>. > > ----------------------------------------------------------------------- > | mode | read-first > | | > | aspect ratio | 8192-word x 8-bit > | | > | clock | connected to signal <clk> | > rise | > | write enable | connected to signal <ram_wr_i> | > high | > | address | connected to signal <int_ram_adr> > | | > | data in | connected to signal <ram_data_i> > | | > | data out | connected to signal <ram_data_o> > | | > | ram_style | Auto > | | > > ----------------------------------------------------------------------- > Summary: > inferred 1 RAM(s). > Unit <mc8051_ramx> synthesized. > > AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER: > ============================================== > > Macro Statistics > # Block RAMs : 3 > 128x8-bit single-port block RAM : 1 > 16384x8-bit single-port block RAM : 1 > 8192x8-bit single-port block RAM : 1 > > SO THE RAMs are synthesized initially! > ====================================== > THEN A NUMBER (7) OF STRANGE INFOs: > =================================== > > INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are > equivalent, second RAM is removed > > DON'T KNOW WHAT THIS MEANS. > AND THE FINAL (synthesizer) REPORT NOTES: > =========================== > # RAMS : 2 > # RAMB16_S1 : 1 > # RAMB16_S9 : 1 > > SO MOST RAMs ARE GONE!!! > ======================= > ======================= > > What is going wrong here? Anyone an idea? > > I also installed the WebPack on two different machines. > > Regards, > Sietse Achterop > Computing Science department > University of Groningen > > PS. I want to use this design in a number of courses that I am giving > here. > > > =============================================================== > The VHDL RAM descriptions are like: > > library IEEE; > use IEEE.std_logic_1164.all; > use IEEE.std_logic_arith.all; > > entity mc8051_ramx is > > port (clk : in std_logic; -- clock signal > reset : in std_logic; -- reset signal > ram_data_i : in std_logic_vector(7 downto 0); -- data input > ram_data_o : out std_logic_vector(7 downto 0); -- data output > ram_adr_i : in std_logic_vector(15 downto 0); -- adresses > ram_wr_i : in std_logic); -- read=0, write=1 > > end mc8051_ramx; > > > architecture behav of mc8051_ramx is > > type ram_type is array (8191 downto 0) of std_logic_vector(7 > downto 0); > > signal extram: ram_type; > signal int_ram_adr : std_logic_vector(12 downto 0); > > begin > int_ram_adr <= ram_adr_i(12 downto 0); > > p_read : process (clk) > begin > if rising_edge(clk) then > ram_data_o <= extram(conv_integer(unsigned(int_ram_adr))); > end if; > end process p_read; > > p_write : process (clk) > begin > if rising_edge(clk) then > if (ram_wr_i='1') then > extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i; > end if; > end if; > end process p_write; > > end behav; -- __ / /\/\ Aurelian Lazarut \ \ / System Verification Engineer / / \ Xilinx Ireland \_\/\/ phone: 353 01 4032639 fax: 353 01 4640324Article: 104439
to be more precise you have: int_ram_adr <= ram_adr_i(12 downto 0); what about ram_adr_i(15 downto 13) who's driving them ? Aurash Aurelian Lazarut wrote: > you have a 8K memory but it seems from the log file that you are not > using the all the address bits, > WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used. > which means that you basically need only 1K from the total of 8K and > XST remove the rest, I think this make sense if you keep these > addresses tied to a constant. > Aurash > user@domain.invalid wrote: > >> Hello all, >> >> Using WebPACK version 8.1i03 initially synthesized RAM vanishes later in >> the design??? >> The design works perfectly OK in WebPACK version 7.1i04, so I would >> assume that something >> drastic as this should not happen. >> The VHDL code also works on Altera FPGAs. >> I am using Spartan3 here. >> >> I must be doing something obviously wrong, but what? >> Anyone can shed a light on it? It would be much appreciated. >> >> , >> The design is the 8051-microcontroller, version 1.4, with patches from >> http://www.oregano.at/ip/8051.htm >> >> Initially all RAM's are synthesized as in the 7.1i version, but are >> later largely removed. >> The VHDL code of one of the RAMs can be found below. >> The directory with the complete design can be found at >> http://www.cs.rug.nl/~sietse/8051 >> >> But here are the relevant (i think) parts of the log: >> >> FROM THE SYNTHESIS REPORT: >> ========================= >> >> Synthesizing Unit <mc8051_ramx>. >> Related source file is >> "/net/users/sietse/FPGA/versie-8.1i/8051/geheugen.vhdl". >> WARNING:Xst:647 - Input <reset> is never used. >> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used. >> Found 8192x8-bit single-port block RAM for signal <extram>. >> >> ----------------------------------------------------------------------- >> | mode | read-first >> | | >> | aspect ratio | 8192-word x 8-bit >> | | >> | clock | connected to signal <clk> | >> rise | >> | write enable | connected to signal <ram_wr_i> | >> high | >> | address | connected to signal <int_ram_adr> >> | | >> | data in | connected to signal <ram_data_i> >> | | >> | data out | connected to signal <ram_data_o> >> | | >> | ram_style | Auto >> | | >> >> ----------------------------------------------------------------------- >> Summary: >> inferred 1 RAM(s). >> Unit <mc8051_ramx> synthesized. >> >> AND SIMILAR FOR THE OTHER RAMs. AND THEN LATER: >> ============================================== >> >> Macro Statistics >> # Block RAMs : 3 >> 128x8-bit single-port block RAM : 1 >> 16384x8-bit single-port block RAM : 1 >> 8192x8-bit single-port block RAM : 1 >> >> SO THE RAMs are synthesized initially! >> ====================================== >> THEN A NUMBER (7) OF STRANGE INFOs: >> =================================== >> >> INFO:Xst:2399 - RAMs <inst_Mram_mem51>, <inst_Mram_mem41> are >> equivalent, second RAM is removed >> >> DON'T KNOW WHAT THIS MEANS. >> AND THE FINAL (synthesizer) REPORT NOTES: >> =========================== >> # RAMS : 2 >> # RAMB16_S1 : 1 >> # RAMB16_S9 : 1 >> >> SO MOST RAMs ARE GONE!!! >> ======================= >> ======================= >> >> What is going wrong here? Anyone an idea? >> >> I also installed the WebPack on two different machines. >> >> Regards, >> Sietse Achterop >> Computing Science department >> University of Groningen >> >> PS. I want to use this design in a number of courses that I am giving >> here. >> >> >> =============================================================== >> The VHDL RAM descriptions are like: >> >> library IEEE; >> use IEEE.std_logic_1164.all; >> use IEEE.std_logic_arith.all; >> >> entity mc8051_ramx is >> >> port (clk : in std_logic; -- clock signal >> reset : in std_logic; -- reset signal >> ram_data_i : in std_logic_vector(7 downto 0); -- data input >> ram_data_o : out std_logic_vector(7 downto 0); -- data output >> ram_adr_i : in std_logic_vector(15 downto 0); -- adresses >> ram_wr_i : in std_logic); -- read=0, write=1 >> >> end mc8051_ramx; >> >> >> architecture behav of mc8051_ramx is >> >> type ram_type is array (8191 downto 0) of std_logic_vector(7 >> downto 0); >> >> signal extram: ram_type; >> signal int_ram_adr : std_logic_vector(12 downto 0); >> >> begin >> int_ram_adr <= ram_adr_i(12 downto 0); >> >> p_read : process (clk) >> begin >> if rising_edge(clk) then >> ram_data_o <= extram(conv_integer(unsigned(int_ram_adr))); >> end if; >> end process p_read; >> >> p_write : process (clk) >> begin >> if rising_edge(clk) then >> if (ram_wr_i='1') then >> extram(conv_integer(unsigned(int_ram_adr))) <= ram_data_i; >> end if; >> end if; >> end process p_write; >> >> end behav; > > > > -- __ / /\/\ Aurelian Lazarut \ \ / System Verification Engineer / / \ Xilinx Ireland \_\/\/ phone: 353 01 4032639 fax: 353 01 4640324Article: 104440
Matt, Every other cycle of the input clock (it gets divided by two). Austin Matt Blanton wrote: > When using the dcm clkin_divide_by_2 attribute on a V2P DCM, if the clk0 > output is fed into the clkfb input, will clk0 be in phase with clkin? > > MattArticle: 104441
Gilles GEORGES wrote: > Dear all, > > I'm trying to install a FPGA development platform under a Linux Fedora > Core 5. > The only tool not working is Synplify. I have tried two different > versions (7.3.3 and 8.5.1) but got same problem. > Did you try installing the compatibility libraries? The is, compat-libgcc-296 and compat-libstdc++-296.Article: 104442
Duane Clark a écrit : > Gilles GEORGES wrote: > >> Dear all, >> >> I'm trying to install a FPGA development platform under a Linux Fedora >> Core 5. >> The only tool not working is Synplify. I have tried two different >> versions (7.3.3 and 8.5.1) but got same problem. >> > > Did you try installing the compatibility libraries? The is, > compat-libgcc-296 and compat-libstdc++-296. No i didn't. I successfully made synplify running under FC4 a few minutes ago. But thanks for the compatibility library. I will try this way later. GillesArticle: 104443
Hi Chris, > I'll second that request in light of Ben Jones' posting. Dito, I really hope Xilinx will develop the C models. > Simon, I don't know if you are aware of GHDL? It's a VHDL front end for > GCC which spits out object files, so you may be able to compile the Xilinx > Behavioural model into a form you can link C code against... Thanks! I'll definitely have a look at that one. > What sort of performance would you be happy with compared to machine > native floats? Hmm, doesn't need to be very fast, but it should be faster than the HDL simulation. Compared to native floats, I think there will be a huge performance drop (~10 to 100 times slower) when doing it bit-accurate. Best, SimonArticle: 104444
The Mighty Shaman wrote: > Hi there, I'm experiencing some problems with a 64 MB Compact Flash and xilfatfs on the XUP board: since I wasn't able to open in write mode more than one file each time, I tried to reformat the Compact Flash. I reformatted it with mkdosfs in FAT16 and it works perfectly for reprogramming the FPGA, but now I can't open any file in write mode (although everything seems correct in the software platform settings: write support is enabled). Does anybody has any idea why it doesn't work? Any possible solution? > > Thank you very much!!! > > The Mighty Shaman I suffered greatly with this same problem. It all comes down to the format parameters. The best way is to get a copy windows 2000 and tell it to format in FAT16 at a command prompt with format.com -EliArticle: 104445
On 26 Jun 2006 20:18:42 -0700, "Peter Alfke" <alfke@sbcglobal.net> wrote: >Isn't Marketing wonderful... >Here we are discussing which physical implementation is more secure, >and dear Dave tells us that Altera was indeed smart enough to implement >the algorithm correctly. I would never have stooped so low to doubt >that. Yes, Altera can do logic design. Bravo! Advance to second grade! > >The question, however, was totally different: whether the key is >secure. And that is nowhere mentioned in that long URL. >Marketing 101: >If you have nothing good to say, throw in a big bunch of irrelevant >data. >That might defuse the argument. and calm down the waves... > >Peter Alfke, who had expected a more relevant post from Altera. >Don't treat us like dummies. Hi Peter, Isn't FUD wonderful... At least they are not claiming anything which they haven't really accomplished unlike the statements here: "If I can get the IP that is a secret for less than $5,000, then I can clone the devices without paying anything at all." "*Disclaimer: non-volatile poly-efuse EM technology can be read out by a microscope using polarized light for a total investment of less than $5,000 " and then changing the numbers when confronted if actually done: "No, I have not cracked the Altera chip." "My quote of $5,000 is what we pay to have a device ground down on the backside such that we can do analysis on a device. For another $5,000, one can get up to three or four FIB cuts, and a couple of jumper wires. " Now we are up to $10K. Then claiming: "The question is not one of can I crack it (I believe I can), but one of a ASSP vendor deciding to place their IP in a component that is not in compliance with FIPS 140-2. Very, very simple." I think it's put up or shut-up time, don't you think ? If you guys are so sure, why don't you crack it / get it cracked and tell us how much it costs instead of spreading FUD ?Article: 104446
Hi "lecroy" I checked with the designer of that board. It seems that we did not explain the purpose of that cheap little LCD display. It is not there for debugging the meory interfaces. It is mainly for displaying some cute lines at shows and conferences. That's why we do no longer support any interfaces to it. Use CipScope for serious memory interface debugging. Here is what I learned from the designer: " Hi Peter, The LCD panel is merely a display demo and never calls out errors in the memory interfaces. In later releases we removed this code to avoid confusion. It would help to know exactly what this customer wants. If they just want an error reporting mechanism then they should use the latest chipscope demo files. However, if they want LCD display with error reporting functionality then we do not have any code for that and they will have to develop it themselves. The link to the latest chipscope demo files is below. Please ask your FAE to download it and send it to you since you might not have access to this page. The latest rtl code for memory interfaces must be downloaded from the MIG (Memory Interface Generator) tool. http://www.partner.xilinx.com/common/hiend/boards/docs/ml461/ML461_Toolkit_050401.zip End of quote. I hope this eliminates your frustration, or at least redirects it in the proper direction Peter Alfke, Xilinx Applications lecroy7200@chek.com wrote: > We purchased an ML461 board in Aug of 05 for $6000 from Avnet. If I > follow the documention that came with the board, it has a memory test > screen that led me to believe that the board is running some sort of > memory test and reporting errors on the LCD. If I look at the source > files the came with the board, they do not appear to be what was used > to create the actual images being loaded into the board. So, for > example, FPGA 4 controls all of the LCD functions, however looking at > the actual code that was supplied for FPGA 4, there is no support for > the LCD. The actual code for FPGA 4, for example will not even compile > without errors. What is more strange is that if I look in FPGA 3 > which contains the QDR controller, there appears to be only one signal > that reports the errors back to FPGA 4 and it is not routed to it. So, > there appears to be no way for FPGA to actually detect an error. For > fun, if I load FPGA 3 with the binary for FPGA 2, FPGA 4 reports no > memory errors on the LCD. Not that this proves that the design was > faulted, but it does raise my suspicions. I also found some other pins > defined in the source files that do not match the schematics that were > supplied. > > I had opened a case, spoke with two different FAEs and even tried to > get our money back from Avnet. Avnet claims Xilinx will support the > board and the last message from them provided me an inside contact at > Xilinx who was supposed to know this board and be able to help. When I > called him a few weeks ago he explained he was in marketing, not > engineering and suggested that I open a case number with Xilinx, which > I have, yet again. I have now came full circle with this board. > > Does anyone here have all of the code that was used to create the > images for this board?Article: 104447
Aurelian Lazarut wrote: > to be more precise you have: > int_ram_adr <= ram_adr_i(12 downto 0); > > what about ram_adr_i(15 downto 13) who's driving them ? > > Aurash > > Aurelian Lazarut wrote: > >> you have a 8K memory but it seems from the log file that you are not >> using the all the address bits, >> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used. >> which means that you basically need only 1K from the total of 8K and >> XST remove the rest, I think this make sense if you keep these >> addresses tied to a constant. >> Aurash Hello Aurash, thanks for the prompt reply. (the 8KB memory serves as the external RAM of the 8051) But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16 address bits and only 13 bits for the lower 8 KB are used. Or better, the 8KB is repeated 8 times in the 64KB address space. So all 13 address lines for the RAM are used, and I don't see why it is optimized away. SietseArticle: 104448
On Tue, 27 Jun 2006 20:17:29 +0200, Sietse Achterop <sietse@cs.rug.nl> wrote: >Aurelian Lazarut wrote: >> to be more precise you have: >> int_ram_adr <= ram_adr_i(12 downto 0); >> >> what about ram_adr_i(15 downto 13) who's driving them ? >> >> Aurash >> >> Aurelian Lazarut wrote: >> >>> you have a 8K memory but it seems from the log file that you are not >>> using the all the address bits, >>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used. >>> which means that you basically need only 1K from the total of 8K and >>> XST remove the rest, I think this make sense if you keep these >>> addresses tied to a constant. >>> Aurash > > Hello Aurash, > >thanks for the prompt reply. > (the 8KB memory serves as the external RAM of the 8051) >But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16 >address bits and only 13 bits for the lower 8 KB are used. >Or better, the 8KB is repeated 8 times in the 64KB address space. >So all 13 address lines for the RAM are used, and I don't see why >it is optimized away. > > Sietse In your code, I didn't see any decoding of the top 3 bits to enable one of the 8 rams to cover the whole 64k range. That's the reason it thinks all the memories are identical, you are using the same 13 bits to drive them. You should somehow differentiate them, probably with an enable signal generated from the top 3 bits (maybe you're doing that during the generation of read/write strobe?). Why it's removing the last 8k memory I am not sure as you are certainly driving the inputs; check the top level connectivity for reading the outputs of the memory into the core.Article: 104449
Hi, I am not sure about this and hence the modified question: After designing the Aurora protocol and implementing it, I want to access the data values using my PC. For this purpose, I thought of sending the tx values through the RS232 port of the PowerPC. However, I am having a problem. I am not able to access the RS232 access ports. The files are proprietary of XIlinx EDK and cannot be modified...( iam talking abt "opb_uartlite.vhd" and it's rx and tx versions). I also tried adding the system.xmp file to my ISE project but it's useless as no ports are avbl for sending the tx data to the RS 232 block. What is the easiest way to do accomplish this task?? I also gather that if this can be figured out, I can in the future access different blocks written in ISE using PPC and output values on RS232. The values inhaled from RS232 can be used for further processing using Matlab, etc. Thanks, Vivek Hal Murray wrote: > >Now the problem I have is that the avbl project in XPS has a rx and tx > >port (std_logic) and the data I need to send is atleast 16 bits. How do > >I access or interface the register outputs from Aurora to RS232?? > > It's fairly easy to make a hack RS-232 transmitter. It's just > a shift register preloaded with the data and start/stop bits. > For 16 bits of data, I'd use a 20 bit shift register - 2 8-bit > bytes with start and stop bits on each. > > You can probably sort out all the LSB/MSB first and inversions > by reading the specs carefully enough. It's probably simpler to > put a scope on the cable to your PC and make it send a known pattern. > > You (probably) don't need fancy RS-232 level shifters. Most RS-232 > receivers will do the right thing if you feed them a 3V CMOS signal. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam.
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