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 74900

Article: 74900
Subject: Re: spartan 3 on 4 layers
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 21 Oct 2004 12:22:38 +0100
Links: << >>  << T >>  << A >>
On Tue, 19 Oct 2004 13:51:49 -0700, "Symon" <symon_brewer@hotmail.com>
wrote:

>"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
>news:cl3t0g$qob$1@gnus01.u.washington.edu...
>>
>> The suggestion was to improve the ground plane by making it
>> thicker.   To reduce via inductance you need as many of them
>> as you can get.  (Inductors in parallel.)   The OP wanted a four
>> layer board instead of following the suggested two ground and
>> two power planes.
>>
>I just realised, making it thicker will only reduce its resistance. Its
>inductance won't change. The inductance is determined by the loop area of
>the current path. Think about it, when you calculate the inductance of a
>coil, you don't need to know the wire diameter, just the diameter and number
>of turns.

What you can do, though, is play with the thickness of the prepreg. Make
it thin enough and you increase the capacitance between ground and power
planes. Not to a very high value, granted, but connected to the planes
by a _very_ low inductance!

- Brian



Article: 74901
Subject: Xilinx translate error : Cannot find signal "clk"
From: srakesh@hotmail.com (Rakesh Sharma)
Date: 21 Oct 2004 04:31:41 -0700
Links: << >>  << T >>  << A >>
Hi,

  I am getting the following error in Xilinx:-

Annotating constraints to design from file "musicmp3.ucf" ...
ERROR:NgdBuild:755 - Line 2 in 'musicmp3.ucf': Could not find net(s) 'rxd' in
   the design.  To suppress this error use the -aul switch, specify the correct
   net name or remove the constraint.
ERROR:NgdBuild:755 - Line 4 in 'musicmp3.ucf': Could not find net(s) 'clk' in
   the design.  To suppress this error use the -aul switch, specify the correct
   net name or remove the constraint.
ERROR:Parsers:11 - Encountered unrecognized constraint while parsing.
ERROR:NgdBuild:19 - Errors found while parsing constraint file "musicmp3.ucf".

Writing NGDBUILD log file "musicmp3.bld"...


The UCF file looks like :-

#PACE: Start of Constraints extracted by PACE from the Design
NET "rxd" LOC = "P202"  ;
NET "pwm_output" LOC = "P110"  ;
NET "clk" LOC = "P80"  ;


The code goes like this :-

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.std_logic_arith.all; 
use IEEE.std_logic_misc.all;
use work.functions.all;


ENTITY musicmp3 IS
   PORT (
      clk                     : IN std_logic;   
      RxD                     : IN bit;   
      PWM_output              : OUT bit);   
END musicmp3;

ARCHITECTURE translated OF musicmp3 IS

   COMPONENT async_receiver
      PORT (
         clk                     : IN  std_logic;
         RxD                     : IN  bit;
         RxD_data_ready          : OUT bit;
         RxD_data                : OUT bit_vector(7 DOWNTO 0);
         RxD_endofpacket         : OUT bit;
         RxD_idle                : OUT bit);
   END COMPONENT;


   SIGNAL RxD_data_ready           :  bit;   
   SIGNAL RxD_data                 :  bit_vector(7 DOWNTO 0);   
   SIGNAL RxD_data_reg             :  bit_vector(7 DOWNTO 0);   
	 SIGNAL tmp             :  bit_vector(7 DOWNTO 0);   
   SIGNAL PWM_accumulator          :  bit_vector(8 DOWNTO 0);   
   SIGNAL PWM_output_xhdl1         :  bit;  


BEGIN
   PWM_output <= PWM_output_xhdl1;
   deserialer : async_receiver 
      PORT MAP (
         clk => clk,
         RxD => RxD,
         RxD_data_ready => RxD_data_ready,
         RxD_data => RxD_data);   
   

   PROCESS
   BEGIN
      WAIT UNTIL (clk'EVENT AND clk = '1');
      IF (RxD_data_ready = '1') THEN
         RxD_data_reg <= RxD_data;    
      END IF;
   END PROCESS;


   PROCESS
   	VARIABLE s : BIT_VECTOR(7 downto 0);
	VARIABLE DInt : INTEGER := 0;	   	
	VARIABLE EInt : INTEGER := 0;
   BEGIN
      WAIT UNTIL (clk'EVENT AND clk = '1');
     -- PWM_accumulator <= "0" & PWM_accumulator(7 DOWNTO 0) + RxD_data_reg;  
	
	 s := PWM_accumulator(7 DOWNTO 0);
	 DInt := to_integer(s);
	 EInt := to_integer(RxD_data_reg);

	 DInt := DInt + EInt;
	 
	 PWM_accumulator <= to_bit(9, DInt);
		  
   END PROCESS;
   PWM_output_xhdl1 <= PWM_accumulator(8) ;
  
END translated;


What can be wrong? Thanks in advance

Article: 74902
Subject: Re: spartan 3 on 4 layers
From: brimdavis@aol.com (Brian Davis)
Date: 21 Oct 2004 05:04:43 -0700
Links: << >>  << T >>  << A >>
Symon wrote:
> 
> I see in XAPP475 they say that "Unfortunately, IBIS 3.2
> still is not widely supported by simulators.".
>
 Oops, I missed that explanation when skimming XAPP475
yesterday to find the TLine parameters.

 I was actually thinking of this sentence from Answer Record
#19320 when I griped about Xilinx still using IBIS 2.1:

    "We do not have an IBIS model for LVDS_25_DT, as
  the IBIS specification does not provide a mechanism
  for representing the true differential termination"

 It's been I while since I read the IBIS specs, but I believe
it was IBIS 3.x which added support for modeling a differential
terminator, instead of having to bury single-ended terminator
currents in the GND/VCC clamp table.

>  It wouldn't hurt to publish new IBIS3.2 or even 4.0 files
> alongside the old ones though!

  My interest in having data available in one of the newer
IBIS versions is not to actually use them in an IBIS simulator,
but to have {almost} human-readable documentation of the
differential package and I/O parasitics, which Xilinx doesn't
currently publish in any other form.

  I suspect if you use the differential I/O standards, and then
tie adjacent I/O pins as strong drivers to GND(VCCO), you can
establish a nice GND S+ S- GND(VCCO) pinout in a leaded package
and have a good shot at doing extremely fast I/O in an el-cheapo
package. 

  And I'd love to see a small S3 sold in one of the enhanced
VQFP ground-paddle packages, for both thermal and electrical
reasons, especially if done with a G S+ S- G pinout.

>
>Thanks for a very informative post, much appreciated
>
  As were yours, thanks - I've been building 4-6 layer boards
with FPGA's powered from localized plane fills, as you describe,
for many years and generations of FPGA. Keeping the 'dirty' FPGA
power plane localized in such a fashion also helps in RF/mixed
signal board layouts.

  I took a look at building a simple first or second order SPICE
package model of the leaded S3 parts a few months ago, but there
wasn't any package data available in the IBIS files; if I get a
chance to take another crack at it, I'll post some LTspice files.

  And if anyone out there has built a test fixture and made
either differential TDR or VNA measurements on some of the S3 
leaded packages, I'd love to see some real world data to help 
model the pin-pin coupling for a G S+ S- G pinout :)

Brian

Article: 74903
Subject: Re: unstable fpga design
From: info@bostonsemiconductor.com (Chris Alexander)
Date: 21 Oct 2004 06:03:12 -0700
Links: << >>  << T >>  << A >>
In no particular order:

1) Start with the synthesis log files.  It can be easy to overlook the
information presented there - particularly if it is listed as a
"WARNING" as opposed to an "ERROR". Look carefully at all the
WARNINGs, sometimes there is information about clock, latch and
asynchronous inference that you may explain why you are getting
behavior you did not intend.

2) Scan through your code and look for reset circuits in *all* of your
registers.  Did you intend to reset all flops?  Did you actually do
that?  If you did not, sometimes the powerup state of a flop can
change when re-building the design.

3) Simulate, simulate, simulate.  Have you verified this design in
logic simulation?  Does your simulation "sky-wire" into the design to
force internal nodes?  If so, your lab bahavior will be different.

4) Give us more details about the design style you use.  I think the
suggestion to make the entire design synchronous is a very good one. 
Gating clocks and / or generating clocks from internal registers can
cause mismatches between simulation and synthesized designs.

Good luck,
Chris


moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0410200517.391ab8d9@posting.google.com>...
> Hello all,
> 
> first a little background ..
> I'm currently working on a fpga design (using VHDL) and using 
> the Xilinx spartan IIE fpga (xc2s400e) chip.
> my design size is about 1300 slices (about third of the chip
> capacity).
> My problem is as follow :
> sometimes when I change my top design and then re-synthisizes it, some
> "parts"  of my code is not working properly i.e. - some of my fpga
> blocks are working as usuall and some dont (e.g. FSMs).
> this appens not only for large code changes, sometimes it happens when
> I "just" change an output pin to be '0' instead of '1' (a very minor
> change).
> my static timing analisys looks o.k. (at least the paths that i've
> constrained). and I realy dont know where to start looking.
> I checked my design over and over for "bad code" parts but didnt found
> anything that might explain this.
> 
> I would realy like to know if some of you have expeienesd something
> similar in the past and if not maybe someone can give me a tip to
> start with..
> 
> thanks in advance, Moti.

Article: 74904
Subject: Re: Xilinx translate error : Cannot find signal "clk"
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 21 Oct 2004 06:40:40 -0700
Links: << >>  << T >>  << A >>
Rakesh Sharma wrote:

> ERROR:NgdBuild:755 - Line 2 in 'musicmp3.ucf': Could not find net(s) 'rxd' in
>    the design.  To suppress this error use the -aul switch, specify the correct
>    net name or remove the constraint.
> ERROR:NgdBuild:755 - Line 4 in 'musicmp3.ucf': Could not find net(s) 'clk' in
>    the design.  To suppress this error use the -aul switch, specify the correct
>    net name or remove the constraint.

Consider declaring signals named rxd and clk.

          -- Mike Treseler

Article: 74905
Subject: Re: Open-Source MicroBlaze IP-Core working in FPGA :)
From: "Antti Lukats" <antti@case2000.com>
Date: Thu, 21 Oct 2004 07:22:52 -0700
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:4176AD2C.AD82D7C8@yahoo.com...
> Antti Lukats wrote:
> >
> > NIOX is done by me (3 evnings workload) - its completly clean version
> > written from scratch. It has no pipeline but if running from brams can
run
> > about 1 clock instruction except load instructions what is way faster
than
> > NIOSII/e
> >
> > I am testing NIOS-II/uCLinux platform simulator at the moment if that is
> > done then I know how to verify NIOX as well, next step would be
NIOX/uCLinux
> > SoC
>
> Have you done any place and routes to get an idea of the speed and LE
> count?  Or was that already posted and I missed it?  I believe Altera
> has a version of the NIOS-II that is only 600 LEs.  That would make me
> very happy if I could put it in an ACEX as well as a Spartan.

I dont have and probably will not have 600LE version.
current version is <1200 LE's in ACEX, but it is capable in 1 clock per
instruction even with no pipeline and it does include full 1 cycle barrel
shifter.

Antti



Article: 74906
Subject: Re: interfacing a PC based program with a FPGA
From: "Arash Salarian" <arash.salarian@epfl.ch>
Date: Thu, 21 Oct 2004 17:09:03 +0200
Links: << >>  << T >>  << A >>
"Srinivas" <srinivaserj@gmail.com> wrote in message 
news:18bc100b.0410210301.265232ef@posting.google.com...
> Hi,
> I'm looking to integrate a FPGA based program into a PC based
> application.
> I understand i need to write a serial interfacing code on the FPGA
> side and an API on the PC side,considering i intend to use a RS 232
> serial interface bet'n the PC and the FPGA board.
> I need help regarding the PC side API programming.I'll be using a 'C'
> program and would like to call the FPGA based functions.
> Can anyone suggest how i go about this?any references?
>
> TIA.
> Srinivas

As I understand you need help writing a program in C to communicate with the 
serial port?! Then you'd better ask this question on a newsgroup related to 
the software programming not a FPGA or Verilog news group! Also you will 
need to provide some more information; at least the OS under which you are 
going to run your program.

Regards
Arash 



Article: 74907
Subject: Re: interfacing a PC based program with a FPGA
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 21 Oct 2004 11:27:55 -0400
Links: << >>  << T >>  << A >>
Srinivas wrote:
> 
> Hi,
> I'm looking to integrate a FPGA based program into a PC based
> application.
> I understand i need to write a serial interfacing code on the FPGA
> side and an API on the PC side,considering i intend to use a RS 232
> serial interface bet'n the PC and the FPGA board.
> I need help regarding the PC side API programming.I'll be using a 'C'
> program and would like to call the FPGA based functions.
> Can anyone suggest how i go about this?any references?

You may want to find a good terminal emulator program rather than trying
to write your own.  The last time I write code for a serial port (under
windows) it was a real PITA.  But then you may be using a decent OS. 
But under any OS, you will be talking to the driver, not the serial
port.  

If you have to write a program, try searching on the web for source code
for a terminal emulator or similar project.  There are lots of open
source projects out there.  

-- 

Rick "rickman" Collins

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

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

Article: 74908
Subject: Small survey for Handel-C writer
From: pierrotlafouine@hotmail.com (Pierre Lafrance)
Date: 21 Oct 2004 08:43:08 -0700
Links: << >>  << T >>  << A >>
How long it took you to get used to Handel-C language, feel confident in
the code you write ?

Thanks

Article: 74909
Subject: Re: Async reset
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 21 Oct 2004 15:53:44 GMT
Links: << >>  << T >>  << A >>
"Jason Berringer" <jberringer@sympatico.ca> wrote in message
news:5QBdd.26143$J16.1307307@news20.bellglobal.com...
> Any comments would be appreciated.

I'd like to point out that async resets aren't free in all FPGAs.
I've been producing reset-free designs for years in the Xilinx parts having
started with reset-free designs in Altera.

The FPGAs have power-up states that are or can be predefined to specific
values.  The S/R pins can be used as *either* sync or async but cannot be
used as both.  There are no resources needed for a synchronous reset above
and beyond what an asynchronous reset uses in those devices.  What about
when the system goes haywaire and the device needs to be reset?  If the
system is in need of serious reset, just reprogram the part.

Some logic can be sped up by using the integrated synchronous S/R
functionality as long as your synthesizer knows how to use it.  Synplify
does a great job of adding additional logic through the S/R ports often
providing a slightly shorter path in timing sensitive designs.  The one
negative from this practice is that the S/R logic integration tends to be
more widespread than I would like, typically locking out the adjacent
register in a slice from use; both registers need the same S/R, clk, and CE
signals.

How does more logic get in through a set/reset?  The FDR primitive can be
used as an OR gate (Q = D & !R where the inversion is free) and an FDS can
be used as an OR gate (Q = D | S) with the FDRS providing a little more
functionality.  Throw the clock enable in there and things get more flexible
but keep in mind (as the synthesis does) that the reset is higher precedence
than the set which is higher than the clock enable.  This "logic
integration" into the register has saved my designs with respect to I/O
timing by allowing live signals to feed the CE, and S/R directly from other
I/Os allowing a very short setup plus output time for the same clock edge.
Without this functionality, getting on and off the logic fabric without
global routing killed my timing.



Article: 74910
Subject: Re: Anyone routing signals between balls in FBGA?
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 21 Oct 2004 16:03:03 GMT
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message
news:2tnlmeF21mpcbU1@uni-berlin.de...
> Kenneth,
> Yes I do this. I get two tracks between the outer balls on the surface
> layer. Our PCB fab house's standard process is 4 mil tracks with 4 mil
gaps.
> For BGAs the land size for the ball should have a diameter of half the
ball
> pitch. The ball pitch is 1mm or 39.37 mils. So, the land diameter should
be
> 19.69 mils, with a gap between adjacent lands of the same, 19.69mils. To
get
> two 4 mil tracks between, with 4 mil gaps needs 20 mils. Gap track gap
track
> gap! If you look very very closely at my boards, you'll find the outer
ring
> of ball lands are slightly oval, to get the gap between them up from 19.69
> to 20 mils! I kept the same area for the ball lands by extending the other
> axis a fraction, but I don't think it was really necessary. So, using
this,
> the outer 3 rows of balls route out with no vias.
> Cheers, Syms.

Nice detail.
With our boards - given the tolerance slop from plating up the outside
layers - we keep our 4-mil (or 0.1mm) lines and spaces on the inside layers
allowing 2 signals between vias while keeping looser line width/spacing
rules on the outside layers which gives us single lines between balls or
vias.

No yield problems if the board house works with those dimensions *and* you
use a proper solder mask.  I'd hate to think of someone attempting to mount
a FBGA on a board without a solder mask.  Yikes!



Article: 74911
Subject: Re: interfacing a PC based program with a FPGA
From: Prasanth Kumar <lunix@comcast.net>
Date: Thu, 21 Oct 2004 16:06:06 GMT
Links: << >>  << T >>  << A >>
On Thu, 2004-10-21 at 04:01 -0700, Srinivas wrote:
> Hi,
> I'm looking to integrate a FPGA based program into a PC based
> application.
> I understand i need to write a serial interfacing code on the FPGA
> side and an API on the PC side,considering i intend to use a RS 232
> serial interface bet'n the PC and the FPGA board.
> I need help regarding the PC side API programming.I'll be using a 'C'
> program and would like to call the FPGA based functions.
> Can anyone suggest how i go about this?any references?
> 
> TIA. 
> Srinivas

It would depend on your operating system. If it is Windows, then there
are a couple helpful documents in Microsoft's MDSN site. Search for
"Serial Communications C" or something like that. It will probably take
2 to 3 pages of code to setup the serial channel.




Article: 74912
Subject: Re: Virtex-4 Slower than V2Pro?
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 21 Oct 2004 16:11:50 GMT
Links: << >>  << T >>  << A >>
"Eric" <swankoski@nrl.navy.mil> wrote in message
news:84d8efa2.0410191300.341d3f8e@posting.google.com...
> I just got my new ISE and went straight to synthesizing some of my old
> designs. Basically, I'm planning on publishing soon, and figured the
> Virtex-4 would bolster my numbers even further. However, that wasn't
> the case.
>
> ******************************************************************
> ******************************************************************
> Virtex-4 Timing
> ******************************************************************
> ******************************************************************
> Timing constraint: Default period analysis for Clock 'clk'
> Delay:               3.445ns (Levels of Logic = 0)
>   Source:            ksb10_sb3_Mrom__n00001_inst_ramb_0 (RAM)
>   Destination:       rcx10_t5_25 (FF)
>   Source Clock:      clk rising
>   Destination Clock: clk rising
>
>   Data Path: ksb10_sb3_Mrom__n00001_inst_ramb_0 to rcx10_t5_25
>                                 Gate     Net
>     Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
>     ----------------------------------------  ------------
>      RAMB16:CLKA->DOA1     1   1.830   0.470
> ksb10_sb3_Mrom__n00001_inst_ramb_0 (t1_9<1>)
>      FDR:R                     1.145          rcx10_t5_25
>     ----------------------------------------
>     Total                      3.445ns (2.975ns logic, 0.470ns route)
>                                        (86.4% logic, 13.6% route)
>
> ******************************************************************

[snip]

Doesn't the Virtex-4 have integrated registers avaliable in the output path?
A direct recompile might not provide the numbers you need (it's always nice
when all the timing numbers improve in a generation without giving the
design any thought) but if the delay is significantly less going from the
embedded registers to the logic, you might be able to get better timing.  Of
course the pipelining changes might be annoying.

Keep in mind that the timing for control signals - the reset in your case -
can be significantly different between families and even between logic and
I/O within a device.  Checking the timing numbers for the control paths with
the speedprint utility might give you insight into bettering your times.



Article: 74913
Subject: Nios & off-chip memory
From: alanmyler@yahoo.com (amyler)
Date: 21 Oct 2004 09:29:57 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm using a Nios to access off-chip memories via the SoPC-builer's
external memory bridge. The Nios is 32-bit data, the memories are 
16-bit data. Using SignalTap I can see that Nios is only accessing
even addresses in the external memory (using germs monitor commands
and/or my own c-code). Has anyone there come across something like
this before? Thanks in advance,

Alan Myler

Article: 74914
Subject: Assembler for PicoBlaze in Perl
From: Mike Peattie <mike.peattienospam@xilinxnospam.com>
Date: Thu, 21 Oct 2004 09:39:22 -0700
Links: << >>  << T >>  << A >>
I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's working 
for all of my test cases (including quite a complex program with over 
600 instructions). It is a full syntax checker (somewhat more lenient 
than the distributed KCPSM3.EXE), as well as a generator of all the 
files (vhdl and verilog templates, .dec, .hex, .m, and .log files). The 
main features are:
- platform independence (perl distributions are available for all the 
major OSs)
- will support mutiple source files
- will support filenames over 8 characters
- not all template files are required, and can have other names than 
ROM_form.*
- generation of ChipScope token files

I'd like to make a call for test cases, or potential users. Please email 
me if you're at all interested.  It's possible that this script may be 
included in future distributions of PicoBlaze.

Thanks,

Mike Peattie
-- 
--
-- Please ignore the reply to address, and use
-- mike -dot- peattie -at- xilinx -dot- com
--

Article: 74915
Subject: Re: interfacing a PC based program with a FPGA
From: thangkho <>
Date: Thu, 21 Oct 2004 09:44:30 -0700
Links: << >>  << T >>  << A >>
Coding serial communication for DOS is simple since you can control the port registers directly, however it's not easy task in windows unless you familiar with C/C++, win32 API, MFC...if you own a VSC++ develope studio, there's some good examples, check for the project TTY

Article: 74916
Subject: Re: Async reset
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 21 Oct 2004 10:02:02 -0700
Links: << >>  << T >>  << A >>


> From: mk<kal@delete.dspia.com>
> Organization: SBC http://yahoo.sbc.com
> Newsgroups: comp.arch.fpga,comp.lang.vhdl
> Date: Thu, 21 Oct 2004 05:20:35 GMT
> Subject: Re: Async reset
> 
> On Wed, 20 Oct 2004 18:41:08 -0400, "Jason Berringer"
> <jberringer@sympatico.ca> wrote:
> 
>>  For FPGAs, when
> programmed not have an async reset a flop might have a different clk
> to Q delay (or a faster setup) which would make the design faster.
I disagree.
In an FPGA, all flip-flops in the logic fabric (what Xilinx calls CLBs or
slices) are the same. They all have a Reset input, whether you use it or
not, and the clock-to-Q delay is unaffected by the way the user configures
the design and uses or not uses asynchronous or synchronous Reset or Clear.
 
Regarding the basic need for reset, Ken Chapman published an interesting
(and perhaps provocative) article 3 years ago ( Oct 2001, but it is still on
the Xilinx website under TechXclusives), and here is his conclusion:

"Summary
"A design implemented in a Xilinx FPGA does not require you to insert a
global reset network. For the vast majority of any design, the
initialisation state of all flip-flops and RAM following configuration is
more comprehensive than any logical reset will ever be. There is no
requirement to insert a reset for simulation because nothing will be
undefined. Since a Xilinx FPGA is already fully tested silicon, you won't be
inserting scan logic in your design and running test vectors, so you will
not need a global reset as part of this process either.

 "Inserting a global reset will impact your development time and final
product costs even if these factors can not be easily quantified. With the
trend towards higher speed clocks and complete systems on a chip, the
reliability issues must be taken seriously. The critical parts of a system
that must truly be reset should be identified and the release of those
resets on start up, or during operation, must be controlled as carefully as
any other signal within a synchronous circuit.

 As you are creating each section of your next design, simply ask yourself:
"Does this bit need to be reset"?
from the TechXlusives paper by Ken Chapman, Xilinx

Peter Alfke

 


Article: 74917
Subject: Re: Async reset
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 21 Oct 2004 10:10:12 -0700
Links: << >>  << T >>  << A >>


Hendra wrote:

(snip)

> Yes, it is possible to have no reset at all in an FPGA since FPGA will
> automatically clear all FFs inside the chip during downloading from
> the bitstream. However, not having the reset will make it harder to
> simulate since some simulators require all the FFs to be resetted
> before you can do any simulation. Moreover, what would happen when for
> some reason your FFs go to undesired state, then you can not get out
> of the loop!

I don't believe they are guaranteed to be cleared, as far as user
logic is concerned.  The synthesis often moves inverters around,
and many signals, including ones through FF's, are actually the
inverse of the expected signal.  I have seen warning messages from
Quartus for FF's that don't have a reset or preset input that the
initial state is not guaranteed.

> There are some articles regarding sync vs async at
> http://www.sunburst-design.com/papers/

-- glen


Article: 74918
Subject: Re: interfacing a PC based program with a FPGA
From: John Smith <user@example.net>
Date: Thu, 21 Oct 2004 20:11:35 +0300
Links: << >>  << T >>  << A >>

Srinivas wrote:
> Hi,
> I'm looking to integrate a FPGA based program into a PC based
> application.
> I understand i need to write a serial interfacing code on the FPGA
> side and an API on the PC side,considering i intend to use a RS 232
> serial interface bet'n the PC and the FPGA board.
> I need help regarding the PC side API programming.I'll be using a 'C'
> program and would like to call the FPGA based functions.
> Can anyone suggest how i go about this?any references?

Is serial interface a must? There are relatively cheap development 
boards available with either Ethernet or USB interface. Might be easier 
to start with and lot more bandwidth, too! Depends of course on your 
requirements, hobby project?

Just my $0.02, HTH

J.S.

> TIA. 
> Srinivas


Article: 74919
Subject: Re: Async reset
From: mk<kal@delete.dspia.com>
Date: Thu, 21 Oct 2004 17:36:49 GMT
Links: << >>  << T >>  << A >>
On Thu, 21 Oct 2004 10:02:02 -0700, Peter Alfke <peter@xilinx.com>
wrote:
>> 
>>>  For FPGAs, when
>> programmed not have an async reset a flop might have a different clk
>> to Q delay (or a faster setup) which would make the design faster.
>I disagree.
>In an FPGA, all flip-flops in the logic fabric (what Xilinx calls CLBs or
>slices) are the same. They all have a Reset input, whether you use it or
>not, and the clock-to-Q delay is unaffected by the way the user configures
>the design and uses or not uses asynchronous or synchronous Reset or Clear.

There is nothing to disagree about. I was just trying to suggest an
explanation for the observed behavior. You being from xilinx, I'll
take your statement over my speculation about a xilinx design.

Also there is one case where one can't really depend on an FPGA to do
all the resetting for you and that's when you're prototyping an ASIC.
That's my main focus right now.


Article: 74920
Subject: Re: Async reset
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 21 Oct 2004 10:59:36 -0700
Links: << >>  << T >>  << A >>

Hi,

I hope someone will correct me if I'm wrong on this...

For Xilinx FPGAs, all SLICE flip flops (and some other
synchronous elements, too, like BlockRAM output registers,
IOB flops, etc...) are initialized to a known state at
the end of configuration by an internal, chip-wide async
reset called GSR, or "global set/reset".  It also happens
to be the case that there's another signal, GTS, or "global
three-state" that forces all I/O to be three-stated during
configuration.  These signals are not "visible" in the FPGA
Editor view of the part at any place other than the STARTUP
component.

If you instantiate specific primitives, like FDC or FDP,
you are also making a request on how you want these to be
initialized by GSR (regardless of your use of an additional,
async user reset).  FDC initializes to 0.  FDP initializes
to 1.

If you code stuff like:

reg [1:0] myflop;

always @(posedge clk or posedge init)
begin
  if (init) myflop <= 2'b10;
  else myflop <= two_bit_whatever;
end

You have just inferred an FDC and and FDP, both of which are
initialized by GSR at configuration, and both of which also
have an asynchronous user control called "init".

For a more detailed look, try implementing the code above,
and then make a back-annotated netlist using netgen and you
will see that the simulation model has the init signal
logically OR'ed with a signal called GSR, located in the
glbl.v file that you are supposed to use during simulation
of back-annotated designs.

If you code stuff like:

reg [1:0] myotherflop;

always @(posedge clk) myotherflop <= two_bit_whatever;

You have just inferred two generic D flip flops, probably
FD components, and even though you don't have an asynchronous
user control on this, it will get initialized once at the
end of configuration, by the GSR signal.  I believe FD will
default to 0, unless you specify otherwise.

If you repeat the exercise using netgen, you will see that
GSR is still used as an async reset, but there's no other
signal OR'ed with it.

> The synthesis often moves inverters around, and many signals,
> including ones through FF's, are actually the inverse of the
> expected signal.

I would hope anyone doing this transformation would also change
the "initialization state" of the flip flop when they also change
it's sense -- otherwise the transformation is not really
transparent... (I would argue it's wrong)

Eric

Article: 74921
Subject: Re: interfacing a PC based program with a FPGA
From: Steve <nospam@bit.bucket>
Date: Thu, 21 Oct 2004 13:00:17 -0500
Links: << >>  << T >>  << A >>
Srinivas wrote:

> Hi,
> I'm looking to integrate a FPGA based program into a PC based
> application.
> I understand i need to write a serial interfacing code on the FPGA
> side and an API on the PC side,considering i intend to use a RS 232
> serial interface bet'n the PC and the FPGA board.
> I need help regarding the PC side API programming.I'll be using a 'C'
> program and would like to call the FPGA based functions.
> Can anyone suggest how i go about this?any references?
> 
> TIA.
> Srinivas

Srinivas,

Are you referring to programming the serial port under windows? Then see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfiles/html/msdn_serial.asp
Oh, and try the big web secret >>www.google.com<<

If you are asking this question, then do you have a Windows toolset?  
MicroShaft does have a free compiler available
http://msdn.microsoft.com/visualc/vctoolkit2003/

However, I think the debugging facilities are not there.

Here's an open sourced project that has a debugger included.
http://www.openwatcom.org/product/features_content.html
There are others, like cygwin.

Or are you referring to distributed computing, e.g. RPC (Remote Procedure 
Call). In which case, I can't find references specific to FPGAs. Nor have 
I heard of formal RPC implementations WRT FPGAs.  Hopefully, someone
else has and thus give you a better answer if this is your question.

If your application is simple enough, you should be able to derive some
simple message passing on the serial line to call your FPGA C routines.
Done that one many a time myself.

HTH, Steve





Article: 74922
Subject: Re: Experiences with SPARTAN3?
From: gabor@alacron.com (Gabor Szakacs)
Date: 21 Oct 2004 11:13:10 -0700
Links: << >>  << T >>  << A >>
Wait a minute... Spartan doesn't have INTERNAL tristate buffers
but all FPGA's have tristates on I/O pins.  Were you trying to
run internal logic as tristate?  That is no longer available
for Spartan 3.  I/O pins should be tri-statable in any family,
but using IOB primitives from another family can get you in trouble.

googleguy2004@yahoo.com (Googleguy) wrote in message news:<7658f1c7.0410200916.688287fe@posting.google.com>...
> thomas.bartzick@atlanticzeiser.com (Thomas Bartzick) wrote in message news:<47ce721b.0410200140.7c96f079@posting.google.com>...
> > Nicolas Matringe <matringe.nicolas@numeri-cable.fr> wrote in message news:<41750735.2030301@numeri-cable.fr>...
> > > Thomas Bartzick a écrit:
> > > > Hello together,
> > > > 
> > > > has anyone experience with tristates in SPARTAN3-fpgas?
> > > > If we implement a schematic-oriented structure we won't get any
> > > > error-messages but only warnings and the design will be compiled fine.
> > > > But it seems that all our tristate outputs are driven permanently
> > > > (which is very bad!).
> > > 
> > > I have just finished a VHDL PCI design in a Spartan3 and so far it works 
> > > (tests are still in progress but tristate outputs are OK)
> > 
> > Hello Nicolas,
> > 
> > well I didn't mean, that tristates are basically a problem in SPARTAN3
> > but schematic-entry->to vhdl-transformation and also specialized cores
> > make trouble!
> > 
> > We are using a core which has been originally written vor
> > VIRTEX2-devices but was now tested on a SPARTAN3 on which we detected
> > the described phenomenons.
> > 
> > A XILINX-engineer has told me that using library-primitives which
> > carry tristates is a bad idea, because some primitives (and so the
> > tristates of them) are no more supported by XILINX in SPARTAN3.
> > Behavioural models should be used instead!
> > 
> > Ok, well any hints are welcome!
> 
> Tristates can not be instantiated in Spartan 3 devices because Spartan
> 3 devices *DO NOT *HAVE* any tristate buffers.  I believe the Virtex 4
> devices are also tristate free.
> 
> I belive in the past I was told that tristates were best instantiated
> because the tools had never been optimized for tristate synthesis. 
> I'm not sure what that meant, but I guess they knew the end was in
> sight.

Article: 74923
Subject: Re: Async reset
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 21 Oct 2004 11:48:22 -0700
Links: << >>  << T >>  << A >>
While we are on the subject of asynchronous clear or initialization at the
end of configuration:
The problem is the non-synchronous and non-simultaneous timing of the
release of this reset/preset signal, while the user clock is already
running. (Sorry for the convoluted sentence).
That's where state machines can get screwed up: the asynchronous (p)reset
might linger a little longer on one flip-flop than on the other, and the
user clock might occur during this timing difference. Bad luck!
That's why smart designers identify such state machines and give them an
additional, longer and synchronous reset input. An SRL16 is a convenient
tool to control this delay.
This subject has been covered here many times, but it bears repeatung...
Peter Alfke

> From: Eric Crabill <eric.crabill@xilinx.com>
> Organization: Xilinx, Inc.
> Newsgroups: comp.arch.fpga
> Date: Thu, 21 Oct 2004 10:59:36 -0700
> To: glen herrmannsfeldt <gah@ugcs.caltech.edu>
> Subject: Re: Async reset
> 
> 
> Hi,
> 
> I hope someone will correct me if I'm wrong on this...
> 
> For Xilinx FPGAs, all SLICE flip flops (and some other
> synchronous elements, too, like BlockRAM output registers,
> IOB flops, etc...) are initialized to a known state at
> the end of configuration by an internal, chip-wide async
> reset called GSR, or "global set/reset".  It also happens
> to be the case that there's another signal, GTS, or "global
> three-state" that forces all I/O to be three-stated during
> configuration.  These signals are not "visible" in the FPGA
> Editor view of the part at any place other than the STARTUP
> component.
> 
> If you instantiate specific primitives, like FDC or FDP,
> you are also making a request on how you want these to be
> initialized by GSR (regardless of your use of an additional,
> async user reset).  FDC initializes to 0.  FDP initializes
> to 1.
> 
> If you code stuff like:
> 
> reg [1:0] myflop;
> 
> always @(posedge clk or posedge init)
> begin
> if (init) myflop <= 2'b10;
> else myflop <= two_bit_whatever;
> end
> 
> You have just inferred an FDC and and FDP, both of which are
> initialized by GSR at configuration, and both of which also
> have an asynchronous user control called "init".
> 
> For a more detailed look, try implementing the code above,
> and then make a back-annotated netlist using netgen and you
> will see that the simulation model has the init signal
> logically OR'ed with a signal called GSR, located in the
> glbl.v file that you are supposed to use during simulation
> of back-annotated designs.
> 
> If you code stuff like:
> 
> reg [1:0] myotherflop;
> 
> always @(posedge clk) myotherflop <= two_bit_whatever;
> 
> You have just inferred two generic D flip flops, probably
> FD components, and even though you don't have an asynchronous
> user control on this, it will get initialized once at the
> end of configuration, by the GSR signal.  I believe FD will
> default to 0, unless you specify otherwise.
> 
> If you repeat the exercise using netgen, you will see that
> GSR is still used as an async reset, but there's no other
> signal OR'ed with it.
> 
>> The synthesis often moves inverters around, and many signals,
>> including ones through FF's, are actually the inverse of the
>> expected signal.
> 
> I would hope anyone doing this transformation would also change
> the "initialization state" of the flip flop when they also change
> it's sense -- otherwise the transformation is not really
> transparent... (I would argue it's wrong)
> 
> Eric


Article: 74924
Subject: strange behavior in lpm_counter
From: hjones1380@hotmail.com (pjjones)
Date: 21 Oct 2004 11:52:39 -0700
Links: << >>  << T >>  << A >>
Hi,
I'm attempting to implement a 12-bit counter from a vhdl file using
the lpm_counter.  The output count goes something like this
  125..126..255..128..129 
That is, bit 8 (output[7]) goes high one clock cycle too early.  The
same thing happens when bit 9 (output[8]) goes high, this time the
count is as follows:
  251..252..509..510..383..256..257..258
Once again bit 8 goes high one clock cycle early, and bit 9 changes 3
cycles early.

At first, I noticed this and assumed there was a problem in my logic
driving the counter.  Using Quartus, I created a new 12 bit counter
using the mega-function wizard and placed it next to my vhdl
component.  That counter has the exact same glitch.  sclr and sset are
grounded, updown and cnt_en are connected to vcc.  The only input is a
clock.  Next I completely removed my component, and the counter still
has a glitch in the output.  The entire .bdf file is a counter with an
input clock and output lines, the glitch remains.

Next, I created a new project, re-created a counter, and of course
this one works flawlessly.

It seems that no matter what I do, I can't make the broken counter
work correctly, nor break the working counter by adding my component
to it.

Has anyone experienced something similar to this before?  Any ideas on
how to fix it?



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