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 150300

Article: 150300
Subject: Re: OT: Fast Circuits
From: Michael S <already5chosen@yahoo.com>
Date: Sun, 9 Jan 2011 01:28:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 12:08=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga MitchAlsup <MitchAl...@aol.com> wrote:> On Jan 7, 8:38 =
pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
> > wrote:
> >> Intel fabs are often ahead of TSMC and UMC and GF. But this doesn't
> >> explain the whole difference, not by a long shot, especially given AMD=
's
> >> situation.
>
> (snip)
>
> > Note: excepting for RAMs and ROMs, there is almost no dynamic logic in
> > one of the x86 manufactures products. Dynamic logic is hard and takes
> > a lot more designers to get right (some of them in the FAB.) Dynamic
> > logic is sensitive to the process window swings. In many cases,
> > dynamic logic is not really faster once you consider not being able to
> > use the logic in the other 1/2 of the clock cycle and the added skew
> > on the falling edge of the clock.
>
> The 8080 and 8086 used dynamic logic. =A0(Possibly only for registers.)
>
> One reason the Z80 became more popular than the 8080 was its use
> of static logic, and the ability to debug with a slow clock.
>
> The processors with built-in PLL can't be slow clocked, even if
> the logic is static.
>
> -- glen

IIRC, somebody here (or was it Paul DeMone in one of his excellent RWT
articles) explained that dynamic logic of today is different from
dynamic logic of late 70s. From high level perspective today's dynamic
logic could be described as pseudo-static. It works just fine with
slow clocks.

Article: 150301
Subject: Re: OT: Fast Circuits
From: Michael S <already5chosen@yahoo.com>
Date: Sun, 9 Jan 2011 01:42:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 11:29=A0pm, MitchAlsup <MitchAl...@aol.com> wrote:
>
> A good decision based on the power envelope not letting the speed of
> dynamic logic to be utilized to its fullest.
>
> Mtich

What you are saying sounds right for quad and hexacores. But what
about duals?
Here is the fastest Westmere-based dual-core: http://ark.intel.com/Product.=
aspx?id=3D48504
73W at 3.6 GHz. Taking into account that same-generation hexacore runs
at 130W/3.3 GHz things do look either timing path limited or limited
by desire of the marketeers to avoid too big speed difference in favor
of cheaper part.


Article: 150302
Subject: Re: OT: Fast Circuits
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 9 Jan 2011 11:53:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Muzaffer Kal <kal@dspia.com> wrote:
(snip, I wrote)

>>The processors with built-in PLL can't be slow clocked, even if
>>the logic is static.
 
> What if the PLL is programmable and can be told to generate 
> a slow clock?

What do you mean by slow?

Unless one is allowed to supply an external capacitor, there is
no way to make a PLL go as slow as you can clock the Z80.

How about 1uHz? (or 1nHz or 1pHz?)

At 1GHz, you can make an RC circuit with R=1Mohm, C=1fF,
such that RC=1e-9s

For 1uHz, R=1Mohm, C=1F.  That isn't easy, even with an external
capacitor!

-- glen

Article: 150303
Subject: Re: OT: Fast Circuits
From: Michael S <already5chosen@yahoo.com>
Date: Sun, 9 Jan 2011 04:08:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 1:53=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga Muzaffer Kal <k...@dspia.com> wrote:
> (snip, I wrote)
>
> >>The processors with built-in PLL can't be slow clocked, even if
> >>the logic is static.
> > What if the PLL is programmable and can be told to generate
> > a slow clock?
>
> What do you mean by slow?
>
> Unless one is allowed to supply an external capacitor, there is
> no way to make a PLL go as slow as you can clock the Z80.
>
> How about 1uHz? (or 1nHz or 1pHz?)
>
> At 1GHz, you can make an RC circuit with R=3D1Mohm, C=3D1fF,
> such that RC=3D1e-9s
>
> For 1uHz, R=3D1Mohm, C=3D1F. =A0That isn't easy, even with an external
> capacitor!
>
> -- glen

I can imagine the utility of 1mHz, may be, even 0.1 mHz in some
extreme cases where you want to take a deep thought between the
clocks. But 1uHz? Can't see how it helps debugging.

Normally, when one needs very slow clock he gets it by dividing VCO
with counter. Today many off-the-shelf PLLs have counters built-in.
Although I have to admit that I never seen PLL with built-in counter
that was wide enough to produce 1mHz.

Article: 150304
Subject: Strange issue wih a very simple VHDL code and Spartan 3A Starter kit board
From: Francesco Da Riva <usenet@dariva.it>
Date: Sun, 9 Jan 2011 08:05:31 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi ALL,

    my name is Francesco Da Riva and I have recentely bought a Spartan
3A starter kit board.

    I have find a strange issue that i not be abble to solve. I
created a very simple greater  2 bit than comparator and connect it
with the switch and the led on the board.

   All work perfectelly a part of for the input  1001, the led should
be turn on but it is not.

   I try to simulate it on iSim and in simulation all work ok.

Could you help me?


Regards

Francesco Da Riva



VHDL CODE:



library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity gt2 is
    Port ( a : in  STD_LOGIC_VECTOR (1 downto 0);
           b : in  STD_LOGIC_VECTOR (1 downto 0);
              al : out STD_LOGIC_VECTOR (1 downto 0);
              bl : out  STD_LOGIC_VECTOR (1 downto 0);
           agtb : out  STD_LOGIC);
end gt2;

architecture sop_arch of gt2 is
    signal p0, p1, p2, p3, p4, p5 : std_logic;
begin
    agtb <= p0 or p1 or p2 or p3 or p4 or p5;
     al <= a;
     bl <= b;
     p0  <= (not a(1)) and a(0) and (not b(1)) and (not b(0));
     p1  <= a(1) and (not a(0)) and (not b(1)) and (not b(0));
     p2  <= a(1) and (not a(0)) and (not b(1)) and b(0);
     p3  <= a(1) and a(0) and (not b(1)) and (not b(0));
     p4  <= a(1) and a(0) and (not b(1)) and b(0);
     p5  <= a(1) and a(0) and b(1) and (not b(0));

end sop_arch;

CONSTRAINTS FILE




#========================================================
# buttons & switches
#========================================================
# 8 slide switches
NET "a<0>"  LOC = "T9" | IOSTANDARD = LVCMOS33;
NET "a<1>"  LOC = "U8" | IOSTANDARD = LVCMOS33;
NET "b<0>"  LOC = "U10" | IOSTANDARD = LVCMOS33;
NET "b<1>"  LOC = "V8" | IOSTANDARD = LVCMOS33;

#========================================================
# 8 discrete led
#========================================================
NET "agtb"  LOC = "R20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;

NET "al<0>"  LOC = "W21" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "al<1>"  LOC = "Y22" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<0>"  LOC = "V20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<1>"  LOC = "V19" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;




Article: 150305
Subject: Re: OT: Fast Circuits
From: MitchAlsup <MitchAlsup@aol.com>
Date: Sun, 9 Jan 2011 08:37:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 4:08=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga MitchAlsup <MitchAl...@aol.com> wrote:> On Jan 7, 8:38 =
pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
> > wrote:
> >> Intel fabs are often ahead of TSMC and UMC and GF. But this doesn't
> >> explain the whole difference, not by a long shot, especially given AMD=
's
> >> situation.
>
> (snip)
>
> > Note: excepting for RAMs and ROMs, there is almost no dynamic logic in
> > one of the x86 manufactures products. Dynamic logic is hard and takes
> > a lot more designers to get right (some of them in the FAB.) Dynamic
> > logic is sensitive to the process window swings. In many cases,
> > dynamic logic is not really faster once you consider not being able to
> > use the logic in the other 1/2 of the clock cycle and the added skew
> > on the falling edge of the clock.
>
> The 8080 and 8086 used dynamic logic. =A0(Possibly only for registers.)

I was talking about processor designed and FABed in the 2003-2010 time
frame, not made by that company over the entire life of that
architecture.

Yes all the old stuff used dynamic logic. In 2.5 micron single metal
process you had to use dynamic logic to even get the chip to fit in
the die. Times have changed.

Mitch
Mitch

Article: 150306
Subject: Re: OT: Fast Circuits
From: MitchAlsup <MitchAlsup@aol.com>
Date: Sun, 9 Jan 2011 08:39:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 3:42=A0am, Michael S <already5cho...@yahoo.com> wrote:
> On Jan 8, 11:29=A0pm, MitchAlsup <MitchAl...@aol.com> wrote:
>
>
>
> > A good decision based on the power envelope not letting the speed of
> > dynamic logic to be utilized to its fullest.
>
> > Mtich
>
> What you are saying sounds right for quad and hexacores. But what
> about duals?

Q: How could a company afford do another core design that would be
used in a dual processor?

A: They cannot. The dual is the same core as the quad, it just gets to
run in a more power rich environment.

Mitch

Article: 150307
Subject: Re: Strange issue wih a very simple VHDL code and Spartan 3A Starter
From: rickman <gnuarm@gmail.com>
Date: Sun, 9 Jan 2011 09:52:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 11:05=A0am, Francesco Da Riva <use...@dariva.it> wrote:
> Hi ALL,
>
> =A0 =A0 my name is Francesco Da Riva and I have recentely bought a Sparta=
n
> 3A starter kit board.
>
> =A0 =A0 I have find a strange issue that i not be abble to solve. I
> created a very simple greater =A02 bit than comparator and connect it
> with the switch and the led on the board.
>
> =A0 =A0All work perfectelly a part of for the input =A01001, the led shou=
ld
> be turn on but it is not.
>
> =A0 =A0I try to simulate it on iSim and in simulation all work ok.
>
> Could you help me?

The first thing you should do is to break the problem into smaller
pieces to try to isolate the problem.  Generally there are three areas
where your problem can lie, the input, the output or the processing.
You can effectively separate the I/O from the processing by connecting
one of the switches directly to the LED through the FPGA.  If you test
this with each of the four inputs and throwing the switches makes the
LED go on and off, then your problem is in the logic of the code.  If
the LED does not toggle with the switches, then you either have a
faulty switch or you have the I/O mapped to the wrong pins.

Any time you have a problem that you can't trace to a logic problem,
you need to simplify the situation to further isolate the bug.

Rick

Article: 150308
Subject: Re: Strange issue wih a very simple VHDL code and Spartan 3A Starter
From: Francesco Da Riva <usenet@dariva.it>
Date: Sun, 9 Jan 2011 11:18:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote:
> The first thing you should do is to break the problem into smaller
> pieces to try to isolate the problem.

I made this tests :
1)Connect each led to each swith, all work properly.
2)Try the same code on anther board, same issue.

> Any time you have a problem that you can't trace to a logic problem,
> you need to simplify the situation to further isolate the bug.

I agree with you but in this case I no be able to find any trouble in
each single piece of the puzzle.

Regards
   Francesco Da Riva

Article: 150309
Subject: Xilinx ML561 Schematics
From: mehdiru <mehdi@taileb.name>
Date: Sun, 9 Jan 2011 12:10:36 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,
I'm looking for the Xilinx ML561 schematics. Please share!

Thanks in advance

Article: 150310
Subject: Re: OT: Fast Circuits
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 09 Jan 2011 20:40:33 GMT
Links: << >>  << T >>  << A >>
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>In comp.arch.fpga Muzaffer Kal <kal@dspia.com> wrote:
>(snip, I wrote)
>
>>>The processors with built-in PLL can't be slow clocked, even if
>>>the logic is static.
> 
>> What if the PLL is programmable and can be told to generate 
>> a slow clock?
>
>What do you mean by slow?
>
>Unless one is allowed to supply an external capacitor, there is
>no way to make a PLL go as slow as you can clock the Z80.

Bypassing the PLL is a common trick / feature. Many modern processors
allow clocking through the JTAG interface for flash programming an
debugging purposes.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 150311
Subject: Re: Strange issue wih a very simple VHDL code and Spartan 3A Starter
From: rickman <gnuarm@gmail.com>
Date: Sun, 9 Jan 2011 13:31:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 2:18=A0pm, Francesco Da Riva <use...@dariva.it> wrote:
> On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote:
>
> > The first thing you should do is to break the problem into smaller
> > pieces to try to isolate the problem.
>
> I made this tests :
> 1)Connect each led to each swith, all work properly.
> 2)Try the same code on anther board, same issue.
>
> > Any time you have a problem that you can't trace to a logic problem,
> > you need to simplify the situation to further isolate the bug.
>
> I agree with you but in this case I no be able to find any trouble in
> each single piece of the puzzle.
>
> Regards
> =A0 =A0Francesco Da Riva

Sherlock Holmes says that "once you eliminate the impossible, whatever
remains, no matter how improbable, must be the truth".  The only thing
left is your logic.  You have a number of partial products in your
code.  Bring each of them out to the LEDs.  If they work ok, then
combine them again.  I don't know what the polarity of the LEDs are.
Did you try combinations of switches that would both make the LED
light and go out?

This is not magic.  But sometimes the solution is not obvious.  In
those cases you have to gather more information to know enough to
figure out the problem.

Rick

Article: 150312
Subject: Re: Low slewrate, abnormal current consumption.
From: malcolm <malcolm132@gmail.com>
Date: Sun, 9 Jan 2011 14:07:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 8, 5:50=A0am, Muzaffer Kal <k...@dspia.com> wrote:
> On Fri, 07 Jan 2011 07:24:21 -0600, "karl.bengtsson"
>
>
>
> <karl.bengtsson@n_o_s_p_a_m.norspace.no> wrote:
> >Hello.
>
> >I have a design targeting the (ancient, perhaps) Actel A54SX32A. During
> >testing I exposed several of the input pins to signals with extremly low
> >slewrate, using a power-supply to supply the input. This was most likely
> >way outside the minimum slewrate requrements for the device.
>
> >The FPGA seems to be working and it passes all functional tests, but the
> >current to the core is way to large at about 70mA. Sadly, I did not meas=
ure
> >the current beforehand and the cost of a new (ceramic) FPGA prohibits me
> >from just burning a new one to test that. A freshly burned plastic FPGA
> >works fine and consumes the expected current.
>
> >Does anyone have any experience with destroying FPGAs due to low slewrat=
es?
> >Is this even probable?
>
> CMOS structures are push-pull ie they have two switches which
> "simultanenously" turn-on/off to change state; alas the switching is
> never instantenous so there is overlap so dynamic current flows during
> the switch. The worst case current is near the middle voltage level,
> the longer you stay around that point the higher the average current.
> It's possible to destroy individual IOs by leaving unconnected inputs
> and letting them float. Your case is not as extreme but would affect
> lifetime of the IO.

 Which part numbers have you actually seen this occur on ?

 Your explanation is correct, that there is a Icc peak (or double Icc
peak on a Schmitt pin), but that is usually in the sub mA region, and
so will struggle to generate more than 1mW of heating in each FET.

 eg look at NXP 74AUP2T1326, which gives a classic schmitt Icc plot,
twin peaks at 150uA & 200uA, 1.8V testcase.

 A NXP 74LVU04 shows over 200uA @ 1.2V and > 1mA @3V, but that if for
Output Drive fets, (~ 40 ohms)

 Another Digital-Pin effect, is not the current of a linear buffer,
but the  parasitic transition oscillations that can occur, when there
is no hysteresis, and a multiple buffers hit the 'linear' region.

  I have seen the chip-wide effects of that, yield high Icc levels,
and also give 'crosstalk' effects, where supposedly logically
independent pathways, jitter as a result of this. (common mode
inductance).
 This would (over?) heat a larger portion of the chip.

 So the advice is don't float (non schmitt) pins, but has anyone seen
physical/permanent damage/degrade from these effects ?

-jg


Article: 150313
Subject: Re: Strange issue wih a very simple VHDL code and Spartan 3A Starter
From: Francesco Da Riva <usenet@dariva.it>
Date: Sun, 9 Jan 2011 14:25:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On 9 Gen, 22:31, rickman <gnu...@gmail.com> wrote:
> On Jan 9, 2:18=A0pm, Francesco Da Riva <use...@dariva.it> wrote:
>
>
>
> > On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote:
>
> > > The first thing you should do is to break the problem into smaller
> > > pieces to try to isolate the problem.
>
> > I made this tests :
> > 1)Connect each led to each swith, all work properly.
> > 2)Try the same code on anther board, same issue.
>
> > > Any time you have a problem that you can't trace to a logic problem,
> > > you need to simplify the situation to further isolate the bug.
>
> > I agree with you but in this case I no be able to find any trouble in
> > each single piece of the puzzle.
>
> > Regards
> > =A0 =A0Francesco Da Riva
>
> Sherlock Holmes says that "once you eliminate the impossible, whatever
> remains, no matter how improbable, must be the truth".

:-)

>=A0The only thing left is your logic.

But in simulation the wave form work ok for any Input combination.

 =A0I don't know what the polarity of the LEDs are.
> Did you try combinations of switches that would both make the LED
> light and go out?

All combination work properly instead of 1001 combination.
In my code is the p2 signal.

Regards
   Francesco


Article: 150314
Subject: Re: OT: Fast Circuits
From: Del Cecchi <delcecchi@gmail.com>
Date: Sun, 09 Jan 2011 21:16:17 -0600
Links: << >>  << T >>  << A >>
On 1/7/2011 8:38 PM, Andy "Krazy" Glew wrote:
snip
>
> Intel fabs are often ahead of TSMC and UMC and GF. But this doesn't
> explain the whole difference, not by a long shot, especially given AMD's
> situation.
>
> By the way, an interesting conversation is why IBM is above 5GHz,
> whereas Intel is not.
>
>
snip

My first guess would be that SOI had something to do with it.  Second 
would be packaging and higher power budget.  Third might be because it 
was a no holds barred high end design while Intel had other constraints.

Don't know for sure.
And I know that there are differences of opinion about SOI and its 
leverage at various process nodes.

-- 
del

Article: 150315
Subject: Re: Strange issue wih a very simple VHDL code and Spartan 3A Starter
From: rickman <gnuarm@gmail.com>
Date: Sun, 9 Jan 2011 20:18:47 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 9, 5:25=A0pm, Francesco Da Riva <use...@dariva.it> wrote:
> On 9 Gen, 22:31, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Jan 9, 2:18=A0pm, Francesco Da Riva <use...@dariva.it> wrote:
>
> > > On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote:
>
> > > > The first thing you should do is to break the problem into smaller
> > > > pieces to try to isolate the problem.
>
> > > I made this tests :
> > > 1)Connect each led to each swith, all work properly.
> > > 2)Try the same code on anther board, same issue.
>
> > > > Any time you have a problem that you can't trace to a logic problem=
,
> > > > you need to simplify the situation to further isolate the bug.
>
> > > I agree with you but in this case I no be able to find any trouble in
> > > each single piece of the puzzle.
>
> > > Regards
> > > =A0 =A0Francesco Da Riva
>
> > Sherlock Holmes says that "once you eliminate the impossible, whatever
> > remains, no matter how improbable, must be the truth".
>
> :-)
>
> >=A0The only thing left is your logic.
>
> But in simulation the wave form work ok for any Input combination.
>
> =A0=A0I don't know what the polarity of the LEDs are.

If you don't know the polarity, how do you know when it should be on
vs off?


> > Did you try combinations of switches that would both make the LED
> > light and go out?
>
> All combination work properly instead of 1001 combination.
> In my code is the p2 signal.

I think you are saying that you have been able to activate p0, p1, p3,
p4, p5 and the LED lights up?  When you input the other nine
combinations, is the LED off?  If one of those causes the LED to
light, there is something wrong with your assumptions.

I see you pass the switch inputs back out of the chip.  I assume each
of those drives an LED that lights when you expect it to?

There is something wrong, either with your circuit or your
assumptions.  Keep tearing it apart until you find something wrong you
can put your finger on.


I think the hardest debug I've ever done was this past summer.  The
design was only a little complex, but I had a few bugs that had gotten
past simulation.  These were all found in testing with my customer.
Finally we had one problem that defied logic.  Because it shouldn't
have been happening, it was very hard to add debug code to try to
figure out what the problem was.  I went by the customer's site at
least twice a week for a couple of weeks and was making no ground.  In
the third week I had some heavy duty code inserted into the design and
found that the PLL was acting as if it had not been initialized.  We
had already gone over the initialization a couple of times and I
verified that he was doing it right... or so I thought.  Turns out
even though we had gone over it at least twice, he had not done one
step that loaded the registers in the PLL.

The point is, when debugging, challenge all of your assumptions.

Rick

Article: 150316
Subject: Re: Strange issue wih a very simple VHDL code and Spartan 3A Starter
From: malcolm <malcolm132@gmail.com>
Date: Sun, 9 Jan 2011 23:03:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 10, 5:05 am, Francesco Da Riva <use...@dariva.it> wrote:
> Hi ALL,
>
>     my name is Francesco Da Riva and I have recentely bought a Spartan
> 3A starter kit board.
>
>     I have find a strange issue that i not be abble to solve. I
> created a very simple greater  2 bit than comparator and connect it
> with the switch and the led on the board.
>
>    All work perfectelly a part of for the input  1001, the led should
> be turn on but it is not.

Look at the report files, and check the reduced logic
(try more than one target)

Should be along the lines of this

agtb = ((!b_1 & a_1)
	# (a_0 & !b_0 & a_1)
	# (a_0 & !b_0 & !b_1));

If it sims, this has high probability of being what you see.

Next, draw a table of ALL the bench-test values,  (as here you do not
have many) - then work backwards to see what has dropped, or been miss-
mapped.

 My guess is, you have a_1, a_0 swapped, and you forgot to test all
the expected-negative cases as well ? ;)

-jg

Article: 150317
Subject: Re: Low slewrate, abnormal current consumption.
From: "karl.bengtsson" <karl.bengtsson@n_o_s_p_a_m.n_o_s_p_a_m.norspace.no>
Date: Mon, 10 Jan 2011 01:53:10 -0600
Links: << >>  << T >>  << A >>
> Which part numbers have you actually seen this occur on ?
>

My device is an A54SX32SA-208CQFP. A freshly burned A54SX32SA-208PQFP shows
normal current consumption.

I understand how leaving the voltage at an incorrect level will cause
current to flow in the input, which could cause excessive heating.

But how would this translate into an permanent increase in current on the
core supply?

Some additional findings. I desoldered (well, someone did it for me) the
VCCA pins of the FPGA to see if there where any difference between them. I
then connected them one-by-one and looked at the current delivered. A few
of the pins showed a stable, high, current consumption. While a couple of
others varied wildly for a few seconds before settling to the same, high,
current consumption.
I have no idea if this tells anyone anything, but I felt it was worth
noting.

Anyhow, thanks everyone for the replies so far! :)


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150318
Subject: Re: Error in Clock Divider!
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Mon, 10 Jan 2011 10:02:16 +0100
Links: << >>  << T >>  << A >>
Alright, I admit changing the name of the entity after pasting, cause the 
original name was not related to the function.
Also, what is missing in your attempt is:
use ieee.std_logic_unsigned.all;
Which I assumed was very common and didn't include. Sorry for that.


"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:872e6dca-2257-432c-95b7-1fc9ab2a0b09@m37g2000vbn.googlegroups.com...
On Jan 7, 4:07 am, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote:

> >> The code below is some tested and implemented code I found on my drive.
>
> NO, ieee.std_logic_arith.all was not in my code. Did you try it?
>

Yes, I did...apparently you did not, even though you called it "tested
and implemented code I found on my drive".

Quartus 10.0 SP1 reports the following error on the statement
"testcnt<=testcnt+"1"; "
Error (10327): VHDL error at Junk.vhd(341): can't determine definition
of operator ""+"" -- found 0 possible definitions

Modelsim 6.4 reports the following (as I mentioned in the first post)
No feasible entries for infix operator "+".

But before you get those errors, you'll have to clean up another error
because you used the name 'test' as the name of the entity and as a
signal.

     architecture rtl of test is
     ...
     test<='0';

As I suggested in my first post, you might want to try out your code
first before posting.

KJ 



Article: 150319
Subject: Re: Low slewrate, abnormal current consumption.
From: malcolm <malcolm132@gmail.com>
Date: Mon, 10 Jan 2011 02:07:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 10, 8:53=A0pm, "karl.bengtsson"
> But how would this translate into an permanent increase in current on the
> core supply?
>
> Some additional findings. I desoldered (well, someone did it for me) the
> VCCA pins of the FPGA to see if there where any difference between them. =
I
> then connected them one-by-one and looked at the current delivered. A few
> of the pins showed a stable, high, current consumption. While a couple of
> others varied wildly for a few seconds before settling to the same, high,
> current consumption.

So you are saying the device(s?) work ok, but just have higher
currents ?
Are you also saying that higher Icc, is evenly spread over Banks, even
with no floating pins and a static clock ?

-jg


Article: 150320
Subject: Re: Low slewrate, abnormal current consumption.
From: F M <fmont67@gmail.com>
Date: Mon, 10 Jan 2011 02:47:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 10, 8:53=A0am, "karl.bengtsson"
<karl.bengtsson@n_o_s_p_a_m.n_o_s_p_a_m.norspace.no> wrote:
> > Which part numbers have you actually seen this occur on ?
>
> My device is an A54SX32SA-208CQFP. A freshly burned A54SX32SA-208PQFP sho=
ws
> normal current consumption.
>
> I understand how leaving the voltage at an incorrect level will cause
> current to flow in the input, which could cause excessive heating.
>
> But how would this translate into an permanent increase in current on the
> core supply?
>
> Some additional findings. I desoldered (well, someone did it for me) the
> VCCA pins of the FPGA to see if there where any difference between them. =
I
> then connected them one-by-one and looked at the current delivered. A few
> of the pins showed a stable, high, current consumption. While a couple of
> others varied wildly for a few seconds before settling to the same, high,
> current consumption.
> I have no idea if this tells anyone anything, but I felt it was worth
> noting.
>
> Anyhow, thanks everyone for the replies so far! :)
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

It looks like that part was irradiated by particles during a test
beam.
This is a OTP FPGA. That Actel's family is used in the satellites/
rockets/airplane as also in particle physics experiments  and usually
are submitted to radiation test.
After radiation, one major TID effect is an augment of leakage current
in CMOS that is what you observe.

So the question are:
where this Ic come from ?
Could it been irradiated ?

It is only a hypothesis but it is better to have care in managing that
part.

Fabio

Article: 150321
Subject: Re: Strange issue wih a very simple VHDL code and Spartan 3A Starter
From: Francesco Da Riva <usenet@dariva.it>
Date: Mon, 10 Jan 2011 05:48:31 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi All!!!

   I found it!!!

    I test with this architecture

architecture boolean_arch of gt2 is
begin
    agtb <= '1' when a>b else '0';
     al <= a;
     bl <= b;
end boolean_arch;


but the problem remian identical so I cheked the UCF file and find the
problem!!!

I mapped the switch bad, with the MSB on the right side :-)

This is the right UCF:

========================================================
# buttons & switches
#========================================================
# 8 slide switches
NET "a<1>" LOC = "T9" | IOSTANDARD = LVCMOS33;
NET "a<0>"  LOC = "U8" | IOSTANDARD = LVCMOS33;
NET "b<1>"  LOC = "U10" | IOSTANDARD = LVCMOS33;
NET "b<0>"  LOC = "V8" | IOSTANDARD = LVCMOS33;

#========================================================
# 8 discrete led
#========================================================
NET "agtb"  LOC = "R20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;

NET "al<1>"  LOC = "W21" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "al<0>"  LOC = "Y22" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<1>"  LOC = "V20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<0>"  LOC = "V19" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;


Thanks to all for the support


Regards

  Francesco Da Riva

Article: 150322
Subject: FPGA to PHY/MAC chip
From: "buddylee9898" <andrewludwig1@n_o_s_p_a_m.gmail.com>
Date: Mon, 10 Jan 2011 10:19:23 -0600
Links: << >>  << T >>  << A >>
Hello everyone, I have recently begun a project in which I would like to
add an Ethernet interface to my spartan-3e FPGA allowing it to receive
commands from one of two computers on a local network. Currently, I am
using the Digilent Basys 2 starter board along with the pmod Ethernet NIC
offered by Digilent. This pmod contains a PHY/MAC chip with an SPI
interface. 

My question relates to the needed coding on the FPGA. I have been searching
around and found that many people use Microblaze to simulate a
microprocessor on the FPGA, however I am largely unfamiliar with this and
was wondering if there was a way to use straight VHDL to simply receive
data from the PHY/MAC chip? From my understanding my device will not need
to use IP since I have no need to send data over the internet so I could
technically treat the PHY/MAC chip as a memory register that I would read
and write to, correct? Thank you in advance. 

-Andrew

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150323
Subject: Re: FPGA to PHY/MAC chip
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 10 Jan 2011 08:38:19 -0800
Links: << >>  << T >>  << A >>
On 01/10/2011 08:19 AM, buddylee9898 wrote:
> Hello everyone, I have recently begun a project in which I would like to
> add an Ethernet interface to my spartan-3e FPGA allowing it to receive
> commands from one of two computers on a local network. Currently, I am
> using the Digilent Basys 2 starter board along with the pmod Ethernet NIC
> offered by Digilent. This pmod contains a PHY/MAC chip with an SPI
> interface.
>
> My question relates to the needed coding on the FPGA. I have been searching
> around and found that many people use Microblaze to simulate a
> microprocessor on the FPGA, however I am largely unfamiliar with this and
> was wondering if there was a way to use straight VHDL to simply receive
> data from the PHY/MAC chip? From my understanding my device will not need
> to use IP since I have no need to send data over the internet so I could
> technically treat the PHY/MAC chip as a memory register that I would read
> and write to, correct? Thank you in advance.

How much parsing will you need to do of the information from the 
PHY/MAC?  If you just need to do some setup, then read from one memory 
location over and over (which means that you'd be using low-level 
Ethernet in some exceedingly simple fashion) then -- maybe.

I'm not an  FPGA whiz, but I've done a bit of work in them.  Both times 
the problem said "processor", but the customer said "no processor".  You 
end up with these gawdaful state machines that grow without bound, have 
lots of synthesis gotchas (at least when I do them), and as a 
consequence are maintenance nightmares.  At least when I do them I end 
up with more lines of HDL than I would of assembly code to do it on a 
processor.  Perhaps a better man than I could make these work and be 
maintainable -- but perhaps a better man than I could just convince the 
customer that yes, a processor is really what's needed.

Were it me I would hesitate to make the mistake _again_, and I'd figure 
that the up-front work of figuring out how to shove a processor in there 
is going to be less than the subsequent work of maintaining a 
processor-less nightmare of my own creation.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 150324
Subject: Re: Low slewrate, abnormal current consumption.
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Mon, 10 Jan 2011 08:39:09 -0800 (PST)
Links: << >>  << T >>  << A >>
On 10 Jan., 11:47, F M <fmon...@gmail.com> wrote:
> On Jan 10, 8:53=A0am, "karl.bengtsson"
>
>
>
> <karl.bengtsson@n_o_s_p_a_m.n_o_s_p_a_m.norspace.no> wrote:
> > > Which part numbers have you actually seen this occur on ?
>
> > My device is an A54SX32SA-208CQFP. A freshly burned A54SX32SA-208PQFP s=
hows
> > normal current consumption.
>
> > I understand how leaving the voltage at an incorrect level will cause
> > current to flow in the input, which could cause excessive heating.
>
> > But how would this translate into an permanent increase in current on t=
he
> > core supply?
>
> > Some additional findings. I desoldered (well, someone did it for me) th=
e
> > VCCA pins of the FPGA to see if there where any difference between them=
. I
> > then connected them one-by-one and looked at the current delivered. A f=
ew
> > of the pins showed a stable, high, current consumption. While a couple =
of
> > others varied wildly for a few seconds before settling to the same, hig=
h,
> > current consumption.
> > I have no idea if this tells anyone anything, but I felt it was worth
> > noting.
>
> > Anyhow, thanks everyone for the replies so far! :)
>
> > --------------------------------------- =A0 =A0 =A0 =A0
> > Posted throughhttp://www.FPGARelated.com
>
> It looks like that part was irradiated by particles during a test
> beam.
> This is a OTP FPGA. That Actel's family is used in the satellites/
> rockets/airplane as also in particle physics experiments =A0and usually
> are submitted to radiation test.
> After radiation, one major TID effect is an augment of leakage current
> in CMOS that is what you observe.
>
> So the question are:
> where this Ic come from ?
> Could it been irradiated ?
>
> It is only a hypothesis but it is better to have care in managing that
> part.

The A54xxx is the commercial device without radiation hardening. Would
not expect any irradiation of this device expecially not in device
screening process, as rad tests are not part of device screening only
qualification (means the design is irradiated, not the delivered
device). Screening should only cover a burn-in for each device (normal
for a RT54 device, don't know if some mil flow covers burn-in).

For the RT54SXxxS devices from MEC there was an issue with inrush
during power cycling. Don't know if commercial device could have the
same issue as it is different silicon with AFAIK different process
than RT device.

bye Thomas



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