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 119475

Article: 119475
Subject: Re: Filtering the FPGA reset signal
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 21 May 2007 10:00:21 +0100
Links: << >>  << T >>  << A >>
"Eli Bendersky" <eliben@gmail.com> wrote in message 
news:1179737183.440448.61650@x18g2000prd.googlegroups.com...
>
> What are your thoughts ?
>
> Thanks in advance
>
Hi Eli,
You don't need my thoughts, especially at this early hour! Luckily, there 
are plenty of other thoughts easily available. :-)

Google:-
reset synchronous site:xilinx.com

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=kc_smart_reset

HTH, Syms.

p.s. We've been over this many times on this newsgroup before. You'd do well 
to trawl the archive.




Article: 119476
Subject: Re: VHDL newbie: building sequential circuits with basic gates
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 21 May 2007 09:19:51 GMT
Links: << >>  << T >>  << A >>

"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote in message 
news:f2rh0u$kh6$1@newsserver.cilea.it...
> In news:XX24i.1173$u56.485@newssvr22.news.prodigy.net timestamped Sun,
> 20 May 2007 17:19:47 -0400, "KJ" <kkjennings@sbcglobal.net> posted:
> "[..]
>
> Just to clarify: does std_ulogic have a huge disadvantage in contrast
> to std_logic when modelling combinatorial feedback?
>
No disadvantages that I can think of.

<snip> I understand and may agree with this point but I disagree with the
> particular example as being an issue of skill... I would classify this
> as more of an issue of whether the designers know what their tools do.
>
Knowledge of what the tools do and how best to use those tools is part of 
what I would classify as 'skill', others may feel differently.

KJ 



Article: 119477
Subject: Re: Timing not met but working on board
From: vssumesh <vssumesh_asic@yahoo.com>
Date: 21 May 2007 03:46:22 -0700
Links: << >>  << T >>  << A >>
On May 21, 1:52 pm, "J.Ram" <jrgod...@gmail.com> wrote:
> Hi all,
> I developed a design in which i need a master clock of 90Mhz, so
> during synthesis max. freq obtained is 56Mhz and  timing is met for
> global clock of 50Mhz, but timing are not met for 90Mhz.
> but design is working on board for 90Mhz clcock.
> In design all lower level module are working above 100 Mhz, but in top
> module after integarting sub blocks it works around 56 Mhz in
> synthesis and working at 90Mhz on board.
> so please tell me what is wrong with this design.
> Regards
> J.Ram

It may be because u are not yet applied any test vectors which will
violate the 50MHz+ timings..... That may be the one reason why it is
working on the board....


Article: 119478
Subject: Re: seeking insights for potential reconfigurable computing application platforms
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: 21 May 2007 10:56:24 GMT
Links: << >>  << T >>  << A >>
In news:464B9365.9040105@itee.uq.edu.au timestamped Thu, 17 May 2007
09:27:33 +1000, John Williams <jwilliams@itee.uq.edu.au> posted:
"[..]

Are you aware of the Reconfigurable Scalable Computing (RSC) project
being run out of NASA Langley?

A few web references below, but feel free to contact me directly if
you'd like more info.

http://linuxdevices.com/news/NS9415221766.html

http://www.klabs.org/mapld05/presento/130_hodson_p.ppt
http://www.klabs.org/mapld05/presento/125_somervill_p.ppt
http://www.klabs.org/mapld05/presento/1001_williams_p.ppt

Regards,

John"


Dear Dr. Williams,

I note that the term "Bus" appears twice on
WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#299,9,Reconfigurable Processing Module
in contrast to the term "Scalable Network" on
WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#268,4,Scalable Architecture

Is the cache mentioned on
WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#308,10,RPM Features
suitable for realtime use?

"Xilinx logic is triplicated" on
WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#308,10,RPM Features
is not detailed enough to show what risks your form of triplication is susceptible to and resilient to. On
WWW.Klabs.org/mapld05/presento/125 somervill p.ppt#281,10,Embedded Processing
it is written:
"Design mitigated with XTMR tool (or manually)".
What drives your choice for the XTMR tool or manual error detection and correction? However, I note from
WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#266,11,MicroBlaze, Linux and RSC
that your reconfigurable systems for NASA are not intended for spacecraft survivability, so protection against errors might not be very important for you.

On
WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#285,16,MicroBlaze Multiprocessing
it is claimed
"We can put about 8 CPUs in an FPGA"
so what is the 33% utilization "of FIFO16/RAM16s" on
WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#260,9,MicroBlaze
for?

Thanks,
Colin Paul Gloster

Article: 119479
Subject: Re: How to insert tab in Write() function in VHDL
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 21 May 2007 13:01:06 +0200
Links: << >>  << T >>  << A >>
On 19 May 2007 18:58:35 -0700, Weng Tianxiang wrote:

>This time I don't agree with your opinion.
>
>What I do is to print out all related waveforms I am interested in and
>using tab is to make me easier to manually check if the waveforms are
>right so that a software can be used later to check the waveforms
>without 1 clock after another to manually check waveforms.

Ah - you are using tabs to create a tab-separated file for
Excel or some similar software?  If so, then I'm sorry - yes -
that's OK.

I still think tabs are a crazy way to create human-readable
layouts, because different editors and terminals may handle
tabs in different ways.  It can get *very* ugly.

> ht works for tab in VHDL.

Indeed.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 119480
Subject: Re: Timing not met but working on board
From: dalai lamah <antonio12358@hotmail.com>
Date: Mon, 21 May 2007 11:18:37 GMT
Links: << >>  << T >>  << A >>
Un bel giorno J.Ram digiṭ:

> but timing are not met for 90Mhz.
> but design is working on board for 90Mhz clcock.

As far as I know, the timing extimations in ISE are made assuming always
the worst case scenario (worst temperatures, worst limit of each specified
parameter, etc). They represent a "lower performance limit", but for the
actual speed limit I've noticed a lot of difference between the extimation
and the reality, especially in blocks with few gates. For example in a
SpartanII design I have a 8-bit gray counter incremented by an external
clock that in reality exceeds 250 MHz of performance, while the timing
extimations suggest a maximum frequency that barely exceeds 100 MHz.

-- 
emboliaschizoide.splinder.com

Article: 119481
Subject: Re: Timing not met but working on board
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 21 May 2007 07:20:35 -0400
Links: << >>  << T >>  << A >>

"J.Ram" <jrgodara@gmail.com> wrote in message 
news:1179737574.032115.244360@a26g2000pre.googlegroups.com...
> Hi all,
> I developed a design in which i need a master clock of 90Mhz, so
> during synthesis max. freq obtained is 56Mhz and  timing is met for
> global clock of 50Mhz, but timing are not met for 90Mhz.
> but design is working on board for 90Mhz clcock.
> In design all lower level module are working above 100 Mhz, but in top
> module after integarting sub blocks it works around 56 Mhz in
> synthesis and working at 90Mhz on board.
> so please tell me what is wrong with this design.
> Regards
> J.Ram

What is wrong is your expectation that based on a sample of one board that 
works at 90 MHz, that all boards over all rated temperature conditions over 
all possible input conditions will also work at that speed.

It's not at all unusual to expect that a single board in a lab environment 
might happen to work at ~50% over the speed computed by the timing analyzer. 
Try building thousands of such boards and put them in the extreme rated 
temperature conditions and give them the most stressful input pattern and 
see how many of those boards still work.  What you'll likely find is a lot 
of fallout...but again you might have a few survivors.

KJ 



Article: 119482
Subject: Re: external clock frequency doubles
From: Venu <get2venu@gmail.com>
Date: 21 May 2007 04:35:51 -0700
Links: << >>  << T >>  << A >>
Thanks for the input Peter. I have started looking into the pointers
that you have provided.

Just to make this discussion complete, I would like to record one
further observation that I made.

The 2 MHz clock is driving the FPGA ( as I had previously mentioned )
as well as a codec on the board. When the codec power supply is
switched off , then the FPGA is generating pulses at pulses at 500 ns
width ( 1 clock period of the 2MHz clock) . But as soon as the codec
is turned on , the FPGA pulses are now of 250 ns width. In both the
cases though , the external clock frequency remains 2.048 MHz.

Uptil now my ucf setting for the clock pin input was as follows
NET TDM_CLK_pin LOC = "B16";
NET TDM_CLK_pin IOSTANDARD = LVCMOS25;

I will try to use any of the IOB settings to terminate the clock
properly. If I can solve this problem, I will report it in this
discussion.

Thanks once again
Venu




Peter Alfke wrote:
> Venu,
> I am sure that your problem is caused by poor signal integrity at the
> clock input to the FPGA. There may be overshoot, undershoot and
> ringing, which causes the FPGA to interpret the falling clock edge as
> another rising clock edge.
> Try to clean up the clock signal, terminate it properly.
> 2 MHz is a very low clock frequency, and it might have a slow rise/
> fall time, which might be another source of double-triggering caused
> by noise during the transition.
> Peter Alfke, from home.
>
>
> On May 19, 2:35 am, Venu <get2v...@gmail.com> wrote:
> > Hi People,
> >
> > I am attempting to interface the Xilinx Virtex - II Pro FPGA with a
> > quad channel codec.
> >
> > I am using XC2VP30-FF896 FPGA on the Xilinx University Program
> > Development Board.I had applied a 2.048MHz TDM clock to the FPGA pin
> > B16, which is the GCLK6S ( Global Clock Input).
> >
> > My problem is that by the time this clock reaches my IP on the OPB
> > Bus , its frequency doubles!!  I have confirmed this by checking
> > pulses generated on the basis of this clock, on a Digital
> > Oscilloscope.
> >
> > I have confirmed that I have not instantiated a DCM in the external
> > clock path . The resource utilisation shows that the system uses only
> > 1 DCM , which is attached to the sys_clk_s.
> >
> > For now , to make my system work , i have divided the clock frequency
> > inside my IP and then applied it to the individual block. But the
> > confusion of why this exactly happened still remains.
> >
> > Thanks
> > Venu


Article: 119483
Subject: Cyclone FPGAs in Switzerland
From: Richard Klingler <me@aol.com>
Date: Mon, 21 May 2007 13:46:19 +0200
Links: << >>  << T >>  << A >>
EHLO (o;


I tried several weeks ago to contact EBV Switzerland where to get
EP1C and EP2C devices in smaller quantities than their 60/90
package size...but never got any feedback...

Also their website gives no results when doing inventory search
nor their contact form works anymore...looks really borked to me (o;


So...any experience with ordering devices online from Altera
directly?


Was so much nicer support at EBV Finland back then (o;



cheers
rick

Article: 119484
Subject: Re: Cyclone FPGAs in Switzerland
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 21 May 2007 12:11:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
Richard Klingler <me@aol.com> wrote:
> EHLO (o;


> I tried several weeks ago to contact EBV Switzerland where to get
> EP1C and EP2C devices in smaller quantities than their 60/90
> package size...but never got any feedback...

> Also their website gives no results when doing inventory search
> nor their contact form works anymore...looks really borked to me (o;


> So...any experience with ordering devices online from Altera
> directly?


> Was so much nicer support at EBV Finland back then (o;

Consider to buy at Digikey. At lot of EP1 parts are listed as stock

I odered about 16 different part numbers, including Xilinx XC3S500E on
Friday evening and have them alrteady on the desk.


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

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

Article: 119485
Subject: Re: Cyclone FPGAs in Switzerland
From: daniel.studer@ebv.com
Date: 21 May 2007 05:22:23 -0700
Links: << >>  << T >>  << A >>
Dear Rick

What was the problem getting 1C/2C at EBV in Switzerland ?
Call me so we can discuss this.

Regards
Daniel
+41447456161
daniel.studer@ebv.com

On 21 mei, 13:46, Richard Klingler <m...@aol.com> wrote:
> EHLO (o;
>
> I tried several weeks ago to contact EBV Switzerland where to get
> EP1C and EP2C devices in smaller quantities than their 60/90
> package size...but never got any feedback...
>
> Also their website gives no results when doing inventory search
> nor their contact form works anymore...looks really borked to me (o;
>
> So...any experience with ordering devices online from Altera
> directly?
>
> Was so much nicer support at EBV Finland back then (o;
>
> cheers
> rick



Article: 119486
Subject: Re: UART Receiver Parity Check
From: Gabor <gabor@alacron.com>
Date: 21 May 2007 05:32:10 -0700
Links: << >>  << T >>  << A >>
On May 21, 4:19 am, Anson.Stugg...@gmail.com wrote:
> Hello,
>
> I'm trying to learn VHDL and here I'm adding a parity bit to Ben
> Cohen's UART Receiver. RxReg(9) is incoming parity bit from
> transmitter side. A 0 output at Parity_err means no parity error
> detected and otherwise. The receiver has to match the incoming parity
> bit with its own parity bit which is calculated using XOR of its data
> byte, RxReg(8 downto 0). My statement below is giving me a full byte
> delay because my control statements for the parity check. I think it's
> because of the process statement, but that's all I can think of now.
>
> can someone let me know how to fix this?
>
> Thanks,
> AS
> -------------------------------------------------------------------------------
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> -------------------------------------------------------------------------------
> --
> --   Project     :  ATEP
> --   File name   :  uartrx.vhd
> --   Title       :  UART Receiver
> --   Description :  UART receiver  selection
> --
> -------------------------------------------------------------------------------
> --   Revisions   :
> --          Date                Author          Revision
> Comments
> -- Sat Oct 30 10:05:49 1994     cohen   Rev A           Creation
> -------------------------------------------------------------------------------
> entity UartRx_Nty is
>   port (Clk16xT       : in      std_logic; -- 16 of these clocks per
> bit
>         ResetF        : in      std_logic;
>         Serial_InT    : in      std_logic;
>         DataRdyT      : out     boolean;
>         DataOuT       : out     std_logic_Vector(7 downto 0);
>         Parity_err    : out     std_logic; -- Parity Error Output
>         BitClkT       : out     std_logic); -- same speed clock as Tx
> end UartRx_Nty;
>
> architecture UartRx_Beh of UartRx_Nty is
>   subtype Int0to15_Typ is integer range 0 to 15;
>   constant RxInit_c : std_logic_Vector(10 downto 0) := "11111111111";
>   signal RxReg_s   : std_logic_Vector(10 downto 0); -- the receive
> register
>   signal Count16_s : Int0to15_Typ;            --  for divide by 16
>   signal RxMT_s    : boolean;            --   Receive register empty
>   signal RxIn_s      : std_logic;                --   registered
> serial input
>   signal Parity_Reg : std_logic;
>
> begin  --  UartRx_Beh
>
> -----------------------------------------------------------------------------
>   --  Process:   Xmit_Lbl
>   --  Purpose:   Models the receive portion of a UART.
>   --             Operation is as follows:
>   --             . All operations occur on rising edge of Clk16xT.
>   --             . Clk16xT runs 16x the bit clock rate
>   --             . If ResetF = '0' then
>   --                 RxReg_s is reset to "11111111111".
>   --                 Count_s   is reset to 0.
>   --             . If (RxMT_s and RxIn_s = '0') then
>   --                 Start of new byte
>   --             . If Count16_s = 7  and not RxMT_s then --   mid
> clock
>   --                 Sample here where bit most stable
>   --                 RxReg_s <= RxIn_s & RxReg_s(9 downto 1);
>   --             . Entire byte received when
>   --                 not RxMT_s and RxReg_s(9) = '1' and RxReg_s(0) =
> '0'
>   --
>
> -----------------------------------------------------------------------------
>   Rx_Lbl : process
>
>   begin  --  process Rx_Lbl
>      wait until Clk16xT'event and Clk16xT = '1';
>      --   Clock serial input into RxIn_s
>      RxIn_s <= Serial_InT;
>
>      --   reset
>      if (ResetF = '0') then
>        Count16_s <= 0;                   --   reset divide by 16
> counter
>        RxMT_s <= true;                    --   no message starting;
> idle
>        RxReg_s <= RxInit_c;
>
>      --   new bit start
>      elsif (RxMT_s and RxIn_s = '0') then
>        Count16_s <= 0;                   --   reset divide by 16
> counter
>        RxMT_s <= false;                    --   new message starting
>        RxReg_s <= RxInit_c;
>
>      --   If in a receive transaction mode
>      --   if @ mid bit clock then clock data into register
>      elsif Count16_s = 7  and not RxMT_s then --   mid clock
>        RxReg_s <= RxIn_s & RxReg_s(10 downto 1);
>        Count16_s <= Count16_s + 1;
>
>      --   if @ 16X clock rollover
>      elsif Count16_s = 15 then
>          Count16_s <= 0;
>
>      --   Normal count16 counter increment
>      else
>        Count16_s <= Count16_s + 1;
>      end if;
>
> -------------------------------------------------------------Parity
> Check Control
> Statement---------------------------------------------------------
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>      --   Check if a data word is received
>      if not RxMT_s and RxReg_s(10) = '1' and RxReg_s(0) = '0' then
>        Parity_reg = ((RxReg_s(1) xor RxReg_s(2)) xor (RxReg_s(3) xor
> RxReg_s(4))) xor ((RxReg_s(5) xor RxReg_s(6)) xor (RxReg_s(7) xor
> RxReg_s(8)))
>
>      if Parity_reg /= RxReg_s(9) then
>                     Parity_err <= '1';
>            else
>                     Parity_err <= '0';
>            end if;
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>        DataRdyT <= true;
>        RxMT_s <= true;
>      else
>        DataRdyT <= false;
>      end if;
>   end process Rx_Lbl;
>
> -------------------------------------------------------------------------------
> --  Concurrent signal assignment for BitClkT and DataOut
> -------------------------------------------------------------------------------
>
>   BitClkT <=      '1' when Count16_s = 10
>              else '0';
>
>   DataOuT <= RxReg_s(8 downto 1);
>
> end UartRx_Beh;


The point of sending the parity bit at the end of a transmission
is that you can compute the parity as you transmit, one bit at a
time.  Regardless of the parity bit location, you can do the same
for receiving because as far as parity checking is concerned, the
parity bit is just another input to your XOR function.

There is no need to calculate parity on the 8-bit parallel data.
You can receive "running" parity one bit at a time as you fill
the shift register, then your parity check will be complete at
the same time you transfer data to the parallel register.

Parity checking is effectively just a "T" flip-flop that gets
cleared between data words.  The T input is attached to the
incoming data.  Clock is enabled at the same time as your shift
register.  When all bits including parity have been shifted in,
the Q of the flip-flop should have a constant value which only
depends on the type of parity (even or odd).

By the way, the reason you're getting a delay in your code
is that the check is inside the clocked process that loads
the parity register.  So the data on the output of the
parity register at the time the process runs is from the
previous word.  If you wanted to use a parallel method
of parity checking, you either need to calculate the
parity in a separate non-clocked process or use a
variable for Parity_Reg so the parity check is
executed in the same cycle.

HTH,
Gabor


Article: 119487
Subject: Re: Filtering the FPGA reset signal
From: Eli Bendersky <eliben@gmail.com>
Date: 21 May 2007 05:42:16 -0700
Links: << >>  << T >>  << A >>
On May 21, 11:00 am, "Symon" <symon_bre...@hotmail.com> wrote:
> "Eli Bendersky" <eli...@gmail.com> wrote in message
>
> news:1179737183.440448.61650@x18g2000prd.googlegroups.com...
>
> > What are your thoughts ?
>
> > Thanks in advance
>
> Hi Eli,
> You don't need my thoughts, especially at this early hour! Luckily, there
> are plenty of other thoughts easily available. :-)
>
> Google:-
> reset synchronous site:xilinx.com
>
> http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=kc_smart...
>
> HTH, Syms.
>
> p.s. We've been over this many times on this newsgroup before. You'd do well
> to trawl the archive.


I think you misunderstood my question. I am not asking about a
synchronous vs. asynchronous reset and about reset release. I'm asking
about filtering potential noise that may be present on the reset_n
line on the board that goes between the voltage supervisor and the
FPGA.

Eli


Article: 119488
Subject: Re: Timing not met but working on board
From: vssumesh <vssumesh_asic@yahoo.com>
Date: 21 May 2007 06:04:16 -0700
Links: << >>  << T >>  << A >>
On May 21, 4:20 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "J.Ram" <jrgod...@gmail.com> wrote in message
>
> news:1179737574.032115.244360@a26g2000pre.googlegroups.com...
>
> > Hi all,
> > I developed a design in which i need a master clock of 90Mhz, so
> > during synthesis max. freq obtained is 56Mhz and  timing is met for
> > global clock of 50Mhz, but timing are not met for 90Mhz.
> > but design is working on board for 90Mhz clcock.
> > In design all lower level module are working above 100 Mhz, but in top
> > module after integarting sub blocks it works around 56 Mhz in
> > synthesis and working at 90Mhz on board.
> > so please tell me what is wrong with this design.
> > Regards
> > J.Ram
>
> What is wrong is your expectation that based on a sample of one board that
> works at 90 MHz, that all boards over all rated temperature conditions over
> all possible input conditions will also work at that speed.
>
> It's not at all unusual to expect that a single board in a lab environment
> might happen to work at ~50% over the speed computed by the timing analyzer.
> Try building thousands of such boards and put them in the extreme rated
> temperature conditions and give them the most stressful input pattern and
> see how many of those boards still work.  What you'll likely find is a lot
> of fallout...but again you might have a few survivors.
>
> KJ

Can we say that is ~50%....


Article: 119489
Subject: Re: Timing not met but working on board
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 21 May 2007 13:04:39 GMT
Links: << >>  << T >>  << A >>
J.Ram wrote:
> Hi all,
> I developed a design in which i need a master clock of 90Mhz, so
> during synthesis max. freq obtained is 56Mhz and  timing is met for
> global clock of 50Mhz, but timing are not met for 90Mhz.
> but design is working on board for 90Mhz clcock.
> In design all lower level module are working above 100 Mhz, but in top
> module after integarting sub blocks it works around 56 Mhz in
> synthesis and working at 90Mhz on board.
> so please tell me what is wrong with this design.
> Regards
> J.Ram

It's not the *entire* chip that's limited to 56 MHz.  Use the Xilinx 
Timing Analyzer to determine which paths are failing timing.  This will 
both inform you as to where you might see the failure show up (e.g., if 
it's an accumulator to a register read by software, you'll only know 
it's a problem if you know what the count should be when/if you read 
it).  It will also give you an idea of where to recode your RTL to 
achieve 100% timing.

Article: 119490
Subject: Re: Filtering the FPGA reset signal
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 21 May 2007 09:14:42 -0400
Links: << >>  << T >>  << A >>

>
> I think you misunderstood my question. I am not asking about a
> synchronous vs. asynchronous reset and about reset release. I'm asking
> about filtering potential noise that may be present on the reset_n
> line on the board that goes between the voltage supervisor and the
> FPGA.
>
If you have some reason for suspecting that the reset_n signal is noisy then 
you should address that with board level changes to get rid of the noise 
source.

If your FPGA and board design happens to have a single clock source then 
synchronizing the incoming reset signal to that clock before distributing it 
anywhere would make the design somewhat more immune to ground bounce of the 
chip relative to the plane since the reset signal would only be sampled at 
the clock edge and the I/O switching which causes the bounce will occur 
after that edge.  If you don't happen to have this special case though then 
you'll need to deal with the noise source directly as I mentioned.

I'm suspecting though that the reason for the question is because you think 
'reset_n' is such an important signal that some form of noise filtering 
should be done.  That reasoning though is flawed.  I'm guessing that there 
are probably very few inputs to your FPGA design that could tolerate noise 
to the extent that the logic level gets misinterpreted.  Reset just happens 
to be one of your inputs, what about noise on any of the rest?

KJ 



Article: 119491
Subject: Re: Timing not met but working on board
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 21 May 2007 06:24:03 -0700
Links: << >>  << T >>  << A >>
On 21 Mai, 13:18, dalai lamah <antonio12...@hotmail.com> wrote:
> Un bel giorno J.Ram digit=F2:
>
> > but timing are not met for 90Mhz.
> > but design is working on board for 90Mhz clcock.
>
> As far as I know, the timing extimations in ISE are made assuming always
> the worst case scenario (worst temperatures, worst limit of each specified
> parameter, etc). They represent a "lower performance limit",

True.
Another aspect is that static timing analysis is pessimistic. The
slowest path
reported might be a path that is never switching in the design
scenario at hand
or even can't switch under any circumstances (false path).

Kolja Sulimma


Article: 119492
Subject: Error in NGDBuild
From: koustav79@gmail.com
Date: 21 May 2007 07:10:24 -0700
Links: << >>  << T >>  << A >>
Hello everybody,

                     I was trying NGDbuild for a DDR memory controller
implementation. I am getting the following error:

ERROR:NgdBuild:924 - bidirect pad net 'cntrl0_ddr1_dq(0)' is driving
non-buffer
   primitives:
     pin I0 on block _n00001 with type LUT4

Does anybody encountered this before? Any suggestions will be helpful.

Thanks,
Koustav


Article: 119493
Subject: SelectIO banking rules
From: LilacSkin <lpaulo07@iseb.fr>
Date: 21 May 2007 07:49:02 -0700
Links: << >>  << T >>  << A >>
Hi,

Can I drive a LCVMOS25 (input) and a LVTTL (input/output) in the same
bank even if there is VCCIO problems ?

Thanks!


Article: 119494
Subject: Re: external clock frequency doubles
From: Peter Alfke <alfke@sbcglobal.net>
Date: 21 May 2007 07:50:29 -0700
Links: << >>  << T >>  << A >>
Use a good oscilloscope to monitor the FPGA clock input.
If the rise/fall time is very fast 1 to 2 ns, then you should worry
about reflections, and you need termination.
If the rise/fall time is slow (tens of ns) then termination is not
needed, but the signal is sensitive to noise.
In either case, the FPGA interprets the falling clock edge as multiple
edges, one of them a rising edge.
Peter Alfke

On May 21, 4:35 am, Venu <get2v...@gmail.com> wrote:
> Thanks for the input Peter. I have started looking into the pointers
> that you have provided.
>
> Just to make this discussion complete, I would like to record one
> further observation that I made.
>
> The 2 MHz clock is driving the FPGA ( as I had previously mentioned )
> as well as a codec on the board. When the codec power supply is
> switched off , then the FPGA is generating pulses at pulses at 500 ns
> width ( 1 clock period of the 2MHz clock) . But as soon as the codec
> is turned on , the FPGA pulses are now of 250 ns width. In both the
> cases though , the external clock frequency remains 2.048 MHz.
>
> Uptil now my ucf setting for the clock pin input was as follows
> NET TDM_CLK_pin LOC = "B16";
> NET TDM_CLK_pin IOSTANDARD = LVCMOS25;
>
> I will try to use any of the IOB settings to terminate the clock
> properly. If I can solve this problem, I will report it in this
> discussion.
>
> Thanks once again
> Venu
>
> Peter Alfke wrote:
> > Venu,
> > I am sure that your problem is caused by poor signal integrity at the
> > clock input to the FPGA. There may be overshoot, undershoot and
> > ringing, which causes the FPGA to interpret the falling clock edge as
> > another rising clock edge.
> > Try to clean up the clock signal, terminate it properly.
> > 2 MHz is a very low clock frequency, and it might have a slow rise/
> > fall time, which might be another source of double-triggering caused
> > by noise during the transition.
> > Peter Alfke, from home.
>
> > On May 19, 2:35 am, Venu <get2v...@gmail.com> wrote:
> > > Hi People,
>
> > > I am attempting to interface the Xilinx Virtex - II Pro FPGA with a
> > > quad channel codec.
>
> > > I am using XC2VP30-FF896 FPGA on the Xilinx University Program
> > > Development Board.I had applied a 2.048MHz TDM clock to the FPGA pin
> > > B16, which is the GCLK6S ( Global Clock Input).
>
> > > My problem is that by the time this clock reaches my IP on the OPB
> > > Bus , its frequency doubles!!  I have confirmed this by checking
> > > pulses generated on the basis of this clock, on a Digital
> > > Oscilloscope.
>
> > > I have confirmed that I have not instantiated a DCM in the external
> > > clock path . The resource utilisation shows that the system uses only
> > > 1 DCM , which is attached to the sys_clk_s.
>
> > > For now , to make my system work , i have divided the clock frequency
> > > inside my IP and then applied it to the individual block. But the
> > > confusion of why this exactly happened still remains.
>
> > > Thanks
> > > Venu



Article: 119495
Subject: Re: Single Chip MSX computer full schematic and VHDL sources
From: Antti <Antti.Lukats@googlemail.com>
Date: 21 May 2007 08:22:59 -0700
Links: << >>  << T >>  << A >>
Nico Coesel schrieb:
> Antti <Antti.Lukats@googlemail.com> wrote:
>
> >Hi
> >
> >http://code.google.com/p/fpga-retro/downloads/list
> >
> >there is the distribution archive for the one chip MSX project
> >would be fun to convert it for some xilinx board, :)
> >
> >I have been hunting for those VHDL code for ages, all links ended
> >dead somewhere, but with heavy searching the archive was found too.
> >
> >Antti
>
> Cool! Is it the MSX-I or MSX-II? I believe I have the MSX-II video
> chip in VHDL somewhere... Never bothered to do something with it
> though.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl

hum,, good question, need look sources to understand i guess..

I just uploaded the "XST fixed" VHDL sources also, they are good
at least for resource estimate runs.
100% of logic and BRAM of XC3S1000

Antti


Article: 119496
Subject: Re: weird PACE Error, not one google result
From: Ligeti <jllsela@gmail.com>
Date: 21 May 2007 08:50:43 -0700
Links: << >>  << T >>  << A >>
Hello
I get the same problem working with Spartan 3 and Virtex II Pro, it
started when I was trying the ISE 9.1i Quick Start Tutorial (am new to
ISE in general), when it comes to pin assigning the pins, PACE gives
me this message:
"PACE was unable to parse the HDL source file 'C:\...\counter.vhd' "
and after that PACE shows this (whatever you call it):

Loading device for application Rf_Device from file '3s200.nph' in
environmentC:\Xilinx91i.
ERROR:HDLParsers:3562 - pepExtractor.prj line 1  Expecting 'vhdl' or
'verilog'   keyword,  found 'work'.

I searched and search, and the only result was this topic ... so I
sent an Email to mludwig hoping that he knows by now an answer for
this, but he didnt answer me :-(
So I am trying to refresh the topic ... Thats all for the moment,
thank you!

note: sorry for my bad English.


Article: 119497
Subject: Re: SelectIO banking rules
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 21 May 2007 09:01:16 -0700
Links: << >>  << T >>  << A >>
"LilacSkin" <lpaulo07@iseb.fr> wrote in message 
news:1179758942.207465.14080@36g2000prm.googlegroups.com...
> Hi,
>
> Can I drive a LCVMOS25 (input) and a LVTTL (input/output) in the same
> bank even if there is VCCIO problems ?
>
> Thanks!

Since the LVTTL requires 3.3V, the software won't let you do that.

You can, perhaps, receive signals that aren't VCCIO compliant as outputs. 
Your data sheet will show what signals can be received at which VCCIO bank 
standard. 



Article: 119498
Subject: Re: VHDL newbie: building sequential circuits with basic gates
From: Jim Lewis <jim@synthworks.com>
Date: Mon, 21 May 2007 09:42:13 -0700
Links: << >>  << T >>  << A >>
KJ,
> Another example of such a difference between when a particular type is good 
> to use or not would be between the use of type 'unsigned' or type 'natural' 
> when creating a counter (or adder).  In the hands of the more skilled 
> designer, type 'natural' is usually preferred; in the hands of the less 
> skilled the use of type 'natural' can cause problems because signals of type 
> natural will always magically initialize to 0 in simulation.  

Do you find that you are getting good usage of carry out in
place of zero detection with natural?

For example, with unsigned, I can explicitly code the carry out
by adding one bit to my decrement resource (variable Count17)
as shown below.  As a result, the zero detect is implemented as
a single carry/borrow cell (one LUT) for any size of counter.
If you do a test, make sure to use at least 16 bits so you can
notice the difference.

   signal EndDetect : std_logic ;
   signal Count16Reg : unsigned(15 downto 0) ;
...

process (...)
   variable count17 : unsigned(16 downto 0) ;
begin
...
   Count17     := Count17 - 1 ;
   EndDetect   <= Count17(16) ; -- carry bit.
   Count16Reg  <= Count17 (15 downto 0) ;
...

Now if the current generation of synthesis tools can always
extract this information from the following, then there is no
point in working to create the result with unsigned.

   signal EndDetect : std_logic ;
   signal CountReg : natural range 0 to 2**16 - 1 ;

...
   CountReg <= CountReg - 1 ;
...
   EndDetect <= '1' when CountReg = 0 else '0' ;


WRT initialzation, you will always find that in gate sims,
however, it is not a nice time to find it if a rookie forgets
to reset many registers.


Cheers,
Jim

Article: 119499
Subject: Does FPGA need CPU for processing a packet/frame
From: NewToFPGA <hetzme@yahoo.com>
Date: 21 May 2007 09:43:08 -0700
Links: << >>  << T >>  << A >>
I would like to know if an FPGA needs CPU for processing a packet/
frame that it receives.

For example an FPGA is capable of processing a frame based on its
destination Address (similar to layer 2 ethernet device). Does the
FPGA takes help of CPU in actually moving the frame from one port to
another port? Or does it do on its own.

My understanding of an FPGA is that during the start up time we need
to register the FPGA with the processor. We also register the actions
that we perform, interrupts. We configure the FPGA to do specific job
during the FPGA initialization. After that FPGA does not use CPU for
any of the internal work it has to do. It can talk to the CPU in case
of exceptions, so that CPU can look at the packet and do more
application level processing.

Thanks.




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