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 106175

Article: 106175
Subject: Re: Who is your favourite FPGA guru?
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 8 Aug 2006 13:00:36 -0700
Links: << >>  << T >>  << A >>
Two of my favorites:
 Ray Andraka
 Mike Treseler

Brad Smallridge
aivision
 



Article: 106176
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: "ZHI" <threeinchnail@gmail.com>
Date: 8 Aug 2006 13:15:00 -0700
Links: << >>  << T >>  << A >>
My algorithm is to solve the linear equation R.h=3Db, (R matrix ,b vector
is known, generated in Matlab). R,b are  transmitted to FPGA board.
After the application caculation, h is sent back to Matlab.
I set the number of trials is 100. it will no problem. If
trials=3D100000, it will happen the "accidently stop" in Matlab.
I guess you are right that it looks like memory leak. I tried a simple
test.
Numbers from 1 to 100 transmit from Matlab to FPGA board(UART) and send
them back. These numbers are sent back correctly. If i send the number
from 1 to 1000 to UART. The matlab will show like that:
(InputBufferSize=3D512 in my matlab version)
----------------------------------------------------------------
 Error using =3D=3D> serial.fread
SIZE * PRECISION must be less than or equal to InputBufferSize.
Error in =3D=3D> testuart at 17
y=3D fread(s,1000,'uint8');
-------------------------------------------------------
I am not sure if i say it clearly. Hope you can help me to figure it
out.
Thanks a lot.

Zhi



Mike Treseler wrote:
> ZHI wrote:
>
> > The Matlab
> > always
> > show busy but not continue to next trial. I have to close Matlab and
> > try again. The phenomenon happens every time. Is this the problem of my
> > vhdl codes=EF=BC=9F
>
> Sounds like a Matlab bug. Open a case with them.
>
> > But how can it successuflly work for some trials (even
> > reached 9883 trial)?
>
> Memory leaks are like that.
>
> >   How to fix it?
>
> Upgrade Matlab.
> Maybe try a different computer.
>=20
>   -- Mike Treseler


Article: 106177
Subject: Re: verilog versus vhdl
From: fpga_toys@yahoo.com
Date: 8 Aug 2006 13:47:27 -0700
Links: << >>  << T >>  << A >>

Evan Lavelle wrote:
> Actually, you can make your VHDL or Verilog description much more
> abstract than this. I've recently been working with some very abstract
> VHDL code, some of which was untimed, and some of which used functions
> and procedures rather than explicit hierarchy. It was also very
> dependent on passing around large records, and letting the synthesiser
> get rid of the unused bits. The untimed code relied on register
> retiming in DC (which I think XST supports).
>
> Personally, I really hate this sort of code. It was synthesising to
> about 75 logic levels between clocks before I started hacking it.

Following the links in Mike's posting proved to be interesting, as it
references indirectly this great piece, which makes the same arguments
about why you don't want to let hardware designers avoid a high level
of design abstraction, as they will dig the same deep unmaintainable
hole that assembly language provides for programmers, and their
employers.

http://www.designabstraction.co.uk/Articles/Advanced%20Synthesis%20Techniques.htm

And clearly, the bottom line is well stated by this articles
introductory "Scope" section.

> It'll never happen; already been tried, failed. Hacking low-level
> hardware semantics into existing C++ semantics just gives you a
> verbose and complex mess, which is nowhere near as concise and clear
> as a VHDL or Verilog description. Great for modelling, non-starter for
> real-world synthesis.

Having to work with some horrible "concise and clear" VHDL, I have to
disagree. Job security by obscurity in a botched VHDL design that LACKS
reasonable high level abstraction is exactly why in my mind that TTL
designers should not be allowed to write TTL designs in VHDL/Verilog.
That those constructs need to be removed from a production language
that is general use, to specifically force mantainable coding
standards, that improve productivity and maintainability over the long
term.


Article: 106178
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: "Peter Alfke" <peter@xilinx.com>
Date: 8 Aug 2006 13:52:43 -0700
Links: << >>  << T >>  << A >>
Michael, I thought you wanted to use an FPGA (Virtex-4) for the
receiver.
Then you can use any oscillator frequency you want, and modify it with
the DCM inside the FPGA. The decoder design that I sent you has a very
wide data capture range, but slightly less when you go to 4x
oversampling (instead of my 8x).
Peter
==========
Michael Dreschmann wrote:
> On 8 Aug 2006 11:30:03 -0700, "Peter Alfke" <peter@xilinx.com> wrote:
>
> >But I prefer a dedicated oscillator, because it uses less power, and
> >uses an internal chip that is optimized for the purpose, and is
> >manufactured by a company with expertise and a single-minded goal. And
> >it hardly costs extra...
>
> Costs are no problem, it's a university project and not a design for
> production.
> I thought a crystal in combination with the cpld would need less power
> than a dedicated oscillator. Could you give me a hint where to find a
> 100 MHz low power oscialltor working at 2.5V? An external oscillator
> of course would be easier.
> An other question concerning power:
> If I have a design that fits exactly in a xc2c64a cpld and I use the
> next bigger one (xc2c128) with the same design how much more would be
> the power consumption (roughly)?
> 
> Thanks,
>  Michael


Article: 106179
Subject: Avnet V2Pro dev board "Hello world"
From: Alex Iliev <iliev@nimbus.dartmouth.edu>
Date: Tue, 08 Aug 2006 16:58:19 -0400
Links: << >>  << T >>  << A >>
Hi,

I'm trying to get started with logic programming on this board
(ADS-XLX-V2PRO-DEVP20-6), ie. VHDL and no processors, and what could be easier
than flashing the LEDs. However, I haven't had any luck yet. Does anyone have
any such simple code which works the LEDs on this board? Or the serial line for
that matter, anything to enable me to get feedback from it. If you want to see
my efforts thus far, read on...

The best data to go by seemed to be Avnet's OPB-mem example project, which
includes a part to flash the LEDs (but driven by the processor). I ran that LED
test successfully, then tried to use it to guide my own code. I used their UCF
file almost verbatim, and wrote a simple VHDL entity which sets all the relevant
enable bits (I think I got them right, quite possibly not) and puts a constant
signal on the data bus, which should then drive the LEDs. However, no such luck
- they don't respond at all when I download the code to the board.

My speculations as to the problem:

- I missed or mis-set some enable bits,

- Something needs to transition for the LED register to be loaded. I tried to
  transition the LED_CS_L signal, didn't help.

If anyone has time to look at the short VHDL file at the end, and perhaps see
what's wrong, that'd be fantastic.

I'm using ISE 8.1, downloading code over JTAG for now.

Thanks!

alex



-- main.vhd
-- Author: Alex Iliev
-- Entity based on Avnet's OPB-mem sample project


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

-- synthesis translate_off
library UNISIM;
use UNISIM.vcomponents.all;
-- synthesis translate_on



entity main is
   
   -- these are the names used by Avnet for their ucf file, so this is just an
   -- entity to allow mapping my names to their names and using their ucf file
   -- as closely as possible.
   
   port (
--      OPB_Clk      : in    std_logic := '0';
      
--      A            : out   std_logic_vector(0 to 31);  -- A, OE, WE, D are shared flash & sram
      OE_L         : out   std_logic;
--      RST_L     : out    std_logic;
      
      SDRAM_CE_L   : out   std_logic;

      -- sasho: for the reset button
      SYS_RESET_N  : in    std_logic;
      
      WE_L         : out   std_logic;

      D            : inout std_logic_vector(0 to 31);

      FLASH_CS_L   : out   std_logic_vector(0 to 0);
      SYS_ACE_CS_N : out   std_logic;

      GPIO_CS_N    : out   std_logic;
      LED_CS_L     : out   std_logic;

      -- sasho: changed this from inout in the example project to 'out' here.
      SRAM_CS_L    : out std_logic_vector(0 to 0) -- set up as vector to match output of platgen

--      SRAM_BS_L    : out   std_logic_vector(0 to 3)   -- SRAM byte select

      );
   

end main;




architecture Behavioral of main is

   -- notice this is LSB on the left, like the D bus declaration taken from the
   -- system_top entity.
   signal data_write : std_logic_vector(0 to 31);
   
   component IOBUF port
                      ( O  : out std_logic;
                        IO : inout std_logic;
                        I  : in std_logic;
                        T  : in std_logic);
   end component;

begin
   
   -- IOBUF for the D port. We don't need to read anything so the reading port
   -- is open.
   g1 : for i in D'range generate
      iod0 : IOBUF port map 
         (I  => data_write(i),
          IO => D(i),
          O  => OPEN,
          T  => '0'                     -- enable output/disable tristate
          );
   end generate g1;


   data_write <= X"AAAAAAAA";
   LED_CS_L     <= '0';


   OE_L         <= '1';
   WE_L         <= '0';                -- not sure if this WE_L is correct or
                                        -- needed. 

   -- disable all other peripherals on the data bus.
   SRAM_CS_L    <= "1";
   SDRAM_CE_L   <= '1';
   FLASH_CS_L   <= "1";
   
   
   -- these are tied to '1' as in the OPB_mem project.
   SYS_ACE_CS_N <= '1';
   GPIO_CS_N    <= '1';


end Behavioral;


Article: 106180
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: michaeldre@gmx.de (Michael Dreschmann)
Date: Tue, 08 Aug 2006 21:24:49 GMT
Links: << >>  << T >>  << A >>
On 8 Aug 2006 13:52:43 -0700, "Peter Alfke" <peter@xilinx.com> wrote:

>Michael, I thought you wanted to use an FPGA (Virtex-4) for the
>receiver.
>Then you can use any oscillator frequency you want, and modify it with
>the DCM inside the FPGA.

Of course, I'm looking for an oscillator for the transmitting cpld. He
also needs 100 MHz to generate the data stream but as far as I know
there is now DCM or PLL in a CoolRunner 2. Or am I wrong?
On the receiver side power and oscillator is no problem.

Michael

Article: 106181
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: "Peter Alfke" <peter@xilinx.com>
Date: 8 Aug 2006 14:41:13 -0700
Links: << >>  << T >>  << A >>
True, CoolRunner has no DCM or PLL (that's what you meant to say, I
suppose).
When you want to tranmit 100 Mb per second in Manchester code, you
really need a 200 MHz clock, since each data bit uses (potentially) two
level transitions. (or you rely on the 50% clock duty cycle plus an XOR
gate...
Manchester code is wasteful in bandwidth, but easy to implement, and
fairly rugged.
Other schemes, like 8B10B use much lower bandwidth, but are more
sensitive to frequency mismatch between transmitter and receiver.
There are many xtal oscillator manufacturers. Typical telecom
frequencies like 156 or 312 MHz oscillators are readily available, and
are of high quality at a low price, if the frequency suits you.
In that case you can count on extremely good frequency matching between
sender and receiver.
Peter Alfke, Xilinx
================
Michael Dreschmann wrote:
> On 8 Aug 2006 13:52:43 -0700, "Peter Alfke" <peter@xilinx.com> wrote:
>
> >Michael, I thought you wanted to use an FPGA (Virtex-4) for the
> >receiver.
> >Then you can use any oscillator frequency you want, and modify it with
> >the DCM inside the FPGA.
>
> Of course, I'm looking for an oscillator for the transmitting cpld. He
> also needs 100 MHz to generate the data stream but as far as I know
> there is now DCM or PLL in a CoolRunner 2. Or am I wrong?
> On the receiver side power and oscillator is no problem.
> 
> Michael


Article: 106182
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 09 Aug 2006 09:49:50 +1200
Links: << >>  << T >>  << A >>
Antti wrote:
> 
> cpld oscillator shure work, but you still need a resistor across not
> gate in-out
> it want oscillate otherwise. I have spent some time trying to get an
> crystal
> to swing on FPGA pins without external resistor but have not yet
> succeeded.

Interesting target - why is the resistor such a problem ?
There are bigger headaches in FPGA osc than the resistor..

-jg


Article: 106183
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 09 Aug 2006 10:00:16 +1200
Links: << >>  << T >>  << A >>
Michael Dreschmann wrote:

> On 8 Aug 2006 11:30:03 -0700, "Peter Alfke" <peter@xilinx.com> wrote:
> 
> 
>>But I prefer a dedicated oscillator, because it uses less power, and
>>uses an internal chip that is optimized for the purpose, and is
>>manufactured by a company with expertise and a single-minded goal. And
>>it hardly costs extra...
> 
> 
> Costs are no problem, it's a university project and not a design for
> production.
> I thought a crystal in combination with the cpld would need less power
> than a dedicated oscillator. Could you give me a hint where to find a
> 100 MHz low power oscialltor working at 2.5V? An external oscillator
> of course would be easier.

100Mhz is tricky space for crystals, as you are also into overtone.

Look at Maxim and Linear - they have a number of SOT23 Oscillators
that are designed to give quite good precisions (for manchester), in 
10-200Mhz ranges.

If you are brave, a LC osc can be built with a CPLD Inverter
( no resistor needed )
- tho at 100Mhz the Tpd is a size-able chunk of half-period.
Start at 10-20Mhz, and lower L/C, to see if 100Mhz is practical.

You can also make a ring-oscillator, using just the PLD delay elements:
this has the lowest precision, but manchester can auto-baud


> An other question concerning power:
> If I have a design that fits exactly in a xc2c64a cpld and I use the
> next bigger one (xc2c128) with the same design how much more would be
> the power consumption (roughly)?

for low power CPLD clocking notes, take a look at this
http://www.altera.com/literature/an/an422.pdf

As often happens with benchmarks, the really usefull info is 
other-other. Here it is the Xilinx/Lattice relative infos - any 
Altera-others info will be carefully  filtered :)

-jg



Article: 106184
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 09 Aug 2006 10:03:48 +1200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
> news:44D8D028.7080802@xilinx.com...
> 
>>Michael,
>>
>>The use of a CPLD or FPGA inversion is not recommended for a crystal
>>oscillator.
>>
>>The problem is not that it won't work (it often does), it is that it
>>sometimes will not start.  The inversion also comes with a delay that is
>>not something that you can easily model and prove that the oscillator
>>will always start up.
>>
>>Once started, it will oscillate, it is the starting that is sometimes
>>difficult,
>>
>>Austin
> 
> 
> hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps 
> and crystal will not oscillate under some conditions?
> 
> It should be 100% a-stable as it can not stay in non-oscillating state.

A more important question is WHICH frequency it oscillates at ! :)
At lower slew rates (not this case), you can get multiple oscillation
effects : At the thresholds, the extreme (excess) gain can give 
parasitic oscillations, or edge-fur, and that's NOT nice on a clock source !

-jg




Article: 106185
Subject: Re: Xilinx Impact USB speed problem
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 9 Aug 2006 00:12:59 +0200
Links: << >>  << T >>  << A >>
Frank Buss wrote:

> Starting with ISE Webpack 8.2, I have to manually set the speed of the USB
> port to 3 MHz every time I start Impact, because with 6 MHz the write
> process is ignored most of the time and the old configuration is still
> active. How can I preset 3 MHz? Looks like it is not stored in the Impact
> project file.
> 
> Or any other ideas why 6 MHz doesn't work on my computer?

I've solved the problem for me: When hitting the "PROG" button or turning
power off and on before accessing the board, looks like it works all the
time, even with 6 MHz.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106186
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: "Peter Alfke" <peter@xilinx.com>
Date: 8 Aug 2006 15:54:36 -0700
Links: << >>  << T >>  << A >>
I would look at the low-power xtal oscillators used in cell phones,
often at 156 MHz. They are a bargain in small size, low power
consumption, and cost. They are made by the millions (or is it billions
by now ?)
Pletronics is one manufacturer, but there are many others.
Peter Alfke

Jim Granville wrote:
> Antti Lukats wrote:
>
> > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag
> > news:44D8D028.7080802@xilinx.com...
> >
> >>Michael,
> >>
> >>The use of a CPLD or FPGA inversion is not recommended for a crystal
> >>oscillator.
> >>
> >>The problem is not that it won't work (it often does), it is that it
> >>sometimes will not start.  The inversion also comes with a delay that is
> >>not something that you can easily model and prove that the oscillator
> >>will always start up.
> >>
> >>Once started, it will oscillate, it is the starting that is sometimes
> >>difficult,
> >>
> >>Austin
> >
> >
> > hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2 caps
> > and crystal will not oscillate under some conditions?
> >
> > It should be 100% a-stable as it can not stay in non-oscillating state.
>
> A more important question is WHICH frequency it oscillates at ! :)
> At lower slew rates (not this case), you can get multiple oscillation
> effects : At the thresholds, the extreme (excess) gain can give
> parasitic oscillations, or edge-fur, and that's NOT nice on a clock source !
> 
> -jg


Article: 106187
Subject: Re: verilog versus vhdl
From: "JJ" <johnjakson@gmail.com>
Date: 8 Aug 2006 15:57:16 -0700
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> JJ wrote:
> > Myself I vote for the one that begins with V.
> >
> > Now if the C language would pick up some major extensions the likes of
> > which we see in HDLs such as open ended bit sizes and the same notion
> > of concurrency and nested modules I could probably do most everthing in
> > a HDL C combined with regular C. If the compiler would spit out HDL for
> > regular synthesis and allow HDL code to be simulated at C speeds, that
> > would be neat.
>
> Most of the C based HDLs offer some means to assign arbitrary bit
> widths to objects, frequently in ways that break ANSI C compatability.
> Bit fields do however existing in the language, and in ways that are
> actually pretty useful for most applications. Still, one of my nits in
> doing FpgaC is to carry a proposal to the ANSI committee to allow bit
> fields that are larger than the native type, forcing the compiler to
> handle a 200 bit or 64 bit object the same on both an 8bit micro and a
> 128 bit super computer. In FpgaC, I'm not sure there is a limit on the
> width of an object, other than constants, which is something I'm
> already working toward fixing.
>

Exactly, least possible change to the language but to allow wires bits
fields to be truly arbitrarily large, Verilog allows 16M bit width if
needed. perhaps we should be using Fortran or APL as base languages.
Using C++ overloading operators and hence SystemC doesn't do it for me
either. A base language that can do huge math ops in a few symbols is
something we had 40 years ago. It is a pity N.Wirth didn't do more for
HDLs beside Lola.

> As for concurrency, that is something that hardware guys miss
> understand completely. Every compiler is free to shuffle/reschedule the
> code produced, as long as the results have the expected serial
> symantics. Out of order execution and multiple issue pipelines, ARE
> concurrency. As are threads, pipes, processes, and many other
> concurrent abstracts in what appears a sequential language.
>

By concurrency I refer to the CSP model and the occam language which
looks alot lke hardware design. Ofcourse HandelC evolved out of occam
from the U Oxford work a decade ago in synthesizing occam processes as
hardware. I don't know about the other xyzCs or FpgaC and will wait
till they have been around a while.  I do remember though before I
became interested in FPGAs some 10 years ago several commercial ASIC
HDL C and I recall that they all failed miserably in the market as
"nobody wants this stuff". With FPGAs and systems guys, there is
perhaps more room for using HDL C but it has to be a FREE language and
preferably standardized.

> In FpgaC everything in a statement group is completely concurrent.
> Other C based HDLs offer other concurrency rules, from statement level
> clock timing, to explict construction of parallelism using hardware HDL
> semantics.
>

Really wIll have to look into FpgaC some time esp if its gets more
traction and more references by others.

snipping

> While my interest in FpgaC is to build useful FPGA super computers in
> the future, it's a love of both hardware design, and software design,
> that enables that vision. That is not a reasonable vision, while the
> only tools to program fpga designs, and at the bit and clock edge
> level.  I suspect, that just as assembler, and even 'low level" C is no
> longer in favor for complex designs today ... there will be an
> evolution where high level HDL tools move away from detailed hardware
> description at the clock and signal level detail, and move up so that
> system level specification which includes the interface descriptions
> and leaves the internal hardware description clearly to the tools to

I think there needs to be a combination of Verilog (maybe VHDL) and a
subset of C++ so that processes can be described in a common language
that might run as conventional software on a single or massively
threaded cpu or might also be synthesized onto hardware. It should
still allow for bitwise low level hardware design if need be but should
also allow higher lever synthesis too. That should be a boon to those
Opteron systems with FPGA coprocessors .

> optimize and produce. I'm not the brighest tool designer on the planet
> ... actually just a wet eared newbie ... so if I can get FpgaC to do
> these things with a little magic, I'm certain the better guys on the
> planet that do this for a living will blow some socks off with system
> level C languages.  I'm actually looking foward to a SystemC tool based
> on C++ sematics that has really good synthesis ... maybe a few years
> from now?

I find myself moving further & further away from C++, leave as much of
it as possible out of the loop. Perhaps Lisp would or should be the
ticket.

Well I am not the worlds brightest spark either but what I can see is a
mess all around me where ever I look, most of it as a result of too
much idiotic complexity and too many parties. I yearn for the
simplicity of years past. I have 4 different computers around the
office house and every one of them is really crap, and some of it is
pretty new crap. This one won't run that OS, that OS or mobo don't like
that HD, those 2 HDs from same vendor can't be on same ribbon. Its
really endless list of incompatibles. Give me a system based on
something like SpaceWire links for everything and lots of throughput
processors and no Memory Wall!

FWIW I always say that Verilog is closer to Pascal than C, C only
supplies the arithmetic expression operators while Pascal supplies the
module structure. A parser for C is far more complex than for Verilog
even though on the surface C is supposed to be simpler.


John Jakson
transputer guy


Article: 106188
Subject: Question about SSTL
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 8 Aug 2006 16:18:04 -0700
Links: << >>  << T >>  << A >>
I'm about to test a DDR2-SDRAM controller.
I have a question regarding the use of SSTL IO standard in Virtex-4: Is
it needed to connect the Vref?
In the user guide for Virtex-4 (ug70.pdf the bottom of page 290) I
don't understand the note n2 which is related to Vcco for inputs:
"Differential inputs and inputs using VREF are powered from VCCAUX.
However, pin voltage must not exceed VCCO , due to the presence of
clamp diodes to VCCO."

Another question by the way: Which supply should Vccaux have? 2.5v?

Cheers


Article: 106189
Subject: Spartan 3 StarterKit Weirdness
From: David Carne <david-removeme-carne@shaw.ca>
Date: Tue, 08 Aug 2006 23:22:24 GMT
Links: << >>  << T >>  << A >>
I'm experiencing something strange with my Spartan 3 starter kit. It 
seems that when I download a bitstream via jtag directly, things don't 
always work the way they should. However, when I generate a mcs/prm file, 
then burn that prom file to the onboard prom via jtag + boot the fpga 
via that, it works perfectly! I've seen this behavior on multiple 
different designs... no common attribute as to when it happens + when it 
doesnt. I've tried forcing it to verify, but I've never once had that 
succeed, so I don't know if the verify functionality even works.

Has anyone seen this before, and if so, any ideas about a solution? 


Cheers,

--David Carne

Article: 106190
Subject: Re: Spartan 3 StarterKit Weirdness
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 08 Aug 2006 23:44:43 GMT
Links: << >>  << T >>  << A >>
I didn't see the verify work and I haven't gone back to see if it could.
The several times I've reprogrammed, the direct JTAG works fine; I've only 
programmed the flash load once or twice since direct seems to work.  I do 
recall some DCM lock problems that *shouldn't* have been there as far as I 
could tell (and DCM reset didn't help) but I was actively changing the 
design and a next load usually took care of it.  Rapid development masks 
bugs?

- John_H

"David Carne" <david-removeme-carne@shaw.ca> wrote in message 
news:20060808162224915-0700@news.vc.shawcable.net...
> I'm experiencing something strange with my Spartan 3 starter kit. It
> seems that when I download a bitstream via jtag directly, things don't
> always work the way they should. However, when I generate a mcs/prm file,
> then burn that prom file to the onboard prom via jtag + boot the fpga
> via that, it works perfectly! I've seen this behavior on multiple
> different designs... no common attribute as to when it happens + when it
> doesnt. I've tried forcing it to verify, but I've never once had that
> succeed, so I don't know if the verify functionality even works.
>
> Has anyone seen this before, and if so, any ideas about a solution?
>
>
> Cheers,
>
> --David Carne 



Article: 106191
Subject: Re: Spartan 3 StarterKit Weirdness
From: "Brian Davis" <brimdavis@aol.com>
Date: 8 Aug 2006 18:01:38 -0700
Links: << >>  << T >>  << A >>
"David Carne" wrote:
> I'm experiencing something strange with my Spartan 3 starter kit. It
> seems that when I download a bitstream via jtag directly, things don't
> always work the way they should. However, when I generate a mcs/prm file,
> then burn that prom file to the onboard prom via jtag + boot the fpga
> via that, it works perfectly!

 Try changing the mode jumpers to JTAG; also see this msg + thread:
   http://groups.google.com/group/comp.arch.fpga/msg/8b2144041295cd24

John_H wrote:
> I do  recall some DCM lock problems that *shouldn't* have been there
> as far as I  could tell (and DCM reset didn't help) but I was actively changing
> the  design and a next load usually took care of it.  Rapid development masks
> bugs?

 My S3 board with ES silicon also exhibits SSO inspired DCM unlocks
even when well within the revised^N S3 SSO guidelines.

 LOC'ing the DCM's to the other side of the chip 'fixed'  it, but I
never had the time to probe further:
  http://groups.google.com/group/comp.arch.fpga/msg/8becb47f6a28e749

Brian


Article: 106192
Subject: Re: verilog versus vhdl
From: fpga_toys@yahoo.com
Date: 8 Aug 2006 18:37:26 -0700
Links: << >>  << T >>  << A >>

JJ wrote:
>  I do remember though before I
> became interested in FPGAs some 10 years ago several commercial ASIC
> HDL C and I recall that they all failed miserably in the market as
> "nobody wants this stuff". With FPGAs and systems guys, there is
> perhaps more room for using HDL C but it has to be a FREE language and
> preferably standardized.

10 years ago the price performance of FPGA's really was marginal. A
decade of Moore's Law, and we are just now finding the price
performance of FPGA's to be very competitive ... without the proper
tools.

I agree that open source FPGA tools are critical .... and something
that the big vendors haven't realized yet. I can still remember the
posturing and standards problems that plagued the software industry 30
years ago ... till UNIX leveled the playing ground, and create a
cooperative competitive environment the benifited all. Once
reconfigurable computing starts to take off, the large computer vendors
will mandate it. And leave those closed shops behind.

Standards really make the difference ... it's why a C HDL really needs
to be ANSI C, with as FEW changes as possible (IF any at all). It's
actually quite possible to design with ANSI C, and leave the changes in
the back end tools. Restricting bit field declarations to structures
isn't really a problem, and allows portability. A few pragma's are a
bit deal either. Everything else should be portable, standards based.
It's the problem I had with TMCC (the starting source code for FPGA),
and Handel-C.  It was a hard call not to start from scratch, rather
than use the subset TMCC. The evolution of TMCC to an ANSI C in the
FpgaC project has been slow, but steady progress. And even as a subset,
with so-so synthesis, is amazingly useful. A few more good
hardware/software people working on it, and it could be really "done"
in a few months.

The most disappointing part of the project, has been the kids that
arrive gungho, and discover it's  actually some difficult learning and
relatively challenging work as a programmer to do hardware tools. I'd
hoped a few more computer engineering students would find the project.


Article: 106193
Subject: Re: Question about SSTL
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 08 Aug 2006 19:21:22 -0700
Links: << >>  << T >>  << A >>
GaL,

See below,

Austin


GaLaKtIkUs™ wrote:

> I'm about to test a DDR2-SDRAM controller.
> I have a question regarding the use of SSTL IO standard in Virtex-4: Is
> it needed to connect the Vref?

For a driver, no.  For a receiver, yes.

> In the user guide for Virtex-4 (ug70.pdf the bottom of page 290) I
> don't understand the note n2 which is related to Vcco for inputs:
> "Differential inputs and inputs using VREF are powered from VCCAUX.

This is telling you that the differential amplifier (comparator) and the 
Vref comparator are powered from Vccaux.  That means that in order to 
meet the speed specifications for an input, the pin voltage should 
remain inside the limit of ground to Vccaux, better yet, 0.6 volts above 
ground, and no more than 0.6 volts below Vccaux.  To go beyond this 
range means the full CMOS differential amplifier (comparator) may not be 
operating in its linear range.  The comparator will function well beyond 
this range, but it is recommended to stay within the limits of the SSTL 
standard for pon voltages.

> However, pin voltage must not exceed VCCO , due to the presence of
> clamp diodes to VCCO."

There are clamp diodes (intrinsic to the IO drivers) from ground to the 
pin, to Vcco.

gnd ----->|------pin------->|-----Vcco

Is that clear?  These diodes are always there (that is what 'intrinsic' 
means:  part of the device).

They have always been there:  since Virtex II in the Virtex line.  The 
top diode to Vcco was not there in Virtex, or Virtex E.  That was a long 
time ago.

It has also been there in Spartan 3, and Spartan 3E, but not in Spartan 
2, or 2E.

So, diodes = S3, S3E, V2, V2 Pro, V2 Pro-X, V4, V5.

> 
> Another question by the way: Which supply should Vccaux have? 2.5v?

Vccaux is always per the data sheet:  2.5 volts.  In this case, 2.5 
volts.  Maybe someday it will change, but so far it has not changed 
since it was first introduced.  In any event, table 2, section 3, of the 
data sheet is what is important.  That is where you find the recommended 
operating voltage ranges.

Article: 106194
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: Phil Hays <spampostmaster@comcast.net>
Date: Tue, 08 Aug 2006 19:22:19 -0700
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> "Austin Lesea" wrote:

>> The use of a CPLD or FPGA inversion is not recommended for a crystal
>> oscillator.

> hm you mean that an CPLD/FPGA NOT gate with 1 (or 2 resistors) and 2
> caps and crystal will not oscillate under some conditions?


> It should be 100% a-stable as it can not stay in non-oscillating state.


Back in the 1970's, an engineer I was working for decided to save a part
on a design and use a spare 7414 inverter rather than a 7404 inverter as
an oscillator.

A TTL inverter, like the 7404, properly connected, makes a good
oscillator. A 7414, which is a schmitt-trigger inverter, doesn't.

Yes, it would always oscillate.  But only sometimes at the correct
frequency.  More often at the third or fifth harmonic of the crystal.  And
sometimes higher harmonics.

This left me with the idea that a good engineer should make sure that an
oscillator design is a good design before building boards.  Not afterward.


-- 
Phil Hays


Article: 106195
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: michaeldre@gmx.de (Michael Dreschmann)
Date: Wed, 09 Aug 2006 02:24:17 GMT
Links: << >>  << T >>  << A >>
On 8 Aug 2006 14:41:13 -0700, "Peter Alfke" <peter@xilinx.com> wrote:

>When you want to tranmit 100 Mb per second in Manchester code, you
>really need a 200 MHz clock, since each data bit uses (potentially) two
>level transitions. (or you rely on the 50% clock duty cycle plus an XOR
>gate...

When I simply xor the NRZ data with the clock signal I get spikes
which isn't surprising. So I create two 50 MHz clocks from the 100 MHz
clock that are phase-shifted by 90 degree (by using rising and falling
edge of the 100 MHz clock). Then I invert one of the two clocks
depending of the NRZ data bit. Finally the two 50 MHz clocks (one of
them modulated by the data to send) are xored and I have my manchester
signal. Because now the outputs of two flipflops are xored there is
nearly no time difference between them and the output is fine (my
theory, don't laugh Peter ;) ). Of course the incomming clock must
have a 50% duty cycle.
I haven't tested it in silicon but a Post-Fit simulation with modelsim
shows a very good signal and I hope this is a good sign.

>Manchester code is wasteful in bandwidth, but easy to implement, and
>fairly rugged.

Right, but in our application bandwidth is not a problem at the moment
(optical link). We need to save power and so I try to use the smallest
cpld possible.

Thanks also for the infos of oscillator manufacturers. I'll look
tomorrow, it's time for bed now in germany.. ;)

Michael

Article: 106196
Subject: Re: 100 Mbit manchester coded signal in FPGA
From: michaeldre@gmx.de (Michael Dreschmann)
Date: Wed, 09 Aug 2006 02:25:53 GMT
Links: << >>  << T >>  << A >>
Hi,

Thank you all for your help. I think everything is clear to me now.

Michael 

Article: 106197
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: "jtw" <wrightjt @hotmail.invalid>
Date: Wed, 09 Aug 2006 02:55:23 GMT
Links: << >>  << T >>  << A >>

"Jeff Cunningham" <jcc@sover.net> wrote in message 
news:44d7f7d1$0$6591$4d3efbfe@news.sover.net...
> ZHI wrote:
>> Thanks Mike Treseler
>>  I am not reading a vhdl netlist.  I am reading a uart application
>> codes. For example, the input signal (RXD signal) of FPGA  firstly
>> go through a IBUF then a BUFG. What's the uses of them respectively?
>> Why need use these buffers? When need use them?
>> Or we actually don't need to care these buffers at all.
>
> BUFG is a buffer which drives a global clock network.
> IBUF is a buffer from the input pin.
>
> IBUF->BUFG would typically be used when an external pin is used to drive a 
> clock signal and the pin is NOT a dedicated clock input.
>
> Ideally a synthesizer would handle this automatically. Sometimes the tool 
> is not smart enough. Instantiating BUFG directly forces it to route the 
> signal on a global clock net.
>
Sometimes the tool is too smart, and sometimes what you need cannot be 
properly inferred.

In a multiple clock design, I prefer to direct which clocks get which 
bufg's.  I may also want to direct the naming to facilitate placement 
control in the constraints file.  There are many potential reasons for doing 
direct VHDL instantation of a specific component.

Nevertheless, I have difficulty with the idea of explicity instantiating 
hundreds of IBUFs and OBUFs in my code.  The tools have matured to the 
extent that those key pieces will be inferred and created in the edif 
netlist.  (It's the exceptions that merit explicit direction.)

JTW
> Having said that, treating a UART RXD signal as a global clock sounds 
> rather bizarre.
>
> -Jeff 



Article: 106198
Subject: Simple code to check out Spartan3 starter kit?
From: ptkwt@aracnet.com (Phil Tomson)
Date: 9 Aug 2006 04:11:29 GMT
Links: << >>  << T >>  << A >>

I've got ISE 8.1 running under Linux (Gentoo, 2.6.15 kernel, amd64 - I 
plan to use the xc3sprog program to send the bitsream to the board) and 
now I'd like to hook up the starter kit board and try it out...
I'd like a simple design that I could run through ISE and download to the 
board that would do something on the LEDs so I know things are working, 
but I don't see anything like that - according to the README for xc3sprog 
there is some design called echo_out that does something like this, but I 
can't find it anywhere.  Is it (or something similar) available on the web 
anywhere?

...maybe I'm missing something, but it seems like something like this 
should be in the Sparten-3 Starter-kit Board User Guide.  One of the first 
things they should have you do is download a test design and run it 
through ISE and download the bitstream to the FPGA at which point it would 
display something on the LEDs in order to make sure you've hooked up 
everything correctly and that you've setup ISE correctly. 

Phil

Article: 106199
Subject: Re: WHAT SITUATION I NEED A BUFFER
From: "Andrew FPGA" <andrew.newsgroup@gmail.com>
Date: 8 Aug 2006 21:34:56 -0700
Links: << >>  << T >>  << A >>
Not sure if this really helps but a few years ago I saw a problem that
was remarkably similar in concept. The PC application would lock up
after transferring a significant, but random amount of data to the FPGA
via a serial connection. The FPGA uart was one of the free cores on the
xilinx site.  It turned out the receive data line into the FPGA uart
was not being synchronised to the uart clock before being used in the
uart.  As a result the FPGA uart would occasionally get into a locked
up state. (no excuse for the PC app locking up though).

Fix was simply to add a flop synchornising the rxd to the uart clock.

ZHI wrote:
> My algorithm is to solve the linear equation R.h=b, (R matrix ,b vector
> is known, generated in Matlab). R,b are  transmitted to FPGA board.
> After the application caculation, h is sent back to Matlab.
> I set the number of trials is 100. it will no problem. If
> trials=100000, it will happen the "accidently stop" in Matlab.
> I guess you are right that it looks like memory leak. I tried a simple
> test.
> Numbers from 1 to 100 transmit from Matlab to FPGA board(UART) and send
> them back. These numbers are sent back correctly. If i send the number
> from 1 to 1000 to UART. The matlab will show like that:
> (InputBufferSize=512 in my matlab version)
> ----------------------------------------------------------------
>  Error using ==> serial.fread
> SIZE * PRECISION must be less than or equal to InputBufferSize.
> Error in ==> testuart at 17
> y= fread(s,1000,'uint8');
> -------------------------------------------------------
> I am not sure if i say it clearly. Hope you can help me to figure it
> out.
> Thanks a lot.
> 
> Zhi
> 
>




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