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
Sylvain Munaut wrote: > Hello, > > I'd like to know more about local clocking in the spartan 3. > On some xilinx app notes, they're referring to a > XAPP769 "Local clocking in spartan 3 family devices" > > However I can't find it anywhere ... So where can I find infos > about this technique ? Howy Sylvain, I asked the same question of my FAE. The response was that the app note was started last year but isn't yet finished, and if I understood correctly, would rely on a software update (coming in 7.1i). If you can't wait for it to appear, I'd open a webcase or get to talking with your FAE. Good luck, MarcArticle: 79001
> I haven't been able to find the junction-to-board thermal resistance numbers > for the FG676 package (or any other package). Howdy Bob, The "Device Packaging and Thermal Characteristics" (aka ug112.pdf) document, which can be had if you click on the "Packages & Thermal Characteristics" link on this page: http://www.xilinx.com/support/library.htm seems to say that theta(jb) and psi(jt) vary quite a bit from application to application, so I guess that's why they don't publish numbers for them. > I know that theta(jc) is about 2degC/W, and we're curious as to how much >[...] The V2Pro userguide and ug112.pdf guide both agree with your ~2degC/W number. Note that the latest ug112.pdf has some errors in it ... columns are swapped around (theta(ja) of 250 lfm is shown as a smaller number than 500 or 750 lfm!). Have fun, Marc -- Tired of popups and Microsoft security problems? Get the Mozilla free Firefox web browser: http://www.getFirefox.com/Article: 79002
"Antti Lukats" <antti@openchip.org> writes: > Creative lazyness and sometimes simple waiting (or sleeping) is possible the > most effective way to work! And it's a great weight loss program. You can burn 50-90 calories per hour sleeping. I think I'll start sleeping more!Article: 79003
"Martin Schoeberl" <martin.schoeberl@chello.at> writes: > Sounds good. But these SD cards aren't they built with NAND Flash? > And NAND Flash can have bad sectors. If one of these bad sectors > is one of the first you can't use it. No, because the SD card incorporates an intelligent controller that hides the bad blocks, just like a SCSI disk does.Article: 79004
Dave Colson wrote: > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:Wrqdneo8FpgSkpbfRVn-jw@adelphia.com... > >>Dave Colson wrote: >> >>>Hi, >>> >>>Just wondering if anyone has used, or tried to use >>>this device yet. I have a design I did for the ProAsic+ >>>that I converted to use the PA3 as a test. Went fairly well. Only >>>real issue I had was that when I set the option for Designer or move >>>flip flops to the IO cells, it did not implement them correctly. >>>Specifically the async resets where the wrong sense. Since The device I >>>am targeting is not in production yet so I can only simulate the back >>>annotated >>>design. This is where I discovered the problem so I do not know if the >>>problem >>>is with the simulation model or with designer. >>> >>>I had a couple of problems with the Plus and notice some changes to the > > PA3 > >>>data sheet; primarily concerned with the JTAG TRST pin. Under the pin >>>description >>>section, They "recommend" the following: >>> >>>"TRST Boundary Scan Reset Pin >>> >>>The TRST pin functions as an active low input to >>>asynchronously initialize (or reset) the boundary scan >>>circuitry. There is an internal weak pull-up resistor on the >>>TRST pin. In the operating mode, a 100 ? external pulldown >>>resistor should be placed between TRST and GND >>>to ensure that the chip does not switch into a different >>>mode." >>> >>>I had a power-up problem on some of the Plus device and found out >>>that if I ground the TRST pin , the device would start working. I >>>report this to Actel and had them evaluate the parts that exhibited the >>>problem. >>>There recommendation: "ground the TRST pin". Sounds to me like there is > > a > >>>problem with the TAP port on both the Plus and PA3 devices and the >>>100 ? resistor is the "patch" to fix it. I am curious if anyone else has > > had > >>>problems with the TRST pin. >>> >>>The other problem I have had is a high programming failure rate >>>while using the FlashPro programmer, mostly exit 11 errors. >>>Actel was not able to helps us solve this problem. We did >>>not press them on this since eventually we would be getting the >>>devices programmed by our supplier and it would become >>>a non-issue after that. The curious thing is that if a device > > successfully > >>>programmed the first time, it would more then likely always program >>>successfully. I have reprogram a single device 50 to 60 times >>>with no problem. I suspect a marginal problem with the device itself or >>>a problem with the programming algorithm and not with my programming >>>fixture. >>> >>>It bothers me that Actel will not admit problems with their devices. > > Xilinx > >>>has no problem with admitting problems with devices and then publishing >>>a work around to the problem until a permanent fix to the silicon is >>>implemented. >>>Why is Actel reluctant to do this. Maybe this problem with the TRST was >>>already >>>know to them, and if they had published an errata on this then maybe I > > would > >>>not have >>>spent over a week debugging this problem. >>> >>>Why do I use Actel if I am unhappy with there devices? the truth is it > > is > >>>the only >>>reprogrammable FPGA that fit the application. >>> >>>Would like to hear about any experiences that other people have had with > > the > >>>Actel >>>Flash parts. >> >>I am meeting with a sales rep and FAE on these products tomorrow, opps, >>today. My main concern is that they are not slated to be out until Q4 >>although I was told possibly Q3 (meaning end of Sept). I also want to >>hear some real pricing instead of the "as low as xxx in quantity". >> >>I was told that the larger parts would be out first. So if you want a >>$1.50 part you will need to wait until '06, I expect. >> >>The data sheet talks about being 5 volt tolerant, but they aren't. They >>just do the same game of using resistors like the Virtex, etc. parts. >> >>I don't see the pulldown on the TRST as being much of a bug myself. My >>experience has been that every part handles the JTAG signals in >>different, often incompatible ways. But if you use the spec'd pull ups >>or downs and use their cable the JTAG should work just like TI DSPs and >>Xilinx FPGAs. >> >>I'll let you know what I find out from the FAE. > > > > I seem to remember that the JTAG spec requires(recommends) that TRST is > optional. > That is it is not require to perform any of the JTAG operations, including > powering up. I don't believe that is correct. The TRST pin is optional, but it does not have to allow the part to work if not driven to the correct state, as in the JTAG cable can ignore it. > As far as a bug. We had 2 unexplained catastrophic field failures (parts > actually were fried) > of the Plus device before I was able to figure out the problem in the lab. > > Some of the parts that fail to power up correct started to go into thermally > run away. > Eventually they would overhead and destroy themselves. It is one think if it > powers up > brain dead but another when it destroy itself and half of the other > components on the board. I have not looked at the programming process, but isn't there a signal to indicate a programming failure? The SRAM based parts have that. > My main issue is the fact that they do not notify customer of problems with > the device. I always > felt like I was the only one having problems with the device, but I am not > so sure now.Article: 79005
rickman wrote: > Dave Colson wrote: > >> Hi, >> >> Just wondering if anyone has used, or tried to use >> this device yet. I have a design I did for the ProAsic+ >> that I converted to use the PA3 as a test. Went fairly well. Only >> real issue I had was that when I set the option for Designer or move >> flip flops to the IO cells, it did not implement them correctly. >> Specifically the async resets where the wrong sense. Since The device I >> am targeting is not in production yet so I can only simulate the back >> annotated >> design. This is where I discovered the problem so I do not know if the >> problem >> is with the simulation model or with designer. >> >> I had a couple of problems with the Plus and notice some changes to >> the PA3 >> data sheet; primarily concerned with the JTAG TRST pin. Under the pin >> description >> section, They "recommend" the following: >> >> "TRST Boundary Scan Reset Pin >> >> The TRST pin functions as an active low input to >> asynchronously initialize (or reset) the boundary scan >> circuitry. There is an internal weak pull-up resistor on the >> TRST pin. In the operating mode, a 100 ? external pulldown >> resistor should be placed between TRST and GND >> to ensure that the chip does not switch into a different >> mode." >> >> I had a power-up problem on some of the Plus device and found out >> that if I ground the TRST pin , the device would start working. I >> report this to Actel and had them evaluate the parts that exhibited the >> problem. >> There recommendation: "ground the TRST pin". Sounds to me like there is a >> problem with the TAP port on both the Plus and PA3 devices and the >> 100 ? resistor is the "patch" to fix it. I am curious if anyone else >> has had >> problems with the TRST pin. >> >> The other problem I have had is a high programming failure rate >> while using the FlashPro programmer, mostly exit 11 errors. >> Actel was not able to helps us solve this problem. We did >> not press them on this since eventually we would be getting the >> devices programmed by our supplier and it would become >> a non-issue after that. The curious thing is that if a device >> successfully >> programmed the first time, it would more then likely always program >> successfully. I have reprogram a single device 50 to 60 times >> with no problem. I suspect a marginal problem with the device itself or >> a problem with the programming algorithm and not with my programming >> fixture. >> >> It bothers me that Actel will not admit problems with their devices. >> Xilinx >> has no problem with admitting problems with devices and then publishing >> a work around to the problem until a permanent fix to the silicon is >> implemented. >> Why is Actel reluctant to do this. Maybe this problem with the TRST was >> already >> know to them, and if they had published an errata on this then maybe I >> would >> not have >> spent over a week debugging this problem. >> >> Why do I use Actel if I am unhappy with there devices? the truth is it is >> the only >> reprogrammable FPGA that fit the application. >> >> Would like to hear about any experiences that other people have had >> with the >> Actel >> Flash parts. > > > I am meeting with a sales rep and FAE on these products tomorrow, opps, > today. My main concern is that they are not slated to be out until Q4 > although I was told possibly Q3 (meaning end of Sept). I also want to > hear some real pricing instead of the "as low as xxx in quantity". > > I was told that the larger parts would be out first. So if you want a > $1.50 part you will need to wait until '06, I expect. > > The data sheet talks about being 5 volt tolerant, but they aren't. They > just do the same game of using resistors like the Virtex, etc. parts. > > I don't see the pulldown on the TRST as being much of a bug myself. My > experience has been that every part handles the JTAG signals in > different, often incompatible ways. But if you use the spec'd pull ups > or downs and use their cable the JTAG should work just like TI DSPs and > Xilinx FPGAs. > > I'll let you know what I find out from the FAE. Here is what I found. The 600 is the first part out of the chute. It will sample by April, as in *we* can get samples then. We never got to a production date because the part does not fit my socket. The lack of 5 volt tolerance and the schedule keeps it off my board. I also did not really get much on pricing. A thing that I found very surprising, I was told it is not really field programmable, as in by a MCU. It has to be programmed by cable because you have to supply +16 and -13.5 volts (or similar). So if the chip can take these voltages, why can't it handle 5 volts on the IOs??? Obviously they are switching high voltages without problems.Article: 79006
Hello, I am new to configuring FPGAs, and I have a question regarding that. I used a Xilinx Spartan2E FPGA for my hardware prototype, and successfully validated it. I configured it using Boundary-scan mode. But now, I am required to use a PROM for configuring FPGA, to deliver the final prototype. My board has a OTP PROM socket for XC17S200A. I am not completely clear about the procedure I have to do to configure this PROM with my design. Are the following steps correct? 1)Generate a .bin or .hex file using Xilinx iMPACT for the design. 2)Program XC17S200A with the file using a Xilinx compatible programmer. 3)Place the XC17S200A PROM on the socket given on the board and 4)Power up the device. Here I am assuming that soon after I power up the device, the FPGA gets configured automatically. The datasheet for XC17S200A says that FPGA should be in Master-serial mode. Is there any option I have to set in iMPACT for this or just powering up the board would work. Any help is greatly appreciated. Thanks Phani.Article: 79007
Hi, gavbiggs@yahoo.co.uk wrote: > on to layout the design. Once the layout has been completed I can then > use the 'Extract' button to create a *.sdf file from which a timing > file is created. At this stage you could also extract a vhdl netlist from Designer. When using Designer standalone it's the backanotate button pressed and in the next dialog check the box "generate netlist". > The problem occurs when I apply back annotation and try to simulate the > design with the *.sdf file. I apply the .sdf to QuickHDL by using the > following in the command prompt: - > qhsim <design> -sdf<delays> <SDF file> > This will load up QuickHDL and then errors will occur, The errors are > as shown below: > > ERROR: home/biggc/fat.sdf(14): failed to find instance /fat/'INBUF_7' > ERROR: home/biggc/fat.sdf(14): failed to find instance /fat/'MX_3' > ERROR: home/biggc/fat.sdf(14): failed to find instance /fat/'MX_3' > ERROR: home/biggc/fat.sdf(14): failed to find instance /fat/'INBUF_1' > ERROR: home/biggc/fat.sdf(14): failed to find instance /fat/'OUTBUF_10' > WARNING: home/biggc/fat.sdf: this file is probably applied to thw wrong > instance. > Ignoring subsequent missing instances from this file. > Failed to find any of the 8 instances from this file. > The file is probably intended for a lower-level instance, not the > top-level. I saw similar errors when the netlist created by designer and the sdf-file used some different "encoding". Try search the netlist for something like inbuf[7] instead of inbuf_7. If I'm right yould configure that in some ways in the Designer software. > When the VHDL model has been applied to Actel Designer, the code is > converted into a circuit, i.e. I/O pad buffers are created etc. this is > what the errors seem to be referring to as I assume its trying to > simulate the VHDL code which doesnt contain these instances. Do I need > to simulate the .edn file (the netlist file) as well as the .sdf file? > and if so how do I achieve this? I never tried Designer V8.x but I never saw Actel Designer inserting io-buffer, this was done by a tool before (?Silicon Expert?) on edif level. bye Thomas -- Emailantworten bitte an thomas[at]obige_domain. Usenet_10 ist für Viren und Spam reserviertArticle: 79008
Hi, How much lmb memory do you have in your system? If you just build your application, how much code and stack space is reported? The error reports that the program doesn't fit. if you using something like printf, it will consume a lot of code space and stack space. Göran Clemens Ragger wrote: > Hi > > I am working with Microblaze on an Xilinx ML300 board. I have added more C > code to my program which is testing my own FSL IP Core > When I try to add more C Code to my program for the FPGA I get the following > error: > > mb-gcc -O2 TestApp/src/TestApp.c -o TestApp/executable.elf \ > > -mno-xl-soft-mul -Wl,-T -Wl,TestApp/src/TestAppLinkScr -I./microblaze_0/include/ > -L./microblaze_0/lib/ \ > > -xl-mode-executable \ > > > mb-ld: region ilmb_cntlr is full (TestApp/executable.elf section .bss_stack) > > make: *** [TestApp/executable.elf] Error 1 > > Done. > > Is there not enough memory for the C Code available? So that I just have to > generate a new Microblaze core which has more RAM available? > > Or what could be the reason for this? THanks for any hint > Clemens > >Article: 79009
I have two questions regarding the code bellow.
I need a dual port buffer (4Kx32 write only, 8Kx16 r/w port). I have
instanciated 8 block RAMS as the code bellow shows:
-------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
library UNISIM;
use UNISIM.VComponents.all;
entity acqbuf is
Port (
i_Clk : in std_logic;
i_AddrA : in std_logic_vector(11 downto 0);
i_DataInA : in std_logic_vector(31 downto 0);
i_WrEnA : in std_logic;
i_EnA : in std_logic;
i_WrEnB : in std_logic;
i_EnB : in std_logic;
i_AddrB : in std_logic_vector(12 downto 0);
i_DataInB : in std_logic_vector(15 downto 0);
o_DataOutB : out std_logic_vector(15 downto 0)
);
end acqbuf;
architecture structural of acqbuf is
component RAMB16_S2_S4
-- pragma translate_off
generic (
WRITE_MODE_A : string := "WRITE_FIRST" ;
WRITE_MODE_B : string := "WRITE_FIRST" ;
);
-- pragma translate_on
port (
DIA : in std_logic_vector (1 downto 0);
ADDRA : in std_logic_vector (12 downto 0);
ENA : in std_logic;
WEA : in std_logic;
SSRA : in std_logic;
CLKA : in std_logic;
DOA : out std_logic_vector (1 downto 0);
--
DIB : in std_logic_vector (3 downto 0);
ADDRB : in std_logic_vector (11 downto 0);
ENB : in std_logic;
WEB : in std_logic;
SSRB : in std_logic;
CLKB : in std_logic;
DOB : out std_logic_vector (3 downto 0)
);
end component;
attribute BOX_TYPE of RAMB16_S2_S4 : COMPONENT is "BLACK_BOX";
begin
RAM : for i in 0 to 7 generate
U_RAMB16_S2_S4 : RAMB16_S2_S4
port map (
DIA => i_DataInB(i*2+1 downto i*2),
ADDRA => i_AddrB,
ENA => i_EnB,
WEA => i_WrEnB,
SSRA => '0',
CLKA => i_Clk,
DOA => o_DataOutB(i*2+1 downto i*2),
--
DIB => i_DataInA(i*4+3 downto i*4),
ADDRB => i_AddrA,
ENB => i_EnA,
WEB => i_WrEnA,
SSRB => '0',
CLKB => i_Clk,
DOB => open
);
end generate;
end structural;
-------
Whereas this code compiles with no error under ISE, under Modelsim I get
the following result:
do acqbuf_tb.fdo
# ** Warning: (vlib-34) Library already exists at "work".
# Model Technology ModelSim XE II vcom 5.8c Compiler 2004.03 Mar 26 2004
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package vital_timing
# -- Loading package vcomponents
# -- Compiling entity acqbuf
# -- Compiling architecture structural of acqbuf
# ** Error: acqbuf.vhd(33): near ")": expecting: IDENTIFIER
# ** Error: D:/Modeltech_xe_starter/win32xoem/vcom failed.
# Error in macro ./acqbuf_tb.fdo line 5
# D:/Modeltech_xe_starter/win32xoem/vcom failed.
# while executing
# "vcom -93 -explicit acqbuf.vhd
# "
The only way to fix it I have found is commenting the generic section.
Is there a decent way to do it keeping that section?
The second question is fairly (rather?) newbie: how to define the
attributes for the instanciated blocks? I suppose the declarationos in
the generic section aren't enough to guarantee the instanciated
components behave like I mean them to.
I tried to do it as in the snippet bellow and I get compilation error:
RAM : for i in 0 to 7 generate
attribute WRITE_MODE_A : string;
WRITE_MODE_A of URAMB16_S2_S4 : lable is "WRITE_FIRST";
attribute WRITE_MODE_B : string;
WRITE_MODE_B of URAMB16_S2_S4 : lable is "WRITE_FIRST";
U_RAMB16_S2_S4 : RAMB16_S2_S4
port map (
DIA => i_DataInB(i*2+1 downto i*2),
Thank you in advance for your help.
Elder.
Article: 79010read the manual and set the jumper switches M1,M2,M3.Article: 79011
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:CbmdnZjg1d9gppHfRVn-qg@adelphia.com... > rickman wrote: > > Dave Colson wrote: > > > > I'll let you know what I find out from the FAE. > > > Here is what I found. The 600 is the first part out of the chute. It > will sample by April, as in *we* can get samples then. We never got to > a production date because the part does not fit my socket. The lack of > 5 volt tolerance and the schedule keeps it off my board. I also did not > really get much on pricing. are you sure its 600 not 600E ? 600E is supported by free tools, 600 not :) the samples did exist in october 2004! just not for regular mortals :( > A thing that I found very surprising, I was told it is not really field > programmable, as in by a MCU. It has to be programmed by cable because > you have to supply +16 and -13.5 volts (or similar). So if the chip can > take these voltages, why can't it handle 5 volts on the IOs??? > Obviously they are switching high voltages without problems. NO NO! the +16.5 -11.5 are for ProAsic+ not for PA3 ! PA3 works down to 1.5 single supply and needs 3.3 for programming AnttiArticle: 79012
removing the semicolon after the second generic in component should work.Article: 79013
Christos wrote: > I think I understand what went wrong.. > look below. > > "Andrés" <nospam_nussspucke@gmx.de> wrote in message > news:3718pjF58afv7U1@individual.net... > >>ALuPin wrote: >> >>>Hi, >>> >>>in one the last posts Christos recommended me to use Virtual Pins >>>if I want the Fitter not to optimize registered unused signals away. >>> >>>I have a module "sie.vhd" instantiated in my top level schematic design > > file > >>>"top_d.vhd". >>> >>>The module "sie.vhd" has a port "Eop_not_recog" of type std_logic. >>>It is a registered signal which is not used at all. >>> > > > Define also in the top level the "Eop_not_recog" as a port. > then use the assignment editor as you describe below but only this time for > this port. > > >>>(I use Altera QuartusII v 4.2). >>> >>>In the Assignment Editor >>>under LOGIC OPTIONS --> ADVANCED I define a Virtual Pin by >>>going to the NODE FINDER and selecting the signal "Eop_not_recog" of the > > entity > >>>"sie.vhd" with the filter "Register : pre-synthesis". >>>Then I select ASSIGNMENT NAME=Virtual Pin, VALUE=On, ENABLED=Yes >>> >>>After compilation I go into the NODE FINDER again to see if > > "Eop_not_recog" > >>>is still listed with the filter "Registers : post-fitting", >>>but it is not. I conclude from this >>>that the fitter optimized the node away although I defined the node >>>as a Virtual pin. > > > After compilation go to NODE FINDER and search for pins: all and you will > find it. > > >>Somethin additional: >>Christos said: >> >One thing that might work is to drive them to outputs and then define >> >those >> >outputs as virtual pins with the assignment editor. >> >They will not be synthesised away. >> >>In the QuartusII Help it is said: >> >This option should be specified only for I/O elements that become >>nodes >when imported to the top-level design. >> >>So do I have to route the signal in the top level file to a FPGA pin and >>define it as VIRTUAL then >>or do I have to define the Port of the component "sie_rec.vhd" as virtual > > ? > >>It is not explained very clear. > > > I think you have found it and it is clear. > The virtual pin can be only a pin, i.e. in, out or bidir and thus has to be > routed up to the top level. > > >>Thank you. >> >>Rgds >>André >> > > > I hope it works for you. > if not mail me directly .. > > Christos dot Zamantzas at cern dot ch > > It's ok now, thank you Christos. RgdsArticle: 79014
Agree with Göran Bilski. Suggestion:1. Modify your program by replacing 'printf' with 'Xil_printf' for the latter is slimer. And so on. 2. Rebuild your system by adding more memory if there is still Bram avaiable. 3. When 1/2 both failed,try to load your program totally in SDRAM,that needs a little trouble,for you have to consider how to load your program into the SDRAM. Good luck!Article: 79015
Antti Lukats wrote: > > Ahh! Good for you! > > With the V4LX25-ES the SystemACE doesnt seem to work! > Be the reason whatever, at most 10 succesfully secotor reads > with correct contents there comes an error that lock ups further > communication with systemace > So you are lucky I am not... > > I wonder that no-one from Xilinx has bothered to comment the issue > SystemACE is working on ML401 and there is also LX25 on board > so if there is an issue then Xilinx DOES know, or if there isnt a issue > then I would be thankful if someone could confirm that systemace > works ok with V4LX25-ES without using any special tricks. > > Antti Antti, make sure there is no pull up resistor on TDO, and add a capacitor between TDO and ground - about 220 pf. See if that will solve your problem ! Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 79016
Neo wrote: > removing the semicolon after the second generic in component should > work. > It didn't.Article: 79017
In article <cufvla02a24@enews2.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:
>
>This page:
>http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/xst/xst0026_5.html#wp325264
>
>shows some templates for ROM inference in Spartan3 using Xilinx's ISE
>software.
>
>One of the templates is:
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_unsigned.all;
> entity rominfr is
> port (
> clk : in std_logic;
> en : in std_logic;
> addr : in std_logic_vector(4 downto 0);
> data : out std_logic_vector(3 downto 0)
> );
> end rominfr;
> architecture syn of rominfr is
> type rom_type is array (31 downto 0) of std_logic_vector (3 downto 0);
> constant ROM : rom_type :=
> ("0001","0010","0011","0100","0101","0110","0111","1000","1001","1010"
>,"1011","1100","1101","1110","1111","0001","0010","0011","0100","0101"
>,"0110","0111","1000","1001","1010","1011","1100","1101","1110","1111" );
> begin
> process (clk)
> begin
> if (clk'event and clk = '1') then
> if (en = '1') then
> data <= ROM(conv_integer(addr);
> end if;
> end if;
> end process;
> end syn;
>
>
>My question is: are they types of the inputs and outputs important for the
>software to infer the ROM? For example, could I have:
>
>
> entity rominfr is
> port (
> clk : in std_logic;
> en : in std_logic;
> addr : in std_logic_vector(9 downto 0);
> data : out ufixed(0 downto -17) -- ufixed is fixed point
> --type from:
> --http://www.eda.org/vhdl-200x/vhdl-200x-ft/packages/files.html
> );
> end rominfr;
>
>Would the ROM still be inferred because I didn't use std_logic_vector on
>the data output? Just wondering how strict the template must be adhered
>to.
>
>
>There are conversion routines to go to/from std_logic_vector<=>ufixed,
>however I'd prefer to keep the output of the ROM in ufixed format if
>possible.
>
FYI: the line:
data : out ufixed(0 downto -17)
Causes the following error:
ERROR:Xst:1548 - c:/phil/vhdl/svm/../lookuptable.vhd line 13: Negative
range in type of signal <data> is not supported.
So looks like you can't use a ufixed (with negative indices ) in a port
signal, anyway.
Phil
Article: 79018"Rudolf Usselmann" <russelmann@hotmail.com> schrieb im Newsbeitrag news:cuhsl4$ed3$1@nobel.pacific.net.sg... > Antti Lukats wrote: > > > > Ahh! Good for you! > > > > With the V4LX25-ES the SystemACE doesnt seem to work! > > Be the reason whatever, at most 10 succesfully secotor reads > > with correct contents there comes an error that lock ups further > > communication with systemace > > So you are lucky I am not... > > > > I wonder that no-one from Xilinx has bothered to comment the issue > > SystemACE is working on ML401 and there is also LX25 on board > > so if there is an issue then Xilinx DOES know, or if there isnt a issue > > then I would be thankful if someone could confirm that systemace > > works ok with V4LX25-ES without using any special tricks. > > > > Antti > > Antti, > > make sure there is no pull up resistor on TDO, and add a > capacitor between TDO and ground - about 220 pf. See if > that will solve your problem ! > > Regards, > rudi Thanks Rudi, but the TDO pullup isnt directly the problem, the SystemACE does read a random number (less than 10) sectors correctly with correct contents after that it gets error and stuck - the sector reads use MPU pins and the JTAG is not involved at all. But... I had pretty much always problems with systemace mpu interface in all cases where FPGA was not configured by the systemace, so if I desolder that pullup and let the sysace todo the config maybe that solves the problem - I kind dont like to modify PCB boards that use 0201 sized components so I have not yet worked with the soldering iron on the Memec V4 board AnttiArticle: 79019
Hi, It seems that it is not possible to instantiate an accumulator with the Megawizard plug-in which has an input wider than 33 bits. If you set the input wider than 33 bits it gives the following error: --------------------------------------------------------------------------- Microsoft Visual C++ Runtime Library Runtime Error! Program: C:\altera\quartus41\bin\mega_altaccumulate.exe This application has requested the Runtime to terminate it in an unusual way, Please contact the application's support team for more information. ---------------------------------------------------------------------------- -- I have winXP sp1 running QuartusII 4.1 sp2 full version. I have tried this to other PCs with similar configuration and still did not work. Finally, I have read all help files with megawizard and the altaccumulate and have not seen anywhere stating this limitation. Thanks to anyone which can help. ChristosArticle: 79020
jneil@harris.com wrote: > Hi, > > We are using RocketIO (1GHz Fibre Channel) in 32-bit mode in a > Virtex-II Pro 50. We are using the CUSTOM_GT and believe that all the > attributes are set correctly. The problem we are having is in our > simulations. When data is received it seams that the Comma character > is mis-aligned. According to the documention, this can happen and the > signal RXREALIGN will indicate when re-alignment of the data is > necessary. However, we never see RXREALIGN go high in our simulations. > Anyone had similar problems or got any ideas... Howdy Jeff, You've probably already seen this, and I'm probably not reading this correctly, but does http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14994 say that you can't do comma alignment in 32 bit mode? Good luck, MarcArticle: 79021
"Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag news:1108125500.635758.128200@l41g2000cwc.googlegroups.com... > > jneil@harris.com wrote: > > Hi, > > signal RXREALIGN will indicate when re-alignment of the data is > > necessary. However, we never see RXREALIGN go high in our > simulations. > > Anyone had similar problems or got any ideas... > > Howdy Jeff, > > You've probably already seen this, and I'm probably not reading this > correctly, but does > http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14994 > say that you can't do comma alignment in 32 bit mode? its not possible to align to 32 bit, thats for sure. but I think it should align to 16 bits that should work ?? AnttiArticle: 79022
Elder Costa wrote: > >I tried to do it as in the snippet bellow and I get compilation error: > There seem to be various typos in those code snippets you posted- did you cut and paste, or re-type them, into your post? Also, an important BRAM safety tip: A variable width dual port spanning multiple BRAMs needs reindexing of the wider port bits to do what you intend. For some old posts on this subject, see: http://groups.yahoo.com/group/fpga-cpu/message/234 http://groups-beta.google.com/group/comp.arch.fpga/msg/48dceebd2448164b BrianArticle: 79023
See comments below. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:AOKdneYeb9dcpJHfRVn-hA@adelphia.com... > Dave Colson wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:Wrqdneo8FpgSkpbfRVn-jw@adelphia.com... > > > >>Dave Colson wrote: > >> > >>>Hi, > >>> > >>>Just wondering if anyone has used, or tried to use > >>>this device yet. I have a design I did for the ProAsic+ > >>>that I converted to use the PA3 as a test. Went fairly well. Only > >>>real issue I had was that when I set the option for Designer or move > >>>flip flops to the IO cells, it did not implement them correctly. > >>>Specifically the async resets where the wrong sense. Since The device I > >>>am targeting is not in production yet so I can only simulate the back > >>>annotated > >>>design. This is where I discovered the problem so I do not know if the > >>>problem > >>>is with the simulation model or with designer. > >>> > >>>I had a couple of problems with the Plus and notice some changes to the > > > > PA3 > > > >>>data sheet; primarily concerned with the JTAG TRST pin. Under the pin > >>>description > >>>section, They "recommend" the following: > >>> > >>>"TRST Boundary Scan Reset Pin > >>> > >>>The TRST pin functions as an active low input to > >>>asynchronously initialize (or reset) the boundary scan > >>>circuitry. There is an internal weak pull-up resistor on the > >>>TRST pin. In the operating mode, a 100 ? external pulldown > >>>resistor should be placed between TRST and GND > >>>to ensure that the chip does not switch into a different > >>>mode." > >>> > >>>I had a power-up problem on some of the Plus device and found out > >>>that if I ground the TRST pin , the device would start working. I > >>>report this to Actel and had them evaluate the parts that exhibited the > >>>problem. > >>>There recommendation: "ground the TRST pin". Sounds to me like there is > > > > a > > > >>>problem with the TAP port on both the Plus and PA3 devices and the > >>>100 ? resistor is the "patch" to fix it. I am curious if anyone else has > > > > had > > > >>>problems with the TRST pin. > >>> > >>>The other problem I have had is a high programming failure rate > >>>while using the FlashPro programmer, mostly exit 11 errors. > >>>Actel was not able to helps us solve this problem. We did > >>>not press them on this since eventually we would be getting the > >>>devices programmed by our supplier and it would become > >>>a non-issue after that. The curious thing is that if a device > > > > successfully > > > >>>programmed the first time, it would more then likely always program > >>>successfully. I have reprogram a single device 50 to 60 times > >>>with no problem. I suspect a marginal problem with the device itself or > >>>a problem with the programming algorithm and not with my programming > >>>fixture. > >>> > >>>It bothers me that Actel will not admit problems with their devices. > > > > Xilinx > > > >>>has no problem with admitting problems with devices and then publishing > >>>a work around to the problem until a permanent fix to the silicon is > >>>implemented. > >>>Why is Actel reluctant to do this. Maybe this problem with the TRST was > >>>already > >>>know to them, and if they had published an errata on this then maybe I > > > > would > > > >>>not have > >>>spent over a week debugging this problem. > >>> > >>>Why do I use Actel if I am unhappy with there devices? the truth is it > > > > is > > > >>>the only > >>>reprogrammable FPGA that fit the application. > >>> > >>>Would like to hear about any experiences that other people have had with > > > > the > > > >>>Actel > >>>Flash parts. > >> > >>I am meeting with a sales rep and FAE on these products tomorrow, opps, > >>today. My main concern is that they are not slated to be out until Q4 > >>although I was told possibly Q3 (meaning end of Sept). I also want to > >>hear some real pricing instead of the "as low as xxx in quantity". > >> > >>I was told that the larger parts would be out first. So if you want a > >>$1.50 part you will need to wait until '06, I expect. > >> > >>The data sheet talks about being 5 volt tolerant, but they aren't. They > >>just do the same game of using resistors like the Virtex, etc. parts. > >> > >>I don't see the pulldown on the TRST as being much of a bug myself. My > >>experience has been that every part handles the JTAG signals in > >>different, often incompatible ways. But if you use the spec'd pull ups > >>or downs and use their cable the JTAG should work just like TI DSPs and > >>Xilinx FPGAs. > >> > >>I'll let you know what I find out from the FAE. > > > > > > > > I seem to remember that the JTAG spec requires(recommends) that TRST is > > optional. > > That is it is not require to perform any of the JTAG operations, including > > powering up. > > I don't believe that is correct. The TRST pin is optional, but it does > not have to allow the part to work if not driven to the correct state, > as in the JTAG cable can ignore it. To be more precise, the default state of the pin (left unconnected) will allow the JTAG to work properly. That is you do not have connect anything to the pin in order for the JTAG to work. It is in the spec. > > > > As far as a bug. We had 2 unexplained catastrophic field failures (parts > > actually were fried) > > of the Plus device before I was able to figure out the problem in the lab. > > > > Some of the parts that fail to power up correct started to go into thermally > > run away. > > Eventually they would overhead and destroy themselves. It is one think if it > > powers up > > brain dead but another when it destroy itself and half of the other > > components on the board. > > I have not looked at the programming process, but isn't there a signal > to indicate a programming failure? The SRAM based parts have that. ProAsic parts are Flash parts you only program them once, they are non-volatile, there is no "programming" on power up like the Xilinx or Altera. The device is ready to go immediately on power up. Maybe I did not explain this well, The issue is that on power up the JTAG circuits powered up in a undetermined state which cause the boundry scan circuit to do bad things to the IOs. Causing the device to not work because it had no control over the IOs. I believe what happen on some of the parts was that the boundry scan cause contention inside the device which cause the thermal run away. > > > > My main issue is the fact that they do not notify customer of problems with > > the device. I always > > felt like I was the only one having problems with the device, but I am not > > so sure now. >Article: 79024
"Antti Lukats" <antti@openchip.org> wrote in message news:cufkhe$mt7$03$1@news.t-online.com... > Hi > <snip FPGA bootloader for SD Card> Great, looks a very useful thing! Wouldn't this be better done by a small micro (e.g. AVR) though? These could be smaller than the 9536 chips. I'm also looking for a system where the main micro can use the SD card after booting. That is, the FPGA boot device tri-states the control signals so the main CPU can drive them. This would get more usefulness out of the SD card. However, if the card gets the FPGA bit file re-written on a PC then returned, the CPLD hardware method might have to send megabytes of data before the FPGA sees the sync word. A micro-based method might be able to search a FAT to find a particular-named file, though obviously this is a non-trivial job unless you have some experience with FAT already. Anyone got any PD FAT source code in C?
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