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 141225

Article: 141225
Subject: Re: Xilinx Block RAM Sim
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 Jun 2009 13:13:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 10, 11:07=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 10 Jun 2009 06:44:47 -0700 (PDT), rickman wrote:
> >I'm unclear about what you are saying about a short delay interfering
> >with the use of delta delays. =A0Delta delays have 0 ns resolution, in
> >fact, they are in essence "outside" of time delays. =A0All delta delays
> >must be resolved before a time delay is considered. =A0Are you saying
> >that with the delay truncated to 0 ns, it is really no delay at all
> >and so this signal would be processed with a delta delay instead?
> >Even if true, how would that create a problem?
>
> RTL simulation of registered logic works only because delta
> delay models the clock-to-output delay of registers, so that
> each register sees its clock edge happening at least one
> delta cycle before the upstream registers' outputs have
> changed their value. =A0Conceptually, the clock arrives at
> every flop truly simultaneously - in the exact same delta -
> but data changes happen at least one delta after the
> clock edge.
>
> Things like clock gating can introduce one or more delta
> delays in a clock path. =A0In real hardware, the non-zero
> clock-to-output delay of upstream logic means that you
> still have plenty of hold time on the flop that has a
> gated clock. =A0But in simulation, you lose your one delta
> of hold time and you can get bizarre results.

Hmmm...  I am not sure I agree that "In real hardware" clock gating is
not a problem.  In fact, it is very much a problem since it is now a
new clock and must be either routed onto another global clock net or
routed using the distributed routing.  Either way introduces
significant delay which needs special consideration in an FPGA or ASIC
design.

I guess if you just want to ignore the timing issues and need to
perform a unit delay simulation, then you need to add delays to the
output of sequential logic.  But the key here is that you have to
address the delays created by clock gating.  In general the tools are
not very good at this which is why this is discouraged.

Rick

Article: 141226
Subject: Re: Doubt about a Microblaze Based Multiprocessor SoC
From: pbljung <ljung@codetronix.com>
Date: Thu, 11 Jun 2009 13:15:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 11, 12:28=A0pm, "naim32" <engineer_n...@yahoo.com> wrote:
> >You can't chain MPMCs -- the SDRAM port is not compatible with the
> >user port. You can potentially use 8x MB using a MPMC and 4x MB using
> >MCHEMC, but I've never tried that. I'm also not sure that 12 MB fit on
> >a ML403 (which is rather small).
>
> >Why 12 MB? Moving functionality from sw to hw is normally recommended.
>
> I have to migrate a system into my board and compare them. If 12 can not
> fit, its okay. I have one more question regarding the DDR, I can add up t=
o
> 8x MBs on the DDR each including I and D cache? I mean, if I enabled the =
I
> and D cache for my MBs, still I can fit 8 on the DDR?
>
> Thanks
> N

I've run 8x MB (without caches), but don't remember if it was a ML4xx
or ML5xx. Allocating (unused) BRAM to caches should be fine.

Article: 141227
Subject: Re: Safe margin in FPGA static timing analysis
From: whygee <whygee@yg.yg>
Date: Thu, 11 Jun 2009 22:16:15 +0200
Links: << >>  << T >>  << A >>
rickman wrote:
> How long is a piece of string? <snip> So by
> using a design that misses spec by a small amount raises the
> probability of failure, but likely by a small amount.  But that all
> depends on your design...

I think that the answer is "just try" :-)
Now this raises the question of the testbenches
and the verification methodology...
"We" usually spare this effort by trusting
the static analysis results :-)

> Rick
yg

-- 
http://ygdes.com / http://yasep.org

Article: 141228
Subject: Re: Safe margin in FPGA static timing analysis
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 Jun 2009 13:23:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 10, 11:50=A0pm, OutputLogic <evgen...@gmail.com> wrote:
> FPGA timing closure is a time-consuming task and sometimes a source of
> heated debates between team members.
> My question to this group is what is a safe margin in static timing
> analysis in which a design will still work.
> Specifically, if a critical net in Xilinx Virtex5 -2 chip running at
> 250 MHz misses timing by 100ps is it still ok.
> I understand that there are factors like temperature, voltages,
> jitter, etc. to consider, and it's always better to meet timing. But
> I'm interested in how much the timing can be violated if a design is
> running under "normal" conditions in a lab.

How long is a piece of string?  As the others have said, your tools
have to assume worst case *everything* be be able to assure that the
design will work under all possible conditions... no matter how
unlikely the worst case conditions are.  If I'm not mistaken, some of
the "magic" used in coming up with the delay numbers is statistical
based on their process and so the number is never really an absolute
guarantee, but puts you in a very high percentile of working.  So by
using a design that misses spec by a small amount raises the
probability of failure, but likely by a small amount.  But that all
depends on your design...

Rick

Article: 141229
Subject: ASIC Proto and Verif with FPGA survey - Gift Certificate to Amazon
From: "John Blyler" <jblyler@extensionmedia.com>
Date: Thu, 11 Jun 2009 13:48:32 -0700
Links: << >>  << T >>  << A >>
Hi all. I'm running my annual "ASIC-ASSP Protoyping and Verification with 
FPGA" survey. There will be a drawing for twenty, $15 Amazon certificates. 
Survey ends next Wednesday (June 17th). See below for details. Cheers. --  
John


+++++++
Hello. We are conducting a global survey on ASIC-ASSP Prototyping with FPGA 
and would appreciate about 5 minutes of your time to answer a number of key 
questions. Please answer all questions so we have a comprehensive data set.

Extension Media (publishers of Chip Design, Embedded Intel, and FPGA 
Developer) is conducting its annual research study about the evolving trends 
in ASIC-ASSP prototyping and verification with FPGA platforms. We are 
interested in hearing from hardware, software and system 
engineers-architectures working in the chip and embedded development 
communities.

Go to Survey --> http://www.chipdesignmag.com/survey/2009.php

In appreciation for your time, 20 respondents will be selected at random to 
receive a $15.00 gift certificate from Amazon.com. [Chinese respondents 
living outside the US will be entered to win gift certificates from either 
Dangdang.com or Joyo.com]

The drawing will be held on June 24th, 2009. To qualify, respondents must 
complete the survey by Wednesday, June 17, 2009 AND complete all of the 
required Qualification Data.

Your assistance is greatly appreciated.

Thank you. -- John Blyler, Editor-in-Chief 



Article: 141230
Subject: Re: Doubt about a Microblaze Based Multiprocessor SoC
From: "naim32" <engineer_naim@yahoo.com>
Date: Thu, 11 Jun 2009 16:37:11 -0500
Links: << >>  << T >>  << A >>
>
>I've run 8x MB (without caches), but don't remember if it was a ML4xx
>or ML5xx. Allocating (unused) BRAM to caches should be fine.
>

Thank you for the feedback, I will try the system tomorrow and will post
the results soon... Again Thank you

Article: 141231
Subject: Re: Latest Xilinx Discontinuations
From: austin <austin@xilinx.com>
Date: Thu, 11 Jun 2009 15:23:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
Good idea,

"Preferred parts" is not new.

I think contacting our FAE's can tell you that today, but I will
check.

And, to the paranoid, everything is alarming.  Can't help you there
Antti.

Austin

Article: 141232
Subject: Re: Safe margin in FPGA static timing analysis
From: austin <austin@xilinx.com>
Date: Thu, 11 Jun 2009 15:26:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have posted on this topic before: a short repeat---

The adequate slack is the peak of the system jitter (1/2 the peak to
peak).

If the system jitter is 2,000 ps peak to peak, then 1,000 ps is
required.

If the system jitter is 100 ps peak to peak, 50 ps is required.

This is true as long as the paths in question have been properly
constrained (there are no paths that are required to meet timing that
are unconstrained).

Austin

Article: 141233
Subject: Fast carry chain
From: "Andrew Holme" <ah@nospam.co.uk>
Date: Thu, 11 Jun 2009 23:36:58 +0100
Links: << >>  << T >>  << A >>
Looking at a Spartan 3 SLICE in FPGA Editor, I see a tap coming off the fast 
carry chain COUT to a port called YB.

I would like to implement 10-digit BCD addition based on the method 
described here:

http://www.edn.com/archives/1996/021596/04di3.htm

which requires access to the intermediate carry outputs at 4-bit intervals 
in long carry chains.

What is YB for, can I use it for this, and if so, how?

TIA 



Article: 141234
Subject: Re: Safe margin in FPGA static timing analysis
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 11 Jun 2009 15:45:38 -0700
Links: << >>  << T >>  << A >>
On Wed, 10 Jun 2009 20:50:01 -0700 (PDT), OutputLogic
<evgenist@gmail.com> wrote:

>FPGA timing closure is a time-consuming task and sometimes a source of
>heated debates between team members.
>My question to this group is what is a safe margin in static timing
>analysis in which a design will still work.
>Specifically, if a critical net in Xilinx Virtex5 -2 chip running at
>250 MHz misses timing by 100ps is it still ok.
>I understand that there are factors like temperature, voltages,
>jitter, etc. to consider, and it's always better to meet timing. But
>I'm interested in how much the timing can be violated if a design is
>running under "normal" conditions in a lab.

I would not be surprised if Xilinx's timing numbers had at least a %10
margin in them given that they ship millions of parts and it's better
to err on the side of safety (and more profitable too, makes you buy a
-2 part instead of a -1). 100ps over 4000ps is only 2.5% so in a lab
I'd say you're completely safe.
For a product you also have a good solution. You can run speedprint to
time your missing paths with a slightly higher voltage and provide
that level to your chip. V5 is supplied with nominal 1V but trce times
it with 950mv. If you actually supplied the nominal value, you should
be able to pass timing.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 141235
Subject: Re: Latest Xilinx Discontinuations
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Thu, 11 Jun 2009 15:51:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 11, 9:31=A0am, Rob Gaddi <rga...@technologyhighland.com> wrote:
> Hey all --
>
> Just got an email from Xilinx marking discontinuations on the XC3S50 in
> the CP132 package. =A0Their recommendation for anyone using them is the
> XC3S100E, rebuilding the FPGA, and respinning the PCB.

Here's the link for those interested.
http://www.xilinx.com/support/documentation/customer_notices/xcn08011.pdf

> Not to sound alarmist, but I hadn't quite gotten to the point of
> considering the Spartan 3s to be a "fossil" family yet. =A0It seems early
> in the lifecycle to be discontinuing parts with no replacement and,
> while I don't have any designs around this part, it pricks up my ears
> with regard to the many XC3S200-TQ144 designs I've got going.

IMHO, the XC3S50 in the CP132 package (and Pb-free CBP132) is a victim
of the XC3S100E being available in the same package--the only chip-
scale option for either family.  The last time I looked, the XC3S50
and XC3S100 were very close in price but the XC3S100E offered better
value (25% more logic and SPI-PROM configuration, but with essentially
the same features).  Plus, the XC3S50 was an orphan in the CP132;
there was no upgrade path to other members of the Spartan-3 family.
In the Spartan-3E family, you can use an XC3S100E, XC3S200E, or an
XC3S500E in the same CP132 footprint.  SIDE NOTE:  The XC3S100E has
fewer I/O pins (83) than the XC3S50 (89) in the CP132 so you might
need to bump up to the XC3S200E option.  Furthermore, all the I/Os on
Spartan-3 FPGAs are full I/O while some of the Spartan-3E pins are
input-only.

I would guess that the XC3S200 in TQ144 package is one of the safest
package options around.

> Does anyone have any thoughts regarding Xilinx and part longevity?
> And, more to the point, thoughts regarding the other players on the
> field and whether they're any better/worse?

I used to work for Xilinx (now I'm a customer).  It was amazing how
long they kept product families around for sale.  Even when they
finally killed a product, the terms were generally fairly reasonable.

SUMMARY:  I wouldn't worry about the XC3S50 in the CP132 package being
discontinued--unless, of course, you are specifically using that
particular option.  That specific discontinuation decision has little
bearing on the rest of the Spartan-3 part/package options.

-- Steve Knapp
   Prevailing Technology, Inc.
   www.prevailing-technology.com

Article: 141236
Subject: Re: Xilinx Block RAM Sim
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Thu, 11 Jun 2009 15:57:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 8, 8:55=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> But there isnt any 100ps delay on the actual device.
>
> Jon

The 100 ps is for there for behavioral simulation just to show a
causal relationship (not to be confused with a casual relationship!)
between the clock and data output.  It just makes the data output
appear AFTER the clock edge in the waveform.  Otherwise, clock and
data appear to happen simultaneously, which can be confusing when you
are tracking down a bug.

If you switch to post-route simulation, then you will see delays that
more closely match reality.

-- Steve Knapp
   Prevailing Technology, Inc.
   www.prevailing-technology.com

Article: 141237
Subject: Re: AT&T Usenet Netnews Service Shutting Down
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Thu, 11 Jun 2009 16:05:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 8, 4:47=A0pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> <news-supp...@sbcglobal.net> wrote in message
>
> news:1244504405.96258_3078@flph199.ffdc.sbc.com...
>
>
>
> > Please note that on or around July 15, 2009, AT&T will no longer be
> > offering access to the Usenet netnews service. =A0If you wish to contin=
ue
> > reading Usenet newsgroups, access is available through third-party
> > vendors.
>
> > Posted only internally to AT&T Usenet Servers.
>
> Well there's a bite in the nuts. Thanks a bunch.

Unfortunately, it is apparently a common refrain.  Comcast dropped
access awhile back.

Article: 141238
Subject: Re: ISE 10.1 Free Downlaod Web Install
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 12 Jun 2009 01:15:04 +0100
Links: << >>  << T >>  << A >>
On Thu, 11 Jun 2009 12:24:34 -0700 (PDT), john <conphiloso@hotmail.com> wrote:

>Hi All,
>
>I am trying to install ISE webpack 10.1 webinstall on my machine. I
>have Vista Business 64 bit OS. I dowloaded and saved the file on my
>drive and execute the setup file. I entered the Product ID but the
>installation program is only showing the ISE programming tool option
>active not the ISE Design tool active at all. Can anyone tells me what
>is the problem,

Check whether Xilinx say it is compatible with a 64-bit OS.

I have used Webpack under a 64-bit OS, but 
(a) it needed 32-bit compatibility libraries (which were optional with the OS
install)
(b) I had to bypass a 64-bit check in the Webpack setup.sh script to get it to
install
(c) the OS was OpenSuse 11, not Windows.

If you must use Windows you may have to find a 32-bit version (and not one of
the Vista Home editions either. XP seems to be preferred from what I hear)

Or upgrade to the full non-Webpack edition.

- Brian

Article: 141239
Subject: Re: Xilinx DDS cannot pass simulation in Simulink
From: "cwoodring" <cwoodring@cox.net>
Date: Thu, 11 Jun 2009 20:33:04 -0400
Links: << >>  << T >>  << A >>
Are you sure you have the correct version of the XilinxCoreLib for the 
version of System Gen. you are using?

CTW

"fl" <rxjwg98@gmail.com> wrote in message 
news:f1f0afa1-369e-4d5a-8fa0-7ba0ab217537@q14g2000vbn.googlegroups.com...
>
> Hi,
> I am trying simulating xapp1113 in Matlab simulink. The following
> message appears. I don't know how to solve it. Anyone can shed some
> light on it? Thanks a lot.
>
> HDL compilation failed.
> ERROR:HDLParsers:3281 -
>   "C:/DOCUME~1/WNS/LOCALS~1/Temp/xlisim4a23e7da/
> xlisim_xldds_compilerv11.vhd"
>   Line 70. behavioral is not an architecture body for
> dds_compiler_v2_0 in
>   library XilinxCoreLib.
>
>
> Error occurred during "Simulation Initialization".
>
> 



Article: 141240
Subject: Re: Latest Xilinx Discontinuations
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 11 Jun 2009 21:36:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 12, 1:23=A0am, austin <aus...@xilinx.com> wrote:
> Good idea,
>
> "Preferred parts" is not new.
>
> I think contacting our FAE's can tell you that today, but I will
> check.
>
> And, to the paranoid, everything is alarming. =A0Can't help you there
> Antti.
>
> Austin

Austin,
its not me worried, some others are
I am consdering both S3 and S3E as NND
too bad S3A and S6 have no CP132 package thats a bad decision
Actel, Altera, Lattice, Silicon Blue, Quicklogic all have 8x8 packages
in latest familes

Antti




Article: 141241
Subject: Re: Error in FSL Bus
From: Goran_Bilski <goran.bilski@xilinx.com>
Date: Fri, 12 Jun 2009 00:38:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

Since you got an assembler error, I was more thinking of your
assembler code than your hardware implementation.

G=F6ran

Article: 141242
Subject: Verilog "for loop" - exit by setting i to exit value?
From: nachum <nachumk@gmail.com>
Date: Fri, 12 Jun 2009 03:10:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am using Xilinx ISE 11.1 with XST for compiling Verilog code. XST
11.1 for Virtex 5 doesn't support using the disable keyword from
within a for loop. Instead they recommended code like this:
http://www.xilinx.com/support/answers/22177.htm

integer i;
always @(posedge clk)
begin
 for(i = 0; i < NUM_LOOPS; i = i + 1)
 begin
  if(ready[i])
  begin
   go[i] <= 1;
   i = NUM_LOOPS;
  end
 end
end

I have found this code to be synthesized incorrectly as the loop isn't
actually exited after i is set to NUM_LOOPS, and therefore multiple
bits of go are raised in a single clock.

They have said that this isn't supported in the standard. Can someone
shed light on this? Is this code supported and should it work? I don't
have the LRM and I can't find any definitive answer on whether this
code is legal Verilog syntax, and whether it should work.

Thanx,
Nachum Kanovsky

Article: 141243
Subject: Re: Latest Xilinx Discontinuations
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 12 Jun 2009 11:11:40 +0100
Links: << >>  << T >>  << A >>

"austin" <austin@xilinx.com> wrote in message 
news:bd10e80d-29d3-4ea5-84d0-8a9a45d010f3@w9g2000pro.googlegroups.com...
>
> We still sell everything else: with the 3000 series FPGA probably the
> oldest, and still shipping products.
>

I'm probably misreading this, but I think the 3000 series is pushing up the 
daisies...

http://www.xilinx.com/support/documentation/customer_notices/xcn08011.pdf 



Article: 141244
Subject: Re: Verilog "for loop" - exit by setting i to exit value?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 12 Jun 2009 12:42:09 +0100
Links: << >>  << T >>  << A >>
On Fri, 12 Jun 2009 03:10:37 -0700 (PDT), nachum <nachumk@gmail.com> wrote:

> for(i = 0; i < NUM_LOOPS; i = i + 1)
> begin
>  if(ready[i])
>  begin
>   go[i] <= 1;
>   i = NUM_LOOPS;
>  end
> end

>I have found this code to be synthesized incorrectly as the loop isn't
>actually exited after i is set to NUM_LOOPS, and therefore multiple
>bits of go are raised in a single clock.

Not a Verilog user but if I understand the problem, my suggestion is to
transform the loop into one in which the loop extent remains static, which is
less likely to cause grief at synthesis time.

Something like 

 for i in 0 to NUM_LOOPS loop
  if ready(i) and not done then 
   go(i) <= 1;
   done  <= TRUE;	   -- originally i = NUM_LOOPS;
  end if;
 end loop;

Shouldn't result in any more hardware.

- Brian

Article: 141245
Subject: Re: Verilog "for loop" - exit by setting i to exit value?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 12 Jun 2009 14:50:28 +0100
Links: << >>  << T >>  << A >>
On Fri, 12 Jun 2009 03:10:37 -0700 (PDT), nachum wrote:

>Hi,
>
>I am using Xilinx ISE 11.1 with XST for compiling Verilog code. XST
>11.1 for Virtex 5 doesn't support using the disable keyword from
>within a for loop. Instead they recommended code like this:

Oh dear.  Some attitude readjustment is in order, I think.

>integer i;
>always @(posedge clk)
>begin
> for(i = 0; i < NUM_LOOPS; i = i + 1)
> begin
>  if(ready[i])
>  begin
>   go[i] <= 1;
>   i = NUM_LOOPS;
>  end
> end
>end
>
>I have found this code to be synthesized incorrectly as the loop isn't
>actually exited after i is set to NUM_LOOPS, and therefore multiple
>bits of go are raised in a single clock.
>
>They have said that this isn't supported in the standard. 

Well....  it *is* supported by Verilog, for sure, but
it's truly ghastly.  Brian was right; if you can't use
"disable", then do the same thing you would expect your
synth tool to do: allow the loop to run to completion
(because you can't on-the-fly change how much hardware 
you have!) but suppress its activity in the unwanted 
passes of the loop.  This should synthesise OK:

  integer i;
  always @(posedge clk)
  begin : find_first_one  // label the begin..end
    reg found;  // local variable inside named block
    found = 0;  // be sure to do this!!!   
    for(i = 0; i < NUM_LOOPS; i = i + 1)
      if (!found) // still looking???
      begin
        if(ready[i])
        begin
          go[i] <= 1;
          found = 1; // this suppresses later trips
        end
      end
    end
  end

This idiom will synthesise a ripple-OR chain to
get the specified priority-encoding behaviour.
If you get really lucky, it just might use the
carry-chain resources to do that faster....

BTW, your code as it stands is not very useful
because nothing ever clears go[], but I guess
you intentionally deleted a bunch of other code.

As far as the Verilog language rules are concerned:
a loop counter, declared in the way you showed, is
just an ordinary variable and you can indeed set its
value inside the loop, but please tell me you're not
going to do that.  Ever.  Please.  Really, don't.

You should also be aware that it is an exceptionally
bad idea to use a module-level variable as a loop
counter in Verilog.  Make use of the named-block
feature to make the loop counter local:

  always @(whatever) begin : named_block
    integer i;  // LOCAL loop counter
    for (i = 0; .....

That way, there's no risk of nasty interaction
between the 'i' counters of various different loops.

Finally, be aware that SystemVerilog has seen the
error of Verilog's ways and allows you to declare
truly local loop counters:

   for (int i = 0; i<LIMIT; i++) begin ...

This 'i' doesn't exist at all outside the loop body.
Much, much nicer, and easier for synthesis tools
to deal with as well.  Not supported in all tools
just yet, of course.
-- 
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: 141246
Subject: Re: Verilog "for loop" - exit by setting i to exit value?
From: nachumk <nachumk@gmail.com>
Date: Fri, 12 Jun 2009 07:30:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 12, 4:50=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 12 Jun 2009 03:10:37 -0700 (PDT), nachum wrote:
> >Hi,
>
> >I am using Xilinx ISE 11.1 with XST for compiling Verilog code. XST
> >11.1 for Virtex 5 doesn't support using the disable keyword from
> >within a for loop. Instead they recommended code like this:
>
> Oh dear. =A0Some attitude readjustment is in order, I think.
>
>
>
> >integer i;
> >always @(posedge clk)
> >begin
> > for(i =3D 0; i < NUM_LOOPS; i =3D i + 1)
> > begin
> > =A0if(ready[i])
> > =A0begin
> > =A0 go[i] <=3D 1;
> > =A0 i =3D NUM_LOOPS;
> > =A0end
> > end
> >end
>
> >I have found this code to be synthesized incorrectly as the loop isn't
> >actually exited after i is set to NUM_LOOPS, and therefore multiple
> >bits of go are raised in a single clock.
>
> >They have said that this isn't supported in the standard.
>
> Well.... =A0it *is* supported by Verilog, for sure, but
> it's truly ghastly. =A0Brian was right; if you can't use
> "disable", then do the same thing you would expect your
> synth tool to do: allow the loop to run to completion
> (because you can't on-the-fly change how much hardware
> you have!) but suppress its activity in the unwanted
> passes of the loop. =A0This should synthesise OK:
>
> =A0 integer i;
> =A0 always @(posedge clk)
> =A0 begin : find_first_one =A0// label the begin..end
> =A0 =A0 reg found; =A0// local variable inside named block
> =A0 =A0 found =3D 0; =A0// be sure to do this!!! =A0
> =A0 =A0 for(i =3D 0; i < NUM_LOOPS; i =3D i + 1)
> =A0 =A0 =A0 if (!found) // still looking???
> =A0 =A0 =A0 begin
> =A0 =A0 =A0 =A0 if(ready[i])
> =A0 =A0 =A0 =A0 begin
> =A0 =A0 =A0 =A0 =A0 go[i] <=3D 1;
> =A0 =A0 =A0 =A0 =A0 found =3D 1; // this suppresses later trips
> =A0 =A0 =A0 =A0 end
> =A0 =A0 =A0 end
> =A0 =A0 end
> =A0 end
>
> This idiom will synthesise a ripple-OR chain to
> get the specified priority-encoding behaviour.
> If you get really lucky, it just might use the
> carry-chain resources to do that faster....
>
> BTW, your code as it stands is not very useful
> because nothing ever clears go[], but I guess
> you intentionally deleted a bunch of other code.
>
> As far as the Verilog language rules are concerned:
> a loop counter, declared in the way you showed, is
> just an ordinary variable and you can indeed set its
> value inside the loop, but please tell me you're not
> going to do that. =A0Ever. =A0Please. =A0Really, don't.
>
> You should also be aware that it is an exceptionally
> bad idea to use a module-level variable as a loop
> counter in Verilog. =A0Make use of the named-block
> feature to make the loop counter local:
>
> =A0 always @(whatever) begin : named_block
> =A0 =A0 integer i; =A0// LOCAL loop counter
> =A0 =A0 for (i =3D 0; .....
>
> That way, there's no risk of nasty interaction
> between the 'i' counters of various different loops.
>
> Finally, be aware that SystemVerilog has seen the
> error of Verilog's ways and allows you to declare
> truly local loop counters:
>
> =A0 =A0for (int i =3D 0; i<LIMIT; i++) begin ...
>
> This 'i' doesn't exist at all outside the loop body.
> Much, much nicer, and easier for synthesis tools
> to deal with as well. =A0Not supported in all tools
> just yet, of course.
> --
> 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Thanks for the responses,

The only thing that interests me regarding this specific code is
whether it is legal according to the Verilog LRM. Xilinx claims that
my above code is illegal, and the old XST synthesizes it wrong,
whereas the new XST doesn't support it outright. I wrote the code up
above on the fly to demonstrate, so I didn't bother declaring some
things or resetting "go".

The variable i is only used during synthesis to create the appropriate
amount of hardware to do the job. The "i =3D NUM_LOOPS" should create
hardware identical to using a found variable. I also never bother to
create local i variables b/c I do not use them as values, but only as
loop iterators, and as the iterators are synthesized away by
definition there should be no fear of them interacting with each
other. In that sense the i variable is likened to a generate loop.
This is also evidenced by the workaround I have been forced to
implement due to XST's inability with exiting for loops:

integer i;
always @(posedge clk)
begin
 i =3D 0;
 found =3D 0;
 go <=3D 0; //resetting go :)
 while((i < NUM_LOOPS) && !found)
 begin
  if(ready[i])
  begin
   go[i] <=3D 1;
   found =3D 1;
  end
  i =3D i + 1;
 end
end

I have this type of code in my modules multiple times over for various
loop situations, and they all use the same i variable. That code is
properly synthesized. This page http://www.xilinx.com/support/answers/22066=
.htm
shows that XST has issues with multiple for loops in the same module
using the same iterator. That is listed by them as a bug which needs
to be worked around, but they don't mention anything about it being
illegal or dangerous.

Can I get a better explanation as to why my originally suggested for
loop is so bad? Your comment that it is ghastly makes me wonder.

I would love to know if the Verilog LRM fully supports my code? I want
Xilinx to fix XST to support it as I believe it should.

Thank you again,
Nachum Kanovsky
ionipti.blogspot.com

Article: 141247
Subject: Re: Verilog "for loop" - exit by setting i to exit value?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 12 Jun 2009 15:56:54 +0100
Links: << >>  << T >>  << A >>
On Fri, 12 Jun 2009 07:30:25 -0700 (PDT), nachumk wrote:

>The only thing that interests me regarding this specific code is
>whether it is legal according to the Verilog LRM. 

It's LRM-legal.  Try this in any simulator:

module loop;
  integer i;
  initial begin
    for (i=0; i<100; i=i+1) begin
      $display("loop %0d", i);
      i = i * 2;
    end
  end
endmodule

>Xilinx claims that my above code is illegal

They're wrong.

>The variable i is only used during synthesis to create the appropriate
>amount of hardware to do the job. 

Of course.  If you use a loop in any other way,
it will probably not be synthesisable.

>The "i = NUM_LOOPS" should create
>hardware identical to using a found variable.

That's less obviously true.  I agree that it will work that
way in simulation, but synthesis must unroll the loop and
therefore it must treat the loop counter as a constant on
each trip around the loop.  Hacking a loop counter is an
unpleasant thing to do even in software, but it is a crazy
thing to do for synthesis.

> I also never bother to
>create local i variables b/c I do not use them as values, but only as
>loop iterators, and as the iterators are synthesized away by
>definition there should be no fear of them interacting with each
>other.

In synthesis, and in practice, you are right.  But it is a very
bad habit to get into, and "by definition" there most definitely
IS a fear of them interacting, because of Verilog's scheduling
semantics that allows arbitrary interleaving of concurrent
processes.  As soon as you start writing testbench code 
that has time delays in loops, this becomes a very serious
problem indeed - and one that is very easily fixed by 
using locally-declared loop counters.

> In that sense the i variable is likened to a generate loop.

In the sense that it is unrolled for synthesis, yes.  But
that is NOT the Verilog language semantics of a for-loop.

Interestingly, you seem to be contradicting yourself here.
I agree that procedural for-loops act somewhat like
generate-for loops in synthesis.  But surely you would 
not expect to be able to modify a genvar loop counter 
in the body of a generate-for loop?  So why do you think 
it's a good idea to modify a procedural loop counter 
in the body of a for-loop that will be synthesised?

>This is also evidenced by the workaround I have been forced to
>implement due to XST's inability with exiting for loops:
>
>integer i;
>always @(posedge clk)
>begin
> i = 0;
> found = 0;
> go <= 0; //resetting go :)
> while((i < NUM_LOOPS) && !found)
> begin
>  if(ready[i])
>  begin
>   go[i] <= 1;
>   found = 1;
>  end
>  i = i + 1;
> end
>end

Interesting; there are many synthesis tools that cannot
handle while loops, so I suggest that the (very similar)
workaround that I showed you in my previous posting is 
more likely to be portable.

>I have this type of code in my modules multiple times over for various
>loop situations, and they all use the same i variable. 

As I've already explained, that is probably OK for synthesis
but it's unnecessarily poor style.

>That code is
>properly synthesized. This page http://www.xilinx.com/support/answers/22066.htm
>shows that XST has issues with multiple for loops in the same module
>using the same iterator. That is listed by them as a bug which needs
>to be worked around, but they don't mention anything about it being
>illegal or dangerous.

Locally declared loop iterators are...
- more stylish and easier to understand
- essential when you write testbench code
- much less likely to excite that kind of bug
So why make life difficult for yourself, your code reviewers
and the synthesis tool?

>Can I get a better explanation as to why my originally suggested for
>loop is so bad? Your comment that it is ghastly makes me wonder.

Can you spell "information hiding" or "locality of reference"? 
Locality is always good if you can do it.  Letting things
float out to a less local context than necessary, like your
shared loop variables, is error-prone and confusing.
If my 'i' is localized to the block that uses it, then other
blocks can do anything they want with some other 'i' and 
everything is OK.  If your loop counter is global, you can
easily make silly mistakes:

  module foo (...ports...);

    reg [7:0] counter;

    always @(posedge clock) begin
      if (count_enable)
        counter <= counter + 1;
    end

    always @(whatever)
      for (counter = 0; counter <= LIMIT; counter = counter + 1)
        ...

see what I mean?  no, of course you wouldn't do that, and of 
course you would get errors from synthesis, but why expose yourself
to the risk when it's so easy to do local declaration of variables
that are only locally relevant?

>I would love to know if the Verilog LRM fully supports my code? 

As I already said, yes, it does.  Nowhere does the LRM say that
it's illegal to write to a loop counter.

>I want Xilinx to fix XST to support it as I believe it should.

I want lots of other things much, much more than I want that.

-- 
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: 141248
Subject: NTSC/PAL Encoder using FPGA and DAC
From: wallge <wallge@gmail.com>
Date: Fri, 12 Jun 2009 08:58:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am looking into putting a triple video DAC (eg ADV7123, ADV7125)
onto an FPGA board that I am building to do VGA component output.

If I wanted to have an NTSC composite output, rather than RGB
component VGA style outputs, could I repurpose one of my DACs and use
it for NTSC?

I know that there are some ICs that will take in bt601/bt656 and turn
it into NTSC/PAL for me, but these will typically not support the
range of VGA output resolutions that I would also like to support.

It seems that there are quite a few signal processing stages necessary
for getting from 24-bit RGB to composite NTSC, including: RGB to YUV,
Oversampling, Multi-tap LPFs,
Quadrature subcarrier generation, channel summation.

Do you think this can all be done in the digital domain, and then sent
out of the FPGA to the video DAC at the last step? It's just that I
would like to be able to use a single IC to generate VGA outputs as
well as NTSC outputs (although not both at the same time).

Does anyone have experience with implementing the algorithm to go from
RGB to NTSC/PAL? Are there any tricky things that I need to be careful
about?

Is anyone aware of a free/open implementation of this algorithm, or
parts of it, out there on the internets? I have been able to find a
rough description of most of the parts, but not a complete and
detailed narrative of the workings of each of the components.
Does ITU-R BT.470-7 describe the algorithm in detail? I have not been
able to find this document on the web anywhere, but have seen plenty
of places that reference it...

thanks,

Article: 141249
Subject: Re: Verilog "for loop" - exit by setting i to exit value?
From: nachumk <nachumk@gmail.com>
Date: Fri, 12 Jun 2009 09:10:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 12, 5:56=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 12 Jun 2009 07:30:25 -0700 (PDT), nachumk wrote:
> >The only thing that interests me regarding this specific code is
> >whether it is legal according to the Verilog LRM.
>
> It's LRM-legal. =A0Try this in any simulator:
>
> module loop;
> =A0 integer i;
> =A0 initial begin
> =A0 =A0 for (i=3D0; i<100; i=3Di+1) begin
> =A0 =A0 =A0 $display("loop %0d", i);
> =A0 =A0 =A0 i =3D i * 2;
> =A0 =A0 end
> =A0 end
> endmodule
>
> >Xilinx claims that my above code is illegal
>
> They're wrong.
>
> >The variable i is only used during synthesis to create the appropriate
> >amount of hardware to do the job.
>
> Of course. =A0If you use a loop in any other way,
> it will probably not be synthesisable.
>
> >The "i =3D NUM_LOOPS" should create
> >hardware identical to using a found variable.
>
> That's less obviously true. =A0I agree that it will work that
> way in simulation, but synthesis must unroll the loop and
> therefore it must treat the loop counter as a constant on
> each trip around the loop. =A0Hacking a loop counter is an
> unpleasant thing to do even in software, but it is a crazy
> thing to do for synthesis.
>
> > I also never bother to
> >create local i variables b/c I do not use them as values, but only as
> >loop iterators, and as the iterators are synthesized away by
> >definition there should be no fear of them interacting with each
> >other.
>
> In synthesis, and in practice, you are right. =A0But it is a very
> bad habit to get into, and "by definition" there most definitely
> IS a fear of them interacting, because of Verilog's scheduling
> semantics that allows arbitrary interleaving of concurrent
> processes. =A0As soon as you start writing testbench code
> that has time delays in loops, this becomes a very serious
> problem indeed - and one that is very easily fixed by
> using locally-declared loop counters.
>
> > In that sense the i variable is likened to a generate loop.
>
> In the sense that it is unrolled for synthesis, yes. =A0But
> that is NOT the Verilog language semantics of a for-loop.
>
> Interestingly, you seem to be contradicting yourself here.
> I agree that procedural for-loops act somewhat like
> generate-for loops in synthesis. =A0But surely you would
> not expect to be able to modify a genvar loop counter
> in the body of a generate-for loop? =A0So why do you think
> it's a good idea to modify a procedural loop counter
> in the body of a for-loop that will be synthesised?
>
>
>
> >This is also evidenced by the workaround I have been forced to
> >implement due to XST's inability with exiting for loops:
>
> >integer i;
> >always @(posedge clk)
> >begin
> > i =3D 0;
> > found =3D 0;
> > go <=3D 0; //resetting go :)
> > while((i < NUM_LOOPS) && !found)
> > begin
> > =A0if(ready[i])
> > =A0begin
> > =A0 go[i] <=3D 1;
> > =A0 found =3D 1;
> > =A0end
> > =A0i =3D i + 1;
> > end
> >end
>
> Interesting; there are many synthesis tools that cannot
> handle while loops, so I suggest that the (very similar)
> workaround that I showed you in my previous posting is
> more likely to be portable.
>
> >I have this type of code in my modules multiple times over for various
> >loop situations, and they all use the same i variable.
>
> As I've already explained, that is probably OK for synthesis
> but it's unnecessarily poor style.
>
> >That code is
> >properly synthesized. This pagehttp://www.xilinx.com/support/answers/220=
66.htm
> >shows that XST has issues with multiple for loops in the same module
> >using the same iterator. That is listed by them as a bug which needs
> >to be worked around, but they don't mention anything about it being
> >illegal or dangerous.
>
> Locally declared loop iterators are...
> - more stylish and easier to understand
> - essential when you write testbench code
> - much less likely to excite that kind of bug
> So why make life difficult for yourself, your code reviewers
> and the synthesis tool?
>
> >Can I get a better explanation as to why my originally suggested for
> >loop is so bad? Your comment that it is ghastly makes me wonder.
>
> Can you spell "information hiding" or "locality of reference"?
> Locality is always good if you can do it. =A0Letting things
> float out to a less local context than necessary, like your
> shared loop variables, is error-prone and confusing.
> If my 'i' is localized to the block that uses it, then other
> blocks can do anything they want with some other 'i' and
> everything is OK. =A0If your loop counter is global, you can
> easily make silly mistakes:
>
> =A0 module foo (...ports...);
>
> =A0 =A0 reg [7:0] counter;
>
> =A0 =A0 always @(posedge clock) begin
> =A0 =A0 =A0 if (count_enable)
> =A0 =A0 =A0 =A0 counter <=3D counter + 1;
> =A0 =A0 end
>
> =A0 =A0 always @(whatever)
> =A0 =A0 =A0 for (counter =3D 0; counter <=3D LIMIT; counter =3D counter +=
 1)
> =A0 =A0 =A0 =A0 ...
>
> see what I mean? =A0no, of course you wouldn't do that, and of
> course you would get errors from synthesis, but why expose yourself
> to the risk when it's so easy to do local declaration of variables
> that are only locally relevant?
>
> >I would love to know if the Verilog LRM fully supports my code?
>
> As I already said, yes, it does. =A0Nowhere does the LRM say that
> it's illegal to write to a loop counter.
>
> >I want Xilinx to fix XST to support it as I believe it should.
>
> I want lots of other things much, much more than I want that.
>
> --
> 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Hi Jonathan,

First of all I'd like to thank you for a very well written response.

Regarding whether the i =3D NUM_LOOPS is equal in synthesis to found =3D
1, I believe they are equal, and I don't understand the claim that
they aren't. I think both would be unrolled NUM_LOOPS time, and once i
=3D NUM_LOOPS is hit it should build the same logic as found =3D 1 and
mask out the rest of the unrolled hardware.

Declaring i as local is a good idea, and I appreciate your comments
about simulation in this regard. I write my code with synthesis in
mind, and therefore the simulation consideration was not accounted
for. I will modify my coding habits accordingly.

I never though of doing the same thing for generate loops, but I guess
that should be valid in theory. I can't imagine the situation which
would make such code necessary as there is nothing variable about
generate loops as opposed to for loops whose execution can be
variable.

My complaint against Xilinx is that their tool doesn't support code
which is LRM valid, and instead of stating that XST doesn't support
this type of for loop, as they said regarding the disable keyword,
they claim that it is illegal code. I would be happy to have an error
from XST stating that my code is unsupported, but synthesizing my code
wrong which is currently the case is unacceptable. Their bug cost me
many hours of debugging what turned out to be completely correct code.
After modifying my code to use a while loop everything started working
correctly.

Thanks for your comments, they have been very helpful. I have come
away from this thread learning some new things.

All the best,
Nachum Kanovsky
http://www.linkedin.com/in/nachumkanovsky
http://ionipti.blogspot.com/



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