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 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. JohnArticle: 99726
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: 99727On 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. JohnArticle: 99728
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! RichArticle: 99729
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: 99730Michael 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
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: 99732The "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
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
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: 99735John 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, NijmegenArticle: 99736
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 . -ShyamArticle: 99737
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 JanArticle: 99738
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. JohnArticle: 99739
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 :) -jgArticle: 99740
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: 99741John- 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. -JeffArticle: 99742
"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
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
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: 99745Jan 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, BenArticle: 99746
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
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. -ArtArticle: 99748
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
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:
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