Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. RickArticle: 141226
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
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.orgArticle: 141228
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... RickArticle: 141229
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-ChiefArticle: 141230
> >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 youArticle: 141231
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. AustinArticle: 141232
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). AustinArticle: 141233
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? TIAArticle: 141234
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.comArticle: 141235
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.comArticle: 141236
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.comArticle: 141237
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
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. - BrianArticle: 141239
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
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 AnttiArticle: 141241
Hi, Since you got an assembler error, I was more thinking of your assembler code than your hardware implementation. G=F6ranArticle: 141242
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 KanovskyArticle: 141243
"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.pdfArticle: 141244
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. - BrianArticle: 141245
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: 141246On 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.comArticle: 141247
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: 141248I 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
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:
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