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
Brad, The problem with using a DCM with an external signal, and relying on the internal reset on start-up is that the start-up affects the externals signals, and reset is not always good. So, the recommendation is to also have an effective way to reset the DCM specifically when it does not operate the way it is expected to. A simple inversion from LOCKED is perhaps a bit rough (I wouldn't do that - and I helped design it!). But, to read the LOCKED status bit, and the CLKIN_STOPPED status bit, OR them, and then set a bit to be clocked out to reset the DCM (clocked from some other clock source) is a good idea. http://tinyurl.com/5og5c is but one of a number of answers on this very subject. Type dcm reset into the search of the answers database on: http://www.support.xilinx.com/support/mysupport.htm (upper left hand corner) Austin Brad Smallridge wrote: > Hello Xilinx folks, > > I have an issue recently developed when changing an oscillator input from a > oscillator package to a clock generated from a Cypress FX2 chip, both > running at the same frequency. With the oscillator package I was having no > trouble at all but the Cypress chips has to enumerate and renumerate and the > oscillator signal arrives at the Xilinx DCM much later, causing the Xilinx > S3 to lock out. A pushbutton reset to the DCM reset pin or a JTAG reload of > the Xilinx S3 will bring the S3 back to life, however, the power up sequence > does not work. This brings up a number of questions that a proper reset for > the DCM requires: > > First, it states in XAPP462, that a failed lock situation should reset the > DCM. Do you do this by simply inverting the LOCKED signal and putting it > into the DCM RESET pin? Or do you need some sort of external circuit to > detect the lock signal and do a hard pin reset? > > Second, XAPP462 suggest a SLR16 in the reset of the DCM. I assume this is > only necessary if you are using the external feedback path. Yes? > > Third, XAPP462 mentions a STARTUP_WAIT attribute (pg.15). Where is this > setting in the newer 6.2 Project Navigator release? > > Forth, there is an FPGA Startup Clock option with CCLK, User Clock, or JTAG > Clk option. What is the CCLK? And if you select User Clk, how do you > indicate which pin or which VHDL signal you intend to use with it? > > Thanks, > > Brad Smallridge > b r a d @ a i v i s i o n . c o m > > > >Article: 76826
Hello, This problem has been getting on my nerves for quite some time now. First of all I'll let you know that I'm an inexperienced engineer - it's my first year in the field, so please bear with my inherent foolishness where applicable. Now to the point: I'm working on a design which uses the Altera Cyclone as a comm dispatcher/bridge/multiplexer between 3 Microchip PIC18F452, an FTDI 245 USB_to_parallel IC and an Cypress SL811HST USB host controller. The problem is the Cyclone overheats constantly (to about 85 C) from power-up. I have excluded the possibility of outputs colliding with other outputs by only soldering the FPGA to an empty PCB, suppling it with power and downloading the configuration to it and the problem is the same - it overheats whether configured or not. There is no difference in temperature between the configured and unconfigured state. I have tried all the obvious tests including short-circuit-to-ground-or-power testing of each IO pin and all are well. Also all the power pins are properly conected. One thing to know is that the PCB is designed in house by us so there may be errors there as well as this is the first version of the design. Another important observation is that the design was initialy developed on a breadboard using a Cyclone mini dev board purchased from www.devboards.de and connecting the rest by strap-wire. It worked fine without overheating with the same configuration data for the Cyclone. Please suggest any test path I should try to figure out this mess as deadlines ar pressing me quite strongly. Thanks a lot!Article: 76827
"Alex Somesan" <alex.somesan@gmail.com> wrote in message news:1102976011.748524.106200@f14g2000cwb.googlegroups.com... > Hello, > > This problem has been getting on my nerves for quite some time now. > First of all I'll let you know that I'm an inexperienced engineer - > it's my first year in the field, so please bear with my inherent > foolishness where applicable. > Now to the point: I'm working on a design which uses the Altera Cyclone > as a comm dispatcher/bridge/multiplexer between 3 Microchip PIC18F452, > an FTDI 245 USB_to_parallel IC and an Cypress SL811HST USB host > controller. The problem is the Cyclone overheats constantly (to about > 85 C) from power-up. I have excluded the possibility of outputs > colliding with other outputs by only soldering the FPGA to an empty > PCB, suppling it with power and downloading the configuration to it > and the problem is the same - it overheats whether configured or not. > There is no difference in temperature between the configured and > unconfigured state. I have tried all the obvious tests including > short-circuit-to-ground-or-power testing of each IO pin and all are > well. Also all the power pins are properly conected. One thing to know > is that the PCB is designed in house by us so there may be errors there > as well as this is the first version of the design. Another important > observation is that the design was initialy developed on a breadboard > using a Cyclone mini dev board purchased from www.devboards.de and > connecting the rest by strap-wire. It worked fine without overheating > with the same configuration data for the Cyclone. > > Please suggest any test path I should try to figure out this mess as > deadlines ar pressing me quite strongly. > > Thanks a lot! > Have you checked the power supplies with a scope? What frequency does it run at? Does it work despite its temperature? JeroenArticle: 76828
Yes, I've checked the powe supply (3.3 V from a LM317). Look OK on the scope. Even tried powering it from de old breadboard power supply which proved reliable. It runs at 20 MHz from an oscillator device. Yes, it works despite the heat but ocasionaly freezes up (I suspect it messes up configuration RAM contents because a reconfiguration, even without cutting power, gets it working again).Article: 76829
"Alex Somesan" <alex.somesan@gmail.com> wrote in message news:1102977576.801325.220500@c13g2000cwb.googlegroups.com... > Yes, I've checked the powe supply (3.3 V from a LM317). Look OK on the > scope. Even tried powering it from de old breadboard power supply which > proved reliable. > It runs at 20 MHz from an oscillator device. > > Yes, it works despite the heat but ocasionaly freezes up (I suspect it > messes up configuration RAM contents because a reconfiguration, even > without cutting power, gets it working again). Have you also checked the core supply of 1V5? How much ripple? Is the device properly bypassed? Can the supply deliver enough current? Especially on power up the FPGA needs more current. I don't which Cyclone you're using, but an 1C20 needs up to 1.2A at power up. Are there no floating inputs? At certain input voltages the logic can't decide on a level and it will oscillate heavily at several hunderds of MHz. Are the inputs in your logic properly synchronised? Inputs that go into a metastable state may oscillate, and the oscillation will propagate through the device. JeroenArticle: 76830
"Alex Somesan" <alex.somesan@gmail.com> wrote in news:1102977576.801325.220500@c13g2000cwb.googlegroups.com: > Yes, I've checked the powe supply (3.3 V from a LM317). Look OK on the > scope. Even tried powering it from de old breadboard power supply which > proved reliable. > > It runs at 20 MHz from an oscillator device. > > Yes, it works despite the heat but ocasionaly freezes up (I suspect it > messes up configuration RAM contents because a reconfiguration, even > without cutting power, gets it working again). > There is a 1.5V supply as well? -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.comArticle: 76831
"Jacob Bower" <jacob.bower@gmail.com> skrev i meddelandet news:slrncr9his.c73.jab00@sprite.doc.ic.ac.uk... > Hi, > > I was wondering if anyone in this group can provide some insight as to how > hard it might be to get an FPGA to act as a USB host, for collecting data > at quite a high-bandwidth. Particularly can this reasonably be done at all > with a completely hardware implementation, possibly with an external > embedded USB host controller. Or would I be much better off using some kind > of soft-core CPU to collect and format data from the USB peripheral due > complexity of driving an embedded USB host controller? > > Thanks, > - Jake Question is if you can do it cost effectively in an FPGA. If you take an intelligent USB Host like the AT43USB380, you still need an external micro with about 64 kB of memory just for a single driver (for Mass Storage). Maybe your device class is simpler but uyou probably need a soft MCU and around 16 kB of code just to run the USB Host Stack without any device class. If it is point to point, why need USB at all? -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This is a personal view which may or may not be share by my Employer Atmel Nordic ABArticle: 76832
Al Gosselin wrote: > Tullio Grassi wrote: > > On Tue, 7 Dec 2004, Marc Randolph wrote: > > > > > >>... In short, I think we're doing a pretty good > >>job of exploring the limits on that chip, and the MGT keeps running > >>error free, even at industrial temperatures (junction of 100C). > >> > >>Having used them, here are my suggestions: > >> > >>1. Follow the Xilnix guidelines for power filtering on the MGT and > >>vccaux. > >>2. Use a low jitter clock reference for the MGT. No PLL or DLL > >>sources. A cheap crystal osc will do just fine. > >>3. Use the BREFCLK pin for the MGT if possible. > >>4. Use the flip-chip package if possible. Not a requirement, but > >>it'll just make signals, ground, and power just that much better. > >> > > > > > > > > What is your feeling about using RocketIO over 5 meters of copper cable ? > > Assuming we follow your suggestions and that we get good cables and > > connectors, what is the data rate that we could reach reliably ? > > > > Thanks, > > > > Tullio Grassi > > What kind of copper cable? What sort of drive will you be doing? Any > preemphasis? > > This is a perfect thing to try in simulation. Set up your drivers, > receivers, and cable, then look at some eyes. Don't forget the > connectors and the traces on the PC boards. I agree with Al. 5 meters quite a distance, and there are way too many variables and potential gotchas to try to guess at what the limiting factor(s) are in your particular implementation. I'm certainly not saying that it won't work - only that you'll either have to build it and see, or simulate it. The second option is much cheaper, and generally faster. Good luck, MarcArticle: 76833
My design is mixed, Microblaze in VHDL and the application in verilog with CORE memory FIFOs and Dual Ports. I used CORE Gen for the memory blocks. XPS cannot link my memory blocks when doing a bit stream generate. If I do a place and route in ISE for just my app (verilog) it runs just fine. Anybody else having this problem? ThanksArticle: 76834
Hi Jan,
Use the Quartus Assignments->Settings->EDA Settings->Simulation dialog
to set the Target simulator to NCVHDL and check the Map Illegal VHDL
characters box. This will force the illegal characters to be mapped to legal
characters. We are still interested in understanding how the netlist with th
eillegal characters was generated.
Hope this helps.
- Subroto Datta
Altera Corp.
"Jan De Ceuster" <jandc@elis.ugent.be> wrote in message
news:cpkaji$9ma$1@gaudi2.UGent.be...
>>> * simulate netlist from core (yes I've got a license) : doesnt' work due
>>> to errors when trying to compile the thing.
>>
>>
>> Consider posting the first few error messages.
>
> Yeah I know, I should give more information though no workarounds possbile
> (besides of editing the code) I think.
>
> here it is:
>
> ncvhdl: 05.00-p001: (c) Copyright 1995-2003 Cadence Design Systems, Inc.
> SIGNAL ww_\g_local_buffered_if:wdata_fifo\_data : std_logic_vector(29
> DOWNTO 0);
> |
> I think that the _\ construction is illegal but to be honnest: I've no
> desire to dig in the vhdl reference to see who is right, Cadence and
> Synopsys versus Altera.
Article: 76835I have tried reading up on CUPL for a CPLD project, but I have been less than successful. Is there a good tutorial on some of the advanced CUPL stuff? In my case, I have some combinatorial logic (CE_OUT=CE_IN & !A7 & !A6 & !A5 & !A4 & !A3), and I grok that pretty well. But, in my design, I need to implement a read/write register, and I can't find a good example in CUPL to implement it. The Data lines need to be HiZ unless the register is being accessed, and if it is, lines go to latch input if Write, lines go to latch output if read. Examples would be fine, or just links to a good tutorial that would show a register would be perfect. Jim -- Jim Brain, Brain Innovations brain@jbrain.com http://www.jbrain.com Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!Article: 76836
> Xilinx have a hugh advantage on shift registers with SRL16s which I believe > Altera can't easily mimic due to patent issues. Someone from Altera can tell > me if I am wrong in this. Hi John, I'd disagree that Altera is at any disadvantage on shift registers -- we just have a different approach. Building large shift registers out of LE registers is very inefficient in both area and power, and isn't the way we build them in Altera devices. Instead, large shift registers are automatically converted to RAM-based FIFOs. If you don't like to rely on automatic conversion, you can instantiate the altshift_taps megafunction yourself (it implements all sorts of RAM-based shift registers). I just coded up a 721-bit shift register in VHDL, and it takes 1 M4K RAM and 15 Logic Cells in Stratix -- vastly less area and power than the alternative of using 721 logic cell registers. This is also less area and power than the Xilinx SRL16 solution for large shift registers. For example, a 4096-bit shift register takes 1 M4K RAM and 17 Stratix Logic cells, which is a lot smaller than 256 SRL16s. In terms of power, the altshift_taps implementation results in only one entry in the RAM being read and one written each cycle (plus a small amount of switching in the FIFO pointer counters), instead of having each of 4096 registers toggle. I know in your case you're trying to make a high-power design to make a power measurement, but that is definitely not what most of our customers are trying to do, so the power efficiency of FIFOs is pretty compelling. Building clever structures like this out of RAM is why we have 3 different sizes of RAM, and lots of RAM, in our devices. The M512 lets us build moderate size shift registers efficiently, the M4K lets us build big ones efficiently, the MRAM lets us build very big shift registers efficiently, and the register cascade chain feature in the Stratix/StratixII lets us "recycle" unused registers (there are almost always a lot of registers left over in the FPGA devices, since most designs use more LUTs than registers) to build any small shift registers (e.g. 4-bit shift) needed. As for patents, Altera and Xilinx have cross-licensed their patent portfolios, so there's no patent barrier on this. However, for the reasons I've listed above we don't think SRL16 is compelling, so we've judged it not worth the area it adds to the LUT. Vaughn Altera v b e t z (at) altera.com [remove spaces and use proper @ to reach me]Article: 76837
Jim Brain wrote:
> I have tried reading up on CUPL for a CPLD project, but I have been less
> than successful. Is there a good tutorial on some of the advanced CUPL
> stuff?
I don't know a tutorial as I don't use CUPL any more
> But, in my design, I need to implement a read/write register, and I
> can't find a good example in CUPL to implement it. The Data lines need
> to be HiZ unless the register is being accessed, and if it is, lines go
> to latch input if Write, lines go to latch output if read.
a 4-bit register from an old CUPL-file build with D-FFs:
===========><============
pcadrio = [sa9..sa0];
" write:
[reset_ff,swapmem,vcion,reserve].clk = !((pcadrio==^h390) & !iow & !aen);
[reset_ff,swapmem,vcion,reserve].ar = resetdrv;
[reset_ff,swapmem,vcion,reserve].d = [pcd0, pcd1, pcd2, pcd3
].pin;
" read:
[pcd0, pcd1, pcd2, pcd3] = [reset_ff,swapmem,vcion,reserve];
[pcd0, pcd1, pcd2, pcd3].oe = (pcadrio==^h390)& !ior & !aen;
===========><============
another register build without FFs (just the "write" part of it):
===========><============
pullupw = !( (!cspullup & !write & !data.pin) # !reset
# !(!cspullup & !write & data.pin) & !pullupw);
===========><============
Hope it helps.
Andreas
--
DSA Daten- und Systemtechnik GmbH | mailto:ah@dsa-ac.de
Dipl.-Ing. Andreas Hölscher | http://www.dsa-ac.de
Pascalstr. 28 | Tel.: +49 2408 9492-645
D-52076 Aachen | Fax.: +49 2408 9492-92
Germany | PGP Key ID: 0x3EFCA3C6
Article: 76838What do you mean by "XPS cannot link my memory blocks when doing a bitstream generate" ?? Did you create a pcore from your verilog core ? You can also try instantiating the XPS project as a sub-module within ISE. Amit Jerry wrote: >My design is mixed, Microblaze in VHDL and the application in verilog with >CORE memory FIFOs and Dual Ports. I used CORE Gen for >the memory blocks. XPS cannot link my memory blocks when doing a bit stream >generate. If I do a place and route in ISE for just my >app (verilog) it runs just fine. Anybody else having this problem? > >Thanks > > > > >Article: 76839
Hi Subroto, the netlist was generated in the fasted way I could get that netlist. I took the generated DDR SDRAM core from the Altera IP libary (version 2.2) and putted it in a Quartus II 4.1 projectfile on a Stratix FPGA. I've did no pinassignments whatsoever (or any other assignment) and the compiled the whole thing and let Quartus dump out a NCSim (here I am again) VHDL netlist. So in short: generate DDR core, dump it in Quartus 4.1 as is and compile to netlist. Jan > Hi Jan, > > Use the Quartus Assignments->Settings->EDA Settings->Simulation dialog > to set the Target simulator to NCVHDL and check the Map Illegal VHDL > characters box. This will force the illegal characters to be mapped to legal > characters. We are still interested in understanding how the netlist with th > eillegal characters was generated. > > Hope this helps. > - Subroto Datta > Altera Corp. > > "Jan De Ceuster" <jandc@elis.ugent.be> wrote in message > news:cpkaji$9ma$1@gaudi2.UGent.be... > >>>>* simulate netlist from core (yes I've got a license) : doesnt' work due >>>>to errors when trying to compile the thing. >>> >>> >>>Consider posting the first few error messages. >> >>Yeah I know, I should give more information though no workarounds possbile >>(besides of editing the code) I think. >> >>here it is: >> >>ncvhdl: 05.00-p001: (c) Copyright 1995-2003 Cadence Design Systems, Inc. >>SIGNAL ww_\g_local_buffered_if:wdata_fifo\_data : std_logic_vector(29 >>DOWNTO 0); >> | >>I think that the _\ construction is illegal but to be honnest: I've no >>desire to dig in the vhdl reference to see who is right, Cadence and >>Synopsys versus Altera. > > >Article: 76840
Hi,
I have a quit simple question abaut cpld fitting:
I'm using a Xilix Coolrunner (XPLA3) CPLD with pin locking and trying to
access a SRAM.
If I try to fit my code, the following error message is given by the fitter
for some pins:
WARNING:Cpld:1081 - Cannot assign signal 'sram_data<22>' to location
'73=FB16_3'. Not enough control terms.
Searching the Xilinx answer data base I came across a posting (
http://university.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=19477
) in which this problem was described and the following workaround was
presented:
Adjust the design to remove unnecessary unique control term usage (for
example, use synchronous reset or preset as opposed to asynchronous reset or
preset, and use synchronous load as opposed to asynchronous load).
Unfortunalty I don't know what a "synchronous reset or preset " means! Does
this means that I have to have an synchronous reset for the cpld device
(which I have) or does this mean that the macrocell itself should somehow be
reseted synchonously? And how do I do that??
Thanks,
Stephan
Part of my code:
--//////////////////////////////////////////////////////////////////////////
///////////////
--
-- BEGIN PROCESS MAIN
--
--//////////////////////////////////////////////////////////////////////////
///////////////
proc_main: process (CLK, RESET_not) is
begin
--//////////////////////////////////////////////////////////////////////////
///////////////
--
-- CLK'event and CLK = '1'
--
--//////////////////////////////////////////////////////////////////////////
///////////////
if (CLK'event and CLK = '1') then
--//////////////////////////////////////////////////////////////////////////
///////////////
--
-- synchronous RESET
--
--//////////////////////////////////////////////////////////////////////////
///////////////
if RESET_not = '0' then
-- usb
EF_not <= '1';
FF_not <= '1';
--sram
sram_adsc_not <= '1';
sig_sram_bw_not <= "1111";
sig_sram_add <= '0';
sram_oe_not <= '0';
-- sram_adsp_not <= '1';
sram_data <= (others => 'Z');
sram_address_sig <= (others => '0');
testpin <= (others => '1');
--testtest
-- state <= IDLE;
state <= SRAM_FILL_1;
-- state <= SRAM_OUT_WAIT;
-- state <= GET_LENGTH;
-- data_length <= X"0080";
-- command_state <= IDLE;
-- command_state <= SRAM_OUT;
-- end testtest
else
case state is
--//////////////////////////////////////////////////////////////////////////
///////////////
--
-- IDLE
--
--//////////////////////////////////////////////////////////////////////////
///////////////
when IDLE =>
testpin( 15 downto 12) <= "0000";
-- test
if userset_not = '0' then
testpin(0) <= '0';
state <= SRAM_FILL_1;
end if;
--//////////////////////////////////////////////////////////////////////////
///////////////
--
-- USER SRAM DELETE
--
--//////////////////////////////////////////////////////////////////////////
///////////////
when SRAM_FILL_1 =>
testpin( 15 downto 12) <= "1001";
testpin(1) <= '0';
-- all Bytes
sram_adsc_not <= '0';
sig_sram_bw_not <= "0000";
sram_oe_not <= '1';
sram_address_sig <= sram_address_sig + '1';
sram_data(15 downto 0) <= (others => '0'); --sram_address_sig;
sram_data(31 downto 16) <= (others => '0'); --sram_address_sig;
state <= SRAM_FILL_2;
when SRAM_FILL_2 =>
-- testpin( 15 downto 12) <= "1010";
-- testpin(2) <= '0';
testpin <= sram_address_sig;
-- test
--if userset_not = '0' then
sram_address_sig <= sram_address_sig + '1';
if sram_address_sig(15) = '1' then
-- end
testpin(4) <= '1';
state <= IDLE;
sram_adsc_not <= '1';
sram_oe_not <= '0';
sig_sram_bw_not <= "1111";
sram_address_sig <= (others => '0');
sram_data <= (others => 'Z');
-- else
-- write another word
-- sram_data(15 downto 0) <= (others => '1'); --sram_address_sig;
-- sram_data(31 downto 16) <= (others => '1'); --sram_address_sig;
end if;
--end if;
--//////////////////////////////////////////////////////////////////////////
///////////////
--
-- OTHER States
--
--//////////////////////////////////////////////////////////////////////////
///////////////
when others =>
state <= IDLE;
end case;
end if;
end if;
end process;
--//////////////////////////////////////////////////////////////////////////
///////////////
--
-- End PROCESS MAIN
--
--//////////////////////////////////////////////////////////////////////////
///////////////
Article: 76841On Mon, 13 Dec 2004 17:20:58 +0100, Grégory Mermoud <gregory.mermoud@epfl.ch> wrote: > I am currently working on an implementation of such a controller for my > semester project. So I will let you have a look to my code when I have > finished it. > > Greetz :) > > Grégory Mermoud > gregory.mermoud@epfl.ch > Swiss Federal Institute of Technology - Lausanne > Computer Science Departement Yeah that would be great ! Thanks ! Konstantin -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/Article: 76842
Jeroen wrote: > "Alex Somesan" <alex.somesan@gmail.com> wrote in message > news:1102977576.801325.220500@c13g2000cwb.googlegroups.com... > > Yes, I've checked the powe supply (3.3 V from a LM317). Look OK on the > > scope. Even tried powering it from de old breadboard power supply which > > proved reliable. > > It runs at 20 MHz from an oscillator device. > > > > Yes, it works despite the heat but ocasionaly freezes up (I suspect it > > messes up configuration RAM contents because a reconfiguration, even > > without cutting power, gets it working again). > > Have you also checked the core supply of 1V5? How much ripple? Is the device > properly bypassed? Can the supply deliver enough current? Especially on > power up the FPGA needs more current. I don't which Cyclone you're using, > but an 1C20 needs up to 1.2A at power up. > > Are there no floating inputs? At certain input voltages the logic can't > decide on a level and it will oscillate heavily at several hunderds of MHz. > Are the inputs in your logic properly synchronised? Inputs that go into a > metastable state may oscillate, and the oscillation will propagate through > the device. > > Jeroen The power supply is the same as the one used on the breadboard prototype and that one worked fine so I presume it does deliver enough current. Measured current for the whole board with all the devices mounted and the FPGA configured is around 300mA. The Cyclone is a EP1C3T144C8 which in the datasheet is speced at around 500mA at powerup. The power supply can deliver 1.5A considering the datasheet of the LM317. I scoped the power line and found around 20mV of ripple both over and under the 3V average wich sometimes fades to zero ripple. I can't recall of any 1V5 power for the core on the device pinout. The only 1V5 requirement is for the analogue part of the PLL. So as far as I know there is no separate 1V5 supply for the core. The PLL 1V5 supply is OK. I don't realy understand what you mean by floating imputs?. Almost all of the device IO pins are used on the design so there are around 6 pins left unconected on the Cyclone. What sould I do with these? Shoud they be tristated from the design software? As far as input oscillation I don't know if it is directly related to the problems as the heating occurs even when the device is the only chip soldered to the board and both in unconfigured or configured state.Article: 76843
"Alex Somesan" <alex.somesan@gmail.com> schreef in bericht news:1103024769.952592.211250@f14g2000cwb.googlegroups.com... > Jeroen wrote: > > "Alex Somesan" <alex.somesan@gmail.com> wrote in message > > news:1102977576.801325.220500@c13g2000cwb.googlegroups.com... > > > Yes, I've checked the powe supply (3.3 V from a LM317). Look OK on > the > > > scope. Even tried powering it from de old breadboard power supply > which > > > proved reliable. > > > It runs at 20 MHz from an oscillator device. > > > > > > Yes, it works despite the heat but ocasionaly freezes up (I suspect > it > > > messes up configuration RAM contents because a reconfiguration, > even > > > without cutting power, gets it working again). > > > > Have you also checked the core supply of 1V5? How much ripple? Is the > device > > properly bypassed? Can the supply deliver enough current? Especially > on > > power up the FPGA needs more current. I don't which Cyclone you're > using, > > but an 1C20 needs up to 1.2A at power up. > > > > Are there no floating inputs? At certain input voltages the logic > can't > > decide on a level and it will oscillate heavily at several hunderds > of MHz. > > Are the inputs in your logic properly synchronised? Inputs that go > into a > > metastable state may oscillate, and the oscillation will propagate > through > > the device. > > > > Jeroen > > The power supply is the same as the one used on the breadboard > prototype and that one worked fine so I presume it does deliver enough > current. Measured current for the whole board with all the devices > mounted and the FPGA configured is around 300mA. The Cyclone is a > EP1C3T144C8 which in the datasheet is speced at around 500mA at > powerup. The power supply can deliver 1.5A considering the datasheet of > the LM317. I scoped the power line and found around 20mV of ripple both > over and under the 3V average wich sometimes fades to zero ripple. I > can't recall of any 1V5 power for the core on the device pinout. The > only 1V5 requirement is for the analogue part of the PLL. So as far as > I know there is no separate 1V5 supply for the core. The PLL 1V5 supply > is OK. So you have all pins called VCCint tied to 3V3??? Then I guess it's no wonder the device gets hot, you're blowing it up! JeroenArticle: 76844
Stephan Mueller wrote: > Hi, > > I have a quit simple question abaut cpld fitting: > I'm using a Xilix Coolrunner (XPLA3) CPLD with pin locking and trying to > access a SRAM. > If I try to fit my code, the following error message is given by the fitter > for some pins: > > WARNING:Cpld:1081 - Cannot assign signal 'sram_data<22>' to location > '73=FB16_3'. Not enough control terms. > > Searching the Xilinx answer data base I came across a posting ( > http://university.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=19477 > ) in which this problem was described and the following workaround was > presented: > > Adjust the design to remove unnecessary unique control term usage (for > example, use synchronous reset or preset as opposed to asynchronous reset or > preset, and use synchronous load as opposed to asynchronous load). > > Unfortunalty I don't know what a "synchronous reset or preset " means! Does > this means that I have to have an synchronous reset for the cpld device > (which I have) or does this mean that the macrocell itself should somehow be > reseted synchonously? And how do I do that?? Howdy Stephan, They are referring to the reset for the flip-flop in the macrocell. I'm a tad rusty on CPLD design, so I don't know how much it is really hurting you, but it looks like you are inferring latches rather than FF's on a number of your signals. Latches typically require extra feedback, which can chew up extra resources. Since on CPLD"s most of the inputs already feed into the interconnect, this is probably less of an issue, but it still might be pushing you over the edge. To get around this, every signal that has assignment within the reset clause should also have an assignment after the "else" that is associated with your synchronous reset (which I couldn't help but notice is commented in your code). You can do this by either assigning all signals in each and every one of your states, or you can make a default assignment (so you only have to do it once) immedately before the case statement. Have fun, MarcArticle: 76845
Hi *, I'd like to establish a high-speed connection between two Virtex-II-Pro-FPGAs, using several bidirectional 3,125Gbit/s-RocketIO-links in parallel (using e.g. Aurora). How do I route something like this properly? If I want to connect 2 FPGAs that are directly adjacent to each other, the TX-pads are always opposite other TX-pads, and RX-pads always opposite other RX-pads. So the way I see it I'd have to cross each and every TX/RX-pair, like it's usually done in a cross-over-cable... This makes vias in the signal path unavoidable, something I'd rather not do if it can be avoided somehow. Any tips or tricks for this? cu, SeanArticle: 76846
Jim, We have been using CUPL for about 8 years ago. If you want, I can find you one of our two old CUPL projects, whcih you can use a refernce. SHould you wonna this, just email me. -- Regards, Pavel "Jim Brain" <brain@jbrain.com> wrote in message news:Ppuvd.566678$D%.231597@attbi_s51... >I have tried reading up on CUPL for a CPLD project, but I have been less >than successful. Is there a good tutorial on some of the advanced CUPL >stuff? > > In my case, I have some combinatorial logic (CE_OUT=CE_IN & !A7 & !A6 & > !A5 & !A4 & !A3), and I grok that pretty well. > > But, in my design, I need to implement a read/write register, and I can't > find a good example in CUPL to implement it. The Data lines need to be > HiZ unless the register is being accessed, and if it is, lines go to latch > input if Write, lines go to latch output if read. > > Examples would be fine, or just links to a good tutorial that would show a > register would be perfect. > > Jim > > -- > Jim Brain, Brain Innovations > brain@jbrain.com http://www.jbrain.com > Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!Article: 76847
>Depending on what you are trying to do you can use the DBGC405DEBUGHALT >pin on the processor block to stop the processor. See the PowerPC 405 >Processor Block Guide for more information >(http://direct.xilinx.com/bvdocs/userguides/ug018.pdf). > >- Peter Hello, thanks for the hint, i'll try. But i think i found out that solely stopping execution won't solve my problem. What i am trying to do is bypass the ppc to directly access sdram (a component on the fpga is saving/fetching data in sdram, but an executable is running in sdram, too. Resulting in concurrent accesses on the same addresslines ). My hope is, once the ppc is put to sleep, i can manage the bus and access sdram without destroying the executable/cpu-context. My first thought was to use DMA, but i cannot find any examples how to implement a DMA-capable obp-ipif with a master attachement to the bus, at least not with EDK6.2. (as far as i understand a master attachement is needed for dma-access) EDK6.2 only provides a very basic opb-ipif reference-design with a master attachement.. Best regrads PatrickArticle: 76848
Sean, Rotate one of the FPGAs by 180 degrees. Symsx. "Sean Durkin" <smd@despammed.com> wrote in message news:41beee41$1@news.fhg.de... > Hi *, > > I'd like to establish a high-speed connection between two > Virtex-II-Pro-FPGAs, using several bidirectional > 3,125Gbit/s-RocketIO-links in parallel (using e.g. Aurora). How do I route > something like this properly? > > If I want to connect 2 FPGAs that are directly adjacent to each other, the > TX-pads are always opposite other TX-pads, and RX-pads always opposite > other RX-pads. So the way I see it I'd have to cross each and every > TX/RX-pair, like it's usually done in a cross-over-cable... > > This makes vias in the signal path unavoidable, something I'd rather not > do if it can be avoided somehow. Any tips or tricks for this? > > cu, > SeanArticle: 76849
Please help me with an information about PAL16V8 programming. What program should I use for obtain .jedec file? Thanks,
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