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 63700

Article: 63700
Subject: Re: Slightly unmatched UART frequencies
From: "Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com>
Date: Sun, 30 Nov 2003 23:28:53 -0800
Links: << >>  << T >>  << A >>
Simon Peacock <nowhere@to.be.found> wrote:
> you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks
> ... ALL async UARTs MUST be capable of handling this.. that's why there's
> flow control.

There are a lot of systems in the world that don't use flow control and
simply rely on a 'mutual agreement' between the interconnected devices that
large streams of unbroken serial data isn't produced.  This is especially
the case of, e.g., sensors that produce real-time RS-232 output data with no
buffering of their own -- in such a case flow control would just throw data
away, so it's often not implemented to begin with.  (I have a motto
something to the effect of... if detecting an error does no more good than
just ignoring it, you might as well ignore it... Although unfortunately this
idea is often perverted into, 'if detecting an error takes effort, even if
ignoring it causes the machine to rip off someone's arm, you might as well
ignore it because otherwise the customer will immediately be able to pin the
blame on you rather than having to guess whose fault it is.' :-( )

> You will find that 99.9% of them start looking for the start bit 1/2 way
> thru the stop bit.  If you want to build a repeater then you will need a
> fractional stop bit generator OR you can over spec the crystal by 1.5%
> (or the baud rate generator) OR you add RTS / CTS flow control like
> everybody else.

1 -- The fractional stop bit generator is a good idea, and is apparently
implemented in -- some -- commercial devices.  This was news to me, but it
does seem to be a very good solution.
2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution'
is inherently non-scalable -- I can't connect together a dozen of these
repeaters unless each one is progressively 1.5% faster, which isn't viable.
3 -- I'd agree that flow control is the 'proper' or 'textbook' solution,
just that the real world doesn't always play by those rules. :-)

---Joel Kolstad



Article: 63701
Subject: Re: XC9500 design does not fit into Coolrunner
From: Klaus Falser <kfalser@IHATESPAMdurst.it>
Date: Mon, 1 Dec 2003 09:17:53 +0100
Links: << >>  << T >>  << A >>
In article <3fc5e308$0$249$4d4ebb8e@read-nat.news.nl.uu.net>, 
Iwo_dot_Mergler@soton_dot_sc_dot_philips_dot_com says...
> Klaus Falser wrote:
> > Hello,
In article <3fc5e308$0$249$4d4ebb8e@read-nat.news.nl.uu.net>, you say...
> Klaus Falser wrote:
> > Hello,
> > 
> > I have a rather large design for a XC95288XL which consumes 276 macrocells 
> > of 288 possible.
> > Since Xilinx seems to prefer Coolrunner devices to the good old XC9500's 
> > I tried to stuff the design into a Coolrunner II chip to look how it 
> > would behave.
..snip .
> Have you constrained the design (pin assignments, etc)? What
> is the fitter complaining about?
> 
> There are some hard limits, like less OE lines than there are
> outputs to a block. If, for instance, you are trying to create
> a large GPIO device with more than 4 I/Os per block (8 are
> possible) it won't work.
> 
> Kind regards,
> 
> Iwo
> 
> 

No, for my first try I did not give any constrains, whether for pins nor for the 
timing.
The I/O interface is bus-like, so the I/O lines share all the same OE.
From my experience with the 9500's I have seen there are sometimes problems when 
creating a too large multiplexor, which comes from the available Product terms per 
macrocell. 
For instance, if you have a bus and you want to read back from more 
than 5 different registers, which implies a multiplexor before the output-pins, 
you have to distribute your pins carefully, since every macrocell with an output pin
needs to steel PT from their neighbours.
Coolrunner CPLD seems to have less PT inputs per macrocells, but give enough 
macrocells and without placing constraint I did expect some fit.    

Best regards
-- 
Klaus Falser
Durst Phototechnik AG
kfalser@IHATESPAMdurst.it

Article: 63702
Subject: Re: XC9500 design does not fit into Coolrunner
From: "Jim Granville" <no.spam@designtools.co.nz>
Date: Mon, 1 Dec 2003 22:15:52 +1300
Links: << >>  << T >>  << A >>

"Klaus Falser"  wrote
>
>
> No, for my first try I did not give any constrains, whether for pins nor
for the
> timing.
> The I/O interface is bus-like, so the I/O lines share all the same OE.
> From my experience with the 9500's I have seen there are sometimes
problems when
> creating a too large multiplexor, which comes from the available Product
terms per
> macrocell.
> For instance, if you have a bus and you want to read back from more
> than 5 different registers, which implies a multiplexor before the
output-pins,
> you have to distribute your pins carefully, since every macrocell with an
output pin
> needs to steel PT from their neighbours.
> Coolrunner CPLD seems to have less PT inputs per macrocells, but give
enough
> macrocells and without placing constraint I did expect some fit.

Comparing the two RPT files should give some guidelines ?.
It is common for fitters to give better info, for a design that fits, so
'approaching the problem from (just) below' can be much more productive.
When you have a partial design fitting, check the correct globals have
been mapped OK. Missing a global resource can balloon usage.
Sometimes the device package can have an influence - if there is more than
one
choice, get a report file for each package.
-jg



Article: 63703
Subject: Re: Digilent Inc.
From: "GN" <Guenther@FJERNES.softhome.net>
Date: Mon, 1 Dec 2003 13:49:16 +0100
Links: << >>  << T >>  << A >>
Thanks's for your answers!


I've had a couple of bad experiences with different netbased companys
myself - But it sounds like I've nothing to worry about in this case. - Only
fair to let the guy's celebrate Thanksgiving without too much stress! :-)

GN



Article: 63704
Subject: Functional Simulation QuartusII
From: andres.vazquez@gmx.de (Vazquez)
Date: 1 Dec 2003 05:49:41 -0800
Links: << >>  << T >>  << A >>
Dear Sir or Madame,

I have a question concerning the inputs of a VHDL module when
simulating with the Altera QuartusII Waveform Editor.
The input CONTROL shall be a registered signal from a different
module. 
When doing a functional simulation I edit the waveform in that form you
can see so that CONTROL changes its value right with rising edge of
CLK. So I want to reproduce the registered input signal CONTROL.
But when starting the functional simulation I get the error message:
"Found clock-sensitive change during active clock edge ...", of course.
My question: How can I reproduce the clock synchronous input CONTROL without
violating setup-time?  (using the Waveform Editor !!!)

Thank you for your help.

Andre V.
G&D System Development


 --------             --------             --------
|        |           |        |           |        |
|        |           |        |           |        |        CLK
|        |___________|        |___________|        |___________


                      -------------------------------------------
                     |
                     |                                      CONTROL
_____________________|

Article: 63705
Subject: Re: Dual port RAM for Xilinx
From: Tobias =?iso-8859-1?Q?M=F6glich?= <Tobias.Moeglich@gmx.net>
Date: Mon, 01 Dec 2003 15:32:55 +0100
Links: << >>  << T >>  << A >>
Hello!

Thank you for your advice. Yes, I tried it the CoreGenerator.
Hm. One more question:
Do I have to copy the source code generated by the CoreGenerator in a
vhd-file    or
is it enough to add the generated core (-> including the xco-file by saying:
"New Source... IP(CoreGen & Architecture Wizard) in Xilinx ISE Foundation)?

Tobias

>


Article: 63706
Subject: Re: programmable fir and simulation
From: PawelT <ptomasze@poczta.onet._no_spam_.pl>
Date: Mon, 01 Dec 2003 16:22:47 +0100
Links: << >>  << T >>  << A >>
For discussion I include the code of fir example.


-- This is a generic FIR filter generator 
-- It uses W1 signed bit data/coefficients bits
LIBRARY lpm;                     -- Using predefined packages
USE lpm.lpm_components.ALL;

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;
USE ieee.std_logic_unsigned.ALL;

ENTITY fir_prog IS                      ------> Interface
  GENERIC (W1 : integer := 9; -- Input bit width
           W2 : integer := 18;-- Multiplier bit width 2*W1
           W3 : integer := 19;-- Adder width = W2+log2(L)-1
           W4 : integer := 11;-- Output bit width
           L  : integer := 4; -- Filter length 
-- for Mpipe = 1 output Y_OUT is OK (PT)
        Mpipe : integer := 3-- Pipeline steps of multiplier
           );
  PORT ( clk    : IN STD_LOGIC;
         Load_x : IN  STD_LOGIC;
         x_in   : IN  STD_LOGIC_VECTOR(W1-1 DOWNTO 0);
--         c_in   : IN  STD_LOGIC_VECTOR(W1-1 DOWNTO 0); -- (PT)
         y_out  : OUT STD_LOGIC_VECTOR(W4-1 DOWNTO 0));
END fir_prog;

ARCHITECTURE arch_fir OF fir_prog IS

  SUBTYPE N1BIT IS STD_LOGIC_VECTOR(W1-1 DOWNTO 0);
  SUBTYPE N2BIT IS STD_LOGIC_VECTOR(W2-1 DOWNTO 0);
  SUBTYPE N3BIT IS STD_LOGIC_VECTOR(W3-1 DOWNTO 0);
  TYPE ARRAY_N1BIT IS ARRAY (0 TO L-1) OF N1BIT;
  TYPE ARRAY_N2BIT IS ARRAY (0 TO L-1) OF N2BIT;
  TYPE ARRAY_N3BIT IS ARRAY (0 TO L-1) OF N3BIT;

  SIGNAL  x  :  N1BIT;
  SIGNAL  y  :  N3BIT;
  SIGNAL  c  :  ARRAY_N1BIT; -- Coefficient array 
  SIGNAL  p  :  ARRAY_N2BIT; -- Product array 
  SIGNAL  a  :  ARRAY_N3BIT; -- Adder array 
                                                        
BEGIN

  Load: PROCESS            ------> Load data or coefficient
  BEGIN
    WAIT UNTIL clk = '1';  
    IF (Load_x = '0') THEN
 -- load coefs from X_IN input (PT)
      c(L-1) <= x_in;      -- Store coefficient in register
      FOR I IN L-2 DOWNTO 0 LOOP  -- Coefficients shift one
        c(I) <= c(I+1);
      END LOOP;
    ELSE
      x <= x_in;           -- Get one data sample at a time

    END IF;
  END PROCESS Load;


  SOP: PROCESS (clk, load_x)        ------> Compute sum-of-products
  BEGIN
    IF clk'event and (clk = '1') THEN
    FOR I IN 0 TO L-2  LOOP      -- Compute the transposed
      a(I) <= (p(I)(W2-1) & p(I)) + a(I+1); -- filter adds
    END LOOP;
    a(L-1) <= p(L-1)(W2-1) & p(L-1);     -- First TAP has 
    END IF;                              -- only a register
    y <= a(0);
  END PROCESS SOP;

  -- Instantiate L pipelined multiplier 
  MulGen: FOR I IN 0 TO L-1 GENERATE 
  Muls: lpm_mult               -- Multiply p(i) = c(i) * x;
        GENERIC MAP ( LPM_WIDTHA => W1, LPM_WIDTHB => W1, 
                      LPM_PIPELINE => Mpipe,
                      LPM_REPRESENTATION => "SIGNED", 
                      LPM_WIDTHP => W2, 
                      LPM_WIDTHS => W2)  
        PORT MAP ( clock => clk, dataa => x, 
-- this line to turn-off pipelining (PT)
--        PORT MAP ( dataa => x, 
                   datab => c(I), result => p(I));
        END GENERATE;
  y_out <= y(W3-1 DOWNTO W3-W4);  
END arch_fir;



Article: 63707
Subject: debugging microblaze with xmd
From: "Frank" <someone@work.com>
Date: Mon, 1 Dec 2003 16:32:24 +0100
Links: << >>  << T >>  << A >>
Hi,

since I upgraded the EDK 3.2 to 6.1 (with service pack 1) I'm having
problems with debugging. To debug I do the following:

- add next two lines to mss file

PARAMETER DEFAULT_INIT = XMDSTUB
PARAMETER DEBUG_PERIPHERAL = dbg_uart

- set in makefile the optimization off (-O0)
- set in makefile mode to xmdstub (instead of executable)
- set in makefile compiler option -g (generating debug information)

after downloading the bitfile, the program starts to run (very very slowly,
but it runs! while I'm expecting that it should not run!). After starting
xmd, I try to connect:

mbconnect stub -comm serial -port com1 -baud 115200

and the next error was generated:

XMD% mbconnect stub -comm serial -port com1 -baud 115200
ERROR: Unable to sync with stub on the board using the UART
Closing serial port
Unable to establish connection to xmdstub
Unable to connect to MicroBlaze Target

Does anyone have an idea? The described procedure was working with EDK 3.2
and ISE 5.2...

Thanks,
Frank



Article: 63708
Subject: Re: 5V I/O with 1.8V Core
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 01 Dec 2003 07:51:44 -0800
Links: << >>  << T >>  << A >>
Jim,

Been there, done that.

Still doing that, and more.  It is very favorable to do special things 
with the cmos configuration cells (we call them CCC's) rather than SRAM 
memory for configuration.  Our CCC's are 20X or more robust than SRAM to 
SEUs, and all for good reasons.

Austin

Jim Granville wrote:
> "Nicholas C. Weaver"
> 
>>In article <vsclib1e0fi69b@corp.supernews.com>,
>>Hal Murray <hmurray@suespammers.org> wrote:
> 
> <snip>
> 
>>>Any reason somebody couldn't implement 2 types of logic on one
>>>chip.  Slow but low leakage for the config memory and fast but
>>>more leakage for the active logic?  I assume it doesn't work
>>>easily with modern processing or people would be doing it already.
>>>(Maybe they already are?)
> 
> 
> I believe foundries offer this already.
> 
> Maybe Austin L could confirm if Xilinx are using this ?
> 
> In noise immunity topics, we've seen the point made that
> the CONFIG cells have significantly different, and better, noise
> immunity ( so config corruption is less likely than logic corruption).
> 
> 
>>>I'm fishing for more theory or long term ideas.
>>
>>The problem is the FPGA places the SRAM cells (low leakage) right next
>>to active (must be high speed) switching transistors.
>>
>>Any processing rule which had two Vts for the different transistors
>>would probably require a fairly substantial spacing between the two
>>types.
> 
> 
> Why ?   Sure, more steps will be needed - but spacing ?
> 
>  There would be a case for really pushing the Speed rules for LOGIC,
> but going for MAX Yield (ie slightly relaxed geometries) on the CONFIG
> cells (lots more of them, _and_ they are not 'picosecond paranoid' ).
>  There would be some trade off on CONFIG time, and leakage Current in
> a variable threshold design.
> 
>  I think this could be checked experimentally - drop Vcc, and LoadCLK,
> and plot Config verify fail Vcc/Freq curve.
>  Then create a LOGIC fabric shifter, and do the same for it.
> 
>  -jg
> 
> 


Article: 63709
Subject: Re: jitter in Virtex2 DCM
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 01 Dec 2003 08:17:34 -0800
Links: << >>  << T >>  << A >>
Tullio,

The spec is for cycle to cycle jitter, not for peak to peak.

If your signal has 1 ns of cycle to cycle jitter, it would all but 
unusable for just about anything.  Hopefully, that is not the case, and 
the signal has 1 ns of peak to peak jitter.

If you were to measure the cycle to cycle jitter of this signal, it will 
have to be less than the 300 ps +/- DCM input specification (which is 
most likely).  There is also the "jitter filter" attribute which should 
be set to 0xFFFFh for real jittery input signals, as this will allow the 
DCM to track the incming signal the fastest (to prevent one cycle jitter 
to the next cycle of jitter from affecting the phase detector).

The status signals will properly indicate the operation:  if locked does 
not go high at all, or if it goes high, and then goes low a few thousand 
clock cycles later, it is an indication of too much jitter.

I have tested the DCM with sine wave jitter (at one frequency) from 100 
KHz to 20 MHz with much more than 1 ns of p-p jitter, and have seen no 
issues at all, because the cycle to cycle jitter is much less than the 
input specification.  The DCM is completely insensitive to input jitter 
frequency (within the range that was tested).

For example, if in 1 microsecond (1 megahertz), a 100 MHz clock signal 
had 1ns of jitter, peak to peak, then there are 100 clock cycles per 
jitter modulation period (1 us), and the cycle to cycle clock jitter is 
1/100 of the peak to peak (or 10 ps).

Austin

Tullio Grassi wrote:

> The VirtexII data sheet requires an input jitter for 
> the DCM smaller than + or - 300 ps (in Low Frequency Mode).
> Obviously this ensures the proper behavior across all
> permitted frequencies and modes.
> 
> In my case I have an input clock with 1ns of pk-pk jitter, but
> it is a 40 MHz clock, that I only need to shift by 90 (clk90),
> and to multiply by 2 (clk2x) other than having a locked version
> (clk0) of the original clock.
> How can I verify if it still works reliabily ?
> Or is the going to DCM loose lock ?
> Or will the phase relationships btw the output clocks not met ?


Article: 63710
Subject: Re: modular design flow in Xilinx ISE 6.1.
From: Steve Lass <lass@xilinx.com>
Date: Mon, 01 Dec 2003 10:35:37 -0700
Links: << >>  << T >>  << A >>
Ian wrote:

>Hello All,
>
>I am having problems running the modular design flow in Xilinx ISE
>6.1.
>
>Everything seems OK until I configure (Spartan2 via Boundary Scan
>/Parallel using Impact) I get a programming failed message - the done
>pin failed to go high. I have tried a few different options in Bitgen
>with no success.
>
>Also, the Xilinx ISE 'development systems reference guide' and the
>Xilinx answers database seem to conflict on the correct use of ngo/ngd
>files in the modular flow. i.e.
>
>Development Systems Reference Guide, Modular Design Section, Top of
>Page 93 (PDF version)
>
>&#8220;Note: ngdbuild produces two files, design_name.ngd and
>design_name.ngo. The design_name.ngo file is used during subsequent
>Modular Design steps, while design_name.ngd is not.&#8221;
>
>BUT......... 
>
>Xilinx Answer Record # 17058 6.1i Modular Design
>(http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=17058)
>
>&#8220;An NGO file is produced only if an EDIF netlist is used as the
>input to NGDBuild. The NGC netlist created by XST is already in Xilinx
>Database Format, and does not need to be converted to an NGO
>file.&#8221;
>
>
>So could the fact a am using the NGC netlist produced by ngdbuild
>instead of the ngo file prescribed by the Development Systems Ref
>Guide be causing this problem??
>
No.  NGC and NGO have essentially the same info, so the NGC can be used 
in the modular design flow.
We'll fix the reference guide to say that NGC and NGO can be used.

I suspect your problem is related to downloading into the FPGA.

Steve

>
>Please Help (Its nearly Christmas!)
>
>Ian Colwill, University Of Sussex, UK
>  
>


Article: 63711
Subject: CoreGenerator
From: Tobias =?iso-8859-1?Q?M=F6glich?= <Tobias.Moeglich@gmx.net>
Date: Mon, 01 Dec 2003 19:10:26 +0100
Links: << >>  << T >>  << A >>
Hello!

If I use the CoreGenerator (for example in order to configure a Dual
Port Ram)
do I have to copy the source code generated by the CoreGenerator in a
vhd-file    or
is it enough to add the generated core (-> including the xco-file by
saying:
"New Source... IP(CoreGen & Architecture Wizard) in Xilinx ISE
Foundation)?
Isn't it possible just to use the xco-file, generated by the
CoreGenerator?
Or do I have to add a vhd- file in addition?

Tobias.


Article: 63712
Subject: Re: Quote from Xilinx re: XPLA3
From: davidg@altera.com (Dave Greenfield)
Date: 1 Dec 2003 10:41:24 -0800
Links: << >>  << T >>  << A >>
Suppliers don't become market leaders by discontinuing 90% of their
product lines.
There is a clear note in the document referenced that highlights
"selected products"; Altera is not obsoleting any product lines. We do
selectively prune ordering codes (i.e. speed grades, packages, or
extended temp products) when demand is extremely low; during this
process we issue product discontinuation notices (PCNs). Altera also
provides a site to search for all obsolete devices at:
http://www.altera.com/products/devices/common/dev-obsolete_device_search.html.
The actual number of obsoleted products is ~ 2% not 90%.

I think this site would be better served without incorrect competitive
FUD.

Dave Greenfield
Altera Corporation

 > Incidentally, why isn't it interesting when our main CPLD
competitor
> > announces discontinuing about 90% of their product line?
> > See page 29 of this:
> > http://www.altera.com/literature/nv/03nvq3.pdf
> > 
> > Jesse Jenkins, Xilinx CPLDs
> > ---------------------------------------------------------------
> > 
> > Good day!
> > 
>

Article: 63713
Subject: Re: XC2VP70 FPGA board suggestions
From: "Ron Huizen" <rhuizen@bittware.com>
Date: Mon, 1 Dec 2003 13:57:57 -0500
Links: << >>  << T >>  << A >>
Amirix has a V2Pro eval board with gig ether support, but it doesn't go up
to the 70 (7, 20, or 30 I think).  I know that they have people using it to
play with Gig ether, and it has support for the PowerPC core, and a separate
Ether as well.

www.amirix.com

-----
Ron Huizen
BittWare

"Anup Kumar Raghavan" <anup@csee.uq.edu.au> wrote in message
news:3FC9F71E.A44B8F55@csee.uq.edu.au...
> Can I get suggestions for FPGA development boards that house the
> XC2VP70/125 Virtex 2 Pro FPGA? I have read the DINI specs and they seem
> to be the only one I can find that supports this FPGA. I want a board I
> can use to test network protocols like gigabit ethernet, and hence want
> to hook up either fibre or coax-ethernet cable to the board.
>
> Thanks
> Anup
>
>



Article: 63714
Subject: Re: Quote from Xilinx re: XPLA3
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 01 Dec 2003 11:33:44 -0800
Links: << >>  << T >>  << A >>
I am innocent, but let me apologize on behalf of Xilinx.
We should all make sure that our information is correct, and especially
so when we mention the competitor. Let's stay away from mudslinging!

Peter Alfke
===================
Dave Greenfield wrote:
 
> I think this site would be better served without incorrect competitive
> FUD.
> 
> Dave Greenfield
> Altera Corporation
> 
>  

Article: 63715
Subject: Re: programmable fir and simulation
From: Marc Randolph <mrand@my-deja.com>
Date: Mon, 01 Dec 2003 19:44:32 GMT
Links: << >>  << T >>  << A >>
PawelT wrote:
> Hello,
> I tried to simulate example of  generic FIR filter on page 82 from
> book Uwe Meyer "Digital Signal Processing with FPGAs".
> In book in simulation the first valid output is after 475 ns and zeros
> before that.
> I tried this example with MAxplus2 Baseline v10.2 and with new
> ACF-file. Does anybody compile this?
> After compilation and simulation on outputs Y_OUT there is appeared
> unexpected new value dec*2046* after 125ns till 325ns,
>  and after 475 ns there is "correct" value from book.
> And my question is: why this *unexpected* value (2046) appeared ?

I'm guessing that since your flip-flops are not initialized upon reset, 
what you are seeing is the time it takes for your filter taps (and 
coefficients?) to settle down with valid values.  For many designs, this 
type of behavior is not a problem. - but you'll have to be the judge of 
that for your situation.

> After that I tried change number of pipeline stages in lpm_mult, and
> this *unexpected* value disappeared when constant Mpipe=1. For
> Mpipe=2,3,4 there is bad value....
[...
> May I attache this source vhdl code on usenet?  

Of course.  It often helps in diagnosing problems.

 > I think about copyrights..

Once posted to usenet, you have little control of the code.  You can 
place a copyright on it, but enforcement can be near impossible.

    Marc


Article: 63716
Subject: Re: about digilent board
From: Jan Panteltje <panteltje@NyoaShpoaom.com>
Date: Mon, 01 Dec 2003 21:40:29 GMT
Links: << >>  << T >>  << A >>
On a sunny day (30 Nov 2003 18:54:40 -0800) it happened
huangphoenix@hotmail.com (deadflower) wrote in
<3cfa6819.0311301854.56386fdd@posting.google.com>:

>Hi, group,
>
>I plan to buy digilent combo board DIO2 combo. Does anybody know if a
>download cable will be included in the package?
Yes parallel port
>also, do they provide
>the software like foundation or webpack?
No

Article: 63717
Subject: Exact Timing Constraints vs. Over-Constraining
From: pospamme@yahoo.com (PO Laprise)
Date: 1 Dec 2003 15:24:11 -0800
Links: << >>  << T >>  << A >>
I have seen much conflicting advice w.r.t timing constraints on this
newsgroup, and I was hoping that the proponents of both camps might
make explicit their reasons so that others (meaning I ;) can benefit
from their experience.

I have seen many posts recommending over-constraining the timing
requirements in an effort to ensure correct functioning in the
presence of uncertainty and unknowns, but I have also seen many posts
stating that the tools are now good enough that this is no longer
necessary, and that giving the true timing constraints is sufficient,
and will allow more latitude for the tools to put their effort where
it is truly needed.  I doubt if it's so cut-and-dry, but which is the
"right" one?  Or have I completely misunderstood the problem?

Thanks for your time,
Pierre-Olivier

--To reply directly, remove the obvious in
pl_N0SP4M_apri@cim.mcgill.1NV4LID.ca--

Article: 63718
Subject: Re: debugging microblaze with xmd
From: Raj Nagarajan <raj.nagarajan@xilinx.com>
Date: Mon, 01 Dec 2003 19:12:04 -0800
Links: << >>  << T >>  << A >>
Hi Frank,

Frank wrote:
> 
> Hi,
> 
> since I upgraded the EDK 3.2 to 6.1 (with service pack 1) I'm having
> problems with debugging. To debug I do the following:
> 
> - add next two lines to mss file
> 
> PARAMETER DEFAULT_INIT = XMDSTUB
> PARAMETER DEBUG_PERIPHERAL = dbg_uart
> 
> - set in makefile the optimization off (-O0)
> - set in makefile mode to xmdstub (instead of executable)
> - set in makefile compiler option -g (generating debug information)
> 
> after downloading the bitfile, the program starts to run (very very slowly,
> but it runs! while I'm expecting that it should not run!). After starting

If your download.bit contains xmdstub (typically the case for XMDSTUB
mode), the xmdstub starts to execute after the bitfile is downloaded..
After the following changes in mss file, did you update your bitstream ?

> xmd, I try to connect:
> 
> mbconnect stub -comm serial -port com1 -baud 115200
> 
> and the next error was generated:
> 
> XMD% mbconnect stub -comm serial -port com1 -baud 115200
> ERROR: Unable to sync with stub on the board using the UART
> Closing serial port
> Unable to establish connection to xmdstub
> Unable to connect to MicroBlaze Target

Looks like your download.bit file does not contain xmdstub. Updating the
bitstream should have xmdstub in your design. There is no change in
EDK6.1 and the design should work.

-Raj

> 
> Does anyone have an idea? The described procedure was working with EDK 3.2
> and ISE 5.2...
> 
> Thanks,
> Frank

Article: 63719
Subject: Re: Exact Timing Constraints vs. Over-Constraining
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Tue, 02 Dec 2003 04:23:15 GMT
Links: << >>  << T >>  << A >>
PO Laprise wrote:
 
> I have seen much conflicting advice w.r.t timing constraints on this
> newsgroup, and I was hoping that the proponents of both camps might
> make explicit their reasons so that others (meaning I ;) can benefit
> from their experience.
> 
> I have seen many posts recommending over-constraining the timing
> requirements in an effort to ensure correct functioning in the
> presence of uncertainty and unknowns, but I have also seen many posts
> stating that the tools are now good enough that this is no longer
> necessary, and that giving the true timing constraints is sufficient,
> and will allow more latitude for the tools to put their effort where
> it is truly needed.  I doubt if it's so cut-and-dry, but which is the
> "right" one?  Or have I completely misunderstood the problem?

I try to enter the constraints that exactly match the timing that the
design will need to function, including board delay, loading delay,
clock jitter and clock skew.

Xilinx tools will now allow for a clock jitter number, and will add 
jitter when going through DCMs.  So the tools are (maybe) somewhat
better.  But the rest still needs at least minimal work, and maybe
a lot of work if the timing is tight.


-- 
Phil Hays

Article: 63720
Subject: Re: Exact Timing Constraints vs. Over-Constraining
From: Larry Doolittle <ldoolitt@recycle.lbl.gov>
Date: Tue, 2 Dec 2003 05:56:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3FCC13DB.8F643B8F@attbi.com>, Phil Hays wrote:
> I try to enter the constraints that exactly match the timing that the
> design will need to function, including board delay, loading delay,
> clock jitter and clock skew.

Don't forget metastability slack.  In theory it does not apply to the
purely synchronous nets; in practice I don't want to go through the
work of separating them out, and it's a good excuse to add one more
conservative assumption.

       - Larry

Article: 63721
Subject: Re: Exact Timing Constraints vs. Over-Constraining
From: "Robert Sefton" <rsefton@abc.net>
Date: Mon, 1 Dec 2003 22:30:13 -0800
Links: << >>  << T >>  << A >>
"Larry Doolittle" <ldoolitt@recycle.lbl.gov> wrote in message
news:slrnbsoacg.9j2.ldoolitt@recycle.lbl.gov...
> In article <3FCC13DB.8F643B8F@attbi.com>, Phil Hays wrote:
> > I try to enter the constraints that exactly match the timing that
the
> > design will need to function, including board delay, loading delay,
> > clock jitter and clock skew.
>
> Don't forget metastability slack.  In theory it does not apply to the
> purely synchronous nets; in practice I don't want to go through the
> work of separating them out, and it's a good excuse to add one more
> conservative assumption.
>
>        - Larry

Larry -

What is metastability slack and how do you apply it? Do you mean you
over-constrain your clock periods slightly to expand setup margins?

Thanks,

Robert



Article: 63722
Subject: Re: Exact Timing Constraints vs. Over-Constraining
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 02 Dec 2003 06:35:57 GMT
Links: << >>  << T >>  << A >>
Phil Hays wrote:

> PO Laprise wrote:

>>I have seen much conflicting advice w.r.t timing constraints on this
>>newsgroup, and I was hoping that the proponents of both camps might
>>make explicit their reasons so that others (meaning I ;) can benefit
>>from their experience.

>>I have seen many posts recommending over-constraining the timing
>>requirements in an effort to ensure correct functioning in the
>>presence of uncertainty and unknowns, but I have also seen many posts
>>stating that the tools are now good enough that this is no longer
>>necessary, and that giving the true timing constraints is sufficient,
>>and will allow more latitude for the tools to put their effort where
>>it is truly needed.  I doubt if it's so cut-and-dry, but which is the
>>"right" one?  Or have I completely misunderstood the problem?

> I try to enter the constraints that exactly match the timing that the
> design will need to function, including board delay, loading delay,
> clock jitter and clock skew.

> Xilinx tools will now allow for a clock jitter number, and will add 
> jitter when going through DCMs.  So the tools are (maybe) somewhat
> better.  But the rest still needs at least minimal work, and maybe
> a lot of work if the timing is tight.

How about temperature or Vcc variation?

Or process variations in the chips?  A newer chip batch, done on a 
different process, may be faster than an older one.

If the timing constraints already include such margins, you don't need 
to add additional margins.

-- glen


Article: 63723
Subject: Re: Slightly unmatched UART frequencies
From: "Simon Peacock" <nowhere@to.be.found>
Date: Tue, 2 Dec 2003 20:30:41 +1300
Links: << >>  << T >>  << A >>

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:bqeqiq$654$1@news.oregonstate.edu...
> Simon Peacock <nowhere@to.be.found> wrote:
> > you guys seem to miss the point.. Async RS232 ALWAYS has mismatched
clocks
> > ... ALL async UARTs MUST be capable of handling this.. that's why
there's
> > flow control.
>
> There are a lot of systems in the world that don't use flow control and
> simply rely on a 'mutual agreement' between the interconnected devices
that
> large streams of unbroken serial data isn't produced.  This is especially
> the case of, e.g., sensors that produce real-time RS-232 output data with
no
> buffering of their own -- in such a case flow control would just throw
data
> away, so it's often not implemented to begin with.  (I have a motto
> something to the effect of... if detecting an error does no more good than
> just ignoring it, you might as well ignore it... Although unfortunately
this
> idea is often perverted into, 'if detecting an error takes effort, even if
> ignoring it causes the machine to rip off someone's arm, you might as well
> ignore it because otherwise the customer will immediately be able to pin
the
> blame on you rather than having to guess whose fault it is.' :-( )
>
> > You will find that 99.9% of them start looking for the start bit 1/2 way
> > thru the stop bit.  If you want to build a repeater then you will need a
> > fractional stop bit generator OR you can over spec the crystal by 1.5%
> > (or the baud rate generator) OR you add RTS / CTS flow control like
> > everybody else.
>
> 1 -- The fractional stop bit generator is a good idea, and is apparently
> implemented in -- some -- commercial devices.  This was news to me, but it
> does seem to be a very good solution.
> 2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution'
> is inherently non-scalable -- I can't connect together a dozen of these
> repeaters unless each one is progressively 1.5% faster, which isn't
viable.
> 3 -- I'd agree that flow control is the 'proper' or 'textbook' solution,
> just that the real world doesn't always play by those rules. :-)
>

Actually you can :-)

Data is only sent at the speed it arrives at.. so although you are 1.5%
fast.. you actually end up adding extra stop bits into the stream to
compensate .. is simple and oh so clever.  This is exactly what modems did
for years to cope with the V.14 shaved bits when they couldn't do them.


Simon




Article: 63724
Subject: Re: Slightly unmatched UART frequencies
From: "Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com>
Date: Mon, 1 Dec 2003 23:41:23 -0800
Links: << >>  << T >>  << A >>
HI Simon,

Simon Peacock <nowhere@to.be.found> wrote:
> Data is only sent at the speed it arrives at.. so although you are 1.5%
> fast.. you actually end up adding extra stop bits into the stream to
> compensate .. is simple and oh so clever.

Well, fair enough, if you KNOW that your data source is truly supposed to be
'nominally,' say, 9600bps, then you can be clever and get away with an
internal nominal bit rate of 9600*1.015=9744bps.  However, if you tell me
you have such a device that you'd like to connect to one of my devices,
you'd better be able to convince me there really is no way your device could
start spewing data continuously at 9744 bps when my 9600 bps receiver isn't
going to be able to hack it!

>This is exactly what modems did
> for years to cope with the V.14 shaved bits when they couldn't do them.

Interesting; I didn't know that either!

---Joel





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