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 144500

Article: 144500
Subject: Re: Cheapest way to get a chipscope compatible cable?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 11 Dec 2009 16:29:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
Alex Freed <alex_news@mirrow.com> wrote:

> No big surprise here: if they sell a cable worth about $10 in parts for 
> $250 they think it's good busyness. Doesn't take into account the loss 
> from bad PR this generates.
> In any case there are now compatible Xilinx cable clones that are always 
> available on e-bay for around $70 or so. In addition my understanding is 
> that Digilent has a compatibility library now that allows their very 
> inexpensive USB cable to be used with Xilinx tools. Didn't try it myself 
> as I have both a genuine Xilinx cable and a clone from China that works 
> just as well just in case.

This doesn't help if for some reason (e.g. high speed UBS transfer) you
already have  some device that handles USB access and could handle JTAG. To
plug in the DLC(clone) you need another connector ...
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

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

Article: 144501
Subject: Re: Please Help me
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 11 Dec 2009 10:07:00 -0800
Links: << >>  << T >>  << A >>
Ben Jones wrote:

> I still maintain that asynchronous reset "isn't the best solution",
> but everything Andy says is certainly true. Sometimes, you have an
> external requirement for it, and in most cases the FPGA silicon and
> tools will cope with it. But note that in more complex designs and on
> some devices, certain blocks (e.g. DSPs, BRAMs) contain registers that
> are only resetable synchronously.

True, but it simplifies simulation having a reset
for the input and output registers, even if (especially if ?)
the rams and some shifters don't have one.

The reset can always be tied inactive if it is not
needed in the system.

But it does
help me on the front end, and is always there if I need it.
There is also value for me in using the same design rules
every time.


   -- Mike Treseler

Article: 144502
Subject: Re: Please Help me
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 11 Dec 2009 10:13:43 -0800
Links: << >>  << T >>  << A >>
Joshi & Joshi wrote:

> thanks a lot for all your inputs ...
> the asynchronous reset i synthesized already 
> but the problem is in simulaton ...
> please correct my Code ..

Here's my take on Andy's clever idea.
Untested, but compiles and should be close.

           -- Mike Treseler

__________________________________________________________________
package period_pkg is -- idea from Andy
-- To account for uneven half cycles:

   constant input_f  : integer := 40000000;
   constant output_f : integer := 1200;
   constant period   : integer
      := (input_f + output_f / 2) / output_f;
-- round up
   constant high     : integer := (period + 1) / 2;
   constant low      : integer := period - high;

end package period_pkg;
------------------------------------------------------------------
use work.period_pkg.all;
library ieee;
use ieee.std_logic_1164.all;

entity period is
   port (
      in_clk, rst : in  std_ulogic;
      out_clk     : out std_ulogic);
end entity period;

architecture period of period is

-- Fri Dec 11 09:47:27 2009 mtreseler

begin  -- architecture period
   p : process(in_clk, rst) is
      variable clk_cnt_v : integer range 0 to high - 1;
      variable out_clk_v : std_ulogic;
   begin

      if rst = '1' then
------------------------------------------------------------------
      -- init regs
         out_clk_v := '0';
         clk_cnt_v := 0;

      elsif rising_edge(in_clk) then
------------------------------------------------------------------
      -- update regs
         roll:if clk_cnt_v = 0 then
            load:if out_clk_v = '1' then
               clk_cnt_v := low - 1;    -- load low half-period
            else
               clk_cnt_v := high - 1;   -- load high half_period
            end if load;
            toggle:out_clk_v := not out_clk_v;
         else
            decr:clk_cnt_v := clk_cnt_v - 1;
         end if roll;
      end if;
------------------------------------------------------------------
      -- update ports:
         ports:out_clk <= out_clk_v;

   end process p;
end architecture period;

Article: 144503
Subject: Re: very wide counter (42-bit)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 11 Dec 2009 18:16:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
kendor <jonas.reber@bfh.ch> wrote:
 
> for a measuring utility (running @ 100MHZ) I need a counter of 42-bit width
> whose value is used by several sub blocks of my design. As a first, somehow
> dirty solution I have implemented this like follows. Since this approach
> needs quite a huge amount of FFs and leads to long delaytimes (bit 0 to 42)
> I am looking for an alternative. I was thinking about using Block RAM
> (Spartan3) to reduce routing effort and delaytimes. (see also
> http://courses.ece.illinois.edu/ece412/References/datasheets/xapp463.pdf)

Someone else suggested a LFSR which seems like it might work.

It depends somewhat on what you do with the count later. 

I was just thinking that you could cascade counters with a latch
between the carry out of one and the carry in of the next.
That causes the carry to occur one cycle late, which results in
a strange count sequence, but fairly easy to correct externally.

Though propagating the value to other subblocks seems likely to
take about as long as getting the carry through 42 bits.  That might
require more pipeline registers throughout the design.

Otherwise, 50MHz or 25MHz should be easy.  A one or two bit
counter at 100MHz with the appropriate logic to generate 
and latch a carry signal should also work.

-- glen

Article: 144504
Subject: Re: Spartan 3E starter Kit
From: Bob Smith <bsmith@pohl.linuxtoys.org>
Date: Fri, 11 Dec 2009 11:43:07 -0800
Links: << >>  << T >>  << A >>
thranduil <vlasinac@gmail.com> wrote:
> i want to buy Spartan 3E starter kit and I am wonder if someone managed to
> make it works like a standard USB device.


Take a look at the Demand Peripherals BaseBoard4.  It has
a USB interface to the host and appears as a USB serial
port.  The USB serial port is used for downloading the
FPGA code and then the port is available as a communication
channel between the host and the FPGA.  There was an article
in the February issue of Nuts and Volts magazine about this
board.  Google for "FPGAs at the Command Line" to find it.
(BTW: I wrote the article.)

HTH
Bob Smith


Article: 144505
Subject: Re: very wide counter (42-bit)
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 11 Dec 2009 14:50:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 4, 10:15=A0am, "kendor" <jonas.re...@bfh.ch> wrote:
> hello there
>
> for a measuring utility (running @ 100MHZ) I need a counter of 42-bit wid=
th
> whose value is used by several sub blocks of my design.
> kendor

The conventional design of a synchronous counter would concatenate 42
flip-flops, using the built-in dedicated carry chain. Its carry
propagation delay is extremely short, but the total delay might be too
long for 100 MHz operation.
You can maintain the synchronous nature of the design, but decode an
additional count enable from the first 2 flip-flops and route that
signal to all the remaining 40 flip-flops in parallel. That gives the
long carry chain not 10 ns, but 40 ns to stabilize, which is more than
sufficient. And you still have a totally synchronous counter where all
bits change on the same clock.

If you think that 42 flip-flops are too many, you can use BlockRAMs.
Each dual-ported 4K BlockRAM can implement an 8-bit counter per port,
easily concatenated to 16 bits per BRAM. (The two ports have the same
look-up functionality, just different addressing inputs, fed back from
the own outputs) Two BlockRAMs can thus form a 32-bit fully
synchronous counter, and a third BRAM can extend that to 48 bits.
There is some trickery in gating the carry signals, but it never
involves more than one level of combinatorial logic, no problem at 100
MHz. And you can also of course always use a pre-scaler, as described
above.

Now, if you use more modern FPGAs, like Spartan3DSP, or Spartan6, or
Virtex4,5,or 6, then you can use the ready-made 48-bit accumulator (an
accumulator that adds 1 per clock tick is a counter) without any
design effort at all, and a speed of up to 500 MHz.

Old FPGA families may sometimes look cheaper, but that may be
deceptive.
Would you today buy a car with drum brakes, no fuel injection, no CD
player, no airbags and no air conditioning ?

Peter Alfke


Article: 144506
Subject: Re: Xilinx's version of Quartus' Signaltap?
From: laserbeak43 <laserbeak43@gmail.com>
Date: Fri, 11 Dec 2009 17:04:43 -0800 (PST)
Links: << >>  << T >>  << A >>
interesting. I'll try a chipscope demo...

Thanks

On Dec 9, 6:48=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> Andy Peters <goo...@latke.net> writes:
> > On Dec 7, 6:26=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> >> laserbeak43 <laserbea...@gmail.com> writes:
> >> > Hello,
> >> > =A0 =A0 I've just been shownSignaltap, A feature inQuartusWebpack
> >> > Edition. Does the Webpack Edition of ISE have this feature? WOW this
> >> > alone can convince me to use Altera products.
>
> >> Chipscope is theXilinxequivalent - it's not in webpack (personally, I
> >> think that's a mistake onXilinx'spart)
>
> >> But comparing it toSignaltapmay (IMHO) leave you underwhelmed... it's
> >> very disjointed and unintegrated in comparison. =A0I'm still using FPG=
A
> >> editor to change which signals to monitor, then having to update the
> >> viewer by hand! V. tedious.
>
> > Really? Whatversionof ChipScope are you using?
>
> 10.1.3
>
>
>
> > Use the ChipScope Core Inserter.
>
> Indeed, I could (and have in the past), but
>
> a) I'm using the EDK variety of core inserter, as it manages the JTAG
> linkages with the microblaze debug module for me
>
> b) I then have to run MAP, PAR, bitgen again.
>
> > All of the signals and elements of
> > the design are shown in it, and you simply choose the signals to
> > monitor. After you close the Inserter, go back to ISE, and re-fit.
>
> Re-fit - 10s of minutes.
>
> > From the ChipScope viewer, you can reconfigure the FPGA, then do an
> > "Import" which lets you bring in the names of all of the signals you
> > selected from the ChipScope Core Inserter project file.
>
> > No need to go into the FPGA editor at all!
>
> FPGAeditor, regenerate bitstream, 10s of seconds... =A0Then click "write
> CDC" button, import the result into the analyser. =A0Still tedious :)
>
> As I recall my experience withSignalTap(which was a while ago
> admittedly) I could select a signal from a dropdown list *in the
> Analyser* and it would do the tedious hacking that I currently do in
> FPGAed, regen the bitstream and upload it for me.
>
> Under some circumstances, it would redo a fit at that point, which was
> irritating, but at least I was able to do it all from the analyzer GUI,
> which was then always in sync with the FPGA.
>
> [Followups set to comp.arch.fpga, as it's not very Veriloggy]
>
> Cheers,
> Martin
>
> Crosspost & Followup-To: comp.arch.fpga
> --
> martin.j.thomp...@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://w=
ww.conekt.net/electronics.html


Article: 144507
Subject: post route simulation
From: JSreeniv <sreenivas.jyothi@gmail.com>
Date: Sat, 12 Dec 2009 01:54:23 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi all,

I am presently doing post route timing simulations using net-list and
sdf file.

I built test benches and done functional simulations and all are
working fine and expecting expected results

When i am running timing simulations for Min, Typ, Max, here i am
getting simulation results from the waveforms for Typ, Max,
but Min case my simulation is running up to some steps (where i can
observe in waveform) and after some time bus is idle and no more
simulation is happening. I am giving run time simulation in well; i
mean at least double the original time.

Is that i have to change any settings in Modelsim or any other process
to run this case.
Please anyone give some knowledge on this issue.


Thanks

Article: 144508
Subject: Re: Please Help me
From: Rube Bumpkin <Someone@somewhere.world>
Date: Sat, 12 Dec 2009 07:38:22 -0500
Links: << >>  << T >>  << A >>
Joshi & Joshi wrote:
> Hello to all
> 
> i have master Clock 40 Mhz and from master Clock want Generate 1.2 K
> hz Suare wave pulses at output
> 
> (1) what is problm with my Code
> (2) how Counter works and how to take decide the Counter values like
> these designs
> (3) without Counter can we use Shift ??
> 
> my code is as below
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use ieee.std_logic_unsigned.all;
> 
> entity Clk_divider is
>   port(
>     resetn           : in  std_logic; -- Reset
>     MHZ_clock      : in  std_logic;
>     Out_clock        : out std_logic
> 
>    );
>   end Clk_divider;
> 
> architecture Clk_divider_arch of Clk_divider is
> 
> signal  clk_count  : std_logic_vector(16 downto 0) :=
> "00000000000000000"; -- 16 Bit Counter
> 
> begin
> 
> Clock : process(resetn, MHZ_clock) -- 0.025uSec
> begin
>   if(resetn = '0') then
>     Out_clock <= '0';
> 
>   elsif(MHZ_clock'event and MHZ_clock = '1') then
>     	if(clk_count <= "01000001000101000") then ---    want Generate
> Delay (40M Hz /1.2K Hz = 3320)
>       		clk_count <= clk_count + '1';
>        		out_clock <= '1';
> 
>      	elsif(( clk_count > "01000001000101000") AND (clk_count <
> "10000010001010000"))then
>                       -- 0 to 3333 ON and 3333 to  6666 OFF
> 
>             	out_clock <= '0';
>                      clk_count <= clk_count + '1';
>                        if(clk_count = "10000010001010000") then
> 	clk_count <= "00000000000000000" ;
> 
>                         end if;
>           end if ;
> 
>   end if ;
>         end process Clock ;
> end Clk_divider_arch ;
> 
> Waiting fr  replies ..
> 
> with Advance Thanks
> Joshi
Homework?

Article: 144509
Subject: Does a 1-bit mux glitch if only one input is known to change at one time?
From: "dlopez" <d@designgame.ca>
Date: Sat, 12 Dec 2009 09:52:10 -0600
Links: << >>  << T >>  << A >>
Hi,

Would wire 'a' in this case be glitch free if:

1) count[0] comes out of a flip flop.
2) I can garantee that 'count[0]' is stable when 'b' is changing (but
'count[0]' might be high or low). 
3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
glitch free as well.
4) 'b' is a fully asynchronous signal

wire a = b ? 1 : count[0];


I'm using a Spartan3 FPGA.

Thanks,
Diego	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144510
Subject: Re: post route simulation
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 12 Dec 2009 08:00:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 12, 4:54=A0am, JSreeniv <sreenivas.jyo...@gmail.com> wrote:

> observe in waveform) and after some time bus is idle and no more
> simulation is happening. I am giving run time simulation in well; i
> mean at least double the original time.

You shouldn't need to run for any simulation time longer than you do
for simulating
- Original code
- Max time
- Typ time

>
> Is that i have to change any settings in Modelsim or any other process
> to run this case.

Why are the tools are the first suspect?  With almost 100% certainty,
the problem is one of the following:
- Your original code
- Possibly (but I would guess much less likely) the post route model
has some problem with the min timimg)

> Please anyone give some knowledge on this issue.
>
The problem is most likely in your code.  Since typ and max work I
would suspect that you have one (or more) of the following design
issues that need to be fixed.
- Incorrectly handled clock domain crossing
- Latches or other combinatorial logic loops

The easier way to find this is to perform static timing analysis.  The
harder way is to use the simulator.  Also, even if the simulator does
work with min, typ and max it does not imply that your design does not
have a timing problem.  The only way to insure that is through static
timing analysis.

Kevin Jennings

Article: 144511
Subject: Re: Cheapest way to get a chipscope compatible cable?
From: John Adair <g1@enterpoint.co.uk>
Date: Sat, 12 Dec 2009 08:46:51 -0800 (PST)
Links: << >>  << T >>  << A >>
I will add that our new USB based Prog3 is now working. This cable
will work with Impact and Chipscope. We do have some more tests to do
after which we will release to sell generally with our products.
Expect this to be available in January sometime.

John Adair
Enterpoint Ltd.

On 8 Dec, 22:43, John Adair <g...@enterpoint.co.uk> wrote:
> A number of parallel port based cables, like our Prog2 cable, will
> work for Chipscope/Impact tools. USB solutions are not readily
> available as yet unless you are a student where there is an option for
> a cheaper cable. We may offer something of a solution in a little
> while but remains to be debugged as yet.
>
> John Adair
> Enterpoint Ltd.
>
> On 8 Dec, 20:35, "dlopez" <d...@designgame.ca> wrote:
>
> > Hi,
> > It seems like Chipscope only supports the original Xilinx cable...no ot=
her
> > JTAG cable would work. Anyone knows if there is a way to obtain one for
> > less than the very high 250$ they ask for?
>
> > Thanks,
>
> > Diego =A0 =A0 =A0
>
> > --------------------------------------- =A0 =A0 =A0 =A0
> > This message was sent using the comp.arch.fpga web interface onhttp://w=
ww.FPGARelated.com


Article: 144512
Subject: Re: Cheapest way to get a chipscope compatible cable?
From: "dlopez" <d@designgame.ca>
Date: Sat, 12 Dec 2009 11:09:16 -0600
Links: << >>  << T >>  << A >>
Thanks everyone for the feedback...I ended up getting the Digilent cable
since it's so cheap. It was news to me that this cable would support
chipscope. It sure is better than 250$!

Diego	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144513
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: John Adair <g1@enterpoint.co.uk>
Date: Sat, 12 Dec 2009 09:55:37 -0800 (PST)
Links: << >>  << T >>  << A >>
You still will need to make sure you meet setup and hold to avoid
glitches.

If the system allows it would be better to put ;b; into the same clock
domain. Running as fast a clock as you can can minimise this inducted
jitter of an edge. With careful design and keeping it simple you could
probably run a 200Mhz clock giving a jitter window of 5 nS by
synchronising 'b'.

John Adair
Enterpoint Ltd.

On 12 Dec, 15:52, "dlopez" <d...@designgame.ca> wrote:
> Hi,
>
> Would wire 'a' in this case be glitch free if:
>
> 1) count[0] comes out of a flip flop.
> 2) I can garantee that 'count[0]' is stable when 'b' is changing (but
> 'count[0]' might be high or low).
> 3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
> glitch free as well.
> 4) 'b' is a fully asynchronous signal
>
> wire a =3D b ? 1 : count[0];
>
> I'm using a Spartan3 FPGA.
>
> Thanks,
> Diego =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> This message was sent using the comp.arch.fpga web interface onhttp://www=
.FPGARelated.com


Article: 144514
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 12 Dec 2009 19:07:44 +0100
Links: << >>  << T >>  << A >>
On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d@designgame.ca> wrote:

>Would wire 'a' in this case be glitch free if:
>
>1) count[0] comes out of a flip flop.
>2) I can garantee that 'count[0]' is stable when 'b' is changing (but
>'count[0]' might be high or low). 
>3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
>glitch free as well.
>4) 'b' is a fully asynchronous signal
>
>wire a = b ? 1 : count[0];
>
>I'm using a Spartan3 FPGA.

As John Adair hinted, the only truly safe way to do this is 
synchronously - which you've indicated is not possible.

There is no fundamental reason to assume that ANY combinational
logic will be glitch-free in a LUT-based FPGA.  In such FPGAs your
2-input OR gate (for that is what it is) will be implemented in
a LUT.  That means the LUT's address decoder will be changing
when either of the two inputs b,count[0] changes; and, in 
principle, all bets are off about glitches.  In practice the
LUTs seem very well behaved, and Xilinx experts may be able
to tell you how to do this in a way that's guaranteed glitch-free.
Personally, though, I wouldn't bet my life on it.  Find a solution
that doesn't depend on freedom from glitches at that level.
-- 
Jonathan Bromley

Article: 144515
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: Antti <antti.lukats@googlemail.com>
Date: Sat, 12 Dec 2009 10:28:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 12, 8:07=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d...@designgame.ca> wrote:
> >Would wire 'a' in this case be glitch free if:
>
> >1) count[0] comes out of a flip flop.
> >2) I can garantee that 'count[0]' is stable when 'b' is changing (but
> >'count[0]' might be high or low).
> >3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
> >glitch free as well.
> >4) 'b' is a fully asynchronous signal
>
> >wire a =3D b ? 1 : count[0];
>
> >I'm using a Spartan3 FPGA.
>
> As John Adair hinted, the only truly safe way to do this is
> synchronously - which you've indicated is not possible.
>
> There is no fundamental reason to assume that ANY combinational
> logic will be glitch-free in a LUT-based FPGA. =A0In such FPGAs your
> 2-input OR gate (for that is what it is) will be implemented in
> a LUT. =A0That means the LUT's address decoder will be changing
> when either of the two inputs b,count[0] changes; and, in
> principle, all bets are off about glitches. =A0In practice the
> LUTs seem very well behaved, and Xilinx experts may be able
> to tell you how to do this in a way that's guaranteed glitch-free.
> Personally, though, I wouldn't bet my life on it. =A0Find a solution
> that doesn't depend on freedom from glitches at that level.
> --
> Jonathan Bromley

I am almost sure Xilinx claims the LUT output is glitch-free
(under all conditions)

Antti




Article: 144516
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 12 Dec 2009 18:41:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jonathan Bromley <jonathan.bromley@mycompany.com> wrote:
> On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d@designgame.ca> wrote:
 
>>Would wire 'a' in this case be glitch free if:

>>1) count[0] comes out of a flip flop.
>>2) I can garantee that 'count[0]' is stable when 'b' is changing (but
>>'count[0]' might be high or low). 
>>3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]'
>>glitch free as well.
>>4) 'b' is a fully asynchronous signal

>>wire a = b ? 1 : count[0];

>>I'm using a Spartan3 FPGA.
 
> As John Adair hinted, the only truly safe way to do this is 
> synchronously - which you've indicated is not possible.

I think asking about glitches indicates the desire to not 
use synchronous logic.  While most people do, not everyone does.
 
> There is no fundamental reason to assume that ANY combinational
> logic will be glitch-free in a LUT-based FPGA.  In such FPGAs your
> 2-input OR gate (for that is what it is) will be implemented in
> a LUT.  That means the LUT's address decoder will be changing
> when either of the two inputs b,count[0] changes; and, in 
> principle, all bets are off about glitches.  

I will see what Xilinx says about this.  There are too many cases
in current designs where glitches like this would cause problems.
Now, changing two LUT inputs is likely to glitch if you can't
guarantee the intermediate states.  It might be, though, that the
decoders are implmented as two input MUX such that changing one
input won't glitch.  If you change more than one and the intermediate
states are consistent such that there is no glitch for any order
(which you likely can't predict) then it also shouldn't glitch.

All that really matters, though, is that any glitches are faster
than subsequent logic can see.  (Considering, for example, input
capacitance and drive strength.)

> In practice the
> LUTs seem very well behaved, and Xilinx experts may be able
> to tell you how to do this in a way that's guaranteed glitch-free.
> Personally, though, I wouldn't bet my life on it.  Find a solution
> that doesn't depend on freedom from glitches at that level.

-- glen

Article: 144517
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: "dlopez" <d@designgame.ca>
Date: Sat, 12 Dec 2009 13:12:58 -0600
Links: << >>  << T >>  << A >>
Alright I guess I should have posted what I was trying to do in the first
place...maybe the asynchronous way is just not the way to go.

I'm designing the interface with the FT2232H chip in Asynchronous Fifo
Mode. I want to maximize throughput. The timing diagram is on page26,
figure 4.5:

http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf

RXF: fully asynchronous input to FPGA
RD#: output from FPGA
D[7:0]: input to FPGA, needs to be grabbed when RD# goes high.

Now this has to be the most confusing timing diagram in the world, but
after hours of starring at it, I think I got it:

1)RXF goes low
2)FPGA drives RD# low...need to stay low 50ns
3)FPGA drives RD# high and grab the data.
4)RXF will stay low up to 25ns, then go high. It will stay high UP TO
67ns(but could be less). 
5)When RXF goes low again, we repeat this sequence.

What I'm struggling with is that when RXF goes low, the FPGA should bring
RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted
time that would reduce throughput.

Any ideas?
Thanks,
Diego

	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144518
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 12 Dec 2009 11:26:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 12, 11:12=A0am, "dlopez" <d...@designgame.ca> wrote:
> Alright I guess I should have posted what I was trying to do in the first
> place...maybe the asynchronous way is just not the way to go.
>
> I'm designing the interface with the FT2232H chip in Asynchronous Fifo
> Mode. I want to maximize throughput. The timing diagram is on page26,
> figure 4.5:
>
> http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf
>
> RXF: fully asynchronous input to FPGA
> RD#: output from FPGA
> D[7:0]: input to FPGA, needs to be grabbed when RD# goes high.
>
> Now this has to be the most confusing timing diagram in the world, but
> after hours of starring at it, I think I got it:
>
> 1)RXF goes low
> 2)FPGA drives RD# low...need to stay low 50ns
> 3)FPGA drives RD# high and grab the data.
> 4)RXF will stay low up to 25ns, then go high. It will stay high UP TO
> 67ns(but could be less).
> 5)When RXF goes low again, we repeat this sequence.
>
> What I'm struggling with is that when RXF goes low, the FPGA should bring
> RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted
> time that would reduce throughput.
>
> Any ideas?
> Thanks,
> Diego
>
> --------------------------------------- =A0 =A0 =A0 =A0
> This message was sent using the comp.arch.fpga web interface onhttp://www=
.FPGARelated.com

I have answered this particular question dozens of times while I was
working at Xilinx.
Today, I googled for "lut glitches" and here is what I found:

http://www.castalk.com/ftopic12373.html

In short:
changing a SINGLE lut input will NEVER generate a glitch.

Peter Alfke, quoting himself.

Article: 144519
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 12 Dec 2009 11:57:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 12, 2:12=A0pm, "dlopez" <d...@designgame.ca> wrote:
> Alright I guess I should have posted what I was trying to do in the first
> place...maybe the asynchronous way is just not the way to go.
>

With FPGAs going synchronous design is usually the best...

> I'm designing the interface with the FT2232H chip in Asynchronous Fifo
> Mode. I want to maximize throughput. The timing diagram is on page26,
> figure 4.5:
>
> http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf
>

Yes, I see it...it immediately follows figure 4.4 and the description
on pages 24 and 25 of SYNCHRONOUS Fifo mode operation...

>
> What I'm struggling with is that when RXF goes low, the FPGA should bring
> RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted
> time that would reduce throughput.
>
> Any ideas?

In the end, asynchronous mode operation of the fifo will never be able
to come close to getting the throughput that you can get with
synchronous mode operation.

For this particular part, it looks like you can clock the fifo at 60
MHz for synchronous mode.  For async operation, the theoretical best
performance (and not actually achievable in any real design because it
assumes zero prop delay, PCB delay, setup or hold time) is a clock
period of T1 (=3D50 ns) + T2 (=3DT5 + T6 =3D 0 + 33 ns) for a total of 83
ns...5 times slower than synchronous mode...and not achievable
either.  In reality you'd probably be lucky to get the whole thing to
run with a 100 ns clock...6 times slower than synchronous mode.

You say you want to get the data 'as soon as possible', but that's not
a real requirement.  Do the analysis and figure out what sort of
performance you actually need.  Then you can decide whether the ~10
MHz operation of async mode operation is acceptable.  If not, then
you'll have to run the fifo synchronously.

Kevin Jennings

Article: 144520
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: "dlopez" <d@designgame.ca>
Date: Sat, 12 Dec 2009 14:46:14 -0600
Links: << >>  << T >>  << A >>

>With FPGAs going synchronous design is usually the best...
>
>> I'm designing the interface with the FT2232H chip in Asynchronous Fifo
>> Mode. I want to maximize throughput. The timing diagram is on page26,
>> figure 4.5:
>>
>> http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf
>>
>
>Yes, I see it...it immediately follows figure 4.4 and the description
>on pages 24 and 25 of SYNCHRONOUS Fifo mode operation...
>
>>
>> What I'm struggling with is that when RXF goes low, the FPGA should
bring
>> RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted
>> time that would reduce throughput.
>>
>> Any ideas?
>
>In the end, asynchronous mode operation of the fifo will never be able
>to come close to getting the throughput that you can get with
>synchronous mode operation.
>
>For this particular part, it looks like you can clock the fifo at 60
>MHz for synchronous mode.  For async operation, the theoretical best
>performance (and not actually achievable in any real design because it
>assumes zero prop delay, PCB delay, setup or hold time) is a clock
>period of T1 (=3D50 ns) + T2 (=3DT5 + T6 =3D 0 + 33 ns) for a total of 83
>ns...5 times slower than synchronous mode...and not achievable
>either.  In reality you'd probably be lucky to get the whole thing to
>run with a 100 ns clock...6 times slower than synchronous mode.
>
>You say you want to get the data 'as soon as possible', but that's not
>a real requirement.  Do the analysis and figure out what sort of
>performance you actually need.  Then you can decide whether the ~10
>MHz operation of async mode operation is acceptable.  If not, then
>you'll have to run the fifo synchronously.
>
>Kevin Jennings
>

I agree with your worst case calculations, and they align with what FTDI
claim for the Async mode (10MB/s). 
However, there are two things to consider:
1)the sync fifo is more like 25MB/s sustained (it bursts out at 60, but in
the end you get 25). 
2)the async FIFO has TWO channels, at say 10MB/s. So overall it might be a
bit less, but the fact that the two channels run in parallel GREATLY
simplify my system since I can separate control and streaming data.

Now I'm REALLY struggling to get the state machine with 3 states to run at
more than 100MHZ!!!

Diego
	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144521
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at one time?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 12 Dec 2009 22:48:20 +0100
Links: << >>  << T >>  << A >>
On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke
<alfke@sbcglobal.net> wrote:

>In short:
>changing a SINGLE lut input will NEVER generate a glitch.

Nice to know, and - thinking about the likely structures
for the guts of a LUT - perfectly reasonable.  Thanks.

However.... can all other manufacturers of LUT-based 
FPGAs make the same promise?  Again, *probably* yes; 
but would you bet your life/reputation/fortune on it?
-- 
Jonathan Bromley

Article: 144522
Subject: Re: post route simulation
From: Muzaffer Kal <kal@dspia.com>
Date: Sat, 12 Dec 2009 17:00:12 -0800
Links: << >>  << T >>  << A >>
On Sat, 12 Dec 2009 01:54:23 -0800 (PST), JSreeniv
<sreenivas.jyothi@gmail.com> wrote:

>Hi all,
>
>I am presently doing post route timing simulations using net-list and
>sdf file.
>

Does the post-route timing report have any violations? Before you run
post-route simulations you need to make sure you have proper timing
constraints and your post-route timing is clean. 

>I built test benches and done functional simulations and all are
>working fine and expecting expected results
>
>When i am running timing simulations for Min, Typ, Max, here i am
>getting simulation results from the waveforms for Typ, Max,
>but Min case my simulation is running up to some steps (where i can
>observe in waveform) and after some time bus is idle and no more
>simulation is happening. I am giving run time simulation in well; i
>mean at least double the original time.

For properly designed circuits min, max and typ behavior should be
identical. Even if your simulation completed with longer run times, it
would mean there is still a violation (there might be some timing
dependency on synchronization paths for clock domain crossings but
this should be rare and bounded in time).
One other thing you can check is the timing simulation log. Are there
any timing violations reported? Min timing problems suggest that there
might be some hold violations. Look at the log which comes out while
running your simulation and check if any hold violations are being
reported.
Another option you can try is to run your timing simulation with "no
timing checks" option in your simulator and see if that completes
properly. If the simulation runs properly with "+notimingchecks"
option then it's almost guaranteed that you have some timing
violations which  need to be fixed.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 144523
Subject: Re: Does a 1-bit mux glitch if only one input is known to change at
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 12 Dec 2009 17:06:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 12, 3:46=A0pm, "dlopez" <d...@designgame.ca> wrote:
> However, there are two things to consider:
> 1)the sync fifo is more like 25MB/s sustained (it bursts out at 60, but i=
n
> the end you get 25).

That's because the part runs out of data (read) or can't send it out
fast enough (write).  The effective throughput is limited by how well
the USB engine and whatever is on the other end can transfer data, not
because of some inherent issue with the synchronous interface.

> 2)the async FIFO has TWO channels, at say 10MB/s. So overall it might be =
a
> bit less, but the fact that the two channels run in parallel GREATLY
> simplify my system since I can separate control and streaming data.
>

OK, but then if you have a justification for why you''re willing to
sacrifice performance you shouldn't worry too much about limiting it a
bit more by your choice of data connection.

> Now I'm REALLY struggling to get the state machine with 3 states to run a=
t
> more than 100MHZ!!!

Using the synchronous protocol you'd only need to run at 60 MHz.

Good luck, sounds challenging and that always makes life interesting.

Kevin Jennings

Article: 144524
Subject: Re: Data2MEM - finding the blockrams after PAR?
From: Eric Smith <spacewar@gmail.com>
Date: Sat, 12 Dec 2009 23:23:22 -0800 (PST)
Links: << >>  << T >>  << A >>
> The data2mem tool doesn't require you to know the physical location of
> a particular BlockRAM, it just needs to know what the name is like a
> UCF file does.http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2...

Thanks!  I'm still confused since that manual says (page 28) "The BMM
file <i>must</i> have LOC or PLACED constraints for each block RAM.
These constraints can be added manually, but they are most often
obtained as an annotated BMM file from Bitgen.  For information, see
Using Integrated ISE(R) Design Suite Implementation Tools."  I think
that is in reference to the "-bd" option to bitgen, but as far as I
can tell, that still needs to have physical location constraints for
the blockrams (page 33) "Placement information of each block RAM is
provided by teh NCD file.  Any block RAM placement constraints that
appear in the BMM file are already reflected in the NCD information.
All othe rblock RAMs are assigned placement constraints by previous
tool steps."

I was originally using generic VHDL code to get XST to infer the
blockrams, and I couldn't figure out how to refer to them in
constraints, but I've given up on using inference and am now
instantiating RAMB16_S9 primitives.

Eric



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