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 116425

Article: 116425
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 08 Mar 2007 12:41:53 -0800
Links: << >>  << T >>  << A >>
Austin Lesea wrote:


> I agree that a slit in the ground plane is going to be an impedance
> discontinuity for signals that cross the split.

> For that reason, I would probably have any signals that cross the split
> have a continuous ground underneath them.  That little bit of ground
> that now connects the "isolated" ground plane to the rest of the ground
> plane is also a DC short across the NEC-Tokin device, but from an AC
> traveling wave point of view, it is an open, as the power and ground
> currents return to the power supply, and are unlikely to return over a
> small bridge between two planes.

My first thought on your previous post on split power planes, and
considering them as transmission lines, is that you can distribute
the effect of the clock transitions back to the power supply.

If you have multiple FPGAs on a board, all clocked at the same
time, but with different length low impedance transmission lines
to the power supply, (bypass capacitors), you distribute the effect
of those capacitors.   Then again, you should be able to
get a similar effect with different clock delays.

If you have a split ground plane it would seem that the signal
lines should go around, and not cross the split.

-- glen


Article: 116426
Subject: Re: Multiplication operation
From: "Paul" <pauljbennett@gmail.com>
Date: 8 Mar 2007 12:46:25 -0800
Links: << >>  << T >>  << A >>
The problem with "the synthesizer should be able to figure it out"
comments that keep being thrown around here is that that violates the
entire purpose of VHDL.  VHDL was intended to be a VERY strongly
type'ed language.  Which is why (std_logic_vector) * (floating point)
is not defined in any standard IEEE library.  This is precisely the
constraint that makes your synthesis results reliable.  Whether the
programmers gone hardware designers in the group like it or not,
writing VHDL is designing hardware.  If you write VHDL with no regard
for the hardware that will be built from it, and violate basic design
rules, you WILL encounter problems - particularly if you try to get
anywhere near the upper speed limit of the part you're designing.

That being said... if you know how you want your multipliers/dividers
to be built, I would recommend writing a library to do what you want.
Once you define the function "SLV * FLOAT" in a library, you can write
statements like that until your heart's content AND be confident in
how it will be built because you designed the library.


On Mar 4, 3:47 pm, "Peter Alfke" <a...@sbcglobal.net> wrote:
> Matthew let me argue for peace:
> It all depends on your roots.
> If you started out as a logic designer (like I did), then you see the
> FPGA as a wonderful way to design a production-worthy breadboard of
> terrific complexity and very good performance. God's gift to the logic
> designer, good-bye wire-wrap!
> I think in terms of block diagrams, and use VHDL/Verilog to manage the
> design process. I would never be in doubt about the choice of binary
> vs decimal, or fixed vs floating point, because they have such
> enenormous impact on the design efficiency.
>
> If you start out as a computer programmer, then you design=program the
> way this thread was started, totally oblivious of hardware constraints
> and limittions. Let the synthesizer worry about those details! The
> trouble is that these unworthy details can impact the design by an
> order of magnitude in size=cost and performance.
>
> You will never beat the urge for economy, performance, and design
> elegance out of us hardware guys. Maybe one day FPGAs will become so
> big and cheap and fast that it does not matter anymore.
> Well, hopefully there will always be Social Security.
> And St. Peter might show mercy with us former pip-pokers genus
> schemato-saurus.
> Peter Alfke
>
> On Mar 4, 12:12 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
>
>
>
> > First, to address the question, you're not really doing multiplication but
> > performing division through multiplication with decimals.  ISE doesn't do
> > division either way.  Like John_H said, scale your numbers up (refer to fixed
> > point numbers) so multiplication is done with integers.  When done, just
> > scale the result down by the same amount for the final answer.  A hint is
> > to scale the numbers by a power of 2 so you just have to do bit shifts.
>
> > Second, I would like to give my two cents on John_H's 1990's attitude.  You
> > shouldn't tell someone to read up on vendor specific blocks when it is clear
> > that they are just starting out, doesn't need an optimal implementation,
> > and don't have a firm grasp on the basics.  You should give them a very simple
> > and concise explanation at their level and a fix at their level.  The synthesizer
> > is more than capable of handling the * symbol, the OP doesn't need to worry
> > about what Xilinx puts on the hood.  If Xilinx were smart and had good programmers,
> > which it seems they are trying to work towards, no one would need to know
> > of any of the blocks under the hood.  People should be able to "program"
> > the hardware.  The synthesis program should be smart enough to use the blocks
> > under the hood to provide a near optimal implementation of the "program".
> >  There is a reason why people use high level programming languages not assembly.
> >  For everyone's sake, "designing" a system on an FPGA shouldn't be hard.
>
> > ---Matthew Hicks
>
> > > VHDL_HELP wrote:
>
> > >> Hi every body ,
> > >> i hope that you can help me , i want to do this operation:
> > >> s = c1 * 0.2+ c2 * 0.6 + c3 * 0.1
> > >> when i check the syntax , i have these errors
> > >> ERROR:HDLParsers:808 - "C:/Xilinx/projet/operation.vhd" Line 44. *
> > >> can
> > >> not have such operands in this context.
> > >> ---------------------------------------------------------------------
> > >> ---------------------------------------------------------------------
> > >> ----------------------
>
> > >> library IEEE;
>
> > >> use IEEE.STD_LOGIC_1164.ALL;
>
> > >> use IEEE.STD_LOGIC_ARITH.ALL;
>
> > >> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> > >> entity operation is
> > >> Port ( clk : in  STD_LOGIC;
> > >> c1 : in  STD_LOGIC_VECTOR (7 downto 0);
> > >> c2 : in  STD_LOGIC_VECTOR (7 downto 0);
> > >> c 3: in  STD_LOGIC_VECTOR (7 downto 0);
> > >> s: out  STD_LOGIC_VECTOR (7 downto 0);
> > >> end operation;
>
> > >> architecture Behavioral of operation is
>
> > >> begin
>
> > >> s <=c1 * 0.2 + c2 * 0.6 + c3 * 0.1 ;
>
> > >> end Behavioral;
>
> > >> ---------------------------------------------------------------------
> > >> ---------------------------------------------------------------------
> > >> ----------------
>
> > >> and thanks for your help
>
> > > Can you tell me how the synthesizer will format your floating point
> > > result in s so it maps to silicon?
>
> > > Use scaled integers.  Use the precision available in the hardware
> > > multipliers to get a rather precise approximation of s.  The digital
> > > realm is binary, after all, not decimal.
>
> > > Please read up on how the hardware multipliers perform and how best to
> > > utilize them.  It's insanely sad to see someone trying to "program" an
> > > FPGA rather than design it.- Hide quoted text -
>
> - Show quoted text -



Article: 116427
Subject: Re: Spartan3AN - Roadmap
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 09 Mar 2007 10:00:36 +1300
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> I do recall certain Xilinx representatives saying something like "on-
> board configuration memory means that we'll have to use an older
> process, meaning slower, more power-hungry parts, yadda yadda
> yadda."

That was refering to same-die configuration; the process constraints
go away then you deploy 2 die in one package, which is what Xilinx have
done.

Some companies simply wire bond the second die in a spare area, in
BGA that's easy - just design the BGA paddle & pgm the bonding machine.


Others are working on flip-chip bump bonding, where the die is designed 
  to take the daughter chip, and the bonding costs drop (not just $, but 
area/height costs too ) and you can get a lot of contacts going between 
the die.
If you are already doing flip-chip onto the BGA, to get die-wide bond 
pads, and lower nH, then it's somewhat harder to find a place to put the 
second memory die .....

-jg


Article: 116428
Subject: Re: Driving PLL from general I/O in Altera Cyclone
From: "Will Dean" <will@nospam.demon.co.uk>
Date: Thu, 8 Mar 2007 21:12:39 -0000
Links: << >>  << T >>  << A >>
"nfirtaps" <lloyd.rochester@gmail.com> wrote in message 
news:1173383894.763347.110110@64g2000cwx.googlegroups.com...
>
> 1.) Can I somehow drive a PLL with a general purpose I/O

I don't think so.  I'm using Cyclone II at the moment and I'm 99.9% sure you 
can't feed the PLLs with anything except one of the 'clock input' pins. 
(These can also be general purpose input pins, so I would always recommend 
connecting anything vaguely 'clock-like' to one of those pins, even if you 
think you might not actually use it as a clock.)

> 2.) Is there another way of deserializing the DDR signal.

You don't say anything about frequency, but I'd be inclined just to sample 
on the falling edge as well, and then shift the two bits (+ve edge and -ve 
edge) into your shift register on the next +ve clock.

> Currently I have a the DDR clock coming in my fpga and I not the clock
> so I can sample the DDR signal on the rising egde.

Is that giving you a problem?

Will




Article: 116429
Subject: Re: V.34 Modem IP core
From: Eric Smith <eric@brouhaha.com>
Date: 08 Mar 2007 13:38:56 -0800
Links: << >>  << T >>  << A >>
GX wrote:
> any IP vendor out there who supply hard/soft core for V.34Modem?

I wrote:
> V.34 is normally (probably always) implemented in software.  You could
> put any DSP core (or RISC core with DSP capability) into your FPGA or
> ASIC, and run a V.34 implementation on it.

GX wrote:
> Thanks for your response.
> 
> After googling, I have found lot of Single chip Modem ASICs.
> like, MN195006 from Panasonic.
> 
> Did anyone integrated the functional equivalent of these single chip
> modem chip in to FPGA/ASIC/SoC?

The answer is still the same.  The MN195006 is almost certainly a
mask programmed DSP, or perhaps an ASIC containing a DSP core and ROM.

You can certainly put a DSP core into an FPGA, but there's not likely
to be enough block RAM for all the code for V.34, so you'll need
external memory.  In an ASIC, it's possible to integrate the whole
thing, as the MN195006 shows.

If the MN195006 does what you need, you're almost certainly better
off buying that and interfacing it to your own design, than trying
to integrate a modem yourself.  Unless you expect volumes well
over 100K units, the integrated approach will be significantly more
expensive.

If you really think you want to do it, there are companies out there
that will be happy to sell you a license for a V.34 software
implementation, which you can then use in your FPGA or ASIC.  Do a
Google search for "v.34 soft modem" and several turn up.

Eric

Article: 116430
Subject: Xilinx Spartan DCM jitter spectrum
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 08 Mar 2007 22:04:47 GMT
Links: << >>  << T >>  << A >>
Hello all,
Does anyone has some numbers on the frequency spectrum of the jitter
from a DCM? The datasheet says the DCM has a jitter of 100ps but I
would like to know a bit more about the spectrum to determine whether
or not the clock from a DCM is usefull for sampling.


-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 116431
Subject: Re: Avnet Virtex-4 FX12 mini module
From: "davide" <davide@xilinx.com>
Date: Thu, 8 Mar 2007 14:09:32 -0800
Links: << >>  << T >>  << A >>
Don't forget to check out XAPP's 434 and 443:
http://www.xilinx.com/bvdocs/appnotes/xapp434.pdf
http://www.xilinx.com/bvdocs/appnotes/xapp443.pdf

The reference designs here might be just what you are looking for.


"Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message 
news:espn0e$g9h$1@news.lysator.liu.se...
> On 2007-03-08, jrabbani@gmail.com <jrabbani@gmail.com> wrote:
>> Ok. I will try to get the data sheet this way. In the meantime, can
>> you suggest the easiest way of establishing the Gigabit etherner
>> connectivity between the FPGA and the host PC. I need speed in excess
>> of 50 Megabytes / Sec. Should I go the EDk way or to try the verilog
>> side. I have Virtex-4 FX so it has extensive support for Gigabit
>> ethernet. Thanks.
>
>
> It depends on what kind of application/data we are talking about.
> It is for example not that hard to send UDP data to a static IP address
> using a hardcoded MAC address in your design. The dataflow could be
> something like the following:
>
> Data in -->   FIFO   --> Add UDP/IP header --> Asynchronous FIFO -->
> --> CRC generator --> Ethernet PHY
>
> This setup should work well if you have a fast PC connected to your
> design either directly or through a switch. However, you should be
> prepared to lose a few packets here if your PC is not fast enough or
> does not allocate enough buffer space for UDP packets coming in at 50
> MB/s. However, if you need something like TCP/IP or the ability to
> buffer data in an off-chip memory and send it to the PC on demand, you
> are facing a tougher problem. In this case it is probably worth to
> investigate what the EDK has to offer.
>
>
> If you are going the first route I would suggest that you look at the
> following lab exercise which has some good information (only for
> 10/100 Mb/s Ethernet but the only difference is that you are typically
> using 8 wires for data to a gigabit Ethernet PHY instead of 4):
>
> http://www.sm.luth.se/~maglun/lab33/lab33.pdf and
> http://www.sm.luth.se/~maglun/lab33/
>
> In particular, they have an explanation of the Ethernet CRC and a
> couple of example CRC:s which is very valuable when you are trying to
> send an Ethernet packet through your own CRC generator.
>
>
> /Andreas 



Article: 116432
Subject: Re: VHDL and Latch
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 8 Mar 2007 14:16:15 -0800
Links: << >>  << T >>  << A >>
On Mar 8, 11:36 am, "Weng Tianxiang" <wtx...@gmail.com> wrote:
> On Mar 7, 3:02 am, "KJ" <kkjenni...@sbcglobal.net> wrote:
>
>
>
>
>
> > "Weng Tianxiang" <wtx...@gmail.com> wrote in message
>
> >news:1173237015.878201.302510@p10g2000cwp.googlegroups.com...> 1. Q <= (C and D) or (not(C) and Q);
> > > I have never seen such equation in my coding experiences and have no
> > > idea how this equation would be written. The logic result is beyond a
> > > reason. Could you please write it in equivalent latch equation in
> > > informal VHDL?
>
> > It's the same old transparent latch that we've been talking about all along.
> > The following forms are exactly equivalent logic and will result in the
> > exact same synthesized result.
> > #1 -- Traditional form of writing a latch
> > process(C, D)
> > begin
> > if (C='1') then
> >    Q <= D;
> > end if;
> > end process;
>
> > #2 -- Another traditional form of writing a latch.
> > Q <= D when (C = '1');
>
> > #3 -- Latch equations written as a sum of products
> > Q <= (C and D) or (not(C) and Q);
>
> > #4 -- Latch equation written in a sum of products form that includes a
> > 'cover' term
> > Q <= (C and D) or (not(C) and Q) or (D and Q);
>
> > Try all four of the above out and run them through synthesis and you should
> > get the exact same fitted equations for all 4.
>
> > Of the four different forms, only #4 is written in a way that will not have
> > timing issues that are caused simply by the implementation (over which you
> > have no real control in an FPGA).  However, the last term ".. or (D and Q)"
> > is redundant and any synthesizer worth a dime will 'optomize the logic' and
> > implement it as form #3.  This 'optomization' though creates a logic hazard
> > when 'C' switches from '1' to '0'.  This logic hazard will in turn show up
> > as a failure in the latch operation.  Specifically, what you'll run into is
> > that even if you have 'D' set up oodles of time before 'C' switches from '1'
> > to '0', the output 'Q' can latch itself at either '1' or '0' (depending on
> > the targetted part) because of differences in prop delay in computing the
> > first two or terms or glitches in 'C'.  That last "D and Q" term is
> > absolutely required in order to even have a shot at inferring a latch that
> > will actually work but since it is logically 'redundant' it will always get
> > optomized away.  If you hark back to Boolean Logic 101, you may recall that
> > adding redundant terms is the method you employ to get rid of logic hazards.
> > The FPGA LUT implementation leaves even more to the imagination as you
> > wonder just what those RAM outputs are doing with this combinatorial loop
> > and whether 'Q' will glitch and cause even more havoc since it would feed
> > back to the address input of the LUT.
>
> > The bottom line is
> > - There are various forms of writing source code that infers a latch.
> > - Whether a latch is a 'good' thing or a 'bad' thing depends on the
> > targetted device itself and whether that device actually has a hard latch
> > and a way to guarantee the timing and glitch requirements of 'D' and 'C'.
> > - Inferring any storage element (flops, latches, memory) needs to be done in
> > such a way that the storage is not implemented as a collection of
> > LUTs/macrocells but instead uses hard storage resources of the device.
>
> > > 2. FPGA of Xilinx chip really has latch primative and one may use it
> > > using latch primative to call it. But it is hard to refer to it in
> > > VHDL.
>
> > You'll still have trouble meeting and guaranteeing the timing and glitch
> > requirements on 'D' relative to 'C' in order to get it to work correctly for
> > arbitrary signals 'D' and 'C'.  If it does work, it likely won't scale well
> > (i.e. if you try to infer thousands of these as you would like to)
>
> > > I don't mean VHDL should have included latch statement, what I
> > > mean is VHDL really lacks the statement element to refer to a latch in
> > > a clear and reliable way and the lack can be easily corrected.
>
> > I've shown above four different forms for inferring the exact same latch
> > (i.e. synthesizes to the exact same thing).  Which form you prefer (or if
> > you prefer to make up your own) to use is up to you.  Making up a new method
> > though will not prohibit the earlier forms from being used and outlawing the
> > other forms gets in the way of people who do use latches and are doing so in
> > a way that they can control the various issues so you're not helping them by
> > outlawing their method.
>
> > Kevin Jennings
>
> Hi KJ,
> I have another question for you.
>
> 1. Is any combinational equation with target signal in both right part
> and left part of the equation a latch like your equations 3 or 4 show?
While Jim and Peter can debate whether or not it's a latch or an
oscillator, suffice it to say that any time you have something of the
form of equations #3 and #4 where you have the same signal on both
sides of the '<=' in a concurrent statement you have some form of
storage or memory being inferred that will cause you the exact same
timing/glitch/hazard issues to deal with as you would if you have
something that matches exactly #3 and #4.

The important thing to take away is not whether it's a latch or an
oscillator or anything else, just that red flags should go off in your
head when you see the output being used on the right side of the
equation.  Whether this is a problem or not depends on what the target
device is.  In ASICs this will not be a problem, in FPGAs you have to
be very careful or it will be a problem.

>
> 2. Is there any general algorithm to change such an equation to a
> latch equation?
Not sure what you mean....all four forms that I presented are exactly
equivalent 'latch equations', they will produce the same synthesized
result.  Equations #1 and #2 involve less typing then #3 and #4.

Also keep in mind, that latches do not need to fit into a single
equation, any time that you form a combinatorial loop you have to be
concerned about how this will get implemented.  A combinatorial loop
happens when you have multiple equations, none of which inherently
shows any feedback but taken together the whole set does.  A simple
example of this would be

#5
Q <= (C and X) or (not(C) and Y);  -- Eqn. 5a
Y <= Q and Z;  -- Eqn. 5b

Equation 5a, on the surface appears to be a 2->1 multiplexer where 'C'
is simply used to select between two signals 'X' and 'Y'.

Equation 5b, on the surface appears to be a simple anding of two
signals 'Q' and 'Z'.

But when you put them together the two form a combinatorial loop
because 'Q' depends on 'Y' and 'Y' depends on 'Q'.  When you run
through synthesis, these things generally get flagged as warnings
somewhere.  The nice thing is that it will find all these loops no
matter how complex the equations or how spread out they are as long as
they are totally self contained within the entire design.  By that I
mean, lets say that Equation 5a was implemented in some entity
somewhere in some file and Equation 5b in a totally different entity
in some other file.  By themselves, each entity/file will synthesize
just fine.  But when you add the code for the entity that ties these
two blocks together that new design and synthesize that new block,
you'll have now formed the loop and the synthesizer should flag the
warning for you.  Take those warning seriously if you're designing in
the FPGA/CPLD world.

Kevin Jennings


Article: 116433
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 8 Mar 2007 14:21:33 -0800
Links: << >>  << T >>  << A >>
>
> If you have a split ground plane it would seem that the signal
> lines should go around, and not cross the split.
>
The signal will go where the copper is which is over the ground plane
split.  The return current for that signal will follow it's copper
which is in the ground or power plane so it will be forced around the
split.  This separates the signal current from it's return current
which causes a nice big radiating loop....bad for EMI if the edge rate
on that signal is single digit nanoseconds.

Kevin Jennings


Article: 116434
Subject: Re: Xilinx Spartan DCM jitter spectrum
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 08 Mar 2007 14:40:37 -0800
Links: << >>  << T >>  << A >>
Nico,

The power spectral density (the spectrum you would see on a spectrum
analyzer) is extremely close to the carrier -- that is no spurs.

The reason for this is that if you make small adjustments to the delay
lines every so many clocks, these small steps (~25ps steps) represent a
tiny increase or decrease in the period of the clock, which means that
there is a correspondingly tiny step of frequency that lasts for one
period, and then is gone.

The result is gaussian noise bump in spectra around the carrier.

There are no other frequency components (unless they are already present
in the input clock, in which case they come directly through -- a DCM
does not attenuate jitter).

In the time domain, if you do a histogram of periods, you will get two
overlapping (or more) gaussian distributions of period length:  period -
tap, period + tap, possible period + two taps, possible period - 2 taps.
 The time domain is the superposition of period lengths with and without
the taps inserted.  Since the change in tap is completely random (like
flipping a coin each time), there is no determinism, and hence no rate
at which changes occur, and no sub-harmonics, or sidebands.

Austin

Article: 116435
Subject: Re: VHDL and Latch
From: Jim Lewis <jim@synthworks.com>
Date: Thu, 08 Mar 2007 16:18:51 -0800
Links: << >>  << T >>  << A >>
Peter,
No argument from me as you seem to be saying the same
thing I said.

I interpreted Weng's question as being, when a combinational
signal is on both the right and left side of an equation,
is the only hardware solution a latch.

The answer which we both observed is no and the simple
case is an oscillator.

Cheers,
Jim


> I think we will agree that a latch needs positive feedback from the
> output to at least one of the inputs.
> If the feedback is negative (Qbar to D, for example) you end up with
> an oscillator.
> Peter Alfke
> 
> On Mar 8, 9:49 am, Jim Lewis <j...@synthworks.com> wrote:
>> Weng> Hi KJ,
>>> I have another question for you.
>>  >> Q <= (C and D) or (not(C) and Q);
>>
>>> 1. Is any combinational equation with target signal in both right part
>>> and left part of the equation a latch like your equations 3 or 4 show?
>> A latch is the most benign form.
>> There are oscillators (however when they occur by
>> accident, they are not necessarily this obvious):
>>     Q <= not Q ;
>>
>> There is also other strange latch-like behavior.
>> I don't have an equation for you, but I do remember
>> analyzing one - it was very interesting.
>>
>> Cheers,
>> Jim
> 
> 

Article: 116436
Subject: Re: VHDL and Latch
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 8 Mar 2007 16:28:52 -0800
Links: << >>  << T >>  << A >>
On Mar 8, 4:18 pm, Jim Lewis <j...@synthworks.com> wrote:
> Peter,
> No argument from me as you seem to be saying the same
> thing I said.
>
> I interpreted Weng's question as being, when a combinational
> signal is on both the right and left side of an equation,
> is the only hardware solution a latch.
>
> The answer which we both observed is no and the simple
> case is an oscillator.
>
> Cheers,
> Jim
>
>
>
> > I think we will agree that a latch needs positive feedback from the
> > output to at least one of the inputs.
> > If the feedback is negative (Qbar to D, for example) you end up with
> > an oscillator.
> > Peter Alfke
>
> > On Mar 8, 9:49 am, Jim Lewis <j...@synthworks.com> wrote:
> >> Weng> Hi KJ,
> >>> I have another question for you.
> >>  >> Q <= (C and D) or (not(C) and Q);
>
> >>> 1. Is any combinational equation with target signal in both right part
> >>> and left part of the equation a latch like your equations 3 or 4 show?
> >> A latch is the most benign form.
> >> There are oscillators (however when they occur by
> >> accident, they are not necessarily this obvious):
> >>     Q <= not Q ;
>
> >> There is also other strange latch-like behavior.
> >> I don't have an equation for you, but I do remember
> >> analyzing one - it was very interesting.
>
> >> Cheers,
> >> Jim- Hide quoted text -
>
> - Show quoted text -

Hi KJ, Jim and Peter,
Thank you for your response and help.

Anyway now I understand the latch a little more than before the
posting.

In coding experiences, when writing code equations, a reasonalble FPGA
engineer will never generate a situation that leads to a signal
appearing in both sides of logic equation in concurrent area. Because
most of time the odd behavior equations would be fully beyond the
acknowledgable. And there is no reason to generate an oscillator
neither.

Jim correctly repeated my question and both of you gave me a right
answer.

Weng


Article: 116437
Subject: Re: VHDL and Latch
From: Jim Lewis <jim@synthworks.com>
Date: Thu, 08 Mar 2007 16:30:44 -0800
Links: << >>  << T >>  << A >>
Weng,
 > 2. Is there any general algorithm to change such an
 > equation to a latch equation?
I have not seen any evidence of one you can expect different
tool vendors to support.

For RTL code, if you want a synthesis tool to reliably
create a latch library part, only use #1 or #2 (below from
KJs post).  Going further, if you want to avoid portability
issues with some of the ASIC synthesis tools, then use
only #1.

>> #1 -- Traditional form of writing a latch
>> process(C, D)
>> begin
>> if (C='1') then
>>    Q <= D;
>> end if;
>> end process;
>>
>> #2 -- Another traditional form of writing a latch.
>> Q <= D when (C = '1');

If you use other forms, a synthesis tool may generate
logic that implements latching behavior without using
a latch part.  If you use these to deliberately create
a latch, good luck.

Generally people accidentally create the other forms
when two separate pieces of logic communicate.

Cheers,
Jim

Article: 116438
Subject: Re: Driving PLL from general I/O in Altera Cyclone
From: "nfirtaps" <lloyd.rochester@gmail.com>
Date: 8 Mar 2007 17:18:30 -0800
Links: << >>  << T >>  << A >>
The problem I am having maybe due to jitter. I am not sure.  I am
running under 35 MHz, althougth I am using LVDS.  I am sampling on the
rising and falling edge of the clock, and the deserializer needs to
take every 7 clocks (respective 14 bits) since it is DDR.  When I look
at the output clk/7 that I generate by a simple counter (when counter
= 1-4 clk is high, when counter = 4-7 clk is low), I see that the duty
cycle changes by about 1 clock.  It seems as though the counter misses
a beat or something of that nature.

What I expect to see is a newly generated clock where the rising edges
occur at the same place every time, although, I see a rising edges
"walk" with respect to my trigger on the scope.  I have no idea the
source of the problem, or how to fix it.

Regards

On Mar 8, 2:12 pm, "Will Dean" <w...@nospam.demon.co.uk> wrote:
> "nfirtaps" <lloyd.roches...@gmail.com> wrote in message
>
> news:1173383894.763347.110110@64g2000cwx.googlegroups.com...
>
>
>
> > 1.) Can I somehow drive aPLLwith a general purpose I/O
>
> I don't think so.  I'm usingCycloneII at the moment and I'm 99.9% sure you
> can't feed the PLLs with anything except one of the 'clock input' pins.
> (These can also be general purpose input pins, so I would always recommend
> connecting anything vaguely 'clock-like' to one of those pins, even if you
> think you might not actually use it as a clock.)
>
> > 2.) Is there another way of deserializing the DDR signal.
>
> You don't say anything about frequency, but I'd be inclined just to sample
> on the falling edge as well, and then shift the two bits (+ve edge and -ve
> edge) into your shift register on the next +ve clock.
>
> > Currently I have a the DDR clock coming in my fpga and I not the clock
> > so I can sample the DDR signal on the rising egde.
>
> Is that giving you a problem?
>
> Will



Article: 116439
Subject: Re: CAN vhdl code document
From: "Tom" <tom.derham@gmail.com>
Date: 8 Mar 2007 18:09:46 -0800
Links: << >>  << T >>  << A >>
On Mar 8, 8:22 pm, barukula.ram...@gmail.com wrote:
>     i have downloaded the CAN VHDL from opencores but am unable to
> understand the code.
> can anyone please tell me where i can get the document for that code.

There isn't much (any?) documentation. But you only need to understand
the operation of the core, and its interfaces, not how it works
internally.
The core basically replicates a Philips SJA1000 CAN controller - all
the registers are the same.
So just look at http://www.nxp.com/pip/SJA1000 and get the datasheet.

There are 2 interfaces (at least in the Verilog version) - Wishbone
and 8051.
The Wishbone interface is specified by Opencores - get the spec from
http://www.opencores.com/projects.cgi/web/wishbone/wishbone
You can get the (Intel) 8051 spec from the datasheets and app notes
from any of the vendors making 8051 clone chips - start here
http://en.wikipedia.org/wiki/Intel_8051

Best wishes



Article: 116440
Subject: Re: Large power planes vs. power islands vs. slits for decoupling
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 08 Mar 2007 18:33:46 -0800
Links: << >>  << T >>  << A >>

>>If you have a split ground plane it would seem that the signal
>>lines should go around, and not cross the split.

KJ wrote:
> The signal will go where the copper is which is over the ground plane
> split.  The return current for that signal will follow it's copper
> which is in the ground or power plane so it will be forced around the
> split. 

What I meant was the the copper should follow the ground plane,
such that the signal does go that way.  It says signal lines,
so I don't see how you would read it any other way.

-- glen


Article: 116441
Subject: Re: V.34 Modem IP core
From: "GX" <growxpert@gmail.com>
Date: 8 Mar 2007 19:01:11 -0800
Links: << >>  << T >>  << A >>
On Mar 9, 2:38 am, Eric Smith <e...@brouhaha.com> wrote:
> GX wrote:
> > any IP vendor out there who supply hard/soft core for V.34Modem?
> I wrote:
> > V.34 is normally (probably always) implemented in software.  You could
> > put any DSP core (or RISC core with DSP capability) into your FPGA or
> > ASIC, and run a V.34 implementation on it.
> GX wrote:
> > Thanks for your response.
>
> > After googling, I have found lot of Single chipModemASICs.
> > like, MN195006 from Panasonic.
>
> > Did anyone integrated the functional equivalent of these single chip
> >modemchip in to FPGA/ASIC/SoC?
>
> The answer is still the same.  The MN195006 is almost certainly a
> mask programmed DSP, or perhaps an ASIC containing a DSP core and ROM.
>
> You can certainly put a DSP core into an FPGA, but there's not likely
> to be enough block RAM for all the code for V.34, so you'll need
> external memory.  In an ASIC, it's possible to integrate the whole
> thing, as the MN195006 shows.
>
> If the MN195006 does what you need, you're almost certainly better
> off buying that and interfacing it to your own design, than trying
> to integrate amodemyourself.  Unless you expect volumes well
> over 100K units, the integrated approach will be significantly more
> expensive.
>
> If you really think you want to do it, there are companies out there
> that will be happy to sell you a license for a V.34 software
> implementation, which you can then use in your FPGA or ASIC.  Do a
> Google search for "v.34 softmodem" and several turn up.
>
> Eric

Thanks very much Eric. This helps me a lot.

-GX


Article: 116442
Subject: Re: Spartan3AN - Roadmap - bigger questions may prevail...
From: "John McCaskill" <junkmail@fastertechnology.com>
Date: 8 Mar 2007 20:18:17 -0800
Links: << >>  << T >>  << A >>
On Mar 8, 10:51 am, "Symon" <symon_bre...@hotmail.com> wrote:
> "John McCaskill" <junkm...@fastertechnology.com> wrote in message
>
> news:1173371757.756269.53650@h3g2000cwc.googlegroups.com...
>
> > On Mar 8, 10:06 am, Austin Lesea <aus...@xilinx.com> wrote:
> >> Symon,
>
> >> Intel is keeping this secret.  If true, it is a huge improvement, and
> >> one that the foundries will be itching to get their hands on.
>
> >> The hi-K dielectric for the transistor will keep the roadmap moving
> >> forward with lower leakage (the gates leak at 65nm and below), and
> >> perhaps better speed (hi-K makes the transistor stronger according to
> >> Intel).
>
> >> Austin
>
> > I don't remember where I first saw it mentioned, but they are not
> > keeping it a secret. Here are a few mentions about it:
>
> >http://pubs.acs.org/cen/news/85/i06/8506notw4.html
> >http://www.intel.com/technology/silicon/45nm_technology.htm
>
> > And here is the leading supplier of it:
>
> >http://www.wahchang.com/pages/products/data/hafnium.htm
>
> > Regards,
>
> > John McCaskill
> >www.fastertechnology.com
>
> I guess Austin means they're keeping the process details secret, not the
> results. Go to the above link you posted on intel.com and search for
> 'secret'! ;-)
> HTH, Syms.



Perhaps that is what he meant, but I would expect that either Intel
would licence their technology after a while, or the IBM/AMD/Sony/
Toshiba group will.

If none of them want to license it, I didn't want it anyway. After
all, hafnium is only half as good as unobtanium which is used in all
the best -K dielectrics.

Regards,


John McCaskill
www.fastertechnology.com


Article: 116443
Subject: Re: Driving PLL from general I/O in Altera Cyclone
From: "Rob" <robnstef@frontiernet.net>
Date: Fri, 09 Mar 2007 04:27:55 GMT
Links: << >>  << T >>  << A >>
If your input clock is not on the global clock network you will be fighting 
with clock skew to the flops.  When your clock edges are happening with 
respect to the data at the flops becomes an utmost concern for you.

"nfirtaps" <lloyd.rochester@gmail.com> wrote in message 
news:1173383894.763347.110110@64g2000cwx.googlegroups.com...
>I am trying to deserialize a DDR signal in my Cyclone.  For reasons I
> won't go into the DDR clock comes in off a general purpose I/O pin.  I
> need a way of deserializing this signal, and want to increase the
> frequency of the DDR clock by 2 so I can use rising edge flip-flops.
>
> 1.) Can I somehow drive a PLL with a general purpose I/O
> 2.) Is there another way of deserializing the DDR signal.
>
> Currently I have a the DDR clock coming in my fpga and I not the clock
> so I can sample the DDR signal on the rising egde.
>
> Thanks
> 



Article: 116444
Subject: Re: Introducing picosecond delay between two output signals
From: Jerry Coffin <jcoffin@taeus.com>
Date: Thu, 8 Mar 2007 22:08:03 -0700
Links: << >>  << T >>  << A >>
In article <1173304789.265305.168410@p10g2000cwp.googlegroups.com>, 
axr0284@yahoo.com says...
> Hi,
>  I would like to know what are the common methods of introducing
> delays as low as 10ps between two outputs in an FPGA.

Do it on the PC board? Depending on board material, a 10 ps delay 
translates to adding about 2 mm to a trace length.

A worked out example of the math: an FR-4 microstrip has a dielectric 
constant of about 3.4, giving a transission velocity of:

(3e8 m/s)/sqrt(3.4) = 1.63e8 m/s

Multiplying by 10 ps (1e-11) cancels the seconds, giving 1.63e-3 m, or 
1.63 millimeters.

Of course, you need to adjust the dielectric constant for the material 
you're using, or you can end up wrong by a fairly substantial margin.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Article: 116445
Subject: Re: FPGA Vs ASIC design and implementation
From: "Thomas Stanka" <usenet_10@stanka-web.de>
Date: 9 Mar 2007 00:00:33 -0800
Links: << >>  << T >>  << A >>
Hi,

I feel you are talking about fullcustom ICs when talking about ASICs.
There exist fix predesigned technology libs when doing cell based
design, and Sea-of-Gate ASIC didn't allow to include anything not
available in the technology.

On 8 Mrz., 12:57, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:
> Karl wrote:
> The main differences:
> - FPGAs come with IOBs (QDR/DDR/SDR, differential/single-ended, in/out/inout, etc.), with
> ASICs you have to license someone else's or create your own

Or choose a ASIC technology that fits. I never bothered about IOs in
an ASIC.
DDR is so easy in ASIC, but may be hard if your fpga didn't support it
(every fpga allows DDR as long, as your FPGA is _slow_ clocked, but
you have trouble getting data in and out on a speed exceeding your
Fpgas fmax if your technology didn't support it by dedicated HW (don't
expect to have all designs on a virtex *g*).

> - FPGAs come with some analog bits (PLLs, DACs, ADCs, MGTs, etc.), with ASICs you have to
> license someone else's or create your own

Which FPGA provides DAC and ADC? Actel Fusion provides AFAIK only ADC
and is the only available mixed signal FPGA known to me.
I would have considered a PLL as a standard for actual ASIC
technologies.

> So, for me, the most significant difference between ASIC and FPGA after the development
> cost and production timetable is having to license all the low-level nuts and bolts if I
> want to be able to concentrate on the higher-level functions I wish to implement without
> having to worry about going through a dozen re-spins just to get the low-level stuff like
> FFs and IOBs to work properly.

This is not true for the cell based design I worked on.

by Thomas


Article: 116446
Subject: Re: Xilinx CoreGen fifo - ngdbuild error
From: Markus Fras <fras@mppmu.mpg.de>
Date: Fri, 09 Mar 2007 09:05:57 +0100
Links: << >>  << T >>  << A >>
Sean Durkin schrieb:
> Markus Fras wrote:
>> Checking timing specifications ...
>> Checking expanded design ...
>> ERROR:NgdBuild:604 - logical block 'inst_fifo/BU2' with type
>>    'fifo18w16d_fifo_generator_v2_3_xst_1' could not be resolved. A pin name
>>    misspelling can cause this, a missing edif or ngc file, or the
>> misspelling of
>>    a type name. Symbol 'fifo18w16d_fifo_generator_v2_3_xst_1' is not
>> supported
>>    in target 'virtex2'.
> Is there a third file in the coregen-directory? There might be an
> .ngc-file called fifo18w16d_fifo_generator_v2_3_xst_1.ngc. If so, you
> have to add this to your project as well (also with the -exclude
> option). The .edn is then just a wrapper for the .ngc, and is way smaller.
> 
> I've had this problem before. Even if I explicitely tell CoreGen that I
> want it to create an EDIF-netlist for third-party tools, I always get an
> .edn and an .ngc, and I need them both. I don't remember this from
> earlier ISE-versions, but I might just not have tried all different
> settings.
> 
> HTH,
> Sean
> 

Well, Xilinx CoreGen created two additional files:

fifo18w16d_fifo_generator_v2_3_xst_1.ngc
fifo18w16d_fifo_generator_v2_3_xst_1_blkmemdp_v6_2_xst.edn

Even if I include both of the, I still get the same error message.

The solution is to add the output directory of CoreGen to ngdbuild with 
the switch `-sd'. Then you need only to include the *.v file in the 
synthesis.

I.e. in the synthesis script only add the line

`add_input_file fifo18w16d.v'


and to the ngdbuild command, add the switch

`-sd <coregen_output_directory>'


Cheers,

Markus Fras

Article: 116447
Subject: data2mem crash
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Fri, 09 Mar 2007 10:03:35 +0100
Links: << >>  << T >>  << A >>
Hi everyone,

I just installed a new workstation, a Core2 duro running linux 64 bits.
But I can use data2bram on it, it crashes every time. I've tested with both 8.2 and 9.1 (both with latest service pack). For 8.2 I even tried the 32b and the 64 version.

Using this utility is really important for me to update picoblaze and microblaze software without a need to recompile each time I want to test a new firmware.

Has anyone encountered such an issue ?

	Sylvain

Article: 116448
Subject: RLOC not working correctly in ISE 8.2 and 9.1?
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Fri, 9 Mar 2007 09:09:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
I've been wondering if someone else has noticed that RLOCs
does not seem to be working very well in ISE 8.2 and 9.1?

Currently I'm experimenting with a project where the RLOCs
are working ok for smaller submodules but when I try to
instantiate these submodules into a larger design in 
several places the RLOCs are lost in some way.

In ISE 8.1 everything is working as expected though.

/Andreas

Article: 116449
Subject: Re: Load V4 bitstream encryption key with XSVF
From: jetmarc@hotmail.com
Date: 9 Mar 2007 02:27:31 -0800
Links: << >>  << T >>  << A >>

jetm...@hotmail.com wrote:
> Hi.
>
> I want to load the bitstream encryption key on a V4FX board.
>
> Using IMPACT and a Xilinx download cable, I can successfully load it
> (together with a design file).
>
> However, my board doesn't normally expose the JTAG pins to connect a
> Xilinx cable.  Instead, it uses a proprietary interface.  I can play
> XSVF files over this interface to program the bitstream.
>
> To create the XSVF I repeat the same steps that work with a Xilinx
> cable, recording to XSVF.  However, playing this file on my board
> doesn't load the keys.  Analysis of the XSVF suggests that IMPACT (ISE
> 8.1 SP3) forgets to include the JTAG commands for the key for some
> reason.
>
> At least, when recording to an ASCII SVF file, I can't locate the key
> anywhere.
>
> As alternative approach to the problem, I browsed the V4FX
> documentation for instructions on how to create a key loader program
> myself.  Unfortunately the only hint I found is that ISC_PROGRAM can
> be (somehow) used to enter a so-called "key-access mode", without
> giving further details on the matter.
>
> I appreciate any information on that matter.  Even just a sample
> (X)SVF containing the instructions for a key load would be of help to
> me.
>
> Thanks,
> Marc




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