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 99725

Article: 99725
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 28 Mar 2006 11:24:37 -0800
Links: << >>  << T >>  << A >>
On 28 Mar 2006 10:29:55 -0800, "Jeff Brower" <jbrower@signalogic.com>
wrote:

>John-
>
>Bill Sloman has a point, you shouldn't be so hard on him.

Sloman has, for years, followed me around, biting at my ankles,
changing the subject from technical issues to the subject of my
personal mental and nationalistic shortcomings. Our very first
encounter began just that way, and he's kept it up well past the point
of tedium. It's hard to not do what's natural, namely be outright
cruel to him, which would be both easy and satisfying.

>Many of our
>customers require a summary of what's been changed in a logic upgrade
>-- these tend to be the ones who know something about programmable
>logic.  If we listed "clock deglitch" then there would be a good chance
>they would want more information, which might lead to more discussion
>about using a delay line based on buffers (or whatever is your fix),
>which might lead to us having to update boards in the field with a
>hardware fix to a hardware problem (at our cost).  If one of my
>engineers omitted or lied about what we changed and I found out... well
>that's another problem, constrained by ethics and rules and not by
>creative thinking.

We've absolutely honest with all our customers. There are ten or so
similar units in the field, working fine, that could some day manifest
the clock glitch problem, and it would be easy to keep quiet and bet
that nothing goes wrong. We're going to tell them about the hazard,
and send them new roms to upgrade the FPGA configs. Our customers,
especially the areospace guys, love this sort of attitude.

>
>I hope your fix is solid and based on sound engineering techniques, and
>your customer -- if they knew -- would be Ok with it.  If so then I've
>missed the mark and I apologize in advance for chiming in.

No apology needed; different companies just have different customer
bases and different policies in cases like this. If it was a TV remote
that hit the wrong channel occasionally below 5 degrees C, I wouldn't
volunteer to replace them all. But our gadgets are testing jet
engines.

The current fix tests good and sure looks solid.

John



Article: 99726
Subject: Re: OpenSPARC released
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 28 Mar 2006 19:26:47 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <44285364@usenet01.boi.hp.com>,
at) hp . com  (no spaces)" <"J o h n _ E a t o n  (at) hp . com  (no spaces <"J o h n _ E a t o n  (at) hp . com  (no spaces)"> wrote:
>Jan Decaluwe wrote:

>> As for the SPARC code, it seems like an extreme example. I wouldn't
>> call this RTL code. It's more like a manually generated technology-
>> independent netlist. For example, they don't even use flip-flop
>> inference. And they do have excessive hierarchy.

>> I suspect that it should be possible to gain at least an order
>> of magnitude in terms of lines of code by using a proper RTL
>> style. And the synthesis results might be better. (Excessive
>> hierarchy tends to yield suboptimal synthesis results).

>That's what I was afraid of. Structural netlists are useful for transmitting
>an intact design without revealling the "real source" code. That code is what
>you need if you really want to understand or modify the design.

I've looked at the code: it's not machine generated at all.  It was actually
written in this style.  All of the logic is in 'assign' statements and all
of the flip flops are instantiated primitives.

There is an advantage to coding this way, even in FPGAs.  If you want to
hand place everything, you get no (or almost no) synthesis generated names. 
This will preserve your placement work if you need to re-synthesize.

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 99727
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 28 Mar 2006 11:33:31 -0800
Links: << >>  << T >>  << A >>
On Tue, 28 Mar 2006 17:37:31 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Hello John,
>
>> 
>>>Have you tried another brand of 16MHz clock oscillator? Farnell have
>>>heaps of alternative parts avaialble off the shelf  in a variety of
>>>packages.
>> 
>> What's a Farnell?
>> 
>
>Bill is in Europe. Farnell is one of the distributors over there and 
>AFAIK cooperates with Newark on this side of the pond.

Oh, I knew that; Bill plugs Farnell in most of his posts. But why
would I buy oscillators from Farnell, when we're 40 miles away from a
zillion distributors in Silicon Valley? And I pointed out, certainly
no more than six or eight times, that I was looking for a fix that did
*not* involve hacking the hardware.


>> We could have sent them a small ferrite disk, to be glued into the top
>> of the board over the clock trace (we'd of course furnish a tube of
>> glue, no extra charge) that would fix it too. But I think the ROM swap
>> is more professional and managerial.
>> 
>
>Cool. You could ship these in prescription med containers and call it 
>"Extra Strength Larkinin" or something like that. With luck someone will 
>later claim that they cure rheumatism and you'd have a new biz line that 
>probably makes more money than anything before.

Cruel but true.

John


Article: 99728
Subject: Re: deglitching a clock
From: Rich Grise <richgrise@example.net>
Date: Tue, 28 Mar 2006 19:36:01 GMT
Links: << >>  << T >>  << A >>
On Tue, 28 Mar 2006 08:17:23 -0800, John Larkin wrote:
...
> Spare me your armchair theorizing; it's not a "hardware problem" or a
> "software problem", it's just a problem. 
...

Q: How many programmers does it take to change a light bulb?
A: None, that's a hardware problem.

Q: How many engineers does it take to change a light bulb?
A: No problem! We'll fix it in software!

;-)

Cheers!
Rich


Article: 99729
Subject: xst and fpga express
From: "uckingcu" <uckingcu@yahoo.com>
Date: Tue, 28 Mar 2006 13:37:57 -0600
Links: << >>  << T >>  << A >>
Hi all,
           i am working in a network security company..i got a question..i
am using a very big design targeted for xilinx virtex2 xc2v3000 device..i
found a interesting problem recently...i used my design with
xst7.1,everything works fine in functional simulation but after i download
onto fpga,only some functions works. I also built fpga design with fpga
express and downloaded onto fpga..for my surprise,all the functions work
when tested at board level..i could not understand this.

can anyone explain differences between fpga exprees tool and xst7.1

thankx



Article: 99730
Subject: Re: C-based FPGA programming/mixed languages
From: fpga_toys@yahoo.com
Date: 28 Mar 2006 12:00:13 -0800
Links: << >>  << T >>  << A >>

Michael Sch=F6berl wrote:
> The biggest problem comes with "thinking in hardware" which turnes out
> to be quite a problem for C-people ... the sequential way of planing
> your programm usually does not fit very well and will waste a lot of
> ressources ...

C-people are hardly all the same cookie cutter experience levels, any
more than hardware engineers are. Many have both the experience and
skill levels to do C based hardware design with modest training on the
tools.  There are embedded, device driver, and parallel programming
C-people that are very used to concurrency in their programming styles.

> To get a deep understanding about whats really happening inside and why
> some description is not very clever will take you well above .5 years

Again, when you say "you", it's probably an unfounded generalization
without any understanding of the OP's training, experience, or skills.
Such blind generalizations are ....


Article: 99731
Subject: Re: OpenSPARC released
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Tue, 28 Mar 2006 22:28:16 +0200
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> In article <44285364@usenet01.boi.hp.com>,
> at) hp . com  (no spaces)" <"J o h n _ E a t o n  (at) hp . com  (no spaces <"J o h n _ E a t o n  (at) hp . com  (no spaces)"> wrote:
> 
>>Jan Decaluwe wrote:
> 
> 
>>>As for the SPARC code, it seems like an extreme example. I wouldn't
>>>call this RTL code. It's more like a manually generated technology-
>>>independent netlist. For example, they don't even use flip-flop
>>>inference. And they do have excessive hierarchy.
> 
> 
>>>I suspect that it should be possible to gain at least an order
>>>of magnitude in terms of lines of code by using a proper RTL
>>>style. And the synthesis results might be better. (Excessive
>>>hierarchy tends to yield suboptimal synthesis results).
> 
> 
>>That's what I was afraid of. Structural netlists are useful for transmitting
>>an intact design without revealling the "real source" code. That code is what
>>you need if you really want to understand or modify the design.
> 
> 
> I've looked at the code: it's not machine generated at all.  It was actually
> written in this style.  All of the logic is in 'assign' statements and all
> of the flip flops are instantiated primitives.

Note that I called it a *manually* generated technology-independent
netlist.

> There is an advantage to coding this way, even in FPGAs.  If you want to
> hand place everything, you get no (or almost no) synthesis generated names. 
> This will preserve your placement work if you need to re-synthesize.

That sounds like a weak argument to me. Hand place everything?
With the complexity of today's and future FPGAs, I believe there's
little choice but assuming that synthesis and layout tools work fine -
they should by now.

Even if there would be real advantage to that coding style (I don't
know it), the price you pay is very large: unmaintainable, unreadable
code which is probably an order of magnitude larger than proper RTL.
And again, better code may well synthesize better and therefore
be easier to layout :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Article: 99732
Subject: Re: combinatorial always blocks + for-loops in XST
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 28 Mar 2006 20:34:16 GMT
Links: << >>  << T >>  << A >>
The "always @*" or "always @(*)" equivalent construct is a Verilog2001 
catchall for the sensitivity list.  If you don't choose Verilog2001 support 
(it's optional in the Synplify compiler) or if XST 7.1.04i doesn't support 
that construct, you would do best to include the full sensitivity list - 
"always @(b or bit)"

Also - since the "for" statement is a single statement, the begin/end 
constructs are superfluous; they do no harm but they add nothing.  It's only 
when there are multiple lines that the begin/end are needed.


"Jeff Brower" <jbrower@signalogic.com> wrote in message 
news:1143571625.151565.45160@v46g2000cwv.googlegroups.com...
> John-
>
>> reg [31:0] a;
>> reg [7:0] b [31:0];
>> reg [2:0] bit;
>> integer i;
>> always @*
>>   for( i=0; i<32; i=i+1 )
>>     a[i] = b[i][bit];
>
>> A doesn't need to be declared a wire to be a combinatorial value. 
>> Because
>> the always block is a combinatorial block, the reg value is a 
>> combinatorial
>> result, not implemented as a flip-flop or "register" primitive.  The 
>> always
>> constructs need reg-declared variables to work.
>
> Ok, got it.  I suppose I can think of it as a latch, always enabled.
> But to let you know XST doesn't like the "*".  To synthesize, I had to
> use:
>
> always begin
>  for (i=0; i<32; i=i+1)
>    a[i] = b[i][bit];
> end
>
> Is it equivalent?  XST complains that b and bit are missing from the
> sensitivity list.
>
> -Jeff
> 



Article: 99733
Subject: Re: OpenSPARC released
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 28 Mar 2006 20:38:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <44299C60.5030105@jandecaluwe.com>,
Jan Decaluwe  <jan@jandecaluwe.com> wrote:
>Joseph H Allen wrote:

>> I've looked at the code: it's not machine generated at all.  It was actually
>> written in this style.  All of the logic is in 'assign' statements and all
>> of the flip flops are instantiated primitives.

>Note that I called it a *manually* generated technology-independent
>netlist.

>> There is an advantage to coding this way, even in FPGAs.  If you want to
>> hand place everything, you get no (or almost no) synthesis generated names. 
>> This will preserve your placement work if you need to re-synthesize.

>That sounds like a weak argument to me. Hand place everything?
>With the complexity of today's and future FPGAs, I believe there's
>little choice but assuming that synthesis and layout tools work fine -
>they should by now.

>Even if there would be real advantage to that coding style (I don't
>know it), the price you pay is very large: unmaintainable, unreadable
>code which is probably an order of magnitude larger than proper RTL.
>And again, better code may well synthesize better and therefore
>be easier to layout :-)

Well they might not have any choice but hand placement for high performance
CPUs, but I don't really know.  I've not had to opportunity to make a
multi-GHz design.  Otherwise I agree with, especially about FPGAs.  I did
one hand placed design in Virtex-E: 175 MHz (with hand made DDR macros). 
But it was very simple.  However, bad things did happen when you changed
versions of the synthesis tools.  Synplicity frequently likes to change how
their machine generated names are generated.

For anything more complicated, the tools are better than hand hand-placed,
and the benefits of having clean verilog obviously are going to outweigh any
imagined gain, so I basically agree with you.

Anyway, I've been trying to figure out if this SPARC is superscalor or not.
It does not appear to have any dataflow management logic and the main
register file is only 5 ports, so I suspect not.  Also, I've heard that the
real high performance chips use latches and dynamic logic.  I've always
wondered how this showed up in RTL, but this chip appears to only use plain
old d-flip flops.  It's cool to look at the floating point unit.

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 99734
Subject: Keystroke saving w/ IEEE.Numeric_Std
From: "JustJohn" <john.l.smith@titan.com>
Date: 28 Mar 2006 12:39:22 -0800
Links: << >>  << T >>  << A >>
When you want a one of eight decoder, are you tired of typing in:

with Phase_Ctr
  select Phase <=
    "00000001" when "000",
    "00000010" when "001",
    "00000100" when "010",
    "00001000" when "011",
    "00010000" when "100",
    "00100000" when "101",
    "01000000" when "110",
    "10000000" when "111",
    "00000000" when others;

Then start taking advantage of IEEE.Numeric_Std:

Phase <= ROTATE_LEFT( "00000001", TO_INTEGER( Phase_Ctr ) );

This is equally clear, and should sim/synth just the same.

Other examples welcome...

Sidebar request to Xilinx:
I love the vhdl template your ISE produces when adding a new source,
but it still starts things off with:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

That is so '90s, we're over halfway through the 00's. Is there any way
to change your ISE vhdl template to:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

Regards all,
Just John


Article: 99735
Subject: Re: deglitching a clock
From: bill.sloman@ieee.org
Date: 28 Mar 2006 12:45:23 -0800
Links: << >>  << T >>  << A >>

John Larkin wrote:
> On 28 Mar 2006 01:07:52 -0800, bill.sloman@ieee.org wrote:
>
> >
> >John Larkin wrote:
> >> On 27 Mar 2006 15:00:52 -0800, bill.sloman@ieee.org wrote:
> >>
> >> >
> >> >John Larkin wrote:
> >> >> We have a perfect-storm clock problem.
> >
> ><snip>
> >
> >> If we wanted to spin the board layout, we could just put in the
> >> risetime-limiting inductor, or add a meaty clock buffer, or better yet
> >> add a series resistor, with maybe an optional cap to ground, to slow
> >> down the sig on the clock line, and then add a Tiny Logic schmitt
> >> buffer at each chip. But as I noted, the challenge here is to find a
> >> software-only fix.
> >
> >This is the manager talking, rather than the engineer. This is a
> >hardware problem, and it sounds as if you've already spent more time on
> >trying to find a software sticking-plaster than is cost-effective.
>
> Spare me your armchair theorizing; it's not a "hardware problem" or a
> "software problem", it's just a problem. We have, in a few hours,
> found and tested an excellent FPGA-internal fix that we can pop into a
> rom and mail to our customers. We'll include a couple of other nice
> firmware improvements, while we're at it. Your definitions of
> "manager" and "engineer" do not constrain my latitude to think.

So the Fpga to Fpga routing worked - good.

> >Have you tried another brand of 16MHz clock oscillator? Farnell have
> >heaps of alternative parts avaialble off the shelf  in a variety of
> >packages.
>
> What's a Farnell?

The peope who bought Newark. Win Hill got their catalogue years ago -
they are just another broad-line distributor. I check out the Digi-Key
catalogue from time to time (and don't like it as much) but Farnell's
is the one that I've largely memorised.

> >If the part you are using really does have a built-in source
> >termination resistor - which does seem to be the most likely
> >explanation of the flat spot on the clock waveform at Fpga1 - swapping
> >to a different manufacturer might cure the problem.
>
> I already explained: it's too fast and too weak to drive our
> low-impedance clock line.

"Fast" and "weak" is an odd combination - FWIW my impression was that
packaged crystal oscillators used regular logic chips.

> It's wildly improbably that a $1.50, 16 MHz
> xo would deliberately include a series terminator... what value would
> they pick?

If they were selling stuff that mostly went onto PCI bus lines, they
might read the spec. AMD sold a TTL line driver for years with roughly
22R built into the pull-down side of the output to match the output
impedance of the pull-up circuit. Around 22R was commonly used to tame
(but not source terminate) outputs driving long buses.

>And I already explained, several times, we don't want to
> recall all the units in the field.

Nobody ever does. Cambridge Instrument's service engineers used to
change parts on boards on-site, which wasn't cheap either, and you'd
seem to be working working with roughly the same kinds of customers.

> We could have sent them a small ferrite disk, to be glued into the top
> of the board over the clock trace (we'd of course furnish a tube of
> glue, no extra charge) that would fix it too. But I think the ROM swap
> is more professional and managerial.

Much more professional-looking, provided that it works.

-- 
Bill Sloman, Nijmegen


Article: 99736
Subject: Re: OpenSPARC released
From: "Shyam" <shyam.thoziyoor@gmail.com>
Date: 28 Mar 2006 12:50:42 -0800
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:

Anyway, I've been trying to figure out if this SPARC is superscalor or
not. It does not appear to have any dataflow management logic and the
mainregister file is only 5 ports, so I  suspect not.

---Yeah, I suspect the existing Verilog is not for a superscalar
microarchitecture. Check out
http://forum.sun.com/thread.jspa?threadID=28739 .

-Shyam


Article: 99737
Subject: Re: Altera web site inaccessible
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Tue, 28 Mar 2006 21:20:23 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Wed, 29 Mar 2006 01:06:17 +0200) it happened Ben Twijnstra
<btwijnstra@gmail.com> wrote in
<94180$4429a2ee$d52e23a9$20068@news.chello.nl>:

>Jan Panteltje wrote:
>
>> So would it be possible to synthesize with Altera to EDIF, then use the
>> EDIF in Webpack to program a Spartan?
>> Have to look into that......
>
>It won be optimal, but I happen to know one Philips lab that did something
>similar - but they used the eqn file to convert to xnf. Does ISE still use
>XNF?
Well, I think not, but somebody will likely correct me.
What happened now was this:
I got stuck in the weekend when my video filter would not compile on
webpack-8.1i.
It gave some error case, and that indicated the 'bug' would be fixed in 8.2.
So....
And I believed what it did say.....
So I took my project, put it into Quartus, and it told me about a silly typo
I made.
I fixed that, then it compiled without errors in the Altera soft....
So today I took the corrected version back to webpack, and have now the best
video filter I had so far, just sat there looking at the scope... cool.
The lesson to learn here is one for Xilinx I think:
For Gods sake give a sane error message.
They completely send you on the wrong track.
I know why, the X soft will synthesise, and then get stuck and tell you how
it got stuck.
The Altera soft did some simple checking before it started and told me about
my error.

Anybody remember the old ZX81 / Sinclair Spectrum?
That BASIC was soooo popular because it did error checking on each line
entered.
Hey even iverilog did not catch this....
It can save the user many many hours.....

So, even if the X soft was better then the A soft (I dunno, I have a different
feeling), the program with the better error checking (and sane messages) will
save you +++++hours and so money too.

Of course the advantage of the capitalist world is competition.... So we use
the best of both.
Next time in a similar case I will run on Quartus too to see what happens.

But X should fix that really.....

Groeten
Jan


Article: 99738
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 28 Mar 2006 13:28:40 -0800
Links: << >>  << T >>  << A >>
On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote:


>So the Fpga to Fpga routing worked - good.

That's not what we did. We designed a clock deglitcher to go inside
the FPGA.

John



Article: 99739
Subject: Re: Quartus Compiler as Quailty Check for WebPack
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 29 Mar 2006 09:50:08 +1200
Links: << >>  << T >>  << A >>
Jan Panteltje wrote:
> Well, I think not, but somebody will likely correct me.
> What happened now was this:
> I got stuck in the weekend when my video filter would not compile on
> webpack-8.1i.
> It gave some error case, and that indicated the 'bug' would be fixed in 8.2.
> So....
> And I believed what it did say.....
> So I took my project, put it into Quartus, and it told me about a silly typo
> I made.
> I fixed that, then it compiled without errors in the Altera soft....
> So today I took the corrected version back to webpack, and have now the best
> video filter I had so far, just sat there looking at the scope... cool.
> The lesson to learn here is one for Xilinx I think:
> For Gods sake give a sane error message.
> They completely send you on the wrong track.
> I know why, the X soft will synthesise, and then get stuck and tell you how
> it got stuck.
> The Altera soft did some simple checking before it started and told me about
> my error.
> 
> Anybody remember the old ZX81 / Sinclair Spectrum?
> That BASIC was soooo popular because it did error checking on each line
> entered.
> Hey even iverilog did not catch this....
> It can save the user many many hours.....
> 
> So, even if the X soft was better then the A soft (I dunno, I have a different
> feeling), the program with the better error checking (and sane messages) will
> save you +++++hours and so money too.
> 
> Of course the advantage of the capitalist world is competition.... So we use
> the best of both.
> Next time in a similar case I will run on Quartus too to see what happens.

sounds like a good idea.

> 
> But X should fix that really.....

Of course, and to 'help them along', we can meanwhile promote using 
Quartus as a 'second opinion', should a designer ever hit an unhelpful 
WebPack error message.

I have changed the heading to help this :)

-jg


Article: 99740
Subject: Re: OpenSPARC released
From: "Art Stamness" <artstamness@gmail.com>
Date: 28 Mar 2006 14:00:41 -0800
Links: << >>  << T >>  << A >>
Please provide any evidence of this assertion :

   " The price you pay is very large: unmaintainable, unreadable code
     which is probably an order of magnitude larger than proper RTL."

This coding style which you so clearly denegrate as sub par, is
actually quite standard among high end chip development. Some reasons :


1) Much easier to swap flop models, because noone is allowed to write
there own always @ flop blocks. To replace the library for flops, it is
as simple as changing an include.

Attempting to do this in a "proper RTL" is actually  "unmaintainable".
Experience in porting a design from one technology library to the next
will give you the type of experience that shows these coding standards
are *necessary*, to be able to do this type of work, your "proper RTL"
style is inflexible compared to this.

2) The synthesis tool does not care. If you write up a inverter going
into a flop, or code up a flop with an inverting input, the synthesizer
doesn't care where you placed the code. The final result is the exact
same thing.

Now if you had followed these coding guidelines, swapping out this flop
can be done by tweaking the include path for the library, you would
have to visit every line of code in your design to see whether or not
the always block is actually a flop, and then recode by hand. ( Good if
you get paid by the hour, not so good for your employer ).

3) Rebalancing logic across clock domain crossings is easier when the
logic is seperate from the flop : X's are flops (a,b,c) is assign wires

   X1 --> a --> b --> c --> X2
   X1 --> a --> b --> X2 --> c

The only changes that need to occur, is the input from the X2 is
changed to be b, instead of c, and the input to c is changed to be the
output of X2 instead of the output of b.

Using "proper RTL", you might have coded "a,b,c" inside of an always
block. You then need to create more wires or modify an always blocks to
pull this logic out, and then hook it up. At the end, after you have
applied your timing fix, the code is larger.

Worse yet, you may have made a mistake. These things tend to happen,
and when you recoded this flop, you have have left some path out, and
have turned it into a latch. These types of mistakes are not possible
to do in a instance -- assign -- assign -- instance methodology.
because "always @(posedge...)" is not allowed in your code, it belong
inside a library.

Now you may say "But I am smarter than that!", well that is nice for
you. But when setting up a coding standard that needs to be used by
hundreds of engineers, and verified by tools, ad-hoc methods of "proper
RTL" get left in the dust behind rigid standards that prevent bad stuff
from happening in the first place.

Please consider that this chip was probably design by a group of
engineers easily topping 100+, there were many compiler tools,
synthesis, and other tools that needed to manipulate this code, and get
meaningful information from it. Having each engineer write in what you
describe as "proper RTL" style is not acceptable in these situations.
It is not flexible enough ( you have to add lines of code just to make
timing fixes), error prone ( you can write logic that is not possible
or available in your library ), and doesn't get you *any* better
results.

I fail to see any benefit from using your "proper RTL" style. If there
is some that would offset the costs I have listed above, I am open to
reconsider. And I realize if you have not been exposed to these ideas
before they may sound like problems that you have not faced. But these
problems are common among large scale IC's that need to be taped out
many technologies, and go through extensive ECO timing fixes to achieve
maximum performance. 

-Art


Article: 99741
Subject: Re: combinatorial always blocks + for-loops in XST
From: "Jeff Brower" <jbrower@signalogic.com>
Date: 28 Mar 2006 14:03:55 -0800
Links: << >>  << T >>  << A >>
John-

Many thanks.

> The "always @*" or "always @(*)" equivalent construct is a Verilog2001
> catchall for the sensitivity list.  If you don't choose Verilog2001 support
> (it's optional in the Synplify compiler) or if XST 7.1.04i doesn't support
> that construct, you would do best to include the full sensitivity list -
> "always @(b or bit)"

XST burps up "Unexpected event in always block sensitivity list." with
that syntax.

Even going sans list, the result is still not equivalent to the lengthy
assign statement.  XST changes routing enough to add 1 nsec on a local
clock net that I use as my canary.

> Also - since the "for" statement is a single statement, the begin/end
> constructs are superfluous; they do no harm but they add nothing.  It's only
> when there are multiple lines that the begin/end are needed.

Ya know.  Sorry... I've been trying so many darn things I kept 'em
there for experimenting.

-Jeff


Article: 99742
Subject: Re: combinatorial always blocks + for-loops in XST
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 28 Mar 2006 22:39:01 GMT
Links: << >>  << T >>  << A >>
"Jeff Brower" <jbrower@signalogic.com> wrote in message 
news:1143583435.146145.259790@v46g2000cwv.googlegroups.com...
> Even going sans list, the result is still not equivalent to the lengthy
> assign statement.  XST changes routing enough to add 1 nsec on a local
> clock net that I use as my canary.

*Never* count on a reference net for timing information to give you a clue 
on synthesis.  Synthesizers will move things around and place & routes 
confuse things further.  Only by checking the technology view post-synthesis 
will the "equivalence" be checked 100% to my satisfaction. 



Article: 99743
Subject: Re: Hand-drawn schematic symbols of ISE coregen cores revert to rectangles when underlying core parameters are changed!
From: "PeterC" <peter@geckoaudio.com>
Date: 28 Mar 2006 14:40:31 -0800
Links: << >>  << T >>  << A >>

Thanks Gabor.

The port sizes often do change so I think the best approach will be to
simply generate a wide range of cores and schematics and simply replace
the core as opposed to re-customizing it.

Cheers,
Peter.


Article: 99744
Subject: Re: OpenSPARC released
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 28 Mar 2006 22:56:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1143583241.607996.321520@t31g2000cwb.googlegroups.com>,
Art Stamness <artstamness@gmail.com> wrote:

>1) Much easier to swap flop models, because noone is allowed to write
>there own always @ flop blocks. To replace the library for flops, it is
>as simple as changing an include.

>Attempting to do this in a "proper RTL" is actually  "unmaintainable".
>Experience in porting a design from one technology library to the next
>will give you the type of experience that shows these coding standards
>are *necessary*, to be able to do this type of work, your "proper RTL"
>style is inflexible compared to this.

This only makes sense to me if you have different flops in the same design,
otherwise just rename the flop itself to match the one generated by the
synthesis tool.

So if the real problem is that you have different kinds of flops in the same
design, why not just attach an attribute to the 'reg' which becomes the
flop?

reg [15:0] foo /* synthesis attribute floptype="master_slave_3" */;

There is another advantage to this.  Definitions in include files are
frequently bad because they are global.  It is almost always better to use
parameters whenever possible- then you can reuse code in different ways by
overriding a parameter:

parameter main_flop="master_slave_3";

reg [15:0] foo /* synthesis attribute floptype=main_flop */;

>2) The synthesis tool does not care. If you write up a inverter going
>into a flop, or code up a flop with an inverting input, the synthesizer
>doesn't care where you placed the code. The final result is the exact
>same thing.

It doesn't care if you instantiate an inverter, but it certainly does care
if you code up a state machine with a 'case' statement.

Also, by instantiating flops, you are not giving the synthesis tool
information about the flop: in particular, the flop might have a built in
clock-enable pin that you want the synthesis tool to use.

>3) Rebalancing logic across clock domain crossings is easier when the
>logic is seperate from the flop : X's are flops (a,b,c) is assign wires

Why are you doing this in source code?  Can't your synthesis tool rebalance
the logic at this micro level?

>Worse yet, you may have made a mistake.

Human editing is bad.  Make the tool do it.

>I fail to see any benefit from using your "proper RTL" style. If there
>is some that would offset the costs I have listed above, I am open to
>reconsider. And I realize if you have not been exposed to these ideas
>before they may sound like problems that you have not faced. But these
>problems are common among large scale IC's that need to be taped out
>many technologies, and go through extensive ECO timing fixes to achieve
>maximum performance. 

IBM long ago showed that bugs were proportional to the number of lines. 
Thus anything that reduces the number of lines of code is going to reduce
your verification cost, which is substantial.

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 99745
Subject: Re: Altera web site inaccessible
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 29 Mar 2006 01:06:17 +0200
Links: << >>  << T >>  << A >>
Jan Panteltje wrote:

> So would it be possible to synthesize with Altera to EDIF, then use the
> EDIF in Webpack to program a Spartan?
> Have to look into that......

It won be optimal, but I happen to know one Philips lab that did something
similar - but they used the eqn file to convert to xnf. Does ISE still use
XNF?

Best regards,


Ben


Article: 99746
Subject: Re: OpenSPARC released
From: Jason Zheng <xin.zheng@jpl.nasa.gov>
Date: Tue, 28 Mar 2006 15:37:42 -0800
Links: << >>  << T >>  << A >>
Art,

You wrote quite a bit, but I cannot agree with any of your arguments.

Art Stamness wrote:
> Please provide any evidence of this assertion :
> 
>    " The price you pay is very large: unmaintainable, unreadable code
>      which is probably an order of magnitude larger than proper RTL."
> 
> This coding style which you so clearly denegrate as sub par, is
> actually quite standard among high end chip development. Some reasons :
> 
Care to show some examples? What "high end chip" are you talking about?

> 
> 1) Much easier to swap flop models, because noone is allowed to write
> there own always @ flop blocks. To replace the library for flops, it is
> as simple as changing an include.
> 
If you code your flops in always blocks, this is also true. The flops
are simply implied by the synthesis tools.

> Attempting to do this in a "proper RTL" is actually  "unmaintainable".
> Experience in porting a design from one technology library to the next
> will give you the type of experience that shows these coding standards
> are *necessary*, to be able to do this type of work, your "proper RTL"
> style is inflexible compared to this.
> 
Again, I don't see how writing always blocks is "unmaintainable." Maybe
I haven't had enough experience to "give me the type of experience."
Anyhow, suppose you had instantiated a dff that takes clock, din, clr,
and set inputs, and synchronous resets are generated from a mux logic.
Now, a new technology library gives you cells that has built-in
syncronous reset. To port to this new library, you must manually recode
all the synchronous reset logic. Compare this to an always block: you
don't need to do anything.

> 2) The synthesis tool does not care. If you write up a inverter going
> into a flop, or code up a flop with an inverting input, the synthesizer
> doesn't care where you placed the code. The final result is the exact
> same thing.
> 
> Now if you had followed these coding guidelines, swapping out this flop
> can be done by tweaking the include path for the library, you would
> have to visit every line of code in your design to see whether or not
> the always block is actually a flop, and then recode by hand. ( Good if
> you get paid by the hour, not so good for your employer ).
> 
If you had coded in an always block, you don't have to anything at all!
Any synthesis tool will figure out whether the cells have inverting
inputs or not. Even if you accidentally put two inverters along the
logic path, this will be optimized away from the truth tables
constructed by the synthesis tools.

> 3) Rebalancing logic across clock domain crossings is easier when the
> logic is seperate from the flop : X's are flops (a,b,c) is assign wires
> 
>    X1 --> a --> b --> c --> X2
>    X1 --> a --> b --> X2 --> c
> 
> The only changes that need to occur, is the input from the X2 is
> changed to be b, instead of c, and the input to c is changed to be the
> output of X2 instead of the output of b.
> 
Excuse me? Rebalancing across clock domains? It is never trivial and
what you offered only works when you are balancing with the SAME clock
domain.

> Using "proper RTL", you might have coded "a,b,c" inside of an always
> block. You then need to create more wires or modify an always blocks to
> pull this logic out, and then hook it up. At the end, after you have
> applied your timing fix, the code is larger.
> 
> Worse yet, you may have made a mistake. These things tend to happen,
> and when you recoded this flop, you have have left some path out, and
> have turned it into a latch. These types of mistakes are not possible
> to do in a instance -- assign -- assign -- instance methodology.
> because "always @(posedge...)" is not allowed in your code, it belong
> inside a library.
> 
That's a lot of assumptions, not to mention many synthesis tools
rebalance logic for you automatically.

> Now you may say "But I am smarter than that!", well that is nice for
> you. But when setting up a coding standard that needs to be used by
> hundreds of engineers, and verified by tools, ad-hoc methods of "proper
> RTL" get left in the dust behind rigid standards that prevent bad stuff
> from happening in the first place.
> 
> Please consider that this chip was probably design by a group of
> engineers easily topping 100+, there were many compiler tools,
> synthesis, and other tools that needed to manipulate this code, and get
> meaningful information from it. Having each engineer write in what you
> describe as "proper RTL" style is not acceptable in these situations.
> It is not flexible enough ( you have to add lines of code just to make
> timing fixes), error prone ( you can write logic that is not possible
> or available in your library ), and doesn't get you *any* better
> results.
> 
I see the complete opposite. Having 100+ engineers working on the same
project require them to actually understand each other's code quickly. A
netlist style is NIGHTMARE. RTL is created to be different from netlist
so that it is more readable.


Article: 99747
Subject: Re: OpenSPARC released
From: "Art Stamness" <artstamness@gmail.com>
Date: 28 Mar 2006 15:59:12 -0800
Links: << >>  << T >>  << A >>
I think the main point you are missing of mine is that these techniques
solve problems which it does not appear you are not familiar with.

Adding another layer of indirection in the form of an instantiated flop
model solves many of these problems and is an industry standard as far
as high end retargetable ASIC coding standards are concerned.

Each solution you have described involves adding more lines of code to
the actual RTL source, and strips out any layers of indirection. It
attaches implementation attributes directly to a design that is
intentionally high level, so that it can be retargetd. Those layers of
indirection are invisible to the tools that use them, synthesis, and
simulator, but provide flexibility for the person who needs to model
different behavior or change libraries.

Now maybe you have not had the need to do this, in which case it seems
superficial and a waste of time. But I can assure you, lots of time and
effort was spent in building these components this way for a very good
reason. 

-Art


Article: 99748
Subject: iverilog error messages (was: Altera web site inaccessible)
From: Ben Jackson <ben@ben.com>
Date: Tue, 28 Mar 2006 18:09:06 -0600
Links: << >>  << T >>  << A >>
On 2006-03-28, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
> Hey even iverilog did not catch this....
> It can save the user many many hours.....

What was the bug?  Can you create a test case so that iverilog could
be enhanced to print a useful message?

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

Article: 99749
Subject: Question about: Logic Levels in Critical Path
From: "hongyan" <hy34@njit.edu>
Date: 28 Mar 2006 16:17:34 -0800
Links: << >>  << T >>  << A >>
Hello here,
I have a 64bits adder (ALU) like this c<=Ain+Bin, there are 34 logic
levels in its critical path with Propagation time 3.447. Then I just
included this adder in my design and add some mux before the input A, B
like this: DAin is Ain after a register.

ProcALUAin : Process(c1, DAin) is
begin
if(c1='1') then
	ALUAin(31 downto 0) <= DAin(31 downto 0);	-- take the lower copy
	if(DAin(31)='0') then
		ALUAin(63 downto 32) <= X"00000000";
	else
		ALUAin(63 downto 32) <= X"11111111";
	end if; 	-
     else
	ALUAin <= DAin;
end if;
end process ProcALUAin;

Same thing for the input B.

Then when I do the synthesis, I got 33 logic levels (For another bigger
design including the adder, an even smaller number, ex 27) in the
critical path with Propagation time 5.043. I don't understand why the
number of logic level is less than the ALU alone. I suppose they should
be higher by adding the logic numbers.  I am using synplifypro 8.1 for
the synthesis.

Or because the timing analysis will analysis the muxes and adder
together, several levels in the critical path in the adder are not a
part in the new critical path, they are replace by a less logic levels
but higher delay induced the muxes. So the logic levels are less. I
don't think I expressed my idea clearly. It is clearer in my mind.
Sorry.




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