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 74500

Article: 74500
Subject: Re: Interfacing from the analogue domain
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 12 Oct 2004 23:14:09 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <2t2te2F1rhr88U1@uni-berlin.de>,
Symon <symon_brewer@hotmail.com> wrote:
>Thomas,
>If you read the datasheet you'll find out that the IOB set in PCI33 mode has
>Vih (min) = 60% of Vccint = 0.6 x 2.5V = 1.5V. There you go....

Cool.  I'd for some reason thought anything more exotic than LVTTL required
external reference voltages which the board I have wasn't providing, but
this is because I was misreading the datasheet.  Thanks!

Tom

Article: 74501
Subject: Re: Interfacing from the analogue domain
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 12 Oct 2004 15:40:28 -0700
Links: << >>  << T >>  << A >>
No worries, Thomas! This IOB set up saved my ass a few years ago. We needed
to use a TCXO with a sine wave 0.7V pk-pk amplitude. It worked out that with
AC coupling and the correct biasing, you can make this work within the PCI33
specced inputs. Just. Then all I had to do was fix the glitchy bits as the
thresholds were crossed....
Best, Syms.
"Thomas Womack" <twomack@chiark.greenend.org.uk> wrote in message
news:zhh*mxXwq@news.chiark.greenend.org.uk...
> In article <2t2te2F1rhr88U1@uni-berlin.de>,
> Symon <symon_brewer@hotmail.com> wrote:
> >Thomas,
> >If you read the datasheet you'll find out that the IOB set in PCI33 mode
has
> >Vih (min) = 60% of Vccint = 0.6 x 2.5V = 1.5V. There you go....
>
> Cool.  I'd for some reason thought anything more exotic than LVTTL
required
> external reference voltages which the board I have wasn't providing, but
> this is because I was misreading the datasheet.  Thanks!
>
> Tom



Article: 74502
Subject: Re: Actel Fusefile Reverse Engineering
From: johnjakson@yahoo.com (john jakson)
Date: 12 Oct 2004 17:58:35 -0700
Links: << >>  << T >>  << A >>
Mike Treseler <mike_treseler@comcast.net> wrote in message news:<0-adnfbWALJ4dfbcRVn-sg@comcast.com>...
> Wong wrote:
> > tatto0_2000@yahoo.com (Wong) wrote in message news:<509bfe22.0410110029.3a3cccc0@posting.google.com>...
>  
> >>  I am a Actel 54SXA family user. I would like to get from the
> >>fusefile what I/O standard I have selected in my Designer software
> >>(i.e. PCI, LVTTL). Is that possible ? I am doing so because I have
> >>been messed up my files and I cant trace back.
> 
> If you don't remember, it's probably the default.
> Check with Actel and measure a programmed device for
> output swing and input thresholds.
> 
>         -- Mike Treseler

Why not regen the bit file, 1 for each IO option and do a bin diff
against what you have. One should match!

regards

johnjakson_usa_com

Article: 74503
Subject: Re: direct calculation of the modulus ?
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Wed, 13 Oct 2004 12:14:01 +1000
Links: << >>  << T >>  << A >>
On Tue, 12 Oct 2004 11:39:10 -0700, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>
>
>mete wrote:
>
>> Is there method that is more efficient than regular division for
>> calculating modulus ?
>
>For specific input base and modulus there is usually an
>efficient way.  For decimal input and modulus of 3 or 9,
>you can add the digits together, and take the modulus of
>the sum.  For binary input there are even more rules, but
>the modulus must be known in advance.

In particular, if the divisor is 2^N +/- 1, there are significant
simplifications.

Regards,
Allan

Article: 74504
Subject: Re: EP1C12 or XC3S400?
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Tue, 12 Oct 2004 22:17:05 -0400
Links: << >>  << T >>  << A >>
Hi Arash,

> It comes in two flavours: one with an Altera Cyclone series EP1C12F324C8
and
> the other one with a Xilinx Spartand 3 XC3S400-4F456C. Both options have
the
> same price of $99. Besides the FPGA, the both kits are exactly the same
> thing.
> My question is which one to select? Personally, I'd rather select the
BIGGER
> one but I don't know which one it is. I know it is very difficult to
compare
> the SIZE of two FPGAs with very different architectures.

The Cyclone 1C12 (www.altera.com/cyclone) has 12060 logic elements (4-LUT +
FF + goo).  In addition, we believe our LE is more efficient than Xilinx's
logic element based on benchmarking results of how much we can pack into
ours; I can't find the stats right now by memory tells me we believe there
is a ~10% difference in packing density.  The XC3S400 has 8,064 "logic
cells", or in other words 7168 4-LUT + FF + different goo blocks (Xilinx
inflates by 12.5% for random marketing reasons).  So as you can see there is
a large difference in logic capacity.

The XC3S400 has embedded multipliers, which the 1C12 does not, so if you
require substantial multiplication then some of the logic difference will be
consumed for multiplication.  It also depends on how large the multipliers
are that you need, what speed you need to run them, and what latency you
require -- there are solutions involving "soft multipliers" that allow you
to use M4K RAM blocks as multipliers if need be.

Speed may also be a consideration.  In general, Cyclone is faster than
Spartan-3; see www.altera.com/switch for benchmarking results, and be sure
to search this newsgroup for Steve (from Xilinx)'s responses to these
claims.  Note that the two devices offered on the dev board in question are
both the slowest speed grade offered in the two respective families.

As far as processors go, both companies offer embedded soft processor
solutions.  Altera's Nios core was the first soft-processor solution
available and has a large user base and mature, robust development tools.
Nios II is the next-generation version of this core and offers improve
capabilities and performance.  Please see www.altera.com/nios for more
information.

You can try out both devices using the freely available software available
from both companies.  Our Quratus II Web Edition software
(http://www.altera.com/products/software/products/quartus2web/sof-quarwebmai
n.html) fully supports Cyclone.  If you have a design in mind, try it out on
both and see which software and which chip you like.

Regards,

Paul Leventis
Altera Corp.



Article: 74505
Subject: Re: newbie question
From: Shreyas Kulkarni <shyan@gmail.com>
Date: Wed, 13 Oct 2004 08:17:19 +0530
Links: << >>  << T >>  << A >>
Thanks a lot Philip for that nice reply.

--
$hreya$


Philip Freidin wrote:

> On Tue, 12 Oct 2004 06:20:57 +0530, Shreyas Kulkarni <shyan@gmail.com> wrote:
> 
>>hello there,
>>
>>i m a newbie to this fpga world. can i ask -
>>what is meant by timing closure?
> 
> 
> Sure you can ask.
> 
> 
>>does it anyway relate to meeting the timing requirements?
>>or something else?
> 
> 
> You are correct. When you do your design, you should know the
> clock frequency (or frequencies) that your design needs to operate
> at, as well as the requirements at the I/O pins, such as setup and
> hold times with regard to other I/O pins, and usually clock pins.
> 
> Together, these timing requirements are referred to as "timing constraints"
> by the FPGA implementation software.
> 
> So you pass your logical design plus these constraints to the implementation
> software, and the end result is hopefully a placed and routed design,
> plus a timing report. If all went well, the timing report tells you that
> all your constraints have been met. This would be "closure".
> 
> Providing that your design is logically correct, and you have timing
> closure, you are ready to try out your design in an FPGA.
> 
> If you don't have timing closure, there is little point in running your
> design, since although it still may work (because the device you are
> using might be better than average, or it is a cold day, or a full moon),
> you could not predict whether the design would run in the next chip you try.
> 
> If you dont have timing closure, there are several hings you can do:
> 1) Run the implementation tools again. Some tools have some randomness in
>    their operation, and you might be lucky.
> 2) Figure out what paths did not meet timing constraints, and change your
>    design to make these paths take less time. I.e. less logic, more pipeline
>    stages
> 3) Change to a faster FPGA
> 4) Change you clock rate, and the constraints
> 
> Note that timing closure does not guarantee that your design will work. I
> have seen many designs where the constraints did not cover all paths in the
> design. The implementation tools are notorious for reporting that your design
> meets timing, but fails to tell you that only 30% of your paths had timing
> constraints. The rest of the paths MUST have some timing requirement, but you
> forgot to include it in the constraints list.
> 
> 
>>i know, it's a stupid question, but one should never underestimate
>>the human stupidity !  ;-)
> 
> 
> There are no stupid questions, only stupid answers.
> 
> 
>>TIA
>>$hrey$
> 
> 
> Philip
> 
> 
> 
> ===================
> Philip Freidin
> philip.freidin@fpga-faq.com
> Host for WWW.FPGA-FAQ.COM

Article: 74506
Subject: Re: CORDIC NCO Frequency resolution?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 12 Oct 2004 23:19:44 -0400
Links: << >>  << T >>  << A >>
Right.  Consider though, if your DAC is only 16 bits, then you needn't carry 32 bits all
the way up to the DAC, you can drop off LSBs, one less on each previous stage...ie last
iteration has 17 bits, next to last has 18, the one before that 19 and so on in order to
save hardware (at the expense of being harder to code).

Carlos Murillo wrote:

> Thank's for you help Ray,
>
> Now I think I get it!!
> Please tell me if I'm wrong!!!
>
> For example: In my case where I have 16+guardbits in my Cordic(input)
> the 360 degrees are divided in 2^(16+guardbits),that means that just
> when the MSW(16 bits) from phase accumulator changes, a new output
> will come from Cordic on each phase accum. step.  But when the phase
> accumulator LSW changes, Cordics output will not change in every phase
> acc. step!
>
> look figure in http://www.nova-eng.com/downloads/ip_nco_crdc.pdf
>
> It will be "ideal" to have always in each acc. step a new output. That
> will  give a better input to the DAC. To achieve this task we will
> need 2^32 phase acc. steps(common!) and a angle resolution of 2^32.
> But because a DAC with 32 bits are just dreams!! the angle resolution
> has to be truncated.
> Is it right???
>
> Carlos Murillo
>
> Ray Andraka <ray@andraka.com> wrote in message news:<416A8F3A.B3FFF57@andraka.com>...
> > There is a difference between phase resolution and frequency
> > resolution.  Typically, you'll have a phase accumulator that adds some
> > fixed increment to itself every clock cycle.  The increment value sets
> > the frequency, which is the frequency of the accumulator wrap-arounds.
> > The frequency is Fo = Fc*N/(2^k) where Fc is the clock frequency, N is
> > the increment value (integer) and k is the number of bits in the phase
> > accumulator.  The more bits in the accumulator, the finer the resolution
> > to which you can set the frequency.  The CORDIC width does not affect
> > the frequency at all, rather it will affect the noise added by the
> > CORDIC.  You have several factors here:  number of iterations, width of
> > I and Q paths and width of phase path.
> >
> > First, look at the number of iterations.  If we assume for the moment
> > that there is infinite precision in the I and Q data paths as well as in
> > the phase accumulator path, then each iteration performs a perfect
> > rotation with no error, but the angle of rotation is fixed at the
> > elemental angle for that iteration.   If you limit the number of
> > iterations, you limit the total number of possible rotation
> > angles...that is limiting the number of iterations introduces a phase
> > error in the rotated output.  There is no amplitude error due to
> > limiting the number of iterations.
> >
> > Next, lets consider limited precision in the phase accumulators.  Again,
> > we'll assume infinite precision in the I and Q paths.  If the phase
> > accumulator width is limited, we introduce a truncation/rounding error
> > in the phase for each iteration accomplished.  Again, the error is only
> > in phase angle, not in amplitude.
> >
> > In both the above cases, the phase error is not cumulative from sample
> > to sample, so it manifests itself as phase noise.  Note this has no
> > effect on the average frequency, and that there is no amplitude noise.
> >
> > Finally, in the case of limited precision I and Q, the rotations are no
> > longer perfect, as there is a rounding or truncation error on sum at
> > each iteration. The result is the rotated vector is forced to fall on a
> > retangular grid, which introduces both angular and magnitude errors.
> > Again, there is no effect on the average phase or amplitude, but the
> > instantaneous values will have some error bounded by the resolution of
> > the IQ grid defined by the I and Q resolution.  The extra LSBs, which
> > you are calling guard bits are there to make the I and Q truncation
> > error smaller with respect to the signal, and therefore reduce this
> > noise source.
> >
> > I hope this helps explain it.
> >
> > Carlos Murillo wrote:
> >
> > > Hello everybody!!
> > >
> > > Maybe some CORDIC guru's can help me???
> > >
> > > I've seen a lot of papers, designs and cores and I still don't
> > > understand
> > > why always everybody offers (for example) a Frequency Resolution of
> > > 32bit when at the input of CORDIC's block the angle just have
> > > 16bits+guard bits(log2(16)) = 20 bits. That's not a 32 bits
> > > resolution!!!! The phase offset is 16 bits, That's OK but 32 bits
> > > frequency resolution!!!! I think maybe it's all about the guard bits
> > > but I'm not sure!!! Can some one please Help me to understand it!!!!
> > > Thank's for your time!!!
> > >
> > > Carlos Murillo
> >
> > --
> > --Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >  "They that give up essential liberty to obtain a little
> >   temporary safety deserve neither liberty nor safety."
> >                                           -Benjamin Franklin, 1759

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 74507
Subject: Re: Reading RAM while
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 13 Oct 2004 00:49:43 -0400
Links: << >>  << T >>  << A >>
Yaseen Zaidi wrote:
> 
> This may sound trivial but why is data being output (read) on the out
> port during the write cycle in the Xilinx inferred RAM examples such
> as:
> 
>  if (CLK'event and CLK = '1') then
>          if (en = '1') then
>             if (we = '1') then
>                ram(conv_integer(unsigned(addr))) <= di;
>                do                                <= di;
>                else
>                do <= ram(conv_integer(unsigned(addr)));
>             end if;
>          end if;
>  end if;

Why do you think this should not be done?  Don't you expect something to
appear on the do output?  What would you expect the do output to have?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 74508
Subject: Re: Use Xilinx VP20 with 2 ppc and one DRAM chip
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Tue, 12 Oct 2004 22:05:41 -0700
Links: << >>  << T >>  << A >>
Tony,

if you want to share data structures between the two processors you will 
need to flush the caches if the data structures are in cacheable area. 
EDK has some simple functions in the xcache_l.h library that help you do 
that. Further, Erik has described the process very well in his email.

Alternatively, you can use some BRAM memory for shared data structures 
and put them into uncached memory. Instead of a BRAM you can alias the 
main memory, i.e. give it in EDK a larger address range than it really 
has and then cache the first 128MB but not cache the second (aliased) 
128MB. By putting the shared structures into the second 128MB they are 
automatically uncached and immediately written back to main memory.

Last but not least you can use the MMU and set up a few pages and divide 
the main memory into cached and uncached areas at page boundaries. For 
many applications this can be done statically, ie. you do not have to 
worry about TLB replacement.

- Peter


T Lee wrote:
> John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<ckd6rb$c62$1@bunyip.cc.uq.edu.au>...
> 
>>Hi Peter
>>
>>>1) hook up both PPC to the same PLB together with the PLB SDRAM controller
>>>2) write seperate linker scripts for each of the two processors. The 
>>>first processor uses the memory in [0,64[ and the second one uses [64,128[.
>>
>>Nice solution - what will the caches do in this configuration? 
>>Duplicate / thrash?  Get incoherent?
>>
>>John
> 
> 
> John, Peter, Thanks both for reply.
> 
> Caches will be fine for the application I have in mind, since each PPC will 
> run different application without share any common data structures.
> 
> Worst case, I can use volatile with the data structures access and also 
> design the code/structure that one always read, the other always write.
> 
> 
>>Interesting questions, with no easy answers.   If you make your custom 
>>processing logic bus master capable, then in principle you could use DMA 
>>to handle all of this.  You need to be careful that you don't end up in 
>>a bus-bound mess, losing any performance gains that might otherwise be 
>>achieved with the hardware offloading in the first place!
>>
>>It depends on the nature of what you are trying to do - if it is heavy 
>>on the computation, and light on the communication, then it's not so 
>>bad.  However, if the opposite is true, you will end up saturating the bus.
>>
> 
> 
> For an application that needs to process 1-2 millions packets per seconds, 
>     process = 
>        * look at the headers and some data structures and make forwarding
>          decision, 
>        * append packets descriptor to various Qs.
>        * A TX engine, check all Qs and tx them out to RIO base on time and 
>          QOS setting,  update counter values in the DDR.
> 
> The packets is already stored in a different DDR.  This process only need to 
> controls the DMA descriptors of the packets at the rate of 1-2 millions per second.
> 
>     Thanks again for both of your comments.
> 
> -Tony


Article: 74509
Subject: Re: EP1C12 or XC3S400?
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 13 Oct 2004 01:13:29 -0400
Links: << >>  << T >>  << A >>
"Paul Leventis (at home)" wrote:
> 
> Hi Arash,
> 
> > It comes in two flavours: one with an Altera Cyclone series EP1C12F324C8
> and
> > the other one with a Xilinx Spartand 3 XC3S400-4F456C. Both options have
> the
> > same price of $99. Besides the FPGA, the both kits are exactly the same
> > thing.
> > My question is which one to select? Personally, I'd rather select the
> BIGGER
> > one but I don't know which one it is. I know it is very difficult to
> compare
> > the SIZE of two FPGAs with very different architectures.

I looked at the Altium site and did not find the Spartan 3 modules you
describe.  Did you get this info directly from the sales people? 

But keep in mind that there are other issues than just size or even the
hardware.  You should download the free versions of the software from
each company and run them a bit to get a feel for them.  You can do a
*lot* of work with FPGAs without ever using hardware.  One significant
difference is that the Altera sofware does not include an HDL
simulator.  It has a gate level simulator, so you can't run a test bench
if I am not mistaken.  You have to generate a waveform stimulus file
instead which is much less flexible and portable. 


> The Cyclone 1C12 (www.altera.com/cyclone) has 12060 logic elements (4-LUT +
> FF + goo).  In addition, we believe our LE is more efficient than Xilinx's
> logic element based on benchmarking results of how much we can pack into
> ours; I can't find the stats right now by memory tells me we believe there
> is a ~10% difference in packing density.  The XC3S400 has 8,064 "logic
> cells", or in other words 7168 4-LUT + FF + different goo blocks (Xilinx
> inflates by 12.5% for random marketing reasons).  So as you can see there is
> a large difference in logic capacity.

The odd thing is that in the V2P data sheet they even *define* what a
logic cell is "Logic Cell = (1) 4-input LUT + (1)FF + Carry Logic" and
they *STILL* inflate the count by 12.5%.  I wonder why they bother to
define logic cells if they are not going to count them.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 74510
Subject: Re: Flex10K10A, I2C, MultiVolt IO, pull-ups
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 13 Oct 2004 01:26:09 -0400
Links: << >>  << T >>  << A >>
Markus Fuchs wrote:
> 
> rickman wrote:
> > I believe when you say "4,7V" you mean what we call 4.7 volts in the US,
> > no?
> 
> Damn, just gave myself away! <grin>
> English is not my native language, but you're right: I meant 4.7 volts.

My concern was not your english, but the odd voltage values.  Typically
there is a 5 volt supply on the board, but 4.7 and 5.6 volts are both
not very standard in digital logic.  


> Jim Granville wrote:
> >   If the PIC is always the master, you could try making the SCL line
> > always CMOS drive : In single master, only SDA needs to be open drain.
> 
> I already tried that without success.
> 
> >   That will ensure faster clock edges - what you describe is a
> > little counter-intuitive, esp as you say the resistor change had
> > no effect, but sounds closest to edge-effects.
> >   FPGAs tend to be slow edge intolerant.
> 
> Thank you Jim, that was it! I put a buffer between the PIC and the FPGA on
> the SCL line and now it works.
> So, what do you, Jim, Rick and all the other experts, recommend to get the
> edges on the I2C lines faster?
> There must be another solution for it, I guess, since buffers won't work on
> bidir lines.
> 
> Thank you!
> Markus
> 
> PS: Microchip says max. rise/fall time for the I2C lines are 300ns! :-(

I can't say what I would recommend since I still don't understand what
was wrong.  Did you put a scope on the signals out of the PIC?  If the
FPGA was reading 0xFF it sounds to me like the PIC was not pulling the
data signal down to ground.  A buffer might cure that since the PIC
would not be pulling on a stiff pullup (perhaps), but you said the
buffer was on the clock line, right?  Earlier you said changing the
pullup voltage from 4.7 volt to 5.6 volts fixed the problem while
changing the pullup resistor value did not.  I guess the higher voltage
would improve the edge rate, but reducing the resistor value should do
that as well.  

I suggest that you figure out exactly what was wrong with the original
design since it should have worked ok.  Just adding a buffer is more of
a bandaid than a real solution (not that there is anything wrong with
just "getting it to work").  

BTW, with the 400R resistor, your SCL line should have been within edge
rate spec with up to 1 nF (1000 pF) capacitance on the line.  Is this
all on the same board or is it possible that you are running too long a
line off the board and have a lot of capacitance?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 74511
Subject: HDL-Models of CLB/Slice
From: "Jan Bruns" <post@abnuto.de>
Date: Wed, 13 Oct 2004 07:58:55 +0200
Links: << >>  << T >>  << A >>
Hallo.

Where to find HDL-models of CLBs, so one could instantiate 
them directly (or just to get a basic idea of what's efficiently
implementable)? The Xilinx datasheets aren't really clear about
the CLB-structure, I think. For example, after having read then
SpartanII datasheet, I still  even don't know, how many signals go 
out of a CLB, and which functions can be programmed with a CLB.

Gruss

Jan Bruns





Article: 74512
Subject: Re: EP1C12 or XC3S400?
From: "Arash Salarian" <arash.salarian@epfl.ch>
Date: Wed, 13 Oct 2004 09:11:02 +0200
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:416CB979.EC57FD01@yahoo.com...
> I looked at the Altium site and did not find the Spartan 3 modules you
> describe.  Did you get this info directly from the sales people?
>
No, I found the information in the altium website. It seems they have just 
recently modified the evaluation package and now offer it with Spartan 3. 
Here is the online order form with the part number of the FPGAs on board. 
http://www.altium.com/evaluation/
It seems that the original offer included BOTH Xilinx and Altera's FPGAs (in 
the form of daugther boards) but the new one comes separately.

> But keep in mind that there are other issues than just size or even the
> hardware.  You should download the free versions of the software from
> each company and run them a bit to get a feel for them.  You can do a
> *lot* of work with FPGAs without ever using hardware.  One significant
> difference is that the Altera sofware does not include an HDL
> simulator.  It has a gate level simulator, so you can't run a test bench
> if I am not mistaken.  You have to generate a waveform stimulus file
> instead which is much less flexible and portable.
>

Thanks. Yes that's the way to go. The point is that it is now round 3 years 
that I have not done any new designs using FPGAs but before that (in the 
Altera's 10K and 20K age!) I used to work actively with both Altera and 
Xilinx. So basically I know the toolsets quite well but I have never used 
Cyclone or Spartan and that's why I was wondering.
Simulator in the Quartus or ISE is not that important for me. I have yet an 
older version (but a full version!) of ModelSim and I think even though it 
is old, yet it is much better of any offerings from Altera or Xilinx. At 
least I can use the full potentials of VHDL and also interface to C codes 
and much more. 



Article: 74513
Subject: Re: EP1C12 or XC3S400?
From: Tommy Thorn <foobar@nowhere.void>
Date: Wed, 13 Oct 2004 07:16:48 GMT
Links: << >>  << T >>  << A >>
Arash Salarian wrote:
> Thanks. Yes that's the way to go. The point is that it is now round 3 years 
> that I have not done any new designs using FPGAs but before that (in the 
> Altera's 10K and 20K age!) I used to work actively with both Altera and 
> Xilinx. So basically I know the toolsets quite well but I have never used 
> Cyclone or Spartan and that's why I was wondering.
> Simulator in the Quartus or ISE is not that important for me. I have yet an 
> older version (but a full version!) of ModelSim and I think even though it 
> is old, yet it is much better of any offerings from Altera or Xilinx. At 
> least I can use the full potentials of VHDL and also interface to C codes 
> and much more. 

There are free options as well.  I'm very happy with Icarus Verilog, 
which suits my workstyle much better than a slow GUI.

Tommy

Article: 74514
Subject: Re: EP1C12 or XC3S400?
From: "Arash Salarian" <arash.salarian@epfl.ch>
Date: Wed, 13 Oct 2004 09:34:59 +0200
Links: << >>  << T >>  << A >>
"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message 
news:5t2dnaO327O9DfHcRVn-jg@rogers.com...
>
> The Cyclone 1C12 (www.altera.com/cyclone) has 12060 logic elements (4-LUT 
> +
> FF + goo).  In addition, we believe our LE is more efficient than Xilinx's
> logic element based on benchmarking results of how much we can pack into
> ours; I can't find the stats right now by memory tells me we believe there
> is a ~10% difference in packing density.  The XC3S400 has 8,064 "logic
> cells", or in other words 7168 4-LUT + FF + different goo blocks (Xilinx
> inflates by 12.5% for random marketing reasons).  So as you can see there 
> is
> a large difference in logic capacity.
Thanks for the info Paul. As I see the Xilinx datasheet says 896 CLB. Each 
CLB is four slices and each slice has 2 FF so 896*4*2=7168. Hmmmm, it seems 
my logic of only counting the embedded flipflops works :) Well It seems that 
the EP1C12 is indeed much BIGGER than XC3S400. Your point about the 
multipliers in the Spartan is also interesting. But the fact is that I need 
a board for prototyping and only God knows what I will try on it so I can't 
predict how many times I'll need a multiplier or not (sometimes I do DSP 
designs but not all DSP designs need full multipliers) ant thats why having 
more LEs (or FFs or CLBs or anything) is more important to me.

Just one more question. I remember that in the 10K series (yes, I'm an old 
guy!) the block RAM (EAB?) could also work in a fully asyncronous mode while 
the Xilinx devices at that time did not have this feature (and I used it a 
lot!). Is it the same for Cyclone and Spartan? Does Cyclone supports fully 
async block RAM while Spartan does not?

Regards
Arash 



Article: 74515
Subject: Re: EP1C12 or XC3S400?
From: "Arash Salarian" <arash.salarian@epfl.ch>
Date: Wed, 13 Oct 2004 09:45:09 +0200
Links: << >>  << T >>  << A >>
"Tommy Thorn" <foobar@nowhere.void> wrote in message 
news:AD4bd.17169$54.287148@typhoon.sonic.net...
> Arash Salarian wrote:
>> Thanks. Yes that's the way to go. The point is that it is now round 3 
>> years that I have not done any new designs using FPGAs but before that 
>> (in the Altera's 10K and 20K age!) I used to work actively with both 
>> Altera and Xilinx. So basically I know the toolsets quite well but I have 
>> never used Cyclone or Spartan and that's why I was wondering.
>> Simulator in the Quartus or ISE is not that important for me. I have yet 
>> an older version (but a full version!) of ModelSim and I think even 
>> though it is old, yet it is much better of any offerings from Altera or 
>> Xilinx. At least I can use the full potentials of VHDL and also interface 
>> to C codes and much more.
>
> There are free options as well.  I'm very happy with Icarus Verilog, which 
> suits my workstyle much better than a slow GUI.
>
Well, I've never used Icarus before (maybe because I design most of the time 
in VHDL not in Verilog). But as I see Icarus does not have a waveform view 
(which can be very useful when dealing with complex timings) and also I 
won't call ModelSim a "slow GUI". As far as I know ModelSim is yet one of 
the fastest simulators in the industry and if you don't like GUI, you can 
use almost all of it from command line. In fact you need to do it as 
ModelSim's GUI is just a very thin layer of TCL over the command line tools 
so for any serious job you should write you own scripts. Also I use the code 
coverage tool and the debug mode of the ModelSim quite a lot and I don't 
know if Icarus has the same features or not (I could not find much info in 
the Icarus website). 



Article: 74516
Subject: Re: Interfacing from the analogue domain
From: "Simon Peacock" <nowhere@to.be.found>
Date: Wed, 13 Oct 2004 20:59:32 +1300
Links: << >>  << T >>  << A >>
there's rumours floating around the differential inputs are actually a
comparator...  even safer bet :-)

Simon


"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:ckhf5q$t8u$1@gnus01.u.washington.edu...
>
>
> Thomas Womack wrote:
>
> (snip)
>
> > On the other side of the room, I have some photo-diodes and some
> > LM324N op-amps.  If I rig up an op-amp as a comparator, I can get a
> > signal which swings from 0V to ... umm ... inspect the datasheet
> > ... Vcc - 1.5V.
> >
> > Is there some easy way I can set up the IOBs so that the FPGA believes
> > that 0V is a zero and 1.8V a one?  Or should I rig up another battery
> > to increase the supply voltage to the op-amp by 1.5V or so; in that
> > case I might be setting the input voltage on an FPGA pin to slightly
> > greater than the supply voltage to the FPGA, which seems likely to
> > be painful.
>
> How about a series diode and pull up resistor to increase
> by 0.7V?   Hopefully not too small of a resistor would
> be needed.
>
> -- glen
>



Article: 74517
Subject: Re: EP1C12 or XC3S400?
From: "Simon Peacock" <nowhere@to.be.found>
Date: Wed, 13 Oct 2004 21:05:23 +1300
Links: << >>  << T >>  << A >>
A word of caution here:

Altium or Protel as it was called is a PCB software company... Nextar is
their FPGA development tools and both of these boards are designed to use
Altium's software.  As such support outside this simple parameter will be
non existent.

Simon


"Arash Salarian" <arash.salarian@epfl.ch> wrote in message
news:416bf9fb$1@epflnews.epfl.ch...
> Hi,
>
> I've seen this prototype board from Altium that seems to have a very good
> price: http://www.altium.com/livedesign/
> It comes in two flavours: one with an Altera Cyclone series EP1C12F324C8
and
> the other one with a Xilinx Spartand 3 XC3S400-4F456C. Both options have
the
> same price of $99. Besides the FPGA, the both kits are exactly the same
> thing.
> My question is which one to select? Personally, I'd rather select the
BIGGER
> one but I don't know which one it is. I know it is very difficult to
compare
> the SIZE of two FPGAs with very different architectures.
> I used to compare the total number of the programmable flipflops in the
> FPGAs as my index. (it can be discussed if it is indeed a good index or
not,
> but I think for syncronous and NORMAL designs this is much better than
fuzzy
> things like system gates etc.). It seems that EP1C12 has much more FFs in
> the programable sections than XC3S400.
> So what do you think? Do you think EP1C12 is bigger than XC3S400? For
> designs that would be more of DSP type which one is better? And what for
> designs with a small processor inside?
> Well, one option is to buy both of them as you can easily cascade them an
> use them together in peace :)
>
> Regards
> Arash
>
>



Article: 74518
Subject: Re: Routing PLL output
From: karlIGNORETHISPART@chello.nl (Karl)
Date: 13 Oct 2004 01:17:57 -0700
Links: << >>  << T >>  << A >>
ALuPin@web.de (ALuPin) wrote in message news:<b8a9a7b0.0410112337.6a5097fb@posting.google.com>...
> Some additional thing:
> 
> "Differential" is the wrong expression. I need
> inverted clocks on a 3,3V logic level.
> 
> But in my opinion there is no 180° phase allignment given when
> inverting one of the clocks, isn't there?
> 
> Does QuartusII provide some module to make this phase allignment?
> 
> Thank you.
> 
> Rgds
> André

Hi Andre,

You could use the c0 & c1 output of the PLL's, where you give the c1
an 180 deg shift, and both route them to output pins. The internal
routing within the device and the placement of the pins could give
some phase shift, but you could 'fiddle' around with that a little to
get it working.

Karl.

Article: 74519
Subject: Re: EP1C12 or XC3S400?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 13 Oct 2004 08:25:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
Arash Salarian <arash.salarian@epfl.ch> wrote:
: Well, I've never used Icarus before (maybe because I design most of the time 
: in VHDL not in Verilog). But as I see Icarus does not have a waveform view 
: (which can be very useful when dealing with complex timings) and also I 
Icarus is a simulator. For waveform viewing there are other options, like
gtkview or dinotrace. 

Bye

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 74520
Subject: spartan 3 on 4 layers
From: colin_toogood@yahoo.com (colin)
Date: 13 Oct 2004 01:35:15 -0700
Links: << >>  << T >>  << A >>
Hi guys

I have just finished routing a simple board with a 208 pin qfp spartan
3. I have just used top and bottom layers and it is time to add the
power. I need 3.3v for all IO and the 1.2v and 2.5v for vccint and
vccaux. I have not routed any signal under the spartan on either layer
so I plan to use GND on 1 inner layer and 3.3 on the fourth layer with
an island of 1.2 or 2.5 under the spartan with 2.5 or 1.2 then on the
bottom layer.

Just wondering if anyone can see any holes in this idea.

thanks

colin

Article: 74521
Subject: Re: low cost MPEG4 codec (from Atmel )
From: "Ulf Samuelsson" <ulf@atmel.dot.com>
Date: Wed, 13 Oct 2004 10:35:40 +0200
Links: << >>  << T >>  << A >>
"T Lee" <tony.p.lee@gmail.com> skrev i meddelandet
news:470b6397.0410110645.1d13becc@posting.google.com...
> I don't work for Atmel.  I am interested in knowing how they did it.
> (I am using Xilinx at this time - a few very expensive one.)
>
>
> Since it is from a fpga company, I wonder if it use one of those
> FPGA 2 ASIC conversion process to get such low cost price pointer
> for such complex chip.

No, you might use FPGAs for prototyping, but in the end you synthesize in an
ASIC flow.
The ASIC conversion improve pricing, but not down to standard cell pricing.
Typically you use a gate array, and those are not as effective as standard
cell.
You hardly fit the AT76C120 on a single FPGA, and you are not going to
get any good pricing for the end product.

>
>
> I wonder if has anyone done similar complex SOC chip with
> xilinx/altera?
>
> ....





-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.



Article: 74522
Subject: Re: multiplexing clocks
From: jon@beniston.com (Jon Beniston)
Date: 13 Oct 2004 01:46:10 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<BD90370B.95F8%peter@xilinx.com>...
> Jonathan, the issue could be the asynchronous (?) selection of the clocks. I
> would assume that you can easily generate glitches, and no circuitry likes
> uncontrolled glitches on the global clock lines.
> Virtex global buffers include a mux that can be used to select between two
> inputs with glich-free operation guaranteed.

Can these (BUFGMUX) be used to implement clock-gating? (i.e. if one
input is the clock and the other is tied to 0)?

Cheers,
Jon

Article: 74523
Subject: Re: EP1C12 or XC3S400?
From: "Arash Salarian" <arash.salarian@epfl.ch>
Date: Wed, 13 Oct 2004 11:39:45 +0200
Links: << >>  << T >>  << A >>
"Simon Peacock" <nowhere@to.be.found> wrote in message 
news:416ce1d3@news.actrix.gen.nz...
>A word of caution here:
>
> Altium or Protel as it was called is a PCB software company... Nextar is
> their FPGA development tools and both of these boards are designed to use
> Altium's software.  As such support outside this simple parameter will be
> non existent.

Actually they are now gearing towards more integrated solutions and from 
Protel 99, they used to have a Schematics/PLD/Spice/PCB solution in one 
package so FPGAs are the next logical step.
About the limitations of the evaluation board, as you can see from the 
specs, it supports a normal JTAG interface (using the PC's parallel 
port)that can be used with both Quartus and ISE so there is no problem with 
it if you don't want to use the Altium products for the development. So to 
me, it's just another FPGA prototype board as the others but with a bit 
better price/(density*features).

I myself, used to do my PCBs with Protel (and do the autorouting with 
SPECCTRA) so for me the new FPGA support in the Protel (or Nextar) is 
interesting and I may switch back to Protel in near future again. I don't 
think I'll use Protel/Nextar to actually design/simulate my FPGA based 
designs, but the changes in Schematics/PCB design programs to support FPGA 
based designs are attractive (like handling the pin-assignments based on the 
constrains of the PCB. Try to assign the pins manually for a 700+ pin BGA 
and see what I mean). Also they have a mixed signal simulator which can be 
sometimes useful if you need to mix analog/digital in the same board though 
I'm sure for pure digital simulation, my old trusty ModelSim is much better. 



Article: 74524
Subject: simprim errors
From: yaseenzaidi@NETZERO.com (Yaseen Zaidi)
Date: 13 Oct 2004 03:26:03 -0700
Links: << >>  << T >>  << A >>
I generate a testbench and then do Simulate Post-Translate VHDL Model
in ISE 6.2.03i. Modelsim frowns as follow:

# ** Error: (vcom-19) Failed to access library 'simprim' at "simprim".
# No such file or directory. (errno = ENOENT)
# ** Error: rcvr_translate.vhd(18): Library simprim not found.
# ** Error: rcvr_translate.vhd(19): Unknown identifier 'simprim'.
# ** Error: rcvr_translate.vhd(20): Unknown identifier 'simprim'.
# ** Error: rcvr_translate.vhd(22): VHDL Compiler exiting
# ** Error: C:/Modeltech_5.8d/win32/vcom failed.

I have compiled both simprim and unisim libraries in $Xilinx
directory. The testbench includes the following headers:

library SIMPRIM;
use SIMPRIM.VCOMPONENTS.ALL;
use SIMPRIM.VPACKAGE.ALL;

I like to do post translate/map/PAR timing simulation if I could only
get pass this error.

Thanks,

YZ



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