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 72625

Article: 72625
Subject: Re: ring oscillator calibration
From: eternal_nan@yahoo.com (Ljubisa Bajic)
Date: 26 Aug 2004 15:47:43 -0700
Links: << >>  << T >>  << A >>
Hi Uwe,

How can he control the speed at which the individual gates are
switching? Are you suggesting he should make the inverter chain long
to prevent the inverters from switching often or something else?

Thanks,
Ljubisa

Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message news:<cgk5oq$m6m$1@lnx107.hrz.tu-darmstadt.de>...
> Siva Velusamy <sv7d@adder.cs.virginia.edu> wrote:
> 
> : Thanks everyone for the suggestions.
>  
> : The problem was clearly due to difference in routing. Using FPGA Editor's
> : directed routing, I obtained the routing information for one particular
> : placement, and simply copied them over for all other instances only
> : substituting the correct net names. Now all the frequencies are in a 2%
> : range, far better than the 10% earlier.
>  
> : Peter - Could you explain a bit more about how to use the carry chain?
> : From the docs I could see that the carry chain goes up vertically through
> : the slices, so I understand the part about automatic floorplanning - but
> : how exactly should I configure them? There is no local connection between
> : Cin and the CI/DI inputs. So I cannot directly send the carry signal as
> : the select for the subsequent mux. Also, for this application I don't have
> : any target frequency - I only need a predictable response with variation
> : in temperature. So I probably don't need more stages.
>  
> : Kevin - Yes, I am trying to measure the temperature over different parts
> : of the die. Specifically I am interested in the temperature gradient.
> : There have already been papers (in FPGA 04 for instance) that have shown
> : that a gradient exists.
> 
> Well, 
> 
> if you are interested into the thermal behaviour, you probably don't want to
> run the stages of the ring oscillator at nearly full gate speed, as this
> will contribute to (local) heating...
> 
> Bye

Article: 72626
Subject: Re: 6.1 vs. 6.2
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 26 Aug 2004 16:28:43 -0700
Links: << >>  << T >>  << A >>


These options are nice, especially Read_First (Read before write).
 They might even help relative timing between ports, provided both ports use
the same clock. But we do not guarantee this, since you would then rely on
excellent timing tracking between adjacent ports of the BlockRAM circuitry.
Peter Alfke>

> Actually in the newer BlockRAM implementations, you can choose the
> behaviour (at least you can on the Spartan-3, whose datasheets I've been
> poring over recently :-)
> 
> There's:
> 
> o READ_FIRST, which will always report the value of the data
> in RAM before the write was committed
> 
> o WRITE_FIRST, which will provide the unpredictable behaviour
> you mention (and it's the default, to provide backwards
> compatibility)
> 
> o NO_CHANGE, which seems to disconnect the output RAM so the
> output value remains unchanged.
> 
> I doubt anything would help you if you simultaneously write into the
> same address on both ports, though :-)
> 
> Simon.


Article: 72627
Subject: Re: 6.1 vs. 6.2
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Thu, 26 Aug 2004 17:48:48 -0600
Links: << >>  << T >>  << A >>


Simon wrote:
> Brian Philofsky wrote:
> 
>>
>>
>> <snip>
> 
> 
> Actually in the newer BlockRAM implementations, you can choose the 
> behaviour (at least you can on the Spartan-3, whose datasheets I've been 
> poring over recently :-)
> 
> There's:
> 
>   o READ_FIRST, which will always report the value of the data
>     in RAM before the write was committed
> 
>   o WRITE_FIRST, which will provide the unpredictable behaviour
>     you mention (and it's the default, to provide backwards
>     compatibility)
> 
>   o NO_CHANGE, which seems to disconnect the output RAM so the
>     output value remains unchanged.
> 
> I doubt anything would help you if you simultaneously write into the 
> same address on both ports, though :-)


This is a mis-conception many fall into.  Those modes apply only to the 
port that is being written to.  In other words, the output of the port 
being written has this known behavior you specify above but as for the 
other port, everything I said still applies regardless of which mode you 
have it in.


--  Brian


Article: 72628
Subject: Re: 6.1 vs. 6.2
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 26 Aug 2004 20:52:07 -0500
Links: << >>  << T >>  << A >>
>These options are nice, especially Read_First (Read before write).
> They might even help relative timing between ports, provided both ports use
>the same clock. But we do not guarantee this, since you would then rely on
>excellent timing tracking between adjacent ports of the BlockRAM circuitry.

Then there is skew in the clock distribution network(s).
(Ugh.  My head hurts.)

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 72629
Subject: Xilinx DCM Spread Spectrum feature
From: "Kevin Neilson" <kevin_neilson@removethiscomcast.net>
Date: Fri, 27 Aug 2004 04:24:13 GMT
Links: << >>  << T >>  << A >>
The Xilinx DCM was originally supposed to have a spreading feature which
would smear the output clock's spectrum to reduce EMI.  There are some
inputs on the DCM, called DSS_MODE and DSSEN, I think, that are for this
feature.  I wanted to use this feature recently and it seems to be
unsupported.  What happened?  Does it not work?  -Kevin



Article: 72630
Subject: Re: 6.1 vs. 6.2
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 26 Aug 2004 21:45:50 -0700
Links: << >>  << T >>  << A >>
Brian Philofsky wrote:

> If you are reading from one port of a RAM and
> at the approximately same time writing to the other at the same address,
> there is no tell whether the read data will be the old data, the new
> data or something in-between.

A controller is required to provide arbitration
as it is for any shared resource.
In a synchronous design, both sides use
the same clock, and all is well.

> Timing simulation also ensures your design is properly constrained and
> nothing is missed during static timing analysis (is that path really a
> multi-cycle path? Can you safely ignore timing on this path? 

A multi-cycle can be eliminated with adequate pipelining.

> Did you miss anything?

Not if all inputs are registered and 
all processes are synchronous.

> Are you certain the synthesis tool
> interpreted your code they way you think it did?

I have never had a problem with the standard synchronous templates.
I would run a few gate sims if I were validating a new synthesis tool
or inference template. I do check the utilization report and
the edif schematic viewer after each synthesis.

> Were there delays in the code, 

Static timing would catch that.

> missed items in the sensitivity list,

No. Just reset and clk.

> misconnnected components  
> or other things in the code to make it behaviorally simulate different
> than it was implemented by synthesis?

A bad wire will be picked up in the functional sim.
The more you infer, the fewer wires you will have.

> If you are prepared with your testbench to do timing simulations, in
> general not too much time or overhead needs to be spent at this step and
> at minimum it will be another check off the list of ensuring the design
> is properly verified and all things have been considered.

Certainly it is not hard to do, and it should be done at least
once as a release check-off item. However, it should not be a part
of the edit-sim-edit flow.

> Many times it 
> will save far more time than is spent here especially if you do find an
> issue such as above that can not be easily identified by other
> verification methods.

If a problem is found at the gate level, 
either a new design rule, or better enforcement 
is indicated.

Thanks for the posting.

  -- Mike Treseler

Article: 72631
Subject: Xilinx Spartan II and 5V PCI
From: "Christian E. Boehme" <boehme@os.inf.tu-dresden.de>
Date: Fri, 27 Aug 2004 06:46:22 +0200
Links: << >>  << T >>  << A >>
Hello all,

I am using a Xilinx Spartan II FPGA on a prototype PCI add-in card
as the PCI device attached to the bus.  According to the Spartan II
data sheet it appears that 5V PCI compatible IOs are indeed instantiable
which was the very reason for going with a Spartan II in the first place.

However, after correlating the appropriate requirements from the PCI spec
with what is claimed in the Spartan II data sheet I am not 100% positive
about true 5V PCI compliancy without extra circuitry (namely clamping
diodes to the 5V rail) because the PCI spec requires that a device with-
stand AC worst case voltages of +11V down to -5.5V respectively while the
data sheet gives +7V down to -2V which more or less resembles only the
3.3V PCI AC requirements.  Notice that I am concerned about the over
and under voltages during switching and not the DC or ``5V tolerance''
behaviour of the device.

So, has anyone experienced problems with using Spartan II FPGAs in
typical (read: off-the-shelf el cheapo PCs) 5V PCI environments ?
And while I am at it, should the PCI CLK signal ideally be routed to
one of the GCK{0|1|2|3} inputs with IBUFG_PCI33_5 instantiated ?
Am I wrong with the assumption that the the dedicated pins (/PROGRAM,
Done, M0, M1, M2, and CCLK) only allow a high level of Vccint ?

Any help is greatly appreciated.


Thanks and regards,
Christian Boehme


Article: 72632
Subject: Xilinx XC9572XL delay prediction
From: "Christian E. Boehme" <boehme@os.inf.tu-dresden.de>
Date: Fri, 27 Aug 2004 06:47:49 +0200
Links: << >>  << T >>  << A >>
Hello all,

I am evaluating the use of a Xilinx XC9572XL CPLD vs. standard logic
hardware for the glue logic between a Spartan II FPGA and an on-board
FLASH device used to store the configuration bit stream.  This mainly
follows the idea presented in XAPP079 only that the configuration mode
will be Slave Parallel.  Specifically, I found it impossible to calculate
the overall propagation delay of the (ripple?) counter presented in the
design which is needed to determine the maximum clock frequency fed to
the FLASH address counter.  I am looking for something similar to the
CLB FF delay timings in the FPGA data sheets.

Anyone know how to determine said delay without actually implementing
and measuring it ?


Thanks and regards,
Christian Boehme


Article: 72633
Subject: Re: 6.1 vs. 6.2 - one more question
From: =?ISO-8859-1?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se>
Date: Fri, 27 Aug 2004 08:16:21 +0200
Links: << >>  << T >>  << A >>
I'd like to thank everyone for their input on the subject. I also want=20
to make clear that the cores in my design that I've created myself are=20
thoroughly simulated and analyzed. However, the system includes some=20
cores from CoreGen as well (filters, CORDIC, DDS etc) and I find it hard =

to create a meaningful input to simulate the whole system, and that is=20
when I use ChipScope to watch the behavior of the different parts.

One question is still unanswered though, and I'd really appreciate some=20
input on this matter. How come that a system that synthesized perfectly=20
fine in ISE 6.1 also does that in ISE 6.2, but with a lower performance=20
(i.e. much more noise etc)? I have checkes all the coregen cores that I=20
utilize and they are all the same version. I have also checked my own=20
logic, and it seem to synthesize the same way, but still the result is=20
so much better using 6.1.

Johan

--=20
-----------------------------------------------
Johan Bernsp=E5ng, xjohbex@xfoix.se
Embedded systems designer
Swedish Defence Research Agency

Please remove the x's in the email address if
replying to me personally.

Article: 72634
Subject: Re: X propagation in Timing Simulation
From: muthusnv@yahoo.co.in (Muthu)
Date: 26 Aug 2004 23:28:00 -0700
Links: << >>  << T >>  << A >>
jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0408260854.32175499@posting.google.com>...
> muthusnv@yahoo.co.in (Muthu) wrote in message news:<4f8e807b.0408260230.2b5aaf74@posting.google.com>...
> > Hi,
> > 
> > In a timing simulation, Setup / Hold violation of Flip-Flop will
> > result in value of 'x' at the output. Is that Right?
> 
> Usually.
> 
> > If so, how double synchronisation circuits work in timing simulation ?
> > Won't it propagate x. ?
> 
> See part 12.0 in this very good paper:
> 
> http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf
> 
> Cheers,
> JonB

Thank you all..

Regards,
Muthu S

Article: 72635
Subject: Re: DDR SDRAM
From: ALuPin@web.de (ALuPin)
Date: 27 Aug 2004 00:07:49 -0700
Links: << >>  << T >>  << A >>
Marcus Harnisch <marcus.harnisch@gmx.net> wrote in message news:<86fz69bmmg.fsf@dipsy.harnisch.local>...
> Hi Andre,
> 
> Don't get me wrong, but if you are trying to decypher the waves at the
> SDRAM interface it would help if you'd know about some of the basics
> of DDR SDRAMs. The "usual suspects" (Micron, Samsung, etc.) provide
> good datasheets for download. JEDEC79x (x >= C) might be a little
> dry but is certainly the most comprehensive source of information in
> that respect.
> 
> Good luck,
> Marcus

Hi Marcus,

could you tell me where to find that JEDEC79x ?

Thank you

André

Article: 72636
Subject: Re: ring oscillator calibration
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 27 Aug 2004 07:40:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ljubisa Bajic <eternal_nan@yahoo.com> wrote:
: Hi Uwe,

: How can he control the speed at which the individual gates are
: switching? Are you suggesting he should make the inverter chain long
: to prevent the inverters from switching often or something else?

The longer the chain, the less switching per inverter per time. Obvious he
can control the spped  of a single inverter...  

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

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

Article: 72637
Subject: Re: Altera MAX II
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Fri, 27 Aug 2004 09:47:25 +0200
Links: << >>  << T >>  << A >>

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:mirXc.451$mZ2.46793@news02.tsnz.net...
> Luiz Carlos wrote:
> >>PS Also missing from this spin, is the fact that the cheapest
> >>previous-generation MAX devices, are actually cheaper than the
> >>cheapest MAX II devices.
> >>  ie the price per resource unit has declined, but the
> >>minimum unit-cost step has actually increased, because they
> >>pruned the two smallest offerings.
> >
> >
> > Jim,
> >
> > Do you mean the 32 and 64 macrocells MAX1 devices are dead?
>
>   Not yet, but they did not move forward a generation.
> That means if you are starting a new design, you should look
> carefully at vendors whose parts have moved forward recently.
>

Could it perhaps be simply that there are relatively few customers looking
for Max 2 features in something as small as a 32 or 64 macrocell PLD, and
thus the Max 1 convers that sector perfectly adequetly?  Think about what
changed with the Max 2 architecture - the Max 1 use a traditional CPLD
architecture, which requires routing resources that scale badly with
macrocell count, making large chips proportionally very expensive.  The Max
2 uses more fpga-style routing, which does scale well, making large chips
proportionally cheaper.  Thus the Max 2 is suited to bigger cplds, while the
Max 1 suits small ones.

And what makes you think that Altera bringing out the Max 2 means they will
stop making the Max 1?  No doubt there will be little further development of
the current Max 1 line - it's a mature product, doing a perfectly good job.
The larger parts will become less popular as they are replaced by Max 2 in
designs, but Altera is unlikely to pull out of the small pld market segment
just because they've now got a better part for a different market segment.
They are a business, and they are not stupid - as long as people want small
cpld's, they'll keep making them.  As to whether they will invest in making
future generations of small plds which are faster, lower-power, etc. - we'll
just have to wait and see.

Note - I don't have any connection with Altera other than as a user, and I
also think the "four times the density at half the price" slogan was a bit
misleading.  And it could be that Jim has some insider information that I
don't have, but I think the suggestion that they will be dropping their
small cplds just because they've got better big cplds sounds like pure FUD.



> > And the 128 macrocells MAX1 is cheaper than the "198 macrocell" MAX2?
>
>   The asymptope price mentioned for MAX II is $1.50, which is quite
> a lot higher than the cheapest MAX1.
>   Thus if you have a smallish amount of logic, and want some of the MAX
> II features, or even a reduction in power, but no increase in price,
> then you are out of luck.
>   Altera has left that market sector behind, but MAX II WILL have a
> significant impact on the biggest CPLDs.
>
>   Fortunately in the 32/64 MCell area, there are still Xilinx, Lattice,
> and Atmel, all with low power devices.
>
>   My point was really that when marketing trumpet 'half the price'
> that's not always the whole story :)
>
> -jg
>



Article: 72638
Subject: Re: problem with DDR
From: vinodece@yahoo.co.in (vinod)
Date: 27 Aug 2004 02:11:45 -0700
Links: << >>  << T >>  << A >>
Brian Philofsky,
Thank u for ur response..i made changes in my stimulus as u told
stimuli : process 
begin 
wait for 20 ns;
reset <= '1';
 
wait for 120 ns;
reset <= '0';

 
 
wait;
end process stimuli;
 and i made simulation once again but @180 ns the rising edge data '0'
of d comes to q1 in same rising edge ..actually it shud come at
falling edge.. it is correct in functional simulation... i am getting
same wrong result even if I used IFFDDRSE primitive .

can u check this plz..

thank u
vinod


Brian Philofsky <brian.philofsky@no_xilinx_spam.com> wrote in message news:<412E568B.9020503@no_xilinx_spam.com>...
> Vinod,
> 
> I would guess that the reason you are seeing a functional difference 
> would be due to the fact that you are not waiting until the global 
> set/reset signal to complete.  For all Xilinx gate-level simulations, a 
> global set/reset pulse is generated for the first 100 ns of the design 
> to initialize all of the registers and simulate the effect for the GSR 
> signal in simulation.  For the first 100 ns of the design, the registers 
> will be in reset and will not change value.  If you hold off you 
> stimulus for the first 100 ns of simulation (keep your clock running and 
> initialize the inputs but just don't wiggle them yet), you will likely 
> see more correlation between your behavioral and post-translate simulation.
> 
> Also, if you are desiring to have the DDR register pulled into the I/O 
> and use the dedicated resource, you should be instantiating the IFDDRRSE 
> in the design.  The code you are creating will use two separate 
> registers but not the dedicated DDR registers in the I/O.
> 
> 
> --  Brian
> 
> 
> vinod wrote:
> 
> > i am vinod..i got problem with ddr for virtex2 fpga. i have written
> > code and did functional simulation everything is correct but after
> > post translate simulation i am not getting same result. here is my
> > code and testbench
> > 
> > code: 
> > library ieee; 
> > use ieee.std_logic_1164.all; 
> > library UNISIM;
> > use UNISIM.VCOMPONENTS.ALL;
> > 
> > entity input_ddr is 
> > Port ( d : in std_logic; 
> > reset : in std_logic;
> > clk : in std_logic; 
> > dataoutx : out std_logic;
> > dataouty : out std_logic
> >  ); 
> > end input_ddr; 
> > 
> > architecture input_ddr_arch of input_ddr is 
> >  
> > 
> > signal q1, q2 : std_logic; 
> >  
> >  
> > 
> > begin 
> >  
> >  
> >  
> > 
> > process (clk,d,reset) 
> > begin 
> > 
> > if reset = '1' then
> >   q1 <= '0';
> >   dataoutx <= '0';
> > 
> > elsif  rising_edge(clk) then 
> > q1 <= d; 
> > dataoutx <= q1;
> > end if; 
> > end process; 
> > 
> > process (clk,d,reset)
> > begin 
> > if reset = '1' then
> >  q2 <= '0';
> >  dataouty <= '0';
> > elsif  falling_edge(clk)  then 
> > q2 <= d; 
> > dataouty <= q2;
> > end if; 
> > end process; 
> > 
> >  
> > 
> > end input_ddr_arch; 
> > 
> > testbench....
> > library ieee; 
> > use ieee.std_logic_1164.all;  library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.numeric_std.all;
> > use IEEE.STD_LOGIC_1164.ALL;
> > use IEEE.STD_LOGIC_ARITH.ALL;
> > use IEEE.STD_LOGIC_UNSIGNED.ALL;
> > library UNISIM;
> > use UNISIM.VCOMPONENTS.ALL;
> > 
> > entity tbddr is
> > end entity tbddr;
> > 
> > architecture test2 of tbddr is
> > component  input_ddr is 
> > Port ( d : in std_logic; 
> > reset : in std_logic;
> > clk : in std_logic; 
> > dataoutx : out std_logic;
> > dataouty : out std_logic
> >  ); 
> > end component ; 
> >  
> > 
> > component FDDRRSE is
> > port (
> > 
> > Q : out STD_ULOGIC;
> > C0 : IN STD_ULOGIC;
> > C1 : IN STD_ULOGIC;
> > CE  :IN STD_ULOGIC;
> > D0 : IN STD_ULOGIC;
> > D1 : IN STD_ULOGIC;
> > R  :IN STD_ULOGIC ;
> > S : IN STD_ULOGIC
> > );
> > end component;
> > 
> >  
> >  
> > signal risdatax,faldatax : std_ulogic;
> > signal dataoutx,dataouty : std_logic;
> > signal count : natural range 0 to 15;
> > --signal cnt : natural range 0 to 40;
> > signal ind : std_logic;
> > signal S,R,cE :std_logic;
> >  
> > signal data : std_ulogic_vector(15 downto 0):="1101000111010101";
> > signal data1 : std_ulogic_vector(15 downto 0):= "1001011100011100";
> > --signal data2: std_ulogic_vector(15 downto 0):= "0010100111001011";
> > signal clk,invclk,  reset :std_logic;
> > signal clk2 ,d : std_logic;
> > begin
> > 
> > --clk2 <= not  clk;
> > 
> > 
> > uut1: input_ddr
> > port map (
> >  d   => d,
> >  clk  => clk,
> > reset => reset,
> > dataoutx => dataoutx,
> > dataouty => dataouty
> >   
> >  
> > );
> > 
> > 
> > FDDRRSEx : FDDRRSE
> > port map (
> > 
> > Q => d,
> > C0 => clk,
> > c1 => invclk,
> > CE => ce,
> > 
> > d0  => risdatax,
> > d1 =>  faldatax,
> > r => '0',
> > s => '0'
> > );
> > 
> >  
> >  
> > clock1 : process
> > begin
> >  clk <= '1';
> >  invclk <= '0';
> > wait for 10 ns;
> > 
> > clk <= '0';
> > invclk <= '1';
> > wait for 10 ns;
> > end process;
> > 
> > stimuli : process 
> > begin 
> > wait for 20 ns;
> > reset <= '1';
> >  
> > wait for 40 ns;
> > reset <= '0';
> > 
> >  
> >  
> > wait;
> > end process stimuli;
> > 
> > process(clk,reset,ind)
> > begin 
> >   if reset  = '1' then
> >     count <= 0;
> > 	 ce <= '0';
> > 	 risdatax <= '0';
> > 	 faldatax <= '0';
> > elsif clk'event and clk = '1' then
> >   
> >  ce <= '1';
> >   risdatax <= data(count);
> >   faldatax <= data1(count);
> >   if count < 15 then
> >   count <= count+1;
> >    elsif count = 15 then
> > 	  count <= 0;
> >   end if;
> >   end if;
> >   
> >  end process;
> > end test2;
> > 
> > 
> > 
> > i have used FFDDRSE primitive in testbench for generating double data
> > rate.
> > 
> > i will be waiting for reply...
> > 
> > thanks in advance
> > bye

Article: 72639
Subject: Re: ring oscillator calibration
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 27 Aug 2004 22:42:58 +1200
Links: << >>  << T >>  << A >>
Uwe Bonnes wrote:
> Ljubisa Bajic <eternal_nan@yahoo.com> wrote:
> : Hi Uwe,
> 
> : How can he control the speed at which the individual gates are
> : switching? Are you suggesting he should make the inverter chain long
> : to prevent the inverters from switching often or something else?
> 
> The longer the chain, the less switching per inverter per time. Obvious he
> can control the spped  of a single inverter...  
   [can't]

  The effect may be more subtle than that. Switching power is
Sigma(Fn x Cn) x Vcc^2, Fn reduces in proportion with chain count,
but the Cn increases, so ignoring buffering effects the ring osc
itself will be nominally constant power.
  The power density will decrease, as that power is spread over
more die, and it is probably also a good idea to gate/enable the 
oscillator, to further minimise the self-heating effects.

  That effect could be used to actually measure the local hot-spot
effects caused by low node counts, running very fast.


  The power to measure the Freq will be another cost, and again
that will favour lower frequencies - until you consider gating,
and obtaining a fixed resolution / unit time.
  Here, higher freqs use more power, but allow lower % GATE times
for a given resolution/ms.
-jg


Article: 72640
Subject: Re: Altera MAX II
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 27 Aug 2004 23:02:52 +1200
Links: << >>  << T >>  << A >>
David Brown wrote:

> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
>>>Jim,
>>>
>>>Do you mean the 32 and 64 macrocells MAX1 devices are dead?
>>
>>  Not yet, but they did not move forward a generation.
>>That means if you are starting a new design, you should look
>>carefully at vendors whose parts have moved forward recently.
>>
> 
> 
> Could it perhaps be simply that there are relatively few customers looking
> for Max 2 features in something as small as a 32 or 64 macrocell PLD, and
> thus the Max 1 convers that sector perfectly adequetly?  Think about what
> changed with the Max 2 architecture - the Max 1 use a traditional CPLD
> architecture, which requires routing resources that scale badly with
> macrocell count, making large chips proportionally very expensive.  The Max
> 2 uses more fpga-style routing, which does scale well, making large chips
> proportionally cheaper.  Thus the Max 2 is suited to bigger cplds, while the
> Max 1 suits small ones.
> 
> And what makes you think that Altera bringing out the Max 2 means they will
> stop making the Max 1?  No doubt there will be little further development of
> the current Max 1 line - it's a mature product, doing a perfectly good job.
> The larger parts will become less popular as they are replaced by Max 2 in
> designs, but Altera is unlikely to pull out of the small pld market segment
> just because they've now got a better part for a different market segment.
> They are a business, and they are not stupid - as long as people want small
> cpld's, they'll keep making them.  As to whether they will invest in making
> future generations of small plds which are faster, lower-power, etc. - we'll
> just have to wait and see.

You can still buy EPROMs too, which are mature products doing a 
perfectly good job :)

> Note - I don't have any connection with Altera other than as a user, and I
> also think the "four times the density at half the price" slogan was a bit
> misleading.  And it could be that Jim has some insider information that I
> don't have, but I think the suggestion that they will be dropping their
> small cplds just because they've got better big cplds sounds like pure FUD.

  I did not say Altera are dropping the small cplds, merely noting that 
they did NOT move forward a generation.
  Others have moved their smaller cplds forward, to lower Icc and lower
mA/MHz.

  If you already have a Max1 device designed in, sure, why change ?

  If you are doing a new design, that's very different, and the high Icc 
of the Max 1 families is looking 'old fashioned' against the other
offerings.

-jg



Article: 72641
Subject: Modelsim: ROM initialisation
From: Adam <>
Date: Fri, 27 Aug 2004 05:17:53 -0700
Links: << >>  << T >>  << A >>
I am using Modelsim XE II/Starter 5.7g to try and mdoel some ROM that I have instantiated using COREGEN. 

I have associated a .COE file with the ROM in COREGEN with the values that I would like. 

However I get an error message in Modelsim when I try to run the simulation saying "failed to open VHDL file "romvalues.mif" in rb mode". 

Does anyone know how I can set up the initial values in the ROM? 

Thanks very much 

Adam Morris 


Article: 72642
Subject: DSP & FPGA Resource Guide
From: phopper@opensystems-publishing.com (Patrick Hopper)
Date: 27 Aug 2004 06:00:32 -0700
Links: << >>  << T >>  << A >>
The first ever DSP & FPGA Resource Guide is now available at www.dspengineering.com

Article: 72643
Subject: Replace for Altera ByteBlaster II -- Minford MF160 FPGA and CPLD Downloader
From: jamesw789@yahoo.ca (James Wang)
Date: 27 Aug 2004 06:44:16 -0700
Links: << >>  << T >>  << A >>
Hi Friends,

Minford Technology has Altera FPGA and CPLD downloader, it can replace
Altera ByteBlaster II directly and work in AS mode, PS mode, JTAG
mode.

It supports all Altera FPGA, CPLD and configuration devices (EPC,
EPCS1 and EPCS4).

For more technical or ordering information, please visit us at
www.minford.ca, we ship our products worldwide.
Very low price compared with Altera ByteBlaster II(US$150)


Sincerely,

James Wang

Minford Technology Inc.

Tel: 1 (416) 953-8926
E-mail: info@minford.ca

Article: 72644
Subject: FPGA Board Newsletter August 2004
From: "Tony Burch" <tony@burched.com.au>
Date: Fri, 27 Aug 2004 23:44:20 +1000
Links: << >>  << T >>  << A >>
FPGA Board Newsletter August 2004
BurchED - Making FPGA Prototyping Easy!
http://www.burched.biz

In this newsletter:
(1) Did you break your FPGA?
(2) New products
(3) New upgrade offers for current customers
(4) Reminder - please keep in touch
(5) User website spotlight for August

(1) Did you break your FPGA?
Great news, if you blew up your FPGA!
BurchED now offers replacement of the XC2S300E FPGA on
your board, and we will mail it back to you, all for free!
http://www.burched.biz/FreeStuff.html

(2) New Products
* Sydney-X1E:
     Following on from the successful release of the
     Sydney-X1 FPGA development system, BurchED has now
     released the Sydney-X1E.  While the Sydney-X1 is
     a lower cost and compact system, the Sydney-X1E is
     a more expandable system in a larger box, with
     a "quick release" lid.
     http://www.burched.biz/sydneyx1e.html
* A range of "Bulk Saver Packs":
     Significant savings for quantity purchases.
     Ideal for setting up University Laboratories.
     http://www.burched.biz/BulkSaverPacks.html

(3) New upgrade offers for current customers
     Great offers for owners of BurchED products.
     An opportunity to get the latest boards and systems,
     at special prices.  Offers include upgrade to a Sydney-X1E.
     http://www.burched.biz/UpgradeDeals.html

(4) Reminder - please keep in touch
Please remember, as a customer or user of BurchED products,
you are very welcome to email us at any time with questions,
comments, or for discussion.  We are always interested to hear
about your latest projects and applications.
Drop us a line at tony@burched.com.au

(5) User website spotlight for August
Keith Howell, in Cambridge, England.
http://www.howell1964.freeserve.co.uk/logic/burched/fpga_devkit_b5.htm
Keith has been a valued customer of BurchED for many
years, and he is a guy with alot of great technical ideas.
His website provides a very interesting read, and
he is available for FPGA consulting work, so please
contact him if you require FPGA design services.



Article: 72645
Subject: Re: EPM7064LC44-7 - Not there in Quartus II...
From: dhruvish@gmail.com (Drew)
Date: 27 Aug 2004 07:09:33 -0700
Links: << >>  << T >>  << A >>
Well,

Seems like I have to buy some EPM "SLC" packages. Now the question
will be from where I can buy EPLDs in very less quantities? Arrow
Electronics which is vendor of Altera ships them in more then 900. I
need only couple of them and I can buy upto 20-25. Please let me know.

Drew

"Antti Lukats" <antti@case2000.com> wrote in message news:<cgklvf$9k9$03$1@news.t-online.com>...
> "Drew" <dhruvish@gmail.com> wrote in message
> news:ad2011c0.0408260441.39841b@posting.google.com...
> > Hello guys,
> >
> > I am trying to Assign the Max Family EPLD - EPM7064 LC44-7 and run my
> > compilation. But in the Assign Device I find EPM7064 SLC44-7. There
> > are some significant differences between LC and SLC in terms of Max
> > allowable freq, LCELL delay etc. Please let me know if anybody can
> > find it in the Assign Device section.
> 
> its not there! all the devices with no JTAG ISP are dropped from Quartus,
> you need to use MAXPLUS !
> but you need a special programmer to program those old PLDs anyway, you can
> not program them with byteblaster !
> 
> Antti

Article: 72646
Subject: How to Figure out EPLD can be socketed or not!
From: dhruvish@gmail.com (Drew)
Date: 27 Aug 2004 07:36:11 -0700
Links: << >>  << T >>  << A >>
Helo Guys,

I am sort of new to it. I need to buy some EPLD which can be socketed
so that I can remove and put another one it it. The problem I am
having is, looking solely by the device package name (PLCC, TQFP) I
cant tell its socketed or not. How do I know which one is socketed
simply by looking at the device name. Say, EPM3032ALC44-4 and
EPM3032ATC44-4.

Please let me know,
Drew

Article: 72647
Subject: Re: Xilinx DCM Spread Spectrum feature
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 27 Aug 2004 07:36:32 -0700
Links: << >>  << T >>  << A >>
Kevin,

No, it does not work.

Basically it spread the spectrum by the FCC test method and reduced 
power by only 1.5 dB.  Not enough to do anything.  It was a case where I 
got too clever, and did not do an FFT during simulation.  The feature 
makes the periods alternately longer and shorter (great for adding 
jitter to check to see if you have enough slack in your timing! 100, 
200, up to 500 ps of jitter).

Unfortunately the modulation frequency is 1/21 the clock frequency, 
which makes the modulation at too high a frequency to spread the spectrum.

We do have an (internal)app note for really spreading the spectrum 
(better than 20 dB reduction in carrier).  Ask your FAE about it.  It 
uses one DCM as the master, tracking the clock.  A second DCM is run in 
test mode as a tap controlled oscillator.  The tap values of the first 
DCM are read out, and jammed into the second DCM.  The second DCM is not 
phase or frequency locked, but does generate a spread spectrum clock. 
As a practical test (it looked too good to be true), I used a narrowband 
FM receceiver at 50.000 MHz, and was clearly able to get an S9 signal 
unspread, and could not break squelch when the spreading was enabled. 
The short term jitter added turns out to be relatively small (less than 
200 ps p-p) as the modulation frequency is now very low (compared to the 
old every 21th clock).  Basically, there is a low frequency 'wander' 
that is providing the spreading.

Future products may bring back the feature (working) once we have a 
'best' method for doing it in an all digital fashion (using the DCM).

If you want more details, you may also just email me directly.

Austin

Kevin Neilson wrote:
> The Xilinx DCM was originally supposed to have a spreading feature which
> would smear the output clock's spectrum to reduce EMI.  There are some
> inputs on the DCM, called DSS_MODE and DSSEN, I think, that are for this
> feature.  I wanted to use this feature recently and it seems to be
> unsupported.  What happened?  Does it not work?  -Kevin
> 
> 

Article: 72648
Subject: Re: Modelsim: ROM initialisation
From: Vincent <vincent.blablabla@blablabla.com>
Date: Fri, 27 Aug 2004 15:57:03 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------090902040809040404000403
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Modelsim needs a *.MIF file to know what is the ROM initialization in 
behavioral simulation. I am not sure if COREGEN creates one for you but 
I think so.
Anyway, if you change the coe file you have to regenerate the CORE to be 
sure ISE take it into account.
Find attached an example of a MIF file and COE file.
I hope this helps.

Vincent.

Adam wrote:
> I am using Modelsim XE II/Starter 5.7g to try and mdoel some ROM that I 
> have instantiated using COREGEN.
> 
> I have associated a .COE file with the ROM in COREGEN with the values 
> that I would like.
> 
> However I get an error message in Modelsim when I try to run the 
> simulation saying "failed to open VHDL file "romvalues.mif" in rb mode".
> 
> Does anyone know how I can set up the initial values in the ROM?
> 
> Thanks very much
> 
> Adam Morris


--------------090902040809040404000403
Content-Type: text/plain;
 name="instmem_core.mif"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="instmem_core.mif"

10001100010000010000000000000001
00000100011000010000000000000001
00000100011000110000000000000001
10000100011000110000000000000001
10000100011000110000000000000001
00010000100000010000000000000000
00010000100000010000000000000001
00010000100000000000000000000001
00010000100000000000000000000000
00010000100000000000000000000001
00010100101000010000000000000001
00010100101000000000000000000000
00010100101000010000000000000000
00010100101000000000000000000000
00010100101000000000000000000001
00011100110000010000000000000001
00011100110000010000000000000000
00011100110000010000000000000001
00011100110000000000000000000001
00011100110000010000000000000001
00011100110000000000000000000000
00011100110000010000000000000001
00100100000000100000000000000000
10100100000000110000001000000000
10100100000001000000010000000000
10100100000001010000011000000000
10100100000001100000100000000000
00100000111000000000000000000000
10100001000000000000001000000000
10100001001000000000010000000000
10100001010000000000011000000000
10100001011000000000100000000000
01001000000000010100011000000001
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
01010010000000000000000000000000
00000000000000000000000000000000

--------------090902040809040404000403
Content-Type: text/plain;
 name="instructions.coe"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="instructions.coe"

memory_initialization_radix=2;
memory_initialization_vector=
10001100010000010000000000000001,
00000100011000010000000000000001,
00000100011000110000000000000001,
10000100011000110000000000000001,
10000100011000110000000000000001,
00010000100000010000000000000000,
00010000100000010000000000000001,
00010000100000000000000000000001,
00010000100000000000000000000000,
00010000100000000000000000000001,
00010100101000010000000000000001,
00010100101000000000000000000000,
00010100101000010000000000000000,
00010100101000000000000000000000,
00010100101000000000000000000001,
00011100110000010000000000000001,
00011100110000010000000000000000,
00011100110000010000000000000001,
00011100110000000000000000000001,
00011100110000010000000000000001,
00011100110000000000000000000000,
00011100110000010000000000000001,
00100100000000100000000000000000,
10100100000000110000001000000000,
10100100000001000000010000000000,
10100100000001010000011000000000,
10100100000001100000100000000000,
00100000111000000000000000000000,
10100001000000000000001000000000,
10100001001000000000010000000000,
10100001010000000000011000000000,
10100001011000000000100000000000,
01001000000000010100011000000001,
00000000000000000000000000000000,
00000000000000000000000000000000,
00000000000000000000000000000000,
01010010000000000000000000000000,
00000000000000000000000000000000,
00000000000000000000000000000000;

--------------090902040809040404000403--

Article: 72649
Subject: Re: DSP/FPGA/video board?
From: "Georgi Beloev" <gbH8SPAM@beloev.net>
Date: Fri, 27 Aug 2004 08:03:31 -0700
Links: << >>  << T >>  << A >>
Thanks to all who responded! I think I have a better picture of what's
available now.

-- Georgi


"john jakson" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0408260622.6bc86a66@posting.google.com...
> "Georgi Beloev" <gbH8SPAM@beloev.net> wrote in message
news:<SYydnTMglL5u-7fcRVn-gw@megapath.net>...
> > Hi,
> >
> > I'm looking for an inexpensive (up to $1000) development board with the
> > following features:
> >
> > - Relatively fast DSP, e.g., Blackfin.
> > - Mid-range Cyclone II or Spartan-3 FPGA.
> > - At least 4 MB SDRAM.
> > - Video in (CVBS and Y/C), digital video decoder.
> > - Video out (CVBS and Y/C),  digital video encoder.
> > - The video decoder and encoder should be able to work simultaneously.
> >
> > A combination of boards, e.g., a DSP kit and a plug-in FPGA board can
also
> > work. Other DSPs and FPGAs than the ones mentioned above can also be
> > considered. This is for doing research on video processing and video
> > compression; I don't have more precise requirements yet.
> >
> > Thanks,
> > -- Georgi
>
> Usual place to start is
>
> http://www.fpga-faq.com/FPGA_Boards.shtml
>
> Nallatech comes to mind but there are a few others that do DSP+FPGA too.
>
> Google <dsp fpga video boards> gives me plenty to start by
> $1k is cutting it on the low side for some of these vendors.
>
>
>
> http://www.entegra.co.uk/c6416_pmc_fpga_dsp_quadia.htm
>
> http://www.nuhorizons.com/products/xilinx/DSP/index.html
>
> http://www.lyrtech.com/DSP-development/educational/index.php
>
> http://www.traquair.com/catalog/microline.products.html
>
> http://www.mangodsp.com/
>
> http://www.hunteng.co.uk/solutions/imagesys.htm
>
>
> and so on
>
> regards
>
> johnjakson_usa_com





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