Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 76825

Article: 76825
Subject: Re: Xilinx S3 late arriving DCM clkin
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 13 Dec 2004 13:18:28 -0800
Links: << >>  << T >>  << A >>
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
Subject: Cyclone device misteriously overheats
From: "Alex Somesan" <alex.somesan@gmail.com>
Date: 13 Dec 2004 14:13:31 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Cyclone device misteriously overheats
From: "Jeroen" <jayjay.1974@xs4all.nl>
Date: Mon, 13 Dec 2004 23:31:23 +0100
Links: << >>  << T >>  << A >>

"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?

Jeroen



Article: 76828
Subject: Re: Cyclone device misteriously overheats
From: "Alex Somesan" <alex.somesan@gmail.com>
Date: 13 Dec 2004 14:39:36 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Cyclone device misteriously overheats
From: "Jeroen" <jayjay.1974@xs4all.nl>
Date: Tue, 14 Dec 2004 00:12:25 +0100
Links: << >>  << T >>  << A >>

"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



Article: 76830
Subject: Re: Cyclone device misteriously overheats
From: Al Clark <dsp@danvillesignal.com>
Date: Mon, 13 Dec 2004 23:15:51 GMT
Links: << >>  << T >>  << A >>
"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.com

Article: 76831
Subject: Re: FPGA as host for a USB peripheral
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Tue, 14 Dec 2004 00:27:33 +0100
Links: << >>  << T >>  << A >>
"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 AB



Article: 76832
Subject: Re: Virtex-II PRO, DDR2 SDRAM, RocketIO
From: "Marc Randolph" <mrand@my-deja.com>
Date: 13 Dec 2004 17:23:05 -0800
Links: << >>  << T >>  << A >>
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,

   Marc


Article: 76833
Subject: ISE/XPS ERRORS
From: "Jerry" <nospam@nowhere.com>
Date: Mon, 13 Dec 2004 21:34:52 -0500
Links: << >>  << T >>  << A >>
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: 76834
Subject: Re: altera DDR core simulation with NCSim
From: "Subroto Datta" <sdatta@altera.com>
Date: Tue, 14 Dec 2004 04:02:41 GMT
Links: << >>  << T >>  << A >>
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: 76835
Subject: Need help with CUPL
From: Jim Brain <brain@jbrain.com>
Date: Tue, 14 Dec 2004 04:58:23 GMT
Links: << >>  << T >>  << A >>
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: 76836
Subject: Re: Cylone Problem with Large Shift Register
From: "Vaughn Betz" <no_spam@altera.com>
Date: Tue, 14 Dec 2004 00:37:52 -0500
Links: << >>  << T >>  << A >>
> 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
Subject: Re: Need help with CUPL
From: =?ISO-8859-1?Q?Andreas_H=F6lscher?= <ah@dsa-ac.de>
Date: Tue, 14 Dec 2004 07:45:58 +0100
Links: << >>  << T >>  << A >>
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: 76838
Subject: Re: ISE/XPS ERRORS
From: Amit Kasat <Amit.Kasat@Xlnx.com>
Date: Mon, 13 Dec 2004 23:43:26 -0800
Links: << >>  << T >>  << A >>
What 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
Subject: Re: altera DDR core simulation with NCSim
From: Jan De Ceuster <jan.de.ceuster@xs4all.be>
Date: Tue, 14 Dec 2004 09:12:29 +0100
Links: << >>  << T >>  << A >>
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
Subject: Newbie question: fitting in cpld
From: "Stephan Mueller" <s.mueller96@gmx.de>
Date: Tue, 14 Dec 2004 09:54:58 +0100
Links: << >>  << T >>  << A >>
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: 76841
Subject: Re: UART receiver
From: "Konstantin Dols" <Konstantin.Dols@rwth-aachen.de>
Date: Tue, 14 Dec 2004 12:02:56 +0100
Links: << >>  << T >>  << A >>
On 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
Subject: Re: Cyclone device misteriously overheats
From: "Alex Somesan" <alex.somesan@gmail.com>
Date: 14 Dec 2004 03:46:09 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Cyclone device misteriously overheats
From: "Jeroen" <sink@null.dev>
Date: Tue, 14 Dec 2004 13:05:27 +0100
Links: << >>  << T >>  << A >>

"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!

Jeroen



Article: 76844
Subject: Re: Newbie question: fitting in cpld
From: "Marc Randolph" <mrand@my-deja.com>
Date: 14 Dec 2004 04:39:45 -0800
Links: << >>  << T >>  << A >>
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,

Marc




Article: 76845
Subject: Linking FPGAs with RocketIOs
From: Sean Durkin <smd@despammed.com>
Date: Tue, 14 Dec 2004 14:44:33 +0100
Links: << >>  << T >>  << A >>
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,
Sean

Article: 76846
Subject: Re: Need help with CUPL
From: "Pavel Semyonov" <pas99@mail.ru>
Date: Tue, 14 Dec 2004 10:22:33 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: pausing execution on ppc405
From: mai99drh@studserv.uni-leipzig.de
Date: 14 Dec 2004 07:45:07 -0800
Links: << >>  << T >>  << A >>
>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
Patrick


Article: 76848
Subject: Re: Linking FPGAs with RocketIOs
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 14 Dec 2004 08:41:35 -0800
Links: << >>  << T >>  << A >>
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,
> Sean 



Article: 76849
Subject: Pal programming
From: dan.costin@gmail.com (Dan)
Date: 14 Dec 2004 09:03:17 -0800
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search