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 75700

Article: 75700
Subject: Re: Xilinx Webpack, simulate with off-chip-connected-pins? (VHDL)
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 12 Nov 2004 08:29:34 -0800
Links: << >>  << T >>  << A >>
vax, 9000 wrote:
>   Hi group,
>   Sorry to bother you again. I am developing code for a hobby project and I
> need to simulate my design with some off-chip-connected-pins. For example,
> I generate a secondary clock on chip, output it from a pin, and feed it
> into another pin (dedicated clock pin). How do I simulate it? Where do I
> tell the simulator that the two pins are connected? I guess one possible
> place is the test bench vhdl source file, and another possible place is the
> simulator command lines where I 'force' the input pins...

Err, force? Are you using a force file? Please don't do that. Write a 
proper VHDL testbench; google around for some examples. For the example 
you mention above, the code is trivial:

architecture board of bd_top is
    constant CLK_PRD  : Time := 10 nS;
    signal CLK;
    signal CLK_FB;
begin
    UUT: entity work.my_device
      port map (
         CLK => CLK,
         FBCLK_OUT => CLK_FB,
         FBCLK_IN  => CLK_FB
      );

    -- Generate the clock.
    clk_gen: process
    begin
       loop
          Clk <= '1' after CLK_PRD/2, '0' after CLK_PRD;
          wait for CLK_PRD;
       end loop;
    end process clk_gen ;

end architecture board;

-- 
My real email is akamail.com@dclark (or something like that).

Article: 75701
Subject: std_logic_vector(0 downto 0)
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 12 Nov 2004 08:29:48 -0800
Links: << >>  << T >>  << A >>
The Xilinx core generator generates std_logic_vector(0 downto 0) on some
parts like a BUSMUX.  How do you "cast" this IO so that it can be connected
to std_logic without errors?

Brad Smallridge
b r a d @ a i v i s i o n . c o m




Article: 75702
Subject: Re: constraints coverage
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Fri, 12 Nov 2004 16:32:13 GMT
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2004 05:11:23 -0800, "Lars Theodorsson"
<lars.theodorsson@se.flextronics.com> wrote:

>Is there a way to list the unconstrained paths?
>
>The timing report with trace -u only lists the number 
>of unconstrained paths and the maximum delay. I would 
>like to see them to assert that I have not missed a 
>vital path in my constraints.

The timing analyzer has no way of knowing which paths are vital to
you.

Use -u followed by a number, e.g., -u 100, and you'll get a report of
that many unconstrained paths, sorted from longest to shortest.


Bob Perlman
Cambrian Design Works

Article: 75703
Subject: Re: std_logic_vector(0 downto 0)
From: "Andrea Sabatini" <andrea@dapdesign_N_O_S_P_A_M_.com>
Date: Fri, 12 Nov 2004 17:47:48 +0100
Links: << >>  << T >>  << A >>
Brad,

if

a : std_logic_vector(0 downto 0) ;

and

b : std_logic ;

then

b <= a(0) ;

Hope this help,

Andrea


"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10p9p836ut3ila4@corp.supernews.com...
> The Xilinx core generator generates std_logic_vector(0 downto 0) on some
> parts like a BUSMUX.  How do you "cast" this IO so that it can be
connected
> to std_logic without errors?
>
> Brad Smallridge
> b r a d @ a i v i s i o n . c o m
>
>
>



Article: 75704
Subject: Re: std_logic_vector(0 downto 0)
From: "Antti Lukats" <antti@case2000.com>
Date: Fri, 12 Nov 2004 17:50:51 +0100
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10p9p836ut3ila4@corp.supernews.com...
> The Xilinx core generator generates std_logic_vector(0 downto 0) on some
> parts like a BUSMUX.  How do you "cast" this IO so that it can be
connected
> to std_logic without errors?
>
> Brad Smallridge
> b r a d @ a i v i s i o n . c o m

signal_not_vector <= signal_vector_size0(0);

maybe there is other way, but I do the above if needed.
Antti



Article: 75705
Subject: Re: C Compiler for Picoblaze !!!!!
From: cs_posting@hotmail.com (Chris Stratton)
Date: 12 Nov 2004 08:56:32 -0800
Links: << >>  << T >>  << A >>
Jim Granville <no.spam@designtools.co.nz> wrote in message 
> 
> There is an opening for more portable assemblers, call it a "Structured 
> Assembler", or a C-Syntax Assembler, if you will.
> These will always be subsets, but if they implement a common 
> preprocessor, and in-line asm, for example, then it will be possible to
> have one source file that is portable.
>   Eg A design could start on a PC, to develop the algorithm, and then
> be re-coded/optimised as needed, to target tiny cores, like the 
> PicoBlaze, et al.

Isn't that why they make software simulators?

Though I can see the need for portability when you don't yet know how
much work the application will involve to select a suitable processor.

Chris

Article: 75706
Subject: Re: digital analog conversion
From: "Pete Fraser" <pete@rgb.com>
Date: Fri, 12 Nov 2004 09:18:26 -0800
Links: << >>  << T >>  << A >>

"Arash Salarian" <arash.salarian@epfl.ch> wrote in message 
news:419496dd$1@epflnews.epfl.ch...

>
> The critical parameter for you is deltaV / deltaT for the hold state. 
> Typically, this value is round one milivolts per second for a good quality 
> 1u capacitor! So for 5 minutes that would be round 0.3 volts. Maybe you 
> can find a better part than LF198 but the big problem is to find a very 
> high quality capacitor that it's internal impedance is actually much 
> higher than the input impedance of the sample and hold IC.
> The advantage of using ICs like that is their tiny size and small board 
> area (you just need one small IC and one capacitor).
>

But she doesn't need to hold for 5 minutes.
The DAC can be updated at a 1 MHz rate.
If she has 10 outputs, she can refresh each output every ten microseconds.
As long as the DAC and t/h have no serious glitch this has no downside,
and allows the use of small caps without droop. 



Article: 75707
Subject: Obsolete processors resurected in FPGAs
From: "Ryan" <ryanclark410@hotmail.com>
Date: Fri, 12 Nov 2004 17:28:56 GMT
Links: << >>  << T >>  << A >>
As part of an academic project I'm going to be looking at the pros and cons 
of re-producing microprocessors in current FPGA technologies that are no 
longer available on the open market. This is to address the problem that 
occurs in some specialised areas where the lifetime of a product is very 
long and the cost of rewriting the software is prohibitively high (e.g. it 
was written in a language and/or tools that aren't supported anymore). The 
idea is to be able to use an FPGA implementation an either a drop-in 
replacement component onto a legacy board or to produce a new board but of 
identical functionality. Either way, no changes to the application object 
code stored in ROM is required.

There are many different factors that I'll have to look into before I can 
make any conclusions and I'm concerned that some important ones could be 
missed. Obviously there are:
1) Availability of the original processor HDL or equivalent.
2) How can the exact EBI timings of the original be recreated (or how close 
to the original is practical)?
3) Cache memory cannot be recreated on-chip.
4) How close can the internal timings be recreated?
5) Verification ?!

If anyone would like to contribute to this initial brainstorming, I'd be 
grateful.

Rupert. 



Article: 75708
Subject: Basic DVI example?
From: colin@beyondboxes.com (Colin Anderson)
Date: 12 Nov 2004 09:30:27 -0800
Links: << >>  << T >>  << A >>
Has anyone here worked on or have run across a hobbyist-scale project
using DVI video/graphics? I would like to experiment with a DVI
transmitter fed by a dedicated SDRAM framebuffer, but I do not know
where to start. My experience is with PIC- and SX-based projects, but
I'm about to start working with FPGA projects. Any advice is
appreciated!

Article: 75709
Subject: Re: Obsolete processors resurected in FPGAs
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Fri, 12 Nov 2004 13:38:49 -0500
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2004 17:28:56 +0000, Ryan wrote:

> As part of an academic project I'm going to be looking at the pros and cons 
> of re-producing microprocessors in current FPGA technologies that are no 
> longer available on the open market. This is to address the problem that 
> occurs in some specialised areas where the lifetime of a product is very 
> long and the cost of rewriting the software is prohibitively high (e.g. it 
> was written in a language and/or tools that aren't supported anymore). The 
> idea is to be able to use an FPGA implementation an either a drop-in 
> replacement component onto a legacy board or to produce a new board but of 
> identical functionality. Either way, no changes to the application object 
> code stored in ROM is required.
> 
> There are many different factors that I'll have to look into before I can 
> make any conclusions and I'm concerned that some important ones could be 
> missed. Obviously there are:
> 1) Availability of the original processor HDL or equivalent.
Systems that were designed 20 years ago were designed with paper
schematics not HDLs. If the manufacturer still exists, and most of them
are long gone, the designs are going to be hidden away in a long forgotten
file cabinet. The architecture manuals may be still be available some
where, maybe even on the net. I've seen sites devoted to the Data General
machines for example (I was one of the designers of the DG MV8000 in the
late 70s which is why I've looked). The good news is that machines of that
vintage were relatively simple because of the limited number of gates that
we had available. The smallest FPGA has more gates that any minicomputer
of the 70s and the available block RAM in a decent size FPGA exceeds the
main memory sizes of many of those machines. The caches, if any, were
tiny. A couple of block RAMs is enough. Also modern HDLs like Verilog
vastly simplify the design task. One person using Verilog and a decent
simulator can do in a few weeks what it took a team of people a couple of
years to do in the 70s and early 80s.

> 2) How can the exact EBI timings of the original be recreated (or how
> close to the original is practical)?
This probably isn't practical. 

> 3) Cache memory cannot be recreated on-chip. 

Easily done on chip

4) How close can the
> internal timings be recreated? 

It would be hard to reporduce it exactly, but why would you want to?
Minicomputers of the 70s had clock speeds of 5-10MHz, modern FPGAs run at
over 100MHz without any work at all, and much faster if you put even
modest effort into it.

5) Verification ?!
If you can find the orginal diagnostics that would give you a start. In
the 70s machines and early 80s machines were debugged in the lab using
instruction set diagnostics. The prototype machines were built on wirewrap
boards which could be fixed almost as easily as we change a line of
Verilog today. The simulators that existed weren't very good and the
machines that they ran on were too slow to do any serious debugging so
there was no such thing as a testbench as we know it today. The real
debugging was in hte lab.


> 
> If anyone would like to contribute to this initial brainstorming, I'd be
> grateful.
> 
> Rupert.

While it is practical to emulate an obsolete architecture in an FPGA it's
not clear that it's the right thing to do. Using a software emulator is
the more cost effective way to do this. Moores law works out to a factor
of 100 per decade which means that in the last 25 years the
performance/price ratio has improved by a factor of 100,000. Today's
desktop PC is several thousand times faster than the super minicomputers
of the late 70s while being a factor of 100 cheaper. What this means is
that even if took you 100 instructions to emulate a single instruction on
an antique machine the emulator would still run 20-30 times faster than
the original machine did. Of course a decent emulator should be able to do
a lot better than this but my point is that even the crudest software
emulator could do the job.




Article: 75710
Subject: Re: Obsolete processors resurected in FPGAs
From: "mike_treseler" <tres@fl_ke_networks.com>
Date: Fri, 12 Nov 2004 14:53:15 -0500
Links: << >>  << T >>  << A >>
It might be an intriguing exercise, but
but don't expect much outside interest in the
results. Those parts are obsolete for good reasons. 

        -- Mike Treseler


Article: 75711
Subject: Re: VirtexII-Pro MGT: 8/10 coding bypass problems
From: herwin@ee.ucla.edu (Herwin)
Date: 12 Nov 2004 12:19:54 -0800
Links: << >>  << T >>  << A >>
mrand@my-deja.com (Marc Randolph) wrote in message news:<15881dde.0411101917.47c12fef@posting.google.com>...
> herwin@ee.ucla.edu (Herwin) wrote in message news:<6314bb40.0411101033.43e00fd4@posting.google.com>...
> [...]
> > Here is the situation.  Using a 50Mhz oscillator I am trying to
> > achieve a channel bit rate of 1Gbps in 8/10 bypass mode.  For every 20
> > bits, I am transmitting 5 'ones' in random positions.  This should
> > ensure that I have at least 1 transition every 20 bits and enough for
> > the PLL to lock on to the clock.  What I am seeing is that the bit
> > error rate is very high (>0.1).  This is the case even when I set the
> > MGT to serial bypass mode.  What can be the cause of this since this
> > configuration introduces no transmission losses?
> 
> Howdy Herwin,
> 
> I'm not sure what serial bypass mode is - did you mean 8b/10b bypass?

The system runs with 8/10 bypass, and the tests that I performed used
the serial loopback mode.  Parallel loopback works perfectly.  The
clock that I am using is directly from a crystal oscillator from Sunstu (SOVB25T).
Indeed, I am now suspecting that the jitter requirement has been
violated.  I am now trying to investigate what this jitter is on
this part.

As for how the reference clock is routed:  The signal is first fed through
an input buffer.  The output net is connect to both a DCM (for the logic)
and the MGT reference clock input.

Thanks a lot for the feed back

Herwin

Article: 75712
Subject: Re: Obsolete processors resurected in FPGAs
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 13 Nov 2004 09:56:46 +1300
Links: << >>  << T >>  << A >>

Ryan wrote:

> As part of an academic project I'm going to be looking at the pros and cons 
> of re-producing microprocessors in current FPGA technologies that are no 
> longer available on the open market. This is to address the problem that 
> occurs in some specialised areas where the lifetime of a product is very 
> long and the cost of rewriting the software is prohibitively high (e.g. it 
> was written in a language and/or tools that aren't supported anymore). The 
> idea is to be able to use an FPGA implementation an either a drop-in 
> replacement component onto a legacy board or to produce a new board but of 
> identical functionality. Either way, no changes to the application object 
> code stored in ROM is required.
> 
> There are many different factors that I'll have to look into before I can 
> make any conclusions and I'm concerned that some important ones could be 
> missed. Obviously there are:
> 1) Availability of the original processor HDL or equivalent.
> 2) How can the exact EBI timings of the original be recreated (or how close 
> to the original is practical)?
> 3) Cache memory cannot be recreated on-chip.
> 4) How close can the internal timings be recreated?
> 5) Verification ?!
> 
> If anyone would like to contribute to this initial brainstorming, I'd be 
> grateful.

  A good place to start, is to look at what is already out there.
This is a good launch site
http://www.lug-kiel.de/links/details/hdl.html

Look at devices like 6502, 6809, & 8080 as simpler examples of cores 
that have a wider code base, but are not active hardware any more.

Peripheral logic is likely to be as much/more work than the core.

There is also a lot of work being done on game-machine emulation.

Someone has mentioned SW emulation, for an interesting take on that
see
http://www.xilinx.com/publications/xcellonline/xcell_48/xc_picoblaze48.htm

[this uses a Soft CPU in a FPGA to SW Emulate a more complex CPU ! ]

Where you have spare speed, this approach can save resource.

  What would be interesting research, would be a tool chain that allowed
a soft-boundary and generic approach to the replacement of any core.
  The most flexible emulation, would be to start using a tinycore, and
calling Target Opcode Sw emulation blocks. This gets the system working, 
but at a lower speed.
  Then, you analyse the blocks, and target the frequent/slow ones, to be 
replaced by either FPGA Logic resource, or opcode extension on the 
original core.

-jg



Article: 75713
Subject: Re: Obsolete processors resurected in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 12 Nov 2004 15:28:34 -0600
Links: << >>  << T >>  << A >>
>Someone has mentioned SW emulation, for an interesting take on that
>see
>http://www.xilinx.com/publications/xcellonline/xcell_48/xc_picoblaze48.htm
>
>[this uses a Soft CPU in a FPGA to SW Emulate a more complex CPU ! ]

There was a time when it was common to implement instruction
sets by writing microcode that ran on real hardware.  The general
idea on the ones I'm familiar with was to use a wide instruction
word that was easy to decode and simple to implement.  (and ran
very fast)

It might be fun to do that in an FPGA.  I wonder how much it takes
to implement a 6502 or such.

-- 
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: 75714
Subject: Re: DDR Mux - how does it work?
From: gabor@alacron.com (Gabor Szakacs)
Date: 12 Nov 2004 13:29:57 -0800
Links: << >>  << T >>  << A >>
It's clear that the "mux" is really an integral part of the
DDR flop design.  It has been suggested that the individual
flip-flops are not really wired as shown, but rather wired so that
the outputs can be XORed together to form the final Q output.
This method does not have a glitch if the Q doesn't switch.
See VHDL code below.

The only reason I can see to use 180 DCM output (which uses extra
global routing resources) is if the clock you're using is not
50% duty cycle.  Normally DCM outputs are adjusted to 50% unless
you tell the tools specifically not to.  Thus using 0 phase clock
and its inverse (yes the inverter is pulled into the IOB) gives
just as good results.  I think newer reference designs use this
method instead of the 0 and 180 method.

I have used DDR flops as clock drivers because they make a good
low skew (but not zero delay) copy of a global clock signal without
extra routing resources related to using multiple DCM phases or
2x clocks.  They also neatly match the data delay in DDR SDRAM
designs.

newman5382@aol.com (Newman5382) wrote in message news:<20041112103601.06264.00000418@mb-m18.aol.com>...
> Just as a follow-up: The original question is a good one.  When one sees a 2:1
> mux, one may wonder if it is susceptable to static hazard one and static hazard
> zero glitches.  I've seen that Xilinx recommends using this component for clock
> forwarding, which implies that it is not subject to such.  When I reviewed the
> design in the FPGA editor, the inverter in the C1 path was apparently absorbed
> into the IOB.  In some App note for high speed designs, it was recommended that
> the 180 DCM output be used for C1.  Since my design was not high speed, and I
> was running out of clock buffers on that side of the chip, I opted for the
> merged inverter.  Apparently the "DDR Mux" uses two clocks, and it is unclear
> exactly how it does that.
> 
> - Newman

>From anonymous source:

There was a post a while back on comp.lang.vhdl about double edged
clock circuits, and one of the responses included code for a double
edged register built from two single edged registers and three XOR
gates.

Basically, the way it worked was that the state of the DDR register
was encoded as follows: Whenever the states of the two individial
registers was different, the output was a '1', whenever they were the
same, it was a zero.  The following code will synthesize in
synplify-pro, but might have to be split into separate processes for
other tools. It creates a multiple-"bit" DDR "register", using SDR
registers, with parameterizable size and reset value, through vhdl
generics (it cannot puch this into an IOB's DDR register)

I don't know if this is the circuit that Xilinx uses or not (note that
if one flop is held in reset, the circuit reverts to single edge
functionality), but the output "mux" is really just an XOR gate, and
no clocks are needed!

  library ieee;
  use ieee.std_logic_1164.all;
    entity ddrff is
     generic (size   : positive := 1;
              rstval : std_logic_vector := (0 => '0') --
unconstrained, defaults to 1 bit
             );
     port (d     : in  std_logic_vector(size - 1 downto 0);
           q     : out std_logic_vector(size - 1 downto 0);
           clk   : in  std_logic;
           rst   : in  boolean
           );
  end ddrff;

  architecture rtl of ddrff is
     signal qr, qf : std_logic_vector(d'range);
  begin
  -- Double Data Rate Flip Flop Circuit
  -- two bit state is encoded as follows:
  -- if flops differ, the 'value' is '1'
  -- if flops match, the 'value' is '0';
  -- therefore either flop (on either edge) can change the state or
  -- keep it the same, and a simple xor gate decodes the state to
  -- produce the output
  -- output is glitch free
 
  main:
     process (rst,clk) is
     begin
        if rst then
           qr <= (others => '0');
           qf <= rstval;
        elsif rising_edge(clk) then
           qr <= qf xor d;
        elsif falling_edge(clk) then
           qf <= qr xor d;
        end if;
     end process;
         -- decode output
     q <= qr xor qf;
  end rtl;

Article: 75715
Subject: Re: DDR Mux - how does it work?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 12 Nov 2004 15:48:42 -0600
Links: << >>  << T >>  << A >>
>It's clear that the "mux" is really an integral part of the
>DDR flop design.  It has been suggested that the individual
>flip-flops are not really wired as shown, but rather wired so that
>the outputs can be XORed together to form the final Q output.

I started thinking along that line.  I couldn't make it work.

Consider the case where the FFs are fed by 1/0 constants
to make a clock.  The value of the FFs never changes.

I'm sure the actual implementation has some interesting magic.


>The only reason I can see to use 180 DCM output (which uses extra
>global routing resources) is if the clock you're using is not
>50% duty cycle. ...

At least one place in the Xilinx documentation suggests using
clk and clk180 in preferance to clk and clk-inverted for better
results.  I think the idea was that there is more skew on
rising vs falling edges as compared to loaded and not-loaded
clock distribution nets.

Might be fun to measure.  I wonder how hard it would be to make
something that balanced the clock loading.  Probably doable
in FPGA editor by hand for a one-shot experiment.


>I have used DDR flops as clock drivers because they make a good
>low skew (but not zero delay) copy of a global clock signal without
>extra routing resources related to using multiple DCM phases or
>2x clocks.  They also neatly match the data delay in DDR SDRAM
>designs.

You could use a DLL with external feedback if you want to
avoid that delay.  But that delay doesn't matter for the normal
clock forwarding case.


-- 
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: 75716
Subject: Re: Xilinx and Altera -- maximum total bitrate for high-speed serial I/O
From: davidg@altera.com (Dave Greenfield)
Date: 12 Nov 2004 15:00:03 -0800
Links: << >>  << T >>  << A >>
Ian,
Stratix II GX will elevate LE count, increase transceiver speed, and
increase channel count. I think the majority of chip-to-chip and
backplane requirements in the next generation will be better addressed
by transceiver speeds in the 5-6 Gbps range than in the 10-12 Gbps
range based on supporting infrastructure required. More details on
Stratix II GX are available today with an NDA.

Dave Greenfield
Altera Marketing
> > 
> > I've been trying to work out what total serial I/O capability is
> > available on the latest (and near future!) FPGAs, but it's not always
> > easy. In the timescales I'm looking at I guess that the likely
> > candidates are Virtex-4 (for which little information is available on
> > the MGTs), and whatever the "next-generation" Altera device is
> > (Stratix-II doesn't have serial I/O, Stratix GX does but may be
> > lacking in processing power) -- can anyone at Altera give any clue
> > about this?
> > 
> > > > 
> > Cheers
> > 
> > Ian Dedic
> > Chief Engineer
> > Mixed Signal Division
> > Fujitsu Microelectronics Europe
> > 
> > P.S. If there are things which can only be revealed under NDA, please
> > contact me off-list since we have NDAs with both Xilinx and Altera.

Article: 75717
Subject: Re: digital analog conversion
From: langwadt@ieee.org (Lasse Langwadt Christensen)
Date: 12 Nov 2004 15:39:48 -0800
Links: << >>  << T >>  << A >>
"Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote in message news:<cn1vol$r7k$1@news.cs.tu-berlin.de>...
> Just to put my aim in perspective: I'm neither trying to fool you nor trying
> to get my homework solved (like a given individual presumed). Why I am
> talking about a basic condition with respect to the "one D/A converter for
> multiple output channels"-configuration is that this single D/A converter
> already exists in hardware. It is there, physical, for me to touch, already
> bought... And now I want to use this very D/A converter to feed several
> output channels. Of course I could buy a DAC for every channel but that's
> not my intention. The hardware setup does not allow to solder other devices
> on the board. So PLEASE just take it as it is! I want to solve the problem
> that way. So don't try to proselytize me like that jehovah's witnesses
> guys... ;-)
> 
> Hope you come up with more constructive suggestions!
> 
> Veronica

ok, what you want is a sample-and-hold for each channel and yes that could
be a cap a switch and an opamp buffer, the "droop" will depend on the capacitor
and what's discharging it (don't forget that cap is self)

you say you can't solder anything on the board, but you can fit several opamps
high quality switches and caps?  what will control the switches? 

A multiple output DAC give you all of it in a single package, it so much
simpler and most likely better...

you do sound a little like the jehovas witnesses ;) 

-Lasse

Article: 75718
Subject: Re: digital analog conversion
From: jonathan.bromley@doulos.com (Jonathan Bromley)
Date: 12 Nov 2004 18:36:22 -0800
Links: << >>  << T >>  << A >>
"Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote in message news:<cn1vol$r7k$1@news.cs.tu-berlin.de>...
> Just to put my aim in perspective: I'm neither trying to fool you nor trying
> to get my homework solved (like a given individual presumed). Why I am
> talking about a basic condition with respect to the "one D/A converter for
> multiple output channels"-configuration is that this single D/A converter
> already exists in hardware. It is there, physical, for me to touch, already
> bought... And now I want to use this very D/A converter to feed several
> output channels. Of course I could buy a DAC for every channel but that's
> not my intention. The hardware setup does not allow to solder other devices
> on the board. 

Presumably you have space for the analogue sample/hold or demux
arrangements?

> So PLEASE just take it as it is! I want to solve the problem
> that way. So don't try to proselytize me like that jehovah's witnesses
> guys... ;-)

Well, I won't try to proselytise, but you really need to know that
some problems just *can't* be solved "as it is"!  Maybe the solution
can be found only if you re-frame the problem somewhat...

Since you want DC-like output, it seems to me that the best way would
be to make a bank of sample/hold circuits, one per output channel,
and refresh them as frequently as possible.  The digital value
corresponding to each channel's output can be held in an internal
register or small RAM bank, and the one-and-only DAC can be cycled
round all these values continuously.  That way, the sample/hold
circuits don't need particularly special droop performance and
they could probably be built using simple analogue switches and
small-value capacitors. It would require just a little extra logic 
in your FPGA, of course, but it sounds like only half an afternoon's 
work to me.

Alternatively, why not abandon the dedicated DAC altogether, and
provide one single FPGA output per analogue channel?  These
digital outputs can then be pulse-width modulated by logic inside
the FPGA, and low-pass filtered on the output side by a simple 
single-stage RC.  Once again, the fact that you are trying to 
create "DC" outputs comes to your aid: the RC filter can be
quite brutal (have a very long time constant), simplifying
the PWM design.

I know of no straightforward analogue sample/hold that can give
you very low droop over a period of minutes.  Consequently, your
original approach to the problem is unworkable.  No proselytising,
just good old-fashioned experience!
-- 
Jonathan Bromley

Article: 75719
Subject: Spartan3 Block RAM from WebPACK
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 12 Nov 2004 20:58:13 -0600
Links: << >>  << T >>  << A >>
Is it possible to use the Block RAMs in the Spartan3
with the (free) WebPACK software?  If so, how?

I'm playing with the Spartan3 starter kit and trying to make
a ROM.  I'd expect to find something in the library package.
I can't find anything there other than tiny ones using CLBs.

Looks like the normal path is to use Coregen, but that's not
part of WebPACK.  I could use a machine with Coregen installed
on it to do the "gen" part, but that makes something that's
tangled up with the Coregen libraries.  (Maybe that tangle is
only the simulation libraries. But everybody would snicker if
I didn't simulate.)

Am I just overlooking something simple?  (If so, what's the
magic word.)

-- 
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: 75720
Subject: Re: digital analog conversion
From: cs_posting@hotmail.com (Chris Stratton)
Date: 12 Nov 2004 19:29:54 -0800
Links: << >>  << T >>  << A >>
"Veronica Matthews" <ikeepthespiritalive@freenet.de> wrote in message news:<cn1vol$r7k$1@news.cs.tu-berlin.de>...
> Just to put my aim in perspective: I'm neither trying to fool you nor trying
> to get my homework solved (like a given individual presumed). Why I am
> talking about a basic condition with respect to the "one D/A converter for
> multiple output channels"-configuration is that this single D/A converter
> already exists in hardware. It is there, physical, for me to touch, already
> bought... And now I want to use this very D/A converter to feed several
> output channels. Of course I could buy a DAC for every channel but that's
> not my intention. The hardware setup does not allow to solder other devices
> on the board. So PLEASE just take it as it is! I want to solve the problem
> that way. So don't try to proselytize me like that jehovah's witnesses
> guys... ;-)

How quickly and how often can you cycle through the channels?  If you
can afford to do it at a high rate to refresh the outputs, the
sample/hold requirements may be fairly simple.

At the extreme, if you have a fast enough clock and can afford to
devote on on-chip counter per chanel, or a fair amount of processor
attention to the problem, you can just use pulse width modulation of
your chanel selects to produce your outputs, without needing any
external "DAC hardware" at all.  Or look at doing sigma-delta
modulation.

Don't rule out the possibility that you may find multichanel outboard
DAC's that take up less board space than whatever analog sample/hold
solutions you could come up with.

Chris

Article: 75721
Subject: Re: Obsolete processors resurected in FPGAs
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Sat, 13 Nov 2004 04:07:23 GMT
Links: << >>  << T >>  << A >>
"mike_treseler" <tres@fl_ke_networks.com> wrote in message 
news:b0118205e8cb94b0184ad5644ab2a5f0@localhost.talkaboutelectronicequipment.com...
> It might be an intriguing exercise, but
> don't expect much outside interest in the
> results. Those parts are obsolete for good reasons.


True.

It only becomes interesting when you have an application that cannot be 
economically or practically replaced by software re-writes or a desktop PC.

I heard that the space shuttle is having a hard time sourcing 8086 chips.
These were decent in the late seventies when the shuttle was developed.

Many military flight systems suffer from part obsolescence.

Concorde used many analogue computers. It was never going to be economic to 
upgrade those to modern technology and test them all.

In all the cases above, it is too dear to re-write code and impractical to 
stick in a modern PC running an emulator. A Blue Screen of Death might 
easily become a White Hot Screen of Death.

It is interesting to look at space craft over the years.

The early space craft looked rather like pinball machine panels.

The recent Spaceship One cockpit looked like a it had a single LCD panel and 
a joystick.


In another field, the wartime Colossus is said to be on a par with recent 
PCs, but internal workings are still quite closely guarded. Partly because 
the guy looking at it regards it as his project a lot, and doesn't want to 
give too much away. He is also under the official secrets act, so there's 
always the risk of having a suspicious suicide in the woods. ;-)





Article: 75722
Subject: Re: DualPortRAM serial IN - parallel OUT
From: "Simon Peacock" <nowhere@to.be.found>
Date: Sat, 13 Nov 2004 20:26:38 +1300
Links: << >>  << T >>  << A >>
I don't believe you can... The 20k RAM is some what specialized as compared
with more modern FPGAs. But why not just use a 16bit shift register on the
input?

Simon

"Manfred Balik" <e8825130@stud4.tuwien.ac.at> wrote in message
news:41945fa6$0$11614$3b214f66@tunews.univie.ac.at...
> Is it possible to configure a DualPartRAM in an Altera APEX20KE (using
> Quartus II 4.1) to
> write serial to the RAM (1 Bit) and
> read parallel from the RAM (16 Bit)?
>
> Thanks, Manfred
>
>



Article: 75723
Subject: Re: Obsolete processors resurected in FPGAs
From: "Alex Gibson" <al xx at tpg dot com dot au - remove spaces replace dot>
Date: Sat, 13 Nov 2004 18:29:11 +1100
Links: << >>  << T >>  << A >>

"Hal Murray" <hmurray@suespammers.org> wrote in message 
news:nNednVl0h_eftgjcRVn-hQ@megapath.net...
> >Someone has mentioned SW emulation, for an interesting take on that
>>see
>>http://www.xilinx.com/publications/xcellonline/xcell_48/xc_picoblaze48.htm
>>
>>[this uses a Soft CPU in a FPGA to SW Emulate a more complex CPU ! ]
>
> There was a time when it was common to implement instruction
> sets by writing microcode that ran on real hardware.  The general
> idea on the ones I'm familiar with was to use a wide instruction
> word that was easy to decode and simple to implement.  (and ran
> very fast)
>
> It might be fun to do that in an FPGA.  I wonder how much it takes
> to implement a 6502 or such.

quite a few 6502 cores available

www.opencores.org

www.fpgaarcade.com
http://home.freeuk.com/fpgaarcade/platforms.htm  vic20,6502
http://home.freeuk.com/fpgaarcade/pac_main.htm z80

http://zxgate.sourceforge.net/  zx81 ,zx spectrum, jupiter ace, trs80

http://www.fpga-games.com/

commadore 64 http://c64upgra.de/c-one/
http://www.howell1964.freeserve.co.uk/logic/index_logic.htm  lots of stuff 
see the links

Alex 



Article: 75724
Subject: Re: Spartan3 Block RAM from WebPACK
From: "Simon Peacock" <nowhere@to.be.found>
Date: Sat, 13 Nov 2004 20:31:34 +1300
Links: << >>  << T >>  << A >>
there is lots missing from the webpack.  but you can still use memory in
vhdl or verilog by just describing it :-) just infer it.  there are a few
examples in webpack of this

Simon

"Hal Murray" <hmurray@suespammers.org> wrote in message
news:RuednZqh6-LY5QjcRVn-hQ@megapath.net...
> Is it possible to use the Block RAMs in the Spartan3
> with the (free) WebPACK software?  If so, how?
>
> I'm playing with the Spartan3 starter kit and trying to make
> a ROM.  I'd expect to find something in the library package.
> I can't find anything there other than tiny ones using CLBs.
>
> Looks like the normal path is to use Coregen, but that's not
> part of WebPACK.  I could use a machine with Coregen installed
> on it to do the "gen" part, but that makes something that's
> tangled up with the Coregen libraries.  (Maybe that tangle is
> only the simulation libraries. But everybody would snicker if
> I didn't simulate.)
>
> Am I just overlooking something simple?  (If so, what's the
> magic word.)
>
> -- 
> 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.
>





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